新版软件测试专题计划书模板.doc

软
件
测
试
计
划
书

修订历史统计
版本　　　　　　　
日期　　　　　　
AMD　　　　　　
修订者　　　　　
说明　　　　　

（A-添加，M-修改，D-删除）

目录
1． 介绍 4
1. 1目标 4
1. 2背景 4
1.3范围 4
2. 测试参考文档和测试提交文档 5
2.1测试参考文档 5
2.2测试提交文档 6
3.测试进度 6
4.测试资源 6
4.1人力资源 6
4.2测试环境 7
4.3测试工具 7
5.系统风险、优先级 7
6.测试策略 8
6.1数据和数据库完整性测试 8
6.2接口测试 9
6.3集成测试 9
6.4功效测试 10
6.5用户界面测试 10
6.6性能评测 11
6.7负载测试 12
6.8强度测试 13
6.9容量测试 14
6.10安全性和访问控制测试 15
6.11故障转移和恢复测试 16
6.12配置测试 17
6.13安装测试 18
7.问题严重度描述 19
8.附录：项目任务 19

1． 介绍
1. 1目标
＜项目名称＞这一“测试计划”文档有利于实现以下目标：

[确定现有项目标信息和应测试软件构件。
列出推荐测试需求（高级需求）。
推荐可采取测试策略，并对这些策略加以说明。
确定所需资源，并对测试工作量进行估量。
列出测试项目标可交付元素]
1. 2背景
[对测试对象（构件、应用程序、系统等）及其目标进行简明说明。需要包含信息有：关键功效和性能、测试对象构架和项目标简史。]
1.3范围
[描述测试各个阶段（比如，单元测试、集成测试或系统测试），并说明本计划所针正确测试类型（如功效测试或性能测试）。
简明地列出测试对象中将接收测试或将不接收测试那些性能和功效。
假如在编写此文档过程中做出一些假设可能会影响测试设计、开发或实施，则列出全部这些假设。
列出可能会影响测试设计、开发或实施全部风险或意外事件。
列出可能会影响测试设计、开发或实施全部约束。]

2. 测试参考文档和测试提交文档
2.1测试参考文档
下表列出了制订测试计划时所使用文档，并标明了各文档可用性：
[注：可合适地删除或添加文档项。]
文档
（版本/日期）
已创建或可用
已被接收或已经过复审
作者或起源
备注
可行性分析汇报
是□　否□
是□　否□

软件需求定义
是□　否□
是□　否□

软件系统分析
（STD,DFD,CFD,DD）
是□　否□
是□　否□

软件概要设计
是□　否□
是□　否□

软件具体设计
是□　否□
是□　否□

软件测试需求
是□　否□
是□　否□

硬件可行性分析汇报
是□　否□
是□　否□

硬件需求定义
是□　否□
是□　否□

硬件概要设计
是□　否□
是□　否□

硬件原理图设计
是□　否□
是□　否□

硬件结构设计（包含PCB）
是□　否□
是□　否□

FPGA设计
是□　否□
是□　否□

硬件测试需求
是□　否□
是□　否□

PCB设计
是□　否□
是□　否□

USB驱动设计
是□　否□
是□　否□

Tuner BSP 设计
是□　否□
是□　否□

MCU设计
是□　否□
是□　否□

模块开发手册
是□　否□
是□　否□

测试时间表及人员安排
是□　否□
是□　否□

测试计划
是□　否□
是□　否□

测试方案
是□　否□
是□　否□

测试汇报
是□　否□
是□　否□

测试分析汇报
是□　否□
是□　否□

用户操作手册
是□　否□
是□　否□

安装指南
是□　否□
是□　否□

2.2测试提交文档
[下面应该列出在测试阶段结束后，全部可提交文档]
3.测试进度
测试活动
计划开始日期
实际开始日期
结束日期
制订测试计划

设计测试

集成测试

系统测试

性能测试

安装测试

