接口测试自动化过程和规范

接口测试规范

1.简介

• 前言

  1. 接口测试是测试系统组件间接口的一种测试，主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点，本文中所指接口为web-接口；
  2. 接口测试的重点是要检查数据的交换，传递和计算处理过程，以及系统间的相互逻辑依赖关系等；
  3. 大部分接口测试，其测试内容都为:
     • 客户端发送request请求
     • 服务器返回response报文
     • 对response内容进行检验比对，从而判定接口访问是否成功，返回数据是否符合要求，以此验证此接口是否符合需求；

• 目的

  1. 保证系统接口的功能正常，提高需求质量；
  2. 持续集成，提高测试效率，保证数据的准确性；
  3. 后端基础服务的架构比较复杂，接口测试可以让测试人员集中精力关注系统对外交互的部分，因而能够提供系统复杂度上升情况下的低成本高效率的解决方案。

• 意义

  1. 更早地发现问题:
     • 测试工作应该更早地介入到项目开发中，因为越早发现bug，修复的成本越低。功能测试必须要等到系统提供可测试的界面后才能进行。
     • 单元测试和接口测试是更早介入测试的两个方面。接口测试可以在功能界面未开发出来之前对系统的接口进行测试，从而可以更早地发现问题并以更低的成本修复问题。
  2. 缩短产品研发周期:
     • 接口测试的介入可以更早地发现并解决bug，使得留到功能测试阶段被修复的bug减少，从而缩短整个项目的上线时间。
  3. 发现更底层的问题:
     • 系统中的有些bug如果想通过UI层功能测试会比较困难，或者构造测试条件非常复杂。通过接口测试可以更简单更全面地覆盖到底层的代码逻辑，从而可以发现一些隐藏的bug。
     • 通常把UI层的验证称为弱验证，这是因为它很容易被绕过。如果只针对UI层的功能进行测试，就很难发现后端系统对一些异常情况的处理能力，而接口测试可以很容易地验证这些异常情况。
  4. 前端随便变，接口测好了，后端不用变
     • 前端与后端的分离，是近年来Web应用开发的一个发展趋势。这种模式的优势前端的专业性越来越高，通过调用Web接口获取数据，从而专注于数据展示和页面交互的设计。
     • 后端不必精通前端技术（HTML5/JavaScript/CSS），只专注于数据的处理并提供Web接口即可。由后端开发的接口既可以提供给Web页面调用，也可以提供给移动APP调用；既可以提供给公司内部系统调用，也可以提供给公司外部系统调用。
  5. 检查系统的安全性、稳定性

2.原则

1. 任何新增接口和修改接口都需通知测试人员，并由其进行相关接口测试；
2. 接口测试不仅要求从白盒角度对系统的整体架构有足够了解(逻辑)，还要求从黑盒角度对用户场景熟悉(业务)，两者相辅相承设计测试用例；
3. 始终站在用户的角度对系统接口进行全面高效持续的检测。

3.评估项

1. 业务功能覆盖是否完整
2. 业务规则覆盖是否完整
3. 参数验证是否达到要求（边界、业务规则）
4. 接口异常场景覆盖是否完整
5. 接口覆盖率是否达到要求
6. 代码覆盖率是否达到要求
7. 性能指标是否满足要求
8. 安全指标是否满足要求

4.类型

1. 业务功能测试: 正常场景，异常场景;
2. 边界分析测试: 业务规则边界分析，输入输出参数边界分析;
3. 参数组合测试;
4. 异常情况测试: 重复提交，并发测试，事务测试，大数据量测试;
5. 性能测试: 响应时间，吞吐量，并发数，服务器资源使用率;
6. 安全测试: 敏感信息，SQL注入;

5.步骤

1. 理解接口规范: 熟悉接口文档，理解请求参数、方法、路径和预期的响应。
2. 设计测试用例: 基于接口规范设计全面的测试用例，包括正常流程和异常流程。
3. 准备测试环境: 配置测试所需的环境，如接口服务器、数据库和测试数据。
4. 执行测试: 运用自动化测试工具或手动执行测试用例。
5. 结果验证: 验证接口的响应是否符合预期结果。
6. 问题跟踪: 记录测试中发现的问题，并跟踪至解决。
7. 测试报告: 生成测试报告，总结测试结果和发现的问题。

6.内容

• 一、参数校验

1. 数据类型校验：
   • 确保传入参数的数据类型与接口文档中定义的类型一致。
   • 校验参数类型，如字符串、整数、浮点数等，是否满足要求。　　
2. 数据长度校验：
   • 对于字符串类型的参数，检查其长度是否在允许的范围内，避免数据溢出或截断。
3. 数据格式校验：
   • 对于特定格式的参数，如日期、邮箱地址、手机号码等，检查其格式是否正确。
4. 必填参数校验：
   • 验证接口文档要求的必填字段是否都已提供，并且参数值不为空、不越界、类型正确。
5. 　　非必填参数校验：
   • 对于非必填参数，验证其传入的正确性，包括格式、长度等。
6. 　　重复参数校验：
   • 对于可能重复传递的参数，进行唯一性校验，避免重复处理。

• 二、返回值校验

