模块 |
测试执行结果 系统用例 |
通过 |
失败 |
阻塞 |
忽略 |
会员管理 |
报名参赛(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%。也就是说,除了已修复的缺陷需要进行验证外,其他需要强制关闭的缺陷必须经过确认,且有对应的应对措施。可以将缺陷解决率作为测试结束和版本发布的一个标准。如果有部分缺陷仍处于打开或已处理状态,那么原则上来说,该版本是不允许发布的。
图二 缺陷解决率
缺陷关闭数据,可以通过缺陷跟踪工具定期(如每周)收集当前系统的缺陷数、已关闭缺陷数,通过这两个数据,即可绘制出整个项目过程或某个阶段的缺陷解决率曲线。
当然了,测试度量指标不仅仅只包括上述四个,在实际工作中,还会用到如:验证不通过率、缺陷密度等指标。收集这些数据目的是为了能对测试过程进行量化管理。但是,简单收集度量数据不是目的,通过对数据的分析、预防问题、对问题采取纠正措施,减少风险才是目的。