一页纸测试策略

“测试策略是什么样的？”
“测试策略嘛，还不是包括#&~+-=～*-+$这些…”
“你们项目的策略有什么特别的吗？”
“我们项目嘛，测试策略的内容有点多，从哪说起呢？”

前面那个场景有没有似曾相识？你是否清楚目前你们正在使用的测试策略是什么样的？

一、常见测试策略

（一）测试策略的内容与形式

我们都知道，测试策略包括以下两方面的内容：

1. 测什么（What）？

测什么是指质量需求是什么、需要关注质量的哪些方面，比如应用的功能范围、性能、安全、易用性等非功能需求。

2. 怎么测（How）？

怎么测就是采用什么办法来帮助系统实现质量需求，而不仅仅是手动和自动化的测试方法，也包括一切为质量保障服务的流程、环境、基础设施和人员等。

为了描述清楚要测的内容以及如何来测，测试策略通常篇幅较长的文档，包含多个章节；以文字描述为主，只加上少量的配图。

图1 常见策略文档目录结构

【图片来源： https://www.softwaretestingmaterial.com/test-strategy/ 】

（二）测试策略的痛点

长篇大论的文字给人带来居多不便：

1. 编写困难

篇幅较长的测试策略文档要写好还真不是件容易的事情，尤其是对于理工科出身的不是那么擅长写作的测试人员来说，更是比较麻烦，成本较高。

2. 不易阅读

长篇大论的测试策略文档，要从中快速找出关键信息可没那么容易，可能一不小心错过的细节就是最关键的部分，因为篇幅太长，通常不太重要的信息挺多的。

3. 维护、更新痛苦

策略文档不可能一成不变，这种篇幅较长的文档要更新和维护简直是噩梦。往往刚开始还好，随着时间推移，更新和维护越来越麻烦。

4. 失去了策略的价值

由于不易阅读，也不易维护和更新，事实上团队可能有很多人并不是很清楚策略文档上的内容，这样的策略文档形存实亡，不能真正起到策略的指南作用。

5. 反敏捷

工作的软件高于详尽的文档

— 敏捷宣言

敏捷开发强调的是缩短反馈周期，快速交付高质量的软件产品。花费太多精力编写、维护一份不能起到策略作用的长篇幅文档，显然是不利于敏捷的。

测试策略的重要性不言而喻，是否可以找到一种更好的表达方式，让测试策略不那么痛呢？

Jamie McIndoe提出可以把测试策略可视化，用一页纸来搞定。我们都知道，图示化的表达方式直观、清晰，容易识别关键信息，并且易于记忆。如果能够用图示化的方法将测试策略在一页纸上搞定，一定非常棒。

下面一起来看看图示化表达的测试策略是什么样的。

二、图示化测试策略

（一）一页纸搞定

顾名思义，图示化就是用图来描述测试策略的内容，但并不是把原来文字描述的每个章节直接翻译成图。我们考虑用图来表示测试策略的各个关键组成部分，并且绘在一页纸上。

基于Jamie McIndoe的可视化测试策略思想，我建议的测试策略图包含下列信息：

• 指导性原则：团队为质量负责
• 测什么：可能包括功能、性能和安全等
• 如何测：测试左移、精益测试、测试右移，涵盖测试流程、测试类型、测试方法等

例如，蓝鲸项目的测试策略如下图所示：

图2 蓝鲸项目策略图

（二）各部分详细介绍

下面，我们来看看该测试策略各组成部分的具体含义。

1. 指导性原则

蓝鲸项目采用的是敏捷开发模式，质量不是某个单一角色的事情，团队为质量负责是项目质量保障的指导性原则，需要所有团队成员对此有一致的认识，人人都要有关注质量的意识。更多关于团队为质量负责的内容，请关注我的另一篇文章《 说好的团队为质量负责呢？ 》

2. 测试左移与质量内建

