明确版本提测流程及产研质量要求，旨在通过规范化的准入标准、可度量的质量指标、清晰的责任界定，保证提测版本质量，提升研发测试协作效率，降低版本上线风险，形成可追溯、可改进的质量闭环。
本规范适用于ICC产品线所有涉及软件研发、测试活动的项目与版本。所有产研团队成员均需遵守。不满足则有权拒绝提测。
本章定义了版本进入正式测试阶段前必须满足的强制性要求，是提测的“准入门槛”。
所有代码需通过团队内至少一名成员的审查，消除明显逻辑缺陷
通过Sonar、SCA等工具扫描，结果满足以下红线标准（不得突破）：
1. bug数量：红线标准≤ 30个推荐标准= 0个
2. 阻断违规数量：红线标准= 0个推荐标准= 0个
3. 严重违规数量：红线标准≤ 5个推荐标准≤ 1 个
4. 阻断性漏洞：红线标准= 0个推荐标准= 0个
5. 严重漏洞：红线标准≤ 5 个推荐标准= 0个
6. 重要漏洞：红线标准≤ 10 个推荐标准= 0个
注： sonar扫描： 通过静态代码分析，系统性检测代码中的技术债务、可靠性问题、安全漏洞及可维护性风险，提供整体质量画像。 scan扫描： 识别项目所使用第三方依赖库中的已知安全漏洞、许可证合规风险，并管理开源组件清单。
2.2.3 单元测试覆盖率达标
1. 单元测试通过率 100%
2. 全量代码行覆盖率 ≥ 50%
3. 全量代码分支覆盖率 ≥ 40%
4. 增量代码行覆盖率 ≥ 80%
5. 增量代码分支覆盖率 ≥ 70%
2.3 集成和冒烟测试通过
1. 联调完成：
1. 完成跨模块/系统的端到端集成联调
2. 保证提测需求功能点正确实现
2. 冒烟测试通过：
1. 在联调环境执行主流程冒烟测试并通过，确保主流程可正确执行
2. 提供冒烟测试用例执行通过结果，录屏并发送报告
2.4 交付物就绪
技术文档已在知识库更新并同步相关方。配置、脚本等均已就绪。
技术文档包括不限于：
1. 需求文档
2. 设计文档
3. 接口文档
4. 新增配置说明和配置流水线提交
5. 数据库变更说明及脚本
6. 部署说明
注：1）上述质量要求原则上均需满足，特殊情况需向部门提交申请（含原因及改进计划），申请通过后需按计划逐步推进。
2）上述要求为全面的质量目标。当前阶段，提测的强制准入检查项以 第6.2.3节 中定义的清单为准。其他要求（如静态扫描、单元测试覆盖率）团队将逐步通过工具链集成，纳入自动化准入检查。
本章定义了研发团队在提测后需持续关注和改进的质量指标，并明确其责任边界。指标数据应尽可能从DevOps平台自动获取。
|
衡量维度 |
衡量指标 |
目标值 |
考核频率 |
备注与数据来源 |
|
单元测试质量 |
新增代码分支覆盖率 |
详见2.2.3单元测试覆盖率达标 |
每次代码提交/迭代 |
仅考核当期新增代码 |
|
新增代码行覆盖率 |
每次代码提交/迭代 |
仅考核当期新增代码 |
||
|
功能质量 |
新需求测试用例通过率 |
≥ 80% |
每轮测试 |
需求提测后第一轮测试通过率 |
|
新需求门槛测试用例通过率 |
100% |
每轮测试 |
新需求门槛用例 |
|
|
千行代码缺陷密度 |
≤ 5个/K |
按迭代 |
新增每K代码量对应的缺陷数 |
|
|
严重缺陷占比 |
≤ 10% |
按迭代 |
(致命+严重)/总缺陷数 |
|
|
缺陷回归不通过率 |
≤ 5% |
按迭代 |
原场景测试不通过的缺陷/总缺陷数 |
|
|
上线P1/P2事件数 |
0 |
按版本/月度 |
公司层级问题 |
|
|
交付效率 |
提测打回次数 |
0 |
每次提测 |
打回标准见2节 |
|
需求提测准时率 |
≥ 90% |
按迭代 |
按计划准时提测的需求数/总需求数 |
|
|
缺陷平均修复时间(致命&严重) |
≤ 1天 |
按迭代 |
24小时内修复（工作日） |
|
|
缺陷平均修复时间(一般&轻微) |
≤ 2天 |
按迭代 |
48小时内修复（工作日） |
|
|
CI/CD质量 |
CI/CD流水线通过率 |
≥ 95% |
每次构建 |
历史基本功能用例，当前流水线未搭建起来，暂不考核 |
单元测试质量维度旨在衡量代码的自动化测试覆盖程度，确保核心逻辑得到有效验证。
|
指标名称 |
新增代码分支覆盖率 |
新增代码行覆盖率 |
|
|
目标值 |
详见2.2.3单元测试覆盖率达标 |
详见2.2.3单元测试覆盖率达标 |
|
|
考核范围 |
仅考核当期新增代码 |
仅考核当期新增代码 |
|
|
统计口径 |
新增代码中覆盖的分支数 ÷ 新增代码总分支数 × 100% |
新增代码中覆盖的代码行数 ÷ 新增代码总行数 × 100% |
|
|
数据来源 |
SonarQube / JaCoCo / 覆盖率报告 |
SonarQube / JaCoCo / 覆盖率报告 |
|
|
采集频率 |
每次代码合并后自动采集 |
每次代码合并后自动采集 |
|
|
责任主体 |
开发工程师 |
开发工程师 |
|
评分等级 |
新增代码分支覆盖率 |
新增代码行覆盖率 |
含义说明 |
|
好 (A) |
≥ 85% |
≥ 90% |
测试覆盖充分，核心逻辑有完整验证 |
|
中 (B) |
70% - 84% |
75% - 89% |
基本覆盖，存在少量未覆盖逻辑 |
|
差 (C) |
< 70% |
< 75% |
覆盖不足，存在质量风险 |
说明：对于特殊场景（如UI层、复杂异常处理等）可根据实际情况申请调整目标值，需经技术负责人审批。
|
指标名称 |
新需求测试用例通过率 |
新需求门槛测试用例通过率 |
|
目标值 |
≥ 80% |
100% |
|
统计口径 |
首轮测试通过的用例数 ÷ 该需求总用例数 × 100% |
首轮测试通过的门槛用例数 ÷ 该需求门槛用例总数 × 100% |
|
门槛用例定义 |
- 核心业务流程 - P0级功能 - 冒烟测试用例 |
- 核心业务流程 - P0级功能 - 冒烟测试用例 |
|
数据来源 |
测试用例管理系统 |
测试用例管理系统 |
|
采集频率 |
需求提测后首轮测试完成时 |
需求提测后首轮测试完成时 |
|
责任主体 |
开发工程师 |
开发工程师 |
|
评分等级 |
新需求测试用例通过率 |
新需求门槛测试用例通过率 |
含义说明 |
|
好 (A) |
≥ 90% |
100% |
提测质量高，仅少量非核心问题 |
|
中 (B) |
80% - 89% |
100% |
提测质量合格，存在一定问题 |
|
差 (C) |
< 80% |
< 100% |
提测质量差，影响测试进行 |
|
指标名称 |
千行代码缺陷密度 |
|
目标值 |
≤ 5个/K |
|
统计口径 |
(迭代内发现的缺陷总数 × 1000) ÷ 迭代内新增/修改代码行数 |
|
缺陷统计范围 |
- 提测后发现的缺陷 - 回归测试发现的缺陷 - 代码评审发现的缺陷 |
|
排除规则 |
- 重复缺陷 - 无效缺陷（"不是缺陷"、"无法重现"） - 线上缺陷（另有指标统计） |
|
数据来源 |
缺陷管理系统 + 代码仓库 |
|
采集频率 |
迭代结束后 |
|
责任主体 |
开发工程师 |
|
评分等级 |
千行代码缺陷密度 |
含义说明 |
|
好 (A) |
≤ 2.5个/K |
代码质量优秀，缺陷密度很低 |
|
中 (B) |
2.6 - 5.0个/K |
代码质量可控，处于正常范围 |
|
差 (C) |
> 5.0个/K |
缺陷密度过高，需要质量改进 |
|
指标名称 |
严重缺陷占比 |
|
目标值 |
≤ 10% |
|
统计口径 |
(致命缺陷数 + 严重缺陷数) ÷ 总缺陷数 × 100% |
|
缺陷等级定义 |
详见4.1缺陷严重等级定义 |
|
数据来源 |
缺陷管理系统 |
|
采集频率 |
按迭代/版本 |
|
责任主体 |
开发工程师 |
|
评分等级 |
严重缺陷占比 |
含义说明 |
|
好 (A) |
≤ 5% |
严重缺陷控制很好，无明显质量问题 |
|
中 (B) |
6% - 10% |
严重缺陷在可控范围内 |
|
差 (C) |
> 10% |
严重缺陷过多，需分析原因并改进 |
|
指标名称 |
缺陷回归不通过率 |
|
目标值 |
≤ 5% |
|
统计口径 |
回归测试不通过的缺陷数 ÷ 当期回归测试的缺陷总数 × 100% |
|
判定标准 |
缺陷标记为"已修复"，但在验证时发现未修复、修复不完整或引入新问题 |
|
数据来源 |
缺陷管理系统（工作流记录） |
|
采集频率 |
按迭代 |
|
责任主体 |
开发工程师 |
|
评分等级 |
缺陷回归不通过率 |
含义说明 |
|
好 (A) |
≤ 2% |
修复质量高，一次通过率高 |
|
中 (B) |
3% - 5% |
修复质量正常，偶有反复 |
|
差 (C) |
> 5% |
修复质量差，浪费验证时间 |
|
指标名称 |
上线P1/P2事件数 |
|
目标值 |
0 |
|
统计口径 |
统计周期内，生产环境发生的P1/P2级事件总数 |
|
事件等级定义 |
- P1：核心功能完全不可用、大面积故障、数据严重错误 - P2：部分功能受影响、性能明显下降、少量用户受影响 |
|
数据来源 |
事件管理系统 / 运维监控平台 |
|
采集频率 |
按版本/月度 |
|
责任主体 |
全流程（开发、测试、产品、运维） |
|
评分等级 |
上线P1/P2事件数 |
含义说明 |
|
好 (A) |
0 |
无生产事故，发布质量优秀 |
|
中 (B) |
0 |
无事故（此指标仅有好和差） |
|
差 (C) |
≥ 1 |
发生生产事故，需进行事故复盘 |
|
指标名称 |
提测打回次数 |
|
目标值 |
0 |
|
打回标准 |
详见2 提测打回标准 |
|
统计口径 |
统计周期内，被测试团队打回的需求/任务次数 |
|
数据来源 |
测试管理系统 / 提测记录 |
|
采集频率 |
每次提测 |
|
责任主体 |
开发工程师 |
|
评分等级 |
提测打回次数 |
含义说明 |
|
好 (A) |
0 |
提测质量合格，一次通过 |
|
中 (B) |
1 |
偶有打回，需加强自测 |
|
差 (C) |
≥ 2 |
提测质量不稳定，需规范自测流程 |
|
指标名称 |
需求提测准时率 |
|
目标值 |
≥ 90% |
|
统计口径 |
按时提测的需求数 ÷ 计划提测的需求总数 × 100% |
|
准时定义 |
在迭代计划中约定的提测时间点当天完成提测（包括23:59前） |
|
延期处理 |
延期提测需说明原因，影响后续测试排期 |
|
数据来源 |
项目管理工具的提测记录 |
|
采集频率 |
迭代结束时 |
|
责任主体 |
开发工程师/项目经理 |
|
评分等级 |
需求提测准时率 |
含义说明 |
|
好 (A) |
100% |
所有需求准时提测，计划性强 |
|
中 (B) |
90% - 99% |
大部分准时，个别延期可控 |
|
差 (C) |
< 90% |
延期较多，影响迭代节奏 |
|
指标名称 |
缺陷平均修复时间(致命&严重) |
缺陷平均修复时间(一般&轻微) |
|
目标值 |
≤ 1天 |
≤ 2天 |
|
统计口径 |
Σ(致命&严重缺陷修复时长) ÷ 致命&严重缺陷总数 |
Σ(一般&轻微缺陷修复时长) ÷ 一般&轻微缺陷总数 |
|
修复时长计算 |
从缺陷"创建时间"到"修复完成时间"的工作日天数 |
从缺陷"创建时间"到"修复完成时间"的工作日天数 |
|
暂停计时 |
阻塞等待时间不计入（如等待外部依赖） |
阻塞等待时间不计入 |
|
数据来源 |
缺陷管理系统的工作流日志 |
缺陷管理系统的工作流日志 |
|
采集频率 |
按迭代/月度 |
按迭代/月度 |
|
责任主体 |
开发工程师 |
开发工程师 |
|
评分等级 |
致命&严重缺陷修复时间 |
一般&轻微缺陷修复时间 |
含义说明 |
|
好 (A) |
≤ 0.5天 |
≤ 1天 |
响应迅速，修复高效 |
|
中 (B) |
0.6 - 1天 |
1.1 - 2天 |
符合预期，按时完成 |
|
差 (C) |
> 1天 |
> 2天 |
响应慢，影响开发进度 |
|
指标名称 |
CI/CD流水线通过率 |
|
目标值 |
≥ 95% |
|
统计口径 |
(流水线成功执行次数 ÷ 流水线总触发次数) × 100% |
|
测试范围 |
- 代码编译 - 单元测试 - 静态代码扫描 - 构建打包 - 历史基本功能用例（待接入） |
|
当前状态 |
流水线未完全搭建，暂不考核 |
|
数据来源 |
Jenkins / GitLab CI / 流水线平台 |
|
采集频率 |
每次构建 |
|
责任主体 |
开发工程师/运维工程师 |
|
评分等级 |
CI/CD流水线通过率 |
含义说明 |
|
好 (A) |
≥ 98% |
流水线稳定，极少失败 |
|
中 (B) |
95% - 97% |
偶有失败，整体可控 |
|
差 (C) |
< 95% |
频繁失败，影响交付效率 |
对产品需求的理解负有主动确认义务。因未充分沟通导致理解偏差引发的缺陷，由研发承担主要责任。
负责提供准确、完整的接口文档、设计文档。因文档错误或缺失导致的集成问题，由研发承担。
任何代码、接口、配置的变更，必须通过正式渠道及时通知所有受影响方（含测试）。因未通知导致测试漏测，由研发承担全部责任。
确保提测版本满足第2章所有准入标准。出现以下情况，测试有权打回，责任归属研发：
本章定义了测试团队独立的质量活动、度量指标与责任边界。
|
衡量维度 |
衡量指标 |
目标值 |
备注 |
|
测试过程 |
测试完成时间执行进度偏差率 |
≤ 10% |
测试完成时间相对计划延迟不能超过10% |
|
缺陷平均验证周期(P0致命/P1严重) |
≤ 1天 |
24小时内验证（工作日） |
|
|
缺陷平均验证周期(P2一般/P3轻微) |
≤ 2天 |
48小时内验证（工作日） |
|
|
门槛用例提供延迟次数 |
0 |
未按时提供给开发 |
|
|
测试效果 |
缺陷逃逸率（上线发现问题） |
≤ 1% |
核心指标：上线后发现缺陷数/总缺陷数 |
|
上线P1/P2事件数 |
0 |
||
|
测试执行覆盖率 |
100% |
新增用例100%执行 |
|
|
子系统拦截率 |
≥ 80% |
测试发现本模块问题/归属该模块所有问题 |
|
|
测试资产与效率 |
新增自动化有效性及忠诚度 |
100% |
1.用例与自动化一一对应； 2.步骤与手工用例一致 |
|
集成功能回归测试周期 |
≤ 4人/天 |
完成一轮回归测试的工作量 |
|
|
CI/CD自动化测试通过率 |
≥ 95% |
除去产品问题，反映脚本健壮度 |
|
指标名称 |
测试完成时间执行进度偏差率 |
|
目标值 |
≤ 10% |
|
统计口径 |
|实际测试完成时间 - 计划测试完成时间| ÷ 计划测试周期 × 100% |
|
计算公式示例 |
计划3天完成，实际3.2天完成 → 偏差率 = 0.2 ÷ 3 × 100% = 6.67% |
|
统计规则 |
- 仅计算可测试的时间（排除阻塞、等待时间） - 计划变更需重新基线 - 以测试报告提交时间为完成时间 |
|
排除情况 |
- 需求变更导致的测试范围扩大 - 环境不可用等客观阻塞因素 - 开发延期提测导致的计划压缩 |
|
数据来源 |
测试计划文档 / 项目管理工具 / 测试报告 |
|
采集频率 |
每个测试任务结束后 |
|
责任主体 |
测试工程师 |
|
评分等级 |
偏差率范围 |
含义说明 |
|
好 (A) |
≤ 5% |
计划准确，执行偏差极小 |
|
中 (B) |
5% - 10% |
偏差在可接受范围内 |
|
差 (C) |
> 10% |
计划或执行存在较大问题，需复盘 |
|
指标名称 |
缺陷平均验证周期(P0/P1) |
缺陷平均验证周期(P2/P3) |
|
指标代码 |
TEST-VERIFY-P0P1 |
TEST-VERIFY-P2P3 |
|
目标值 |
≤ 1天 |
≤ 2天 |
|
统计口径 |
Σ(缺陷验证时长) ÷ 对应优先级缺陷总数 |
Σ(缺陷验证时长) ÷ 对应优先级缺陷总数 |
|
验证时长定义 |
从缺陷标记为"已解决"到测试验证通过/关闭的时间（工作日） |
从缺陷标记为"已解决"到测试验证通过/关闭的时间（工作日） |
|
暂停计时 |
- 等待开发提供验证环境的等待时间不计 - 等待产品确认的阻塞时间不计 |
- 等待开发提供验证环境的等待时间不计 - 等待产品确认的阻塞时间不计 |
|
数据来源 |
缺陷管理系统的工作流日志 |
缺陷管理系统的工作流日志 |
|
采集频率 |
按迭代/月度 |
按迭代/月度 |
|
责任主体 |
测试工程师 |
测试工程师 |
|
评分等级 |
P0/P1缺陷验证周期 |
P2/P3缺陷验证周期 |
含义说明 |
|
好 (A) |
≤ 0.5天 (4小时) |
≤ 1天 |
验证及时，响应迅速 |
|
中 (B) |
0.6 - 1天 |
1.1 - 2天 |
符合预期，按时验证 |
|
差 (C) |
> 1天 |
> 2天 |
验证滞后，可能影响迭代节奏 |
特别说明：
|
指标名称 |
门槛用例提供延迟次数 |
|
目标值 |
0 |
|
门槛用例定义 |
- 冒烟测试用例（核心业务流程） - P0级功能验证用例 - 提测准入的基本功能用例 |
|
提供时间要求 |
需求进入开发前，或至少提测前2个工作日提供给开发 |
|
延迟判定 |
开发提测时，门槛用例仍未提供即计为1次延迟 |
|
统计口径 |
统计周期内，门槛用例提供时间晚于要求的次数 |
|
数据来源 |
测试用例管理系统 / 需求文档 / 沟通记录 |
|
采集频率 |
每次需求 |
|
责任主体 |
测试工程师 |
|
评分等级 |
延迟次数 |
含义说明 |
|
好 (A) |
0 |
用例准备及时，开发可提前了解测试要点 |
|
中 (B) |
0 |
（此指标仅有好和差之分） |
|
差 (C) |
≥ 1 |
用例提供延迟，影响开发自测或提测质量 |
|
指标名称 |
缺陷逃逸率 |
|
目标值 |
≤ 1% |
|
统计口径 |
(生产环境发现的缺陷数 ÷ 总缺陷数) × 100% |
|
总缺陷数定义 |
线上缺陷数 + 测试阶段发现的缺陷数 |
|
线上缺陷统计 |
- 用户反馈并确认的缺陷 - 监控系统发现的程序错误 - 线上事件中确认为代码缺陷的部分 |
|
排除规则 |
- 需求变更/新需求（非缺陷） - 环境配置问题 - 数据问题（非代码导致） |
|
数据来源 |
缺陷管理系统 + 事件管理系统 |
|
采集频率 |
按版本/月度 |
|
责任主体 |
测试团队 |
|
评分等级 |
缺陷逃逸率 |
含义说明 |
|
好 (A) |
≤ 0.5% |
测试覆盖充分，漏测极少 |
|
中 (B) |
0.6% - 1.0% |
漏测在可控范围内 |
|
差 (C) |
> 1.0% |
漏测较多，需分析测试盲区 |
|
指标名称 |
上线P1/P2事件数 |
|
目标值 |
0 |
|
统计口径 |
统计周期内，生产环境发生的P1/P2级事件总数 |
|
事件等级定义 |
- P1：核心功能完全不可用、大面积故障、数据严重错误 - P2：部分功能受影响、性能明显下降、少量用户受影响 |
|
与测试相关的责任界定 |
- 因测试未覆盖导致 → 测试负主要责任 - 因需求理解偏差导致 → 测试/产品共同责任 - 因环境差异导致 → 测试/运维共同责任 |
|
数据来源 |
事件管理系统 / 运维监控平台 |
|
采集频率 |
按版本/月度 |
|
责任主体 |
测试团队（作为质量门禁的最后一道防线） |
|
评分等级 |
上线P1/P2事件数 |
含义说明 |
|
好 (A) |
0 |
无生产事故，测试拦截有效 |
|
中 (B) |
0 |
无事故（此指标仅有好和差） |
|
差 (C) |
≥ 1 |
发生生产事故，需进行事故复盘 |
|
指标名称 |
测试执行覆盖率 |
|
目标值 |
100% |
|
统计口径 |
(实际执行的用例数 ÷ 计划执行的用例总数) × 100% |
|
计划执行用例范围 |
- 本次测试范围涉及的所有新增用例 - 本次测试范围涉及的回归用例 - 计划中明确需要执行的用例 |
|
未执行处理 |
未执行的用例必须在测试报告中说明原因 |
|
可接受的未执行原因 |
- 需求变更导致用例失效 - 环境问题且短期内无法解决 - 优先级调整（需审批） |
|
数据来源 |
测试用例管理系统 / 测试执行记录 |
|
采集频率 |
每轮测试结束后 |
|
责任主体 |
测试工程师 |
|
评分等级 |
测试执行覆盖率 |
含义说明 |
|
好 (A) |
100% |
所有计划用例均执行，测试完整 |
|
中 (B) |
95% - 99% |
个别用例未执行，有合理说明 |
|
差 (C) |
< 95% |
大量用例未执行，测试不完整 |
|
指标名称 |
子系统拦截率 |
|
目标值 |
≥ 80% |
|
统计口径 |
(测试发现的归属本模块的缺陷数 ÷ 归属该模块的所有缺陷数) × 100% |
|
分母定义 |
测试发现的归属本模块缺陷数 + 集成测试发现的归属本模块缺陷数 + 线上发现的归属本模块缺陷数 |
|
分子定义 |
测试阶段发现的、缺陷归属为本模块的问题（包括功能测试、自动化测试等） |
|
统计意义 |
衡量测试在自身负责模块的缺陷发现能力，数值越高说明本模块测试越充分 |
|
数据来源 |
缺陷管理系统（按模块归属） |
|
采集频率 |
按迭代/月度 |
|
责任主体 |
测试工程师 |
|
评分等级 |
子系统拦截率 |
含义说明 |
|
好 (A) |
≥ 90% |
测试充分，绝大部分问题在本模块发现 |
|
中 (B) |
80% - 89% |
拦截能力良好，偶有漏测到集成阶段 |
|
差 (C) |
< 80% |
拦截能力不足，问题外溢到后续阶段 |
|
指标名称 |
新增自动化有效性及忠诚度 |
|
目标值 |
100% |
|
定义说明 |
这是一个复合指标，包含两个核心要求： 1. 一一对应：每条自动化用例对应一条手工用例，无冗余/缺失 2. 步骤一致：自动化用例的验证步骤与手工用例完全一致，保证测试逻辑不变 |
|
统计口径 |
(符合要求的自动化用例数 ÷ 新增自动化用例总数) × 100% |
|
符合要求判定标准 |
- 可在自动化平台查询到对应的手工用例ID - 自动化脚本覆盖了手工用例的所有验证点 - 无额外的不相关验证逻辑 - 用例命名和描述能清晰对应 |
|
不符合情况示例 |
- 一条自动化覆盖多条手工用例（无法准确定位失败原因） - 自动化脚本验证逻辑与手工用例不一致 - 没有对应的手工用例记录 - 手工用例已失效但自动化仍在运行 |
|
数据来源 |
自动化测试平台 + 手工用例库 |
|
采集频率 |
每次自动化代码提交/每周统计 |
|
责任主体 |
自动化测试工程师 |
|
评分等级 |
自动化有效性 |
含义说明 |
|
好 (A) |
100% |
自动化用例管理规范，与手工用例完美对应 |
|
中 (B) |
95% - 99% |
存在少量对应问题，需优化改进 |
|
差 (C) |
< 95% |
自动化用例管理混乱，难以维护和定位问题 |
|
指标名称 |
集成功能回归测试周期 |
|
目标值 |
≤ 4人/天 |
|
统计口径 |
回归测试投入的总人天数 |
|
计算公式 |
参与测试人数 × 测试天数 |
|
示例 |
2人测试2天 → 4人/天；4人测试1天 → 4人/天 |
|
统计范围 |
- 环境准备时间 - 用例执行时间 - 结果记录与分析时间 - 缺陷复现与初步定位时间 |
|
排除范围 |
- 缺陷修复时间（属开发） - 等待时间（环境不可用等） - 测试报告编写时间 |
|
数据来源 |
测试工时记录 / 项目管理工具 |
|
采集频率 |
每次版本回归测试后 |
|
责任主体 |
测试团队 |
|
评分等级 |
回归测试周期 |
含义说明 |
|
好 (A) |
≤ 2人/天 |
回归效率高，可能受益于自动化程度高 |
|
中 (B) |
2.1 - 4人/天 |
回归效率符合预期 |
|
差 (C) |
> 4人/天 |
回归耗时过长，影响发布效率 |
|
指标名称 |
CI/CD自动化测试通过率 |
|
目标值 |
≥ 95% |
|
统计口径 |
(自动化测试成功执行并通过的次数 ÷ 自动化测试总执行次数) × 100% |
|
统计范围 |
- CI/CD流水线中集成的所有自动化测试 - 单元测试、接口测试、UI自动化测试等 |
|
失败原因分类 |
1.产品问题：代码缺陷导致用例失败 2. 脚本问题：自动化脚本自身不稳定或断言错误 3. 环境问题：测试环境不可用、数据问题 4. 框架问题：测试框架或依赖问题 |
|
目标值说明 |
目标值≥95%是指"脚本问题+环境问题"导致的失败率控制在5%以内，反映脚本健壮度 |
|
数据来源 |
Jenkins / 流水线平台 / 自动化测试报告 |
|
采集频率 |
每次构建/每日统计 |
|
责任主体 |
自动化测试工程师 |
|
评分等级 |
自动化测试通过率（脚本健壮度） |
含义说明 |
|
好 (A) |
≥ 98% |
脚本非常稳定，极少因脚本问题失败 |
|
中 (B) |
95% - 97% |
脚本稳定，偶有不稳定因素 |
|
差 (C) |
< 95% |
脚本不稳定，频繁误报，需优化维护 |
注：此指标不考核产品问题导致的失败，仅考核"非产品问题"的比例。
更精确的计算方式：脚本健壮度 = 1 - (非产品问题导致的失败次数 ÷ 总执行次数) × 100%其中：非产品问题 = 脚本问题 + 环境问题 + 框架问题
对产品需求的理解负有确认义务。在研发已明确通知变更的前提下，因测试分析遗漏导致的用例缺失，由测试承担全部责任。
对已覆盖的测试用例，因执行遗漏或验证不充分导致缺陷逃逸至上线的，由测试承担主要责任。
有权根据第2章拒绝接收不达标版本，并对版本质量给出客观评估。
负责业务层自动化测试脚本的编写、维护与忠诚度（与手工用例一致）。
本章定义跨系统、跨模块协作中出现问题时的定责原则与流程，是第3、4章责任条款在技术协作层面的延伸和具体化。
|
问题类型 |
定责标准 |
主要责任方 |
|
接口定义问题 |
接口文档与实际实现不一致 |
接口提供方 |
|
数据格式问题 |
返回数据格式不符合约定 |
接口提供方 |
|
调用方式问题 |
调用参数错误、超时设置不当 |
接口调用方 |
|
数据校验问题 |
未对输入数据进行校验导致异常 |
接口提供方 |
|
异常处理问题 |
未处理接口异常导致系统崩溃 |
接口调用方 |
|
性能问题 |
接口响应超时或吞吐量不足 |
接口提供方 |
|
兼容性问题 |
接口升级未向下兼容 |
接口提供方 |
|
依赖服务问题 |
依赖的第三方服务不可用导致功能异常 |
依赖服务提供方 |
问题发现阶段
初步定位阶段
责任判定阶段
问题修复阶段
复盘改进阶段
接口管理机制
变更通知机制
监控告警机制
质量度量机制
通过这套定责标准，可以有效减少模块间推诿扯皮，提升研发协作效率，确保系统稳定性和可维护性。
本节记录了ICC产品线过往使用的邮件提测流程。自DevOps平台提测流程（见6.2节）正式生效后，邮件提测方式已不再作为标准提测渠道。本节内容主要供历史追溯和参考，所有新版本提测请统一遵循6.2节的DevOps平台流程。
背景：在DevOps平台全面推广前，团队通过邮件方式进行版本提测通知。
目标：
按研发阶段划分，版本提测包括：子系统提测、产品提测、项目提测。
在发送提测邮件通知相关干系人前，必须满足以下所有条件：
子系统提测：
产品/项目提测：
通用条件：
发件人与收件人：
邮件主题：
邮件内容：
\产品管理\产品力建设专项\产品版本管理\<版本号>\测试文档。本节明确了通过DevOps平台进行提测的核心原则、质量标准和执行要求，是团队必须遵守的基准，旨在统一提测流程，实现系统化、线上化管理，保障交付质量。
背景：为统一产研团队在敏捷迭代模式下的提测方式，杜绝邮件、口头等不统一形式，推荐统一通过DevOps平台测试管理进行提测。
目标：
提测前必须全部满足以下条件，测试人员有权对不达标提测单执行打回：
注：本清单是当前通过DevOps平台提测的强制检查项。团队更全面的质量目标（如代码扫描、单元测试覆盖率等）请参见本规范 第2节 提测质量要求。
模板
1、提测版本：icc-au-admin:test_R2.3.8.0
2、RD建议回归覆盖范围： *
2.1 xxx功能模块；
2.2 xxx功能模块；
2.3 ....
3、研发资料单：https://weikezhijia.feishu.cn/docx/PU5LdiPFRoxhp2x7VDDcL9X4ntb关键字段：
test_Rx.x.x.x）。本规范按季度进行定期回顾。
|
回顾周期 |
回顾日期 |
备注 |
|
第1次回顾评估日期 |
规范生效后一个季度 |
|
|
第2次回顾评估日期 |
||
|
第3次回顾评估日期 |
||
|
.... |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。