你才刚刚步入这个炫酷、崭新的敏捷世界。学校里的课本、那些传统课程都已经被你抛于脑后，你游走于那些饱受欢迎、经久不衰的博客资源，说不定也从 InfoQ上吸取了一点知识和建议。此外，还有些指南告诉你：你必须让测试自动化——尤其是面向业务的“验收测试”，以确保需求被正确理解和满足。哦，你猜怎么着，现在有些相同背景的专家正在提出相反的意见：千万别把那些测试自动化了。

　　主导近这次相反建议的讨论的，是被尊为敏捷思想的James Shore，够讽刺的(不是吗?)，他曾一度担任Fit(Ward Cunningham的自动化验收测试框架，该项目也开启了自动化验收测试的先河)项目的协调员。

　　受到与Gojko Adzic一次谈话的触动，Shore发表了他关于“(自动化)验收测试存在的问题”的观点，总结为以下两点：

　　自动化测试工具的初衷，比如Fit，是想让业务人员(“客户”)自己写出可执行的例子来。过去的经验证明这非常难实现。少数情况下是由测试人员编写的，但多数情况下是开发人员在编写这些测试。

　　由于这些测试既慢又脆弱，还常常难于重构，它们通常会成为名副其实的维护负担。这一点，端到端的“集成测试”显然事半功倍，JB Rainsberger写了一系列的文章来阐述他这一观点的合理性。

　　总之一句话，Shore(间接地还有Rainsberger)认为，由于不存在预期价值(客户编写测试)，没有理由投入高成本(维护)了。

　　哇，不写自动化验收测试?看起来真是180度大转弯的极端想法。虽然这并不奇怪，但Brian Marick大谈类似的观点已经有一段时间了。又是一次讽刺(不是么?)，1998年Marick发表的关于自动化“面向业务测试”潜在好处的论文，成为了当时自动化验收测试运动的先驱。然而十年后，整整两年前，Marick却这样说：

　　TDD方式、白板风格、面向业务且注重实例的设计方法、可视化运作的探索性测试、以及一些少量的自动化系统整体健全性测试，程序员使用方法构建的应用软件，开发起来将更加经济，而且质量方面并不会比一个通过GUI做低限度的探索性测试、以及由注重实例设计方法指导的、完全用面向业务的TDD测试所开发的应用软件差。

　　Adzic是Shore观点的初接受者，他认同第一个观点，但并不完全信服“不要自动化”的所有观点：

　　我从未真正期望客户自己能写点什么，但是我在相当程度上成功说服了他们参与需求研讨会，会上提出的例子随后会被转化成验收测试……清晰的例子和改善的沟通是这一过程的大好处，而使用工具也会带来额外的收益。工具使得我们对进展有个公正的度量。Ian Cooper在对我的新书做访谈时说过“工具使开发人员保持诚实”，我很认同。用一个公正的工具来做评测，比如“完成”是真地完成了“大家一致同意的事情”，而不是“大部分都做好了剩下几件小事明天补”。我不确定现场回顾(Shore的评论里所提到的)是否能足以完全够避免这些问题。

　　George Dinwiddie也认为：让业务人员写测试或者在这类工作中投入很多测试人员收效甚微，但他坚持认为自动化对降低回归缺陷成本依然是很有意义的：

　　正如Elisabeth Hendrickson所说，“如果客户有一个期望，并表达清楚了这个期望，那么他们有充足的理由相信你已经满足了这个期望，他们可不想非得去手动再次验证事实上你之前已经做好的事。”

　　要求太过分了吗?

　　...

　　考虑到我所确信的东西还要拿去重测，而且迭代越短，他们需要更频繁地重测，我可不想放弃自动化测试。