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

  • Amr Elssamadisy
  • 张晓庆

2009 年 6 月 8 日

话题:敏捷测试文化 & 方法

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

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

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

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

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

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

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

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

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

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

敏捷测试文化 & 方法