质量追踪-一切数据说话
目录
[一段时间内]有多少次需求变动、插入需求、紧急需求上线、hotfix
[一段时间内]线下bug数据(严重级别、根源、修复周期等等)
[一段时间内]线上bug数据(严重级别、根源、修复周期等等)
面临问题
- 月末、季度末、年末,为了用数据来”证明“自己的成绩,于是不得不到处搜刮数据;实在找不到了,就粗略估计、一拍脑袋给个数字。
- 测试报告,几乎每个QA都写过这个,不仅内容五花八门,而且看了半天,根本不知道想表达什么,不能起到”有则改之无则加勉“的效果
- 重复工作反复做。例如,统计每个人的工时,无论是QA,还是开发人员,需要反复写自己的工时。例如,排期写一次、建任务写一次、周报写一次、月报写一次...
以下是在项目中经过实践,外加上自己的一些心得体会,如有不同意见,欢迎交流!!!
方法论
第一阶段——线下完整手工记录需要的数据
第二阶段——将线下的操作挪到线上
数据支撑质量
[一段时间内]有多少次需求变动、插入需求、紧急需求上线、hotfix
图表参考自:https://blog.csdn.net/Jora_Zhang/article/details/62884198
[一段时间内]有多少需求、上线、回滚
[每月质量]线下线上的质量
质量 |
指标 |
内容 |
分析 |
---|---|---|---|
线下质量 |
上线次数 |
A级项目:2(八爪鱼模块、平台) B级项目:2 C级项目:15 |
C级项目上线较为频繁 |
提测质量 |
自测通过率:50%(项目维度,排除C级项目) |
|
|
测试质量 |
bug总数:175 p1/p2严重bug总数:43 严重bug比:43/175=24.6% |
||
线上质量 |
线上case情况 |
case总数:80 case总数(系统原因产生case):25 top3 case总数(系统原因产生case):23 |
线上case总数量呈下降趋势; 自测上线导致的系统问题较多 |
线上监控 |
接口监控告警次数:3 |
告警原因:dc服务 内存fullgc导致接口超时 处理方案:fullgc问题通过添加router解决(doing); |
[每次迭代]各个节点出现了多少问题
举例:
评估点 |
目标 |
关注数据 |
数据统计 |
---|---|---|---|
需求管理
|
需求评审后无重大变更 |
需求变动情况(自需求评审文档最终版提供后,是否有需求重大变动影响了开发进度,测试进度等) |
正常 |
需求文档及时提供 |
需求评审文档在需求评审会前及时提供 |
||
提测质量 |
提测及时 |
按需求排期正常完成开发并提测
|
正常 |
开发自测质量通过冒烟测试 |
提测时冒烟测试情况 |
A级项目自测质量偏差 B级项目提测质量尚可 |
|
测试质量 |
测试进度及时周知 |
测试进度每天周知给团队成员 |
正常 |
质量风险及时周知 |
缺陷、环境问题等导致的上线质量风险及时周知给团队成员 |
正常 |
|
上线质量 |
上线内容完整 |
上线内容(包括DB相关,权限相关,代码相关)是否有遗留 |
正常 |
按排期及时上线 |
上线是否delay |
正常 |
|
正常上线不被干扰 |
是否被其他问题干扰(mini及线上回归验证不通过) |
正常 |
|
线上质量 |
用户问题反馈及时处理 |
运营反馈case情况 |
正常 |
接口服务稳定 |
接口监控告警情况 |
告警 |
[一段时间内]线下bug数据(严重级别、根源、修复周期等等)
通过类似bugfree,禅道,公司/团队自行开发的平台
[一段时间内]线上bug数据(严重级别、根源、修复周期等等)
通过类似bugfree,禅道,公司/团队自行开发的平台