“如果我们循序渐进地做项目，那么一个大型软件项目就成了一系列小的项目。在这些小项目中，如果我们无法为下面两周所作的工作制定可供测试的验收标准，那么我们的麻烦就大了。如果我们可以制定该标准，那么我们为什么不直接用测试用例来表现该标准，反而要用其它方式表现该标准而后又从中衍生测试用例呢？”
-- Steven Gordon, 博士, 原文出自Agile Testing List
Steven Gordon在上文中所推荐的想法超过了普通的验收测试自动化。事实上，他建议我们直接把测试用例当作产品需求来用。换句话说：如果我们在一开始就开发了测试用例，用其衡量代码是否正确 -- 那么需求文档还拿来干什么呢？如果测试用例通过了，代码就是正确的。如果现有用例不能论证代码是正确的，那么我们则需要更多的测试。
我得承认，这种逻辑有些诱人。第一，自动测试用例是具体、明确、而且显然可测试的。你（至少现在）不可能写一个能“适当的处理错误”的模棱两可的自动测试。反之，你必须定义发生错误的情况，软件对其反应，以及怎么去衡量这些错误是否正确。同时，发现不一致的测试要比发现不一致的需求容易的多。比如：“这两个用例输入一样，输出却不同，到底哪个正确？”
但现实中是什么样的呢？
试想现在我们有个项目是设计并创造一个简单的网页 – 一个把华氏度转为摄氏度的在线服务。我们的商业用户制定了一套验收测试，而我们把它全部自动到只要按一个按钮就能运行。在产品初具规模时，我们运行这个自动测试工具而得出了以下结果：
| 函数 | 输入 | 期待输出 | 实际输出 | 结果 |
| Convert_Farenheit_To_Celsius | 32 | 0 | 0 | |
| Convert_Farenheit_To_Celsius | 212 | 100 | 100 | |
| Convert_Farenheit_To_Celsius | 100 | 38 | 38 | |
| Convert_Farenheit_To_Celsius | 300 | 149 | 149 | |
| Convert_Farenheit_To_Celsius | 0 | -17 | -17 | |
| Convert_Farenheit_To_Celsius | 10 | -12 | -12 | |
| Convert_Farenheit_To_Celsius | -20 | -29 | -29 |
很明显，所有的验收测试都过了，那么这软件一定工作，对吧？
试想如果你是这个软件的商业用户，或者是一个独立的第三方测试人员，你愿意让这个软件过关吗？
作为一套测试用例集，以上的列表还比较全面。但作为需求文档，有许多方面它都没有覆盖到：
把华氏转为摄氏的基本逻辑是什么？分数结果怎么处理？应该四舍五入还是用小数表示？
该函数的上限及下限是什么？
输入可以是分数么？
Null或者数学公式化输入怎么办？
为了要给出这些问题的答案，我们需要更多的测试用例。但就算这样做，还是会有无法回答的问题（比如基本逻辑）。
所以这就是问题根本所在：如果我们要随机的测试其它输入，就必须的知道期待正确的输出是什么 – 而要达到这个目的我们需要一个“先知”。需求文档可以在多数情况下担任“先知”的作用。如果没有这个“先知”，使这套验收测试通过就可以简单到专门为这些用例写一些只针对对它们返回正确值的代码。
以上是个很简单的例子。现实生活中的代码会与数据库、文件、以及有诸多变量的对象互动。
在我工作的环境里（我想在你的环境中也一样），事先制定好的验收测试用例是很有用的，不过单靠它们是不够的。所以我们会制定需求然后做探索性的验收测试。
验收测试可以成为需求文档很好的补充。它们可以作为例子形容这个软件应该做些什么。但例子不能做为解释，而测试用例并不能取代需求。
