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

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

socalled Agile Testing Quadrants

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

  • 哪些测试更适合自动化测试?
  • 哪些测试更适合手工测试?
  • 哪些测试需要手工测试和自动化测试结合起来?
  • 测试工具在哪些测试中发挥主导作用?

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

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

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

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

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

再仔细想想

  • 为什么单元测试是支持团队,而性能测试就不是呢?
  • 为什么功能测试和用户故事测试是支持团队,而探索式测试就不是呢?
  • 性能测试/安全性测试是评价产品,功能测试为什么不是评价产品呢?
  • Examples(实例?)、原型和仿真 有验证的作用,但许多时候不是为了测试,而是为了沟通,搞清楚用户的真实需求。

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

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

  • Q1: 面向技术的测试驱动开发,测试驱动开发,单元测试代码行覆盖率达到100%,代码都经过扫描、静态分析(静态测试),自动的持续集成测试(CI是敏捷开发的重要特征)。传统开发也做单元测试,只是力度不够,做单元测试的方式就更不同。
  • Q2: 面向业务的测试驱动开发,实例化需求,让需求可执行,需求即测试,常见的开发模式有ATDD/BDD等,再进一步,可以测试驱动设计。
  • Q3: 面向业务的评价产品质量,探索式测试,配合SBTM、众测。传统测试也会做易用性测试、用户验收测试,不是敏捷测试的特点。
  • Q4: 面向技术的评价产品质量,基于工具的 “功能、性能、安全性、可靠性”等测试与建模分析,这也是全生命周期的、持续的,但更体现了技术性。

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

参考:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

联系我
  • 上海市嘉定区曹安公路4800号同济大学软件学院
  • kerryzhu@vip.163.com