又到年终总结时，今天发信给大家收集过去的一年中各个
测试项目的一些数据，然后要根据部门年初时设定的一些质量目标进行总结。关于测试，我们一直在说是Quality Control的重要方式，而对于测试本身的质量该如何衡量？以下是我们目前的一些指标，大家也来说说自己现在都是怎么衡量的吧！
1. 测试项目on time delivery——是否能够按时完成测试项目，这其中有多项因素，包括开发团队的进度和质量等等。但是综合而言，这个指标依然能够反映整个项目过程中对于风险等综合因素的控制，也对测试团队对于整个项目的影响提出了一定的要求。
2. 测试项目in resource delivery——是否能够在计划资源内完成测试项目，这一因素与前一个因素相关，也对测试团队的开支控制提出了要求。
3. 测试效率——遗漏的
bug数，即发布后用户报告的bug数，从而体现了测试的全面程度和质量。
4. 测试有效性——递交bug的有效率，体现了测试员是否能够正确理解系统并发现问题，是否能够发现有效的问题。
当然，对于具体的测试成果有更多的衡量标准，如bug/test case，各种severity bug比率，不同类型bug比率。但是如果从整个测试部门的角度来看，又有哪些标准可以更好地来衡量整个部门的测试质量呢？
针对
软件测试质量：
1、功能、界面是否全部按照设计要求完成开发，这在测试（质量）的报告中，无论如何都要说一下的。
2、测试中执行计划、CASE等是否得到开发等相关部门的认可或认同，（是否涵盖了所有的功能、所有可能的逻辑操作等）？ 这可以进一步说明测试的有效性及正确性。
3、测试中采用的软硬件环境，说明与软件实际上要运行的软硬件环境是否相同，以及存在什么样的异同。
4、发布时软件中缺陷的状况，已知的还未修改的BUG、无法修改的问题、包括一些测试人员认为的设计上、界面上的问题等；
5、测试过程是否有序的完成？测试结果是否达到预期目的？（说明原因及状态）
6、依据需求，还有哪些测试需要后续进行的？（说明原因及状态）
另“递交bug的有效率”对测试有效性的说明作用也不是很大，反而在对个人测试质量的考量上有一定的参考意义。
我觉得下面几条对测试的质量的思考比较重要:
1.每轮测试用例的完成情况
2.每轮找到BUG的情况,是否达到预期的数量和分布
3.当前测试阶段的测试计划的执行情况
4.测试环境,测试资源是否达标和有效地控制
个人认为有做测试计划的公司,一定要按照此来作为测试活动的依据,其实测试计划写得详细的公司,其要求的测试质量和测试活动内容已经有一个标准在里面了.
衡量标准是不是可以分成两个类别？一是对于单个项目的标准，可能有很多指标，比如每轮用例通过情况，Bug分布情况等。另外一类是对于整个测试部门的衡量指标，这个应该是所有测试项目共有的标准，用来宏观衡量整个部门的持续改进。
限于种种因素，以前做项目的时候我们都简单地以bug数来衡量测试成果；后来又稍微改进了一下，以bug数*bug权重来衡量，其中的权重以相应模块在spec中的优先级来表示。