用户验收测试

对测试进行评定

产品公布

4.测试资源
4.1人力资源
下表列出了在此项目标人员配置方面所作多种假定。
[注：可合适地删除或添加角色项。]
角色
所推荐最少资源（所分配专职角色数量）
具体职责或注释

4.2测试环境
下表列出了测试系统环境
软件环境（相关软件、操作系统等）

硬件环境（网络、设备等）

4.3测试工具
此项目将列出测试使用工具：
用途
工具
生产厂商/自产
版本

5.系统风险、优先级
[简明描述测试阶段风险和处理优先级]

6.测试策略
[测试策略提供了对测试对象进行测试推荐方法。
对于每种测试，全部应提供测试说明，并解释其实施原因。
制订测试策略时所考虑关键事项有：将要使用技术和判定测试何时完成标准。
下面列出了在进行每项测试时需考虑事项，除此之外，测试还只应在安全环境中使用已知、有控制数据库来实施。]
注意：不实施某种测试，则应该用一句话加以说明，并陈说这么理由。比如，“将不实施该测试。该测试本项目不适用”。
6.1数据和数据库完整性测试
[要＜项目名称＞中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象用户界面用作数据接口。对于数据库管理系统（DBMS），还需要进行深入研究，以确定能够支持以下测试工具和技术。]

测试目标：
[确保数据库访问方法和进程正常运行，数据不会遭到损坏]

测试范围：

技术：
[调用各个数据库访问方法和进程，并在其中填充有效和无效数据（或对数据请求）。
检验数据库，确保数据已按预期方法填充，而且全部数据库事件已正常发生；或检验所返回数据，确保正当理由检索到了正确数据]
开始标准：

完成标准：
[全部数据库访问方法和进程全部根据设计方法运行，数据没有遭到损坏。]
测试关键和优先级：

需考虑特殊事项：
[测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。
进程应该以手工方法调用。
应使用小型或最小数据库（统计数量有限）来使全部没有法接收事件含有更大可视度。]

6.2接口测试
测试目标
确保接口调用正确性

测试范围：
全部软件、硬件接口，统计输入输出数据

技术：

开始标准：

完成标准：

测试关键和优先级：

需考虑特殊事项：
接口限制条件

6.3集成测试
[集成测试―关键目标检测系统是否达成需求对业务步骤及数据流处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理标准及要求。此阶段测试基于功效完成测试。]
测试目标
检测需求中业务步骤，数据流正确性

测试范围：
需求中明确业务步骤，或组合不一样功效模块而形成一个大功效。
技术：
[利用有效和无效数据来实施各个用例、用例流或功效，以核实以下内容：
在使用有效数据时得到预期结果。
在使用无效数据时显示对应错误消息或警告消息。
各业务规则全部得到了正确应用。]

开始标准：
在完成某个集成测试时必需达成标准

完成标准：
[所计划测试已全部实施。
所发觉缺点已全部处理。]

测试关键和优先级：
测试关键指在测试过程中需着重测试地方，优先级能够依据需求及严重来定

需考虑特殊事项：
[确定或说明那些将对功效测试实施和实施造成影响事项或原因（内部或外部）]

6.4功效测试
[对测试对象功效测试应侧重于全部可直接追踪到用例或业务功效和业务规则测试需求。这种测试目标是核实数据接收、处理和检索是否正确，和业务规则实施是否合适。这类测试基于黑盒技术，该技术经过图形用户界面（GUI）和应用程序进行交互，并对交互输出或结果进行分析，以此来核实应用程序及其内部进程。以下为多种应用程序列出了推荐使用测试概要：]

测试目标
[确保测试功效正常，其中包含导航，数据输入，处理和检索等功效。]

测试范围：

技术：
[利用有效和无效数据来实施各个用例、用例流或功效，以核实以下内容：
在使用有效数据时得到预期结果。
在使用无效数据时显示对应错误消息或警告消息。
各业务规则全部得到了正确应用。]

