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