课程注册系统
体系结构原型测试计划
V1.0
修订历史记录
日期 | 版本 | 描述 | 作者 |
---|---|---|---|
1999 年 3 月 7 日 | 1.0 | 初始发行版 - 原型测试计划 | K. Stone |
|
|
|
|
|
|
|
|
|
|
|
|
目录
测试计划
用于
体系结构原型
1. 目标
1.1 目的
本文档描述用于测试“课程注册系统”的体系结构原型的计划。本测试计划文档支持以下目标:
本测试计划描述集成和系统测试,它们将按照原型的集成构建计划 [16] 中确定的子系统和组件集成,在体系结构原型上执行。
假设单元测试已提供了彻底的黑匣测试、广泛的源代码覆盖和所有模块接口的测试。
组装体系结构原型的目的是测试选中体系结构的可行性和性能。在此早期阶段测试所有系统和子系统接口以及系统性能是很关键的。在原型上将不执行系统功能和功能部件的测试。
将测试以下子系统之间的接口:
将测试以下设备的外部接口:
要测试的最关键性能测量是:
适用的参考资料有:
下面的列表指出那些被确定为测试目标的项(用例、功能需求和非功能需求)。这个列表列出将测试什么。
(注:本测试计划的未来发行版可能使用 Rational RequisitePro 直接链接到用例文档和补充规范中的需求。)
2.1 数据和数据库完整性测试
验证对“课程目录数据库”的访问。
验证同时的记录读访问。
验证“课程目录”更新期间的锁定。
验证对数据库数据更新的正确检索。
2.2. 功能测试
远景文档,第 12.2 节:“系统应与现有的课程目录数据库系统对接。课程注册应支持 [2] 中定义的数据格式。”
远景文档,第 12.2 节:“系统应与现有的计费系统对接并且应支持 [1] 中定义的数据格式。”
远景文档,第 12.2 节:“系统的服务器组件应在大学校园服务器上运行并且应运行在 UNIX 操作系统下。”
补充规范,第 9.3 节:“系统的服务器组件应在 Wylie College UNIX 服务器上运行。”
远景文档,第 12.2 节:“系统的客户机组件应在具有 486 微处理器或者更好微处理器的任何个人计算机上运行。”
补充规范,第 9.3 节:“系统的客户机组件应在具有至少 486 微处理器的任何个人计算机上运行。”
补充规范,第 9.1 节:“系统应与在 College DEC VAX Main Frame 上运行的现有旧系统(课程目录数据库)集成。”
补充规范,第 9.2 节:“系统应与在 College DEC VAX Main Frame 上运行的现有课程计费系统集成。”
2.3 业务周期测试
无。
2.4 用户界面测试
验证浏览一系列样本屏幕的难易程度。
验证样本屏幕是否符合 GUI 标准。
远景文档,第 10 节:“系统应易于使用,并且应适合熟悉计算机的学生和教授的目标市场。”
远景文档,第 12.1 节:“桌面用户界面应符合 Windows 95/98。”
补充规范,第 5.1 节:“桌面用户界面应符合 Windows 95/98。”
补充规范,第 5.2 节:“课程注册系统的用户界面应易于使用,并且应适合没有培训过使用系统但熟悉计算机的用户群。”
2.5 性能测试
验证访问外部财务系统的响应时间。
验证访问外部课程目录子系统的响应时间。
验证远程登录的响应时间。
验证课程注册的远程提交的响应时间。
远景文档,第 12.3 节:“系统应提供对旧课程目录数据库的访问,但等待时间不超过 10 秒。”
补充规范,第 7.2 节:“系统应提供对旧课程目录数据库的访问,但等待时间不超过 10 秒。”
2.6 负载测试
验证承受 200 个登录学生时的系统响应。
验证 50 个学生同时访问课程目录时的系统响应。
2.7 强度测试
无。
2.8 容量测试
无。
2.9 安全性和访问控制测试
验证从本地 PC 进行的登录。
验证从远程 PC 进行的登录。
验证使用用户名和密码机制时的登录安全性。
2.10 故障转移/恢复测试
无。
2.11 配置测试
远景文档,第 12.2 节:“系统的客户机组件应在 Windows 95、Windows 98 和 Microsoft Windows NT 上运行。”
补充规范,第 9.4 节:“课程注册系统的基于 Web 的接口应在 Netscape 4.04 和 Internet Explorer 4.0 浏览器中运行。”
补充规范,第 9.5 节:“基于 Web 的接口应与 Java 1.1 VM 运行时环境兼容。”
2.12 安装测试
无。
测试策略提供测试软件应用程序的建议方法。有关测试需求的前一节描述了将测试什么;这一节描述将如何测试它。
测试策略的主要注意事项是要使用的技术和了解何时完成测试的标准。
除了为下面的每个测试提供的注意事项以外,还应只使用已知的受控数据库在安全环境中执行测试。
以下测试策略在本质上是通用的,并且意在适用于本文档的第 4 节中列出的需求。
3.1 测试类型3.1.1 数据和数据库完整性测试
数据库和数据库进程应作为独立的系统进行测试。这些系统应不带应用程序(作为数据的接口)进行测试。需要执行对数据库管理系统(DBMS)的更多研究,来指出可能存在的、支持下面所列测试的工具/技术。
测试目标: | 确保数据库访问方法和进程正确运行并且没有数据损坏。 |
技术: |
|
完成标准: | 所有数据库访问方法和进程都按设计的那样运行并且没有数据损坏。 |
特殊注意事项: |
|
3.1.2 功能测试应用程序的测试应专注于所有可以直接跟踪到用例(或业务功能)的目标需求,同时专注于业务规则。这些测试的目标是验证正确的数据验收、处理和检索以及适当的业务规则实施。这种测试基于黑匣技术;即,通过图形用户界面(GUI)与应用程序交互并分析输出(结果),来验证应用程序(及其内部进程)。下面概括了为每个应用程序建议的测试:
测试目标: | 确保正确的应用程序导航、数据输入、处理和检索。 |
技术: |
|
完成标准: |
|
特殊注意事项: |
|
3.1.3 业务周期测试
3.1.4 用户界面测试本节不适用于体系结构原型的测试。
用户界面测试验证用户与软件的交互。UI 测试的目标是确保用户界面向用户提供对应用程序功能的相应访问和浏览。此外,UI 测试还确保 UI 中的对象照预期工作并符合社团或行业标准。
测试目标: | 验证以下方面:
|
技术: |
|
完成标准: | 成功验证每个窗口都与基准版本一致或都在可接受的标准内 |
特殊注意事项: |
|
3.1.5 性能概要分析
性能测试测量响应时间、事务速率和其他与时间相关的需求。性能测试的目标是验证性能需求已经实现。性能测试通常执行多次,每次在系统上使用不同的“后台负载”。初始测试应使用“额定”负载(类似于目标系统上的正常负载或预期负载)执行。第二个性能测试使用高峰负载运行。
此外,性能测试可用于设定和调整系统的性能,使它成为多种状况(例如工作负载或硬件配置)的作用结果。
注意:下面的事务涉及“逻辑业务事务”。这些事务被定义为预期系统的某个用户要使用应用程序执行的特定功能,例如添加或修改给定的合同。
测试目标: | 验证以下两种状况下指定的事务或业务功能的系统响应时间: - 正常的预期容量 - 预期的较差容量 |
技术: |
|
完成标准: |
|
特殊注意事项: |
|
3.1.6 负载测试负载测试让待测试系统承受不同的工作负载,从而评估系统有多大的能力在这些不同的工作负载下正常工作。负载测试的目标是确定和确保系统在超过预期的最大工作负载时正常运转。此外,负载测试还评估性能特征(响应时间、事务率和其他与时间相关的问题)。
注意:下面的事务涉及“逻辑业务事务”。这些事务被定义为预期系统的某个用户要使用应用程序执行的特定功能,例如添加或修改给定的合同。
测试目标: | 验证不同工作负载状况下所指定事务或业务案例的系统响应时间。 |
技术: |
|
完成标准: |
|
特殊注意事项: |
|
3.1.7 强度测试
3.1.8 容量测试本节不适用于体系结构原型的测试。
3.1.9 安全性和访问控制测试本节不适用于体系结构原型的测试。
安全性和访问控制测试专注于安全性的两个关键方面:
应用程序安全性,包括对数据或业务功能的访问。
系统安全性,包括对系统的远程访问。根据您想要的安全性,应用程序安全性确保用户被限定使用特定的功能,或他们被限制使用他们可用的数据。例如,可能允许每个人输入数据和创建新帐户,但仅经理可以删除它们。如果存在数据级别的安全性,则测试确保用户“类型”一可以看到所有客户信息(包括财务数据),但是用户类型二仅可以看到同一客户机的调查数据。
系统安全性确保仅授权访问系统的那些用户能访问应用程序,并且只能通过适当的网关进行访问。
测试目标: | 功能/数据安全性:验证用户仅可以访问向他们的用户类型提供许可权的那些功能/数据。
系统安全性:验证仅具有系统和应用程序访问权的那些用户可以访问它们。 |
技术: |
|
完成标准: | 对于每个已知用户类型,可以使用适当的功能/数据,并且所有事务如期望的那样运行并在之前的“应用程序功能”测试中运行 |
特殊注意事项: |
|
3.1.10 故障转移和恢复测试
3.1.11 配置测试本节不适用于体系结构原型的测试。
配置测试验证软件在不同的软件和硬件配置上的运行。在多数生产环境中,客户机工作站、网络连接和数据库服务器的特定硬件要求都是不同的。客户机工作站可能装入了不同的软件,例如应用程序、驱动程序等。在任意时候,都可能存在许多不同的组合并且使用不同的资源。
测试目标: | 验证客户机应用程序在规定的客户机工作站上正确运行。 |
技术: |
|
完成标准: | 对于原型和 PC 应用程序的每种组合,事务都成功完成(无故障)。 |
特殊注意事项: |
|
3.1.12 安装测试3.2 工具本节不适用于课程注册体系结构原型的测试。
工具 | 版本 | |
---|---|---|
测试管理 | Rational RequisitePro Rational Unified Process |
TBD |
测试设计 | Rational Rose | TBD |
缺陷跟踪 | Rational ClearQuest | TBD |
功能测试 | Rational Robot | TBD |
性能测试 | Rational Visual Quantify | TBD |
测试覆盖率监视器或概要分析程序 | Rational Visual PureCoverage | TBD |
其他测试工具 | Rational Purify
Rational TestFactory |
TBD |
项目管理 | Microsoft Project
Microsoft Word Microsoft Excel |
TBD |
DBMS 工具 | TBD | TBD |
4. 资源
4.1 角色此表显示测试原型的人员配备假设。
人力资源
角色 | 建议的最少资源 (分配的全职工作人员数) |
具体职责/注释 |
---|---|---|
测试经理 | 1 - Kerry Stone | 提供管理监管 职责:
|
测试设计人员 | Margaret Cox
Carol Smith |
确定测试用例、划分测试用例优先级然后实施测试用例 职责:
|
系统测试员 | Carol Smith | 执行测试
职责:
|
测试系统管理员 | Simon Jones | 确保测试环境和资产得到管理和维护。
职责:
|
数据库管理/数据库经理 | Margaret Cox | 确保测试数据(数据库)环境和资产得到管理和维护。
职责:
|
设计人员 | Margaret Cox | 识别和定义测试类的操作、属性和关联 职责:
|
实施者 | Margaret Cox | 实施测试类和测试包并对它们执行单元测试
职责:
|
4.2 系统
下表列出测试课程注册原型的系统资源。
系统资源
资源 | 名称/类型/序列号 |
---|---|
Wylie College 服务器 | 序列号:X179773562b |
课程目录数据库 | 版本标识:CCDB-080885 |
计费系统 | 版本标识:BSSS-88335 |
客户机测试 PC |
|
3 台远程 PC(可访问因特网) | 序列号:A8339223
序列号:B9334022 序列号:B9332544 |
3 台本地 PC(连接 LAN) | 序列号:R3322411(注册处)
序列号:A8832234(IT 实验室) 序列号:W4592233(IT 实验室) |
测试存储库 |
|
Wylie College 服务器 | 序列号:X179773562b |
测试开发 PC - 6 | 序列号:A8888222
序列号:R3322435 序列号:I88323423 序列号:B0980988 序列号:R3333223 序列号:Y7289732 |
5. 项目里程碑
“课程注册体系结构原型”的测试包含了前面的节中确定的每个测试工作的测试任务。每个项目里程碑被标出以交流项目状态和完成情况。
请参阅软件开发计划 [13] 和 E1 迭代计划 [14],了解整个阶段或主项目日程表。
里程碑任务 | 工时(pd) | 开始日期 | 结束日期 |
---|---|---|---|
原型测试计划 | 2 | 3 月 12 日 | 3 月 15 日 |
原型测试设计 | 3 | 3 月 15 日 | 3 月 18 日 |
原型测试开发 | 4 | 3 月 19 日 | 3 月 23 日 |
原型测试执行 | 3 | 3 月 24 日 | 3 月 26 日 |
原型测试评估 | 1 | 3 月 29 日 | 3 月 29 日 |
下表概括了此测试计划中定义的测试任务的工作产品。
工作产品 | 所有者 | 复审/分发 | 到期日 |
测试计划 | K. Stone | 高级项目管理小组 | 3 月 15 日 |
测试环境 | S. Jones | - | 3 月 18 日 |
测试套件 | C. Smith 和 M. Cox | 内部同级复审 | 3 月 23 日 |
测试数据集 | M. Cox | 内部同级复审 | 3 月 23 日 |
测试脚本 | M. Cox | - | 3 月 23 日 |
测试存根,驱动程序 | M. Cox | - | 3 月 23 日 |
测试缺陷报告 | C. Smith | 高级项目管理小组 | 3 月 26 日 |
测试结果 | C. Smith | - | 3 月 26 日 |
测试评估报告 | C. Smith | 高级项目管理小组 | 3 月 29 日 |
6.1 测试 套件测试套件将定义所有测试用例和与每个测试用例关联的测试脚本。
6.2 测试日志计划使用 RequisitePro 确定测试用例并跟踪每个测试用例的状态。在 RequisitePro 中测试结果将总结为“未测试”、“已通过”、“有条件通过”或者“失败”。总之,将设置 RequisitePro 以支持每个测试用例的以下属性(如需求属性准则 [17] 中所定义):
- 测试状态
- 构建号
- 测试者
- 测试日期
- 测试注释
7. 项目 任务更新 RequisitePro 中的测试状态将是系统测试员的职责。
测试结果将保留在配置控制下。
6.3 缺陷报告Rational ClearQuest 将用于记录和跟踪每个缺陷。
下面是测试“课程注册体系结构原型”的测试相关任务:
计划测试 |
|
|
|
|
|
|
设计测试 |
|
|
|
|
|
实施测试 |
|
|
|
|
|
执行测试 |
|
|
|
|
|
|
评估测试 |
|
|
|
确定是否已完成“测试完成标准”和“成功标准” |
创建测试评估报告 |
Copyright (c) IBM Corp. 1987, 2004. All Rights Reserved. |
课程注册项目 Web 示例 |