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

本文转自测试人社区，原文链接：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（用于负载均衡）

四、协议分析方法

网络监听：
- TcpDump
- WireShark
代理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，还需要进行服务故障转移测试。比如数据库故障测试，接口故障测试。
- 数据库故障测试：
  - 开发配合制造数据库数据丢失的场景，启动数据恢复策略，测试规定时间段内数据是否可以恢复；
  - 开发配合制造数据库崩溃的场景，测试数据库多活策略是否启动，保证功能不受影响。
- 接口故障测试：
  - 开发配合接口服务重启，测试集群负载是否自动重启实例，所有请求无异常；
  - 开发配合制造集群崩溃场景，测试是否返回对应的错误信息，内部服务是否有重试机制。