标签：
在华为业务线上有近40天的时间了，参与了两个版本，华为的项目大多数走的都是敏捷迭代开发模式了，至于什么是敏捷，网上有很多的解释与资料，这里就不阐述了，就说说这期间华为的一个敏捷模式。
下面就开始写测试是从什么时候介入以及有哪些工作的。
1、story澄清会议（即需求澄清），参与人员：开发人员、资料开发人员、测试人员、TSE、需求接口人等。
目的：1）理解需求背景和价值
2）保证SE、开发、测试人员对需求场景、处理流程、依赖与限制、交付件理解一致
3）明确接口
4）明确测试场景、关键测试点
内容：1）SE介绍需求背景和价值
2）开发人员按场景和业务流程讲解自己负责的模块输入、处理和输出
3）其他人员针对需求提出问题，保证对需求的理解一致
4）测试明确测试范围和关键测试点
关键点：1）需求澄清要正式面对面交流，结论要发纪要，会后相关人员确认结论
2）SE在澄清过程中，就一些关键点（容易遗漏、犯错的地方）提问，确认开发与SE的理解一致
3）对于复杂的功能模块，开发人员可以准备demo演示，这样也有利于测试人员测试用例的输出
2、测试人员根据需求澄清会了解的需求，设计编写测试方案，完成测试用例的输出，测试用例完成后给开发人员、TSE、BA对用例进行评审，评审后根据评审意见对用例进行修改，直到大家都认可，最后导入用例管理工具中。
3、迭代story转测试前，测试人员需对程序进行冒烟测试，冒烟测试通过后才能转测试。
转测试附带的文档：代码检视确认报告、测试组提供用例的执行结果报告、开发自测用例样例参考等。
4、测试执行，测试人员执行测试用例>>提交Bug>>回归问题>>关闭问题
5、迭代结束，回归会议，开发、测试、PM、SE 一起对此次迭代版本的进行质量分析
6、问题单分析，分析每个问题单产生的原因，是测试用例遗漏、老版本遗留的问题还是修改引入的问题？如果是用例设计遗漏还需要补充用例的，如果是开发的修改引入比较多，那开发的麻烦就大了，是需要通报批评的。
7、测试报告，从发现问题多少、严重性以及聚焦的功能点等考虑对版本给出质量评价，并合理的给出建议，比如加强开自验、加强用例输出的标准等。
标签：
原文地址：http://www.cnblogs.com/wakey/p/4507083.html
