你的测试只限于你为测试所保留的某些特殊值，这意味着你将小心地选择那些特殊值。
如果数据对时间敏感，那对数据库的维护将更为困难。例如，数据库中有产品销售提议，而该提议只在明确的时间段里有效。
我曾经试着做过修改。例如，在数据库中增加“is_test”字段作为区分测试数据的标志，从而避免特殊值的问题。但由此带来的问题是，你的测试代码将只测试那些标记为测试的数据，而你的正式代码却要处理那些未标记为测试的数据。如果你的测试在这方面有区别，你事实上并不在测试同一代码。
你需要四个数据库
有些想法认为一个好的测试是足够充分的并能建立测试所需要的全部数据。如果你能在测试进行前就明确知道数据库所处的状态，测试可以进行一些简化。一个简化的方法是建立一个独立的单元测试数据库用于测试程序，测试程序在开始进行前清除测试数据库中的全部数据。
在代码中，你可以编写一个dbSetUp方法，如下所示：
public void dbSetUp()
{
// Put the database in a known state:
// (stored procedures would probably be better here)
helper.exec("DELETE FROM SomeSideTable");
helper.exec("DELETE FROM User");
// Insert some commonly-used test cases:
...
}
任何数据库测试程序都将在做任何事前首先调用dbSetUp方法，它将使测试数据库处于一种已知状态(大部分情况下是空数据库状态)。这种做法具有以下的优点：
所有的测试数据都在代码层和其他编程人员进行交流，因此没有必要进行外部测试数据协调。
无须测试用的特殊数据的介入。
简单而容易理解的一种方法。
在每一次测试前删除和插入数据可能会花较多时间，但是由于测试用的数据量相对较小，我认为这种方法比较快捷，特别是在测试一个本地数据库时。
这种做法不利的一面是你需要至少两个数据库。但是请记住，他们在必要是都可以在同一个服务器上运行。采用这种方法，我用了四个数据库，另外两个在紧急关头时使用，具体如下：
1.实际使用数据库，包含实际数据。在这个数据库中不进行测试，确保数据的完整性。
2.你的本地开发数据库，用来进行大部分的测试。
3.一个加入一定量数据的本地开发数据库，可能和其他编程人员共享，用来运行应用程序并检测是否能在实际使用的数据库上运行，而不是照搬实际使用数据库中的全部数据。从严格意义上说你可能并不需要这一数据库，但这一数据库能确保应用程序在有大量数据的数据库中顺利运行。
文章来源于领测软件测试网 https://www.ltesting.net/