如何写好接口自动化测试脚本(1)，2024年最新程序员去大公司面试

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

当我们明确好测试目标后，再开始编写测试用例，会有更针对性的去设计测试数据和接口组合。接下来的问题是什么呢？去哪里确认你的接口信息是有效的？基本上有两种路径：

接口文档：开发人员都不喜欢自己写文档，同时也很讨厌别人不写文档。所以测试人员如何获取一份真实有效的接口文档是件比较麻烦的事。一般团队内都会有一个统一的接口文档管理工具（如果没有，就找开发多磨麿，让他们弄个，并不难），我们需要关注接口文档的有效性和及时性。现在也有很多的插件或者工具能够帮助研发人员自动生成接口文档，例如Swaager、apidoc等等。
接口抓包：如果什么都没有，那就自力更生，通过Fiddler之类的工具，通过抓包分析的方式来获取接口，这类的场景如果较多的话，可以把Fiddler抓到的接口导出，然后写个小程序，直接转成接口平台可以识别的脚本，效率会更高一些。
在获取到接口信息后，需要与开发人员多交流，明确参数的意义及来源，以便我们针对性的做测试用例设计，这个环节不要过多的自己猜（很多测试人员经常会自己猜想），直接找开发问就好了。在这个接段，还要梳理并区分接口的重要程度和优先级。这样就可以确认哪些接口优先设计用例，哪些接口可以先放放，在有限制的时间内，做最大价值的事。

3、一些基本原则

拿到接口后，明确了参数说明，结合测试目标，我们就可以开始设计并编写测试用例了。区别于功能测试用例，接口测试用例（脚本）一些原则需要注意：

自动化：好像是废话，所有的用例应该是非交互试，最常见的就是Token之类的生成，需自动处理好（我见过每次执行用例前，需要自己手动生成Token再粘贴进去的脚本，特别是分环境执行的时候）。
独立性：每个用例应该是独立的，没有依赖的。需要在一个用例里处理好前置条件，而不是多个用例相互依赖。
可重复：用例测试可重复执行，所以需要注意参数的生成方式。
可持续性：如果代码修改导致已有接口测试执行失败，必须修复代码问题或者测试代码逻辑。
4、断言那些事

在设计测试用例时，还需要关注的是针对断言的设计，好的断言能够帮助我们发现问题，没有断言的用例（脚本）就是耍流氓，完全没有意义。个人在审核脚本时，会重点关注这个（很多测试人员为了数据好看，或者因为是事后补写，所以断言写的非常简单，这类脚本其实都是在做无用功，纯粹是为了KPI）。

从接口层面看，我们至少需要验证两点：

数据结构验证：验证接口返回的数据结构是否与事先定义的一样。调用方在处理数据时，肯定是根据事先定义好的数据结构来解析数据的，如果数据结构发生变化，那对调用方来说，是灾难性的（契约测试考虑下）。
核心数值的验证：根据业务场景的不同，可以有目的性的验证某些key的值是否与预期的一样，可以结合数据库查询的方式来验证（不同的自动化测试框架有不同的实现方式）。这个就比较依赖测试人员对业务的了解。根据实际情况灵活的设计验证点。
除了以上两点外，还有一些额外的验证点在需要的时候可以进行，如涉及到其它方的数据流转、返回的URL是否可被访问，返回的数据是否真的是必要的（这点很重要，过多的返回会导致很多意外的问题），等等。根据实际情况进行补充。

这样，通过一系列的方法设计出来的接口用例，才会有一定的业务价值，能够真正的帮助到团队，提升测试效率，对于这样的测试脚本，全部PASS的结果才会让人安心。（你能想象没有断言的脚本全部PASS，你还放心的么）

5、脚本的后期维护

测试用例（脚本）编写完成后，并不意味着接口测试的成完。在其它的测试环节中，如果发现因为接口问题而产生的BUG（如响应异常、无数据返回等情况），我们需要适当的补充到接口用例中，避免类似的情况再次发生而我们没有验证到。在积累到一定高质量的用例（脚本）后，可以进一步挖掘这些东西的价值，如转化成线上业务监控的脚本，转换成精准测试的依据等。还有更高端的玩法，是借助混沌测试的思路，独立拉个分支，故意修改一些异常出来，让测试用例验证，能否发现这些BUG，以验证测试用例的有效性。如果不能发现，那就需要我们去思考如何改进测试脚本（业内已经有类似的平台出现了）。

6、关于测试数据的准备

多聊下测试数据准备的事，这其实是接口测试中很重要的一个环节，想要脚本可以在多个环境中运行，那么测试数据就不能写的太死，需要根据环境去自动获取一些数据值。针对测试数据的准备，一般的玩法也有三类：

公共参数：通过不同作用域及标识的区分，有个专门的文件来处理一些共用数据的存放，例如不同环境下的用户名。
数据集合：通过特定的API或者SQL事先生成所需要的数据，然后放到一个指定的集合（参数或者文件都可以）中，在需要的时候，从这里获取对应的数据值。
数据模板：这个是数据集合的升级版，根据业务数据流，只需要填写一些简单的信息，就可以自动生成一整套的业务数据（例如个人做过的，通过基础的学校信息，就自动生成一套针对性的数据，包含学校、班级、学科、学生等整套的数据）。

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

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**