接口测试的相关总结—持续更新

什么平台上写接口用例？

公司基于unittest框架二次开发，提供了一个接口测试平台。

接口测试用例设计的原则？

1.业务仅涉及到单接口，针对接口的正常传参和异常传参的进行相关用例编写。

a.必传参数/必传参数+非必传参数的组合验证

b.参数长度为10个字符，长度的边界的验证

c.参数类型为int类型，错误的类型的验证

2.业务涉及到多接口，分为两个方面编写：

1)拆分多接口到一个个单接口上，可按照方法1的方法去进行用例编写

2)根据业务来写，针对各种正向业务和异常业务进行用例编写

a.主流程所有正向分支业务———适合于回归验证&持续集成

b.主流程异常分支业务

c.非主流程的正向业务

平台编写过程中踩坑总结

1)接口的输入传参需要是数组/int类型时，没有注意，传入的参数写成了string类型，导致接口一直返回报错，要一一check每个参数的数据类型

2)接口的返回值进行断言判断，除了比较code返回值以外，还需要跟数据库中的记录或者关键字进行比较。

3)需要考虑部分主流程业务相关的用例，需要持续运行，需要做好相关的数据清理工作，避免在数据库造成过多的脏数据。

4)接口的输入传参来自于数据库的时候，此时需要多多注意数据库中的字段的数据类型，且传入的时候是否满足传参的数据类型要求

5)考虑到用例的维护成本，写用例的时候可以多考虑下这两个方面：

a.传入的参数尽量通过变量传入，涉及到传入的参数需要调整的时候，比较方便，不用调整整个用例，只需要调整变量部分的值即可

b.同一个接口的用例，使用子用例的方式，不同场景下需要用到此接口的话，只需要调用这个子用例即可。使用场景：当此接口有变动的时候，不需要调整所有使用这个接口的用例，而只用调整一个子用例即可

c.一个业务下包含多个接口时，特别是有几个接口组合起来是其他场景下的前置条件，这样也可以把这几个接口组合成子用例。这样当此前置条件有变动的时候，只需调整这个子用例即可。比如发奖系统前置均需要对发奖单申请预算，而申请预算又包含几个接口，此时可以把申请预算这块当作一个场景子用例。

注：子用例包括单接口的子用例或者场景子用例，需根据业务进行划分，根据需要进行相应的编写。

6)当接口文档写的不是很规范的时候，比如注释没写等，我们可以从哪些方面辅助写接口用例(我司web侧数据交互分为两种情况)：

a.前端页面[接入层]直接与server底层进行数据交互，此时前端页面的一些接口称为接入层，可通过抓包看到接口的传参，可结合接口文档，来帮助自己写接口用例

b.前端页面[接入层]与后端页面[服务层]先进行数据交互，后端页面在与server底层进行数据交互，此时后端页面的一些接口称为服务层，此时想通过抓包去查看接口的传参是不可能的，此时只能去询问开发每个参数的具体含义

7)汇总下编写接口用例中遇到的数据传参：

a.根据参数的格式要求直接传入到接口内

b.从数据库中提取部分字段传入到接口内

c.其余接口的返回值json数据进行提取部分字段传入到接口内

d.从明文html中正则匹配出部分字段传入到接口内

e.从服务器密文的邮件内容解密后正则匹配出部分字段传入到接口内