现在很多公司都会采用一些测试管理或者bug跟踪工具。通过这些工具我们也能够很容易的得到诸如每人发现bug数等等的数据。但是数据本身是没有意义的，正如上面提到的，简单的用发现bug数量来衡量测试效率是有失偏颇的。我们手里有足够多的数据，这是我们做分析评价的第一步。但是更重要的是怎么样用好这些数据，怎么样让这些数据成为有价值的报表，这才是我们应该关注和思考的。

　　首先，我们需要保证数据的真实性。比如说，我们会对每个bug的严重程度进行分类，但是如果由于大家分类的标准不统一导致这一项数据不准确，那么即使接下来有很好的分析模型来分析这些数据，我们最终拿到的报表也是不能真实反应测试工作的状态的。对于这个问题，我们应该对每一项数据有明确的定义，然后通过案例分析的方式在整个测试团队中统一标准，同时定期的随机抽查bug数据的质量，尽可能地保证数据本身的准确性和真实性。

　　其次，当我们有了真实的数据之后，我们就需要建立模型，对数据进行分析。这是整个评价过程中最重要的一环，也是要求最高的一环。我们需要明确我们关注的是什么。比如说，我们关注整个测试周期各阶段的情况，我们可能就会去获取每个阶段我们发现了多少个bug，这些bug有多少是应该在前面的测试环节就被发现的等等。或者我们关注的是模块与模块之间的横向比较，可能我们就会关心各个模块在各个阶段的bug比例，不同的严重程度下各个模块的bug数和bug比例。又或者我们关注在测试人员身上，那么除了每个人发现bug的数量，我们还会关心发现bug的严重程度，bug遗漏的比例等等。

　　最后，我们需要定义一些辅助数据来平衡数据本身的一些差异。比如说，我们在得到每个测试人员发现bug数量的数据之后，需要考虑他所在的测试阶段和模块的一些特点，可能系统测试发现bug的难度比功能测试高，或者财务模块bug发现难度比较大，那么我们就应该相应的给这些测试阶段和测试模块更高的权重系数，来反应它们之间的差异性。

　　当我们做完上面的事情之后，我们就完成了初始化的工作，接下来我们需要做得是调整和改进。通过一段时间的使用和观察，可能我会发现有些数据本身的定义有一些问题，或者一些模型忽略了影响很大的因素，再或者我发现权重系数有问题，那么我们可以对上面的系统进行改进和调整。

　　在软件开发和测试的过程中，没有一套一成不变的方法和系统，能一直准确的反应这个过程。我们可以做的，就是接受变化，跟上变化，从而尽可能地用变化的思路和方法来反应项目的状态。

转载请保留：本文出自51Testing软件测试论坛每周一问活动，感谢会员deanaa的精彩回答。

查看更多活动详情请点击：http://bbs.51testing.com/forum-157-1.html