软件测试-如何准备测试数据

准备测试数据是软件测试种非常重要的一个环节，无论是手工测试、动化测试还是性能测试，准备工作种除了分析外最重要的就是准备测试数据。

从创建测试数据的维度来看，准备测试数据的方法主要分为四大类
1.基于 GUI 操作生成测试数据；
2.通过 API 调用生成测试数据；
3.通过数据库操作生成测试数据；
4.综合运用 API 和数据库的方式生成测试数据。

基于 GUI 操作生成测试数据：
基于 GUI 操作生成测试数据，是最原始的创建测试数据的方法。简单地说，它就是采用 E2E 的方式来执行业务场景，然后生成数据的方法。 比如，你想要测试用户登录功能，那么首先就要准备一个已经注册的用户，为此你可以直接 通过 GUI 界面来注册一个新用户，然后用这个新创建的用户完成用户登录功能的测试。 这个方法的优点是简单直接，在技术上没有任何复杂性，而且所创建的数据完全来自于真实 的业务流程，可以最大程度保证数据的正确性。

但是，该方法的缺点也十分明显，主要体现 在以下这四个方面：
1. 创建测试数据的效率非常低。一是因为每次执行 GUI 业务操作都只能创建一条数据，二 是因为基于 GUI 操作的执行过程比较耗时。
2. 基于 GUI 的测试数据创建方法不适合封装成测试数据工具。由于测试数据的创建是通过 GUI 操作实现的，所以把这种数据创建方法封装成测试数据准备工具的过程，其实就是 基于 GUI 操作生成测试数据； 通过 API 调用生成测试数据； 通过数据库操作生成测试数据； 综合运用 API 和数据库的方式生成测试数据。 在开发 GUI 自动化测试用例。无论是从开发工作量，还是从执行效率来讲，把基于 GUI 操作的测试数据创建方法封装成测试数据准备工具都不是最佳的选择。 
3. 测试数据成功创建的概率不会太高。因为，测试数据准备的成功率受限于 GUI 自动化执 行的稳定性，而且任何界面的变更都有可能引发测试数据创建的失败。
4. 会引入不必要的测试依赖。比如，你的被测对象是用户登录功能，通过 GUI 页面操作准 备这个已经注册的用户，就首先要保证用户注册功能没有问题，而这显然是不合理的。

通过 API 调用生成测试数据：
通过 API 调用生成测试数据，是目前主流的测试数据生成方法。其实，当我们通过操作 GUI 界面生成测试数据时，实际的业务操作往往是由后端的 API 调用完成的。所以，我们 完全可以通过直接调用后端 API 生成测试数据。 还是以用户登录功能的测试为例，我们通过 GUI 界面注册新用户时，实际上就是调用了 createUser 这个 API。既然知道了具体要调用哪个 API，那么我们就可以跳过在 GUI 界面 的操作，直接调用 createUser 生成“已经注册的用户”这个测试数据了。

通过 API 调用生成测试数据的方法，优点主要体现在以下几个方面：
可以保证创建的测试数据的准确性，原因是使用了和 GUI 操作同样的 API 调用； 
测试数据准备的执行效率更高，因为该方法跳过了耗时的 GUI 操作；
把创建测试数据的 API 调用过程，封装成测试数据函数更方便，因为这个调用过程的代 码逻辑非常清晰；

测试数据的创建可以完全依赖于 API 调用，当创建测试数据的内部逻辑有变更时，由于 此时 API 内部的实现逻辑也会由开发人员同步更新，所以我们依旧可以通过调用 API 来 得到逻辑变更后的测试数据，而这个过程对使用来说是完全透明的。

但是，该方法也不是完美无瑕的，其缺点主要表现在：
1. 并不是所有的测试数据创建都有对应的 API 支持。也就是说，并不是所有的数据都可以 通过 API 调用的方式创建，有些操作还是必须依赖于数据库的 CRUD 操作。那么，这 时，我们就不得不在测试数据准备函数中加入数据库的 CRUD 操作生成测试数据了。
2. 有时，创建一条业务线上的测试数据，往往需要按一定的顺序依次调用多个 API，并且 会在多个 API 调用之间传递数据，这也无形中增加了测试数据准备函数的复杂性。
3. 虽然相比于 GUI 操作方式，基于 API 调用的方式在执行速度上已经得到了大幅提升，并 且还可以很方便地实现并发执行（比如，使用 JMeter 或者 Locust），但是对于需要批 量创建海量数据的场景，还是会力不从心。 因此，业界往往还会通过数据库的 CRUD 操作生成测试数据。

