课程注册系统
C2 测试评估摘要
版本 1.0
修订历史记录
日期 |
版本 |
描述 |
作者 |
1999 年 3 月 28 日 |
1.0 |
R1.0 发行版(在 C2 迭代中开发 - 第一版)的测试评估 |
C. Smith |
|
|
|
|
|
|
|
|
目录
- 目标
- 范围
- 参考
- 简介
- 测试覆盖率
- 代码覆盖率
- 缺陷分析
- 7.1 缺陷密度
- 7.2 缺陷趋势
- 7.3 缺陷帐龄
- 建议操作
- 图
C2 测试评估摘要
1. 目标
本“测试评估报表”描述 C-Registration R1.0 系统测试在测试覆盖率(基于需求的覆盖率和基于代码的覆盖率)和缺陷分析(即缺陷密度)方面的结果。这些测试在 C2 迭代期间执行。
2. 范围
本“测试评估报告”适用于在 C2 迭代中实施的 C-Registration R1.0 发行版。所执行的测试在“测试计划”[5] 中描述。本“评估报告”用于以下方面:
- 评估 R1.0 系统的性能行为的可接受性和适当性
- 评估测试的可接受性
- 确定用于提高测试覆盖率和/或测试质量的改进
3. 参考资料
适用的参考资料有:
- Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
- Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
- Course Registration System C2 Iteration Plan, WyIT500, V1.0, 1999, Wylie College IT.
- Course Registration System C2 Integration Build Plan, WyIT502, V1.0,
1999, Wylie College IT.
- Course Registration System Test Plan, WyIT501, V1.0, 1999, Wylie
College IT.
4. 简介
“测试套件”中定义的测试用例按照“测试计划”[5] 中定义的测试策略执行。测试缺陷已经记录,并且所有中等优先级、高优先级或关键优先级的缺陷当前已被指定给所有者进行修订。
测试覆盖率(见以下的 5.0 一节)根据“测试计划”[5] 中定义的用例和测试需求的覆盖情况,已完成 95%。由于“负载仿真软件”中存在错误,10 个涉及完全负载情况下的系统的操作的测试用例尚未完成。
代码覆盖率使用 Rational Visual PureCoverage 评估,这在 6.0 一节描述。
缺陷分析(如以下 7.0 一节所示)显示多数所发现的缺陷一般是划为高严重性或关键严重性的重大问题。另一个重要的发现是组成到“课程目录系统”的接口的软件组件中包含大量的缺陷。
5. 测试覆盖率
“测试套件”中定义的所有测试用例都已尝试执行。10 个测试由于“负载仿真软件”中存在软件错误而未完成。已执行的测试用例中,有 15 个测试失败。
测试覆盖率结果如下:
已执行测试用例比率 = 110/120 = 92%
成功的测试用例比率 = 95/110 = 87%
失败率最高的测试区域是:
- 涉及访问“课程目录系统”的性能测试
- 涉及访问“课程目录系统”的负载测试
- 客户机软件安装。
有关测试覆盖率进一步的详细信息可以通过使用 Rational RequisitePro 和“测试用例”矩阵查看。
6. 代码覆盖率
测试的代码覆盖率使用 Visual PureCoverage 评估。
已执行 LOC 比率 = 94,399 / 102,000 = 93%
大约 93% 的代码已在测试期间执行。此覆盖率超出了 90% 的目标。
7. 缺陷分析
本节概述使用 Rational ClearQuest 生成的缺陷分析的结果。第 8 节中列出了用于解决缺陷分析发现的问题的推荐操作。
7.1 缺陷密度
有关缺陷密度的数据已使用从 ClearQuest 报告中抽取的数据生成。本文档的第 9 节包含了说明以下内容的图表:
- 按严重性级别(关键、高、中等、低)分类的缺陷
- 缺陷源(问题或故障所在的组件)
- 缺陷状态(已记录、已指定、已修订、已测试、已关闭)。
按严重性级别分类缺陷图表中显示了 36 个已记录的缺陷中,严重性划为“高”或“关键”的 26 个缺陷。此数量被认为是一个非常高的数量;此外,为了生成“发行版”,必须能够关闭所有的高严重性和关键严重性缺陷。
缺陷源图表中显示了与组成到“课程目录系统”的接口的组件(c-abx、c-xxx)关联的异乎寻常的高缺陷百分比。此外,控制客户机软件安装的软件组件中也存在许多缺陷。
缺陷状态图表中显示缺陷迅速被指定并得到处理。多数缺陷都已经过验证并关闭。
此外,对关键严重性缺陷和高严重性缺陷的分析显示,其中的许多缺陷是由于在“课程目录系统”处于重负条件期间进行访问,因而响应时间过长而导致的。(只有 50% 用于验证性能需求的测试用例通过了测试。)
7.2 缺陷趋势
缺陷趋势(即随时间推移而产生的缺陷计数)在第 9 节“图”中显示。此趋势显示缺陷的出现数量依然很高。如果这种趋势继续存在,则可能需要进行附加的迭代来查找代码中剩余的缺陷。
7.3 缺陷帐龄
“缺陷帐龄图”(见第 9 节)显示关闭某些缺陷使用的时间超出了 30 天。
8. 建议操作
建议的操作如下:
- 继续在涉及“课程目录系统”的响应时间问题方面投入系统工程资源。这是一个关键的问题,因为不满足性能需求就无法发布 R1.0 发行版。
- 复审主进度安排,以查看是否可以在“构造阶段”中加入第四个迭代。随时间推移的缺陷趋势表明在代码中依然存在许多缺陷,所以建议添加一个额外的测试周期。
- 在重新提交缺陷率很高的组件进行构建之前应当对其进行检查。这包括 c-abx 和 c-xxx。
- 关键严重性和高严重性缺陷的比率很高可能表明设计不完善和未适当地进行复审。为 R2.0 发行版计划附加的设计复审。
- 修订“负载仿真软件”的问题并重新运行关联的测试用例。
- 调查缺陷帐龄。为什么许多缺陷使用了超出 30 天的时间才关闭?
9. 图
|