不管是手工测试、API自动化测试、GUI自动化测试、性能测试，我们都需要构造测试数据，高效构造符合测试目的的数据也是软件测试工程师的必备技能之一，总得来讲，构造测试数据主要有以下几种方法：

1. 通过GUI构造测试数据。这是最原始最基本的方法，通过在客户端操作来构造我们的测试数据，例如创建订单，我们在客户端下单即可构建订单数据。通过GUI构造测试数据的优点是保证了数据的准确性，不会因为脏数据影响我们的测试结果。但通过GUI构造测试数据的缺点就是效率不高，如果我们要构造1万+订单数据，那我们不可能通过GUI手工下1万+订单。

2. 通过API构造测试数据。通过API构造测试数据，我们就能够解决构造1万+订单数据的问题。通过GUI构造测试数据，实质上就是在客户端调用API接口来构造测试数据。那么，我们直接调用API接口，并结合jmeter等工具，就可以绕过客户端批量构造测试数据（注：如果不清楚构造测试数据所调用的API，那么直接在GUI上构造一遍所需要的测试数据并抓包就知道了；或者询问开发同学也可以）。通过API构造测试数据的优点就是效率高，并且也不会带来脏数据。但如果我们要构造100万+订单数据，通过API构造测试数据还是需要一点时间的。这个时候该怎么办呢？

3. 通过数据库操作构造测试数据。我们调用API接口构造测试数据，实质上是先调用API，API再调用数据库语句来构造测试数据，那么我们理所当然的可以直接调用数据库语句来直接构造测试数据。通过直接调用数据库语句，我们能实现海量数据的构造。但通过数据库操作构造测试数据的缺点是维护成本高。假如服务端代码有改变，涉及到数据库字段的变动或代码实现的变动，那意味着我们构造测试数据的数据库语句脚本也需要改变。而通过API构造测试数据则不存在这个问题，因为不管数据库字段和后端代码逻辑如何改变，API是不会变的，这就大大降低了API脚本的维护量。此外，像Redis这样的缓存数据库，是无法批量操作的，要在Redis中构造海量测试数据，还是需要通过调用API接口来实现。

4. 通过软件抓包打断点或修改数据库来构造测试数据。对于一些特殊场景用例的测试，我们也会通过软件抓包打断点或修改数据库来构造测试数据。例如，我们要测试客户端上100+消息时的表现，这时候就可以抓包后打断点，把消息数修改成100+即可。（如何抓包打断点，可以参考之前写的一篇博文<a href=\"http://122.51.4.96/blog/45\">Charles抓包、打断点及模拟网络环境</a>）。

       再比如，有一个活动的需求，活动有开始时间和结束时间，假如活动将于一个月后结束，我们想要测试一个月后的用例，那么我们就可以把数据库中的活动结束时间修改成5分钟后，以此实现执行活动结束的用例。

       需要注意的是，对于实际测试中，我们还需要结合具体的用例，并基于测试数据的特性来决定选择哪些方法构造测试数据。基于测试数据的特性，我们又把测试数据分为on-the-fly（即用即建）和out-of-box（开箱即用）两种。其中，on-the-fly是执行测试用例时需要实时创建的数据，这类数据我们很难事先准备，一般被称为“活水数据”（不稳定，经常改变的数据），例如我们执行下单的用例，订单号是实时生成而不是事先准备的，因此往往采用GUI来构造测试数据。out-of-box是执行测试用例时可以事先准备、开箱即用的数据，例如我们下单前需要有很多商品，那么这些商品数据是可以事先准备的，一般被称为“死水数据”（稳定，几乎不改变的数据），因此可以采用API、数据库操作或API和数据库操作结合的方式来构造测试数据。