案例设计：数据驱动为主

我们在设计测试案例的时候，比较容易犯如下两个错误：
1. 使用大量随机函数，产生随机的测试数据，来进行测试。我们会以为这样产生的数据才是最“真实“的。其实，这样做，会有如下弱点：
   我们设计测试案例在绝大多数情况下，只能验证我们的应用对普通数据是否运作正确；由于这个局限性，我们测试案例在大部分时间可能只是做一些重复的测试，我们测试的有效性和高效性也很难实现。由于数据是随机产生
的，及时发现问题，要重现，需要花费大量的时间，即：cost;由于随即的数据不具有系统的设计性，所以，我们
很难回答这样一问题：测试的涵盖范围是多大？同样的，由于数据的随机性，发现的错误也具有随机性，所谓的
failure rate 在这种情况下，在可控制的时间内可能不会明显降低，也就是说，我们也回答不了“什么时候可以
停止测试”这个问题。
2. 有过开发经验的测试人员更容易这个毛病：常使自己去开发一个具有“同样”功能的应用，作为参考。通过输入
相同的数据，比较开发人员的应用与参考应用的处理行为，来测试开发应用。这种方法，有如下弱点：一般情况
下，我们开发的参考应用，本身就会各种问题，而且，错误几率与开发员是基本一样的，用相同错误率的应用作为
参考，本身不符合逻辑，查找和清除参考应用的时间，本来可以用来测试开发应用的。就算是我们的参考应用完美无瑕，要使用什么样的测试数据来进行比较，还是我们要考虑的问题，而如果我们能正确、巧妙、高效地选取测试
数据来确保测试的完备性，这些数据完全可以用来直接测试开发应用，我们的参考应用的价值，可以说几近为零。还有，我们用来开发“参考应用”的时间，本来可以用来设计测试数据，这样一来，我们的测试周期，几乎翻
倍了。

所以，在一般情况下，我们应该更加重视测试数据的设计和使用，即所谓test data driven. 当然，个别时
候，随即数据的使用还是可能的，但绝不是充分条件。