质量追踪-一切数据说话

目录

面临问题

方法论

数据支撑质量

[一段时间内]有多少次需求变动、插入需求、紧急需求上线、hotfix

[一段时间内]有多少需求、上线、回滚

[每次迭代]各个节点出现了多少问题

[一段时间内]线下bug数据(严重级别、根源、修复周期等等)

[一段时间内]线上bug数据(严重级别、根源、修复周期等等)

---

面临问题

• 月末、季度末、年末，为了用数据来”证明“自己的成绩，于是不得不到处搜刮数据；实在找不到了，就粗略估计、一拍脑袋给个数字。
• 测试报告，几乎每个QA都写过这个，不仅内容五花八门，而且看了半天，根本不知道想表达什么，不能起到”有则改之无则加勉“的效果
• 重复工作反复做。例如，统计每个人的工时，无论是QA，还是开发人员，需要反复写自己的工时。例如，排期写一次、建任务写一次、周报写一次、月报写一次...

以下是在项目中经过实践，外加上自己的一些心得体会，如有不同意见，欢迎交流！！！

方法论

第一阶段——线下完整手工记录需要的数据

第二阶段——将线下的操作挪到线上

数据支撑质量

[一段时间内]有多少次需求变动、插入需求、紧急需求上线、hotfix

图表参考自：https://blog.csdn.net/Jora_Zhang/article/details/62884198

[一段时间内]有多少需求、上线、回滚

[每月质量]线下线上的质量

质量	指标	内容	分析
线下质量	上线次数	A级项目：2(八爪鱼模块、平台) B级项目：2 C级项目：15	C级项目上线较为频繁
	提测质量	自测通过率：50%（项目维度,排除C级项目）	本月由于A级项目提测质量不高，bug总数、严重bug总数比9月，10月 大幅度增长
	测试质量	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，禅道，公司/团队自行开发的平台