Jim Shore提出自动化验收测试得不偿失

作者 Mike Bria 译者 金毅 发布于 2010年4月30日

领域

过程 & 实践

主题

敏捷 ,

敏捷实施

标签

验收测试 ,

业务/IT整合

你才刚刚步入这个炫酷、崭新的敏捷世界。学校里的课本、那些传统课程都已经被你抛于脑后，你游走于那些饱受欢迎、经久不衰的博客资源，说不定也从 InfoQ上吸取了一点知识和建议。此外，还有些指南告诉你：你必须让测试自动化——尤其是面向业务的“验收测试”，以确保需求被正确理解和满足。哦，你猜怎么着，现在有些相同背景的专家正在提出相反的意见：千万别把那些测试自动化了。
主导最近这次相反建议的讨论的，是被尊为敏捷思想领袖的James Shore，够讽刺的（不是吗？），他曾一度担任Fit（Ward Cunningham的自动化验收测试框架，该项目也开启了自动化验收测试的先河）项目的协调员。
受到与Gojko Adzic一次谈话的触动，Shore发表了他关于“（自动化）验收测试存在的问题”的观点，总结为以下两点：

1. 自动化测试工具的初衷，比如Fit，是想让业务人员（“客户”）自己写出可执行的例子来。过去的经验证明这非常难实现。少数情况下是由测试人员编写的，但多数情况下是开发人员在编写这些测试。
2. 由于这些测试既慢又脆弱，还常常难于重构，它们通常会成为名副其实的维护负担。就这一点，端到端的“集成测试”显然事半功倍，JB Rainsberger写了一系列的文章来阐述他这一观点的合理性。

总之一句话，Shore（间接地还有Rainsberger）认为，由于不存在预期价值（客户编写测试），就没有理由投入高成本（维护）了。
哇，不写自动化验收测试？看起来真是180度大转弯的极端想法。虽然这并不奇怪，但Brian Marick大谈类似的观点已经有一段时间了。又是一次讽刺（不是么？），1998年Marick发表的关于自动化“面向业务测试”潜在好处的论文，成为了当时自动化验收测试运动的先驱。然而十年后，整整两年前，Marick却这样说：

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

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

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

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

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

要求太过分了吗？
...
考虑到我所确信的东西还要拿去重测，而且迭代越短，他们就需要更频繁地重测，我可不想放弃自动化测试。
...
如果我们和客户一起着手用例开发，用客户的话说，我们就已经完成了最难的部分。投入额外的精力让这些用例可以运行（通过把它们自动化）从而预防缺陷是值得的，而不要在有了缺陷后再去想办法找出它们。

Shore很快用一个例子继续印证了他的观点，那就是他和他的团队在不使用自动化验收测试的情况下来“消除缺陷”。在这里，Shore澄清到，他并不是建议抛弃自动化验收测试，而是要用某些东西取代它，继而他描述了他眼中的“某些东西”。实质上，Shore勾勒出的方法正是当下极限编程实践的一个很棒的、严谨的应用（尽管如此，这篇文章还是非常值得一读，值得收藏）。

在对Jim两篇文章的回应中，Ron Jeffries参与了整个讨论过程。在诸多其它观点中，Jeffries始终像Adzic和Dinwiddie一样，认为不该遗忘自动化：

Jim一直坚持说他觉得测试不自动化没什么问题，而且即使客户不理解也没事。我觉得客户不理解没关系——尽管我倾向于客户能理解，如果成本很低的话。测试不要自动化的理念我却不能苟同。我担忧的是，如果测试不能自动化，回归就变得门户大开、不可控制了。

此时，测试什么时候该自动化，什么时候不用，如果没自动化，其它测试通常要怎样才算做到位，就成了要关心的问题。当然，没必要把每个用例都跑一遍来确保代码工作正常。但可能还是要跑一些。
...
我的结论是，显然Jim的团队所做的事情是可行的，而且他们做的所有XP的实践都很不错。如果其它团队也能将这些实践运用得那么好，他们可能得到类似的结果。

而我认为：自动化那些故事的测试用例，是预防缺陷在后续故事中出现的最简单、最有效的方法。

所以，每个人都重新强调了让业务人员和开发人员一起讨论用例依然是必不可少的一项。但至于自动化那些用例，Shore、Rainsberger和Marick认为也许不需要。其它人却说需要。

确实是一个有趣的讨论。你说呢？

查看英文原文：Jim Shore Suggests Automated Acceptance Tests Are Not The Right Move

译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。

1. 返回顶部

   是否自动化验收测试很大程度上取决于项目的规模

   发表人 Zhao Wei

   个人看法：
   
   如果项目的规模不够大（比如，研发预算10个人月以内），验收测试的内容不够多，开发和维护自动化验收测试的成本将高过手动执行这些测试。
   
   当项目规模足够大时，自动化验收测试的边际成本降低，而测试的执行次数增加（收益增加），这时候自动化验收测试就比较有意义了。
   
   产品的开发，不管是否以项目形式开发，自动化验收测试都是投入收益比良好的。

   回复

2. 返回顶部

   Re: 是否自动化验收测试很大程度上取决于项目的规模

   发表人 徐 毅

   可惜的是敏捷更多的是讲长期性的产品开发，而不是短期的项目开发。对于收益周期的判断和要求不同，自然看法也不同。
   
   你的说法“是否自动化验收测试很大程度上取决于项目的规模”一点都没错，但对于“长期性、延续性的产品研发”来说，“自动化验收测试”可以说是一种必须的实践。

   回复

• 更早的 >