如何做好接口自动化测试？

前言

接口自动化测试常用框架：Python+requests+pytest+yaml+alluer+Jenkins；

接口自动化测试的目的？

自动化测试的主要目的是用来回归测试的，当代码有变化时，有可能影响不应该变化的逻辑，这个时候为了确认这种情况，就需要进行回归测试。

有时候回归测试的范围比较大，如果全由人工的测试，一次两次还可以接受，如果每次都这样做，人力成本不说，反反复复执行相同测试用例的测试人员也会抱怨。

通过接口自动化测试可以实现手工测试不容易做的验证，比如验证接口中大量数据的排序，多字段的比较，如果都通过手工来做，效率问题不可接受。

手工很难充分验证的功能逻辑，一些异常、极限的场景，通过手工很难构造，此时如果我们了解接口的内部逻辑，通过使用脚本有目的的构造这样的场景来触发接口的内部逻辑，从而对这些逻辑进行验证测试，相对来说是很容易的。

采用定时的针对线上接口的自动化测试，能启动一定的监控作用，当接口功能出现问题时，通过定时的巡检测试就可以及时发现。

需要掌握的技能

首先就是对于业务要有相当程度的理解，如果要设计好的接口自动化测试用例，一定要对业务有着深刻的理解，因为接口自动化的前期会有一定的投入，如果我们可以将有限的投入聚焦业务中的核心功能点，会有事半功倍的效果。

其次是拥有设计功能测试用例所用到的测试设计基本功，自动化测试和功能测试一样，同样不可穷举、不能做到足够的充分测试，那么就需要经过一定的测试分析，来选择最有效的测试用例。

最后是有一些代码能力，架构设计能力。

同时，我也为大家准备了一份软件测试视频教程（含面试、接口、自动化、性能测试等），就在下方，需要的可以直接去观看，也可以直接点击文末小卡片免费领取资料文档

软件测试视频教程观看处：

需要注意什么？

由于开展接口自动化测试有一定的成本，所以编写接口自动化测试用例，实际上要有一个权衡的。

如果测试用例写得很细，我们测试了接口中每个功能点甚至是每一条分支路径都有涵盖，那么就会特别依赖被测代码的逻辑，如果被测代码逻辑稍微有点变化，测试用例可能就会执行失败。

如果我们的测试用例验证的内容没那么细的话，那有可能即使被测代码逻辑有变动，但是测试用例执行不容易失败，这时就有可能遗漏由于代码变动产生的真的bug。

所以开展自动化测试要找到一个平衡点，尤其是要注意和其他层面的测试相互配合，比如单元测试、UI自动化测试、人工测试等。

我们可以事先定义出一套分层测试的规范，即哪些逻辑应该有接口自动化测试保证，哪些逻辑要由UI自动化测试保证，哪些逻辑要由人工测试保证。我们在进行不同层面的测试时，就能互相配合，达到一个较高的测试覆盖率。

这个规范没有统一的标准，也是根据自己团队的实际业务、资源、人力等因素来设定的。

最后，接口自动化测试用例其实也是有生命周期的，从产生到修改、再到废弃。自动化测试用例只要在生命周期内才能发挥价值，所以我们要尽可能的延长它的生命周期，还要尽可能的降低case的产生成本和修改成本，所以整个自动化测试用例就要进行管理。

说到管理，我们就不得不谈谈度量了。关于自动化测试的度量指标列举了一些供大家参考：

case总数量；
case变更量；
代码覆盖率；
投入人力；
单个/所有case执行次数；
单个/所有case发现问题数；
人工参与的回归测试投入情况；

当我们开展自动化测试时，就需要通过分析上述指标，以及这些指标一段时间内的趋势，来调整自动化测试方案和策略。

总结

PS：这里分享一套软件测试的自学教程合集。对于在测试行业发展的小伙伴们来说应该会很有帮助。除了基础入门的资源，博主也收集不少进阶自动化的资源，从理论到实战，知行合一才能真正的掌握。全套内容已经打包到网盘，内容总量接近100个G。

☑ 240集-零基础到精通全套视频课程
☑ [课件+源码]-完整配套的教程
☑ 18套-测试实战项目源码
☑ 37套-测试工具软件包
☑ 268道-真实面试题
☑ 200个模板-面试简历模板、测试方案模板、软件测试报告模板、测试分析模版、测试计划模板、性能测试报告、性能测试报告、性能测试脚本用例模板（信息完整）

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。