敏捷测试现实与幻想
作者:网络转载 发布时间:[ 2012/7/18 11:13:48 ] 推荐标签:
如果您的公司正在实践敏捷开发,你可能已经遇到和George Wilson相同的挑战。作为AIG Computer Services的Business Group Manager,他同时还在TickIT管理环境中管理IBM 中端和PC开发项目,这些都需要ISO9001的QA认证。现在,作为测试自动化工具厂商Original Software的共同创始人和总经理,他开始布道敏捷实践,作为达到质量的佳方式。
“敏捷项目对于QA来说,是一个领导(测试)整个过程极好的机会,”Wilson说。不该是开发者掌舵整个过程,测试员只是次要的地位,他推荐测试员应该带头起领导作用。“还有其他更好的人能消除用户和开发者之间的鸿沟吗?理解什么是必需的,怎样才能达到目标?在发布之前如何确保质量?”这要求QA team自身在敏捷活动中非常灵活,所以Wilson 列举了以下的事实来揭穿一些常见的敏捷测试的谎言。
谎言一:你需要做单元测试——TDD测试足够了
TDD(测试驱动的开发 Test Driven Development)是一个好的开始,但是对于那些认为TDD是全部的人,“对于绝大多数的商业开发来说,这显然是不对的。即便是敏捷开发的强烈支持者也认识到使用大量测试技术的必要性….包括白盒测试、黑盒测试、回归测试、压力测试和用户验收测试(UAT),”Wilson说。
因此,有效的敏捷项目将会包括探索性测试(黑盒测试)的技术补充(而不是竞争)白盒测试。“好的探索性测试将会在陷入深渊之前,发现开发者遗漏掉的问题。”Wilson说。
谎言二:你可以重用单元测试,构建回归测试集
传统的位于开发活动后期的测试不是必要的,因为应用程序的每一行代码都有对应的测试用例,有人曾经告诉过你吗?“一些TDD支持者…建议通过重新组织单元测试,从用户验收测试(UAT)到回归测试的一切都可以执行。Wilson说。
听起来好像很有道理,Wilson认为这实际上是不现实的,因为TDD开发的白盒单元测试的粒度和目标,和后期的黑盒测试,目的完全不一样。“单元测试全部的目标是验证代码做预期的事,回归测试的目标是保证修改后的应用代码没有意料之外的,或者是意外的结果。”这两个目标不完全相同。如,检查一个属性是有效的日期格式,和对于给定的输入,检查字段的值包含预期的日期,是不同的。
谎言三:我们不再需要测试员或者自动化工具
不对。测试员执行“和他们的开发组同事不同的、但同样有效的任务,”Wilson说,测试员应该在项目表(project table)上有同样的位置。“传统的测试自动化工具没能做到工具厂商宣传的广告效果,这已经是被广泛公认的事实。也许厂商们(没有恶意,Original)应该降低宣传的规格。”
谎言四:单元测试后不再需要手工测试
没有人会不同意手工测试是重复的、昂贵的、令人厌烦并且容易出错的。虽然TDD可以减少手工做功能测试的工作量,但它不能替代更多的手工或者自动化的黑盒测试。“通过自动化捕获测试员的操作过程,记录他们的键盘按键和鼠标移动,测试员将会有更多的时间来做‘有趣的’、更有价值的活动,例如测试那些很难或者不可能自动化的复杂的场景。虽然手工测试发现错误是耗时的(因此也是昂贵的)方法,但没有发现他们的代价常常会更大。”Wilson说。
谎言五:不再需要用户验收测试
在Wilson经历的敏捷开发中,验收测试常常定位是“和客户一起工具,解决不正确的需求”,而不是“纠正不满足用户需要的功能”。也许实际上两点都有。“当用户初定义他们的需求时,他们是基于他们初的期望。当他们看到刚‘新鲜出炉’的系统时,他们总是会提出不同的或者额外的需求,”他说。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11