测试流程积累

1. 测试流程总结：

（ 1 ）               接任务

接受任务的时候，首先弄清楚任务小组的成员，谁是需求，谁是设计，谁是开发，谁是pm ，这个主要是方面在后面出现疑问的时候找谁解答，或者出现风险的时候该找谁。

（ 2 ）               学习需求和设计文档

弄清业务需求，即此产生此需求的原因，然后学习需求和设计文档。

（ 3 ）               和需求，设计人员讨论需求及设计疑问点

在学习需求及设计文档的时候，有疑问点要当时问清楚并记下来。如果不问清楚，到时候会有很多问题。

（ 4 ）               设计测试用例

设计测试用例属于测试人员必备能力，这个不多说。

（ 5 ）               和需求，开发过用例

和需求，开发过用例，目的不是评判用例，而是指出用例是否覆盖到用户所有的常用场景，及开发人员和需求人员从另一个角度去指出要覆盖到的点。

（ 6 ）               优化测试用例

在和需求人员及开发人员过用例后，优化测试用例。

（ 7 ）               询问环境准备

测试用例准备完毕后，要准备测试环境，最怕的就是要从tfs 拉取代码，耗时太长，而且拉取代码过程中，机器反应很慢，所以环境一定要提前确认清楚，自己部署环境，在哪里部署，需要什么文件等等。

（ 8 ）               部署测试环境

部署测试环境的过程中可能会出很多问题，一般对于公司产品出现的问题，可以在公司的知识库中查询。

（ 9 ）               执行测试，记下bug

登记bug 的过程中，要注意写明 bug 的操作步骤，预期结果，实际结果，及 bug等级

（ 10 ）           和开发过 bug

过bug 的过程中，要注意和开发一起定 bug优先级别，定修复时间。

（ 11 ）           对和开发有疑问的 bug 和 pm （需求）确认

跟开发过bug 的时候，一般都会有和开发存在异议的 bug，这种时候，我们要做的并不是和开发去争吵是不是有效 bug ，因为是不是有效 bug ，开发和测试说了都不算，客户说了算，所以这种时候应该让开发，测试，需求，pm 一起过有争议的 bug ，决定怎么处理。

（ 12 ）           B ug 系统中登记 bug

Bug 系统中登记的 bug 一定要是在测试环境中可以重现的，无法重现的 bug 就是无效的 bug ，无效的 bug 会耗费测试的时间。好的测试人员是可以帮助开发定位bug 产生原因的，当然，定位 bug是需要锻炼的和经验的。

（ 13 ）           发送测试情况报告

发送测试情况报告的过程中，要写明bug 的数量，类型，是否有影响测试流程的 bug，这样做的目的是让团队知道产品的质量问题，有利于更好的改善产品。

（ 14 ）           跟进 bug 修复情况

这个是防止开发因为忙忘记了修复bug ，或者是拖延 bug 的修复，所以在修复日期前就应该了解开发 bug修复进度问题。

（ 15 ）           验证 bug

在提测的bug 中，一定要求开发写上产生原因，影响点分析及解决方案，对于延期处理的 bug 要求开发写出延期处理原因，为什么一定要开发写上解决方案和产生原因呢，产生原因和解决方案可以帮助测试了解bug 的来源，影响点可以帮助测试确定验证 bug的范围。

（ 16 ）           验证 bug 后，发送测试情况报告

在测试情况报告中最好写明新激活的bug 及原 bug 的验证情况。

（ 17 ）           直至所有的要本次修复的bug 都验证通过，然后版本就可以发布了

（ 18 ）           发布之前要准备的工作

要和产品的对接人沟通好，发布时需要提交什么样的文档，或是需要以什么形式提交版本，或者是要求提交一个测试报告等等，若是没有提前沟通好，后面的工作只会延时，浪费更多的时间。