接口测试用例设计

学习笔记
, , , ,
1

一、简介

  • 接口测试在需求分析完成之后，即可设计对应的接口测试用例，然后根据用例进行接口测试。

  • 接口测试用例的设计，也需要用到黑盒测试用例的设计方法，和功能测试用例设计的方法类似，设计过程中还需要增加与接口特性相关的测试用例。

二、接口测试流程

image
image1044×2517 171 KB

三、接口测试的质量目标

  • 功能测试：确保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 接口测试的思路

image

5.2 基本功能流程测试

  • 在基本功能流程测试方面，首先需要执行冒烟测试，把最基本的功能流程走通。

  • 冒烟测试决定提测是否成功。

    • 如果冒烟测试通过，才会进入到详细的测试阶段；
    • 如果冒烟测试不通过，需要打回给开发，开发修改之后重新提测。

  • 冒烟测试通过，进入正常流程覆盖测试，粒度会比冒烟测试更细一些，覆盖一些分支业务逻辑。

5.3 基于输入域的测试

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

    • 边界值测试

      • 对于有范围要求的参数，需要综合等价类和边界值的方法设计测试用例。
      • 边界值选中上点和离点即可，要覆盖到有效等价类和无效等价类。

    • 特殊字符校验

      • 对于很多请求参数会要求不能包含特殊字符，需要单独设计包含特殊字符的测试用例来做验证。

    • 参数类型校验

      • 有些参数对类型有要求，比如只能包含英文数字，或者只能包含整数类型等。对于这种对类型有要求的字段，要单独设计测试用例，尤其是一些反向用例。

    • 必选参数校验

      • 对于每一个必填的参数，都要设计一条不传的用例来验证。

    • 组合参数校验

      • 对于有选填参数的接口来说，需要对于各种参数的不同组合场景来进行验证。比如只传必填参数，或者必填参数和不同数量的选填参数组合，可以使用判定表法进行设计。

    • 排重逻辑

      • 如果字段要求不能重复，就要进行排重逻辑的覆盖，验证重复请求相同的参数，服务端的处理逻辑是否正确。

    • 接口幂等性

      • 幂等性是指任意多次执行所产生的影响，均与第一次执行的影响相同。

      • 保证接口的幂等性是非常重要的，尤其是在涉及资金的系统，如银行、电商等。

      • 如用户重复提交请求，或者网络重发、系统重试等，都需要设计测试用例来保证接口的幂等性。

      • 接口的幂等测试，需要多次发送同一参数的请求，查看服务端响应是否只有一次是成功的。

5.4 线程安全测试

  • 线程安全测试包含了并发测试、分布式测试。

  • 分布式更多的一个概念，是为了解决单个物理服务器容量，和性能瓶颈问题而采用的优化手段。

  • 分布式的两种实现形式：

    • 水平扩展：当一台机器扛不住流量时，就通过添加机器的方式，将流量平分到所有服务器上，所有机器都可以提供相当的服务。

    • 垂直拆分：前端有多种查询需求时，一台机器扛不住，可以将不同的需求，分发到不同的机器上。

  • 相对于分布式来讲，高并发在解决的问题上会集中一些，它的重点是测试同时有多少量，比如在线直播同时有上万人观看。

  • 高并发可以通过分布式技术去解决，将并发流量分到不同的物理服务器上。但除此之外，还可以有很多其他优化手段，比如使用缓存系统，还可以使用多线程技术，将一台服务器的服务能力最大化。

  • 对于并发场景，需要测试多个相同参数的请求，只有一条请求成功，其他请求失败。

  • 对于分布式测试，则需要测试在分布式环境中，并发相同参数的请求，只有一条请求成功，其他请求失败。

5.5 故障注入

  • 故障注入测试，需要测试人员故意制造故障的场景，来保证系统的健壮性。

  • 如果产品中用到了Redis，就需要对于Redis做一些故障降级测试。Redis一般会放在数据库前面，用来做高速缓存。

    • Redis故障注入，需要开发配合清空Redis数据、发请求、击穿Redis，从DB中获取正常的数据，并能回写到Redis中。

    • 然后开发配合启动Redis数据恢复功能，测试可以从Redis中获取正确的数据。

    • 还需要开发配合制造Redis崩溃场景，发请求，测试是否降级从DB中获取到正常的数据。

  • 除了Redis，还需要进行服务故障转移测试。比如数据库故障测试，接口故障测试。

    • 数据库故障测试：

      • 开发配合制造数据库数据丢失的场景，启动数据恢复策略，测试规定时间段内数据是否可以恢复；

      • 开发配合制造数据库崩溃的场景，测试数据库多活策略是否启动，保证功能不受影响。

    • 接口故障测试：

      • 开发配合接口服务重启，测试集群负载是否自动重启实例，所有请求无异常；

      • 开发配合制造集群崩溃场景，测试是否返回对应的错误信息，内部服务是否有重试机制。

5.2 接口测试用例要素

  • 模块

  • 测试标题

  • 优先级

  • 前置条件

  • URL

  • 请求方法

  • 请求参数

  • 预期结果

  • 实际结果

    image
    image2962×1098 209 KB