关注我，让我成为你的专属小太阳吧

Hei~Guys

这里是“叨叨的软件测试分享台”

小编继续为大家讲

接口自动化测试的知识点

快眯上你的小眼睛，认真阅读吧

前言：

自动化测试，算是近几年比较火热的一个话题，当然，更是软件测试未来的一个发展趋势。未来，功能测试等非核心的测试工作，都将被外包。想要在软件测试这个行业继续前行，就必须拥有核心竞争力，掌握自动化测试技术，是必不可少的一个技能。

在《Google软件测试之道》一书中有介绍到：在Google，70%的自动化测试工作集中于单元测试，20%集中于接口测试，剩下10%才是UI测试。你悟到了吗？

虽然，我们没有Google那么完善的机制和工程师文化，没必要一切照搬Google，但Google作为互联网2.0时代最耀眼的一个公司，它的技术发展方向，流程管理等可以说是不久的将来，

我们也要到达的方向。选择适合自己的，落地应用，是当下我们应该做的。

目前国内的互联网行业，大环境来说，还处在一个快速发展，需要流程化标准化的时期，如何跟上不断变幻发展的节奏？除了不断了解接触新的东西，还需要不断学习，提升自身，以内在

的驱动力，去紧跟时代浪潮。即使做不了弄潮儿，也不能变成时代淘汰的那一批。说到这里，推荐乐搏学院的2节公开课：乐哥的《软件测试小白集训营》、《软件测试在职提升班》，都是免费的试听课，有直播课和录播课，非常鼓励大家去试听，快从课堂中Get到你的知识点。

一、接口自动化测试的"能”

接口自动化的目标：

用于项目的 API 层的 HTTP 接口的功能逻辑验证? 减少手工测试的工作（回归验证；跨模块的验证）? 实现手工验证不能做的验证（如接口涉及大量数据的排序比较）? 手工很难充分验证的功能逻辑（如接口的功能验证涉及大量的数据）

Ps：实际项目中，接口自动化的根本目的是什么？

个人认为是定时跑时，能监控接口，当接口功能失常时，可以及时发现，即发现 Bug。因此，可以使用代码覆盖率来评估接口自动化的完整性，但更重要的是发现问题。

接口自动化 Case 用例设计原则、切记：

不要为了做自动化而做自动化，做的首要目标是问题出现时，能第一时间发现；? 自动化中的代码覆盖率统计可以作为参考，但不能一开始就为了提高覆盖率，陷入 Case 设计之中；

注意：

好的接口自动化 Case 设计，依赖于 Case 设计者的功能理解程度（手工测试的功力）+ 功能覆盖点；

原则：

1.将手工测试点转换为自动化用例。Case 设计注意：验证用例通过的标准—参考一个功能点容易出问题的地方。或者说，一个用例的通过说明此功能点一定没问题；反之，一定有问题。

2.覆盖手工测试不易检查／太浪费时间的检查

比如：

一个 HTTP 接口设计大量的数据比较的时候；? 接口的 json 返回不能直接检查功能点是否正确（需要调用另一个接口的 json 来间接验证时）；? 一个接口的 json 返回需要和其他模块的接口联合” 互相验证 “（需要调用其他模块的接口的 json，两个 json 相互来验证彼此的正确性）

3.”边缘性“的功能检查 这里主要指的是回归验证。如果系统涉及边缘性的功能验证，把此类功能设计层自动化用例

4.接口验证的程度 接口的验证：即判断一个接口是否正常的标准。注意：接口参数”合理的“组合；

5.DB 数据更新检查（如果有必要）注意从接口的角度检查 DB 数据的更新：

其他系统的数据更新到待测系统 DB 中的数据；每天待测系统由于用户操作更新到 DB 中的数据；

6.接口自动化的数据准备

关于是否需要为接口自动化，特意在 DB 中准备需要的数据，适需要程度而定。原则：除非必须，否则不用准备。如果不准备数据，无法完成对接口的验证，则自己准备数据即可。

注意：一旦自己准备数据，评估对其他功能验证的影响。确保DB 中数据量和真实性（模拟的数据需要充足，并且不能和真实数据差异性过大）。

接口自动化用例定时跑：

自动化一般会选择每天定时跑。这里需要注意的一点就是定时跑的时间选择。时间选择上注意几点：

在线上跑时，注意对线上接口的影响（一般要求：线上的回归验证可以随时跑）；

如果要检查 DB 数据更新的有关逻辑，注意数据的稳定性 (如用户量少的时候)；

在测试时（非生产环境），接口涉及读，写 DB，考虑是否需要定时跑；