如何组织策划一场测试？

黑盒软件测试工程师通常被划分为初级测试工程师，测试工程师，测试组长，测试经理。

初级测试工程师一般需要具备设计简单CASE，执行CASE，报BUG能力，这些能力在实践6个月-1年后应该就能完全掌握。

比较难的是从初级测试工程师到测试工程师的跨越，测试工程师除了能高效的执行CASE和报BUG外，还需要能设计覆盖在较全的TEST CASE和提供比较全面的测试报告，更重要的是需要具备组织策划一场测试的能力。

更难的是从测试工程师到测试组长的过渡，测试组长除了具备上述的所有能力外，还需要有组织测试流程和抽象测试规范的能力，需要从更高的角度看问题，而不是仅仅关注某一个项目的好坏。

当然测试经理的能力要求的就更高了，它要求的就不仅仅是测试流程了，更重要的是规范整个公司的流程。

在一家小型的软件公司待了4年，从最初级的测试工程师到现在的测试组长，我经历了所有这些成长期的痛苦。

今天主要介绍一下如何做好一个测试工程师，并组织和策划一场测试。

1.先要了解一个公司的测试流程和开发流程,比如我们单位采用的敏捷迭代开发的流程，整个项目工程划分成若干小迭代来完成，每个迭代都走一个小的瀑布模型。

2.想一想测试流程如何与开发流程搭配进行。

• 每个迭代开始前
• 要保证有稳定的User Stories,且这些User Stories是通过专家和项目所有人审核通过的，这样才能保证测试和开发都是走在正确的道路上。
• 要有测试计划和测试策略。
• 定义测试范围：比如普通WEB APP测试可能覆盖功能测试，性能测试，安全性测试，安装卸载测试，Broken Link，兼容性测试等等，根据项目不同而不同。
• 定义测试策略：
  
• 是否需要自动化，分别使用哪些工具。
• 使用什么样的方法设计测试用例。
• 测试类型在不同阶段的应用。
• 在每个迭代可能有若干Builds分别Cover不同的功能点，这时候需要针对每个Build进行功能的覆盖。
• 在所有的功能均完成后，需要对这个迭代所有的Builds进行一次整体的回归。
• 如果再发生问题，需要再进行若干次Smoking Test直至可以发布为止。
• 待部署到正式服务器上之后，要走一次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的覆盖率不全
• 测试方法不正确
• 测试数据不充分
• 性能/安全方面遗漏
• 易用性方面
• 根据上面的一些细节可以得出如下流程图：