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

发表于:2017-7-27 15:36

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:朱少民    来源:软件质量报道

分享:
  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: 面向技术的评价产品质量,基于工具的 “功能、性能、安全性、可靠性”等测试与建模分析,这也是全生命周期的、持续的,但更体现了技术性。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号