关键词：接口测试          数据的管理

一、测试数据包括哪些？

1、 背景测试数据

　　测试背景数据是被测试系统运行依赖的业务数据，可能来自于其他外围系统，背景数据通常在被测试系统中作为输入数据，业务操作只是读取操作，并不做任何修改，业务处理完成后者部分可能保持位置不动也可能被备份到其他地方。

　　背景测试数据在测试前根据测试需求进行一次性准备，并在测试前对背景数据表进行备份作为数据基线。

　　背景测试数据修改时可能影响原有测试用例和测试数据，因此背景数据要与测试数据和测试用例建立版本对应关系。

2 、系统业务测试数据

　　系统业务数据包括静态业务数据和动态业务数据，静态业务数据指业务操作中不会被修改的数据例如业务字典、业务规则等，动态业务数据是指在业务操作过程中会被生成或修改的数据，例如审批记录、审批单据等等

　　系统业务数据与测试用例紧密相关，测试用例依赖于系统业务数据。测试执行前测试用例脚本依据测试输入数据修改业务数据满足测试需求，测试业务执行完，测试脚本要读取动态业务数据验证结果正确性，在测试执行结束前通常要对修改和影响的数据进行回退。

　　业务数据于测试集合建立对应关系。

3、 测试输入数据

　　测试输入数据提供给测试脚本使用的测试数据，测试输入数据应该包括：业务触发数据、期望结果数据和配置数据等。

　　测试输入数据与测试用例是一一对应的关系，在单元测试和接口测试中采用读取Excel或者读取Database方式。

　　对特殊的输入对象数据或文件数据等，在指定目录中进行保存。通过接口方式读取这类数据。

　　测试输入数据与测试脚本建立对应关系。

二、测试数据如何造？

方法一：

1、用docker作基础数据库，维护一套标准数据

2、利用diffy的方法回流收集线上数据作为测试数据

方法二：

“通过数据库直接构造”不可取。

最好还是走流程生成，哪怕效率低一点。

提取关键流程接口，封装关键字或者方法，用例驱动部分把所有预处理操作放入before中。数据部分把每个用例分为预处理包含的数据和当前用例包含的数据。

另外，再复杂的接口能慢到哪儿去。。。对于慢的查询类或者有第三方的，mock大法祭出来

三、测试数据如何管理？

    自动化测试过程中，现在大多都默认测试脚本与测试数据分离的设计，这样做的好处是：降低维护成本，迁移成本以及提高效率。

    因此，测试数据放在哪里，如何管理，不能一概而论。个人觉得应该从以下几方面来考虑：

1、业务场景

①、比如在UI自动化测试中，需要测试某个电商网站的各个业务模块，但前提是要用户登录。这个用来执行登录的测试账号数据往往是固定的，那么专门将一组username和password放在一个测试数据文件或者测试数据库中，这样就显得太笨重，耗时费力。将其写入测试脚本或者写入配置文件，直接引用效率会更高。

②、同样，测试电商网站，账号体系分为普通账号，会员账号，会员还分很多等级，有时候为了测试会员中心不同的账号展示的信息是否不同，就需要使用不同等级的账号登录，这种场景下，可以将测试数据放在测试文件里（比如excel、csv），通过参数化的方式来循环读取，执行后续操作。

③、在API自动化测试中，比如针对restful风格的接口，它的域名相对来说都是固定的，只是不同接口的path不同，那么也可以将域名写入配置文件，测试过程中只需要将实例化的域名和path进行拼接即可，这样也省却了在测试数据文件中维护的成本，一定程度上提升了测试效率。

2、数据类型

测试数据也分不同类型，大概分为以下几种类型：

base-data：即基础数据，比如电商网站的商品信息、SKU，比如物流公司的仓储管理等，这类数据往往基数比较大，可以视为持久层，储存在DB中；

test-data：测试数据，根据业务场景不同，数据无论量级还是变更频次也不同，基于测试脚本与数据分离的概念，可放在专门的测试文件中，比如excel、csv；

ephemeral-data：临时数据，即使用一次的数据，这种类型的数据可以用临时文件存储（比如dat、csv等）格式，然后进行参数化读取，或者直接写入脚本中；

3、数据量级

①、还是电商网站的某个场景，需要先执行登录，登录的账号比如是专门配置的一个测试账号，相对固定，那么将测试账号写入测试脚本也无可厚非。

    不过，我本人不喜欢将测试数据直接写入脚本，这种情况我会写入配置文件，然后实例化调用，这种情况就需要根据个人习惯来设计，没有固定的套路；

②、数据量级在几十——几百上千之间，这种时候，可以写入excel文件进行存储管理，但是excel的局限在于其本身目前最大支持65500+行的数据存储，而且只支持单事务，如果需要多线程读取，就会变成瓶颈。

③、csv文件，结构简单、通用，可以和excel进行转换，可以减少存储文件size，且具备简单的安全性，可以在一定程度上替代excel成为数据存储文件。

　　本人目前在大多数场景下也是使用csv类型的文件进行测试数据存储管理；

④、当测试数据超过一定量级，比如性能测试中，如果要执行并发测试或者稳定性测试，那么所需测试数据量级就很大，这时使用excel或者csv就会变得很不方便。

　　无论是从维护的成本还是便捷性考虑，都应该选择利用DB或其他高效的管理方式来存储和管理测试数据；

4、使用频次

测试数据的重用频次不同，也需要选择不同的存储方式，比如：

①、once：只使用一次的测试数据，那么只需要写入临时文件，用完作废或者删除即可；

②、often：即经常使用的测试数据，应根据数据量级，使用场景，数据类型选择合适的存储管理方式；

③、alway：可以理解为base-data或者持久数据，这种类型的数据因为其本身更新频次很低，或者数据量级较大，一般存储在DB中是比较好的一种管理方案。

综上所述，测试数据的存储和管理，没有固定的套路，需要结合业务场景，使用频次，数据类型和数据量级来综合考虑，设计合理高效的方案，才是正确的方式！