TMMi 2.1 测试方针和策略——测试活动的起点（2）测试策略

前言：今天开始着手写TMMi16个过程域的内容。本人并不想将TMMi标准的内容照搬，网上这样的文章和内容太多了，不缺这几篇。这一系列更多的是写自己的理解和实践中的经验与实例，也希望可以通过这些文章的内容，与更多的同行讨论交流软件测试。有关TMMi相关的文档可参考TMMi官方文档：TMMi Documents - TMMi

本篇主要讲"测试策略"。

---

上一篇写了第一个特殊实践“测试方针”，今天来写第二个特殊实践“测试策略”。首先来看什么是测试策略。

2. 测试策略

2.1. 什么是测试策略

在朱少民老师的《软件测试》一书中，将软件测试策略定义为“在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合，这就是测试策略”。简单来说，测试策略就是“测什么”和“怎么测”，重点在于“怎么测”，是在开展测试用例设计和测试执行前，先要想清楚测试的方向以及测试的手段，比如一个新产品上线，需要想清楚是否全部的功能模块都需要测试，哪部分功能模块要多测试一些，是否需要执行多轮回归测试，是否要开展自动化测试，是否需要测试性能和执行安全性测试等，需要用到哪些测试用例设计方法，需要哪些测试工具支持，需要在什么环境下执行，测试数据如何建立，如何维护，测试人力资源如何规划等等。

为什么需要制定测试策略呢？因为测试是无穷尽的，为了最大程度地减少遗漏的错误，同时也为了最大限度地发现存在的错误，在测试实施之前要确定有效的测试策略，以最少的软、硬件资源及人力资源投入而获得最佳的测试效果，这就是建立测试策略的目的所在。

2.2. 建立测试策略的特殊实践

TMMi提倡“建立和部署组织范围或项目群范围的测试策略，能够识别和定义要执行的测试级别。”，在本章节中，阐述了三个特殊实践，分别为“SP2.1 执行通用产品风险评估”，“SP2.2 定义测试策略”，“SP2.3 将测试策略分发给干系人”。

 2.2.1 执行通用产品风险评估

TMMi的测试管理思想是基于风险评估的，业内对于”基于风险的测试”书籍也非常少，但是风险管理是成熟的方法论，我们可以从风险管理的角度来理解如何开展产品风险评估。

国标“GB/T 25353-2009 风险管理 原则和实施指南”中对于风险管理过程是这样描述的——风险管理过程是组织管理的有机组成部分，嵌入在组织文化和实践中，贯穿于组织的经营过程。风险管理主要由明确环境信息、风险评估、风险应对、监督和检查几个活动组成，其中“风险评估”包括风险识别、风险分析和风险评价三个步骤，如下图所示。

明确环境信息
明确环境信息主要是确定风险管理的目标以及风险管理的范围，确定风险管理的原则等。在测试风险管理中，也需要明确对于实施测试风险评估的对象，开展测试风险评估的依据，方法，步骤，输入材料和输出交付物等。

风险识别

团队开展测试风险评估，可以由测试经理或者其他项目团队人员牵头，组织团队成员进行头脑风暴，从项目管理、测试方法、人员团队、工具技术等方面开展测试风险的识别，也可以将这些方面的内容写入“测试风险检查表”，并逐步完善，以供后续开展测试风险评估工作。典型的测试风险检查表内容见下：

 风险分析和风险评价

对已经识别的测试风险，可以从“可能性”和“影响程度”两个方面进行判断，也可以增加其他维度，如系统重要程度，综合评定测试风险的优先级别，决定测试风险后续的处置。如果是优先级较高的测试风险，有可能需要进行上报，并优先处置。

风险应对

风险应对主要是对于确定优先级的测试风险采取行动，确定行动的执行人和执行周期，后续也需要出具详细的行动计划，并付诸行动。

监督和检查

监督和检查是对测试风险进行监督和跟踪，并在实施风险应对措施后，对残余的测试风险进行再次评估，确定残余风险已经消失、可以接受或者需要继续处置。

我们理解的测试风险管理的通用流程后，就理解了“通用产品风险评估”如何去做。在制定测试策略之前“执行通用产品风险评估”，主要是确定通用产品风险的完整性、类别和优先级别，对于风险高的部分，需要多投入资源以保证产品质量。例如某个应用第一次上线前开展测试，某个业务流程问题发生后影响程度高，那么相关的测试用例有可能需要多做几次回归测试，在不同的阶段需要进行测试，如在SIT，UAT这些测试阶段都要测，也需要运用更多的测试设计方法和测试技术。

对产品进行风险评估，在三级的过程域“3.3 测试生命周期与集成”中会继续使用到。

2.2.2 定义测试策略

TMMi建议，定义测试策略是“对每个等级，定义目标、职责、主要任务、入口/出口准则等等”。这短短的一句话，包含了不少内容。逐步解释一下：

每个等级都可以定义测试策略

在定义测试策略时，根据测试目标，设计测试活动，自上至下逐层考虑测试策略。见以下示例：

测试活动的分层：某公司的测试执行过程需要先计划每个月的月次功能测试，然后再计划月次功能测试中包含的测试任务。首先，在测试规划阶段，由“月次测试架构师”定义月次功能测试的测试策略，然后，在接下来的测试分析阶段中，由测试经理对于自己负责的测试任务，定义测试任务的测试策略。

测试策略内容：此公司在定义月次功能测试的测试策略中，需要明确“测试环境”、“测试数据”、“测试分析和设计策略”等。在测试任务的测试策略中也需要明确功能测试的测试方法、非功能测试和安全性测试的测试任务。

以上示例的测试策略如下图所示：

 由测试策略形成测试方案

定义测试策略时还需要考虑投入测试活动的人力资源，入口准则（即满足什么条件可以启动测试）和出口准则（即满足什么目标测试结束）等等，以上这些内容可以形成“测试方案”。也许有人会问，这不就是测试计划吗？TMMi中并没有提到测试方案，我认为，测试方案是在实践中形成的文档材料，指明了测试怎样去做的大体方向，将测试目标、测试范围和测试策略包含的内容逐一阐述，而测试计划包含了具体的任务（WBS）、执行人员和时间节点，是根据测试策略（或者测试方案）形成的更细化的行动计划。测试计划在TMMi下一个过程域“2.2 测试计划”会详细讲解。

一个典型的测试方案可以包含以下内容：

• 测试目标
• 通用产品测试风险
• 测试范围
• 测试级别（单元测试、接口测试、系统测试、用户验收测试）
• 测试用例设计技术策略
• 测试环境策略
• 测试数据策略
• 测试过程管理策略（测试工具策略、测试问题管理策略、测试总结要求等）
• 测试人力资源策略
• 准入准出要求

2.2.3 将测试策略分发给干系人

测试策略非常重要，需要在开始执行测试活动之前将如何做，做什么考虑清楚。TMMi提出的这个特殊实践要求不仅仅将测试策略考虑清楚，还需要形成可以沟通的材料，并与相关干系人进行确认。在实际工作中，可以将测试策略或者测试方案通过评审的方式，邀请干系人反馈意见。

另附SG2 建立测试策略的特殊实践，典型工作产品和子实践。

---

想了解更多细节，请关注我的博客，后续会陆续发表更多关于测试的文章。喜欢我的博客就快快关注吧！

转载请注明出处和作者，拒绝一切内容剽窃！