什么是完整的接口自动化测试

在工作中常说的"接口测试",一般说的是一个完整的实施方案。包括：

测试数据的准备

测试脚本的开发

测试执行

测试结果分析汇报

测试集的维护优化

那么现在聚焦到“接口脚本的开发”。

首先要了解如何用手工方式进行。在这个基础上，掌握接口测试思路。

继而引入工具（例如fiddler、postman等）

引入代码，编写测试项目（框架）

持续优化为测试框架引入各种功能（AI生成case、可视化方案、线上巡检/监控。。。）

真实项目里怎么开始

对于接口测试阶段来说，一个理想的开始，就是从完美的接口文档开始的。它应该有以下几个特性：

开发工程师在设计和开发接口的过程中，就在不断维护和更新接口文档

它包含了每一个接口的访问方式、访问路由、输入参数含义、返回参数含义，以及一个完整的例子

但是很多时候，我们没有没有获得足够的资料，那么开始接口测试前。就需要先做一些工作，把以上元素整理出来。

举例：

假设我们的码同学商城，现在需要进行接口测试。但是目前没有接口文档，开发也是新接手项目。这时候我们可以使用fiddler来观察请求，结合业务和前端输入就能得到一份接口文档

分析：

该接口传输的参数，发现正好和前端输入匹配

接口名称有"user\login"的字样，显然和登录业务是相关的

接口响应中，有信息“登录成功”匹配我们前端做的登录操作

进一步的：

1.需要搞清楚参数的来源和意义

​ 例子中有2个参数‘accounts’和‘pwd’

​ 两个参数的来源是前端输入

​ 根据“登录”业务的特性，两个参数应该存在一下几种情况：

​ 用户名：已注册、未注册、已注销、黑名单等状态

​ 密码：正确密码、错误密码、为空、特殊字符

​ 登录业务往往涉及了“状态保存”，那么cookie、token、session可能会在该接口产生

2.要确定响应信息的含义

​ 这里的响应信息中，'msg'写了‘登录成功’。这可以作为检查点。

​ code的值具体代表了什么？是请求成功，还是指登录成功。一般来说，根据code不同。会对应不同的后续业务（例如code：-1， code：0），针对这需要补充哪些case

​ data字段一般对杨具体数据，目前看是空的。它又会对应什么逻辑

​ 我们的业务是否对登录操作记录，记录这里的那几个字段？

小结：

现在，假设我们没有任何附加需求和资料。只针对单一接口来设计case，

从业务维度：

保证这个接口可以按照需求，返回出信息

可以正确处理传入的参数

可以兼容不同形式的入参（对于中间服务很重要）

可以的绝传入非正确的参数，并且给出合理、友好的提示

抛开业务我们还可以从以下角度设计case

• 可靠性：参数容错、异常状态修复、CAP（分布式系统一致性）
• 功能性：业务功能、幂等（多次及并发调用结果一致）、事务测试、共享数据线程安全
• 易用性：设计风格、错误提示（不返回代码异常）、文档友好性
• 单接口性能：并发响应时间、非并发响应时间

*如果资源充分，我们可以尽量发散设计最够多的case

3.业务流测试（多接口串联）

工作之中的大部分的测试场景中，我们需要串行多个接口，才能完成一个完整的业务逻辑。多个接口之间的：

业务逻辑

通过数据传递

业务容错

都是需要我们进行case覆盖的点，尤其在多接口串联的场景下。我们更关心每个参数，是否对业务链上的其他有影响

总结

接口测试的执行方式、设计思维都和业务测试并不完全一致

交集部分

是它们都会涉及到业务逻辑测试

是站在我们系统的角度来进行测试

差异部分

更加关注业务中的数据流转

单接口测试需要严格检查，参数、逻辑边界

业务流测试着重考虑业务正向流程