课程注册系统

体系结构原型测试计划

V1.0

 

修订历史记录

日期 版本 描述 作者
1999 年 3 月 7 日 1.0 初始发行版 - 原型测试计划 K. Stone
 
 
 
 
 
 
 
 
 
 
 
 

 

 

目录

  1. 目标
  2. 测试需求
  3. 测试策略
  4. 资源
  5. 项目里程碑
  6. 工作产品
  7. 项目任务

 

测试计划

用于

体系结构原型

1. 目标

1.1 目的

本文档描述用于测试“课程注册系统”的体系结构原型的计划。本测试计划文档支持以下目标:

1.2 范围

本测试计划描述集成和系统测试,它们将按照原型的集成构建计划 [16] 中确定的子系统和组件集成,在体系结构原型上执行。

假设单元测试已提供了彻底的黑匣测试、广泛的源代码覆盖和所有模块接口的测试。

组装体系结构原型的目的是测试选中体系结构的可行性和性能。在此早期阶段测试所有系统和子系统接口以及系统性能是很关键的。在原型上将不执行系统功能和功能部件的测试。

将测试以下子系统之间的接口:

    1. 课程注册
    2. 财务系统
    3. 课程目录。

将测试以下设备的外部接口:

    1. 本地 PC
    2. 远程 PC。

要测试的最关键性能测量是:

    1. 远程登录课程注册系统的响应时间。
    2. 访问财务系统的响应时间。
    3. 访问课程目录子系统的响应时间。
    4. 系统装入 200 个登录学生时的学生响应时间。
    5. 50 个学生同时访问课程目录数据库时的响应时间。
1.3 参考

适用的参考资料有:

    1. Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
    2. Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
    3. Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
    4. Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
    5. Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
    6. Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
    7. Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
    8. Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
    9. Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
    10. Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
    11. Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
    12. Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.
    13. Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
    14. Course Registration System Iteration Plan, Elaboration Iteration #E1 , WyIT420, V1.0, 1999, Wylie College IT.
    15. Course Registration System Software Architecture Document, WyIT431, V1.0, 1999, Wylie College IT.
    16. Course Registration System Integration Build Plan for the Architectural Prototype, WyIT430, V1.0, 1999, Wylie College IT.
    17. Course Registration System Requirements Attributes Guidelines, WyIT404, V1.0, 1999, Wylie College IT.