开始标准：

完成标准：

测试关键和优先级：

需考虑特殊事项：
[确定或说明那些将对功效测试实施和实施造成影响事项或原因（内部或外部）]

6.5用户界面测试
[用户界面（UI）测试用于核实用户和软件之间交互。UI测试目标是确保用户界面会经过测试对象功效来为用户提供对应访问或浏览功效。另外，UI测试还可确保UI中对象根据预期方法运行，并符合企业或行业标准。]

测试目标
[核实以下内容：
经过测试进行浏览可正确反应业务功效和需求，这种浏览包含窗口和窗口之间、字段和字段之间浏览，和多种访问方法（Tab键、鼠标移动、和快捷键）使用
窗口对象和特征（比如，菜单、大小、位置、状态和中心）全部符合标准。]

测试范围：

技术：
[为每个窗口创建或修改测试，以核实各个应用程序窗口和对象全部可正确地进行浏览，并处于正常对象状态。]

开始标准：

完成标准：
[成功地核实出各个窗口全部和基准版本保持一致，或符合可接收标准]

测试关键和优先级：

需考虑特殊事项：
[并不是全部定制或第三方对象特征全部可访问。]

6.6性能评测
[性能评测是一个性能测试，它对响应时间、事务处理速率和其它和时间相关需求进行评测和评定。性能评测目标是核实性能需求是否全部已满足。实施和实施性能评测目标是将测试对象性能行为看成条件（比如工作量或硬件配置）一个函数来进行评测和微调。
注：以下所说事务是指“逻辑业务事务”。这种事务被定义为将由系统某个Actor经过使用测试对象来实施特定用例，添加或修改给定协议。]

测试目标
[核实所指定事务或业务功效在以下情况下性能行为：
正常预期工作量
预期最繁重工作量]

测试范围：

技术：
[使用为功效或业务周期测试制订测试过程。
经过修改数据文件来增加事务数量，或经过修改脚原来增加每项事务迭代数量。
脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个用户机（虚拟或实际用户机，请参见下面“需要考虑特殊事项”）上反复。]

开始标准：

完成标准：
[单个事务或单个用户：在每个事务所预期时间范围内成功地完成测试脚本，没有发生任何故障。]
[多个事务或多个用户：在可接收时间范围内成功地完成测试脚本，没有发生任何故障。]

测试关键和优先级：

需考虑特殊事项：
[综合性能测试还包含在服务器上添加后台工作量。
可采取多个方法来实施此操作，其中包含：
直接将“事务强行分配到”服务器上，这通常以“结构化语言”（SQL）调用形式来实现。
经过创建“虚拟”用户负载来模拟很多个（通常为数百个）用户机。此负载可经过“远程终端仿真（Remote Terminal Emulation）工具来实现。此技术还可用于在网络中加载“流量”。
使用多台实际用户机（每台用户机全部运行测试脚本）在系统上添加负载。
性能测试应该在专用计算机上或在专用机时内实施，方便实现完全控制和正确评测。
性能测试所用数据库应该是实际大小或相同缩放百分比数据库。]

6.7负载测试
[负载测试是一个性能测试。在这种测试中，将使测试对象负担不一样工作量，以评测和评定测试对象在不一样工作量条件下性能行为，和连续正常运行能力。负载测试目标是确定并确保系统在超出最大预期工作量情况下仍能正常运行。另外，负载测试还要评定性能特征，比如，响应时间、事务处理速率和其它和时间相关方面。]
[注：以下所说事务是指“逻辑业务事务”。这各事务被定义为将由系统某个最终用户经过使用应用程序来实施特定功效，比如，添加或修改给定协议。]

测试目标
[核实所指定事务或商业理由在不一样工作量条件下性能行为时间。]

测试范围：

技术：
[使用为功效或业务周期测试制订测试。
经过修改数据文件来增加事务数量，或经过修改脚原来增加每项事务发生次数。]

