测试计划模板68646.docVIP

卷号 卷内编号 密级 测 试 计 划 项目名称：_部门级文档管理系统 项目编号： *** 编写人员： ____ 编写日期： 2004-5-10 _ 审批人员： 审批日期： 历史修改记录 版本号 修改人/日期 摘要 审核人/日期 简介 目的 项目名称 的这一“测试计划”文档有助于实现以下目标： ? [确定现有项目的信息和应测试的软件构件。 ? 列出推荐的测试需求（高层次）。 ? 推荐可采用的测试策略，并对这些策略加以说明。 ? 确定所需的资源，并对测试的工作量进行估计。 ? 列出测试项目的可交付元素] 背景 [输入测试对象（组件、应用程序、系统等）及其目标的的简要说明。需要包括的信息有：主要的功能和特性、测试对象的构架以及项目的简史。本节应该只包含 3 至 5 个段落。] 范围 [描述测试的各个阶段，例如：单元测试、集成测试或系统测试，并说明本计划所针对的测试类型（如功能测试或性能测试）。简要地列出测试对象中将接受测试或将不接受测试的那些特性和功能。 如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。 列出可能会影响测试设计、开发或实施的所有风险或意外事件。 列出可能会影响测试设计、开发或实施的所有约束。] 项目标识 下表列出了制定测试计划所用的文档，并标明了文档的可用性： [注：可以视情况删除或添加项目。] 文档（版本/日期） 已创建或可用 已被接受或已经过复审 作者或来源 备注 需求规约 ( 是 ( 否 ( 是 ( 否 功能性规约 ( 是 ( 否 ( 是 ( 否 用例报告 ( 是 ( 否 ( 是 ( 否 项目计划 ( 是 ( 否 ( 是 ( 否 设计规约 ( 是 ( 否 ( 是 ( 否 原型 ( 是 ( 否 ( 是 ( 否 用户手册 ( 是 ( 否 ( 是 ( 否 业务模型或业务流程 ( 是 ( 否 ( 是 ( 否 数据模型或数据流 ( 是 ( 否 ( 是 ( 否 业务功能和业务规则 ( 是 ( 否 ( 是 ( 否 项目或业务风险评估 ( 是 ( 否 ( 是 ( 否 测试需求 下面列出了那些已被确定为测试对象的项目（用例、功能性需求和非功能性需求）。此列表说明了测试的对象。 [在此处输入一个主要测试需求的高层次列表。] 3. 测试策略 [测试策略提供了推荐用于测试对象的方法。上一节“测试需求”中说明了将要测试哪些对象，而本节则要说明如何对测试对象进行测试。 对于每种测试，都应提供测试说明，并解释其实施和执行的原因。 如果不实施和执行某种测试，则应该用一句话加以说明，并陈述这样做的理由。例如，“将不实施和执行该测试。。该测试不合适。” 制定测试策略时所考虑的主要事项有：将要使用的方法以及判断测试何时完成的标准。 下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、受控的数据库来执行。 ] 3.1 测试类型 3.1.1 数据和数据库完整性测试 [数据库和数据库进程应作为项目名称中的子系统来进行测试。 在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和方法。] 测试目标： [确保数据库访问方法和进程正常运行，数据不会遭到损坏。] 方法： ( [调用各个数据库访问方法和进程，并在其中填充有效的和无效 的数据或对数据的请求。 ( 检查数据库，确保数据已按预期的方式填充，并且所有 数据库事件都按正常方式出现；或者检查所返回的数据，确保为 正当的理由检索到了正确的数据] 完成标准： [所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。] 需考虑的特殊事项： ( [测试可能需要 DBMS 开发环境或驱动程序以便在数据库中直接 输入或修改数据。 ( 进程应该以手工方式调用。 ( 应使用小型或最小的数据库（其中的记录数很有限）来 使所有无法接受的事件具有更大的可见性，海量的数据表可能会使数据的逻辑错误很难查找。] 3.1.2 功能测试 [测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。这些测试的目标在于核实能否正确地