首先，我们要明确一个概念，就是“严重bug”。这6个维度，有很多都和严重bug有关。严重bug指的是项目中，严重性是1级和2级的bug。注意，并不是优先级，而是严重性。严重性1级是“block”，指程序无法正常运行或者是测试无法正常进行，随便点两下，就报错；2级是major，指功能的各种错误，总之是用户不可接受的错误。3级大多是文案或者是易用性的问题，用户可以接受少量这种类型的bug。
好，下面开始讨论那六个维度，我会说明计算方法，以及它们的战略意义。
1、严重bug数 / 测试用例数
这个维度代表了一个项目的严重bug数量是否正常，让测试用例参与计算，是为了平衡规模不同的项目的数据。
2、第三轮测试出现的严重bug数 / 严重bug总数
目前我们的测试过程模型是“三轮测试”，三轮的目标分别是：发现bug、验证bug、稳定回归。如果在第三轮回归的时候，还出现大量严重bug，那肯定是不正常的，也会对质量构成巨大风险。这个数字应该要控制在一个很低的水平。
3、被reopen的严重bug / 严重bug总数
reopen指开发fix后，测试验证不通过，或者是已经close的bug又复发。这个维度也应该被控制在一个很低的水平，如果偏高，说明开发修复bug的效率偏低，代码不稳定，发布后出现bug的几率增加。
4、第二轮测试用例执行通过率
因为第二轮的目标就是修复bug，所以如果第二轮结束的时候，严重bug全部被修复，并且第三轮没有出现新的严重bug，那么可以说项目的质量是非常稳定的。这里判定第二轮用例通过与否的标准，就是看第二轮结束时，如果有严重bug没有关闭，那相关的测试用例就是failed。此外，3级bug如果没有关闭，除非有确定的用例与之对应，否则不会影响用例的通过率。
5、测试工作量（人月） / 测试用例数
这个维度代表投入的测试资源是否充足，这里的工作量，指的是从测试设计到测试执行的所有人月数。如果数字过低，说明测试资源紧张，无法保证测试质量；如果过高，说明有可能测试效率低，测试经理需要进行解释。
6、严重bug平均关闭时间（天）
bug 关闭时间，指bug从创建开始，到close为止，经过的时间，要精确到小数点后1位。只有状态是close的bug，才会计算关闭时间。平均关闭时间的计算方法也很简单，把所有closed严重bug求平均值即可。这个维度代表项目组解决bug的效率，如果时间太长，说明项目组对bug重视不够。
其实要度量项目的质量，还有很多维度要考虑，比如需求文档、设计方案、代码等等，不过我们还是先在测试的范畴进行讨论，欢迎大家对这些维度提改进建议，或者提出新的维度。
用例评价的质量维度
经济性： 只为确定需要的目的设计相应的测试步骤。
可重复性： 自我一致性，即不管谁执行此用例，结果一样。
适应性：既 能适应短期需要，又能考虑长远需要。
可追踪性： 用例能追踪到一个具体的需求
自我清理性： 单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。
可测试性： 用例的测试目的和操作在具体系统中是可实现的，可操作，可观察的。
指导性： 用例的操作步骤能够指导执行人员完成测试，并准确判断结果是否正确
覆盖率： 保障对需求的完全覆盖，“用例数/需求”达到质量目标
规范性： 格式规范，且所有用例都符合统一的写作规范
有效性： 用例发现问题的效率可用“百用例发现问题数”或“平均用例发现问题数”来度量
5C原则： Correct（准确）、Clear（清晰）、Concise（简洁）、Complete（完整）、Consistent（一致）