敏捷测试最关键的两点就是尽早测试和频繁测试（Test early, test often），也就是测试左移与质量内建的思想。

测试左移要求在需求分析阶段开始对需求本身的合理性进行验证，不仅要正确的构建产品，更重要的是构建正确的产品，这就需要把好源头需求这一关。因此，我们可以看到策略里的流程是从需求分析开始的。

质量内建则是在软件开发生命周期的每个阶段都有质量相关的活动，把质量融入到开发的每一个步骤，通过CI/CD等方式获取快速反馈，做好软件缺陷的预防，以减轻缺陷暴露太晚带来的大量修复成本。蓝鲸项目的开发生命周期主要体现在图示的七个环节，每个环节都有相应测试活动的开展，并且每个活动都有不同角色的参与。

图3 蓝鲸项目生命周期的测试活动

3. 测试精益

测试精益可以理解为以业务价值为目标，以尽量少的成本交付高质量的软件，也就是说测试要测在能体现价值的点上，要做到有效覆盖、减少浪费。蓝鲸项目的策略图里有两个框架帮我我们更有效的测试，分别是测试象限和测试分层。

（1）测试象限

在Lisa Crispin和Janet Gregory合著的书籍《敏捷软件测试：测试人员与敏捷团队的实践指南》中，我们看到了敏捷测试象限的介绍。由于该象限框架所起到的作用不仅局限于敏捷的环境，我在这里称之为测试象限。

测试象限矩阵一共四个部分，称为四个象限。下侧是面向技术的测试，上侧是面向业务的测试；左侧是支持团队的测试，右侧则是评价产品的测试。

a. 支持团队的测试

支持团队的测试是用来告诉团队要写什么代码，起到明确需求、辅助设计的作用。其中，第一象限是面向技术的支持团队的测试，主要是TDD，帮助构建产品的内部质量，也就是代码质量的保障，比如单元测试和api测试等；第二象限则是面向业务的支持团队的测试，从更高层次以业务专家可以理解的方式确定系统期望的行为，做到产品外部质量的保障。

这两个象限的测试能够快速提供反馈信息，并确保快速的解决问题，既指导了功能的开发，又提供了防止重构和新代码的引入而导致不期望行为发生的安全网。

b. 评价产品的测试

程序员编写的代码可以使得左侧面向业务的测试通过，但也可能没有产生客户真正想要的东西，因此还需要第三、第四象限的评价产品的测试。

第三象限是面向业务的评价产品的测试，通过模仿真实用户使用应用的方式，帮助确认是否构建了真正需要的产品；第四象限是面向技术评价产品的测试，主要采用工具和相应的技术来评价产品的性能、健壮性和安全性等非功能特性，并且在开发周期的每一步都要考虑这些测试的开展。

这两个象限的测试中产生的信息应该反馈到象限矩阵的左侧，并用于创建新的测试来驱动下一步开发，形成良性的增强环路。

c. 测试象限的使用

象限的顺序跟测试执行的顺序无关，敏捷开发往往开始于客户测试（面向业务的测试）。与测试执行时机相关的因素通常有：

• 产品发布的风险
• 客户方对产品目标的要求
• 是基于遗留系统的开发还是从零开始构建的新系统
• 可利用的测试资源等

测试象限提供一种需要哪些测试来保障质量的思考框架，可以根据项目具体情况，结合考虑以开展对应的测试。策略图所示蓝鲸项目的测试象限体现的测试类型跟Lisa书里介绍的就不太一样，这是根据项目当前跟客户的合作方式、业务需求、质量要求等来确定的当下需要执行的测试，比如其中的安全测试就分为业务部分和技术部分。

（2）测试分层

关于测试分层的思想，大家可能比较熟悉的是测试金字塔，主要是针对自动化测试，根据测试所能覆盖的范围分成不同的层。金字塔的含义是测试比例的多少，体现为底层单元测试较多，越往上层测试比例越少，呈现为金字塔结构。

