测试用例、测试计划的具体例子？？？
将具体的样例发到我的邮箱中，谢谢！！！jessiebian@21cn.com 问题点数：0、回复次数：3Top
1 楼klbt（快乐白兔）回复于 2003-08-02 21:56:27 得分 0
顶！Top
2 楼tj_dns（愉快的登山者）回复于 2003-08-20 13:08:46 得分 0
转载：
fastpoint 2002-9-10 13:55:21
大学体育寻呼系统
测试计划
版本 1.0
修订历史记录
日期
版本
说明
制作者
1999 年 10 月 26 日 1.0 初始版本 Context Integration
目录
简介
测试需求
测试策略
资源
项目里程碑
可交付工件
附录 A：项目任务
简介
目的
大学体育寻呼系统的“测试计划”文档有助于实现以下目标：
确定现有项目信息和应测试的软件构件
列出推荐的测试需求（高级）
推荐并说明可采用的测试策略
确定所需的资源，并对测试工作量进行估计
列出测试项目的可交付元素
背景
当发生属于订户预定的大学体育类别的体育赛事时，大学体育寻呼系统就会向订户发出字母数字寻
呼。随后，用户可以连接到个性化的 Web站点，查看与他们所接收的寻呼相对应的报道内容，以及其
他大学体育新闻。
系统由 3 个主要的子系统（包含在应用 Web 服务器中）构成，并与现有的 WebNewsOnLine Web
站点及寻呼网关进行交互。这些子系统包括：
内容管理 — 该子系统接受内容、标记类别、并向订户显示标题。该子系统还管理针对于特定订户组
的广告内容（根据他们的订阅简档确定）。
寻呼 — 当新内容装载到系统上时，该子系统即被激活。该子系统负责确定寻呼接收人，并负责向寻
呼网关发送消息。
报告 — 该子系统用于跟踪报告广告的浏览情况。
此系统构架的描述如下：
范围
将对大学体育寻呼系统进行单元测试和系统测试。单元测试处理功能方面的质量问题，而系统测试则
处理伸缩性和性能方面的问题。
对于子系统交互将进行如下测试：
用于寻呼的内容管理
用于报告的内容管理
将测试以下系统接口：
大学体育寻呼系统和现有 WebNewsOnLine Web 服务器的接口
大学体育寻呼系统与寻呼网关的接口
最关键的测试是负载和性能测试。测试将如下进行：
我们将创建一个测试场景，它将生成越来越多的寻呼（直到 200,000 个寻呼）。
我们还将创建另一个测试场景，在此场景中，新内容以每 20 秒一条的速度到达系统。
最后，我们将模拟不断增长的并行订户负载，直到 200，000。
项目标识
下表列出了制定测试计划所用的文档，并标明了文档的可用性：
标准与成功标准
fastpoint 2002-9-10 13:55:54
文档
（版本/日期） 已创建或可用 已被接收或已经过复审 制作者或来源 备注
前景文档 n 是 o 否 n 是 o 否 Context Integration
补充规约 n 是 o 否 n 是 o 否 Context Integration
用例报告 n 是 o 否 n 是 o 否 Context Integration
项目计划 n 是 o 否 n 是 o 否 Context Integration
设计规约 n 是 o 否 n 是 o 否
原型 n 是 o 否 n 是 o 否 Context Integration
项目/业务风险评估 n 是 o 否 n 是 o 否 Context Integration
测试需求
下面的列表列出了那些已被确定为测试目标的项目（用例、功能性需求、非功能性需求）。此列表说
明了测试的对象。
数据库测试
核实是否可以输入和检索订户信息。
核实是否可以插入和显示内容和类别。
核实是否可以输入和显示广告商简档和账户信息。
核实是否可以跟踪特定订户的使用信息。
功能性测试
核实订户能否查看到他们已请求发送寻呼的信息。
核实当新内容到达时，寻呼是否会发给订户。
核实自动内容插入功能是否有效。
核实编辑人员的批准是否会导致非自动内容的插入。
核实已终止订阅的订户是否不再收到寻呼。
核实是否没有向订户重复显示已标记为存档的内容。
核实是否删除了已过时的内容。
核实广告商报告是否准确。
核实广告商报告能否以 Word、Excel 或 HTML 格式来接收。
业务周期测试
无。
用户界面测试
浏览所有的用例，核实是否每个 UI 面板都易于理解。
核实所有的联机帮助功能。
核实是否所有的屏幕都符合 WebNewsOnLine 标准。
性能评测
核实寻呼网关系统接口的响应时间。
核实现有 WebNewsOnLine Web 服务器接口的响应时间。
核实使用 56Kbps 调制解调器进行连接时的响应时间。
核实本地接入时的响应时间（在同一 LAN 中）。
负载测试
核实在具有 200 名并行订户时的系统响应。
核实在具有 500 名并行订户时的系统响应。
核实在具有 1.000 名并行订户时的系统响应。
核实在具有 5.000 名并行订户时的系统响应。
核实在具有 10.000 名并行订户时的系统响应。
核实在具有 50.000 名并行订户时的系统响应。
核实在具有 100.000 名并行订户时的系统响应。
核实在具有 200.000 名并行订户时的系统响应。
强度测试
无。
容量测试
核实当单个内容元素到达时，寻呼是否在 5 分钟内发出。
核实当内容每隔 20 秒到达时，寻呼是否在 5 分钟内发出。
安全性和访问控制测试
核实非订阅用户是否不能访问仅向订户提供的信息。
核实非编辑人员是否不能批准内容。
核实广告商只能看到他们自己的广告内容。
故障转移/恢复测试
无。
配置测试
核实使用 Netscape V4.x 浏览器时的操作情况。
核实使用 Microsoft Internet Explorer V5.x 时的操作情况。
安装测试
无。
测试策略
测试类型
数据和数据库完整性测试
测试目标： 确保数据库访问方法和进程正常运行，数据不会遭到损坏。
方法： 调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据（或对数据的请求）。
检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件都已正常发生；或者检查所返回
的数据，确保为正当的理由检索到了正确的数据。
完成标准： 所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。
需考虑的特殊事项： 进程应该以手工方式调用。
应使用小型或最小的数据库（记录的数量有限）来使所有无法接受的事件具有更大的可见性。
功能测试
测试目标： 确保测试对象的功能正常，其中包括导航、数据输入、处理和检索等功能。
方法： 利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
完成标准： 所计划的测试已全部执行。
所发现的缺陷已全部解决。
需考虑的特殊事项： 无。
用户界面测试
测试目标： 核实以下内容：
通过测试对象进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段
之间的浏览，以及各种访问方法（Tab健、鼠标移动和快捷键）的使用。
Web 的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。
方法： 为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于
正常的对象状态。
完成标准： 成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准需考虑的特殊事项：
并不是所有定制或第三方对象的特征都可访问。
性能评测
测试目标： 核实所指定的事务或业务功能在以下情况下的性能行为：
正常的预期工作量
预期的最繁重工作量
方法： 使用为功能或业务周期测试制定的测试过程。
通过修改数据文件（来增加事务数量），或通过修改脚本来增加每项事务的迭代数量。
愉快的登山者
⊙
◢◣◢◣◢◣
Top
3 楼tj_dns（愉快的登山者）回复于 2003-08-20 13:09:08 得分 0
fastpoint 2002-9-10 13:56:2
脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或
实际的客户机，请参见下面的“需考虑的特殊事项”）上重复运行。
完成标准： 单个事务/单个用户：在每个事务所预期/要求的时间范围内成功地完成测试脚本，没有
发生任何故障。
多个事务/多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。
需考虑的特殊事项： 综合的性能测试还包括在服务器上添加“后台”工作量。
可采用多种方法来执行此操作，其中包括：
直接将“事务强行分配到”服务器上，这通常以 SQL 调用的形式来实现。
通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。此负载可通过“远程终端仿
真”(Remote Terminal Emulation)工具来实现。此技术还可用于在网络中加载“流量”。
使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。
性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。
性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。
负载测试
测试目标： 核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。
方法： 使用为功能或业务周期测试制定的测试。
通过修改数据文件来增加事务数量，或通过修改测试来增加每项事务发生的次数。
完成标准： 多个事务/多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。
需考虑的特殊事项： 负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制
和精确的评测。
负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。
容量测试
测试目标： 核实测试对象在以下高容量条件下能否正常运行：
连接（或模拟了）最大（实际或实际允许）数量的客户机，所有客户机在长时间内执行相同的、且情
况（性能）最坏的业务功能。
已达到最大的数据库大小（实际的或按比例缩放的），而且同时执行了多个查询/报表事务。
方法： 使用为性能评测或负载测试制定的测试。
应该使用多台客户机来运行相同的测试或互补的测试，以便在长时间内产生最繁重的事务量或最差的
事务组合（请参见上面的“强度测试”）。
创建最大的数据库大小（实际的、按比例缩放的、或填充了代表性数据的数据库），并使用多台客户
机在长时间内同时运行查询和报表事务。
完成标准： 所计划的测试已全部执行，而且在达到/超出指定的系统限制时没有出现任何软件故障。
需考虑的特殊事项： 对于上述的高容量条件，哪个时间段是可以接受的时间？
安全性和访问控制测试
测试目标： 应用程序级别的安全性：核实主角只能访问其所属用户类型已被授权访问的那些功能或
数据。
系统级别的安全性：核实只有具备系统和应用程序访问权限的主角才能访问系统和应用程序。
方法： 应用程序级别：确定并列出各主角类型及其被授权访问的功能或数据。
为各主角类型创建测试，并通过创建各用户主角所特有的事务来核实其权限。
修改用户类型并为相同的用户重新运行测试。对于每种用户类型，确保正确地提供或拒绝了这些附加
的功能或数据。
系统级别的访问（请参见下面的“需考虑的特殊事项”）
完成标准： 各种已知的主角类型都可访问相应的功能或数据，而且所有事务都按照预期的方式运行，
并在先前的功能测试中运行了所有的事务。
需考虑的特殊事项： 必须与相应的网络或系统管理员一起对系统访问权进行检查和讨论。由于此测
试可能是网络管理或系统管理的职能，可能会不需要执行此测试。
配置测试
测试目标： 核实测试对象可在所需的硬件/软件配置中正常运行。
方法： 使用功能测试脚本。
在测试过程中或在测试开始之前，打开各种与非测试对象相关的软件（例如 Microsoft 应用程序：
Excel 和 Word），然后将其关闭。
执行所选的事务，以模拟主角与测试对象软件和非测试对象软件之间的交互。
重复上述步骤，尽量减少客户机上的常规可用内存。
完成标准： 对于测试对象软件和非测试对象软件的各种组合，所有事务都成功完成，没有出现任何
故障。
需考虑的特殊事项： 需要、可以使用并可以通过桌面访问哪种非测试对象软件？
通常使用的是哪些应用程序？
应用程序正在运行什么数据（例如，在 Excel 中打开的大型电子表格，或是在 Word 中打开的 100
页文档）？
作为此测试的一部分，应将整个系统、Netware、网络服务器、数据库等都记录下来。
工具
此项目将使用以下工具：
工具
版本
缺陷跟踪 项目主页
项目管理 Microsoft Project
资源
本节列出推荐在测试大学体育寻呼系统时使用的资源，及其主要职责、知识或技能。
角色
下表列出了在此项目的人员配备方面所作的各种假定。
人力资源
角色 推荐的最少资源 具体职责/注释
测试经理/测试项目经理 1 名（大学体育寻呼系统项目经理） 进行管理监督
职责：
提供技术指导
获取适当的资源
管理报告
测试设计员 1 确定测试用例、确定测试用例的优先级并实施测试用例
职责：
生成测试计划
生成测试模型
评估测试工作的有效性
测试员 4 名（由 WebNewsOnLine 提供） 执行测试
职责：
执行测试
记录结果
修正错误
记录变更请求
测试系统管理员 1 确保测试环境和资产得到管理和维护
职责：
管理测试管理系统
分配/管理角色对测试系统的访问权
数据库管理/数据库管理员 1 名（由 WebNewsOnLine 提供） 确保测试数据（数据库）环境和资产得
到管理和维护
职责：
管理测试数据（数据库）
设计员 2 确定并定义测试类的操作、属性和关联
职责：
确定并定义测试类
确定并定义测试包
实施员 4 实施测试类和测试包，并对它们进行单元测试
职责：
创建在测试模型中实施的测试类和测试包
系统
下表列出了测试项目所需的系统资源。
此时并不完全了解测试系统的具体元素。建议使系统模拟生产环境，并在适当的情况下减小访问量和
数据库大小。
系统资源
资源 名称/类型
数据库服务器
-网络/子网 TBD
-服务器名 TBD
-数据库名 TBD
客户端测试 PC
-包括特殊配置
-需求 TBD
测试存储库
-网络/子网 TBD
-服务器名 TBD
测试开发 PC TBD
项目里程碑
里程碑任务 工作量 开始日期 结束日期
制定测试计划
设计测试
实施测试
执行测试
评估测试
可交付工件
测试模型
对于所执行的每个测试，都将创建一个测试结果表单。其中应包括以下内容：测试的名称或 ID、测
试的相关用例或补充规约、测试日期、测试员
ID、所要求的测试前提条件、以及测试的结果。
测试日志
将使用 Microsoft Word 来记录和报告测试结果。
缺陷报告
将使用 Web 上的项目主页来记录缺陷。
附录 A：项目任务
以下是一些与测试有关的任务：
制定测试计划
确定测试需求
评估风险
制定测试策略
确定测试资源
创建时间表
生成测试计划
设计测试
工作量分析
确定并说明测试用例
确定并构建测试过程
复审和访问测试覆盖
实施测试
记录或编写测试脚本
确定在设计和实施模型中的测试专用功能
建立外部数据集
执行测试
执行测试过程
评估测试的执行情况
恢复暂停的测试
核实结果
调查意外结果
记录缺陷
评估测试
评估测试用例覆盖
评估代码覆盖
分析缺陷
确定是否达到了测试完成
愉快的登山者
⊙
◢◣◢◣◢◣
Top