开始标准：

完成标准：
[多个事务或多个用户：在可接收时间范围内成功地完成测试，没有发生任何故障。]

测试关键和优先级：

需考虑特殊事项：
[负载测试应该在专用计算机上或在专用机时内实施，方便实现完全控制和正确评测。
负载测试所用数据库应该是实际大小或相同缩放百分比数据库。]

6.8强度测试
[强度测试是一个性能测试，实施和实施这类测试目标是找出因资源不足或资源争用而造成错误。假如内存或磁盘空间不足，测试对象就可能会表现出部分在正常条件下并不显著缺点。而其它缺点则可能因为争用共享资源（如数据库锁或网络带宽）而造成。强度测试还可用于确定测试对象能够处理最大工作量。]
[注：以下提到事务全部是指逻辑业务事务。]
测试目标
[核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：
服务器上几乎没有或根本没有可用内存（RAM和DASD）
连接或模拟了最大实际（实际许可）数量用户机
多个用户对相同数据或帐户实施相同事务
最繁重事务量或最差事务组合（请参见上面“性能测试”）。
注：强度测试目标可表述为确定和统计那些使系统无法继续正常运行情况或条件。
用户机强度测试在“配置测试”第3.1.11节中进行了说明。]

测试范围：

技术：
[使用为性能评测或负载测试制订测试。
要对有限资源进行测试，就应该在一台计算机上运行测试，而且应该降低或限制服务器上RAM和DASD。
对于其它强度测试，应该使用多台用户机来运行相同测试或互补测试，以产生最繁重事务量或最差事务组合。]

开始标准：

完成标准：
[所计划测试已全部实施，而且在达成或超出指定系统限制时没有出现任何软件故障，或造成系统出现故障条件并不在指定条件范围之内。]

测试关键和优先级：

需考虑特殊事项：
[假如要增加网络工作强度，可能会需要使用网络工具来给网络加载消息或信息包。
应该临时降低用于系统DASD，以限制数据库可用空间增加。
使多个用户机对相同统计或数据帐户同时进行访问达成同时。]

6.9容量测试
[容量测试使测试对象处理大量数据，以确定是否达成了将使软件发生故障极限。容量测试还将确定测试对象在给定时间内能够连续处理最大负载或工作量。比如，假如测试对象正在为生成一份报表而处理一组数据库统计，那么容量测试就会使用一个大型测试数据库。检验该软件是否正常运行并生成了正确报表。]

测试目标
[核实测试对象在以下高容量条件下能否正常运行：
连接或模拟了最大（实际或实际许可）数量用户机，全部用户机在长时间内实施相同、且情况（性能）最坏业务功效。
已达成最大数据库大小（实际或按百分比缩放），而且同时实施多个查询或报表事务。]

测试范围：

技术：
[使用为性能评测或负载测试制订测试。
应该使用多台用户机来运行相同测试或互补测试，方便在长时间内产生最繁重事务量或最差事务组合（请参见上面“强度测试”）
创建最大数据库大小（实际、按百分比缩放、或填充了代表性数据数据库），并使用多台用户机在长时间内同时运行查询和报表事务。]

开始标准：

完成标准：
[所计划测试已全部实施，而且达成或超出指定系统限制时没有出现任何软件故障。]

测试关键和优先级：

需考虑特殊事项：
[对于上述高容量条件，哪个时间段是能够接收时间？]

6.10安全性和访问控制测试
[安全性和访问控制测试侧重于安全性两个关键方面：
应用程序等级安全性，包含对数据或业务功效访问。
系统等级安全性，包含对系统登录或远程访问。
应用程序等级安全性可确保：在预期安全性情况下，Actor只能访问特定功效或用例，或只能访问有限数据。比如，可能会许可全部些人输入数据，创建新帐户，但只有管理员才能删除这些数据或帐户。假如含有数据等级安全性，测试就可确保“用户类型一”能够看到全部用户消息（包含财务数据），而“用户二”看见同一用户统计数据。
系统等级安全性可确保只有含有系统访问权限用户才能访问应用程序，而且只能经过对应网关来访问。]
测试目标
应用程序等级安全性：[核实Actor只能访问其所属用户类型已被授权访问那些功效或数据。]

