读完需要

9

分钟

速读仅需 3 分钟

“你们的测试开发比是多少？测试全阶段参与，怎么可能忙的过来？”

“全阶段都在测，那么都需要哪些测试才能保证质量呢？”

“自动化测试覆盖率要求达到 99%，包括功能、性能，甚至还有易用性……”

前面的第一个和第二个问题经常被人问到，是大家比较关心的问题，而第三个是某项目的真实要求。分别是关于测试人员如何测试、测试活动如何开展、测试覆盖率该是多少的问题，都跟接下来要讲的精益测试有关。

   

01. 精益生产

在介绍精益测试之前，我们先了解精益生产的概念。

从维基百科可以看到对于“精益生产”的解释：精益生产主要来源于丰田生产方式(TPS)的生产哲学，因此也称为丰田主义 (Toyotism)，一直到 1990 年间才称为精益生产。精益生产的目标是控制库存量，减少生产过程中的浪费，其核心是“Just in time”，旨在需要的时候，按需要的量，生产所需的产品，也就是用最少工作，创造价值。

   

02. 精益测试

敏捷测试要求的测试左移、全程测试，其目的也是为了快速反馈、降低成本，以交付高质量的软件。如果把精益的概念引入敏捷测试，将有助于减少测试过程中的浪费，让测试价值最大化。

什么是精益测试

测试要做到精益，需要明白：不能一味的追求测试覆盖率，大而全的测试覆盖是一种浪费，有效的测试更有价值。

不管是手工测试还是自动化测试，都要先搞清楚业务价值和质量目标，根据业务风险来执行测试，对于优先级高的要重点测，而优先级低的可以减少测试覆盖。

根据“二八原则”，80%的业务优先级可能只在其中 20%的功能模块上，而其他 80%的功能模块只占有 20%的业务。如果一视同仁，追求全面覆盖，花费大量精力在那 80%的低优先级模块上，必然造成大量的浪费。相反地，不追求测试覆盖率，追求测试的有效性，将会事半功倍，带来更高的 ROI。因此，很多时候，测试恰到好处很关键，带着 bug 上线也许是个好的策略。

注意，这里的质量目标是关键，对于一些事关生命安危的软件系统，质量要求会特别高，全面的测试覆盖都是有效的，也是恰到好处的一种。

这就是是精益测试的思想。

因此，精益测试可以定义为：以业务价值为目标，以尽量少的成本交付高质量的软件，测试测在能体现价值的点上，做到有效覆盖，减少浪费。

精益测试的精髓

基于精益测试的定义，可以将精益测试的精髓总结为TAT：适时（Time）、适量（Amount）、精准（Target）。

适时（T）

敏捷测试要求测试全程参与，让测试活动发生在敏捷软件开发生命周期的每个环节，而让每种类型的测试发生在它最该发生的时刻，这就是“适时”的概念。比如：开发前对需求的确认，开发代码提交前自动化测试的实现和验证，部署后对系统做的冒烟测试等等。

适量（A）

对于测试覆盖率，有人会认为越高越好，比如前面提到的有团队要求 99%的自动化测试覆盖，就算这些测试覆盖都是有效的，但是花费太多精力去测试一些不是那么重要或者不是那么容易出问题的模块，也可能得不偿失，造成浪费。我们建议测试覆盖，不管是手动还是自动化的，都是适量就好，根据风险来确定需要加强测试的业务优先级和响应的测试覆盖量，一定不能一味的追求高覆盖。需要权衡利弊，把时间花在真正有价值的事情上，这也是精益的体现。

比如，做用户故事验收的时候，需要测到多细一直是个有争议的问题。我觉得主要路径的正常用例，加上一些需要特别关注的点就可以了，特别关注的点包括易出错的异常路径、IE 这样的特殊浏览器、高风险的安全问题等。不能也不需要在故事验收的时候覆盖所有的边角情况，毕竟需求、开发和测试三方凑一起不容易，时间要尽量短些才好。当然，可能有的团队还需要在故事验收的时候验收日志、性能等，只要做到尽量高效，按照团队需求来就好，并没有千篇一律的答案。

精准（T）

精准测试通常是指根据代码改动所影响到的范围去针对性的进行自动化测试。而这里说的精准测试范围更广，可以理解为基于风险的测试，风险可能来自于业务和架构层面，也可能来自于代码改动，还可能跟系统特点或其他项目因素相关。执行测试之前更重要的是分析和设计，不能盲目的去测。

   

03. 精益测试的指导框架

精益测试的指导框架常见的有两个：测试四象限和测试分层，下面分别介绍。

测试四象限

敏捷测试四象限最早由 Brian Marick ( http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2 )提出，Lisa Crispin 和 Janet Gregory 在书籍《敏捷软件测试：测试人员与敏捷团队的实践指南》 ( https://book.douban.com/subject/5338399/ )中引用这个四象限框架，并做了详细的介绍。由于该象限框架所起到的作用不仅局限于敏捷的环境，我在这里称之为测试四象限。

测试四象限矩阵的左右两侧指的是测试的作用，分别为支持团队和评价产品，而上下两部分指的是测试面向的对象，分别为面向业务和面向技术。

支持团队的测试

左侧支持团队的测试是用来告诉团队要写什么代码，起到明确需求、辅助设计的作用。

其中，第一象限是面向技术的支持团队的测试，帮助构建产品的内部质量，也就是代码质量的保障，比如单元测试和 API 测试等；第二象限则是面向业务的支持团队的测试，从更高层次以业务专家可以理解的方式确定系统期望的行为，帮助团队澄清业务以更好的理解真正的业务价值。

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

评价产品的测试

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

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

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

测试象限的使用

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

• 产品发布的风险

• 客户方对产品目标的要求

• 是基于遗留系统的开发还是从零开始构建的新系统

• 可利用的测试资源等

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

测试分层

关于测试分层的思想，主要是针对自动化测试，根据测试所能覆盖的范围分成不同的层。下面借用 Martin Fowler 网站 ( https://martinfowler.com/articles/microservice-testing/#conclusion-summary )上微服务架构的几种测试分层结构图来解释测试分层的概念：

从图中可以看到几种不同类型的测试所能覆盖的范围大小是不一样的。

关于测试分层的概念，大家可能更为熟悉的是测试金字塔 ( https://martinfowler.com/bliki/TestPyramid.html )，测试金字塔呈现的是不同种类测试比例的多少，底层单元测试较多，越往上层测试比例越少，呈现为金字塔结构。

其实，随着技术架构、系统特点、质量要求、团队技能水平等因素的不同，每种测试的比例也不尽相同，不一定都是金字塔结构，如下图所示的蜂巢结构或者甜筒冰淇淋结构都有可能。

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

   

04. 小结

精益测试的思想主要是帮助团队制定合适的测试策略，并不是一种具体的测试方法。精益测试的精髓是将测试做到适时、适量和精准，就是让测试做到恰到好处以减少浪费。

测试策略受众多因素的影响，需要做到目标驱动，并且根据具体情况随着时间推移不断的演进。测试四象限和测试分层都只是指导框架，不是必须遵守的规范，可以作为测试策略制定的参考模型，具体项目的策略还需根据项目特定情况进行调整。