---

前言

1、为什么要做接口测试？

1）现在很多系统前后端架构是分离的，因为不同端（前段，后端）的工作进度不一样，所以我们要针对最开始出来的接口，以及需要调用其他公司的（银行，支付宝，微信，qq等）一些接口进行接口测试及验证数据，从安全层面来说，

只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。在这种情况下就需要从接口层面进行验证。

前后端传输、日志打印等信息是否加密传输也是需

要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

2）如今系统越来越复杂，传统的靠前端测试已经大大降低了效率，而且现在我们都推崇测试前移也叫测试左移，希望测试能更早的介入测试，那接口测试就是一种及早介入的方式。

例如传统测试，你是不是得等前后端都完成你才能进行测试，才能进行自动化代码编写。

而如果是接口测试，只需要前后端定义好接口，那这时自动化就可以介入编写接口自动化测试代码，手工测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。

接口将前端和后端进行很好的分离，帮前后端实现数据交互，这样在项目初期就可以和前端工程师讨论需要的后端数据，然后后端根据需求开发后接口，将数据返回给前端，测试人员提前进入测试接口，前后端然后在各自开发自己模块。

项目迁移，以及后期维护，接口带来的便利性，试想一下，如果没有项目交付以后，后端人员将数据库的某个字段的长度、类型修改后发版，而由于某些原因没有及时通知前端工程师，而此时前端的获取的这个字段的类型、长度是以前的，那么就可能引发线上事故。如

果前端技术牛叉，存储获取字段是一个变量，工作量还小点。只需要改变变量类型、长度即可，如果是一个差一点的没有用变量，而前端又是好几百个页面都用到这个字段，这样就造成后果无法想象的，但是用到接口就有不一样了，如果出现类似的情况，后端人员只需

要将这个字段通过接口做处理是返回的字段保持一致即可，也就是分分钟的事，可能用户都没有察觉就修复了。而且前端、后端、测试也很好排查问题，跑一下接口，查看接口文档返回数据有差异，修给接口就可以，这样处理问题效率也会大大提高。

简单概括：

①越底层发现bug，它的修复成本是越低的。

②前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。

③检查系统的安全性、稳定性，前端传参不可信，比如京东购物，前端价格不可能传入-1元，但是通过接口可以传入-1元。

④如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的解决方案。

⑤接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。

⑥现在很多系统前后端架构是分离的，从安全层面来说：
只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。

前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

2、为什么要写用例

功能测试用例，大家都写过。接口测试用例，很多人没有写过。在后边后又专门一章关于接口用例和接口报告的模板。在写之前，我们来讨论下，为什么要写接口用例。

理清思路，避免漏测和重复测；
提高测试效率；
跟进测试进度；
告诉领导做过；
跟进重复性工作；
更好的记录问题，发现问题，复现问题；
同时这也是是接口测试流程中的一个产物（测试用例）；

上面七点，结合自己测试实际经验，应该来说是很好理解和认同的。有用例，自己做到心中有数，不要一个测试点重复测好多次，就有思路，避免漏掉测试点。

跟着用例测试，避免随机测试那种没有目的性的测试，提高测试效率。有用例，上级问你完成的进度，你好用数据回答。有用例，用来标记你执行的结果，证明你做过测试。

避免将来发生问题，人家说你没有测试，有数据和证据说话。有用例，测出问题你可以根据用例将问题轻而易举的浮现出来，不至于等你反馈或者复现的问题时，你忘记是如何操作才回出现问题。

接口测试也需要重复跑，跑几轮，或者用自动化天天跑。这样的重复性工作，用例可以保证每次重复做的是一样的情况。

3、接口主要设计用例点

主要从四个方面来设计接口用例：功能，逻辑业务，异常，安全

功能：
1）功能是否正常；
2）功能是否按照接口文档实现

举例：比如博客园添加随笔，需要登录才能添加。也就是业务要求不支持游客添加随笔功能，如果设计一个没有登录的用户，然后去测试添加随笔接口，结果接口能添加到随笔，说明功能不正常，不符合需求和接口文档描述。

逻辑业务：是否依赖业务；
举例：该接口调用之前，需要调用登录接口，如果不登录也能请求数据，不符合业务规则。

异常：参数异常和数据异常
参数异常：关键字参数，参数为空，多，少参数，错误参数

数据异常：关键字数据，数据为空，长度不一致，错误数据

举例：不管数据异常还是参数异常，测试点差不多，一个参数有key和value，key表示参数，value表示数据。

第一，看看参数和数据能不能支持关键字，例如Java中的保留关键字等等。

第二个就是参数和数据都为空，看看是否做了判断。

第三个，参数多和少，例如有两个参数的接口，你需要设计一个三个参数的用例，一个只有一个参数的用例。

数据那边长度不一致，例如设计很长的字符串是否支持，因为数据库创建表过程都设置好了每个字段的长度。输入错误的参数和数据，例如故意输出单词等等。

安全测试用例设计：
cookie：有cookie才能获取数据，如果不带cookie还有信息返回，说明有问题

header：正常接口带header信息，删除header看是否能够返回数据。
唯一识别码：app手机识别码，一般是唯一的。

安全测试主要从上面三点检查。第三个是唯一识别码，主要是指app上手机的识别码，一般很少用到，除非很严格的接口测试，例如银行app登录，需要指纹，而指纹来源手机，一般有一个手机识别码判断过程。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

在困境中坚守信念，勇敢面对挑战；用智慧与勤奋，开创美好未来；抓住机遇，超越极限，让努力成为自己的底气，奋斗成就人生辉煌。

人生的路途上，不断追求进步和突破，用热情与智慧燃点自己，用行动与勇气拥抱未来，只有这样，才能实现自己的理想，成就人生的辉煌。

每一次努力都是一次蜕变，每一次奋斗都是一次成长，不要停下前行的脚步，用汗水浇灌梦想的花朵，让自己在坚持中绽放辉煌。