“测试策略是什么样的？”
“测试策略嘛，还不是包括#&~+-=～*-+$这些…”
“你们项目的策略有什么特别的吗？”
“我们项目嘛，测试策略的内容有点多，从哪说起呢？”
前面那个场景有没有似曾相识？你是否清楚目前你们正在使用的测试策略是什么样的？
一、常见测试策略
（一）测试策略的内容与形式
我们都知道，测试策略包括以下两方面的内容：
1. 测什么（What）？
测什么是指质量需求是什么、需要关注质量的哪些方面，比如应用的功能范围、性能、安全、易用性等非功能需求。
2. 怎么测（How）？
怎么测就是采用什么办法来帮助系统实现质量需求，而不仅仅是手动和自动化的测试方法，也包括一切为质量保障服务的流程、环境、基础设施和人员等。
为了描述清楚要测的内容以及如何来测，测试策略通常篇幅较长的文档，包含多个章节；以文字描述为主，只加上少量的配图。
常见策略文档目录结构
【图片来源：https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html】
（二）测试策略的痛点
长篇大论的文字给人带来居多不便：
1. 编写困难
篇幅较长的测试策略文档要写好还真不是件容易的事情，尤其是对于理工科出身的不是那么擅长写作的测试人员来说，更是比较麻烦，成本较高。
2. 不易阅读
长篇大论的测试策略文档，要从中快速找出关键信息可没那么容易，可能一不小心错过的细节就是最关键的部分，因为篇幅太长，通常不太重要的信息挺多的。
3. 维护、更新痛苦
策略文档不可能一成不变，这种篇幅较长的文档要更新和维护简直是噩梦。往往刚开始还好，随着时间推移，更新和维护越来越麻烦。
4. 失去了策略的价值
由于不易阅读，也不易维护和更新，事实上团队可能有很多人并不是很清楚策略文档上的内容，这样的策略文档形存实亡，不能真正起到策略的指南作用。
5. 反敏捷
工作的软件高于详尽的文档
-- 敏捷宣言
敏捷开发强调的是缩短反馈周期，快速交付高质量的软件产品。花费太多精力编写、维护一份不能起到策略作用的长篇幅文档，显然是不利于敏捷的。
测试策略的重要性不言而喻，是否可以找到一种更好的表达方式，让测试策略不那么痛呢？
Jamie McIndoe在"Testing Stuff - A One-Page Test Strategy"中首次提出可以把测试策略图视化，用一页纸来搞定。我们都知道，图示化的表达方式直观、清晰，容易识别关键信息，并且易于记忆。如果能够用图示化的方法将测试策略在一页纸上搞定，一定非常棒。
下面一起来看看图示化表达的测试策略是什么样的。
二、图示化测试策略
（一）一页纸搞定
顾名思义，图示化就是用图来描述测试策略的内容，但并不是把原来文字描述的每个章节直接翻译成图。我们考虑用图来表示测试策略的各个关键组成部分，并且绘在一页纸上。
当然，一页纸的测试策略只是将关键信息以图示化的方式呈现出来，并不是整个测试策略的全部，在一页纸的背后是团队的充分沟通和对策略各个方面达成的一致认识，是需要团队一起来做很多工作的。这种高度简化的呈现形式，是为了给团队更多的讨论空间，一页纸也更易于修改，从而更能适应变化，真正满足需求。
基于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/
2.说好的团队为质量负责呢：
https://insights.thoughtworks.cn/team-is-responsible-for-quality/
3.QA in Production：https://martinfowler.com/articles/qa-in-production.html
4.生产环境下的QA：https://insights.thoughtworks.cn/qa-in-production-practice/
5.QA与Ops通力合作打造反脆弱的软件系统：https://insights.thoughtworks.cn/anti-fragile-software-system/
文/ThoughtWorks 林冰玉
