敏捷测试四象限的起源与介绍

来源：http://www.51testing.com/

　　一、敏捷测试象限起源

　　敏捷测试象限的起源是出自 Brian Marick 最开始提出的敏捷测试矩阵。后来在他的许可下，敏捷测试专家 Lisa Crispin 和 Janet Gregory 对敏捷测试矩阵进行补充和扩展，并在她们的著作《敏捷软件测试：测试人员与敏捷团队的实践指南》提出了敏捷测试象限的概念，如图1所示。

　　敏捷测试象限作为敏捷测试的基础框架，是每个敏捷测试人员必须要了解的知识。敏捷测试象限表示了不同类型的测试有不同的目的，主要的维度包括面向技术还是面向业务、面向支持团队还是面向评价产品。然后根据这几个维度按组合分为四个象限，而敏捷测试中涉及到的所有测试类型都归集到这四个象限中：

　　第 1 象限（Q1）：面向技术、支持团队的测试

　　第 2 象限（Q2）：面向业务、支持团队的测试

　　第 3 象限（Q3）：面向业务、评价产品的测试

　　第 4 象限（Q4）：面向技术、评价产品的测试

　　二、敏捷测试象限介绍

　　敏捷测试象限具体每个象限的介绍如下：

(Q1) 面向技术和支持团队的测试

　　主要是开发人员执行的测试。

　　测试类型：单元测试/模块测试、集成测试。

　　测试目标：验证单元模块被正确的实施。

　　主要采用自动化测试的方式，例如在代码检入之前的频繁的自动化测试和重运行。

　(Q2) 面向业务和支持团队的测试

　　主要是测试人员执行的测试。

　　测试类型：功能测试、样例、用户故事测试、原型、模拟等。

　　测试目标：验证一个功能或者用户故事根据验收标准被正确的实施。

　　主要采用自动化为主，手工测试为辅的方式。

(Q3) 面向业务和评价产品的测试

　　主要是业务验收人员和测试人员执行的测试。

　　测试类型：探索式测试，情景测试、可用性测试、用户验收测试、Alpha 测试及 Beta 测试等。

　　测试目标：验证功能满足业务和终端用户需要。

　　主要以手工测试为主，自动化测试为辅的方式。

　(Q4) 面向技术和评价产品的测试

　　主要是测试人员执行，项目团队配合的测试。

　　测试类型：性能/负载测试、安全性测试、其它非功能性“-ility”测试。

　　测试目标：确定产品符合非功能性要求。

　　很多测试需要借助测试工具来完成，主要是自动化加手工结合的方式。

　　敏捷测试象限虽然把不同的测试类型根据目的进行了归类，让我们能得到相对全面的敏捷测试总览图，但是在真正进行敏捷测试的过程中其落地性的指导意义还是不够明确，对此更进一步的敏捷测试框架是 Mike Cohn 的测试金字塔。

　三、传统测试 V 模型的问题

　　我们知道在传统的瀑布型开发模式中，对于测试领域有一个著名的模型叫 V 模型。V 模型主要按项目周期的时间轴把测试分成不同的测试阶段，比如单元测试、集成测试、系统测试、用户验收测试等，如图2所示。V 模型的好处在于定义了不同阶段的测试应该关注于被测系统的哪些测试范围，各司其职而不重复。例如单元测试更关注于模块内部的质量；集成测试更关注于模块之间的集成；系统测试更关注于整个系统的功能正确性以及是否满足需求文档；用户验收测试是从最终用户的角度关注是否满足最终用户的需要。

　　但是 V 模型在敏捷环境下还是存在一些不适性。一方面在敏捷中测试活动是融入到整个开发过程中而不作为单独的阶段，所以 V 模型这种按不同阶段划分的方式明显不适合敏捷测试；另一方面在时间有限的情况 V 模型对各测试阶段需要投入多少精力并没有明确规定，所以导致有不少项目对于单元测试不重视，开发人员由于受到开发进度的压力，很多时候简单测试一下甚至是没有经过自测就提交给测试人员，从而让测试人员不得不花大量的时间来拦截缺陷，一不小心就成为“背锅侠”。在集成测试阶段有些时候因为有测试人员的介入，所以相对来说会做得充分点。但是由于在这个阶段对测试人员的技能要求需要有白盒测试的基础，所以不是每个测试人员都有能力执行集成测试，因此更多的测试工作被推后到了 UI 层的测试，包括 UI 界面的自动化测试和大量的手工测试。这种情况如下图3所示的左边部分。由于左图看起来很像一个冰激凌，所以我们称为“冰激凌”模式。

　　冰激凌模式有几个弊端：

　　测试脆弱性：由于我们的自动化测试脚本集中在 UI 界面，而 UI 界面往往是最不稳定的部分。界面控件经常会发生变化，这对于 UI 端自动化测试脚本来说简直就是灾难。我们知道 UI 自动化测试是非常依赖 UI 界面的控件稳定，只要控件有变化，整个脚本就得重新调整和维护，否则脚本就会运行失败。所以自动化测试非常脆弱。

　　延迟可能性：由于我们在单元测试、集成测试做得不够充分，导致把风险留到了后面阶段，我们需要在后面的 UI 测试花大量的时间进行测试，这时发现缺陷修复缺陷的周期变得非常长而且不可控，从而大大提高了延迟的可能性。

　　复杂性：假如我们在单元测试、集成测试阶段没有测试充分的话，在 UI 界面测试时如果发现缺陷，那么对于缺陷的定位、诊断和分析都变得更加复杂。

　　成本：我们知道测试的一个定律，也就是越早发现缺陷，修复的代价越低。如果我们把一个缺陷留在后面阶段才发现的话，将会大大提升整个项目的成本。