接口测试｜接口自动化落地实践

一 接口自动化测试作用

1、提高测试（回归测试）效率、节约成本；

2、保证每次测试的一致性。自动测试具有一致性和可重复性的特点，使测试更客观，提高测试的信任度；

3、将重复的任务自动化，避免因重复劳动产生厌倦，也能让测试人员有更多精力设计更多更好的测试用例，提高测试准确性和测试人员的积极性；

4、能执行一些手动测试比较困难或手动执行成本较高的测试；

5、为了更好的持续集成和交付。

二 为什么做接口自动化测试

供应链业务，ToB的流程较多，客制化严重，主流程相似，但逻辑细节有很多分支，底层的改动影响范围难确定，只靠手工测试执行慢，且容易覆盖不全，接口自动化迫在眉睫。

如下图所示：主流程都是客户下单后经过我们系统处理下发给下游承运商（如中间主刺），但每个客户可能都存在细微逻辑差别（分支逻辑如主刺上的边刺）。

三 接口自动化落地以及迭代的过程

1、落地过程介绍：

落地其实就是想好用什么做，开始做，让做好的东西落地（后优化）执行使用的过程。

我们的落地以及优化的过程分8个部分完成（如上图）：

下面我将详细为大家解读如何以“case的持续积累”为主线，按部就班地持续优化，由量变到质变的接口自动化落地过程。

2、落地过程详细解读：

1）重要客户的用例编写：

这里分两步，一是要先选取一个“好”的框架，第二才是“花时间”去写自动化case。

a）有关自动化工具（框架）：

如果去网上搜“接口自动化”会有很多种实现方式，Junit、Phpunit、Pytest、jmeter等等很多种；

综合学习成本、持续集成、用例管理、测试报告、扩展性等多方面考虑，最终选择了Httprunner，它有如下的优点：

a.继承 Requests 的全部特性。满足HTTP(S) 接口测试的各种场景需求

b.测试用例描述方式有表现力。支持参数化、函数、以及结果提取等方式，可用简洁的方式进行各种用例描述。

c.测试用例与执行代码分离。采用YAML/JSON描述测试用例，降低用例编写及维护成本；用例转化格式后，可配合不同的执行引擎（比如Jmeter、Locust），达成不同的测试目的（性能测试）。

d.用例可以基于日常手工测试录制（后进行简单调试），避免重复开发。基于 HAR 实现接口录制和用例生成功能（har2case）。

e.测试用例分层合理（api->testcase->testsuit）。高抽象，避免一个接口改动造成大面积用例修改；高复用，便于创建复杂测试场景；方便用例的分组、按需执行。

f.支持测试用例和测试数据分离。避免等价类等场景需要构建重复用例；同时方便构建海量性能测试数据。

g.测试结果统计报告简洁、清晰、详尽；方便进行结果查看和问题定位。

h.高扩展性。能够轻松实现二次开发、Web平台化、Jenkins等持续集成工具对接（采用CLI调用）、自定义报告模板等。

另外该框架是开源的，社区资源比较充足，已经有很多人关注、应用以及维护，会持续迭代，可参考的资料多，有问题可以快速找到解决方案。QA横向也拉齐了公司的各业务线都使用该框架。

b）case积累：

确定好框架，第二步就是编写自动化case，需要的就是时间了。因为学习成本较低，前期熟悉下httprunner就可以上手去写并调试，在写case的过程中再不断的深入学习，不断积累case的同时对框架本身也有足够的了解了。

当前，写case是要有规划的，因为需要在高度迭代的项目中间争取时间去完成，而且对接的上下游系统较多，不同的交互方式、不同的传输协议，调试起来相对还是比较麻烦的。所以我们优先完成了订单通用流程以及重点客户流程的case编写。

具体到写某个case呢，除了场景设计的合理全面外，还要考虑以下几点：

a.校验（断言）一定要细致，错误的例子就是只断言到http应答码是200，正确且完美的case一定是像手工测试一样，需要对是否已经落到存储且存储的值是否正确做好校验的；

b.case的健壮性，不能总是失败，花很多时间去看为什么失败，比如：异步流程写入稍微慢，断言时查不到数据或状态还未更新，影响到case的结果，可以多sleep几秒或者改为查库做断言；

付出是有回报的，自完成自动化的case积累后，我们线上重要客户没有在出现过问题。另外当你遇到原来上线前需要大量时间手动回归的场景，只需要一行命令就搞定的时候，就更能发现收益有多大了，特别是发现问题的时候。

2）Mock服务参数校验：

首先说一下为什么要做这个校验（我们把与被测系统有rpc交互的系统服务全部以mock服务替换掉了），因为mock服务是接口级别的假服务（没有逻辑判断），无论调用mock服务时传的是正确或者错误的数据，返回值都是我们设定好的固定的值，所以使用mock服务会缺失对被测系统逻辑处理后向下游传值是否正确的校验。举个例子：

针对以上情况，我们做了如下图的改造，通过调用时传入logid，将调用mock服务的参数写入redis中，key为logid+url，然后再通过自动化程序使用该key对调用mock服务的参数做查询，将查询到的结果与预期做比较，以完成对mock服务（下游服务）的校验。

