常见的敏捷测试的谎言

常见的敏捷测试的谎言

谎言一：你需要做单元测试——TDD测试足够了

因此，最有效的敏捷项目将会包括探索性测试(黑盒测试)的技术补充(而不是竞争)白盒测试。“好的探索性测试将会在陷入深渊之前，发现开发者遗漏掉的问题。”

谎言二：你可以重用单元测试，构建回归测试集

传统的位于开发活动后期的测试不是必要的，因为应用程序的每一行代码都有对应的测试用例，有人曾经告诉过你吗?“一些TDD支持者…建议通过重新组织单元测试，从用户验收测试(UAT)到回归测试的一切都可以执行。

听起来好像很有道理，我认为这实际上是不现实的，因为TDD开发的白盒单元测试的粒度和目标，和后期的黑盒测试，目的完全不一样。“单元测试全部的目标是验证代码做预期的事，回归测试的目标是保证修改后的应用代码没有意料之外的，或者是意外的结果。”这两个目标不完全相同。如，检查一个属性是有效的日期格式，和对于给定的输入，检查字段的值包含预期的日期，是不同的。

谎言三：我们不再需要测试员或者自动化工具

不对。测试员执行“和他们的开发组同事不同的、但同样有效的任务，测试员应该在项目表(project table)上有同样的位置。“传统的测试自动化工具没能做到工具厂商宣传的广告效果，这已经是被广泛公认的事实。也许厂商们(没有恶意，Original)应该降低宣传的规格。”

谎言四：单元测试后不再需要手工测试

没有人会不同意手工测试是重复的、昂贵的、令人厌烦并且容易出错的。虽然TDD可以减少手工做功能测试的工作量，但它不能替代更多的手工或者自动化的黑盒测试。“通过自动化捕获测试员的操作过程，记录他们的键盘按键和鼠标移动，测试员将会有更多的时间来做‘有趣的’、更有价值的活动，例如测试那些很难或者不可能自动化的复杂的场景。虽然手工测试发现错误是耗时的(因此也是昂贵的)方法，但没有发现他们的代价常常会更大。”

谎言五：不再需要用户验收测试

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