软件测试学习笔记丨接口测试用例设计

作者：测试人

2024-09-09
北京
本文字数：2725 字
阅读完需：约 9 分钟

本文转自测试人社区，原文链接：https://ceshiren.com/t/topic/32078

一、简介

接口测试在需求分析完成之后，即可设计对应的接口测试用例，然后根据用例进行接口测试。
接口测试用例的设计，也需要用到黑盒测试用例的设计方法，和功能测试用例设计的方法类似，设计过程中还需要增加与接口特性相关的测试用例。

二、接口测试流程

三、接口测试的质量目标

功能测试：确保 API 按预期工作，正确处理所有输入，并返回正确的输出。

策略：测试用例覆盖：编写全面的测试用例，覆盖所有 API 端口、请求类型（GET、POST、PUT、DELETE 等），以及输入参数；边界值测试：测试边界值和特殊值（如空值、最大值、最小值等）；异常处理：验证 API 在接收到无效输入，或异常情况下的响应。
工具：Postman、Fiddle、Charles

性能测试：确保 API 在各种负载下表现良好，响应时间满足要求，能处理高并发请求。

策略：负载测试：模拟并发用户请求，检查 API 在高负载下的表现。压力测试：测试 API 的承受能力，找到系统的瓶颈。容量测试：确定系统能够处理的最大用户数量。
工具：JMeter、LoadRunner

安全测试：确保 API 免受常见的安全威胁，如 SQL 注入、跨站脚本（XSS）和跨站请求伪造（CSRF）。

策略：身份验证和授权：验证 API 的身份验证机制（如 JWT、OAuth）和权限控制。输入验证：确保 API 对输入进行严格验证，防止注入攻击。安全漏洞扫描：使用工具扫描 API 的安全漏洞。
工具：OWASP ZAP、Burp Suite、Postman（用于身份验证测试）

兼容测试：确保 API 在不同环境（操作系统、浏览器、设备）下都能正常工作。

策略：跨平台测试：在不同操作系统和浏览器上测试 API。版本兼容性测试：验证 API 的不同版本之间的兼容性，确保新版本不破坏旧版本的功能。
工具：Postman、Selenium（用于模拟不同浏览器）

健壮性测试：确保 API 在意外情况（如网络中断、服务器崩溃）下能够优雅地恢复和处理错误。

策略：异常处理测试：模拟各种异常情况，检查 API 的错误处理和恢复能力。容错测试：测试 API 在部分系统组件失效时的表现。
工具：Postman、Chaos Monkey（用于模拟故障）

高可用性（中间件） ：确保 API 在中间件（如消息队列、缓存、数据库）组件的支持下实现高可用性和可靠性。

策略：冗余和故障转移测试：测试 API 在中间件组件故障时的故障转移机制。健康检查和监控：验证 API 的健康检查和监控机制，确保系统问题能够及时发现和解决。负载均衡测试：确保 API 在负载均衡下能够均匀分配请求，并处理节点故障。工具：Prometheus、Grafana（用于监控和健康检查）、HAProxy（用于负载均衡）

四、协议分析方法

网络监听：TcpDumpWireShark
代理 Proxy：推荐工具：手工测试 Charles【全平台】、安全测试 BurpSuite【全平台 Java】自动化测试：mitmproxy

五、接口测试用例的设计方法

5.1 接口测试的思路

5.2 基本功能流程测试

在基本功能流程测试方面，首先需要执行冒烟测试，把最基本的功能流程走通。
冒烟测试决定提测是否成功。如果冒烟测试通过，才会进入到详细的测试阶段；如果冒烟测试不通过，需要打回给开发，开发修改之后重新提测。
冒烟测试通过，进入正常流程覆盖测试，粒度会比冒烟测试更细一些，覆盖一些分支业务逻辑。

5.3 基于输入域的测试

因为发出接口请求需要携带请求参数，所以肯定会涉及到关于请求参数的各种用例的设计。关于请求参数的用例设计，考虑以下方面：

边界值测试对于有范围要求的参数，需要综合等价类和边界值的方法设计测试用例。边界值选中上点和离点即可，要覆盖到有效等价类和无效等价类。
特殊字符校验对于很多请求参数会要求不能包含特殊字符，需要单独设计包含特殊字符的测试用例来做验证。
参数类型校验有些参数对类型有要求，比如只能包含英文数字，或者只能包含整数类型等。对于这种对类型有要求的字段，要单独设计测试用例，尤其是一些反向用例。
必选参数校验对于每一个必填的参数，都要设计一条不传的用例来验证。
组合参数校验对于有选填参数的接口来说，需要对于各种参数的不同组合场景来进行验证。比如只传必填参数，或者必填参数和不同数量的选填参数组合，可以使用判定表法进行设计。
排重逻辑如果字段要求不能重复，就要进行排重逻辑的覆盖，验证重复请求相同的参数，服务端的处理逻辑是否正确。
接口幂等性幂等性是指任意多次执行所产生的影响，均与第一次执行的影响相同。保证接口的幂等性是非常重要的，尤其是在涉及资金的系统，如银行、电商等。如用户重复提交请求，或者网络重发、系统重试等，都需要设计测试用例来保证接口的幂等性。接口的幂等测试，需要多次发送同一参数的请求，查看服务端响应是否只有一次是成功的。

5.4 线程安全测试

线程安全测试包含了并发测试、分布式测试。
分布式更多的一个概念，是为了解决单个物理服务器容量，和性能瓶颈问题而采用的优化手段。
分布式的两种实现形式：水平扩展：当一台机器扛不住流量时，就通过添加机器的方式，将流量平分到所有服务器上，所有机器都可以提供相当的服务。垂直拆分：前端有多种查询需求时，一台机器扛不住，可以将不同的需求，分发到不同的机器上。
相对于分布式来讲，高并发在解决的问题上会集中一些，它的重点是测试同时有多少量，比如在线直播同时有上万人观看。
高并发可以通过分布式技术去解决，将并发流量分到不同的物理服务器上。但除此之外，还可以有很多其他优化手段，比如使用缓存系统，还可以使用多线程技术，将一台服务器的服务能力最大化。
对于并发场景，需要测试多个相同参数的请求，只有一条请求成功，其他请求失败。
对于分布式测试，则需要测试在分布式环境中，并发相同参数的请求，只有一条请求成功，其他请求失败。

5.5 故障注入

故障注入测试，需要测试人员故意制造故障的场景，来保证系统的健壮性。
如果产品中用到了 Redis，就需要对于 Redis 做一些故障降级测试。Redis 一般会放在数据库前面，用来做高速缓存。Redis 故障注入，需要开发配合清空 Redis 数据、发请求、击穿 Redis，从 DB 中获取正常的数据，并能回写到 Redis 中。然后开发配合启动 Redis 数据恢复功能，测试可以从 Redis 中获取正确的数据。还需要开发配合制造 Redis 崩溃场景，发请求，测试是否降级从 DB 中获取到正常的数据。
除了 Redis，还需要进行服务故障转移测试。比如数据库故障测试，接口故障测试。数据库故障测试：开发配合制造数据库数据丢失的场景，启动数据恢复策略，测试规定时间段内数据是否可以恢复；开发配合制造数据库崩溃的场景，测试数据库多活策略是否启动，保证功能不受影响。接口故障测试：开发配合接口服务重启，测试集群负载是否自动重启实例，所有请求无异常；开发配合制造集群崩溃场景，测试是否返回对应的错误信息，内部服务是否有重试机制。