下表是某项目某一测试版本使用测试用例执行测试的统计数据：
模块 | 测试执行结果 系统用例 | 通过 | 失败 | 阻塞 | 忽略 |
会员管理 | 报名参赛（UC1） | 12 | 0 | 0 | 4 |
赛事查询（UC2） | 5 | 0 | 0 | 0 | |
比赛资格查询（UC3） | 4 | 0 | 0 | 3 | |
加入战队（UC4） | 18 | 0 | 0 | 0 | |
组织我的战队（UC5） | 29 | 0 | 0 | 0 | |
查询我的战队（UC10） | 5 | 0 | 0 | 0 | |
会员注册 | 11 | 0 | 0 | 0 | |
修改会员资料 | 9 | 0 | 0 | 0 | |
基本信息 | 比赛项目管理（UC6） | 12 | 2 | 0 | 1 |
赛区运营商（UC10） | 8 | 1 | 0 | 0 | |
赛场管理（包括支持项目）（UC8） | 16 | 0 | 0 | 0 | |
赛事管理 | 赛事管理（UC9） | 22 | 6 | 0 | 0 |
战队管理（UC12） | 40 | 0 | 0 | 0 | |
统计管理 | 报名统计（UC13） | 9 | 1 | 0 | 0 |
系统参数 | 系统参数配置（UC11） | 4 | 0 | 0 | 0 |
权限管理 | 登录系统 | 5 | 0 | 0 | 0 |
操作员管理 | 12 | 0 | 0 | 0 | |
用户组管理 | 18 | 1 | 0 | 0 | |
用户密码修改 | 2 | 0 | 0 | 0 | |
Session同步 | 4 | 0 | 0 | 0 | |
合 计 | 245 | 11 | 0 | 8 | |
通过计算可知，该测试版本的测试测试执行通过率为92.8%。
4 缺陷解决率
缺陷解决率，指某个阶段已关闭缺陷占缺陷总数的比率。缺陷关闭操作包括以下两种情况：
正常关闭：缺陷已修复，且经过测试人员验证通过；
强制关闭：重复的缺陷；由于外部原因造成的缺陷；暂时不处理的缺陷；无效的缺陷。这类缺陷经过确认后，可以强制关闭。
计算公式：已关闭的缺陷/缺陷总数
在项目过程中，在开始时缺陷解决率上升很缓慢，随着测试工作的开展，缺陷解决率逐步上升，在版本发布前，缺陷解决率将趋于100%，如图二所示。一般来说，在每个版本对外发布时，缺陷解决率都应该达到100%。也就是说，除了已修复的缺陷需要进行验证外，其他需要强制关闭的缺陷必须经过确认，且有对应的应对措施。可以将缺陷解决率作为测试结束和版本发布的一个标准。如果有部分缺陷仍处于打开或已处理状态，那么原则上来说，该版本是不允许发布的。
图二 缺陷解决率
缺陷关闭数据，可以通过缺陷跟踪工具定期（如每周）收集当前系统的缺陷数、已关闭缺陷数，通过这两个数据，即可绘制出整个项目过程或某个阶段的缺陷解决率曲线。
当然了，测试度量指标不仅仅只包括上述四个，在实际工作中，还会用到如：验证不通过率、缺陷密度等指标。收集这些数据目的是为了能对测试过程进行量化管理。但是，简单收集度量数据不是目的，通过对数据的分析、预防问题、对问题采取纠正措施，减少风险才是目的。
