评价测试用例质量还是件比较麻烦的事情，我觉得简单地用“缺陷总数/用例总数”不是非常的客观。因为不同的开发人员的技术水平和对被开发软件的熟悉程度是不一样的。一个senior的DEV所开发的功能点一定会比一个fresh的DEV所开发功能点包含的BUG要少。这样的话很可能造成QA不愿意或者不乐意去接seniorDEV所开发的项目。
测试用例内部评审：
当一个QA完成了手头的测试用例之后，可以让相关的开发人员、攥写需求文档的人员和相对senior或者有专业知识背景的测试人员一起对测试用例做一个review，在review过程当中一般会发现测试用例的不足和需要改进的地方。这些用例的不足之处以及需要改进的地方可以从一个侧面反映出用例的质量。具体的衡量标准由管理人员制定(有些时候测试用例的不足是由于需求文档本身的问题造成的，这就不应该算作是测试用例质量的问题)。
好处：这个的评审可以集思广益，充分发挥协调了各个相关人员的知识，可以提高测试用的覆盖面。同时因为引入了更多的测试人员，大家的对于软件新开发功能都会有进一步的了解，可以提高以后cross function以及complex scenario的测试用例质量
缺点：对于人力的需求较高！
外部评审：
如果公司开发的软件比较大的话，一般会有partner或者咨询公司为软件做代理或者实施。这些partner和咨询公司在实施公司新版本软件之前自己一般会做一些测试（他们自己会有自己的测试用例）。公司可以考虑将收集这些合作商的测试用，然后和QA所写用例比较，以作为对测试用例的评价或考核。当然公司也可以反过来作，即把公司的测试用例拿出去让合作伙伴评审（这样做的我看到的不多）。
好处：partner和咨询公司对于用户的实际情况更为了解，所以他们攥写的测试用例更能够体现用户试用软件的方式和习惯。通过向他们所写用例的比较和学习可以让QA测试用例更多地覆盖客户的试用方式、切合实际。
缺点：愿意这样合作的partner不太多啊.........
按客户反馈评审：
当软件发布后，客户使用一段时间一定会发现有问题，或者在设计方面不符合他们的要求。我们可以将客户报告的BUG收集起来加以分析（严重性，BUG类型，复杂程度），并和通过测试用例发现的BUG作个比较，从而评定测试用例的质量。
好处：因为客户是最终使用软件的人，所以软件的质量主要是围绕他们而展开的。通过引入他们对软件的评价，可以使得测试用例评价方式更加实际，而且相对来说比较客观。而且将客户发现的问题加入测试用例并且执行回归测试对于提高产品的稳定性和客户满意度有很大的帮助。
缺点：响应时间太长。往往等客户发现了问题，在去考虑测试用例的质量已经来不及了。