API 单测开发及验收规范

API 单测开发规范

API 单测的测试点需覆盖以下场景:

API 单测验收规范

API 单测的验收包含两方面,一方面是要验收是否符合上述的开发规范,另一方面要验收是否符合以下的通用规范:

  • 命名规范

    • 单测中需要有充分的断言检查,单测 case 禁止使用 test1/test2 等无实际含义的命名方式。

    • API 单测命名、参数命名、暴露方式、代码目录层级需要与设计文档保持一致,可参考API 通用设计文档要求。

  • 提交规范

    • 单元测试内容需要和开发代码放在同一个 PR 提交,后续修改也需要基于此 PR。

    • 对于 API 单测增强任务,需在 PR 描述中(可参考 PR41191)写明每个算子缺失的单测、问题定位及修复思路的简单描述

  • 覆盖率规范:PR 需要通过所有的 CI 验证,且PR-CI-Coverage需要满足新增代码行覆盖率达到 90%以上,覆盖率信息可通过 CI 详情页面查看,如下: coverage_not_pass.png

  • 耗时规范

    • 新增单测的执行不允许超过 15s,PR-CI-Coverage有相应的检查,检查逻辑可见 tools/check_added_ut.sh。如果你新增的单测无法在 15s 内执行完成,可以尝试减少数据维度(可见链接)或通过在CMakeLists.txt指定该单测的 Timeout 时间。如果你通过修改 Timeout 时间,你需要在 PR 描述中说明原因,同时会有相关同学 review 后进行 approve 后才能合入。原则上 Timeout 设定时间不能超过 120s。 add_ut.png

    • 现有单测的修改原则上不允许超过 120s,PR-CI-Coverage有相应的检查,若有特殊情况可修改CMakeLists.txt文件中该单测的 Timeout 时间,处理逻辑同上诉新增单测超过 15s 一致。

  • 单测 retry 机制:为提高单测执行效率,所有的单测均以一定的并发度执行,而这样的策略可能会引起单测随机挂。因此对失败的单测设定了 retry 机制,一共 retry 四次,如果成功率未达到 50%,就认为该单测可能存在问题,CI 失败。

交流与改进

PR 内容会有 Paddle 同学及 Paddle QA 同学进行 review,确保完整覆盖了待测功能点后,会给予 approved。

若 review 过程中发现测试缺失和遗漏的测试点,会通过 github 代码行 comment 的和 request changes 的方式交流改进,待 PR 修改完毕后给予 approved。

后续维护

代码成功 merge 后,如果发现对框架造成了严重影响,例如阻塞了某些方向的功能开发,或者和部分功能存在严重冲突导致 Bug,会对代码进行 Revert 并通知贡献者。待对 PR 修复后重新合入。