通过数据库操作生成测试数据：
通过数据库操作生成测试数据，也是目前主流的测试数据生成方法。这个方法的实现原理很 简单，就是直接通过数据库操作，将测试数据插入到被测系统的后台数据库中。

常见的做法是，将创建数据需要用到的 SQL 语句封装成一个个的测试数据准备函数，当我 们需要创建数据时，直接调用这些封装好的函数即可。 可以保证创建的测试数据的准确性，原因是使用了和 GUI 操作同样的 API 调用； 测试数据准备的执行效率更高，因为该方法跳过了耗时的 GUI 操作； 把创建测试数据的 API 调用过程，封装成测试数据函数更方便，因为这个调用过程的代 码逻辑非常清晰； 测试数据的创建可以完全依赖于 API 调用，当创建测试数据的内部逻辑有变更时，由于 此时 API 内部的实现逻辑也会由开发人员同步更新，所以我们依旧可以通过调用 API 来 得到逻辑变更后的测试数据，而这个过程对使用来说是完全透明的。 还是以用户登录功能测试为例，当我们通过 GUI 界面注册新用户时，实际上是在后端调用 了 createUser 这个 API，而这个 API 的内部实现逻辑是，将用户的详细信息插入到了 userTable 和 userRoleTable 这两张业务表中。 那么此时，我们就可以直接在 userTable 和 userRoleTable 这两张业务表中插入数据，然 后完成这个新用户的注册工作。

通过数据库操作生成测试数据的方法，主要优点是测试数据的生成效率非常高，可以在较短 的时间内创建大批量的测试数据。

当然，这个方法的缺点也非常明显，主要体现在以下几个方面：
很多时候，一个前端操作引发的数据创建，往往会修改很多张表，因此封装的数据准备函 数的维护成本要高得多； 容易出现数据不完整的情况，比如一个业务操作，实际上在一张主表和一张附表中插入了 记录，但是基于数据库操作的数据创建可能只在主表中插入了记录，这种错误一般都会比 较隐蔽，往往只在一些特定的操作下才会发生异常； 当业务逻辑发生变化时，即 SQL 语句有变化时，需要维护和更新已经封装的数据准备函数。

综合运用 API 和数据库的方式生成测试数据
目前，在实际的工程实践中，很少使用单一的方法生成测试数据，基本都是采用 API 和数 据库相结合的方式。最典型的应用场景是，先通过 API 调用生成基础的测试数据，然后使 用数据库的 CRUD 操作生成符合特殊测试需求的数据。所以，你经常会看到很多的数据准 备函数中，既有 API 操作，又有数据库操作。
我以创建用户为例，和你分享一下如何综合运用 API 和数据库两种方式创建测试数据吧。 假设，我们需要封装一个创建用户的函数，这个函数需要对外暴露“用户国家”和“支付方 式”这两个参数。由于实际创建用户是通过后台 createUser API 完成的，但是这个 API 并 不支持指定“用户国家”和“支付方式”，所以我们就需要自己封装一个创建用户的函数。 自己封装用户创建函数的方法，你可以通过下面这个思路实现：
首先，调用 createUser API 完成基本用户的创建；
然后，调用 paymentMethod API 实现用户对于不同支付方式的绑定，其中 paymentMethod API 使用的 userID 就是上一步中 createUser API 产生的用户 ID；
最后，通过数据库的 SQL 语句更新“用户国家”。
在这个例子中，createUser API 和 paymentMethod API 只是为了说明如何综合运用 API 的顺序调用，而其具体参数并不是我要阐述的关键内容，所以我并没有和你详细说明这两个 API 的参数、实现方式等问题。另外，我在最后一步综合运用了数据库的 CRUD 操作，完成了创建测试数据的全部工作。

总结

我从测试数据创建的角度，和你分享了准备测试数据的四种方法。 其中，基于 GUI 操作生成测试数据是最原始的方法，但是效率很低，而且会引入不必要的 依赖；通过 API 调用以及数据库操作的方式生成测试数据是目前主流的做法，通过 API 调 用的方式具有数据准确度高但是创建效率较低的特点，而通过数据库的方式具有创建效率高 但是维护复杂度也高的特点。 所以，在实际项目中，业界往往会综合采用 API 和数据库的方式生成测试数据，即通过 API 调用生成基础数据，然后使用数据库的 CRUD 操作进一步生成符合特殊测试需求的数据。