这里可能会有人有疑问，为什么不能直接调用真实的下游系统，而要选择mock。使用mock首先是为了避免写数据的场景对下游服务产生影响，因为测试的都是假数据（我们未来还需要在线上跑），第二就是mock服务相对于真实的服务来说比较稳定，是我们自己掌控的，使用mock不会因为下游服务不稳定而影响到自动化的稳定性。

3）定时巡检：

接入Jenkins，通过配置对线上服务代码做定时的巡检（定时触发job），同时可验证到case的稳定性。

4）被测环境稳定性：

因为要对“线上”服务做巡检，所以要保持代码和数据库表结构的一致性；

因为碰到过旧版本pusher长时间运行时有goroutine泄露的问题，所以要定期重启pusher；

因为mock服务会因为线下机器资源不足自己挂掉问题，所以需要检查mock服务是否健康，不在了则拉起；

因为要长期定时运行，日志会越来越多，需要清理；

所以，增加了一些脚本，通过ct任务来定期做上面提到的各种解决问题的操作，以保障被测服务的稳定。

5）执行时间优化：

有了以上，第一期的工作基本完成，剩下的就是持续不断的积累和优化case。在case不断增多的过程中，暴漏了一个新的问题–“执行时间”，随着case的增多执行时间会越来越长，特别是一些业务逻辑是通过异步mq（有的场景，一个请求出发N个mq），想要校验数据需要sleep较长时间才能做到有效校验，串行跑case显然会有很大问题。比如，上线前执行，如果比较紧急，自动化执行需要半个小时甚至一个小时的时间，这样就会比较“尴尬”。

为了解决该问题，我们做了如下优化：

1、通过脚本控制case可以并行执行，但并行执行会生成N个httprunner的结果报告，不好统计展示，所以又引起allure做报告的聚合。

2、增加db工具类，将通过接口查询获取数据的地方改为直接查询数据库，减少case中的sleep时间；

3、支持直接脚本调用，避免等待ct任务定时执行，更灵活

最终我们将case的执行时间从15分钟以上，降低到3分钟左右（如图为allure的结果截图，30种场景，300+的case执行只需要3分多钟）；

6）服务化，研发“自助”：

为了支持研发自测、提测准入执行，新增job，让研发可以通过输入相关的内容，点击开始构建，即可构建开始触发自动化：

需要输入以下内容，其他无需关注：

1）tapdurl  →  需求链接（多个关联需求可只写一个，没有可写明“备注：无”）

 2）models → 代码模块

3) test_branch → 代码分支（每个需求的提测分支，后端模块分支名需统一命名）

4）project_level → 选择C、D级项目

代码的更新是通过在被测服务器上的脚本控制更新的（并且对rpcconf模块做了特殊处理，因为需要保持调用mock服务，要保证不被覆盖掉）；

自动化执行结果会以企业微信消息的方式通知到构建者、QA、相关方向负责人；

7）优化消息通道：

大家看到上面的执行结果通知，当前只能通过查看通知详情中的成功、失败的case数判断自动化是否全部通过的，定时巡检24小时都在进行，所以会有每天会有很多通知，需要每次点开关注是否有失败，容易“降低关注度”，所以我们做了消息通知通道的优化，将成功与失败的分开；

成功的通知（QA-msg通道）：

失败的通知（AutoTest-Alarm通道）：

8）打通上线系统：

人为限制研发执行难度大，只有接入流水线，通过系统限制才能达到强制执行的效果。提供合理可行的方案，配合op、inf、qad共同完成与上线系统的打通。

至此，我们完成能够支持研发阶段研发自测、提测准入，测试阶段快速回归验证，上线时通过系统卡点，上线后对服务定时巡检的全流程覆盖的自动化体系建设。

注：

a）服务巡检

通过jenkins定时触发自动化程序，在线下环境，定时对服务接口及服务的可用性做巡检；

b）上线流程卡点

C、D级项目上线前，都需要在部署完预期要上线的代码分支后执行执行自动化，自动化通过后才能继续下一步上线操作，不通过则阻断流程；

c）提测准入

提测前需要手动执行自动化case，通过后才能进行提测（提测申请中需要附上自动化执行结果的截图）；

四 未来规划与总结

1、回归新功能使用

测试前完成编写，测试中调整，上线前可用于回归新功能使用。（这对整个团队都有很大的挑战，需要尽量保证定义好的接口协议在开发过程中没有变动；测试人员需要相对多的测试时间去调试case；）

2、线上(任意)环境执行

影子标+mock方案落地：达到一套自动化代码&数据在任何环境或服务上都可执行的效果。

影子链路，数据库、rpc调用的conf配置，全部配置为mock服务和影子库。

自动化是一个不断积累完善的过程，需要随着业务的变化同步做变更，随着case的不断积累优化，收益会越来越大，当然面对的挑战也会越来越大，要保证case的合理性、准确性、稳定性。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：【文末自行领取】

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！