你所在公司的测试流程是什么 ？怎么确定流程中的每个阶段都是有效的 ？如何优化它。

目录

1.定义

2.测试流程

3.如何确定流程节点 ？

4.该如何实施 ？

5.总结

---

1.定义

提到测试流程 ，只要做过测试的人是无人不知、无人不晓，都能侃侃而谈 。因为它太基础了，几乎是每个测试人的工作中必不可少的组成部分 。但也正是这个让我们熟悉的工作 ，让我们变的习惯去执行它，很少去思考它的意义并且优化它 。

那我个人觉得这个测试流程大有文章可做 ，里面的每一个节点都值得我们去深思 ，以下是我对测试流程的理解 。

首先 ，我们需要考虑一个问题 ，何为流程 ？ 就是由具体的若干个任务按照一定的顺序执行的过程 ，其目的就是为了使某个业务从混乱状态变为有序状态 ，从而提高业务效率 。那么对于测试流程也是类似的情况，就是为了提高测试所定的目标而所做的一系列任务，而每个任务其实就是流程中的一个节点而已 。

2.测试流程

下面的这条测试流程共包含了8个节点 ，按照这个流程去执行，我们就可以完成每一次迭代的项目 。

同时我将测试流程放在整个开发模型中(迭代模型)中加以说明 ，能更好的体现出流程所经历的阶段 。其中迭代模型包含的具体阶段为 ：需求评审 -> 开发 -> 测试 -> 上线

流程节点	所处模型阶段	主导角色	主要工作
1.需求评审	需求分析阶段的尾声。	产品经理主导，其它角色参与	1.理解需求 2.进行周期评估，包括开发，测试等周期
2.编写测试计划	开发阶段的早期	测试经理主导，测试人员参与	输出测试计划并且同步给团队
3.编写测试用例以及评审	开发阶段中和后期	测试人员	编写测试用例，参与用例的评审
4.搭建测试环境	测试阶段	测试人员	搭建测试所需要的环境
5.执行测试	测试阶段	测试人员	对系统功能进行测试 ，找系统bug。
6.提交bug并跟踪管理	测试阶段	测试人员	持续提交bug并跟踪
7.编写测试报告	测试阶段	测试人员	输出测试报告并同步给团队
8.上线测试	上线阶段	运维角色 ，测试人员，开发人员	上线测试 。

你会发现这个流程中，除了第1和第8个节点是团队合作以外，其它的节点都是都是测试人员去完成的 。而如果说优化流程也是优化的是测试人员完成的这些节点 。

3.如何确定流程节点 ？

很明显，如果你仅仅是为了完成流程中的每一个节点，最后保证产品上线 ，那么就没必要往后讨论了 ，这个流程肯定能满足这个需求 。但是我们通过执行这个流程，可不仅仅是为了正常上线 ，而真正的的目的是为了能上线后尽量减少线上bug甚至不出现bug，即保证质量 。也正是基于这个目的 ，不同公司、不同项目中的流程节点才会变的不同 ，设置的每个流程节点其实就是为了更好的达成目的 ，若你添加的流程节点它能有效的提高上线后的产品质量，减少线上bug(目的) ，那么这个流程就应该加进来 ；反之，如果流程不能很好的提高产品质量，你也就可以将它去掉 。

那么，这里面就会出现一个问题 ，怎样的流程节点才算是有效的呢 ？答案就是这个节点能对达成目的(保证质量)有很好的作用效果 。 比如说经过我们长时间的实践证明 ，编写测试计划确实有助于提升产品质量 ，那么这个节点就应该保留在测试流程中 ，如果说它对产品质量没啥作用，那你就可以大胆的去掉它 。这个验证过程你最好有数据支撑 ，你可以统计往期上线的项目 ，将有这个节点(如测试计划)和无这个节点的数据进行比对 ，看看它是否起到了一定帮助 。从而分析出它的作用效果 。也就是说这个节点的效果如何 ，其实是通过长时间的实践验证出来的 ，这种实践验证我们叫它最佳实践。最后将这些最佳实践保留在流程中 ，然后连接并固化起来就变成了我们的测试流程 。

4.该如何实施 ？

如果说你的项目基本都是正常的迭代而已，那就按照固话好的测试流程执行就可以了，你所做的就是找到这些最佳实践即可 。但是有的时候，我们会接触到不同的项目 ，每个项目情况又各不相同。比如有时候你可能会遇到一个紧急的项目，仅仅只有3天的测试时间，而有时候又遇到一个很大的项目，光测试时间可能就的持续一个月 。遇到这种差距很大的项目，我们该如何更好的实时测试流程呢 ？我的建议是让流程灵活起来，具体是 ：

• 给每一个流程节点设置一个权重并打分 ，让整个流程加起来等于100分 ，并说明其应用场景 。

• 制定一条可伸缩性的流程 ，根据不同项目情况 ，动态确定流程节点 ，从而应对不同的项目情况 。

以下为流程的每个节点及权重，根据不同的项目情况，可适当增删其中的流程节点。

流程节点	权重/分数	是否必选	使用场景	备注
1.需求评审	5	是
2.业务熟悉并提取测试点	5	否	新项目/复杂项目	无时间可去掉
3.编写测试计划	10	否	迭代项目/新项目/复杂项目	尽量不去，但实在没时间可去掉
4.编写测试用例以及评审	15	否	迭代项目/新项目/复杂项目	尽量不去，但实在没时间可去掉
5.熟悉业务表	5	否	迭代项目/复杂项目	无时间可优先去掉
6.编写测试脚本	5	否	据项目情况而定	无时间可优先去掉
7.准备测试数据	5	否	据项目情况而定	无时间可优先去掉
8.执行测试	20	是
9.提交bug并跟踪管理	15	是
10.编写测试报告	5	是
11.上线测试	10	是

同时去掉一些节点的话 ，可能存在一些风险 ，所以你应该为去掉的节点做一些应对措施 。如下 ：

流程节点	是否已去掉	风险	应对措施
2.业务熟悉并提取测试点	是	出现因对业务不熟悉而导致的漏测	在第一轮测试中按需求测试进行覆盖
3.编写测试计划	是	因为没有考虑全而导致的漏测	改为只考虑测试范围和测试策略
4.编写测试用例以及评审	是	因没有对需求全而导致的漏测	在第一轮测试中进行需求测试
5.熟悉业务表	是	因测试效率慢而导致的测试延期	评估不做的风险 或者 加班
6.编写测试脚本	是	因测试效率慢而导致的测试延期	评估不做的风险 或者 加班
7.准备测试数据	是	因后期准备数据导致测试延期	评估不做的风险 或者 加班

通过以上两步 ，我们就可以应对不同不同情况 ，然后进行实时调整 ，从而能最大化的去达成所需目的(如减少bug)

5.总结

通过以上我们可以说明，将重要点进行梳理如下 ：

• 测试流程的每一个节点都是最佳实践(经过验证) ，它的作用是都是为了更好的达成目的而设定的 。

• 找出你项目中的最佳实践 ，将它连接并固化下来 。

• 同一项目正常迭代，只需要按照这个最佳实践执行即可 ，做好实践即可 。

• 若项目差异大 ，根据项目情况可动态的调整流程节点 ，同时给流程节点设置权重，确定那些可有优先调整 ，那些可以不调整 。

• 若取消的流程节点 ，取药考虑其风险因素并给出应对措施 。