<项目名称>
测试计划
版本 <1.0>
[注：以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。]
[要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 File>Properties，然后将 Title、Subject 和 Company 等字段替换为此文档的相应信息。关闭该对话框后，通过选择 Edit>Select All（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按 Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见 Word 帮助。]
修订历史记录
|
日期 |
版本 |
说明 |
作者 |
|
<日/月/年> |
<x.x> |
<详细信息> |
<姓名> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目录
1. 简介 3
1.1 目的 3
1.2 背景 3
1.3 范围 3
1.4 项目标识 3
2. 测试需求 3
3. 测试策略 3
3.1 测试类型 3
3.1.1 数据和数据库完整性测试 3
3.1.2 功能测试 3
3.1.3 业务周期测试 3
3.1.4 用户界面测试 3
3.1.5 性能评价 3
3.1.6 负载测试 3
3.1.7 强度测试 3
3.1.8 容量测试 3
3.1.9 安全性和访问控制测试 3
3.1.10 故障转移和恢复测试 3
3.1.11 配置测试 3
3.1.12 安装测试 3
3.2 工具 3
4. 资源 3
4.1 角色 3
4.2 系统 3
5. 项目里程碑 3
6. 可交付工件 3
6.1 测试模型 3
6.2 测试日志 3
6.3 缺陷报告 3
7. 附录 A：项目任务 3
测试计划
<项目名称> 的这一“测试计划”文档有助于实现以下目标：
• [确定现有项目的信息和应测试的软件构件。
• 列出推荐的测试需求（高层次）。
• 推荐可采用的测试策略，并对这些策略加以说明。
• 确定所需的资源，并对测试的工作量进行估计。
• 列出测试项目的可交付元素]
[输入测试对象（组件、应用程序、系统等）及其目标的的简要说明。需要包括的信息有：主要的功能和特性、测试对象的构架以及项目的简史。本节应该只包含 3 至 5 个段落。]
[描述测试的各个阶段，例如：单元测试、集成测试或系统测试，并说明本计划所针对的测试类型（如功能测试或性能测试）。简要地列出测试对象中将接受测试或将不接受测试的那些特性和功能。
如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。
列出可能会影响测试设计、开发或实施的所有风险或意外事件。
列出可能会影响测试设计、开发或实施的所有约束。]
下表列出了制定测试计划所用的文档，并标明了文档的可用性：
[注：可以视情况删除或添加项目。]
|
文档
（版本/日期） |
已创建或可用 |
已被接受或已经过复审 |
作者或来源 |
备注 |
|
需求规约 |
o 是 o 否 |
o 是 o 否 |
|
|
|
功能性规约 |
o 是 o 否 |
o 是 o 否 |
|
|
|
用例报告 |
o 是 o 否 |
o 是 o 否 |
|
|
|
项目计划 |
o 是 o 否 |
o 是 o 否 |
|
|
|
设计规约 |
o 是 o 否 |
o 是 o 否 |
|
|
|
原型 |
o 是 o 否 |
o 是 o 否 |
|
|
|
用户手册 |
o 是 o 否 |
o 是 o 否 |
|
|
|
业务模型或业务流程 |
o 是 o 否 |
o 是 o 否 |
|
|
|
数据模型或数据流 |
o 是 o 否 |
o 是 o 否 |
|
|
|
业务功能和业务规则 |
o 是 o 否 |
o 是 o 否 |
|
|
|
项目或业务风险评估 |
o 是 o 否 |
o 是 o 否 |
|
|
下面列出了那些已被确定为测试对象的项目（用例、功能性需求和非功能性需求）。此列表说明了测试的对象。
[在此处输入一个主要测试需求的高层次列表。]
[测试策略提供了推荐用于测试对象的方法。上一节“测试需求”中说明了将要测试哪些对象，而本节则要说明如何对测试对象进行测试。
对于每种测试，都应提供测试说明，并解释其实施和执行的原因。
如果不实施和执行某种测试，则应该用一句话加以说明，并陈述这样做的理由。例如，“将不实施和执行该测试。。该测试不合适。”
制定测试策略时所考虑的主要事项有：将要使用的方法以及判断测试何时完成的标准。
下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、受控的数据库来执行。 ]
[数据库和数据库进程应作为<项目名称>中的子系统来进行测试。
在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和方法。]
|
测试目标： |
[确保数据库访问方法和进程正常运行，数据不会遭到损坏。] |
|
方法： |
· [调用各个数据库访问方法和进程，并在其中填充有效的和无效 的数据或对数据的请求。
· 检查数据库，确保数据已按预期的方式填充，并且所有 数据库事件都按正常方式出现；或者检查所返回的数据，确保为 正当的理由检索到了正确的数据] |
|
完成标准： |
[所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。] |
|
需考虑的特殊事项： |
· [测试可能需要 DBMS 开发环境或驱动程序以便在数据库中直接 输入或修改数据。
· 进程应该以手工方式调用。
· 应使用小型或最小的数据库（其中的记录数很有限）来 使所有无法接受的事件具有更大的可见性。] |
[测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。这种类型的测试基于黑盒方法，即通过图形用户界面 (GUI) 与应用程序交互并分析输出结果来验证应用程序及其内部进程。以下列出的是每个应用程序推荐的测试方法概要：]
|
测试目标： |
[确保测试对象的功能正常，其中包括导航、数据输入、处理和检索等。] |
|
方法： |
[利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：
· 在使用有效数据时得到预期的结果。
· 在使用无效数据时显示相应的错误消息或警告消息。
· 各业务规则都得到了正确的应用。] |
|
完成标准： |
· [所计划的测试已全部执行。
· 所发现的缺陷已全部解决。] |
|
需考虑的特殊事项： |
[确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）] |