1. 状态码校验
   • HTTP状态码：首先，验证返回的HTTP状态码是否符合预期。常见的状态码如200（成功）、400（错误请求）、404（未找到）、500（服务器内部错误）等，每种状态码都有其特定的含义和用途。
   • 业务状态码：除了HTTP状态码外，有些API还会返回业务状态码，用于更详细地描述业务处理的结果。测试时需要验证业务状态码是否符合业务逻辑和预期结果。
2. 数据内容校验
   • 数据类型校验：验证返回的数据类型是否与接口文档中定义的类型一致。例如，如果接口文档指定返回的是JSON格式的字符串，那么实际返回的数据也应该是符合JSON规范的字符串。
   • 数据格式校验：对于特定格式的数据，如日期、时间、金额等，需要验证其格式是否正确。例如，日期格式应该符合YYYY-MM-DD或YYYY/MM/DD等规范。
   • 数据完整性校验：验证返回的数据是否完整，是否包含了所有必要的字段。这可以通过与接口文档进行比对来实现。
   • 数据准确性校验：验证返回的数据是否准确，是否符合业务逻辑和预期结果。这可能需要结合具体的业务场景和数据来源来进行判断。

• 返回值必要性校验
  • 避免冗余数据：验证返回的数据是否都是必要的，避免返回过多无用数据。过多的冗余数据不仅会增加网络传输的开销，还可能对前端展示和数据处理造成不必要的麻烦。
  • 按需返回：根据请求参数和业务需求，验证API是否按需返回了相应的数据。例如，如果请求参数中指定了只需要返回某个字段的值，那么API应该只返回该字段的值而不是整个数据对象。
• 其他校验点
  • 异常处理校验：验证当API出现异常时，返回的异常信息是否准确、完整且易于理解。异常信息应该包含足够的上下文信息以便于定位和解决问题。
  • 分页参数校验：如果API支持分页查询，那么需要验证分页参数（如页码、每页数量等）是否有效，以及返回的数据是否符合分页规则。
  • 排序参数校验：如果API支持排序功能，那么需要验证排序参数是否有效，以及返回的数据是否按照指定的排序规则进行了排序。
• 三、命名校验
  1. 接口命名：
     • 确保接口命名准确、简洁，遵循一定的命名规则。
  2. 字段命名：
     • 字段命名应准确反映其含义，且拼写无误，遵循驼峰命名法等规范。
• 四、业务判断
  1. 约束条件校验：
     • 验证接口处理是否满足业务上的约束条件，如数值限制、状态限制、关系限制等。 
  2. 操作对象校验：
     • 验证接口操作的对象是否符合业务规则，如非自己创建的数据不能修改等。 
  3. 时序分析：
     • 确保接口调用的时序符合业务逻辑，如前置条件是否存在。
• 五、安全校验
  1. 参数安全校验：
     • 对传入的参数进行安全性校验，如防止SQL注入、跨站脚本攻击（XSS）等。
  2. 权限校验：
     • 验证接口访问的权限，确保只有具有相应权限的用户才能访问和调用接口。
  3. 加密与验证：
     • 对于敏感数据，如密码、密钥等，进行加密存储和传输，确保数据的安全性。
  4. 访问控制：
     • 通过API密钥、等方式进行身份验证和授权，确保接口访问的安全性。
  5. 漏洞管理：
     • 定期进行安全审计和漏洞扫描，及时修复潜在的安全漏洞。

7.场景覆盖

1. 从用户角度进行设计的测试覆盖。主要是模拟用户的业务操作，达到对用户行为的覆盖。
2. 场景测试优先覆盖正常路径，其次是分支路径以及异常路径。
3. 测试场景保持独立性和原子性，每个测试场景完成独立的功能，不受其他操作的影响。

8.自动化用例编写规范

1. 一个脚本是一个完整的用例。
2. 用例中正向逻辑用例为主，逆向逻辑用例为辅。逆向逻辑的情况较多（例如手机号输错有很多种情况），逆向逻辑按等价类划分法选取具有代表性的用例编写。
3. 用例之间不要产生关联性，即编写的每一个用例都是独立的，不依赖或影响其他用例脚本。
4. 整个脚本中只对验证点进行验证，无需对整个脚本每一步操作都做验证。
5. 测试用例的上下文有一定的顺序性，能够互相连接，并且前置条件清晰。
6. 尽量把重复任务放入一个方法中，这样它可以被多个测试用例调用。
7. 测试用例不匹配预设的验证点，需要抛出合适的异常并提供详细的失败信息。
8. 前置条件的准备尽量调取功能接口完成，非必要情况不使用直接修改数据库字段值的形式（必要情况下也要保证所修改字段不影响其它数据或系统功能）。
9. 统一命名方式，测试用例模块名、方法名以test_api名称命名。

9.测试断言设计

1. 尽量保持断言形式统一。
2. 选择具有明确的message参数的断言方法，使断言结果的可读性更强。
3. 选择断言的对象需准确，有代表性。
4. 不使用接口响应数据作为唯一断言情况下，需结合数据库相应数据变化做断言。

9.准入准则

1. 提交的接口测试对象已联调通过.
2. 接口文档静态测试已通过（包含接口信息、传参信息、响应信息等）.
3. 接口测试环境可正常使用.

10. 准出准则

1. 接口功能清单已全部覆盖且满足需求.
2. 接口问题检出已稳定，回归阶段未发现其它问题.
3. 接口测试报告已出.

ps: 搬运+缝合, 喜欢的自取