课程注册系统
测试评估摘要
用于
体系结构原型
V1.0
修订历史记录
日期 |
版本 |
描述 |
作者 |
1999 年 3 月 21 日 |
1.0 |
体系结构原型测试评估 |
C. Smith |
|
|
|
|
|
|
|
|
目录
- 简介
- 测试结果摘要
- 测试覆盖率
- 代码覆盖率
- 缺陷分析
- 建议操作
- 图
测试评估摘要
用于
体系结构原型
- 简介
- 目的
本测试评估报告从测试覆盖率(基于需求和基于代码的覆盖率)和缺陷分析(即缺陷密度)方面描述了“课程注册体系结构原型”测试的结果。
- 范围
本测试评估报告适用于“课程注册体系结构原型”。在原型 [5] 的测试计划中描述了执行的测试。本评估报告用于以下方面:
- 评估原型的性能行为的可接受性和适当性
- 评估测试的可接受性
- 指出如何改进可提高测试覆盖率和/或测试质量
- 参考
适用的参考资料有:
- 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 Iteration Plan, Elaboration Iteration #E1 , WyIT420, V1.0, 1999,
Wylie College IT.
- Course Registration System Integration Build Plan for the Architectural Prototype,
WyIT430, V1.0, 1999, Wylie College IT.
- Course Registration System Test Plan for the Architectural Prototype, WyIT432,
V1.0, 1999, Wylie College IT.
-
测试结果摘要
原型的测试套件中定义的测试用例已按照测试计划 [5] 中定义的测试策略加以执行。
测试计划 [5] 中定义的用例和测试需求的测试覆盖率(请参阅以下的第 5.0 节)是完整的。
在第 6.0 节中描述了代码覆盖率,但代码覆盖率不认为是原型是否成功的重要衡量方法。
缺陷分析(如以下的第 7.0 节中所示)指出访问旧“课程目录系统”存在重大性能问题。要求读写“课程目录系统”的性能和负载测试远低于设定的目标。管理团队将分配系统工程资源来进一步评估这些测试结果并确定设计替代方法。
- 测试覆盖率
在测试计划 [5] 的第 5.1 节中定义了要对原型执行的测试以及它们的完成标准。测试覆盖率结果如下:
测试用例已执行比率 = 40/40 = 100%
测试用例成功比率 = 30/40 = 80%
失败率最高的测试区域是:
- 要求访问“课程目录系统”的性能测试
- 要求访问“课程目录系统”的负载测试
有关测试覆盖率的进一步详细信息可使用 Rational RequisitePro 和“原型测试用例”表格来获取。
- 代码覆盖率
Rational Visual PureCoverage 用于测量“原型”测试的代码覆盖率。
LOC 已执行比率 = 12,874 / 48,916(大约 25%)
测试期间大约执行了 25% 的代码。由于完整测试了所有接口,因此可以确定此覆盖率对于原型测试是足够的。以后,迭代将要求高出很多的代码覆盖率。
- 缺陷分析
本节总结使用 Rational ClearQuest 生成的缺陷分析的结果。第 8 节列出针对缺陷分析所发现的问题的建议操作。
- 缺陷密度
使用从 ClearQuest 报告抽取的数据生成了有关缺陷密度的数据。本文档的第 9 节包含说明以下内容的图表:
- 按严重性级别(紧急、高、中、低)分类的缺陷
- 缺陷源(问题或故障所在的组件)
- 缺陷状态(logged,assigned,fixed,tested,closed)。
“按严重性级别分类的缺陷”图表显示记录了 4 个紧急和 4 个高优先级的缺陷。缺陷日志的详细分析显示紧急和高优先级缺陷都与访问旧“课程目录系统”时的性能和负载问题有关。(注意:不包含图表。)
“缺陷来源”图表显示“系统接口”组件中存在异乎寻常高百分比的缺陷。
“缺陷状态”图表显示许多缺陷处于“已记录”状态但未分配来作出分析。
- 缺陷趋势
未为“体系结构原型”测试测量缺陷趋势(即随时间变化的缺陷计数)。
- 缺陷帐龄
原型不需要跟踪缺陷存在时间。当前计划是在“构造阶段”开头开始跟踪所开缺陷的存在时间。ClearQuest 将用于生成“缺陷帐龄图”。
- 建议操作
建议的操作如下:
- 分配更多的系统工程资源来进一步评估与访问旧“课程目录系统”有关的性能和负载问题。在实施任何设计解决方案之前,项目团队将复审作为替代的设计。
- 分配工程资源来解决原型上未解决的所开缺陷。
- 延迟紧急和高优先级缺陷的下一个迭代期待解决方案的开始。
- 设计更多的测试来进一步测试“课程目录系统”的负载和访问时间。尝试使用 Rational Visual Quantify 来找出和分析性能瓶颈。
- 建议以后的迭代都检查所有涉及外部接口的设计或代码。这些检查应当减少测试期间找到的问题数目。
7. 图
-
|