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。
