01 用于接口测试

项目测试用例的重复运行首先体现在单个测试用例的独立性上。 也就是说，每个测试用例的运行除了被测对象和相应的数据库环境外，不依赖于任何其他测试用例。 ，并且测试用例执行后，系统上不会有任何痕迹，从而保证每个测试用例都在干净的环境中运行。

要实现测试用例的独立性，需要对被测系统的设计有详细的了解，这样测试用例执行后才不会遗漏任何数据，也不会改变环境。 另外，测试用例也需要详细设计。

另外，为了保证测试用例的复用，还需要及时更新测试用例。 对此，我们做接口测试的人都会维护相应系统的接口测试用例。 我们必须保证每次更新代码时，测试的所有用例都必须执行并通过。

接口测试用例的设计方法实际上与功能测试用例的设计方法类似，因为接口需要满足需求，而接口测试依赖于需求规约。 但是，由于接口测试毕竟是通过代码来测试代码，所以为了保证覆盖率，可能会采用单元测试的方法。 我考虑的具体测试用例设计如下。 请参考一下。 如果有错误，大家一起讨论。

输入参数测试：对输入参数进行测试，也可以说是假设接口参数不正确的情况下进行测试，以保证接口对任何类型的输入都有相应的处理：输入参数合法、输入参数非法、 参数为空，输入参数为null，输入参数太长。

功能测试：接口是否满足所提供的功能，相当于正常测试。 如果接口功能复杂，建议对接口用例进行结构性划分，使子用例具有更好的可读性和可维护性。

逻辑测试：严格来说，逻辑测试应该是单元测试。 单元测试应保持内部逻辑的正确性。 然而，单元测试和接口测试之间的界限并不是那么清晰，因此我们也可以从给定的设计文档中考虑内部逻辑错误。 分支机构情况和例外情况； 异常测试：接口实现是否处理异常。 虽然接口输入参数是合法的，但是接口实现中也可能出现异常，因为内部异常并不一定是由输入数据引起的。 它可能是由其他逻辑引起的，程序需要处理任何异常。

02 接口测试作为集成测试的一部分

通过直接调用被测试的接口，我们可以判断系统在功能、可靠性、安全性和性能方面是否达到预期。 有些情况是功能测试无法覆盖的，所以接口测试是非常有必要的。

接口测试有两种类型。 一种是接口，使用soap协议，通过http传输。 请求消息和返回消息都是xml格式。 测试是通过工具进行的。 使用情况比较少见； 另一个http api接口采用http传输协议，通过路径区分调用方式。 最常用的是 get 和 post 请求。

上面说了，get和post请求是通过路径来区分的。 get请求的请求参数写在URL中，格式为：url?¶m2。 post请求一般写在body中，body可能是key-格式，也可能是json字符串格式，也可能是上传一个文件。 。 。 那么问题来了，get请求和post请求有什么区别呢？ 我们去百度一下，大部分的答案都是这样的：

1. get请求可以在浏览器中请求，post请求的测试需要使用工具。

2. get请求使用URL和参数，post数据放在body中。

3、Post比get更安全，因为传递的参数在url上看不到。

4. get请求的URL会受到限制，而post请求的数据可能会很大。

5、一般使用get请求来获取数据，使用post请求来传输数据。

事实上，对于当前互联网的快速发展来说，上述说法已经不再严谨。 首先，post请求的参数也可以写在URL中，但这种情况很少见； 其次，从表面上看，post似乎是使用body来传递参数，比get URL传递参数更安全，但实际上，只要使用抓包工具（等），该帖子也清晰可见； 第三，现在的浏览器功能非常强大，可以输入并支持很长的URL，所以不再有任何限制。 这样看来，在所有的差异中，只有最后一个才是最根本的。

如何测试接口？ 依据什么？ 这就需要开发提供的接口文档。 接口文档和功能测试需求规范的功能是相同的。 包括：接口说明、调用URL、请求方法（get或post）、请求参数、参数类型、请求参数说明、返回结果说明。 有了接口文档，我们就可以设计用例了。

一般接口测试用例分为以下几类：

1. 通过性验证。 说白了就是传递了正确的参数，是否返回正常的结果。

2.参数组合，因为参数有必选和可选，参数的类型和长度，以及传递时可能存在的一些业务限制，所以在设计用例的时候，需要对这些情况进行安排和组合，保证所有的情况都可以覆盖。 到达

接口的安全性分为几种情况：

1.绕过验证。 比如提交订单时，传递产品价格参数时，修改产品价格取决于后端是否已经验证。 或者当我付款时，我拿一个袋子并更改订单金额。 如果我可以用更改后的金额付款，那么这个借口就有问题。

2、绕过认证是指某项功能只能由具有特殊权限的用户操作。 那么我传给普通用户是不是也可以操作呢？

3、参数是否加密，关系到部分账户的安全。 例如，当我们登录某些网站时，它会对我们的登录信息进行加密。 如果不这样做，我们的信息就会被暴露，这是极其有害的。

4、密码安全规则以及设置密码时的复杂性验证。

5. 根据业务逻辑设计用例。

用例设计好后，应该用什么来测试接口呢？ 我们可以使用一些工具，例如 和 。 使用起来比较简单。 您可以在列表中选择请求方式，并在输入框中输入URL。 如果是get请求，直接点击send即可看到返回结果。

03 什么是接口测试？

接口测试是测试系统组件之间接口的一种测试。 接口测试主要用于检测外部系统与系统之间、内部子系统之间的交互点。 测试的重点是检查数据的交换、传输和控制管理流程，以及系统之间相互的逻辑依赖关系等。

为什么我们需要进行接口测试？

a) 随着互联网的快速发展，公司内部系统或外部系统之间的连接越来越多。 一个业务流程与多个后端系统相关联，它们之间的关系都是基于接口的。 接口测试可以关联复杂的系统。 化繁为简，只要每个接口都测试好，系统质量就能得到更好的保证。

b) 单个系统的变更是否会影响相关业务系统？ 用常规的测试很难覆盖相关的应用系统（比如有N个外部系统使用这个接口，不可能对每一个都进行功能兼容性测试），但是可以验证是否影响其他人的调用通过重写接口函数来实现接口。

c) 接口功能比较简单，可以实现较好的测试覆盖率，比较容易实现自动化持续集成，可以减少人工回归成本和时间，缩短测试周期。

d) 接口会比接口函数更底层，测试覆盖率会更容易（比如业务在调用接口时进行判断，不满足条件时不会显示链接。此时时间，无法从接口测试相关功能是否做得好判断，通过接口更容易）

接口测试范围

a) 业务功能（包括正常场景和异常场景是否实现）

b) 业务规则（覆盖范围是否全面）

c) 参数验证（边界和业务规则是否满足要求）

d) 异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）

e) 性能测试（响应时间、吞吐量、并发数、资源需求）

f) 安全测试（权限验证、SQL注入等）

04 接口测试要点

1. 检查接口返回的数据是否与预期结果一致。

2、检查接口的容错能力，如果传递的数据类型错误是否可以处理。

3.接口参数的边界值。 例如，当传递的参数足够大或者为负数时，接口是否能够正常处理。