一、总则

1.1 背景与目的

背景：当前开发自测流程存在不规范、自测覆盖不充分等问题，导致提测版本质量偏低，线下环境缺陷数量偏高，影响测试效率与产品交付周期。
目的：通过标准化测试用例编写、开发自测流程及软件提测标准，实现以下目标：

• 提升开发代码质量，减少潜在缺陷；
• 提高测试执行效率，缩短测试周期；
• 降低线下环境缺陷数量，保障产品稳定性。

1.2 适用范围

本规范适用于公司所有业务线（优先覆盖订货、物流模块）的软件开发项目，涉及测试、开发、产品等相关角色，明确各环节的职责与操作标准。

二、测试用例编写规范

2.1 用例格式标准

测试用例需包含前置条件、测试标题、测试步骤、预期结果四大核心要素，格式如下表所示：

字段	说明	示例
前置条件	选填，执行用例前需满足的环境配置、数据状态等条件	1. 系统已登录管理员账号； 2. 数据库中存在测试账号：test_user01
测试标题	需明确验证的功能点，格式为“[模块]-[功能]-[场景]”	“[异常原因配置]-[新增] -[正常场景：填写完整字段提交]”
测试步骤	按操作顺序描述具体步骤，每步操作需清晰可执行	1. 点击“新增异常原因”按钮； 2. 输入异常原因：“配送延迟”； 3. 点击“确定”
预期结果	每步操作对应的预期系统行为，需可量化、可验证	1. 弹窗关闭； 2. 列表刷新并显示“配送延迟”记录； 3. 数据库新增记录（ID=xxx）

2.2 用例编写要求

1. 独立性：每条用例需独立可执行，不依赖其他用例的执行结果；
2. 无歧义：描述需清晰准确，避免“可能”“大概”等模糊词汇，例如将“数据正确显示”细化为“列表第1条记录姓名为‘测试’，ID为‘123’”；
3. 可测试性：需将产品需求规则转化为可验证的操作，例如需求“用户密码需包含大小写字母”，用例需明确“输入仅小写字母的密码（如‘test123’），验证系统提示‘密码需包含大写字母’”；
4. 覆盖完整性：需覆盖核心流程、主功能点、边界条件、异常场景（如参数为空、超长字符、枚举值错误等）。

2.3 用例评审机制

1. 评审参与方：测试、开发、产品三方必须参与，确保需求理解一致；
2. 评审内容：检查用例是否覆盖需求点、是否符合编写规范、是否存在遗漏或冗余；
3. 结果同步：评审后需将需求理解错误、遗漏或不确定的点在项目群同步，并在24小时内完成用例补充或修改，修改记录需存档。

2.4 用例管理要求

• 测试用例需以 XMind格式 输出（参考示例：【ID1154837】+【订补货运营配置】生产日期数规则.xmind）；
• 需通过标签区分测试类型：后端自测用例打 标签1，前端自测用例打 标签2，场景用例需同时标注前后端责任方。

三、开发自测规范

3.1 自测范围与比例

开发需对以下范围的用例进行自测，确保覆盖关键风险点：

• 核心流程（如订单创建-支付-发货全链路）；
• 主功能点（如异常原因新增、编辑、删除功能）；
• 边界条件（如参数长度限制、枚举值边界）；
• 业务特殊规则（如“处理方为朴朴物流主管时，定责值必须为否”）；
• 历史高频缺陷点（参考测试报告中“自测不足”类缺陷记录）。

自测比例要求：

• 后端单接口用例：100%自测；
• 前端功能用例：50%自测（可上下浮动，优先覆盖主流程）；
• 场景用例（含前后端交互）：50%自测，需前后端联合执行。

3.2 自测环境与工具

• 自测需在 独立测试环境 执行，禁止在开发本地环境或生产环境自测；
• 后端需使用公司接口测试平台自测通过；
• 数据准备需使用 造数工厂，优先覆盖“边界数据、异常数据、典型业务数据”三类场景。

3.3 自测结果记录与反馈

