测试数据简述
灵魂拷问之什么是测试数据呢？也许你会毫不犹豫地说，测试数据不就是我们每天用于做测试的数据吗？这种说法过于笼统。其实，测试数据指的是跟测试有关的数据，它可以分为以下几类。
1. 测试请求数据
测试请求数据，就是我们常常理解的测试数据。这部分数据是测试用例执行的必要输入（这里的测试用例是指自动化测试用例，通常以测试脚本的形式存在）。
它可以是直接耦合在测试用例里的，也可以是放在外部文件。放在外部文件的情况，即我们前几期推文里提到的，测试数据可以存储在 JSON、YAML、TXT、Excel File(xlsx)、CSV、SQL 文件，甚至 .py 文件中。
这部分测试数据的使用，通过前期的分享，我想大家应该不再陌生了。对于测试请求数据，也分为以下两种情况。
强制数据
发送请求时必须携带的数据即强制数据，例如：
在 UI 自动化测试中提交表单，那些你不填写就无法提交表单的数据；
在 API 自动化测试中，那些你在请求时必须携带的参数和数据，否则发送请求就会报错。
非强制数据
发送请求时非强制携带的数据即非强制数据，例如：
在 UI 自动化测试中提交表单，那些不填写也可以提交表单的数据；
在 API 自动化测试中，那些你在请求时不携带，发送请求也不会报错的参数和数据。
2. 测试期望数据
测试期望数据，通常用作跟测试后产生的结果数据进行比较的数据。这部分数据，常常是伴随着断言函数存在。
用于判定根据测试请求数据生成的测试结果数据，是否跟测试期望数据相同。如果相同，则说明业务行为符合预期；不相同，则说明业务行为跟需求不一致，可能存在Bug。
3. 测试结果数据
即经过测试请求数据的输入，系统产生的结果数据，这部分数据也分为两种情况：
单纯的结果数据
指未经分析、聚合的数据。例如：某一个测试用例的结果数据。它们的作用常常是用来与用户提供的测试期望数据进行比较，来验证业务的正确性。
聚合的结果数据
聚合的结果数据，通常指测试报告。通过把单纯的结果数据聚合，可以使聚合的结果数据告诉我们更多关于系统质量的信息。
例如：在一次测试后，测试报告可以告诉我们，有多少条测试用例成功，有多少条测试用例失败， 测试失败的用例属于哪个模块等问题。
通过多次测试报告的对比，我们可以看出哪个测试模块经常出问题，哪个模块基本稳定，哪个模块的性能又下降了等问题，通过分析聚合数据有助于完善我们的测试策略。
测试请求数据的准备方式
测试请求数据准备在自动化测试中常常会耗费较多的时间，如何有效地准备测试数据，其实是一个没有标准答案的命题。这里根据以往我的项目经验，列出常用的几种数据准备方式，仅供参考。
1.根据业务规则手工创建
这个是目前最简单的一种方式，由测试人员直接提供测试请求数据，包括强制数据和非强制数据。通过直接提供给测试方法或者使用外部文件保存测试请求数据。外部文件保存的测试请求数据在测试进行时，通过数据驱动逐个读取并应用到测试用例（测试脚本）。
手工创建的测试请求数据有一个缺点，即测试请求数据永远不会变化，这个不符合正常的用户使用情况。
2. 使用第三方 fake data 库自动生成
为了更好地模拟正常用户的使用情况，可以使用第三方 fake data，例如 python 中常用的 faker库。通过调用这些 fake data 的库，可以生成更接近正常用户使用的测试数据。
但这种数据一般仅限创建数据时使用。比如注册，填写反馈表单的情况。对于查询型数据，则不适用，因为查询型数据，通常要求数据已经存在系统数据库中。
3. 通过 SQL 查询得出的数据文件
通过 SQL 查询获取测试请求数据的方式是比较常用的方式。一般这种方式适用于一个请求数据的请求本身，来自不同业务的输出的情况。
例如：测试商品扣款接口，那么这个接口的输入必须要有用户 id、商品 id、商品价格、用户余额等参数，而这些参数由一个或多个服务提供。所以使用 SQL 语句组合查询是比较快捷的一种方式。
通过SQL语句查询得出测试数据，如果 join 的表过多，会存在数据生成效率问题。
4. 根据测试平台自动生成数据
数据构造平台（Data platform）是最近几年比较流行的一个数据生成解决方法，它综合了以上几种数据生产的方式，通过提供统一的接口，使用户可以方便地生成测试数据，而不必关心数据是如何生成的，但数据构造平台的构建需要测试团队有一定的开发架构能力。
5. 拷贝自生产环境
通过拷贝生产环境的流量，用于测试环境测试。这个方式常见于性能测试中，通过拷贝线上流量到测试环境的方式来构造测试数据。在大数据测试过程中，有的公司为节约成本或使测试数据更接近于实际用户使用场景数据，也会直接从生产环境拷贝到测试环境。
常见的解决方案有 TcpCopy、goreplay 等。此方式对测试团队的架构能力、代码开发能力有比较高的要求，往往还需要开发团队的配合甚至主导，一般通过公司内部专门组建攻坚项目的方式实行。
测试请求数据的准备时机
关于在测试的哪个阶段去创建测试请求数据，在行业内通常有以下两种方式。
1. 在测试运行前准备
在测试运行前准备，即测试数据是硬编码(hard code)的形式存在。可以直接硬编码(hard code)在测试方法里，也可以是写在各种格式的数据文件中。像上面提及的根据业务规则手工创建测试数据，就是测试运行前准备的最好示例。
2. 在测试运行时准备
在测试运行时准备，指不事先指定测试数据，即测试代码中无测试数据文件。测试数据是通过在测试运行时，先行通过调用数据构造平台或者通过组合查询 DB 的方式，直接生成测试用例要求的测试数据，然后再开始测试。
关于测试数据要在何时准备，目前并没有统一的结论，也无所谓好坏，你可以根据自身情况自由选择。
测试请求数据存在的问题及应对方法
当前，无论是以什么方式准备数据，无论采用何种时机生成测试请求数据，测试请求数据都可能会有如下的问题：
1. 测试数据过期
这种情况常见于测试请求数据事先准备的情况。例如：有一组数据是用于优惠券的扣除，但通常优惠券都有有效期。在优惠券过期之后，使用这组数据进行测试，必然导致测试失败。所以对于事先准备的测试请求数据，必须要定期维护。
2. 多次运行导致测试结果不同
这种情况也常因为数据是提前准备的而发生。例如：提供了一组测试数据用于用户注册，当第一次测试运行时，测试会正常通过，但是第二次测试会由于用户已存在而导致测试失败。
对于测试的过程中需要进行写 DB 操作的情况，最好在测试结束后做 tear down 操作，使系统恢复测试前的状态。
3. 环境切换导致测试数据不可用
通常情况下，一个产品的发布，必然要经过几个测试环境的测试。例如，开发环境、测试环境、集成测试环境、预生产环境、生产环境等。每个环境的测试数据可能不尽相同，切换环境必须保证测试数据可用。
对于环境切换导致测试数据不可用的问题，可通过如下两个方式解决：
保证每个测试环境用同一套数据
此种方式比较烦琐，适用于新项目。给每一个测试环境创建相同的测试数据，避免因测试环境切换导致测试错误。
测试框架具备切换测试环境，自动化查找相应环境数据的能力
这个方式比较常见，不同的测试环境可以有不同的测试数据。测试框架具备切换测试环境后，自动挂载相应测试环境的测试数据的能力。
4. 测试数据在测试运行中被更改
测试数据可能在测试中被动态更改。比如用户的余额存在数据库中，而测试数据是在测试运行时候生成的。即测试运行时去查询获取用户余额才发现用户余额不足。
对于这种情况，通常需要更改测试数据生成的条件，即把查询语句写得更健壮，确保获取到的用户一定是有余额的。或者加条件判断，如果发现没有余额，则调用另外的服务给用户充值。
5. 并发运行导致测试数据不可用
并发运行测试用例，或者多个人同时运行同一条测试用例，可能会导致多个测试用例共同操作同一组数据。这样可能导致测试失败（例如：不同的人拿同一条测试数据进行注册操作）。
对于这种情况，可以编码允许测试框架支持并发运行时使用同一个数据文件，但是这样通常投入较多。为了避免投入太多开发精力，大多数情况会采用多个类支持并发，一个类下面的测试用例顺序执行的方式来避免同一个测试类下的测试用例，同时访问同一个测试数据。
总结
今天分享的是测试请求数据在测试运行中的常见问题。细心的你可能会发现，这些问题虽然各有各的解决方法，但都有一个共性，那就是这些问题的出现，都是由于缺乏测试数据管理才出现的。
欢迎关注【无量测试之道】公众号，回复【领取资源】
Python编程学习资源干货、
Python+Appium框架APP的UI自动化、
Python+Selenium框架Web的UI自动化、
Python+Unittest框架API自动化、
资源和代码 免费送啦~
文章下方有公众号二维码，可直接微信扫一扫关注即可。
备注：我的个人公众号已正式开通，致力于测试技术的分享，包含：大数据测试、功能测试，测试开发，API接口自动化、测试运维、UI自动化测试等，微信搜索公众号：“无量测试之道”，或扫描下方二维码：
添加关注，让我们一起共同成长！