目录
测试用例作为测试人员最重要的输出物之一 ，它的作用不仅仅是能保证需求覆盖 ，提高测试覆盖率等 。通过对执行后的测试用例分析 ，你也可以发现更多在编写上，执行上出现的问题，从而进行修改和完善 。
1.测试用例的分析指标
那么 ，我们该如何做测试用例的分析呢 ？我们可以通过以下几个方面去分析 ：
指标1：测试用例发现bug的占比 ：是指通过测试用例发现的bug数占总bug数的比率 ，因为除了通过执行测试用例发现bug外 ，还可以通过随机测试或探索式发现bug 。 我们一般是希望这个比值是一个合理的范围，太高或太低都其实都是一个不健康的测试 。那么如果这个比值太高的话 ，可能是以下的问题导致 ：
随机发散测试的时间不足 ，花在测试用例执行的时间太长 ，可能的原因是测试轮次安排不合理或者测试时间不够 。
太依赖测试用例发现bug ，测试手段单一 ，或者不愿意发散测试 ，可能原因是团队比较沉闷，缺乏激情 ，只是一味的去执行 。
发散测试或探索测试的效果不好 ，团队不擅长发散测试 ，不能有效的发现深入的bug ，可能原因是团队成员不注重这方面的积累，或者缺少这方面的能力等。
如果这个值太低的话 ，可能是以下的问题导致 ：
随机发散的测试投入过多 ，压缩了测试执行时间 ，可能的原因是测试轮次安排不合理或者测试时间不够 。
测试用例设计水平不高 ，存在测试设计遗漏情况 。可能的原因是不太会使用测试方法或者不去使用测试方法 。
对业务理解不深入，不准确导致 ，存在设计无效或错误的情况 。
指标2：测试用例的首次执行通过率 ：是指测试用例第一次的执行结果为通过的用例占总用例的占比 ，若此占比值高 ，有可能原因的是开发的版本质量比较高 ，或者是测试用例所使用的测试方法单一或不够深入等 ；若此占比值低 ，说明开发版本质量较低或者测试方法比较有效 。所以我们拿这个指标可以评估产品开发的质量或者测试方法的有效性 。
指标3：测试用例的有效率 ：是指执行时有效用例占总用例数的占比 ，若此值太低的话 ，有可能的原因就是测试方法使用不够熟练 ，或者是测试人员对业务理解不够准确或深入 ，亦或者需求变动大导致用例不适用了 。所以通过此指标可以评估测试人员对业务的理解情况或者需求的变更情况 。
指标4：测试用例的执行时间 ：一般我们会将测试用例执行安排在第一轮测试中，它的总占比时间不能超过50% ，如果这个时间太长的话 ，有可能的原因就是测试效率执行低下 ，遇到难以执行卡的时间太长 ，缺少对执行时间长的用例的有效解决办法 ，团队评估的测试周期差距大，没有估计到执行过程中遇到的各种问题 。所以通过此指标可以评估测试人员的执行效率 ，难执行用例的解决方案的效果 或者测试周期评估的准确性 。
2.可能原因的论证
虽然我们列举了几个分析的测试用例指标 ，也进行各种情况的分析 ，但是光分析还不够 ，你还要去论证和解决这些分析后所产生的结果 。比如你已经发现测试用例的首次执行通过率这个值很高，分析后得出的可能原因是版本质量高或者是测试方法使用不当导致 ，那么它的具体原因是什么 ？ 这个还需要我们去进行论证 ，可行的方法就是结合历史数据进行比对 ，分析出那个才是真正原因 ，比如说导致通过率过高可能是你的测试方法使用不当 ，那么就要分析在以往的版本中是否也是这种情况 ，其他测试人员编写的用例通过率如何 ？ 通过这么几个维度的数据比较，基本就能确定出具体的原因 。所以，在这个分析和论证的过程中，你要比较的历史数据和比较的维度就显得很重要 。所以，建议每个版本测试完毕后，尽量要保留重要维度的历史数据 ，以供在后续版本中进行分析。比如以下 ：
3.确定原因的解决方案
找到了具体原因还不行，我们总的解决它，否则以上工作做的再好也是白费劲 。想解决方案，在后续版本中实践此方案 ，同时监测其效果 。比如我们确定了使用的测试方法效果不太好 ，导致测试用例首次执行通过率很高 。那么你可能想到的方案是 ：
找设计用例比较好的同事进行培训 ，然后制定同一标准 ，让大家以后也按照这个标准来设计 ，并加强评审环节的监督 。
买一些测试用例设计的书籍或者视频 ，大家一起去学习 ，然后开会讨论 ，总结出经验 。
复盘以前bug ，通过对好bug的分析 ，然后形成一些方法，最终用到测试用例中 。
通过列举出以上的方案 ，并且在后续工作实践这些方案 ，然后在后续的版本迭代中在此监控用例首次执行通过率这个指标 ，并记录各版本的历史数据 ，通过多个版本历史数据比对最终确定方案是否有效 ，如若方案效果不好 ，可以更换方案再试，直到达到预期的效果。
所以，通过以上的过程我们可以看到 ，有的问题并非是我们想象的那么容易 ，提供了新方法，就能立马见效或者有效 ，是需要不断的重复尝试的一个过程 。
