技术

背景

当前业务核心聚焦于 POCT 领域，设备购买和设备使用等关键功能，已成为测试工作的重点保障对象，但随着系统复杂度的提升,手工的回归测试工作很难全面覆盖。为了确保关键业务功能的质量稳定性，有必要引入自动化测试，增加测试覆盖范围，降低已有功能漏测的风险，提前发现问题。

目标

  1. 短期目标：接入自动化测试（截至3月底）

    1. 前期准备工作
      • 预研不同的自动化测试框架，结合中长期目标与现实情况及各个框架的优缺点选择一套合适的自动化框架
        • 对比几款常见接口测试框架
        • 初步选定：pytest + Requests
          • 语法简洁容易上手-接入成本低
          • 灵活，社区支持好，插件丰富-适合复杂测试场景
      • 制定初步的方案
    2. 自动化项目方案
      • 项目框架搭建
      • 确定实施方案
    3. 测试人员小范围接入自动化项目（跑通流程）
      • 三月底能够将三款新设备正向检测流程转化为自动化测试脚本
        • **将慢病设备下单-上传检测结果流程；快速检测单流程接入接口自动化测试（正向检测流程）
        • **将免疫、血球设备下单-上传检测结果（正向检测流程）

  2. 中期目标 ：自动化项目应用到测试工作流程（截至6月底）

  3. 覆盖三款新设备装机到检测使用的全部场景

    • 覆盖设备装机到检测过程中的各项操作步骤和关键节点，从设备初始化到实际检测，确保各环节功能正常，数据交互准确，为用户提供稳定可靠的设备使用体验（包括异常流程）。

  4. 将自动化流程应用到测试工作流程。

    • 能有效增加测试覆盖率，减少漏测风险。

  5. 脚本的维护流程

    • 在接口变更，需求功能更改后如何维护
    • 运行失败用例如何维护

  6. 长期目标：不断完善接口自动化，有效应用到研发测试工作流程（截至12月底）

    1. 完善涉及用户相关的功能的自动化测试覆盖
      • 对从商城购买到设备装机、检测、报告生成打印及检测后的慢病管理，全流程自动化测试，保障用户使用系统过程中的顺畅性，避免因流程问题导致的交易失败或用户体验不佳情况。
    2. 将自动化测试无缝应用到现有的研发测试工作流程中。
    • 替代大部分回归测试，提高测试效率，进一步减少漏测风险。
    • 自动化测试成为常态化测试手段,能提前发现问题,有效提升整体工作效率。

自动化测试工具选型

  • 自动化测试框架-pytest + Requests

    • 几款常见接口测试框架对比详情：

      1743173315631

    • pytest + Requests

      • 语法简洁容易上手-接入成本低
      • 灵活，社区支持好，插件丰富-适合复杂测试场景
      • 已有相关基础

    • 选型依据 　　兼容性、适合复杂流程交互（设备交互）、丰富的社区支持、接入成本

  • 测试管理工具（飞书或tapd）
  • CI/CD工具
  • GitLab CI
  • uvicorn+fastapi
    • 部署+接口

自动化测试用例设计

  1. 用例分层设计
    1. 基础类（/api）
      • 根据接口文档生成
    2. 测试用例（/tests）
      • 基础功能用例（原子级-单个接口测试）
        • 定义 ：针对单个接口的独立测试，关注接口的输入输出正确性、异常处理能力及边界条件验证。例如，用户登录接口的独立测试需覆盖正常登录、密码错误、账号不存在等场景
        • 特点 ：
        • 原子性 ：每个用例仅验证一个接口的单一功能，不依赖其他接口或业务流程。
        • 高复用性 ：可作为其他复杂用例的构建单元，例如登录接口的测试结果可被后续业务流程用例复用
        • 技术实现 ：通常结合数据驱动设计（如参数化测试数据），通过多组输入数据覆盖等价类和边界值
      • 业务流程用例（端到端、涉及多个接口和流程的测试）
        • 定义 ：模拟真实用户操作路径，串联多个接口验证端到端业务逻辑。例如“创建商品→创建优惠券→创建活动→下单支付”的全流程测试
        • 特点 ：
        • 场景化 ：基于用户使用的功能场景设计，关注接口间的数据传递与状态流转。
        • 风险覆盖 ：重点验证流程中的关键节点（如订单状态变更、库存扣减）和异常分支（如支付超时回滚）
        • 依赖管理 ：通过关键字驱动设计（如“获取Token”“查询订单状态”）复用基础功能用例，降低冗余代码
    3. 测试数据（/data）
      • 存放测试数据
      • 提供测试数据的脚本
    4. 工具(/utils)
      • 工具类集合
  2. 数据驱动设计

　　参数化测试数据（Excel、csv、数据库）

  1. 关键字驱动设计

　　可复用的关键字库（如获取token、查询）

测试执行策略

  1. 触发条件

　　开发人员提交代码触发

手动触发

  1. 优先级划分(暂不考虑)

　　高（核心功能）、中（高频场景）

  1. 失败重试机制

　　自动重试与日志记录

** 持续集成（CI/CD）**

  • 集成流程
  • 代码提交 → 静态检查 → 单元测试 → 自动化测试 → 报告生成
  • 流水线配置
    • GitLab CI YAML配置
  • 结果通知
    • 企业微信群通知

风险管理

  • 潜在风险
    • 环境不稳定
    • 脚本维护成本
    • 需求功能变更
  • 应对措施
    • 设计时需要提前考虑脚本稳定性
    • 定期维护脚本
    • 运行前保证环境正常可用

相关交付物

维护与优化

  • 脚本维护人员
    • 一般情况下谁写的谁维护
  • 脚本维护方法
    • 接口变更的处理

      • 用例执行/定时/手动触发脚本爬取接口文档，并与最新接口文档对比

      • 运行main.py 执行用例时，会在warnning日志提醒相关变更 1743176811159

      • 检查变更是否涉及已经编写的用例（快捷键ctrl+shift+f搜索关键词即可） 1743177028645

        如：PoctCreateOrderInModel存在差异，对应json文档中找到对应 operationId（文件名），在用例文档中搜索createOrder2UsingPOST_1 ，发现涉及已有用例。

        1743177240411

      • 若有涉及用例，则维护成最新接口信息。

    • 当用例运行报错/不通过进行定位
      • bug->记录并通知开发修复；
      • 数据问题->使用自动化专用的数据，避免污染；
      • 脚本本身不稳定导致的运行失败，维护脚本能稳定运行，若维护成功过高可直接先注释脚本，并在对应用例做好备注“待维护”。
  • 脚本维护代办事项

说些什么吧！

giscus