上周参加了关于测试的培训,虽然没有想象中的那么大的帮助,感触还是有的,现对于某几个相关的问题写了一些个人的想法,这次说的是关于bug曲线图的问题,
我们大部分人都知道所有的测试执行完成后,都会有测试报告,而测试报告的一个最关键的因素就是bug曲线图,一般都会有2种曲线:一个是open bug数量的曲线;
另一个是fixed bug 的数量的曲线。同样也要考虑收敛的问题,这里还有一个相关的曲线也是很重要的:bug priority曲线图。这里解释下:也就是优先级比较高的bug数量的曲线变化图,一般来说是P1的bug,如果更细一点也可以有P2的bug。为什么要有这个曲线图呢?一个最重要的目的就是看测试执行后期,也相当于我们第三轮测试的后期出现多一点的P1的bug(或者接近发布的后期),就会对这个质量进行重新评估,也就是会调整计划以及策略去应对这种情况。为什么会有这个判断呢?培训老师认为这是个经验,也就是认为这个时候系统很有可能存在一些严重的bug。
我个人认为这个有些问题在里面,一个是出现多少个P1 的bug就会去调整计划和策略呢?还有一个是如果单纯看经验就会认为系统还很有可能存在其他的P1的bug是否有点勉强?这些都没有量化的依据在里面。但是我觉得这个思考角度是正确的,也就是一旦测试执行后期发现了P1的bug,的确需要重视起来,并客观的分析原因。
而单纯看下P1 bug 数量的曲线图,并没有太大的意义(前期没有什么,后期的还是有点作用)。
我个人觉得这个bug priority 数量曲线图是有必要在测试报告中体现的,一方面让老大们也知道我们发现的bug的严重程度的数量以及趋势变化,二方面给自己一个相关的提醒,也就是前面说到的特别是后期发现P1 bug的重视程度,以及提高发现潜在风险的能力。
还有一个好的就是把我们项目过程中发现的bug分为2类:一个是新功能出现的bug,二个是旧功能出现的bug。还有就是这2中bug的数量关系以及模型,目前业界也在积极的研究当中,但有一点我们可以肯定的是对这些bug进行分类有一些好处,一个是得到新项目的本身的质量,二个是得到新功能与旧功能之间的耦合关系,三个是项目过程中bug fix的质量问题。有了这些数据并且分析,为以后的项目提供一些好的测试策略,同样也可发现潜在风险.
|