系统等级安全性：[核实只有含有系统和应用程序访问权限Actor才能访问系统和应用程序。]

测试范围：

技术：
应用程序等级安全性：[确定并列出各用户类型及其被授权访问功效或数据。]
[为各用户类型创建测试，并经过创建各用户类型所特有事务来核实其权限。]
修改用户类型并为相同用户重新运行测试。对于每种用户类型，确保正确地提供或拒绝了这些附加功效或数据。

系统等级访问：[请参见以下“需考虑特殊事项”。]
开始标准：

完成标准：
[多种已知Actor类型全部可访问对应功效或数据，而且全部事务全部根据预期方法运行，并在先前应用程序功效测试中运行了全部事务。]

测试关键和优先级：

需考虑特殊事项：
[必需和对应网络或系统管理员一直对系统访问权进行检验和讨论。因为此测试可能是网络管理可系统管理职能，可能会不需要实施此测试。]

6.11故障转移和恢复测试
[故障转移和恢复测试可可确保测试对象能成功完成转移，并能从造成意外数据损失或数据完整性破坏多种硬件、软件可网络故障中恢复。
故障转移测试可确保：对于必需连续运行系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障系统，以避免丢失任何数据或事务。
恢复测试是一个对抗性测试过程。在这种测试中，将把应用程序或系统置于极端条件下（或是模拟极端条件下），以产生故障（比如设备输入/输出（I/O）故障或无效数据库指针和关键字）。然后调用恢复进程并监测和检验应用程序和系统，核实应用程序或系统和数据已得到了正确恢复。]

测试目标
[确保恢复进程（手工或自动）将数据库、应用程序和系统正确地恢复到预期已知状态。
测试中将包含以下多种情况：
用户机断电
服务器断电
经过网络服务器产生通信中止
DASD和/或DASD控制器被中止、断电或和DASD和/或DASD控制器通信中止
周期未完成（数据过滤进程被中止，数据同时进程被中止）。
数据库指针或关键字无效
数据库中数据元素无效或遭到破坏]

测试范围：

技术：
[应该使用为功效和业务周期测试创建测试来创建一系列事务。一旦达成预期测试起点，就应该分别实施或模拟以下操作：
² 用户机断电：关闭PC机电源。
² 服务器断电：模拟或开启服务器断电过程。
² 经过网络服务器产生中止：模拟或开启网络通信中止（实际断开通信线路连接或关闭网络服务器或路由器电源）。
² DASD和DASD控制器被中止、断电或和DASD和DASD控制器通信中止：模拟和一个或多个DASD控制器或设备通信，或实际取消这种通信。
² 一旦实现了上述情况（或模拟情况），就应该实施其它事务。而且一旦达成第二个测试点状态，就应调用恢复过程。
² 在测试不完整周期时，所使用技术和上述技术相同，只不过应异常终止或提前终止数据库进程本身。
² 对以下情况测试需要达成一个已知数据库状态。当破坏若干个数据库字段、指针和关键字时，应该以手工方法在数据库中（经过数据库工具）直接进行。其它事务应该经过使用“应用程序功效测试”和“业务周期测试”中测试来实施，而且应实施完整周期。]

开始标准：

完成标准：
[在全部上述情况中，应用程序、数据库和系统应该在恢复过程完成时立即返回到一个已知预期状态。此状态包含仅限于已知损坏字段、指针或关键字范围内数据损坏，和表明进程或事务因中止面未被完成报表。]

测试关键和优先级：

