怎样评价测试用例的质量

zrlcj

各位好：
    目前我用的测试用例质量=缺陷总数/用例总数*100=**（个/百用例），但目前软件的一些小的改动，仍需要进行测试，但编写测试用例并无法找到那么多错误，例如：测试用例编写了20个，但可惜的是没有发现缺陷，难道这个测试用例的质量为0么，
    怎样评价用例的好坏呢，测试用例的覆盖率怎样计算呢？还请高手指点。谢谢了。

zrlcj

还请各位指点。

zrlcj

怎么没人回呢，我等着呢。谢谢了。

wangjingying

说下我个人的看法

评价测试用例质量还是件比较麻烦的事情，我觉得简单地用“缺陷总数/用例总数”不是非常的客观。因为不同的开发人员的技术水平和对被开发软件的熟悉程度是不一样的。一个senior的DEV所开发的功能点一定会比一个fresh的DEV所开发功能点包含的BUG要少。这样的话很可能造成QA不愿意或者不乐意去接seniorDEV所开发的项目。

测试用例内部评审：
当一个QA完成了手头的测试用例之后，可以让相关的开发人员、攥写需求文档的人员和相对senior或者有专业知识背景的测试人员一起对测试用例做一个review，在review过程当中一般会发现测试用例的不足和需要改进的地方。这些用例的不足之处以及需要改进的地方可以从一个侧面反映出用例的质量。具体的衡量标准由管理人员制定(有些时候测试用例的不足是由于需求文档本身的问题造成的，这就不应该算作是测试用例质量的问题)。
好处：这个的评审可以集思广益，充分发挥协调了各个相关人员的知识，可以提高测试用的覆盖面。同时因为引入了更多的测试人员，大家的对于软件新开发功能都会有进一步的了解，可以提高以后cross function以及complex scenario的测试用例质量
缺点：对于人力的需求较高！

外部评审：
如果公司开发的软件比较大的话，一般会有partner或者咨询公司为软件做代理或者实施。这些partner和咨询公司在实施公司新版本软件之前自己一般会做一些测试（他们自己会有自己的测试用例）。公司可以考虑将收集这些合作商的测试用，然后和QA所写用例比较，以作为对测试用例的评价或考核。当然公司也可以反过来作，即把公司的测试用例拿出去让合作伙伴评审（这样做的我看到的不多）。
好处：partner和咨询公司对于用户的实际情况更为了解，所以他们攥写的测试用例更能够体现用户试用软件的方式和习惯。通过向他们所写用例的比较和学习可以让QA测试用例更多地覆盖客户的试用方式、切合实际。
缺点：愿意这样合作的partner不太多啊.........

按客户反馈评审：
当软件发布后，客户使用一段时间一定会发现有问题，或者在设计方面不符合他们的要求。我们可以将客户报告的BUG收集起来加以分析（严重性，BUG类型，复杂程度），并和通过测试用例发现的BUG作个比较，从而评定测试用例的质量。
好处：因为客户是最终使用软件的人，所以软件的质量主要是围绕他们而展开的。通过引入他们对软件的评价，可以使得测试用例评价方式更加实际，而且相对来说比较客观。而且将客户发现的问题加入测试用例并且执行回归测试对于提高产品的稳定性和客户满意度有很大的帮助。
缺点：响应时间太长。往往等客户发现了问题，在去考虑测试用例的质量已经来不及了。

zrlcj

多谢了，我感觉测试用例内部评审和按客户反馈评审比较适合我们。我在衡量一下吧。再次表示感谢。

tiannianyong

如何评价测试人员的工作绩效
随着国内软件测试行业的不断发展，软件测试工作更加深入、规范。其中对测试人员的绩效考核也越来越重要。目前，很多公司对测试人员的考核方面都不相同，有些公司仍然是以单纯的问题单数量来对测试人员进行评价，这样直接对测试人员工作方向产生误导，影响到测试人员工作的积极性和稳定性。因此，为了能够更好对测试过程进行管理，必须对测试人员有一个客观、全面的评价。下面是本人在工作中的一些体会希望能给大家带来一些启发：
一、测试人员工作绩效评价的误区
　　1、 仅从提交的问题单数量、测试执行用例数量来判断测试人员的好坏
　　这种做法明显缺乏全面性。问题单的数量只是评估测试质量的一个方面，我们更需要看中实际的测试质量。这就需要考察问题单的质量、测试的难度、问题单的级别。
　　例如：模块A很不稳定，潜在的问题数可能有100个，由测试人员甲负责测试，他一个月执行300个用例，提交50个问题单，发现30个有效问题，有10个严重问题；
　　模块B比较稳定，潜在的问题数可能有20个，由测试人员乙负责测试，他一个月执行100个用例，提交20个问题单，发现18个有效问题，有8个严重问题；
　　从上述测试执行结果来看，甲提交的问题单数量和执行用例数量都要远远高于乙，但是从测试的质量来看，模块B的遗留问题显然少于模块A，甲执行测试的充分性显然不如乙，从问题单质量来看，甲提交的问题单虽然很多，但近半数是非问题，做了无用功，还影响到开发人员对问题的定位所消耗的时间。
　　因此，必须要走出用问题单数量、用例数量评价测试人员的误区。
　　2、 对测试人员发现的问题的价值没有进行评估
　　发现1个系统架构设计方面存在的缺陷和隐患，远比发现几个普通界面的显示问题要有价值的多。因此，在对测试人员进行评价时，必须区分不同问题的重要性和价值。
　　3、 不重视测试文档的质量
　　测试文档的质量往往是测试人员的测试水平的反映，只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质量。
　　4、 不重视测试人员的综合能力
　　首先，必须考察测试人员的责任心，如果一个测试人员工作不符责任，随意敷衍，即使提交的问题单数量多，也不能证明他测试的质量高。其次，需要关心测试人员的工作积极性，积极工作的态度不仅能带来很高的测试质量，还能提高整个团队的积极向上的风气。还有，测试人员的沟通能力，如果一个测试人员和开发人员对问题沟通交流不畅，甚至经常引发争执，这显然会影响测试工作的效率。
二、建议对测试人员进行综合性的全面评价
　　评价方法如下：

　　三、总结
　　综上所述，必须本着以测试质量为重、对测试负责的角度对测试人员绩效进行客观评价，同时也提高测试人员的质量意识。通过合理的绩效评价，让测试人员以积极的心态投入的测试工作中，保证测试工作的顺利进行。