新增API 测试及验收规范

CI通过性

进入PaddlePaddle主库的代码,涉及到的相关检测CI必须全部Pass。用来验证对之前功能点的兼容和影响,用来保障新合入代码对历史代码不产生影响。

新增代码必须要有相应的单测保障测试覆盖率达到准入要求(测试覆盖率(行覆盖率)90%)。

PR内容描述要求

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

PR内容描述测试部分需要明确指出测试相关的文件列表,并写明测试Case的运行方法和自测结果。

API测试内容及单元测试要求

API命名,参数命名,暴露方式,代码目录层级需按照设计文档要求保持一致或参考API通用设计文档的要求。

新增API测试代码必须覆盖动态图和静态图的测试场景。(原则上需要支持动态图和静态图两种方式调用,如果仅支持其中一种,需要在设计文档RFC和API文档中体现)

新增API测试代码必须覆盖CPU和GPU的测试场景。(原则上需要支持CPU和GPU两种硬件平台调用,如果仅支持其中一种,需要在设计文档RFC和API文档中体现)

新增API涉及tensor的dtype需要有相关Case进行测试覆盖。

新增API的入参,需要对全部入参进行参数有效性和边界值测试。确定每个入参都可以正确生效。

新增API的前向计算,需要对数值的绝对正确性进行验证,需要有通过numpy或其他数学方法实现的函数的对比结果。

新增API的反向计算,需要复用现有单测框架反向计算验证方式保障反向正确性。

  • 使用Python组合方式新增的API,由于反向计算已经在各组合API单测中分别验证了,因此,该API的反向计算不要求验证。

  • 如现有单测框架无法满足要求,需要通过numpy推导或函数直接实现反向等方式验证反向计算结果正确性。

异常测试,对于参数异常值输入,应该有友好的报错信息及异常反馈,需要有相关测试Case验证。

文档测试

中文文档、英文文档齐全,内容一一对应。

文档清晰可读,易于用户使用

给出易于理解的api介绍,文字描述,公式描述。

参数命名通俗易懂无歧义,明确给出传参类型,对参数含义以及使用方法进行详细说明,对返回值进行详细说明。

异常类型和含义进行详细说明。

示例代码需要做到复制粘贴即可运行,并且需要明确给出预期运行结果(如果可以)。

阅读无障碍:无错别字、上下文连贯、内容清晰易懂、链接可正常跳转、图片公式显示正常。

交流与改进

提测代码的单测部分必须paddlepaddle测试人员review,确保完整覆盖了待测功能点后,会给予approved。如果review过程中发现测试缺失和遗漏的测试点,会通过github代码行comment的和request changes的方式交流改进,待PR修改完毕后给予approved。

后续维护

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