需考虑特殊事项：
² [恢复测试会给其它操作带来很多麻烦。断开缆线连接方法（模拟断电或通信中止）可能并不可取或不可行。所以，可能会需要采取其它方法，比如诊疗性软件工具。
² 需要系统（或计算机操作）、数据库和网络组中资源。
² 这些测试应该在工作时间之外或在一台独立计算机上运行。]

6.12配置测试
[配置测试核实测试对象在不一样软件和硬件配置中运行情况。在大多数生产环境中，用户机工作站、网络连接和数据库服务器具体硬件规格会有所不一样。用户机工作站可能会安装不一样软件　比如，应用程序、驱动程序等　而且在任何时候，全部可能运行很多不一样软件组合，从而占用不一样资源。]

测试目标
[核实测试可在所需硬件和软件配置中正常运行。]
测试范围：

技术：
² [使用功效测试脚本。
² 在测试过程中或在测试开始之前，打开多种和非测试对象相关软件（比如Microsoft应用程序：Excel和Word），然后将其关闭。
² 实施所选事务，以模拟Actor和测试对象软件和非测试对象软件之间交互。
² 反复上述步骤，尽可能降低用户机工作站上常规可用内存。]
开始标准：

完成标准：
[对于测试对象软件和非测试对象软件多种组合，全部事务全部成功完成，没有出现任何故障。]

测试关键和优先级：

需考虑特殊事项：
² [需要、能够使用并能够经过桌面访问哪种非测试对象软件？
² 通常使用是哪些应用程序？
² 应用程序正在运行什么数据？比如，在Excel中打开大型电子表格，或是在Word中打开100页文档。
² 作为此测试一部分，应将整修系统、Netware、网络服务器、数据库等全部统计下来。]

6.13安装测试
[安装测试有两个目标。第一个目标是确保该软件在正常情况和异常情况不一样条件下　比如，进行首次安装、升级、完整或自定义安装　全部能进行安装。异常情况包含磁盘空间不足、缺乏目录创建权限等。第二个目标是核实软件在安装后可立即正常运行。这通常是指运行大量为功效测试制订测试。]
测试目标
核实在以下情况下，测试对象可正确地安装到多种所需硬件配置中：
² 首次安装。以前从未安装过＜项目名称＞新计算机
² 更新。以前安装过相同版本＜项目名称＞计算机
² 更新。以前安装过＜Project Name>较早版本计算机

测试范围：

技术：
² [手工开发脚本或开发自动脚本，以验证目标计算机情况　首次安装＜项目名称＞从未安装过；＜项目名称＞安装过相同或较早版本。
² 开启或实施安装。
² 使用预先确定功效测试脚本子集来运行事务。]

开始标准：

完成标准：
＜项目名称＞事务成功实施，没有出现任何故障。

测试关键和优先级：

需考虑特殊事项：
[应该选择＜项目名称＞哪些事务才能正确地测试出＜项目名称＞应用程序已经成功安装，而且没有遗漏关键软件构件？。]

7.问题严重度描述
问题严重度
描述
响应时间
高
比如使系统瓦解
程序员在多长时间内更正此问题

中

低

8.附录：项目任务
以下是部分和测试相关任务：
² 　　制订测试计划
n 确定测试需求
n 评定风险
n 制订测试策略
n 确定测试资源
n 创建时间表
n 生成测试计划
² 设计测试
n 准备工作量分析文档
n 确定并说明测试用例
n 确定测试过程，并建立测试过程结构
² 复审和评定测试覆盖
² 实施测试
n 统计或经过编程创建测试脚本
n 确定设计和实施模型中测试专用功效
n 建立外部数据集
² 实施测试
² 实施测试过程
² 评定测试实施情况
² 恢复暂停测试
² 核实结果
² 调查意外结果
² 统计缺点
² 对测试进行评定
² 评定测试用例覆盖
² 评定代码覆盖
² 分析缺点
² 确定是否达成了测试完成标准和成功标准