精益测试的指导框架

精益测试的指导框架

测试四象限

敏捷测试四象限最早由BrianMarick提出，LisaCrispin和JanetGregory在书籍《敏捷软件测试：测试人员与敏捷团队的实践指南》中引用这个四象限框架，并做了详细的介绍。由于该象限框架所起到的作用不仅局限于敏捷的环境，我在这里称之为测试四象限。

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

支持团队的测试

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

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

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

评价产品的测试

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

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

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

测试象限的使用

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

产品发布的风险

客户方对产品目标的要求

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

可利用的测试资源等

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

测试分层

关于测试分层的概念，大家可能更为熟悉的是测试金字塔，测试金字塔呈现的是不同种类测试比例的多少，底层单元测试较多，越往上层测试比例越少，呈现为金字塔结构。

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

蜂巢和甜筒冰淇淋

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