测试数据的思考

这里说的测试数据是指测试用的、产生的数据，包括随机测试，执行测试用例，确认Bug等过程用的、产生的数据。

 

以前看到一个理论如是说:执行完测试后，应该清理掉测试数据。

 

对此，我也有一些体会及想法（我们项目组目前并没有按照这种理论进行尝试）：

 

1. 在验证Bug的时候、回归测试的时候，如果使用那些在以前测试的时候就产生好的测试数据，避免重复劳动，会有省下很多时间，从而提高效率。

 

2. 由于测试系统的性能这块表现出得能力很有限，测试数据太多了，常常做某些操作，都比数据量小的时候要多耗一些时间，这些时间积少成多，也是工作中的浪费。

 

3. 有些测试数据做得很好，覆盖的功能点很多，很精美，接近真实客户的想法。在测试过程中，使用到这些数据，往往能发现一些意想不到的问题。

 

4. 测试数据多了，难免会有一些垃圾数据，有时这些垃圾数据会引发一系列的问题：基于这些垃圾数据的测试，会得到错误结果；这些垃圾数据导致系统升级产生另一些错误。

 

5. 历史数据会给我们检测程序的兼容性。程序升级后，历史数据不能用了，这种情况的后果是十分严重的。所以在有历史数据的数据库里面升级程序，会轻松的得到检测结果。

 

So我在这里假想下 心中理想的情况（有缺陷是正常，不完善也是正常）：

Solution 1, 测试过程使用两个数据库，一个数据库只用在系统不稳定时，功能需求正在开发时，需要确认某些严重的BUG时，产生的数据到了最后都会抛弃掉；另一个数据库只用在系统稳定时，尽可能多产生一些有意义的、覆盖广的测试数据，如果出来垃圾数据，尽快把它们清除出。每当新一期开发任务时，就可以通过只有正常的数据的数据库，产生一个临时的测试数据库。

 

Solution 2, 只使用一个数据库，系统不稳定时，产生了垃圾数据、很多无意义的数据时，这个时候的测试数据都应该尽快清除掉（或者定期去清除掉）；当系统稳定时，尽可能多产生有意义的数据，以此检测功能，以备以后重复使用。

 

Solution 1 VS Solution 2

第一个方案，需要维护两个数据库，会导致一些多余的工作量；对于测试数据的界定，保留与否，有意义与否，还是比较好判断的。

第二个方案，对于测试数据的界定比较难，例如，某些看似无意义的数据库，也许包含得有重现某个bug的关键信息，删掉后，会也带来多余的工作量来重现。某些数据，不能轻易判断出该保留，还是该删除。

 

以上只是一家之言，难免有不对之处，有意见的有想法的，请提出来一起讨论。