测试流程

 1、story澄清会议（即需求澄清），参与人员：开发人员、资料开发人员、测试人员、TSE、需求接口人等。目的顾名思义就是让所有参与项目的人员更深入的了解需求，会议上任何参与者都可以发表疑问，对不理解的地方要及时问清楚，实践证明这个会议能尽早的发现开发人员遗漏掉的功能点以及功能实现的方式对其他模块的影响等。这个阶段开发输出的文档有：story验收标准。一般情况下对于功能复杂的模块，为了让大家跟直观的了解功能点，一般开发人员会准备demo演示，这样也更有利于测试人员测试用例的输出。

 

   2、测试人员根据需求澄清时了解的需求点编写测试方案，然后输出用例，完成后发给开发人员、TSE对用例进行评审，编写人员根据检视意见修改用例，直到大家都认可了，再导入用例管理工具TMSS。

 

   3、迭代story转测试之前，测试人员需要向开发人员分一部分基本功能的用例验证，用例通过后才可以转测试。转测试附带的文档包括：代码检视确认报告、测试部提供用例的执行结果报告、开发自测用例样例参考等。

 

   4、测试人员执行测试，执行用例---提交bug---回归问题---story评价---关闭story

 

   5、迭代结束，回归会议，开发测试人员一起进行此次迭代版本的优缺点分析等。

 

   6、问题单逆向分析，分析每个问题单产生的原因，是用例设计遗漏、老版本遗留的问题还是修改引入的问题？如果是用例设计遗漏还需要补充用例的，如果是开发的修改引入比较多，那开发的麻烦就大了，是需要通报批评的。

 

   7、测试质量报告，从发现问题多少、严重性以及聚焦的功能点等考虑给出A/B/C等级评价，并合理的给出建议，比如加强开自验、加强用例输出的标准等。

 

   最后补充下这里为什么没有测试计划这一项，因为我们的计划大部分都是根据开发人员的开发计划来制定测试计划，而且这个计划都在迭代计划里面包含的。

 

这个是我从别的地方抄来的，但是就是华为的那套流程。我们以前也是这样做的。