接口自动化用例设计总结

序言

这篇文章主要是接口测试时如果去完善的设计用例，达到不漏测，提升产品质量。

接口常见得bug：
1）传入不合规参数，导致程序crash；
2）数据类型溢出，导致数据读出和写入不一致；
3）因对象权限未进行校验，可以访问其他用户敏感信息；
4）状态处理不当，导致逻辑出现错乱；
5）逻辑校验不完善，可以利用漏洞获取非法利益；

1. 功能测试

1.1 正常场景

1.1.1 有效等价类 + 边界值

1）边界值：可以在有效范围内取上点和内点，如：取值区间在（-99，99】之间，可以取-98，0，99。边界值包含：取值范围和长度，数量类型的边界值。
2) 数据类型：有些参数可能规定了是int，也可以传null、或者str，这里包括传参和返回值
3）返回值：内容校验
4）默认值：默认值可以全部设置默认值，要测时再修改

1.1.2 遍历法

1）对有效范围内得值进行遍历。
2）对不同的请求类型遍历：一般有post\get\put\delete
3) 请求体的类型

1.2 异常场景

1.2.1 无效等价类 + 边界值

1）边界值：可以在有效范围内取离点，如：取值区间在（-99，99】之间，可以取-99，100。边界值包含：取值范围和长度，数量类型的边界值。
2）必填值：必填值为空、缺失
3）非必填值：非必填值为空、缺失
4）key错误：如username变成user
5) 数据类型：规定int传str，这里包括传参和返回值
6）返回值：除了状态码，错误场景下可能回返回错误原因。
7）传参类型：一般都是json，如果不是json呢？或者json内嵌套list有格式错误，如：{“node_list”: [“a”,],},明明后面没有内容了，却多加了一个逗号，这种有些语言是分辨不出来的。
8）默认值：有些默认值时变动的，比如分页，可能必须是10，20 。。。，可以尝试一下其他值

1.2.2 特殊值

一般是0或负数

2. 逻辑业务

1）业务依赖：
场景一：所有的接口都依赖登录
2）业务逻辑
场景一：增删改的操作后需要验证结果，一般可能会有接口查询任务进度，或者列表可查询
3）异常测试
- - 参数异常
关键字：将参数改为开发语言中的关键字
参数多或少：去掉某个参数，或者多传了某个没有的参数，一般开发不会对多出的不必要参数进行校验
错误参数：比如将username参数写为了user等看是否能返回相应的error?code
- - 数据异常
关键字数据：将参数的值填为开发语言中的关键字
数据为空：将参数的额值填为空
长度不一致：因为数据库中每个字段都设置有字段长度，填写不符合的长度进行验证
错误数据：就是将参数的值任意填写，或填写不存在的数值
4）针对逻辑设计
约束条件分析：
数值限制：分数限制，金币限制，等级限制等（满足条件才可以执行）
状态限制：需要先登录等（同步信息等）
关系限制：绑定的关系，好友关系等
权限限制：管理员等
风险：约束条件判断不足，用户可以特殊手段获利等

操作对象分析：
操作通常是针对对象的，针对合法和不合法对象进行操作，后台处理会如何
风险：用户可以非权限的操作

状态转换分析：
被测逻辑抽象成状态机，各个状态之间根据各功能逻辑切换，如果打乱这个顺序，跳转操作，就会有逻辑问题，验证正确性
风险：通过特殊手段达到原本不能的状态，从而获利等

时序分析：
在一些复杂的活动中，一个活动是由一系列动作按照指定顺序进行的，只有按照顺序依次执行完成，才能得到预期结果。正常的流程里，动作依次按序执行，不会打乱，但在接口测试时，需要考虑如果不按时序执行，是否会有问题。

例如：客户端数据同步是由客户端触发执行的，期间用户无法干预。功能测试的时候见到的就是，是否能正常同步，进一步拆解，同步流程就是一些列动作。

例如：获取用户信息，发起请求，后台返回登录信息，本地在上传本地数据，后台校验数据，生成diff和对应新增号，返回增量数据及编号，本地在上报冲突，后台处理冲突，返回客户端同步完成的信息。

接口需要依次调用才可以同步完成，但是接口测试的时候就可以测试打乱这个顺序的执行情况，是否异常等。
风险：非顺序执行后，数据出现异常，可能还有其他程序问题

针对输出设计：
针对输出结果：正确结果可能只有一个，但是错误的情况很多。可以根据返回结果列表或者类型，进行用例设计。

风险：
错误前端处理不足，导致前端异常；
错误提示处理不当，用户看到晦涩的程序码；
错误提示不当，用户不知道哪出现问题，如何解决

接口超时：
接口正常情况下是有返回的，如果接受不到返回呢？接口超时处理也是需要考虑的部分，如果处理不当，造成整个流程阻塞，超时后又接收到返回值，导致逻辑错乱。

其他测试合计：
已废弃接口测试：
废弃的接口，存在没有及时删除的情况，需要做好相关废弃接口的检查，以免出现问题。

接口设计合理性分析：
以下几个方面分析：
接口字段是否冗余；
接口是否冗余；
接口是否返回了调用方期望得到的信息；
接口定义是否可满足所有的调用需求；
接口定义调用是否方便；

5）补充
重复提交，并发测试，分布式测试（负载均衡测试），环境异常测试，大数据量测试

3.性能测试

1）响应时间
2）吞吐量
3）并发用户数
4）占用内存，CPU等

4. 安全测试

敏感信息是否加密
必要参数是否后端也进行校验（现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证）
接口是否防恶意请求（SQL注入）
cookie：就是将header中的cookie修改或删除后看是否能返回相应的error?code
header：就是删除或修改header中部分参数的值，看是否能返回相应的error code
唯一识别码：删除修改唯一识别码测试

5. 环境清理

不管进行什么操作都要考虑会不会影响环境，或影响其他用例的执行，所以恢复环境是重中之重。

6.实战经验

1）查询类接口，很多涉及id,id其实也是有取值范围的，一般id都是主键，取值是大于0
2)异步接口同任务压测报错，原因是超时，后端读取异常。
3）查询类接口，一般列表都会有id，一般人思维都是从1开始排序，所以如果有字段是查询的页数和个数，是不是想着第1页，1页10个，就是id1~10呢？
经验：如果你是这么想的就错了，看看页面上的查询列表，是不是最新的数据才会展示在第一页，所以这是个思维误区。