| 最近在企业里面看了一些测试案例的数据准备，发现了一个共性问题：测试数据中存在大量冗余，这些冗余会给后续的测试案例及数据维护带来大量的成本。
为了便于大家理解，先举一个例子：
测试信用卡交易金额汇总，测试数据完全从csv中加载，每个测试案例根据csv中的数据，assert特定返回值（由于篇幅限制，这里只举了一个简单的例子。实际看到的情况是，csv完全没有字段名称信息，一行里面成百上千个数据，而且还有许许多多类似结构的csv文件作为测试数据）。
在这两个文件里面，我注意到有大量冗余。以csv格式的测试案例为例，想象一下如果未来这个表结构发生变化（增加或减少字段），那么需要修改所有这些csv文件，会是什么样的工作量！
在乔梁翻译的《持续交付：发布可靠软件的系统方法》一书，其实已经给出了解决思路，只不过由于没有具体实例，不是很容易理解。
经何勉提醒，发现在《实例化需求》一书中，也提到了类似思路，但同样都没有实例，：）：
下面我们就以上面例子为基础，说明一下两本书中的思路如何具体应用：
应用程序引用数据(Application reference data)是测试无关数据，但它们是应用程序启动所必需的，这些数据往往是指一些基表和基础数据；
测试引用数据（Test reference data）是那些和测试相关，但是对测试行为没有多大影响的数据，在下面两个例子中，黄色就是测试引用数据
测试专属数据（Test specific data）：真正影响测试行为的特征数据
了解了测试引用数据和测试专属数据的区别后，我就可以介绍测试数据构造第一秘技了：
将测试引用数据和测试专属数据的准备过程分离，分离复用测试引用数据准备，而将测试专属数据保存在测试脚本中。
具体的做法是，第一个例子中，我们建议在每个测试案例里面，先使用一段公共程序为每个案例准备一样的测试引用数据，然后再用UPDATE语句来将测试专属数据导入，测试案例的伪码如下：
测试案例1
从CSV导入测试引用数据
测试专属数据导入
UPDATE transactions SET amount = 15.99 WHERE id = 1;
UPDATE transactions SET amount = 30.98 WHERE id = 2;
UPDATE transactions SET amount = 75.95 WHERE id = 5;
UPDATE transactions SET amount = 150.9 WHERE id = 10;UPDATE transactions SET amount = 750.5 WHERE id = 50;
|
测试执行
测试验证 （总和是1024.32）
测试案例2
从CSV导入测试引用数据
测试专属数据导入
UPDATE transactions SET amount = 34.56 WHERE id = 1;
UPDATE transactions SET amount = 56.78 WHERE id = 2;
UPDATE transactions SET amount = 57.97 WHERE id = 5;
UPDATE transactions SET amount = 44.32 WHERE id = 10;
UPDATE transactions SET amount = 234.65 WHERE id = 50 |
测试执行
测试验证 （总和是428.28）
这样做主要有两点好处：
测试案例可维护性：上面这些案例中，测试引用数据由于使用了INSERT语句，它其实会受到数据库表结构变化的影响，而测试专属数据准备由于使用UPDATE语句，不会受到数据库表结构变化的影响。我们通过统一测试引用数据准备程序，将这种变化的冲击大大降低，未来数据表结构变更，我们只需修改统一的测试引用数据准备程序而无需修改每一个案例，这其实暗合了DRY原则（Don’t
repeat yourself）。
测试案例可读性：由于我们将测试引用数据准备从独立出来了，只要看测试案例本身，就可以明确地看到测试专属数据，被测行为和结果验证，让案例可读性大大提升。
为了便于大家理解，我们再举另一个例子，假设有一个测试汇率转换接口，测试输入是xml文件：
应用测试引用数据和测试专属数据分离原则，可以看到哪些是引用数据，哪些是专属数据
因此，在测试案例中，我们会先准备并加载一个基底XML文件，再设置测试专属数据，下面是利用Robot
Framework编写的两个测试案例，可以看出，未来如果XML文件的结构有任何变更，我们都只需要修改基底XML文件即可，而不需要修改任何测试案例了
至此，我们想大家已经明白，对于测试数据准备这个步骤而言，将测试引用数据和测试专属数据分离，会非常有效地提升测试案例可维护性和可读性。
| 
