Keywords: 提高准入标准、增加冒烟测试、增加各节点质量效率(进度)评估

BUG质量

规范BUG录入标准

BUG 优质级别从测试评估维度出发  
BUG 严重程度从开发评估维度出发  

1.统一BUG标题格式：（为BUG分析做准备）

• 新需求BUG：【需求名(版本号)】(【性能/兼容/安全】)模块-BUG详情；
• 非新需求BUG：【系统测试】(【优化】)-BUG详情。

备注：非新需求BUG为与当前版本无关的BUG，( )中的内容为选填。

标准BUG样例：
内部图，略

2.严重级别（H，M，L）（必填）

• H：影响测试流程，0级用例的BUG；
• M：一般功能性BUG；
• L：不重要功能性BUG。

3.BUG是否优质级别（A，B，C）

• A：级别高，能够复述详细步骤，写出分析过程，并找到BUG产生原因；
• B：一般的BUG，好的建议性BUG；
• C：非测试人员也可发现的BUG和一般性建议的BUG。

4.优先级P（此项暂不在考核中）

• P2：紧急；
• P4：不紧急。

增加BUG分析

1.每个测试人员对 预发布/线上 的BUG分析原因，并打上【预发布】、【生产环境】的标签。禁止出现的悬空BUG，如：

• BUG标题中无【需求名】，无【系统测试】；
• Label中无【预发布】，无【生产环境】。

2.每个测试人员提报 改了3次及以上的BUG，超过3天未改的BUG。需测试人员在功能上线后给出。

3.初步计划1个月出一次BUG分析报告（报告格式后期给出）

Keywords
总BUG数，新功能BUG率，预发布BUG率，上线BUG率；
同比上月的增长率；
每周跟进进度，每天跟进重要的时间节点。

提测节点

按照开发周报的任务进度：标记提测

提测issues标准

1.需求背景或背景需求链接；

2.需求内容（文字描述或给出接口文档）（必填）；

3.改动点（选填）；

4.测试点（必填）（同一个需求同一个人建议不要分步提测）。

提测issues打回标准

每个节点共5个，需记录打回原因，作为提测质量的依据

1.单元测试阶段

• 构建 ——节点1
• 单元测试 ——节点2
• 静态代码分析 ——节点3

2.API层冒烟测试 ——节点4

• 第一阶段：功能点测试，开发自测0级测试不通过联调未通过或测试环境问题导致整个需求无法测试；
• 第二阶段：API 功能自助测试。

3.提测issues： ——节点5

• 测试内容未填写或只有1句话；
• 接口提测issues，无接口文档；
• 无测试点。

测试准备

1.功能性issues

用例分类等级

• 0级：阻塞测试流程的主要功能点；
• 1级：重要功能点；
• 2级：非重要功能点及常用异常点；
• 3级：非常用异常点。

产品提需求前或开发做需求前将需求文档和技术方案同步给测试； 测试在提测前给出测试用例-0级用例必写，1级2级3级可提测后测试前给出或给出需要开发自测的xmind测试点。

2.开发驱动的需求

• 开发给出内容及测试点；
• 测试在提测后给出xmind或测试用例。

测试排期

根据需求的优先级和提测时间，测试进行工期评估，并排期。
测试工期评估依据及优化（后期）

上线节点

1. 给出测试报告（原来）
2. 测试用例（原来）
3. BUG链接（测试环境）

---

关于每周周报BUG分类

BUG按紧急程度分为高、中、低，按BUG发现的等级分为了A、B、C

H：严重，必须立即修改| 后期需要更改

M：一般，本次版本需要解决

L：微小，可不在本次版本解决

A: 能明确给开发说明，指出修改意见的BUG

B: BUG产生原因清晰，能重现定位

C: 不能重现，描述不清晰，无法定位 和 页面展示级别的BUG。