通过上一节的叙述，大家可能会认为，我们只需要像做论述题一样，把测试策略需要关注的六大问题逐一答一遍，测试策略就可以制定好了。但是如果你真的按照这个思路去操作，马上就会发现很多问题：
该在什么时候开始制定测试策略？如果在项目开头进行，你会发现很多和测试策略相关的内容根本就还不明了，无从下手；如果在项目后期进行，内容是明了，但是做测试策略的意义又在哪里呢？
测试策略中的每个问题看起来都不难，但要想答好却不简单，有没有方法或模型可以帮助我们来进行系统的思考和分析？
如何让测试策略真正起到指导测试的作用？
可见，我们还是需要一套方法来指导我们制定测试策略的整个过程，“四步测试策略制定法”应运而生，如图6-3所示。
1. 明确“产品质量目标”
明确“产品质量目标”是我们在制定测试策略过程中十分关键的一个步骤。对我们而言，不仅需要关注操作层面的具体方法，更要理解其中蕴含的测试策略思想。
1）我们的测试目标就是让产品在发布的时候能够满足事先约定的质量目标
对测试来说，我们的测试目标就是让产品在发布的时候，能够满足事先约定的质量目标。我们制定测试策略，也就是为了让产品经过各种测试后，最后能够达到质量目标，可以发布。
在操作层面上，“产品质量评估模型”可以用来帮助我们确定产品的质量目标。关于这个模型的具体内容，将在6.3节中为大家详细描述。
2）围绕产品质量目标进行刚刚好的测试
我们先来做一个小测试。下述情况是否和你有相符的地方呢？
· 这是一个新开发的特性，大家都不熟悉，要作为重点好好测试一下。
· 这个特性，感觉没有什么用吧，随便测试一下就好了。
· 这个特性，使用的技术还比较新，要作为重点好好测试一下。
· 这个特性还是很有意思的，好好测试一下。
我想在这个特性中试试××测试方法。
如果答案是肯定的，说明你充满好奇心，是个技术控。但如果你在制定测试策略的过程中，过多地被这些因素左右，你的测试将很有可能偏离本来的测试目标，变成了“凭感觉”的测试。
“不凭感觉”，“理性”的测试是这样的：
· 产品质量要求高的是测试重点，反之为非重点。
· 产品质量要求高的测试投入大，反之小。
· 产品质量要求高的要测得深，反之浅。
总而言之，要“围绕产品质量”进行。我们并不需要试图将每个地方都测试得全面深入，“刚刚好”才是我们真正需要追求的测试状态。
这部分内容，我们还将在第7章中为大家详细讨论。
3）将目标—行为—评估形成闭环
产品质量目标也使得产品质量评估变得可行。对此，我们的思路是这样的，如图6-4所示。
首先，我们将产品质量评估模型作用于具体的产品，得到产品质量目标。
其次，我们根据产品质量目标来制定测试策略，确定接下来的测试活动。
再次，执行各种测试活动。
最后，对测试效果进行评估，评估产品的质量目标是否达到。
此时我们的目标（产品质量目标）、行为（测试活动）和评估（质量评估）会形成一个闭环。这时测试策略就好像一艘船上的舵，一旦发现没有达到产品质量目标，我们就调整测试策略，让整个测试始终保持在达到产品质量目标的航线上。
这部分内容，我们还将在第8章中为大家详细讨论。
2. 进行“风险分析”
对产品而言，质量目标可能最后都是能够满足用户的商用需求。虽然产品质量评估模型可以帮助分解质量目标，让我们能够基于质量目标来制定测试策略，保证产品发布时的质量可控、可评估，但是我们在执行测试策略的时候，却总能感到些许困惑和无奈：
· 想要顺利完成测试策略并不是一件容易的事情，总有各种问题会阻碍测试活动的进程。
· 我们要做的测试活动总是很多，整个测试策略感觉很笨重。
这说明我们在制定测试策略的时候，一定漏掉了一些重要的东西。没错，我们漏掉了“风险分析”。
1）提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整测试策略
实际项目中真的有很多问题，都会让我们的测试变得举步维艰。
举例：实际项目中测试活动无法顺利开展的一些例子
例1：在需求阶段，需求工程师未能提供全面的产品需求文档，导致测试设计时场景缺失，无法达到测试设计的预期效果。
例2：在测试设计时，开发未能提供相关的设计文档，或是文档未能及时更新，导致测试设计遗漏或不准确，无法达到测试设计的预期效果。
例3：在测试执行时，发现一些测试用例因为缺陷或者代码提交的原因阻塞了，不能按照计划进行测试执行。
例4：在测试执行时，发现缺陷迟迟不能修改，缺陷分析的结果不能达到预期。
“骨感”的现实告诉我们，需要提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整我们的测试策略，增加一些测试活动或者质量保证活动。
例如，对例1，我们可以考虑开展需求澄清会、加强对需求的评审、明确需求的验收条件等活动来应对风险。对例2，我们可以考虑加强对文档的评审和跟踪、开发和测试进行设计澄清、让开发参与测试用例评审等活动来应对风险。
接下来，我们将在6.7节中为大家详细介绍风险分析技术，在第7章中为大家详细介绍如何制订风险应对措施。
2）基于风险来加强和降低测试投入
一般来说，我们的产品中会存在全新开发的功能和老功能。对一个新开发的版本来说，老功能在老版本中已经被测试过，质量的起点相比全新开发的功能要高，失效的风险更低。即使全新开发的功能和老功能的质量目标是一样的，我们也没有必要等同投入资源——理想的状态是测试能够基于风险来进行测试：
· 对高风险的部分加强测试投入。
· 对低风险的部分降低测试投入。
因此我们完全可以减少那些质量情况较好的老功能测试，而将测试重点放到老功能中风险大的地方。后续我们还将在6.7.2节中为大家介绍老功能分析技术。
3. 适配“产品研发流程”
通过前面的讨论，我们了解到制定测试策略需要围绕质量目标，充分考虑风险，根据风险来对测试活动进行调整，但是有两个问题我们一直没有提及，就是：
· 何时开展测试策略的制定活动？
· 制定测试策略是一次到位，还是要分几次完成？
这就需要我们将测试策略的制定和研发流程结合起来。
1）测试策略的结构
但是制定测试策略投入得越早，项目的各种不确定的因素也就越多。软件测试架构师很难在项目的需求分析阶段，就制定出一份非常详尽的测试策略。如果测试策略的内容只是一些大方向、大原则，那么到执行层面很容易就变形，也就违背了我们制定测试策略的初衷。
解决这个问题的方法是，按照产品研发流程，根据在哪个阶段项目能够确定到哪种程度的实际情况，来为测试策略设计一个符合这种进程的结构。
图6-5是一个传统研发流程示意图。针对这个研发流程，我们设计了总体测试策略—阶段测试策略—测试执行策略这样的测试策略结构。
有了这样的结构，我们能够将当前的测试策略总是控制在“当下”，即项目的情况总是在比较确定的范围内，避免我们过于纠结“未来”。
这样操作还有一个好处，就是我们能够真正将测试策略贯穿于测试，甚至研发项目的始终，做到既能包含大方向、大原则，又能细到对版本和功能测试的指导与控制，实现测试策略的价值。
有些公司的测试组织可能会事先就帮我们设计好了测试策略的结构，我们只需在每个节点输出符合要求的测试策略即可。在这种情况下，这个步骤自然可以省略。当然，我们也可以结合项目的实际情况，来对组织建议的测试策略结构进行裁剪。
我们还将在第7章继续和大家一起来深入讨论和测试策略的结构相关的问题。
2）根据研发流程来安排测试活动
测试策略中具体的内容，也需要和研发流程保持一致，确保测试和开发的节奏能够彼此吻合。
从大层面来说，测试在各个阶段的活动和开发的活动是能够配合起来的。例如，在开发人员进行产品设计的时候，测试人员的主要活动应该是测试分析，而不应该是测试执行。开发人员在进行功能集成的时候，测试人员的主要活动应该是测试执行，而不应该是测试设计，如图6-6所示：
要达到这个大层面的吻合，是比较容易的。相对比较困难的是，是在版本测试阶段，开发活动和测试活动彼此配合的问题。简单地说，就是开发人员在做计划的时候是否考虑了测试活动：
· 是否只是提交了一个“中间层”而非最后用户可见的功能？提交的功能是否可测？
· 测试能否有足够的时间进行测试准备？
· 测试能否在下个版本提交之前完成测试？
这就需要软件测试架构师能够做好版本测试策略，能够和开发人员进行有效沟通，使得双方能够理解彼此的节奏，达到更好的配合。
除此之外，我们即将要介绍的测试分层，也能帮助我们更好地制定版本测试策略。
本文选自《测试架构师修炼之道:从测试工程师到测试架构师》第六章，本站经机械工业出版社和作者的授权。
版权声明：51Testing软件测试网获机械工业出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
