接口场景设计
接口测试数据
接口数据属性
1.作用域：共享数据（适用于 testSuite 级别）、隔离数据（适用于 testCase 级别）
2.创建方式：调用开发接口、使用 Sql、独立开发数据模版
共享数据：所有 case 或一部分 case 共同使用的测试数据
优点：
数据只造一遍，运行速度快，重复工作少
缺点：
1.case数据共同，可读性降低，较难分清哪块业务之间的界限。
2.case数据共同，可能彼此之间产生干扰，如新增用户这条用例执行一半因外部因素干扰了销毁数据的闭环，下次再新增就因同样的数据已经在数据库而运行失败
3.影响链路较长，可能会因为一条数据影响了几十条用例的结果，没办法相互独立
隔离数据：每条用例的数据相互独立，都在每个case的setup 里面创建，在teardown里面销毁
优点：
用例相互独立，可维护、稳定性、可读性都大幅度提升
缺点：
每条用例都重新造一遍数据，速度变慢，若是有些共有业务的数据需要更改，维护起来也比较麻烦
我的策略： 一些基础模块用例还是用前者，其他的功能用例用后者
数据的创建方式
我的策略是直接调用开发接口来构建数据，大多数测试人员对后台数据库的构造并不熟悉，而且若出现一些变动也不好维护，稳妥起见还是调用接口构造，不建议测试人员直接写数据库造数。
单用例运行的流程如下：
而事实上，一个场景往往是通过多个接口共同完成的
举例： 购买月卡服务接口的测试场景，会涉及到登录接口---创建用户接口---月卡服务授权接口等
可以看到，为了完成最后一个接口的功能，需要前面两个接口作为我们的数据依赖。
登录接口用的公共管理员账号，这一块就会用到共享数据，不用一直频繁去变
用户接口会直接干扰到后面的授权测试，因此还是要隔离数据，让每一次运行的case相互独立
接口测试用例设计
前文中提起过，接口测试和功能测试类似，功能测试中的用例设计方法也适用于接口测试，如等价类划分、边界值、场景法等
从非功能的维度去看，就是安全、性能等角度去分析，前面提过，不再分析
接口测试工具
前面数据和用例已经有了，就到了执行环节，如何去做工具选型也是门学问。
第一阶段
以前我做一些定制产品的测试的时候，因为前后关联关系不大，现在测试的接口以后大概率也不会再去测试，属于一遍就过的产品类型，这时候怎么快怎么来，以前用的postman、jmeter比较多，尤其是jmeter，可以做接口测试，必要时候还能用来搞性能。
第二阶段
客户端工具有其局限性所在，使用不够灵活、用例庞大后维护困难等，通过写代码来测试接口很大程度上可以解决这些问题，小型项目使用python+unittest+request可以很快速的上手，考虑到再网上升复杂一点可以使用python+pytest+request来处理。在这里，如果项目复杂度上来了，就需要编写一套测试框架来增强用例的可读性和可维护性，用各类设计模式、抽离出数据、公有方法、共同业务、独立报告等
第三阶段
假如团队代码能力偏弱、涉及维护的接口业务过多，可以考虑使用平台来维护接口测试，但就目前而言，市面上的平台大多都比较难用，而且平台自身也可能有Bug,增加了一些不确定性，建议能写代码还是写代码吧
接口断言
Http Response 断言：Http 状态码、Response Body、 字段、结构 校验、Response Header
数据断言：对数据库中的数据断言
响应时间：是否满足要求