尽管我们有系统测试，有回归测试，但是细心的同学可能都会发现，在预发布测试阶段，虽然时间相对很短，但是仍然有可能发现问题。那么我们是不是该思考为什么会在如此短的时间里（比如十分钟）就能发现我们花费了很多时间和精力却在测试环境没有发现的问题？

当然环境配置引起的差异我们可以先不去深究，那么在同样逻辑功能点的覆盖下，很显然我们会发现引起这一差异的根源在于我们测试最为基本的单元——数据。

我们都认可这样一个事实——真实环境数量的丰富性和真实性是我们在测试环境下无法比拟。如果说只是简单的同步真实环境到测试环境，那么已有的垃圾数据不清除，依然会影响到测试。或者即便是一套与真实环境一模一样的数据背景，倘若我们不能停止无效数据的注入，那么所有的数据完整性、唯一性还是一样的被破坏，那么一切还是回到了原点。

为什么真实环境的数据不会轻易遭到破坏，我想最基本的原因有两点，一是我们不会人为的直接干预数据库，二是我们在使用真实环境时本身就带有一种真实行为的操作倾向。

在测试环境下，很多时候我们为了方便测试，会直接修改数据库，甚至在没有弄清表与表之间的关联性，表与程序之间的联动，就进行操作，并且很多时候，我们只关注逻辑而忽略实际应用的场景，数据本身已缺乏逻辑，那么在此之上建立的测试执行结果，本身就有所欠缺。

所以我们的功能测试设计应该基于实际的应用场景 并描述表之间的关联，而我们的TC同样应该基于这些内容去编写，包括测试数据的描述，我想只有这样，我们才能尽早的发现问题，比如集成测试阶段，而非在预发布环境下，因为我们知道越早发现的好处。