两周前的一次讨论中，一位开发经理问我“如何检验测试质量？”我理解他问这个问题的原因是“需求分析师的工作质量可以由用户、开发人员和测试人员来评判。开发人员的开发质量可以由测试人员来评判。而作为内部最后一道关卡的测试，其质量该由谁去评判？如何评判？”然而遗憾的是当时我的回答却不能让他满意。
我：“来自生产环境的缺陷可以反映出测试质量。”
开发经理：“那太迟了！等到生产环境出问题我才知道内部测试出了问题可不行！”
我：“回归测试时的代码覆盖率分析结果可以一定程度反应测试覆盖率。”
开发经理：“但是测试覆盖了这行代码并不能一定说明测试人员发现了缺陷啊！”
我：“是的。。。测试覆盖率不等于测试质量。但可以一定程度上避免测试人员漏测，即根本没有跑到过的情况。”
开发经理：“回归测试之后马上就上线了。基于回归测试覆盖率分析来检验和补救测试质量？我还是觉得太迟！”
问答至此，我开始感觉到“如何检验测试质量？”是一个有点难以回答的好问题，值得我回头好好想想。于是今天抽空梳理了一下思路，有如下补充。
1、我们日常检查测试人员的工作质量主要是围绕测试覆盖率展开的
（1）检查测试用例质量：在检查测试用例质量的时候主要是比对需求覆盖率。如果测试用例没有覆盖需求，那么我们能在测试用例评审时及时发现和纠正。
（2）检查测试执行质量：对于基于脚本(Script)的测试，在检查测试执行质量的时候主要是比对测试用例覆盖率。对于探索式测试，在检查测试执行质量的时候主要是考察测试章程（Charter）的覆盖率和Debrief时的个人总结。因为测试用例或者章程的自然语言模糊性，如果我们辅助以代码覆盖率的统计会更有效地保障测试执行时不会遗漏任何需要覆盖的代码。但正如前面讨论提到的，代码覆盖率和需求覆盖率、测试用例覆盖率、测试章程覆盖率有一个本质的不同。代码覆盖率没有检查点，所以覆盖不等于有效地测试。
2、除了测试覆盖率，还有哪些方法可以间接检查或者保障测试人员的工作质量？
如下这些已经存在的软件开发实践，其主要目的并不是检查测试人员的工作质量。但它们可以间接帮助检查或者保障测试人员的工作质量。
（1）Beta测试或者UAT
因为Beta测试或者UAT通常是由开发团队之外的人员进行的，且通常他们的领域知识比开发团队更丰富，因此他们往往能发现测试人员“不知道自己不知道”的风险。如果测试人员的测试方法和思路偏离实际使用太远，在这个环节中就会暴露很多问题。虽然这个环节的测试也有些偏后了，但亡羊补牢未为晚矣，至少这是部署到生产环境之前的一个再次检验和补救的机会。
（2）缺陷分析
缺陷分析最多用于开发质量的分析和改进。但其实缺陷不但反映了开发的质量，也反映了测试的质量。
我特别喜欢Michael Bolton关于测试是有关三个故事的描述。他说测试讲述的第一个故事是关于产品的状态（在你的各种不同用户关系的情景下，产品是怎么失效的或者它在什么情况下可能失效）；测试讲述的第二个故事是关于你是如何测试的（你如何配置、如何操作、如何观察。。。你已经测试了什么、准备测试什么、不准备测试什么。。。）；测试讲述的第三个故事是关于你的测试棒不棒（你测试的开销怎样、风险是什么、什么让你的测试变得艰难或者缓慢、被测对象的可测试行如何、你需要什么、想要提出什么建议。。。）。从第二个故事和第三个故事的角度，缺陷也反映测试的水平。
实际工作中我们使用IBM提出的ODC(正交缺陷分类分析)方法来辅助队测试质量的监控。例如，其中一个属性是标识测试人员是通过何种方法(Coverage, sequence, variation, others)发现缺陷的。我们曾发现一些模块本身应该是有很多的操作流程相关的用法，但是报告出来的缺陷中属于操作顺序(sequence)类别的缺陷却很少，于是提醒相关测试人员在后续测试中加强对这种类型的测试，果然挖出不少相关的问题。另一个关于缺陷年龄(age)的分析，则帮助我们识别每个缺陷是属于老版本就已经存在的缺陷，还是由于做新功能引入的缺陷，或者是由于修复缺陷引入的缺陷。如果当前已经发现的缺陷中有大量老版本就已经存在的缺陷，则说明相关测试人员对老版本的测试不充分，测试质量有改进空间。
（３）自动化测试
因为测试的机会效应，即在执行一个测试的时候其实是失去了此刻执行另一个测试的机会，所以一个测试人员纵然再厉害也难以同时发现很多问题。而自动化测试却能帮助我们去覆盖那些此刻我们还没有来得及跑或者根本不会有时间去跑的测试，并发现可能的问题。或者说，“自动化测试”其实不是用来检查测试质量，而是帮助保障测试质量的。
