从满足项目预算和时间进度要求的角度看,测试计划是项目成功的一个主要因素_2.docVIP

测试计划示例 从满足项目预算和时间进度要求的角度看，测试计划是项目成功的一个主要因素。测试计划活动的输出是一份测试计划文档，其中确定了测试产品所需要的资源，确定了需要对什么进行测试、如何进行测试以及测试的结果或提交产物是什么。下面是一个测试计划文档的例子，描述了一个测试管理工具（TMT）产品的测试计划。 文档标识符：TMP-TP-10 文档版本：0.8 作者： 测试管理工具 版本1.0 测试计划 简介 这份文档的目标是详细描述对测试管理工具进行功能验证的测试过程。本文档所关注 的特征来自于需求文档：测试管理工具需求定义。需求文档的标识符是TMT-HD-10。 2、测试项 以下是本文档所关注产品的组成部分的一份清单。 要测试的发行版—这项测试工作将关注“测试管理工具1.0版”的特征功能。 缺陷修正——这是产品的第一个发行版本，所以没有以前版本中发现的缺陷而需要在这个版本中进行测试的。在这次测试工作期间发现的所有缺陷都会被修正并被确认。 发行媒质——产品的首个发行版本将可以从开发站点下载。市场部门认可的客户也可以获得产品的CD.这两种发行方式都将被测试. 最终用户文档-----假定客户端和服务器会在不同的位置，所以会有两个独立的模块，每个都有自己的安装程序。诸如‘用户指南“、”安装指南和“发行说明“等最终用户文档将分别下载，这样顾客可以了解系统需求和安装过程。安装和打包会被测试，文档的准确性会被复查。 3.准备测试的特征 以下特征将被测试，以确保测试管理工具能满足tmt需求规格说明书中制定的需求： 需求3.1.1 用户界面 需求3.1.2 导航 需求3.1.3用户认证——客户 需求3.1.4 用户认证——管理员 需求3.1.5当前项目 需求3.1.6已完成项目 需求3.1.7创建新项目 需求3.1.8修改项目 需求3.1.9删除项目 需求3.1.10创建测试用例或测试套件 需求3.1.11修改测试用例或测试套件 需求3.1.12删除测试用例或测试套件 需求3.1.13查看测试用例 需求3.1.14查看测试套件 需求3.1.15运行单个测试 需求3.1.16运行测试套件 需求3.1.17创建运行清单 需求3.1.18执行运行清单 需求3.1.19缺陷汇总 需求3.1.20测试结果一单个测试 需求3.1.21测试结果一测试套件或运行清单 需求3.1.22创建追踪矩阵 需求3.1.23备份一测试用例 需求3.1.24备份一测试套件 需求3.1.25备份测试结果 需求3.1.26恢复测试用例 需求3.1.27恢复测试套件 需求3.1.28恢复测试结果 需求3.1.29导出测试用例 需求3.1.30导出一测试套件 需求3.1.31导出一测试结果 需求3.1.32帮助 需求3.1.33多用户功能 4、不准备测试的特征 以下功能和系统配置是不准备测试的： 本次测试将不考虑关系数据库的安装和功能。我们假定数据库已安装并处于可操作的状态。我们也假定数据库表结构是准确的，包含需求规格说明书中定义的规定类型和宽度的字段。这些需求在准备和安装文档指南中有详细说明。 本次测试将不会直接测试Web服务器（Apache或IIS）。 本次测试将不会考虑大量的客户端/服务器压力测试。多用户功能将通过5个真实用户来测试，这是规定的多用户功能至少要支持的情况。 5、方法 总体测试方法包括特征测试、回归测试、产品安装测试、备份和恢复测试、GUI测试。在本节中，将对每种测试进行较为详细的描述。 5.1特征测试 在需求定义TMT-RD-10中描述的所有特征，都将在选定的客户端/服务器配置组合上进行测试。特征测试将包括功能测试和恶意测试（使用设计者所不期望的数据进行操作）。 5.2回归测试 因为这是产品的第一个版本，所以不需要验证以前版本中修正过的缺陷是否又重新出现。这个版本关注的是系统测试阶段修正的缺陷不会破坏以前能工作的功能。 我们将使用以下方法来对产品的第一个版本进行回归测试。 发现缺陷时，它们会被修正。对测试团队收到的每个软件进行构建，都会执行测试以验证那些修正过的缺陷没再重现。换言之，每个缺陷修正都会在声称修正了它的版本中进行验证。 在产品已稳定并通过测试用例的证明之后，会进行一次最后的回归测试，然后再是产品是否准备好的复查。对于这个版本来说，通过回归测试意味着通过所有的测试用例。 5.3产品安装 测试团队收到的每个软件构建版本都会按照客户所使用的安装过程进行安装。但对每个构建来说，客户端和服务器部分将只在部分平台和操作系统的组合配置上安装，这些配置组合是在需求规格说明书中定义的。我们假定在一种UNLX平台上的成功安装就代表了在所有其他UNIX平台上的成功安装，对于不同种类Windows系统来说也是如此。这种方法得到了客户的同意。 5.4备份和恢复 备份和恢复将针