2.    测试需求 

    下面的列表指出那些被确定为测试目标的项(用例、功能需求和非功能需求)。这个列表列出将测试什么

    (注:本测试计划的未来发行版可能使用 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 安装测试

    无。

3.    测试策略

    测试策略提供测试软件应用程序的建议方法。有关测试需求的前一节描述了将测试什么;这一节描述将如何测试它。

    测试策略的主要注意事项是要使用的技术和了解何时完成测试的标准。

    除了为下面的每个测试提供的注意事项以外,还应只使用已知的受控数据库在安全环境中执行测试。

    以下测试策略在本质上是通用的,并且意在适用于本文档的第 4 节中列出的需求。

3.1 测试类型

3.1.1 数据和数据库完整性测试

数据库和数据库进程应作为独立的系统进行测试。这些系统应不带应用程序(作为数据的接口)进行测试。需要执行对数据库管理系统(DBMS)的更多研究,来指出可能存在的、支持下面所列测试的工具/技术。

 

测试目标: 确保数据库访问方法和进程正确运行并且没有数据损坏。
技术:
  • 调用每个数据库访问方法和进程,并且对每个同时使用有效数据和无效数据(或数据请求)。
  • 检查数据库,确保数据照预期填充并且所有数据库事件正确发生,或检查返回的数据,确保(为正确的起因)检索到正确的数据。
完成标准: 所有数据库访问方法和进程都按设计的那样运行并且没有数据损坏。
特殊注意事项:
  • 测试可能需要 DBMS 开发环境或驱动程序以在数据库中直接输入或修改数据。
  • 进程应手动调用。
  • 应使用小数据库或超小数据库(记录数有限)来使任何不可接受的事件更易于发现。

 

 

3.1.2 功能测试

应用程序的测试应专注于所有可以直接跟踪到用例(或业务功能)的目标需求,同时专注于业务规则。这些测试的目标是验证正确的数据验收、处理和检索以及适当的业务规则实施。这种测试基于黑匣技术;即,通过图形用户界面(GUI)与应用程序交互并分析输出(结果),来验证应用程序(及其内部进程)。下面概括了为每个应用程序建议的测试:

 

测试目标: 确保正确的应用程序导航、数据输入、处理和检索。
技术:
  • 使用有效数据和无效数据执行每个用例、用例流或功能,验证以下方面:
  • 当使用有效数据时,预期的结果发生。
  • 当使用无效数据时,显示相应的错误/警告消息。
  • 正确应用了每条业务规则。
完成标准:
  • 所有计划的测试都已执行。
  • 所有指出的缺陷都已处理。
特殊注意事项:
  • 需要对 Wylie College UNIX 服务器以及现有课程目录系统和计费系统的访问,以对原型运行某些确定的系统测试。
 

3.1.3 业务周期测试

本节不适用于体系结构原型的测试。

3.1.4 用户界面测试

用户界面测试验证用户与软件的交互。UI 测试的目标是确保用户界面向用户提供对应用程序功能的相应访问和浏览。此外,UI 测试还确保 UI 中的对象照预期工作并符合社团或行业标准。

 

测试目标: 验证以下方面:
  • 对应用程序的浏览正确反映业务功能和需求,包括窗口到窗口、字段到字段以及访问方法的使用(Tab 键、鼠标移动和加速键)
  • 窗口对象和特征(例如菜单、大小、位置、状态和焦点)符合标准。
技术:
  • 为每个窗口创建/修改测试,验证每个应用程序窗口和对象的正确导航和对象状态。
完成标准: 成功验证每个窗口都与基准版本一致或都在可接受的标准内
特殊注意事项:
  • 并不是定制和第三方对象的所有特征都可以访问。
 

3.1.5 性能概要分析

性能测试测量响应时间、事务速率和其他与时间相关的需求。性能测试的目标是验证性能需求已经实现。性能测试通常执行多次,每次在系统上使用不同的“后台负载”。初始测试应使用“额定”负载(类似于目标系统上的正常负载或预期负载)执行。第二个性能测试使用高峰负载运行。

此外,性能测试可用于设定和调整系统的性能,使它成为多种状况(例如工作负载或硬件配置)的作用结果。

注意:下面的事务涉及“逻辑业务事务”。这些事务被定义为预期系统的某个用户要使用应用程序执行的特定功能,例如添加或修改给定的合同。

 

测试目标: 验证以下两种状况下指定的事务或业务功能的系统响应时间:

- 正常的预期容量

- 预期的较差容量

技术:
  • 使用为业务模型测试(系统测试)开发的测试脚本。
  • 修改数据文件(以增加事务数),或修改脚本以增加每个事务发生的迭代次数。
  • 脚本应在一台机器上运行(最符合“一个用户、一个事务”基准),并对多个客户机重复(虚拟客户机或实际客户机,请参阅下面的特殊注意事项)。
完成标准:
  • 一个事务/一个用户:测试脚本在预期/需要的时间分配内成功完成,无任何故障(每个事务)
  • 多个事务/多个用户:测试脚本在可接受的时间分配内成功完成,无任何故障。
特殊注意事项:
  • 综合性能测试包含在服务器上施加“后台”负载。可以用于执行这种操作的有若干方法,包括:
    • 直接向服务器“驱动事务”(通常使用 SQL 调用的形式)。
    • 创建“虚拟”用户负载来模拟许多客户机(通常数百)。远程终端仿真工具可以用于完成此负载。此技术也可以用于给网络加上“流量”。
    • 使用多个物理客户机,每个都运行测试脚本,对系统施加负载。
  • 性能测试应在专用机器上或在专用时间执行。这可以实现完全控制和精确度量。
  • 用于性能测试的数据库应为实际大小或同等比例大小。

 

3.1.6 负载测试

负载测试让待测试系统承受不同的工作负载,从而评估系统有多大的能力在这些不同的工作负载下正常工作。负载测试的目标是确定和确保系统在超过预期的最大工作负载时正常运转。此外,负载测试还评估性能特征(响应时间、事务率和其他与时间相关的问题)。

注意:下面的事务涉及“逻辑业务事务”。这些事务被定义为预期系统的某个用户要使用应用程序执行的特定功能,例如添加或修改给定的合同。

 

测试目标: 验证不同工作负载状况下所指定事务或业务案例的系统响应时间。
技术:
  • 使用为业务周期测试开发的测试。
  • 修改数据文件(以增加事务数),或修改测试以增加每个事务发生的次数。
完成标准:
  • 多个事务/多个用户:测试在可接受的时间分配内成功完成,无任何故障。
特殊注意事项:
  • 负载测试应在专用机器上或在专用的时间执行。这可以实现完全控制和精确度量。
  • 用于负载测试的数据库应为实际大小或同等比例大小。
 

3.1.7 强度测试

本节不适用于体系结构原型的测试。

3.1.8 容量测试

本节不适用于体系结构原型的测试。

3.1.9 安全性和访问控制测试

安全性和访问控制测试专注于安全性的两个关键方面:

应用程序安全性,包括对数据或业务功能的访问。
系统安全性,包括对系统的远程访问。

根据您想要的安全性,应用程序安全性确保用户被限定使用特定的功能,或他们被限制使用他们可用的数据。例如,可能允许每个人输入数据和创建新帐户,但仅经理可以删除它们。如果存在数据级别的安全性,则测试确保用户“类型”一可以看到所有客户信息(包括财务数据),但是用户类型二仅可以看到同一客户机的调查数据。

系统安全性确保仅授权访问系统的那些用户能访问应用程序,并且只能通过适当的网关进行访问。

 

测试目标: 功能/数据安全性:验证用户仅可以访问向他们的用户类型提供许可权的那些功能/数据。

系统安全性:验证仅具有系统和应用程序访问权的那些用户可以访问它们。

技术:
  • 功能/数据安全性:确定并列出每个用户类型以及每个类型具有许可权的功能/数据。
  • 为每个用户类型创建测试,并通过创建特定于每个用户类型的事务来验证许可权。
  • 修改用户类型并对相同的用户重新运行测试。在每种情况下,验证那些附加功能/数据被正确提供或拒绝。
  • 系统访问(请参阅下面的特殊注意事项)
完成标准: 对于每个已知用户类型,可以使用适当的功能/数据,并且所有事务如期望的那样运行并在之前的“应用程序功能”测试中运行
特殊注意事项:
  • 必须与相应的网络管理员或系统管理员检查/讨论系统的访问权。此测试可能不是必需的,因为这可能是网络管理或系统管理的一个功能。
 

3.1.10 故障转移和恢复测试

本节不适用于体系结构原型的测试。

3.1.11 配置测试

配置测试验证软件在不同的软件和硬件配置上的运行。在多数生产环境中,客户机工作站、网络连接和数据库服务器的特定硬件要求都是不同的。客户机工作站可能装入了不同的软件,例如应用程序、驱动程序等。在任意时候,都可能存在许多不同的组合并且使用不同的资源。

 

测试目标: 验证客户机应用程序在规定的客户机工作站上正确运行。
技术:
  • 使用集成和系统测试脚本。
  • 或者作为测试的一部分,或者在测试开始之前,打开/关闭各种 PC 应用程序。
  • 执行选中的事务对各种 PC 应用程序模拟用户活动。
  • 将客户机上的可用常规内存降到最低,然后重复上述过程。
完成标准: 对于原型和 PC 应用程序的每种组合,事务都成功完成(无故障)。
特殊注意事项:
  • 在客户机上可以使用和访问哪些 PC 应用程序?
  • 通常使用哪些应用程序?
  • 这些应用程序在运行什么数据(例如,在 Excel 中打开的一个较大电子表格,Word 中的 100 页的文档)。
  • 整个系统、网络服务器、数据库等也应当记录为此测试的一部分。

 

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 日

     

6.    工作产品

    下表概括了此测试计划中定义的测试任务的工作产品。

    工作产品 所有者 复审/分发 到期日
    测试计划 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] 中所定义):

更新 RequisitePro 中的测试状态将是系统测试员的职责。

测试结果将保留在配置控制下。

6.3 缺陷报告

Rational ClearQuest 将用于记录和跟踪每个缺陷。

7.    项目 任务

下面是测试“课程注册体系结构原型”的测试相关任务:

计划测试

确定测试需求

评估风险

制订测试策略

确定测试资源

创建日程表

生成测试计划

设计测试

工作负载分析(不适用于原型)

开发测试套件

确定和描述测试用例

确定和构造测试脚本

检查和访问测试覆盖率

实施测试

设置测试环境

记录或程序测试脚本

开发测试存根和驱动程序

在设计和实施模型中确定特定于测试的功能

建立外部数据集

执行测试

执行测试脚本

评估测试的执行

从暂停的测试中恢复

验证结果

调查意外结果

记录缺陷

评估测试

评估测试用例覆盖率

评估代码覆盖率

分析缺陷

确定是否已完成“测试完成标准”和“成功标准”
创建测试评估报告

Copyright  (c) IBM Corp. 1987, 2004. All Rights Reserved.

课程注册项目 Web 示例
V2001.03