你被“敏捷测试四象限”蒙蔽多少年了？

2009年出版的 Crispin & Gregory 的著作Agile Testing: A Practical Guide for Testers and Agile Teams 中第一次提出“敏捷测试四象限”，如下图所示：

（so-called Agile Testing Quadrants）

不少测试人就一直被蒙蔽到今天，把它当作“敏捷测试四象限”，不是吗？是不是被蒙蔽了整整八年？ 但实际上，你仔细想想，多问几个为什么，就不会认为这是“敏捷测试四象限”，这没体现出敏捷测试的什么特点，也没体现敏捷的价值观，它只是一个“通用的软件测试策略”的描述，也可以说，它是一个自动化测试的整体策略的描述，帮助刚入门的测试人员更好地理解：

• 哪些测试更适合自动化测试？

• 哪些测试更适合手工测试？

• 哪些测试需要手工测试和自动化测试结合起来？

• 测试工具在哪些测试中发挥主导作用？

（所谓的“敏捷测试四象限”中文版

Q1: 以支持团队的面向技术的测试

Q2: 以支持团队的面向业务的测试 

Q3: 以评价产品的面向业务的测试

    Q4: 以评价产品的面向技术的测试）

再仔细想想：

• 为什么单元测试是支持团队，而性能测试就不是呢？

• 为什么功能测试和用户故事测试是支持团队，而探索式测试就不是呢？

• 性能测试／安全性测试是评价产品，功能测试为什么不是评价产品呢？

• Examples（实例？）、原型和仿真 有验证的作用，但许多时候不是为了测试，而是为了沟通，搞清楚用户的真实需求。

解释不通吧？感觉问题很多。写上了“单元测试（Unit tests）”，为什么还写“组件测试（Component tests）”? 单元测试完全可以包含组件测试，因为“单元”就是一个相对比较抽象的概念，包括类、函数、模块、组件等系统的构成部分。

如果真正要画一个敏捷测试四象限，下面这个也许更合适一些（我只花了1个小时思考，有些匆忙，还不够成熟，有待完善 ）

• Q1: 面向技术的测试驱动开发，测试驱动开发，单元测试代码行覆盖率达到100%，代码都经过扫描、静态分析（静态测试），自动的持续集成测试（CI是敏捷开发的重要特征）。传统开发也做单元测试，只是力度不够，做单元测试的方式就更不同。

• Q2: 面向业务的测试驱动开发，实例化需求，让需求可执行，需求即测试，常见的开发模式有ATDD／BDD等，再进一步，可以测试驱动设计。

• Q3: 面向业务的评价产品质量，探索式测试，配合SBTM、众测。传统测试也会做易用性测试、用户验收测试，不是敏捷测试的特点。

• Q4: 面向技术的评价产品质量，基于工具的 “功能、性能、安全性、可靠性”等测试与建模分析，这也是全生命周期的、持续的，但更体现了技术性。

欢迎大家留言，发表自己的看法。

参考：

• 究竟什么是敏捷测试和探索式测试？

• 评《从一个实例详解敏捷测试的最佳实践》

• 敏捷测试的方法和实践 (上)

• 敏捷测试的方法和实践（下）

• http://docplayer.net/19943277-The-real-agile-testing-quadrants-as-we-believe-they-should-always-have-been.html