[ZZ]为什么传统的自动化测试工具会扼杀敏捷？

作者 Mike Bria译者 郑柯 发布于 2008年5月7日 上午11时35分

社区

Agile

主题

软件测试,

敏捷技术

标签

Fit/Fitnesse,

测试,

测试驱动开发

最近，关于下一代功能测试工具发展方向的讨论热闹地开了锅。不过，还是众多组织仍然在努力让传统的“录制-回放”测试工具跟上敏捷的脚步。被称为“测试狂人”的Elisabeth Hendrickson告诉他们为什么不要再白费功夫了。

Hendrickson将她的看法出色地总结为下面这种索引卡片的形式：

为什么传统的、“录制-回放”式的、重量级的、商业化测试自动化解决方案做不到敏捷
三个原因：

1. 对于敏捷团队来说，类似工具所鼓励的“最后再测试”的工作流程是完全错误的。
2. 类似工具创建的无法维护的脚本会成为敏捷所需的变更的障碍。
3. 这样的特定工具会需要专门的自动化测试专家，因此会形成单打独斗的局面。

Hendrickson首先讲述 “录制-回放”式工具的“最后再测试”方式是如何难以取得成功的，而无关乎项目是否敏捷。她解释了为什么这对敏捷项目来说尤其是个伤害。在敏捷项目中，“最后再测试”的工作流程至少有下列问题：

• 浪费：同样的信息在手工和自动化回归测试中会重复出现。实际上，它也在其他地方有所重复。不过我们可以先将注意力放在手工和自动化测试之上。
• 反馈延迟：这种工作流程中，大量的测试都是手工方式，这就是说要花费几天甚至几周的时间才能发现原先给出的变更所产生的效果。如果我们的Sprint是四周一次，那用三至四周的时间等待回归测试结果就无法令人接受。

……进一步说，“最后再测试”工具无法支持“验收测试驱动开发（Acceptance Test Driven Development）”。敏捷团队需要的测试工具要支持“首先测试”的方式，并可以马上开始进行自动化测试。

Hendrickson解释了测试脚本如何成为这些“录制-回放”测试工具的基础，而且会无可避免地造成类似意大利面的混乱局面，将UI代码中有关业务上的期待和具体实现细节混杂在一起，从而导致敏捷项目很容易变为一场维护的噩梦。她简明地说：

敏捷团队需要可以将要测试的业务实质内容与实现细节相分离的工具。这样的分离是良好设计的标志，并可以增加可维护性。

接下来，在很大程度上出于考虑高昂成本和代码所有权的需要，典型的“录制回放”工具会将大多数组织引向创建专有的“自动化测试专家”小组之路，并且他们会被授权负责监控自动化测试。Hendrickson强调了这样的方式是如何对有效敏捷所需的协作方式形成阻碍的。

敏捷团队通过破除单干的局面来提升工作效率，这凭一些所谓的自动化测试“超级英雄”无法完成。也就是说自动化测试成为需要协作完成的工作。业务利益相关者、分析师和黑盒测试人员，他们都可以通过可自动化的形式（比如Fit表格）来做出对测试的贡献；而程序员则负责编写代码将测试与实现相关联。

最后，Hendrickson讨论了敏捷团队确实需要什么样的自动化测试工具，并以此作为结束：

敏捷团队需要的自动化测试工具或框架要像这样：

• 要支持“首先测试”的方式，并可以马上开始进行自动化测试。
• 将要测试的业务实质内容与实现细节相分离。
• 在自动化测试需要编码的部分，支持并鼓励好的编程实践。
• 支持使用真正的开发语言、真正的IDE来编写自动化测试代码。
• 促进协作。

Fit、FitNesse以及相关工具可以达成上述要求。

很值得花费一些时间来读Elisebeth Hendrickson这篇完整的博客帖子，这样更加了解她深入的想法和经验。此外还可以阅读Brian Marrick的博客来获取更多关于敏捷测试的专家级建议。

查看英文原文：Why Traditional Test-Automation Tools Stifle Agility.