2、接口测试流程

一、需求分析

• 工作方式：基于产品经理的需求文档进行会议讨论
• 执行要点：
  • 需要提前阅读需求文档
  • 通过团队会议确认需求细节
  • 属于基础工作能力，无需专门学习

二、接口文档解析

1. 基本概念

• 定位：接口测试的第一步关键工作
• 核心问题：
  • 明确接口文档的定义和作用
  • 确定需要从文档中提取的关键信息

2. 解析目标

• 关键任务：
  • 理解接口文档的结构和内容
  • 提取测试所需的接口参数和规范
  • 为后续测试用例设计做准备
• 工作产出：填写《接口文档解析模板.xlsx》

三、接口测试完整流程

• 标准流程：
  • 需求分析（产品需求文档）
  • 接口文档解析（API文档）
  • 设计测试用例（Excel表格）
  • 准备测试脚本（Postman/Python）
  • 执行测试并跟踪缺陷
  • 生成测试报告
  • 自动化持续集成（可选）
• 流程特点：
  • 线性推进的工作流程
  • 各环节有明确的交付物

自动化集成属于进阶选项

• • 注：所有时间戳均基于PPT文件名自动生成，图片路径保持原始命名格式。笔记内容严格遵循课程记录，未添加任何非讲授内容。

四、接口文档解析

1. 接口文档解析

1）接口文档

• 定义：接口文档（API文档）是由后端开发编写的，用于描述接口信息的文档，全称为Application Programming Interface。
• 作用：
  • 团队协同：实现开发团队的工作协同配合
  • 规范约束：作为项目更新修改的同步维护依据
• 编写者：后端开发工程师（因为接口测试主要针对后端）
• 核心内容：主要描述接口的各种信息

2）各种接口文档示例

01:43

• 爱家租房网接口文档
   
• • 文档形式：Word文档格式
  • 主要内容：
    • 项目说明：微服务架构的租房业务项目案例
    • 全局错误码：
      • 实际应为"状态码"，为避免与HTTP状态码混淆而称为错误码
      • 采用4位数字编码（如4000系列），区别于HTTP的3位状态码
      • 示例：
        • 0：成功（RECODE_OK）
        • 4001：数据库查询错误（RECODE_DBERR）
        • 4101：用户未登录（RECODE_SESSIONERR）
    • 特点：
      • 错误码不一定表示错误，成功时也可返回
      • 开发团队需统一使用预设的错误码进行状态判定
• 修改记录
• • 作用：记录接口文档的变更历史，确保团队信息同步
  • 内容格式：
  • 管理要求：
    • 任何修改都需要记录并通知项目组
    • 团队成员需按照修改后的文档规范执行
• 项目相关接口文档
• • 结构特点：
    • 按功能模块分类（如首页相关、登录相关等）
    • 每个接口包含：
      • 服务编号
      • 服务名称
      • 请求类型（GET/POST等）
      • URL路径
      • 调用函数名
  • 示例接口：
    • 发送登录信息服务：
      • 请求方法：POST
      • URL：/api/v1.0/sessions
      • 函数：PostLogin
  • 详细说明：
    • 功能描述：发送用户登录信息进行登录
    • 完整URL：需拼接系统域名（如http://xx.com/api/v1.0/sessions）
    • 请求参数：
    • 响应示例：
      • 成功：
      • 失败：
• IHRM人力资源管理系统接口文档
• • 文档特点：
    • 单独列出系统路径（如http://ihrm-test.itheima.net）
    • 接口Path只包含资源路径，需拼接系统路径
  • 接口规范：
    • Path：/api/sys/login
    • Method：POST
    • 请求参数：
      • Headers：
        • Content-Type: application/json
      • Body：
    • 响应规范：
      • 成功状态码：200
      • 错误码：
        • 10000：操作成功
        • 99999：系统繁忙
  • 术语说明：
    • 请求参数：包含请求头和请求体数据（也称请求数据）
    • 注意：与URL查询参数是不同的概念

3）传统风格接口和RESTful风格接口的小结

13:57

• 接口风格概述
• • 传统风格接口：
    • 仅使用GET和POST方法
    • URL不唯一，可能包含操作动词
    • 统一返回200状态码
  • RESTful风格接口：
    • 使用GET、POST、PUT、DELETE等方法
    • URL唯一且仅表示资源
    • 返回状态码灵活（200、201、204等）
