上周参加了关于测试的培训，虽然没有想象中的那么大的帮助，感触还是有的，现对于某几个相关的问题写了一些个人的想法，这次说的是关于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的质量问题。有了这些数据并且分析，为以后的项目提供一些好的测试策略，同样也可发现潜在风险.