测试质量报告-为了更好的下一个

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/u010321474/article/details/50618289

测试质量报告的几个方面:

1.bug率(千行代码产生的bug数量)

千行代码数(即项目中产生或者改动了几千行代码)代表了项目的规模,bug数量从一个侧面反映了项目质量。将不同规模的项目进行平行地比较bug数量,是不合理的;所以以千行代码数的bug率作为项目质量的衡量标准是比较合理的。

应当注意到,规模越大的项目,因为涉及到的项目范围更广,技术复杂度更高,所以产生bug的可能性就越高,bug数量与项目规模并不是线性比例的,而是介于线性和平方之间。或者这样解释,一个10,000(1W)行代码的项目,产生了10个bug,即千行代码bug率为1;但是相对来说,100,000行代码的项目,bug可能就为12了,即bug率为1.2了。在评价项目质量时,必须要考虑这个因素。

2.bug在时间上的分布(主要在什么阶段产生了bug,如果在最后的用户验收测试阶段发现了大量的bug,则测试过程明显不合理)

bug不但在数量上有一定的趋势,而且在时间分布上也应当遵循一个一般规律。比如在项目代码冻结后,刚开始进行测试的阶段,bug是处于上升状态的,随着测试的进行和bug的修复以及因为修复bug而新引入的bug,bug数量会在一定时期维持一个峰值;在测试的末期,新发现的bug数量显著下降,趋于收敛。

这种规律用于预测测试阶段和整体质量,有一定的意义,如果在进行集成测试(Integration Testing)或者用户交付测试(User Accept Testing)之前,bug的产生率还维持在高位或者没有明显的收敛,那么有较大可能会有很多的问题遗留到线上才能发现和解决。

在进行项目质量分析的时候,如果有这方面的风险,要及早暴露出来。

3.bug在空间上的分布(哪些功能点产生了bug)

当然,bug在空间上的分布也有一定的规律。在背后支撑“bug的空间分布分析”的,是“程序的局部性原理”;局部性原理本意是指,程序访问存储介质时,有较高的可能性访问一小块空间内连续的存储单元,这也是cache/缓存/内存/硬盘等多级存储方案设计的基石(包括当前的SSD/磁盘混合型的硬盘),如果一个程序设计的不符合局部性原理(或者采用的内存交换算法不合理),就有可能造成内存的抖动。好,扯的有点远,回到bug的空间分布上来,bug在空间上分布,也存在局部性原理,即在某个点出现bug后,可能同一模块或者关系紧密的相邻模块有更高的可能产生缺陷,对于测试来说,要更加关注,并投入更多的精力去进行测试覆盖。

bug的局部性原理,可能原因是,

1)在设计和编码过程中,不同的模块可能是由不同的开发人员设计和开发,对某一个模块的功能理解或者代码水平受限,在某个范围内可能会集中出现缺陷。

2)在修复缺陷时,更多的是修改掉这个问题,在整个功能链路上的考虑通常较少,一些历史代码往往存在“负负得正”的逻辑,如果盲目修复一个模块内的缺陷,可能会导致上下游的某个环节出现问题,所以在修复缺陷时,有更大的可能在关联代码中引入缺陷。

测试报告中可体现上述问题,以便后续测试更加有针对性。

4.根据上述分布和历史经验以及项目的整体复杂度,对bug作出预期,还有多少问题遗留到线上

对上述问题分析完成后,需要进行相应的预测,最重要的是未来运行过程中,哪些地方容易出问题;如果还有测试时间,在何种范围需要加强测试。

5.对产生bug的部分重点关注,比如配置相应的监控

如果测试资源非常受限且有项目周期的要求,要根据测试报告,给出相应的建议,包括可能的线上性能监控/功能点监控/日志监控等,以便出问题后及时发现,并参照当时的设计方案和测试方案进行问题的修复,将损失降低到最少。

这是质量报告最有价值的几个点之一。

6.质量分析过程中的典型bug可进行重点复盘

对于容易产生问题/经常产生问题的具有代表性的点,可以在质量报告中予以复盘,这种复盘的过程应当包含设计/开发/测试人员,甚至还可能包含产品团队,这种典型bug的总结,复盘和改进建议,是整个技术团队进行技术成长的重要方式。

7.代码整体覆盖率

通过一些额外的工具(如EMMA),可以对程序运行过程中(这种运行既可以是测试过程中为了测试而进行的运行某功能,也可以是在线上进行代码运行的监控。)代码的覆盖率进行统计。

这种统计,可以发现相应的死代码(永远运行不到的代码),也可以发现哪些地方测试相对薄弱,需要加强和补充。同时还可以对持续集成的覆盖率进行统计。

8.安全检测工具检测出的问题及解决

代码的静态扫描,可以发现一部分问题,静态分析工具分析出的权限/数据库注入/跨站等问题,其实都有具体的pattern可以匹配,这种问题发现后的修复也不会浪费太多的时间,但是整体带来的效果是巨大的。

9.代码规范检测出的问题及解决

另外就是一些编码规范的扫描,比如类的注释,缩进等,也是基于代码的静态扫描,会在一个团队内部形成和维持一个良好的技术氛围。在质量报告中体现 (8,9)两条的内容,其实更多的是关注“过程质量”,看具体的质量环节是否有遗漏,相应的质量措施是否有人员去关注,不同的集体在环节上会有差异,在质量报告中能体现这些质量过程,能够在软性上提高参与人员的质量意识。

10.持续集成的变更以及运行情况

如果存在持续集成,并且当次的项目改动对持续集成(Continuous Integration)有影响(包括删除了某部分持续集成/ 修改持续集成的case/ 新增了持续集成的case),应当在质量报告中体现持续集成的变更情况,包括成功率/变化情况,以便考察另一个维度上,项目的质量情况。

质量报告,其实是一次对项目的深度总结。

展开阅读全文

没有更多推荐了,返回首页