• RESTful风格接口特点
  14:20
  • 方法对应：HTTP请求方法与操作类型一一对应
    • GET-查、POST-增、PUT-改、DELETE-删
  • URL设计：
    • 不能从URL看出操作类型
    • 需结合请求方法识别操作
  • 状态码使用：
    • 查询成功：200
    • 添加成功：201
    • 删除成功：204
• 接口文档解析
• • 请求参数：
    • mobile：必须，手机号
    • password：必须，密码
  • 响应结构：
    • success：布尔类型，操作成功标记
    • code：整型，错误码
    • message：字符串，消息描述
    • data：字符串，令牌(token)
• 预期结果与实际结果
  18:57
  • 预期结果：
    • 来自接口文档
    • 是理论上的响应示例
  • 实际结果：
    • 通过实际请求获得
    • 可从浏览器开发者工具或Postman获取
  • 区别：
    • 文档只能提供预期结果
    • 实际结果需通过真实请求获取
• 添加员工接口分析
• • 请求头：
    • Content-Type：application/json
    • Authorization：Bearer + token
  • 请求体参数：
    • 必填项：username、mobile、workNumber
    • 非必填：timeOfEntry、formOfEmployment等
  • 响应示例：
    • 成功：返回新增员工ID
    • 失败：返回错误码和消息
• 接口文档形式
  25:57
  • 常见格式：
    • Word文档
    • PDF文档
    • Excel表格
    • 在线文档工具
  • 文档特点：
    • 通常不完整，需自行补充
    • 不同公司格式差异大
    • 中小公司文档通常较简略

2. 接口文档解析知识总结

1）接口文档基本概念

• 定义与别名：接口文档是描述接口相关信息的文档，也称为API文档
• 编写主体：通常由后端开发工程师负责编写
• 核心功能：用于详细说明接口的各项技术参数和功能特性
• 内容要素：包含接口名称、功能描述、请求参数要求、返回结果格式等关键信息

2）接口文档解析的必要性

• 自动化基础：是接口自动化测试脚本开发的前提条件
• 规范保障：确保测试人员准确理解接口规范和要求
• 效率提升：避免因理解偏差导致的测试用例设计错误
• 协作桥梁：作为开发与测试团队之间的技术沟通媒介

3）接口文档解析流程

• 前置步骤：在需求分析之后立即进行
• 核心环节：包括测试用例设计、脚本开发等关键工作
• 后续关联：直接影响测试执行和缺陷跟踪效果
• 可选扩展：可延伸至持续集成环节实现自动化部署

4）接口风格类型

• 传统风格：采用动词性接口命名方式
• RESTful风格：基于HTTP方法的资源操作规范
• 对比要点：主要区别在于URL设计理念和参数传递方式

五、知识小结

 

知识点	核心内容	考试重点/易混淆点	难度系数
接口文档定义	由后端开发编写，描述接口信息的文档（API文档），包含接口功能、请求参数、返回结果等	区分“错误码”与HTTP状态码（错误码可能表示操作状态，不一定是错误）	⭐⭐
接口文档形式	Word/PDF/Excel/在线工具，常见结构：全局错误码、请求方法（GET/POST）、URL拼接规则、参数说明	URL拼接需手动补充协议和域名（如系统路径+资源路径）	⭐⭐
请求参数解析	包含请求头（如Content-Type: application/json）和请求体（如登录接口的mobile和password）	请求参数≠查询参数，需明确术语差异	⭐⭐⭐
返回结果分析	文档提供的是预期结果（如成功/失败案例），实际结果需通过工具（Postman/代码）发送请求获取	区分HTTP状态码（请求成功与否）与业务错误码（操作成功与否）	⭐⭐⭐
令牌（Token）作用	登录后返回的令牌（如Authorization: Bearer xxx）用于后续接口的身份验证（如添加员工需传令牌）	令牌在请求头中的格式需注意（Bearer前缀）	⭐⭐⭐⭐
接口测试流程	1. 解析文档 → 2. 设计用例 → 3. 准备脚本	文档可能不完整（如缺失失败案例），需自行补充测试场景	⭐⭐⭐
常见接口类型	登录（POST）、查询（GET）、新增员工（POST）等，需关注必填/非必填参数	非必填参数可能影响业务逻辑，需针对性测试	⭐⭐⭐
错误码设计	自定义错误码（如10000=成功，20001=密码错误），避免与HTTP状态码冲突	错误码可能覆盖成功/失败状态（如0表示成功）	⭐⭐