越往底层的测试越接近代码，编写成本更低、执行速度更快、定位问题也更准确，但是离业务较远，不能很好的体现业务价值；越往上层的测试越接近业务，更能反应业务价值，但有着不够稳定、执行速度慢、实现成本较高的不足。因此，需要权衡利弊，根据项目具体情况，真实的目标来确定每层测试的比例。

至于具体的比例是金字塔结构，还是蜂巢结构或其他，并不是一定的，也不会是一成不变的，可能受到价值目标、痛点、质量要求、技术架构、技能水平等因素的影响。

蓝鲸项目的策略图里的是当前的测试分层结构，类似于蜂巢机构，那是因为基于微服务架构的特点，蓝鲸项目更多的自动化测试是保障服务间连通性的API测试部分，而对于单元测试和端到端测试的比例则都有减弱。

4. 测试右移

由于软件系统所处生态环境越来越复杂，技术架构的演进、业务复杂度和数据量的增加、基础设施的发展带来更多的不确定性，软件系统的质量保障在测试环境已经搞不定了，我们需要把目光右移到生产环境。这就是测试右移的思想，其实也就是生产环境下的QA(QA in Production)。

生产环境有着不同于测试环境的特点，生产环境的QA并不是测试环境的QA的直接后延，而是需要利用其特点通过技术手段收集生产环境一切可利用的数据，包括日志、用户行为、用户反馈等，利用这些数据来分析和优化业务以及开发过程的开发和测试工作，形成一个开发过程与生产环境信息分析的良性循环系统。

蓝鲸项目在这方面做了不少工作，更多相关的详细内容，请参考我的另两篇文章《 生产环境下的QA 》和《 QA与Ops通力合作打造反脆弱的软件系统 》。

5. 测什么

之所以把这个放到最后介绍，是因为前面介绍“怎么测”的各个部分都已经涵盖到要测试的内容，蓝鲸项目的测试内容主要有：功能、性能和安全。

这三个方面的测试类似，都是从需求分析到生产环境每个环节都要考虑相关测试，做到质量内建、安全内建和持续的性能测试。

图4 蓝鲸项目的非功能测试

三、测试策略的正确打开方式

一页纸搞定的测试策略，优势非常明显，比传统策略文档更加简洁、清晰，关键信息一目了然。我们再来看一下测试策略图示化以后，还有哪些需要注意的方面。

1. 目标驱动

虽然上网搜索能找到很多测试策略模板，但测试策略不应该是千篇一律的，不可以死搬硬套通用的模板。测试策略受到多种因素的影响，比如：业务价值、质量要求、当时痛点、技术架构、技术能力、工作重心、绩效要求、项目状态等等。

制定测试策略需要明确目标，综合考虑各种因素，权衡利弊，找到最适合自己项目当前状态的策略。也就是说，测试策略应该是目标驱动的。

2. 演进式

项目处于不同阶段会有不同的质量目标，同时随着架构的演进和业务的发展，对软件系统的质量保障工作也需要随之调整。因此，测试策略还应该是演进式的、随需调整的。

图示化的测试策略是高度精简的，具有更大的讨论和发挥空间，在防止僵化、保持演进方面的优势明显。

四、总结

测试策略举足轻重，内容很重要，需要以价值目标驱动，持续度量，并根据项目特定情况适时调整、演进。策略文档不要拘泥于形式，利用图示化的方法，直观、清晰的表达，是非常好的组织形式，能有效克服常规文字为主的文档所带来的痛，推荐大家使用。

延伸阅读

1.Jamie McIndoe的一页纸测试策略： https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/

3.QA in Production： https://martinfowler.com/articles/qa-in-production.html

4.生产环境下的QA： https://www.jianshu.com/p/20b454a88bdb

5.QA与Ops通力合作打造反脆弱的软件系统： https://www.jianshu.com/p/1f456d91c3ab

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见