课程注册系统
测试计划
V1.0
修订历史记录
日期 |
版本 |
描述 |
作者 |
1999 年 3 月 27 日 |
1.0 |
R1 和 R2 的测试计划 |
K. Stone |
|
|
|
|
|
|
|
|
|
|
|
|
目录
- 目标
- 范围
- 参考
- 测试需求
- 测试策略
- 测试类型
- 数据和数据库完整性测试
- 系统测试
- 业务周期测试
- 用户界面测试
- 性能测试
- 负载测试
- 压力测试
- 容量测试
- 安全性和访问权控制测试
- 故障转移/恢复测试
- 配置测试
- 安装测试
- 工具
- 资源
- 工作人员
- 系统
- 项目里程碑
- 工作产品
- 测试套件
- 测试日志
- 缺陷报告
- 项目任务
测试计划
1. 目标
本文档描述有关测试“课程注册系统”的计划。本测试计划文档支持以下目标:
- 确定现有的项目信息和应当测试的软件组件。
- 列出建议的测试需求(高级别)。
- 推荐使用的测试策略并加以描述。
- 指出需要的资源并提供对测试工作的估计。
- 列出测试任务的工作产品元素。
2. 范围
本测试计划适用于将在“课程注册系统”R1 和 R2 上执行的集成和系统测试。请注意存在描述体系结构原型的测试策略的单独测试计划 [17]。
假设单元测试已通过广泛覆盖源代码和测试所有模块接口,提供了彻底的黑匣测试。
本测试计划适用于测试远景文档 [3]、用例规范 [5-12] 和补充规范 [13] 中定义的“课程注册系统”的所有需求。
3. 参考
适用的参考资料有:
- Course Billing Interface Specification, WC93332, 1985, Wylie College
Press.
- Course Catalog Database Specification, WC93422, 1985, Wylie College
Press.
- Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
- Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
- Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College
IT.
- Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
- Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999,
Wylie College IT.
- Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie
College IT.
- Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999,
Wylie College IT.
- Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie
College IT.
- Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College
IT.
- Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie
College IT.
- Course Registration System Supplementary Specification,
WyIT400, V1.0, 1999, Wylie College IT.
- Course Registration System Software Development Plan, WyIT418, V2.0, 1999, Wylie College IT.
- Course Registration System Software Architecture Document,
WyIT431, V1.0, 1999, Wylie College IT.
- Course Registration System Requirements Attributes Guidelines,
WyIT404, V1.0, 1999, Wylie College IT.
- Course Registration System Test Plan for the Architectural
Prototype, WyIT432, V1.0, 1999, Wylie College IT.
4. 测试需求
下面的列表指出那些被确定为测试目标的项(用例、功能需求和非功能需求)。这个列表列出将测试什么。确定测试用例并开发了测试脚本后,接下来就确定有关每个测试的详细信息。
(注意:本测试计划的未来发行版可能使用 Rational RequisitePro 直接链接到远景文档、用例文档和补充规范中的需求。)
数据和数据库完整性测试
验证对“课程目录数据库”的访问。
验证同时的记录读访问。
验证“课程目录”更新期间的锁定。
验证对数据库数据更新的正确检索。
系统测试(即功能测试)
验证“登录”用例 [6]
验证“封闭式注册”用例 [5]
验证“维护学生信息”用例 [10]
验证“维护教授信息”用例 [7]
验证“提交等级”用例 [11]
验证“查看报告卡”用例 [12]
验证“注册课程”用例 [8]
验证“选择讲授课程”用例 [9]
补充规范,第 4.1 节:“应记录所有系统错误。致命的系统错误应引起系统正常关闭。”
补充规范,第 4.1 节:“系统错误消息应包含错误的文本描述、操作系统错误代码(如果适用)、检测到错误状况的模块、数据戳记和时间戳记。所有系统错误都应保留在错误日志数据库中。”
远景文档,第 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 MainFrame 上运行的现有旧系统(课程目录数据库)集成。”
补充规范,第 9.2 节:“系统应与在 College DEC VAX MainFrame 上运行的现有课程计费系统集成。”
业务周期测试
验证下载新的课程目录之后的操作。
验证跨多个学期和多年的操作。
验证在学期跨年时运行是否正确。
用户界面测试
验证浏览一系列样本屏幕的难易程度。
验证样本屏幕是否符合 GUI 标准。
远景文档,第 10 节:“系统应易于使用,并且应适合熟悉计算机的学生和教授的目标市场。”
远景文档,第 12.1 节:“桌面用户界面应符合 Windows 95/98。”
补充规范,第 5.1 节:“桌面用户界面应符合 Windows 95/98。”
补充规范,第 5.2 节:“课程注册系统的用户界面应易于使用,并且应适合没有培训过使用系统但熟悉计算机的用户群。”
补充规范,第 5.3 节:“课程注册系统的每个功能部件都应有提供给用户的内置联机帮助。联机帮助应包含有关使用系统的逐步指示信息。联机帮助应包含术语和首字母缩写的定义。”
性能测试
验证访问外部财务系统的响应时间。
验证访问外部课程目录子系统的响应时间。
验证远程登录的响应时间。
验证课程注册的远程提交的响应时间。
远景文档,第 12.3 节:“系统应提供对旧课程目录数据库的访问,但等待时间不超过 10 秒。”
补充规范,第 7.2 节:“系统应提供对旧课程目录数据库的访问,但等待时间不超过 10 秒。”
装入测试
验证承受 200 个登录学生时的系统响应。
验证 50 个学生同时访问课程目录时的系统响应。
补充规范,第 7.1 节:“在任意给定时间,对于中心数据库,系统都应支持 2000 个同时用户,而在任意时间,对于本地服务器,都应支持多达 500 个同时用户。”
强度测试
验证在使用 UNIX 服务器的重要时间段期间的系统响应。
验证最多学生登录时的系统响应。
容量测试
验证课程目录数据库处于 90% 容量时的系统响应。
安全性和访问控制测试
验证从本地 PC 进行的登录。
验证从远程 PC 进行的登录。
验证使用用户名和密码机制时的登录安全性。
补充规范,第 4.2 节:“通过因特网连接应可远程使用所有功能。”
故障转移/恢复测试
补充规范,第 6.1 节:“一周 7 天,一天 24 小时都应可使用课程注册系统。应不超过 4% 的停机时间。”
补充规范,第 6.2 节:“平均故障间隔时间应超过 300 小时。”
配置测试
远景文档,第 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 运行时环境兼容。”
安装测试
补充规范,第 8.1 节:“应可通过因特网从 UNIX 服务器下载对课程注册的 PC 客户机部分的升级。”
验证服务器部分的安装。
验证客户机部分的安装。
5. 测试策略
测试策略提供测试软件应用程序的建议方法。有关测试需求的前一节描述了将测试什么;这一节描述将如何测试它。
测试策略的主要注意事项是要使用的技术和了解何时完成测试的标准。
除了为下面的每个测试提供的注意事项以外,还应只使用已知的受控数据库在安全环境中执行测试。
以下测试策略在本质上是通用的,并且意在适用于本文档的第 4 节中列出的需求。
- 测试类型
1. 数据和数据库完整性测试
数据库和数据库进程应作为独立的系统进行测试。这些系统应不带应用程序(作为数据的接口)进行测试。需要执行对数据库管理系统(DBMS)的更多研究,来指出可能存在的、支持下面所列测试的工具/技术。
测试目标: |
确保数据库访问方法和进程正确运行并且没有数据损坏。 |
技术: |
- 调用每个数据库访问方法和进程,并且对每个同时使用有效数据和无效数据(或数据请求)。
- 检查数据库,确保数据照预期填充并且所有数据库事件正确发生,或检查返回的数据,确保(为正确的起因)检索到正确的数据。
|
完成标准: |
所有数据库访问方法和进程都按设计的那样运行并且没有数据损坏。 |
特殊注意事项: |
- 测试可能需要 DBMS 开发环境或驱动程序以在数据库中直接输入或修改数据。
- 进程应手动调用。
- 应使用小数据库或超小数据库(记录数有限)来使任何不可接受的事件更易于发现。
|
2. 系统测试
应用程序的测试应专注于所有可以直接跟踪到用例(或业务功能)的目标需求,同时专注于业务规则。这些测试的目标是验证正确的数据验收、处理和检索以及适当的业务规则实施。这种测试基于黑匣技术;即,通过图形用户界面(GUI)与应用程序交互并分析输出(结果),来验证应用程序(及其内部进程)。下面概括了为每个应用程序建议的测试:
测试目标: |
确保正确的应用程序导航、数据输入、处理和检索。 |
技术: |
- 使用有效数据和无效数据执行每个用例、用例流或功能,验证以下方面:
- 当使用有效数据时,预期的结果发生。
- 当使用无效数据时,显示相应的错误/警告消息。
- 正确应用了每条业务规则。
|
完成标准: |
- 所有计划的测试都已执行。
- 所有指出的缺陷都已处理。
|
特殊注意事项: |
- 需要对 Wylie College UNIX 服务器以及现有课程目录系统和计费系统的访问。
|
3. 业务周期测试
业务周期测试应模拟随时间在系统上执行的活动。应确定一个时间段(例如一年),并应执行在一年的时间段期间将发生的事务和活动。这包括所有每日、每周、每月的周期,以及与日期相关的事件(例如记录簿)。
测试目标 |
确保适当的应用程序和后台进程按照所需的业务模型和日程表正常运行。 |
技术: |
- 测试将通过执行以下操作模拟若干业务周期:
- 对应用程序功能的测试将进行修改/增强,以增加执行每个功能的次数,从而在指定的时间段内模拟多个不同的用户。
- 所有与时间相关或与日期相关的功能将使用有效和无效的日期或时间段执行。
- 所有定期执行的功能将在相应的时间执行/启动。
- 测试将包括使用有效数据和无效数据验证以下方面:
- 当使用有效数据时,预期的结果发生。
- 当使用无效数据时,显示相应的错误/警告消息。
- 正确应用了每条业务规则。
|
完成标准: |
- 所有计划的测试都已执行。
- 所有指出的缺陷都已处理。
|
特殊注意事项: |
- 系统日期和事件可能需要特殊的支持活动
- 需要业务模型来确定相应的测试需求和过程。
|
4. 用户界面测试
用户界面测试验证用户与软件的交互。UI 测试的目标是确保用户界面向用户提供对应用程序功能的相应访问和浏览。此外,UI 测试还确保 UI 中的对象照预期工作并符合社团或行业标准。
测试目标: |
验证以下方面:
- 对应用程序的浏览正确反映业务功能和需求,包括窗口到窗口、字段到字段以及访问方法的使用(Tab 键、鼠标移动和加速键)
- 窗口对象和特征(例如菜单、大小、位置、状态和焦点)符合标准。
|
技术: |
- 为每个窗口创建/修改测试,验证每个应用程序窗口和对象的正确导航和对象状态。
|
完成标准: |
成功验证每个窗口都与基准版本一致或都在可接受的标准内 |
特殊注意事项: |
|
5. 性能测试
性能测试测量响应时间、事务速率和其他与时间相关的需求。性能测试的目标是验证性能需求已经实现。性能测试通常执行多次,每次在系统上使用不同的“后台负载”。初始测试应使用“额定”负载(类似于目标系统上的正常负载或预期负载)执行。第二个性能测试使用高峰负载运行。
此外,性能测试可用于设定和调整系统的性能,使它成为多种状况(例如工作负载或硬件配置)的作用结果。
注意:下面的事务涉及“逻辑业务事务”。这些事务被定义为预期系统的某个用户要使用应用程序执行的特定功能,例如添加或修改给定的合同。
测试目标: |
验证以下两种状况下指定的事务或业务功能的系统响应时间: - 正常的预期容量
- 预期的较差容量 |
技术: |
- 使用为业务模型测试(系统测试)开发的测试脚本。
- 修改数据文件(以增加事务数),或修改脚本以增加每个事务发生的迭代次数。
- 脚本应在一台机器上运行(最符合“一个用户、一个事务”基准),并对多个客户机重复(虚拟客户机或实际客户机,请参阅下面的特殊注意事项)。
|
完成标准: |
- 一个事务/一个用户:测试脚本在预期/需要的时间分配内成功完成,无任何故障(每个事务)
- 多个事务/多个用户:测试脚本在可接受的时间分配内成功完成,无任何故障。
|
特殊注意事项: |
- 综合性能测试包含在服务器上施加“后台”负载。可以用于执行这种操作的有若干方法,包括:
- 直接向服务器“驱动事务”(通常使用 SQL 调用的形式)。
- 创建“虚拟”用户负载来模拟许多客户机(通常数百)。远程终端仿真工具可以用于完成此负载。此技术也可以用于给网络加上“流量”。
- 使用多个物理客户机,每个都运行测试脚本,对系统施加负载。
- 性能测试应在专用机器上或在专用时间执行。这可以实现完全控制和精确度量。
- 用于性能测试的数据库应为实际大小或同等比例大小。
|
6. 负载测试
负载测试让待测试系统承受不同的工作负载,从而评估系统有多大的能力在这些不同的工作负载下正常工作。负载测试的目标是确定和确保系统在超过预期的最大工作负载时正常运转。此外,负载测试还评估性能特征(响应时间、事务率和其他与时间相关的问题)。
注意:下面的事务涉及“逻辑业务事务”。这些事务被定义为预期系统的某个用户要使用应用程序执行的特定功能,例如添加或修改给定的合同。
测试目标: |
验证不同工作负载状况下所指定事务或业务案例的系统响应时间。 |
技术: |
- 使用为业务周期测试开发的测试。
- 修改数据文件(以增加事务数),或修改测试以增加每个事务发生的次数。
|
完成标准: |
- 多个事务/多个用户:测试在可接受的时间分配内成功完成,无任何故障。
|
特殊注意事项: |
- 负载测试应在专用机器上或在专用的时间执行。这可以实现完全控制和精确度量。
- 用于负载测试的数据库应为实际大小或同等比例大小。
|
7. 强度测试
强度测试旨在找到由于资源少或资源发生竞争而产生的错误。内存或磁盘空间偏低可能揭示在正常状况下不明显的软件缺陷。其他缺陷可能是共享资源(例如数据库锁或网络带宽)的竞争导致的。强度测试指出系统可处理的高峰负载。
注意:下面对事务的引用指逻辑业务事务。
测试目标: |
验证在以下压力状况下系统和软件是否正确运行并且无错误:
- 服务器上可用内存很少或没有可用内存(RAM 和 DASD)
- 连接(或模拟)的最大(实际或物理上可行的)客户机数
- 对相同数据/帐户执行相同事务的多个用户
- 最坏情况的事务量/混合(请参阅上面的性能测试)。
注意:还可以将强度测试的目标表述为指出并记录系统在什么状况下无法继续正常工作。 |
技术: |
- 使用为性能测试开发的测试。
- 要测试有限的资源,应在一台机器上运行测试,并且服务器上的 RAM 和 DASD 应该减少(或限制)。
- 对于剩余的强度测试,应使用多个客户机,运行相同测试或互补测试以生成最坏情况的事务量/混合。
|
完成标准: |
所有计划的测试都已执行,并且指定的系统限制已达到/超过,而没有软件失败(或者系统失败状况不是指定的状况)。 |
特殊注意事项: |
- 向网络施加压力可能需要使用网络工具给网络加上消息/数据包。
- 用于系统的 DASD 应临时减少以限制可供数据库增长的空间。
- 使客户机对相同记录/数据帐户的同时访问保持同步。
|
8. 容量测试
容量测试使软件承受大量数据,来确定是否达到导致软件失败的限制。容量测试还确定系统在给定的时间段内可以处理的持续最大负载或容量。例如,如果软件在处理一组数据库记录以生成报告,则容量测试将使用一个较大的测试数据库,检查软件是否正常运转并生成正确的报告。
测试目标: |
验证在以下高容量情况下应用程序/系统是否成功运行:
- 连接(或模拟)的最大(实际或物理上可行的)客户机数,所有客户机都长时间执行相同的、情况(性能)最差的业务功能。
- 已达到最大数据库大小(实际或一定比例),并同时执行了多个查询/报告事务。
|
技术: |
- 使用为性能测试开发的测试。
- 应使用多个客户机,运行相同测试或互补测试以在很长的时间段中生成最坏情况的事务量/混合(请参阅上面的强度测试)。
- 创建最大的数据库大小(实际、一定比例或以代表性数据填充),并使用多个客户机在很长的时间段中同时运行查询/报告事务。
|
完成标准: |
所有计划的测试都已执行,并且指定的系统限制已达到/超过,而没有软件失败。 |
特殊注意事项: |
- 哪段时间将视为高容量状况(如上所述)的可接受时间?
|
9. 安全性和访问控制测试
安全性和访问控制测试专注于安全性的两个关键方面:
应用程序安全性,包括对数据或业务功能的访问。
系统安全性,包括登录和对系统的远程访问。
根据您想要的安全性,应用程序安全性确保用户被限定使用特定的功能,或他们被限制使用他们可用的数据。例如,可能允许每个人输入数据和创建新帐户,但仅经理可以删除它们。如果存在数据级别的安全性,则测试确保用户“类型”一可以看到所有客户信息(包括财务数据),但是用户类型二仅可以看到同一客户机的调查数据。
系统安全性确保仅授权访问系统的那些用户能访问应用程序,并且只能通过适当的网关进行访问。
测试目标: |
功能/数据安全性:验证用户仅可以访问向他们的用户类型提供许可权的那些功能/数据。
系统安全性:验证仅具有系统和应用程序访问权的那些用户可以访问它们。 |
技术: |
- 功能/数据安全性:确定并列出每个用户类型以及每个类型具有许可权的功能/数据。
- 为每个用户类型创建测试,并通过创建特定于每个用户类型的事务来验证许可权。
- 修改用户类型并对相同的用户重新运行测试。在每种情况下,验证那些附加功能/数据被正确提供或拒绝。
- 系统访问(请参阅下面的特殊注意事项)
|
完成标准: |
对于每个已知用户类型,可以使用适当的功能/数据,并且所有事务如期望的那样运行并在之前的“应用程序功能”测试中运行 |
特殊注意事项: |
- 必须与相应的网络管理员或系统管理员检查/讨论系统的访问权。此测试可能不是必需的,因为这可能是网络管理或系统管理的一个功能。
|
10. 故障转移/恢复测试
故障转移/恢复测试确保:应用程序或整个系统可以从各种硬件、软件或网络故障(这些故障会造成不当的数据丢失或数据完整性问题)中成功地进行故障转移和恢复。
对于必须保持运行的那些系统,故障转移测试确保当故障转移状况出现时,替代系统或备份系统会正确“接管”失败的系统,而不会丢失任何数据或事务。
恢复测试是一种对抗性的测试流程,其中应用程序或系统暴露在极端状况(或模拟状况)下,例如设备 I/O 故障或无效的数据库指针/键。期间会调用恢复过程,并且监视和/或检查该应用程序/系统,以验证应用程序/系统是否正常并且数据恢复是否已实现。
测试目标: |
验证恢复过程(手动或自动)是否将数据库、应用程序和系统正确地恢复为期望的已知状态。以下类型的状况将包含在测试中:
- 客户机的电源中断
- 服务器的电源中断
- 网络服务器的通信中断
- DASD 和/或 DASD 控制器的中断、通信丢失或断电
- 周期不完整(数据过滤过程中断,数据同步过程中断)。
- 无效的数据库指针/键
- 数据库中无效/损坏的数据元素
|
技术: |
为应用程序功能和业务周期测试创建的测试应当用于创建一系列事务。一旦到达期望的开始测试点,应逐个地执行(或模拟)以下操作:
- 客户机的电源中断:关闭 PC 电源
- 服务器的电源中断:模拟或启动服务器的关闭电源过程
- 网络服务器的中断:模拟或启动网络的通信丢失(物理断开通信线路或关闭网络服务器/路由器的电源)。
- DASD 和/或 DASD 控制器的中断、通信丢失或断电:模拟或物理消除与一个或多个 DASD 控制器或设备的通信。
一旦达到上述状况/模拟状况,应执行附加事务,并在达到第二个测试点状态时,应调用了恢复过程。
测试不完整的周期利用与上述相同的技术,除了数据库进程本身应异常终止或过早终止。
测试以下状况需要达到一个已知的数据库状态。多个数据库字段、指针和键应手动和直接在数据库内(通过数据库工具)损坏。应使用应用程序功能和业务周期测试中的测试执行附加事务,并应执行完整的周期。 |
完成标准: |
在上面的所有情况中,应用程序、数据库和系统应当在完成恢复过程后返回到已知的期望状态。此状态包含限制为已知损坏字段的数据损坏、指针/键和指出由于中断而未完成的进程或事务的报告。 |
特殊注意事项: |
- 恢复测试是具有高度侵略性的。断开电缆的过程(模拟电源或通信丢失)可能不适合或不可行。可能需要替代方法,例如诊断软件工具。
- 需要来自系统(或计算机操作)、数据库和连网组的资源。
- 这些测试应在数小时之后运行或在孤立的机器上运行。
|
11.
配置测试
配置测试验证软件在不同的软件和硬件配置上的运行。在多数生产环境中,客户机工作站、网络连接和数据库服务器的特定硬件要求都是不同的。客户机工作站可能装入了不同的软件,例如应用程序、驱动程序等。在任意时候,都可能存在许多不同的组合。
测试目标: |
验证客户机应用程序在规定的客户机工作站上正确运行。 |
技术: |
- 使用集成和系统测试脚本。
- 或者作为测试的一部分,或者在测试开始之前,打开/关闭各种 PC 应用程序。
- 执行选中的事务对各种 PC 应用程序模拟用户活动。
- 将客户机上的可用常规内存降到最低,然后重复上述过程。
|
完成标准: |
对于每个组合,事务都成功完成(无故障)。 |
特殊注意事项: |
- 在客户机上可以使用和访问哪些 PC 应用程序?
- 通常使用哪些应用程序?
- 这些应用程序在运行什么数据(例如,在 Excel 中打开的一个较大电子表格,Word 中的 100 页的文档)。
- 整个系统、网络服务器、数据库等也应当记录为此测试的一部分。
|
12.
安装测试
安装测试有两个目的。第一个是确保该软件不管是正常状况还是非正常状况,都可在所有可能的配置(例如新安装、升级、完全安装或定制安装)上进行安装。非正常状况包括磁盘空间不足、缺少创建目录的特权等。第二个目的是验证软件一旦安装就可以正确运转。这通常意味着运行为功能测试开发的多个测试。
测试目标: |
验证在以下状况下是否将客户机软件正确安装到每个客户机上:
- 新安装,新机器,从未安装过。
- 更新先前已安装相同版本的机器
- 更新先前已安装旧版本的机器
|
技术: |
- 手动或自动开发脚本以验证目标机器的状况(全新 - 从未安装,已安装相同版本或旧版本)。
- 启动/执行安装。
- 使用集成或系统测试脚本的预先确定的子集,运行事务。
|
完成标准: |
事务成功执行,无故障。 |
特殊注意事项: |
- 应选择哪些事务来构成置信度测试:应用程序已成功安装,并且没有遗漏主要软件组件?
|
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 |
6. 资源
本节说明测试“课程注册系统”的建议资源、它们的主要职责和它们的知识或技能集。
-
工作人员
此表显示测试任务的人员配备假设。
人力资源
工作人员 |
建议的最小资源 (分配的全职工作人员数) |
具体职责/注释 |
测试经理 |
1 - Kerry Stone |
提供管理监管 职责:
|
测试设计人员 |
Margaret Cox
Carol Smith
Sophie King
|
确定测试用例、划分测试用例优先级然后实施测试用例 职责:
|
系统测试员 |
Carol Smith
Sophie King
Adrian Harmsen
|
执行测试
职责:
|
测试系统管理员 |
Simon Jones |
确保测试环境和资产受管理并得到维护。
职责:
- 管理测试管理系统
- 安装/管理工作人员对测试系统的访问
|
数据库管理/数据库经理 |
Margaret Cox |
确保测试数据(数据库)环境和资产受管理并得到维护。
职责:
|
设计人员 |
Margaret Cox |
确定和定义测试类的运行、属性和关联 职责:
|
实施者 |
Margaret Cox
Adrian Harmsen
|
实施测试类和测试包并对它们执行单元测试
职责:
|
2. 系统
下表列出测试“课程注册系统”的系统资源。
系统资源 |
资源 |
名称/类型/序列号 |
Wylie College 服务器 |
序列号:X179773562b |
课程目录数据库 |
版本标识:CCDB-080885 |
计费系统 |
版本标识:BSSS-88335 |
客户机测试 PC |
|
10 台远程 PC(可访问因特网) |
序列号:A8339223
序列号:B9334022
序列号:B9332544
<7 TBD> |
6 台本地 PC(连接 LAN) |
序列号:R3322411(注册处)
序列号:A8832234(IT 实验室)
序列号:W4592233(IT 实验室)
序列号:X3333411(教员办公室)
序列号:A987344(科学实验室)
序列号:X9834000(学生协会) |
测试存储库 |
|
Wylie College 服务器 |
序列号:X179773562b |
测试开发 PC - 6 |
序列号:A8888222
序列号:R3322435
序列号:I88323423
序列号:B0980988
序列号:R3333223
序列号:Y7289732 |
负载模拟器 |
序列号:ABC-123 |
7. 项目里程碑
测试活动和里程碑在很大程度上取决于开发迭代。构造阶段将分为 3 个迭代。每个迭代都包含测试计划、设计、开发、执行和评估的完整测试周期。
请参阅软件开发计划 [14] 和迭代计划,获取说明开发迭代的主日程表和构造阶段计划。
下表显示了测试里程碑。工时、开始日期和结束日期可以按照迭代内容的计划完成。
里程碑任务 |
工时(pd) |
开始日期 |
结束日期 |
迭代 C1:Beta 发行版
测试计划
测试设计
测试开发
测试执行
测试评估 |
TBD |
3 月 15 日 |
4 月 12 日 |
迭代 C2:R1.0 发行版
测试计划
测试设计
测试开发
测试执行
测试评估 |
TBD |
4 月 13 日 |
5 月 14 日 |
迭代 C3:R2.0 发行版
测试计划
测试设计
测试开发
测试执行
测试评估 |
TBD |
5 月 15 日 |
6 月 17 日 |
8. 工作产品
下表概括了此测试计划中定义的测试任务的工作产品。
请注意有些工作产品生成多次;每个测试周期或迭代都生成一次。其他工作产品(例如测试计划)是每个开发迭代都作一次更新。
工作产品 |
所有者 |
复审/分发 |
到期日 |
测试计划 |
K. Stone |
高级项目管理小组 |
3 月 28 日 |
测试环境 |
S. Jones |
- |
3 月 28 日 |
测试套件 |
C. Smith 和 M. Cox |
内部同级复审 |
3 月 28 日 |
测试数据集 |
M. Cox |
内部同级复审 |
3 月 31 日 |
测试脚本 |
M. Cox |
- |
4 月 2 日 |
测试存根,驱动程序 |
M. Cox |
- |
4 月 4 日 |
测试缺陷报告 |
C. Smith |
高级项目管理小组 |
TBD |
测试结果
|
C. Smith |
测试经理 |
TBD |
测试评估报告 |
C. Smith |
高级项目管理小组 |
TBD |
1. 测试套件
测试套件将定义所有测试用例和与每个测试用例关联的测试脚本。
2. 测试日志
计划使用 RequisitePro 确定测试用例并跟踪每个测试用例的状态。在 RequisitePro 中测试结果将总结为“未测试”、“已通过”、“有条件通过”或者“失败”。总之,将设置 RequisitePro 支持每个测试用例的以下属性(如需求属性准则 [16] 中所定义):
更新 RequisitePro 中的测试状态将是系统测试员的职责。
测试结果将保留在配置控制下。
Rational ClearQuest 将用于记录和跟踪每个缺陷。
9. 项目任务
下面是测试“课程注册系统”的测试相关任务:
计划测试 |
确定测试需求
|
评估风险
|
制定测试策略
|
确定测试资源
|
创建日程表
|
生成测试计划
|
设计测试 |
工作负载分析
|
开发测试套件
|
确定和描述测试用例
|
确定和构造测试脚本
|
检查和访问测试覆盖率
|
实施测试 |
设置测试环境
|
记录或程序测试脚本
|
开发测试存根和驱动程序
|
在设计和实施模型中确定特定于测试的功能
|
建立外部数据集
|
执行测试 |
执行测试脚本
|
评估测试的执行
|
从暂停的测试中恢复
|
验证结果
|
调查意外结果
|
记录缺陷
|
评估测试 |
评估测试用例覆盖率
|
评估代码覆盖率
|
分析缺陷
|
确定是否已完成“测试完成标准”和“成功标准”
|
创建测试评估报告
|
|