作者：风清淡雅的梦 | 来源：互联网 | 2023-05-28 06:07
测试流程梳理
1、摘要
写这篇文章的出发点是最近确实吸收了很多有营养的东西，同时也希望可以通过这篇文章，能够帮助测试同学理清项目流程，规范测试操作步骤。
作为一个刚走入职场的测试新人，工作中确实学到了很多，但是真正沉淀下来能与人津津乐道的并不多。
这篇文章也算是对自己曾经的工作内容进行梳理和归纳，也算是另一种鞭策自己的方式吧~
并且，感觉还不错…
第一节 测试前准备
＞ 需求分析：与客户沟通过需求后，测试组全体人员参与需求分析，明确项目需求。
＞ 设计评审：测试人员参加设计评审，提出设计文档的疑惑之处，深入了解业务，做到依据设计文档能够写出完整详细的测试用例。
＞ 编写用例：依据设计文档、产品需求文档，编写测试用例。
＞ 测试计划：测试计划在测试任务确定后，根据测试任务，测试人员，测试时间等做好规划。
＞ 执行测试：测试准备工作就绪后，执行测试。
流程图如下：
第二节 测试规范流程
＞ 开发提测：
提测阶段的意义在于确保经过测试人员测试之后的系统无特别严重的缺陷，无阻塞流程的缺陷，保证系统具备流畅的测试条件。
＞ 第一轮：
第一轮测试的依据是设计文档、产品需求文档，产出是测试用例的第一轮结果，也是正式测试流程中最重要的环节，理论上应该覆盖100%的测试点，以及50%以上的发散点。在这个阶段应该发现系统中90%以上的缺陷。整个测试耗时占到所有测试工作的三分之一【假设只有2轮测试】。
＞ 自动化回归测试：
一轮结束后，发现了系统中大量的缺陷，较为庞大的系统可能有几百个甚至几千个缺陷，在这些缺陷被修复后，整个系统是否引入新的缺陷，是否有新的重大问题，需要自动化脚本来进行检查和核实。
此时，也是进行回归测试的最好时机~
＞ 第二轮测试：
回归测试结束后，进行第二轮测试，第二轮测试的重点是验证第一轮的问题是否被修复，是否影响到其他功能模块，同时也要进行高密度的发散测试。
＞ 交替测试（也称交叉测试）：交替测试顾名思义，是将测试任务重新分工，同一个问题在不同的测试人员手中二次测试后，更能保证产品质量。
＞ 自动化脚本维护：
以上测试工作全部完成后，跟踪Git中的Issues（缺陷管理模块），在所有缺陷、错误都被修复后，录制最新系统的自动化脚本。
在发包（发布）之前，进行整个系统最全面的回归测试。
第三节 缺陷单管理
缺陷单是测试流程过程中具有重要意义的产物，不仅体现了测试人员的专业程度，更反馈了软件开发中暴露的各种问题，认真对待缺陷单，确保所有的缺陷都能被解决是保证产品质量的最基本要求。
缺陷单一般都分为新建、开发反馈、验证、关闭等环节，以Git为例，如何规范缺陷单的跟踪管理。
＞ Git问题新建：
Git问题单规则：
主题：简单地一句话概括问题，通过主题可以明白该问题想表达的内容是什么。
描述：还原问题出现的步骤（前置条件、测试步骤、预期结果、实际结果等内容）。
标签：缺陷/错误。
优先级：一般、严重、紧急。
指派给：对应问题的开发组组长。
提出人：Git提单人。
Time tracking：时间跟踪，预计修复时间为几天。
Due Date：问题修复的最晚截止日期。
Confidentiality：该缺陷的机密性。
原则上所有问题必须要有问题截图。
＞ 问题流转至关闭：
- 转开发后，开发回复为：请验证，问题单状态为：已修复。
- 问题单状态非已修复状态，测试组不予验证。
- 测试组问题验证过，问题单状态为已关闭/验证不通过/挂起。
- 已关闭：该问题测试组验证通过
- 验证不通过：该问题验证不通过。
- 挂起：该问题开发当前版本不修改（暂时忽略）：请对应测试同学让开发在开发回复中回复不修改原因（修改中问题测试人员无法挂起，请联系开发人员修改状态）。
流程图如下：
原则上最后测试组所提Git问题单最后只能是已关闭，但由于特殊原因可以允许挂起状态。
特殊原因：该问题不影像用户使用，对用户基本无影响；该问题当前版本修复风险巨大，这两种情况可挂起，开发回复中写清楚下个版本修复原因。
＞ Wiki历史遗留问题：
每次版本正式测试前，测试组确认上次版本遗留问题在本次中是否修复。
上次Git遗留问题，确认本次版本修复的，测试组修改Git问题单系统版本号。
为本次版本的缺陷或错误，问题单状态修改为新建。
2、同问题单流转至关闭流程
流程图如下：
案例剖析：
测试人员Co在系统功能测试时发现某个新建数据的操作：新建数据有个生成数量的输入框，生成数量没有做限制，于是Co—次生成了1000万条数据，生成之后，对应页面由于大量的数据导致页面打开极其缓慢，影响到工作效率。那么问题来了？如果是你,会如何解决这个问题呢？
为了解决这个问题，Co提出，删掉生成的这1000万条用不到的数据，将生成数量字段做了条件限制，于是开发人员给生成数量字段加了每次最多生成100条数据。
几天后，领导找到Co，因为当时庞大的数据，正好发现了一个数据同步的问题，因为数据量巨大，导致同步数据的过程中，丢失了部分数据，于是，领导要求恢复千万条数据场景再次同步数据分析下问题原因，但是数据已经被删掉了，且因为数据关联性复杂后台也无法重现。
测试Co是万不会想到这批数据会影响到数据同步，但是引发的数据同步问题同时也 引出一个新的问题，就是Co在处理这批大数据时的做法究竟合理吗？
我们知道，系统的问题除了功能问题，还有性能问题，虽然这千万条数据不会影响 到功能，但是访问页面变得缓慢了问题本质则变成了性能问题了，而Co则完全没有想到 这批数据是不可以删除的，而是应该经过性能分析从而判定这批数据是否有存在的必要 性或者如何提高系统的性能以迖到大量数据存在时，页面访问流畅无阻。
希望这个案例能带给测试人员一个小小的思考：发现问题的解决方法有很多，但是 往往由于考虑不周而选择了最捷径的方法。用简单的方式解决了一个小问题，同时也掩 盖了一个大问题。
发现问题，分析问题，不放过任何一个细节，才能保证产品的质量。
愿君受用。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 