共计 5295 个字符，预计需要花费 14 分钟才能阅读完成。
【摘要】测试策略文档通常是篇幅较长、文字为主的模式，编写老本较高，并且写完了很少有人去看，形存实亡。本文介绍可视化的形式，将测试策略用图来表白，并且在一页纸上搞定，这样的策略图十分清晰，要害信息高深莫测，并且提供更大的探讨空间，避免僵化，真正可能施展策略的作用。
“测试策略是什么样的？”
“测试策略嘛，还不是包含 #&~+-=～*-+$ 这些…”
“你们我的项目的策略有什么特地的吗？”
“咱们我的项目嘛，测试策略的内容有点多，从哪说起呢？”
后面那个场景有没有似曾相识？你是否分明目前你们正在应用的测试策略是什么样的？
一、常见测试策略
1.1 测试策略的内容与模式
咱们都晓得，测试策略包含以下两方面的内容：
- 测什么（What）？测什么是指品质需要是什么、须要关注品质的哪些方面，比方利用的性能范畴、性能、平安、易用性等非性能需要。
- 怎么测（How）？怎么测就是采纳什么方法来帮忙零碎实现品质需要，而不仅仅是手动和自动化的测试方法，也包含所有为品质保障服务的流程、环境、基础设施和人员等。
为了形容分明要测的内容以及如何来测，测试策略通常篇幅较长的文档，蕴含多个章节；以文字描述为主，只加上大量的配图。
图片来自网络：https://wenku.baidu.com/view/…
1.2 测试策略的痛点
简明扼要的文字给人带来居多不便：
- 编写艰难：篇幅较长的测试策略文档要写好还真不是件容易的事件，尤其是对于理工科出身的不是那么善于写作的测试人员来说，更是比拟麻烦，老本较高。
- 不易浏览：简明扼要的测试策略文档，要从中疾速找出要害信息可没那么容易，可能一不小心错过的细节就是最要害的局部，因为篇幅太长，通常不太重要的信息挺多的。
- 保护、更新苦楚：策略文档不可能变化无穷，这种篇幅较长的文档要更新和保护几乎是噩梦。往往刚开始还好，随着时间推移，更新和保护越来越麻烦。
- 失去了策略的价值：因为不易浏览，也不易保护和更新，事实上团队可能有很多人并不是很分明策略文档上的内容，这样的策略文档形存实亡，不能真正起到策略的指南作用。
- 反麻利：麻利开发强调的是缩短反馈周期，疾速交付高质量的软件产品。破费太多精力编写、保护一份不能起到策略作用的长篇幅文档，显然是不利于麻利的，也是十分痛的。
测试策略的重要性显而易见，是否能够找到一种更好的表达方式，让测试策略不那么痛呢？Jamie McIndoe 在“Testing Stuff – A One-Page Test Strategy”中首次提出能够把测试策略图视化，用一页纸来搞定。
咱们都晓得，图示化的表达方式直观、清晰，容易辨认要害信息，并且易于记忆。如果可能用图示化的办法将测试策略在一页纸上搞定，肯定十分棒。
上面一起来看看图示化表白的测试策略是什么样的。
二、图示化测试策略
2.1 一页纸搞定
顾名思义，图示化就是用图来形容测试策略的内容，但并不是把原来文字描述的每个章节间接翻译成图。咱们思考用图来示意测试策略的各个要害组成部分，并且绘在一页纸上。
当然，一页纸的测试策略只是将要害信息以图示化的形式出现进去，并不是整个测试策略的全副，在一页纸的背地是团队的充沛沟通和对策略各个方面达成的统一意识，是须要团队一起来做很多工作的。这种高度简化的出现模式，是为了给团队更多的探讨空间，一页纸也更易于批改，从而更能适应变动，真正满足需要。
基于 Jamie McIndoe 的可视化测试策略思维，我倡议的测试策略图蕴含下列信息：
- 指导性准则：团队为品质负责；
- 如何测：测试左移、精益测试、测试右移，涵盖测试流程、测试类型、测试方法等；
- 测什么：包含性能、性能和平安等。
上面将以蓝鲸我的项目为例来介绍这几个局部的内容。对于蓝鲸我的项目，是一个历经 10 年的离岸交付我的项目，采纳的是麻利开发的模式，每四到五周一次公布，遵循麻利开发的各种实际。
例如，蓝鲸我的项目的测试策略如下图所示：
2.2 各局部具体介绍
上面，咱们来看看该测试策略各组成部分的具体含意。
2.2.1 指导性准则
蓝鲸我的项目采纳的是麻利开发模式，品质不是某个繁多角色的事件，团队为品质负责是我的项目品质保障的指导性准则，须要所有团队成员对此有统一的意识，人人都要有关注品质的意识。更多对于团队为品质负责的内容，请参考我的博客文章说好的团队为品质负责呢。
2.2.2 测试左移与品质内建
麻利测试最要害的两点就是尽早测试和频繁测试（Test early, test often），也就是测试左移与品质内建的思维。
测试左移要求在需要分析阶段开始对需要自身的合理性进行验证，不仅要正确的构建产品，更重要的是构建正确的产品，这就须要把好源头需要这一关。因而，咱们能够看到策略里的流程是从需要剖析开始的。
品质内建则是在软件开发生命周期的每个阶段都有品质相干的流动，把品质融入到开发的每一个步骤，通过 CI/CD 等形式获取疾速反馈，做好软件缺陷的预防，以加重缺点裸露太晚带来的大量修复老本。
蓝鲸我的项目的开发生命周期次要体现在下图的七个环节，每个环节都有相应测试流动的发展，并且每个流动都有不同角色的参加。
2.2.3 精益测试
精益测试能够了解为以业务价值为指标，以尽量少的老本交付高质量的软件，也就是说测试要测在能体现价值的点上，要做到无效笼罩、缩小节约。蓝鲸我的项目的策略图里有两个框架帮我咱们更无效的测试，别离是测试象限和测试分层。
1）测试象限
在 Lisa Crispin 和 Janet Gregory 合著的书籍《麻利软件测试：测试人员与麻利团队的实际指南》中，咱们看到了麻利测试象限的介绍。因为该象限框架所起到的作用不仅局限于麻利的环境，我在这里称之为测试象限。
测试象限矩阵一共四个局部，称为四个象限。下侧是面向技术的测试，上侧是面向业务的测试；左侧是反对团队的测试，右侧则是评估产品的测试。
- 反对团队的测试
反对团队的测试是用来通知团队要写什么代码，起到明确需要、辅助设计的作用。其中，第一象限是面向技术的反对团队的测试，次要是 TDD，帮忙构建产品的外部品质，也就是代码品质的保障，比方单元测试和 API 测试等；第二象限则是面向业务的反对团队的测试，从更高层次以业务专家能够了解的形式确定零碎冀望的行为，做到产品内部品质的保障。
这两个象限的测试可能疾速提供反馈信息，并确保疾速的解决问题，既领导了性能的开发，又提供了避免重构和新代码的引入而导致不冀望行为产生的安全网。
- 评估产品的测试
程序员编写的代码能够使得左侧面向业务的测试通过，但也可能没有产生客户真正想要的货色，因而还须要第三、第四象限的评估产品的测试。
第三象限是面向业务的评估产品的测试，通过模拟实在用户应用利用的形式，帮忙确认是否构建了真正须要的产品；第四象限是面向技术评估产品的测试，次要采纳工具和相应的技术来评估产品的性能、健壮性和安全性等非性能个性，并且在开发周期的每一步都要思考这些测试的发展。
这两个象限的测试中产生的信息应该反馈到象限矩阵的左侧，并用于创立新的测试来驱动下一步开发，造成良性的加强环路。
- 测试象限的应用
象限的程序跟测试执行的程序无关，麻利开发往往开始于客户测试（面向业务的测试）。与测试执行机会相干的因素通常有：
- 产品公布的危险；
- 客户方对产品指标的要求；
- 是基于遗留零碎的开发还是从零开始构建的新零碎；
- 可利用的测试资源等。
测试象限提供一种须要哪些测试来保障品质的思考框架，能够依据我的项目具体情况，联合思考以发展对应的测试。策略图所示蓝鲸我的项目的测试象限体现的测试类型跟 Lisa 书里介绍的就不太一样，这是依据我的项目以后跟客户的单干形式、业务需要、品质要求等来确定的当下须要执行的测试，比方其中的平安测试就分为业务局部和技术局部。
2）测试分层
对于测试分层的思维，大家可能比拟相熟的是测试金字塔，次要是针对自动化测试，依据测试所能笼罩的范畴分成不同的层。金字塔的含意是测试比例的多少，体现为底层单元测试较多，越往下层测试比例越少，出现为金字塔构造。
越往底层的测试越靠近代码，编写老本更低、执行速度更快、定位问题也更精确，然而离业务较远，不能很好的体现业务价值；越往下层的测试越靠近业务，更能反馈业务价值，但有着不够稳固、执行速度慢、实现老本较高的有余。因而，须要权衡利弊，依据我的项目具体情况，实在的指标来确定每层测试的比例。
至于具体的比例是金字塔构造，还是蜂巢构造或其余，并不是肯定的，也不会是变化无穷的，可能受到价值指标、痛点、品质要求、技术架构、技能程度等因素的影响。
蓝鲸我的项目的策略图里的是以后的测试分层构造，相似于蜂巢机构，那是因为基于微服务架构的特点，蓝鲸我的项目更多的自动化测试是保障服务间连通性的 API 测试局部，而对于单元测试和端到端测试的比例则都有削弱。更多的对于蓝鲸我的项目测试策略的详情，请参考我的博客文章微服务测试的思考与实际。
2.2.4 测试右移
因为软件系统所处生态环境越来越简单，技术架构的演进、业务复杂度和数据量的减少、基础设施的倒退带来更多的不确定性，软件系统的品质保障在测试环境曾经搞不定了，咱们须要把眼光右移到生产环境。这就是测试右移的思维，其实也就是生产环境下的 QA(QA in Production)。
生产环境有着不同于测试环境的特点，生产环境的 QA 并不是测试环境的 QA 的间接后延，而是须要利用其特点通过技术手段收集生产环境所有可利用的数据，包含日志、用户行为、用户反馈等，利用这些数据来剖析和优化业务以及开发过程的开发和测试工作，造成一个开发过程与生产环境信息剖析的良性循环零碎。
蓝鲸我的项目在这方面做了不少工作，更多相干的具体内容，请参考我的博客文章生产环境下的 QA 和 QA 与 Ops 通力合作打造反软弱的软件系统。
2.2.5 测什么
之所以把这个放到最初介绍，是因为后面介绍“怎么测”的各个局部都曾经涵盖到要测试的内容，蓝鲸我的项目的测试内容次要有：性能、性能和平安。
这三个方面的测试相似，都是从需要剖析到生产环境每个环节都要思考相干测试，做到品质内建、平安内建和继续的性能测试。对于性能方面的品质内建，后面【测试左移和品质内建】局部有介绍，对于平安和性能方面的策略，能够参考如下图示，因为篇幅无限，本文不做赘述。
三、测试策略的正确打开方式
一页纸搞定的测试策略，劣势非常明显，比传统策略文档更加简洁、清晰，要害信息高深莫测。咱们再来看一下测试策略图示化当前，还有哪些须要留神的方面。
3.1 指标驱动
尽管上网搜寻能找到很多测试策略模板，但测试策略不应该是千篇一律的，不能够死搬硬套通用的模板。测试策略受到多种因素的影响，比方：业务价值、品质要求、过后痛点、技术架构、技术能力、工作重心、绩效要求、我的项目状态等等。
制订测试策略须要明确指标，综合思考各种因素，权衡利弊，找到最适宜本人我的项目以后状态的策略。也就是说，测试策略应该是指标驱动的。
3.2 演进式
我的项目处于不同阶段会有不同的品质指标，同时随着架构的演进和业务的倒退，对软件系统的品质保障工作也须要随之调整。因而，测试策略还应该是演进式的、随需调整的。
图示化的测试策略是高度精简的，具备更大的探讨和施展空间，在避免僵化、放弃演进方面的劣势显著。
四、总结
测试策略无足轻重，内容很重要，须要以价值指标驱动，继续度量，并依据我的项目特定状况适时调整、演进。策略文档不要拘泥于模式，利用图示化的办法，直观、清晰的表白，是十分好的组织模式，能无效克服惯例文字为主的文档所带来的痛，举荐大家应用。
延长浏览
- 一页纸测试策略图解
- Jamie McIndoe 的 Testing Stuff – A One-Page Test Strategy：
https://making.stuff.co.nz/te… - 说好的团队为品质负责呢：https://www.bylinzi.com/2019/…
- QA in Production：https://martinfowler.com/arti…
- 蓝鲸我的项目测试策略之微服务测试的思考与实际：https://www.bylinzi.com/2018/…
- 生产环境下的 QA：https://www.bylinzi.com/2016/…
- QA 与 Ops 通力合作打造反软弱的软件系统：https://www.bylinzi.com/2018/…
起源：BY 林子
作者：林冰玉
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
7 月每周四晚 8 点，【冬哥有话说】研发效力工具专场，公众号留言“效力”可获取地址
- 7 月 8 日，LEANSOFT- 周文洋《微软 DevOps 工具链的 “ 爱恨情仇 ”（Azure DevOps）》
- 7 月 15 日，阿里云智能高级产品专家 - 陈逊《复杂型研发合作模式下的效力晋升实际》
- 7 月 22 日，极狐 (GitLab) 解决⽅案架构师 - 张扬分享《基础设施即代码的⾃动化测试摸索》
- 7 月 29 日，字节跳动产品经理 - 胡贤彬分享《自动化测试，如何做到「攻防兼备」？》
- 8 月 5 日，声网 AgoraCICD System 负责人 - 王志分享《从 0 到 1 打造软件交付质量保证的闭环》