敏捷测试现实与幻想

　　敏捷测试现实与幻想   软件测试

　　如果您的公司正在实践敏捷开发，你可能已经遇到和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经历的敏捷开发中，验收测试常常定位是“和客户一起工具，解决不正确的需求”，而不是“纠正不满足用户需要的功能”。也许实际上两点都有。“当用户最初定义他们的需求时，他们是基于他们最初的期望。当他们看到刚‘新鲜出炉’的系统时，他们总是会提出不同的或者额外的需求，”他说。

　　虽然敏捷过程可能会减少以上这些发生的频率，Wilson认为，但指望敏捷方法完全杜绝它是不切实际的，所以不要期望完全消除用户验收测试。“当提到企业用户正式同意用户界面时，这尤其是真理，因为他们设想的和开发者是不一样的。”

原文转自：http://www.ltesting.net