案例设计：数据驱动为主

hobli

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

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

堆积颜色

没看明白~~sdlkfj1

测试数据不是依照测试用例来设计的吗？而测试用例是依照需求外加种种分析方法做出来的，这样的话怎么会产生大量的随机数据呢？sdlkfj8

hobli

你说得没有错，这也正是我所倡导的。在本文中，我只是提及我观察到的一个现象，有些测试员倾向于是用rand()函数，来生成随机数据，用于测试。的确，可以发现很怪得bug,但是弊大于利。

hapliu

随即测试并不是主要测试路线，但并不是不可取的。主要路线还是有计划的含盖范围广的测试用例测试。
     当测试用例执行完成后，本人个人认为还是需要进行随即测试的（时间允许的话）。
真的能够发现一些BUG及问题的，对于以后的修复测试用例和测试方法有一定的帮助。

hobli

绝对同意hapliu 的意见。特别是：
"对于以后的修复测试用例和测试方法有一定的帮助", 我举双手赞成，实际上，我们可以建立某种方式的bug feedback, 从中可以不断改进/调整我们的测试方法，甚至开发方法！

在测试中，没有什么是绝对的，即使是所谓的
侧重的经典理论，也有它不适合的环境，关键是我们要灵活变通的对待。这就是靠经验的悟性了！
当然，有了论坛，我们共同进步的效率会大大提高！:)