◆ 待部署到正式服务器上之后，要走一次Sanity Testing保证大概的流程是正确的，这块可以用自动化来保证。

　　　　　　　　　　◆ 等到所有迭代均开发完成，可以还需要对所有迭代的功能进行一次项目级的整体回归。

　　　　　　　　　　◆ 性能/安全性测试是不是在所有迭代的功能完成后进行？

　　　　　　　　□ 需要有适当的CASE Review来提高测试覆盖率。

　　　　　　　　□ Bug管理的流程，以方便及时的跟踪和管理。

　　　　　　　　□ 是否达到了可以Release的标准，如Critical Bug <5%等等

　　　　　　■ 按照目前的这种测试策略还存在哪些风险等

　　　　　　■ 测试计划，具体的时间和人员安排，尤其是跟开发协商好提交Builds的时间，保证自己测试时间的充裕。

　　● 迭代开始后，测试和开发2条分别开展工作，主要说测试的工作

　　　　○ 设计TEST CASE时应该按照相关的规范，这个是由测试组长来定义的，是考核CASE质量的依据也是提高CASE覆盖率的方法之一。

　　　　○ 执行TEST CASE时，也应该按照相关规范来确定哪些CASE应该执行哪些不应该执行，哪些优先执行，哪些是可选执行的，以下是一个优先级安排，可以根据时间的多少来取舍

　　　　　　■ New Feature

　　　　　　■ Fixed Bug

　　　　　　■ The Modules which have most bugs

　　　　　　■ The Main Functions

　　　　○ 提交BUG报告时，也应该按照相关模板来提交，以方便进行BUG审核及统计。

　　　　○ 提交测试报告，及时向PL及客户汇报项目的情况，根据在测试策略中确定的标准来判断这个项目是否可以Release.

　　● 在一个迭代完成后或一个Milestone后，要如下分析：

　　　　　　■ CASE的覆盖率（数量，哪些Modules自己的覆盖最少，以后要加强）。

　　　　　　■ CASE的执行情况（通过率，发生BUG最多的模块，为接下来的测试策略提供依据，如这些模块会着重测试等）。

　　　　　　■ 有效BUG的数量，分布及优先级，通过分析这些BUG得出开发方面存在什么问题，比如对于重复发生的BUG需要开发这边增加UT等。

　　　　　　■ 客户报告的BUG的数量、分布及比率，并分析漏掉这些BUG原因是什么，为接下来的测试策略提供依据，如这些内容会加强测试及覆盖等。

　　　　　　　　□ 需求理解错误

　　　　　　　　□ 不细心，CASE有覆盖但未纳入TEST SUITE

　　　　　　　　□ CASE的覆盖率不全

　　　　　　　　□ 测试方法不正确

　　　　　　　　□ 测试数据不充分

　　　　　　　　□ 性能/安全方面遗漏

　　　　　　　　□ 易用性方面

　　● 根据上面的一些细节可以得出如下流程图：

版权声明：本文出自 liyun100 的51Testing软件测试博客：http://www.51testing.com/?49689

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。