测试数据准备和释放

测试数据存放总结：

1.对于账号密码，这种管全局的参数，可以用命令行参数，单独抽出来，写的配置文件里（如ini）

2.对于一些一次性消耗的数据，比如注册，每次注册不一样的数，可以用随机函数生成

3.对于一个接口有多组测试的参数，可以参数化，数据放yaml,text,json,excel都可以

4.对于可以反复使用的数据，比如订单的各种状态需要造数据的情况，可以放到数据库，每次数据初始化，用完后再清理

5.对于邮箱配置的一些参数，可以用ini配置文件

6.对于全部是独立的接口项目，可以用数据驱动方式，用excel/csv管理测试的接口数据

7.对于少量的静态数据，比如一个接口的测试数据，也就2-3组，可以写到py脚本的开头，十年八年都不会变更的

 

 

1、无代码型测试如Excel给出测试参数，这种方式的case通常对数据库中存留的业务数据以及当前数据状态有很强的依赖性，所以数据的变更对case的稳定性有很大的影响，而且由于自动化用例编辑器本身的限制，对于测试场景的丰富和接口返回值的验证无法做到全面、有效。

2、一个单测脚本包括准备数据过程，请求接口过程，返回值断言过程，清理数据过程。 case不多时，编写效率和执行效率都没有太大问题，当case量增多，量变引起了case编写维护效率和执行效率的质变，如何组织代码架构、增强代码可复用性、设计模式就成了挑战。

3、将数据准备或环境清除等工作抽取成关键字放到更高的层级中,，抽取时可能需要做一些组合, 但不允许出现重复的建删操作；

 

• 降级。在大流量的情况下，是否能通过一些机制让服务降级，从而保护整个系统的稳定性。举个例子，可能一般情况下，用户购买商品下一个订单就可以马上看到订单的详情，但是在秒杀场景中，用户可能在下单很长时间之后才能看到订单，这就是一种服务降级的表现。
• 削峰。把流量的高峰削平，不让突如其来的大流量对系统产生破坏性的影响。举个例子，12306抢票的时间点是分散的，大概每个小时抢一次，这就防止了一次性放出所有票导致所有用户同时抢票带来的流量高峰，这是一种业务上的削峰。
• 限流。这个很好理解。一些第三方api会限制每分钟调用的次数就是这个道理。
• 熔断。高并发时,如果一些api无法访问后，能不能自动不去访问这些有故障的api，从而保证主流程的顺畅和稳定。
• 故障摘除。一些容器如果被击垮，能不能动态去摘除这些节点，从而保证整个系统可用。

On-the -fly实时创建 缺点：耗时，out-of-box事先创建数据

生成测试数据的方法：

1、基于GUI操作生成测试数据：前端实际操作

2、通过API调用

3、通过数据库操作

4、2和3结合使用

测试数据1.0时代：将测试数据准备的相关操作封装成数据准备函数，通过api调用方式或者是数据库CRUD的方式创建准备数据。