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或测试用例。
测试排期
根据需求的优先级和提测时间，测试进行工期评估，并排期。
测试工期评估依据及优化（后期）
上线节点
- 给出测试报告（原来）
- 测试用例（原来）
- BUG链接（测试环境）
关于每周周报BUG分类
BUG按紧急程度分为高、中、低，按BUG发现的等级分为了A、B、C
H：严重，必须立即修改| 后期需要更改
M：一般，本次版本需要解决
L：微小，可不在本次版本解决
A: 能明确给开发说明，指出修改意见的BUG
B: BUG产生原因清晰，能重现定位
C: 不能重现，描述不清晰，无法定位 和 页面展示级别的BUG。
网友评论