自动化的验收测试──是否只是纸上谈兵？

编写需求并自动生成验收测试（有时候称作测试驱动需求，故事驱动开发，以及──要看你问的是谁── 行为驱动开发），在这方面已经有了零星的成功案例。然而社区中只有很少数的人这样用过。一些思想领袖公开声称这么做不好，浪费精力。每个迭代开始编写的自动化验收测试真的只是纸上谈兵吗？由于很少有人采用，这种方法是否难以奏效？

首先，让我们解释一下自动化的验收测试是什么意思：它是指在迭代开始时编写的测试，是用可执行形式表示的需求。当它们描述的需求开发完成后，就可以 作为详细的例子说明系统具有什么样的功能──也是对“我完成后，系统看上去是什么样的呢？”这个问题最好的解答。以前最常用的自动化验收测试工具是 FIT 和 FITNesse ，然而今天已经是 cucumber 和 rspec 了。

这种类型的测试还没有流行起来。事实上，最近有一篇讨论，题目就是 FIT 死了吗？ 除此之外，在敏捷 2008 大会上 InfoQ 的一个采访中，Brian Marick 就宣称：

InfoQ：听起来有意思极了。我赞同在业务层面的测试，客户能够理解，他们也乐于看到。你还提到了一些例子。我不知道是不是因为用文字描述测试太复杂了，你说的这些例子只是为了简化吗？但是你确实提到了客户的测试，不是吗？能否多介绍一点？

Brian：我注意到一件有趣的事情， 不管在哪个方面它都与单元测试驱动设计不同，比如：你设计了一个测试，通常你对问题已经非常了解。当然单元测试做的还是单元测试的事儿。但是为了使测试自 动化，不需人工干预就把例子运行起来，你需要编写支持代码，通常你不会有任何这样的想法”哈！真高兴写了那些代码，我学到了不少东西“，相反，你会这样想 ”写这些代码真是烦死人了，没学到任何东西“。所以编写那些代码不会有任何收获，除了拥有测试，你不会有任何实际的好处。直到现在，也看不出来验收测试对 深奥复杂的结构有什么影响，就像重构对单元测试那样。所以我的问题是创建测试能否带来价值？编写这些代码还需要投入相当大的成本，把测试自动化能得到与付 出同等的价值吗？因为如果不能从中得到同样的价值，为什么不在一个白板上测试，程序员实现功能，手工检查，甚至向产品负责人手工演示，完成以后，为什么不 擦掉然后忘记它？我们为什么需要把测试保存下来，然后一遍又一遍地运行它们？

然而，社区中许多其他的思想领袖仍然推荐使用自动化的验收测试；仅举几个例子，比如 Robert C. Martin、Joshua Kerievsky 和 James Shore 这样的大牛。

Christ Matts 使用一种有趣的方式来看待这个问题， 即把它作为“信息到达“的问题。比如你在软件开发过程中（不一定是敏捷的）并没有提前编写验收测试。QA 团队运行他们自己的测试场景，发现缺陷后，就反馈 给软件开发人员。缺陷是随机发现的，所以会影响团队的开发速度，因为开发团队必须花费一定的精力来解决这些缺陷。开发过程中，类似这样的信息会随机传递给 开发团队。

现在，我们考虑一下如果QA 部门在开发开始之前就编写测试。我们就可以预测这些信息在迭代开始时就会出现。因此不确定性的因素减少了，速度也就更稳定了（随机的打断更少了），这意味着有了更高的可预测性。

所以，自动化的验收测试只有所谓精英分子（或者交了狗屎运的人）才能玩的转吗？是否某些内部缺陷尚未发现，导致它名不副实？或者它确实有诸多好处，只是比较困难而已，应该鼓励每个软件开发团队去亲自尝试？

查看英文原文 ： Automated Acceptance Tests - Theoretical or Practical