1. 结果标记：

   • 自测通过用例：打 ✅，并在预期结果后补充 实际结果（如截图、业务单号、SQL查询结果或日志片段）；
   • 自测未通过用例：打 ❌，需标注失败原因（如“接口返回500错误”），并附错误截图或日志。

   示例：

   • 预期结果：数据库transportwaybillexceptionreasons表新增一条记录；
   • 实际结果：执行SQL select * from transportwaybillexceptionreasons where id='5003c380'，返回1条记录，字段has_deleted=0。

2. 自测完成标准：

   • 所有标记为“需自测”的用例（标签1/2）均完成执行，无未标记用例；
   • 自测通过率需达到 100%（未通过用例需修复后重新自测）；
   • 需将含自测结果的XMind用例文件回发给测试负责人，文件命名格式：“[项目名]-[模块]-自测结果-[日期].xmind”。

3.4 自测验收

测试人员需对开发自测结果进行验收，验收内容包括：

• 用例覆盖完整性：检查是否存在漏测用例；
• 结果真实性：随机抽取30%的通过用例，在测试环境复现验证；
• 记录规范性：检查实际结果是否包含截图、单号等可追溯信息。
  验收不通过：若发现用例漏测、结果造假或记录不规范，测试有权将提测申请打回，要求开发重新自测。

四、软件提测规范

4.1 提测前置条件

开发提交提测申请前，需满足以下条件：

1. 自测完成：所有标记为“需自测”的用例100%通过，自测结果已回发测试；
2. 环境就绪：测试环境已部署最新代码，数据库脚本已执行，无环境依赖问题；
3. 文档齐全：接口文档（含新增/修改接口）、技术方案已同步至测试；
4. 风险排查：已知未修复缺陷需标注“风险点”，并评估对测试的影响范围。

4.2 提测流程

1. 提测申请：开发在项目管理平台提交提测单，填写版本号、模块、自测结果链接、风险点说明等信息；
2. 准入检查：测试负责人在 1个工作日内 完成提测检查，通过则进入测试阶段，未通过则打回并注明原因；
3. 测试执行：测试按计划执行用例，优先验证开发自测通过的用例（抽测比例根据需求复杂度自定义，通常为30%-50%）。

表2：提测准入检查项

检查项	检查标准	责任方
自测用例覆盖率	标签1/2用例100%执行，无遗漏	测试
环境稳定性	系统无频繁重启、接口响应时间<3s	开发/运维
文档一致性	接口文档与代码实现一致，无字段缺失或类型错误	测试

4.3 提测失败处理

若提测检查未通过（如自测用例覆盖率不足、环境不稳定），测试需在提测单中注明具体问题，开发需在 2个工作日内 完成整改并重新提交提测申请。同一版本提测失败 ≥2次 时，需组织开发、测试、产品三方评审，分析根因并制定改进措施。

五、落地执行与监督

5.1 执行要求

• 自测未通过禁止提测：开发未完成100%自测或自测结果未通过验收，测试有权拒绝接收提测；
• 缺陷根源记录：测试发现的缺陷，若根因为“开发未自测或自测不充分”，需在缺陷管理系统中标记 “缺陷根源=自测不足”，并同步至开发负责人；
• 定期复盘：项目迭代结束后，测试需输出《开发自测质量报告》，统计“自测用例总数、自测发现缺陷数、线下缺陷数”等指标，作为开发绩效评估依据。

5.2 试点方案（订货、物流模块）

针对订货、物流模块的非核心需求，试点“开发自测+测试抽测”模式，具体规则如下：

1. 需求标记：需求评审后，测试评估可试点的需求，打 “抽测模式”标签；
2. 工时折算：测试评估工时需包含开发自测时间，例如总测试工时3天，需分配1天给开发自测，测试实际执行时间为2天；
3. 用例区分：测试用例需明确分为“前端用例、单接口用例、场景用例”，后端单接口用例需100%自测，前端及场景用例按50%自测；
4. 责任共担：测试对开发自测通过的用例进行抽测，若抽测通过的用例在上线后出现缺陷，开发与测试按7:3比例承担责任。

六、附则

本规范自发布之日起执行，由测试部门负责解释与修订。各业务线需在1个月内完成全员培训，确保规范落地。