测试计划模板(标准版).doc_第1页
测试计划模板(标准版).doc_第2页
测试计划模板(标准版).doc_第3页
测试计划模板(标准版).doc_第4页
测试计划模板(标准版).doc_第5页
已阅读5页,还剩19页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

文档编号:CIECC-EP-TP-0I2 项目名称测试计划(标准版)项目名称测试计划(标准版) V1.0(版本号) 拟 制 人_ 审 核 人_ 批 准 人_ 2010 年 9 月 9 日 中国国际电子商务中心中国国际电子商务中心 China International Electronic Commerce Center 测试计划(标准版) 1 / 24 变更历史记录变更历史记录 日期日期版本版本说明说明作者作者审核审核批准批准 2010-09-091.0 首次建立项目测试计划(标准版)模 板 文建东赵明秀 2013-11-041.1 对部分文字及格式进行微调丁晓蓓赵明秀 测试计划(标准版) 2 / 24 目目 录录 项目名称测试计划(标准版)项目名称测试计划(标准版) 0 V1.0(版本号版本号).0 2010 年年 9 月月 9 日日0 第第 1 章章 引言引言.4 1.1 目的4 1.2 名词解释4 1.3 测试摘要4 1.3.1 重点事项.4 1.3.2 测试前约定.5 1.3.3 风险评估.5 1.3.4 时间进度.5 1.3.5 测试目标.5 第第 2 章章 项目背景项目背景 .5 2.1 测试范围5 2.2 联系方式6 2.3 测试文档6 2.3.1 测试参考文档.7 2.3.2 测试输出文档.7 2.4 测试需求7 2.4.1 功能测试.7 2.4.2 用户界面测试.8 2.4.3 性能测试.8 2.4.4 配置测试.8 2.4.5 安全性测试.8 2.4.6 数据和数据库完整性测试.9 2.4.7 故障转移和恢复测试.9 2.4.8 业务周期测试.9 2.4.9 可靠性测试.9 2.4.10 病毒测试.9 2.4.11 文档测试.9 第第 3 章章 质量目标质量目标 .9 3.1 产品质量目标9 3.2 测试质量目标10 第第 4 章章 资源需求资源需求10 4.1 培训资料10 4.2 测试环境10 4.3 测试工具11 4.4 人力资源12 第第 5 章章 测试策略测试策略13 5.1 单元测试13 5.2 集成测试13 测试计划(标准版) 3 / 24 5.3 系统测试13 5.4 测试类型14 5.4.1 功能测试.14 5.4.2 用户界面测试.15 5.4.3 性能测试.16 5.4.4 配置测试.19 5.4.5 安全性测试.20 5.4.6 数据和数据库完整性测试.20 5.4.7 故障转移和恢复测试.21 5.4.8 业务周期测试.22 5.4.9 可靠性测试.22 5.4.10 病毒测试.22 5.4.11 文档测试.23 第第 6 章章 项目里程碑项目里程碑23 第第 7 章章 附录附录 :项目任务:项目任务 23 测试计划(标准版) 4 / 24 第第 1 章章 引言引言 1.1 目的目的 简述本计划的目的,旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。 测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足 够的信息使测试人员明白项目需要做什么是如何运作的。另外,清晰的文档结构能使任何 一个读者在浏览计划的前面几页后,就能对项目有一个大概的认识。测试计划只是测试的 一个框架,很多细节需要跟开发人员或其他人员沟通,因此计划不包括测试用例的细节和 系统功能的详细信息。在计划目的中需要指明读者对象。 1.2 名词解释名词解释 列出本计划中使用的专用术语及其定义 列出本计划中使用的全部缩略语全称及其定义 表表 1 1 名词解释表名词解释表 缩写词或术语缩写词或术语中文解释中文解释 1.3 测试摘要测试摘要 这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信 息传递给那些可能不会通读整个测试计划文档的人员(比如经理或开发项目的负责人)。 测试计划(标准版) 5 / 24 1.3.1 重点事项重点事项 列出测试的重点事项。可以将问题按重要程度和优先级罗列出来,然后在后面的章节 中再对这些问题进行详细说明,这样就能让对这些问题有重要影响的人员知道问题的所在。 1.3.2 测试前约定测试前约定 列出测试前开发和测试之间的约束。 1.3.3 风险评估风险评估 列出可能会影响测试设计、开发或实施的所有风险或意外事件。 列出可能会影响测试设计、开发或实施的所有约束 1.3.4 时间进度时间进度 简要说明测试开始时间与发布时间。 1.3.5 测试目标测试目标 简要说明测试发布的质量目标。 例: 测试计划中所有测试方法和模块已经执行通过 所有的测试案例已经执行过 所有的重要等级为严重/重要的Bug已经解决并由测试验证 测试计划(标准版) 6 / 24 第第 2 章章 项目背景项目背景 2.1 测试范围测试范围 说明本计划涵盖的测试范围,比如功能测试、集成测试、系统测试、验收测试等。通 常说明什么是要测试的,什么是不要测试的是非常重要的。明确规定这些问题后,测试人 员对该做什么有一个清晰的认识。 (1)简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。 (2)如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施,则 列出所有这些假设。 (3)列出可能会影响测试设计、开发或实施的所有风险或意外事件。 (4)列出可能会影响测试设计、开发或实施的所有约束。 提示和技巧: 需要测试和特别注意测试那些部分? 测试是否专么针对与某些问题的解决? 哪些部分不需要测试,为什么? 哪些部分需要推迟测试,为什么? 是否要验证每个模块的稳定性? 测试的优先级和先后顺序 2.2 测试来源(谁提交的测试的测试申请、服务器放在什么测试来源(谁提交的测试的测试申请、服务器放在什么 地方等信息)地方等信息) 2.3 联系方式联系方式 列出项目参与人员的职务、姓名、E-mail 和电话。 表表 2 2 联系方式表联系方式表 测试计划(标准版) 7 / 24 职务职务姓名姓名E-Mail电话电话 开发工程师 CVS Builder 总协调人 开发经理 测试负责人 测试人员 2.4 测试文档测试文档 列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置,测试完成后应 产生的文档。 2.4.1 测试参考文档测试参考文档 列出本计划各处参考的经过核准的全部文档和主要文献。 表表 3 3 参考文档表参考文档表 文档名称文档名称文档版本号文档版本号/标识标识/日期日期 2.4.2 测试输出文档测试输出文档 表表 4 4 测试输出文档表测试输出文档表 文档说明文档说明作者作者文档位置文档位置 测试计划 测试用例 测试计划(标准版) 8 / 24 性能测试计划 性能测试报告 测试报告 2.5 测试需求测试需求 列出需要测试的内容。 2.5.1 功能测试功能测试 注:如开发部门提供需求文档,则测试需求引用此文档;如开发部门不提供需求文档 或需求文档不完整,则测试需求中列出高级别测试需求。 举例说明: 核实是否可以输入和检索订户信息。 核实是否可以插入和显示内容和类别。 核实是否可以输入和显示广告商简档和账户信息。 核实是否可以跟踪特定订户的使用信息。 2.5.2 用户界面测试用户界面测试 注:根据界面规范列出用户界面测试的要点。 举例说明: 核实必录字段是否为红色。 核实系统中所有字体大小是否统一。 2.5.3 性能测试性能测试 注:如开发部门提供需求文档,则测试需求引用此文档;如开发部门不提供需求文档 或需求文档不完整,则测试需求中列出高级别测试需求。 举例说明: 单用户操作数据录入中保存一条记录时间不超过 5 秒。 测试计划(标准版) 9 / 24 2.5.4 配置测试配置测试 注:在此节列出所要进行配置测试的各种环境配置与测试内容。 举例说明: 测试环境一:IE6.0。 测试内容:安装卸载测试、功能测试(详细说明是所有功能还是个别功能)。 2.5.5 安全性测试安全性测试 说明是否进行 SQL 脚本注入、跨脚本注入和.BAK 文档检查测试 2.5.6 数据和数据库完整性测试数据和数据库完整性测试 2.5.7 故障转移和恢复测试故障转移和恢复测试 2.5.8 业务周期测试业务周期测试 2.5.9 可靠性测试可靠性测试 2.5.10 病毒测试病毒测试 2.5.11 文档测试文档测试 注:在此列出要进行测试的文档 第第 3 章章 质量目标质量目标 描述本阶段测试目标和要求。质量目标应该包括产品的质量目标和测试小组的质量目 标。 质量不仅是衡量系统的功能或性能是否正常。对系统来说,在开发过程中尽早建立全 面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具,应该在系 测试计划(标准版) 10 / 24 统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例 如,系统是否能够正式发行?在代码完成后,应该修复那些缺陷?在系统完成后那种类型 的测试是最合适的? 3.1 产品质量目标产品质量目标 可以是产品的质量达到什么样的目标,产品的流程联通性达到什么样的要求。 表表 5 5 产品质量目标表产品质量目标表 测试质量目标测试质量目标确认者确认者 测试已实现的产品是否达到设计的要求,包括:各个功能点是否 以实现,业务流程是否正确 产品规定的操作和运行稳定 3.2 测试质量目标测试质量目标 评价本项目的测试质量目标可以有: 表表 6 6 测试质量目标表测试质量目标表 测试质量目标测试质量目标确认者确认者 所设计的测试用例覆盖率应达到软件需求的 100% 所有的测试案例已经执行过 所有的测试脚本已经执行通过 所有的严重、重要 Bug 已经解决并由测试验证 每一部分的测试已经被 Test Lead 确认完成 发现错误等级为严重、重要、一般的 Bug 的速率正在下降并接近 0 在最后的三天内没有发现错误等级为严重、重要的 Bug 量测统计数不能超 10%=(问题总数-原问题总数)/问题总数 量测统计,应该无严重 BUG,重要问题不能超 5%=(总重要问题数 -原重要问题数)/问题总数 测试计划(标准版) 11 / 24 第第 4 章章 资源需求资源需求 4.1 培训资料培训资料 表表 7 7 培训资料表培训资料表 培训需求培训需求培训内容培训内容培训人员培训人员开始时间开始时间完成时间完成时间 业务流程 安装配置 工具使用 4.2 测试环境测试环境 按下表格记录测试。 表表 8 8 测试环境表测试环境表 服务器端服务器端 序号序号 机型机型网速网速IPIP 地址地址 cpucpu 内存内存操作操作 系统系统 软件软件预计空预计空 间间 1 客服端客服端 序号序号 机型机型/ / 机器名机器名 网速网速IPIP 地址地址 cpucpu 内存内存操作操作 系统系统 软件软件预计空预计空 间间 测试计划(标准版) 12 / 24 4.3 测试工具测试工具 此项目将使用以下工具: 注:可适当地删除或添加工具项。 表表 9 9 工具使用情况表工具使用情况表 工具工具产商产商/ /自产自产版本版本 测试管理 缺陷跟踪 用于功能性测试的 ASQ 工具 用于性能测试的 ASQ 工具 配置管理 DBMS 工具 4.4 人力资源人力资源 下表列出了在此项目的人员配备方面所作的各种假定。 注:可适当地删除或添加角色项。 表表 1010 角色分派表角色分派表 人力资源人力资源 角色角色所推荐的最少资源所推荐的最少资源 (所分配的人员)(所分配的人员) 具体职责或注释具体职责或注释 测试设计员 如有多个人员,则详细说明具体的工作 内容。如设计测试用例,要说明具体设 计哪些模块的测试用例(考虑对不同系 统的公共模块避免重复进行测试设计)。 测试计划(标准版) 13 / 24 职责: 生成测试计划 生成测试用例 评估测试 测试员 执行测试 职责: 按照测试用例执行测试 提交错误报告 第第 5 章章 测试策略测试策略 测试策略提供了对测试对象进行测试的推荐方法。 对于每种测试,都应提供测试说明,并解释其实施和执行的原因。 如果将不实施和执行某种测试,则应该用一句话加以说明,并陈述这样做的理由。例 如, “将不实施和执行该测试。该测试不合适” 。 制定测试策略时所考虑的主要事项有:将要使用的技术以及判断测试何时完成的标准。 下面列出了在进行每项测试时需考虑的事项,除此之外,测试还只应在安全的环境中 使用已知的、有控制的数据库来执行。 5.1 单元测试单元测试 单元测试由研发人员进行单元测试代码编写、执行。 测试计划(标准版) 14 / 24 5.2 集成测试集成测试 集成测试的目的是确保程序满足概要设计说明书的要求。它所测试的内容包括模块的 功能,模块间的接口以及集成后的功能,并且对以前集成的 build 进行增量式测试。 集成测试策略:描写集成测试策略。 例:主要在系统测试的第一轮中进行。开发完一个模块,就测一个模块,确保集成测试与 开发进度相吻合。集成测试以功能测试为主,同时兼顾用户界面测试,易用性测试,数据和数 据库完整性测试及性能测试。 5.3 系统测试系统测试 系统测试是通过与系统的需求规格作比较,发现软件与系统需求规格不相符合或与之 矛盾的地方。它将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机 硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来,在模拟实际运行(使 用)环境下,对系统进行的测试。 系统测试主要进行业务流程方面的测试,同时进行回归测试。 系统测试策略:描写系统测试策略。 例 本次一共分三轮测试。使用交叉测试法、因果关系法、等价划分法和约束法。 第一轮测试 开发完一个模块,就测一个模块。 以功能测试为主,同时兼顾用户界面测试,易用性测试,数据和数据库完整 性测试及性能测试。尽可能将存在的问题暴露出来。 确保业务流程能走通,尽可能将需求中的功能点核实。 所设计的测试用例都执行完。并补充相应的测试用例。 第二轮测试 保证系统正常功能正确的情况下对边界和一些特殊的情况。 保证系统界面符合界面规范和友好性符合用户操作习惯。 保证多用户并发操作时模块功能实现正确。 系统中所有功能按正常流程都能正确实现。 在规定的测试时间段内按要求完成测试。 经过测试保证系统符合项目规范;网页可读性;网页下载速度;系统便用性;浏览器兼容 性等多个方面。 测试计划(标准版) 15 / 24 第三轮测试 达到第3章质量目标 5.4 测试类型测试类型 可以根据产品或项目的实际情况对下方的测试类型进行删减 5.4.1 功能测试功能测试 对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试 需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是 否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互, 并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。以下为各种应用程 序列出了推荐使用的测试概要: 表表 1111 功能测试策略表功能测试策略表 测试目标: 确保测试对象的功能正常,满足功能需求 技术: 利用有效的和无效的数据来执行各个用例、用例流或功能,以 核实以下内容: 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。 完成标准: 所设计的功能测试用例已全部执行。 所发现的缺陷除推迟解决的问题外已全部解决,推迟的问题需 经评审通过。 需考虑的特殊事项: 确定或说明那些将对功能测试的实施和执行造成影响的事项或 测试计划(标准版) 16 / 24 因素(内部的或外部的) 5.4.2 用户界面测试用户界面测试 用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面 会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。 表表 1212 用户界面测试策略表用户界面测试策略表 测试目标:核实以下内容: 通过测试对象进行的浏览可正确反映业务的功能和需求,这种 浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种 访问方法(Tab 健、鼠标移动、和快捷键)的使用 窗口的对象和特征(例如,菜单、大小、位置、状态和中心) 都符合标准。 符合界面规范。 技术:为每个窗口创建或修改测试,以核实各个应用程序窗口和对象 都可正确地进行浏览,并处于正常的对象状态。 完成标准:成功地核实出各个窗口都与基准版本保持一致,或符合可接受 标准。符合界面规范。 所设计的界面测试用例已全部执行。 所发现的缺陷除推迟解决的问题外已全部解决,推迟的问题需 经评审通过。 测试计划(标准版) 17 / 24 需考虑的特殊事项:并不是所有定制或第三方对象的特征都可访问。 5.4.3 性能测试性能测试 对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目 标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当 作条件(例如工作量或硬件配置)的一种函数来进行评测和微调。 注:以下所说的事务是指“逻辑业务事务” 。这种事务被定义为将由系统的某个 Actor 通过使用测试 对象来执行的特定用例,例如,添加或修改给定的合同。 表表 1313 性能测试策略表性能测试策略表 测试目标: 核实所指定的事务或业务功能在以下情况下的性能 行为: 正常的预期工作量 预期的最繁重工作量 技术: 使用为功能或业务周期测试制定的测试过程。 通过修改数据文件来增加事务数量,或通过修改脚本来增加每 项事务的迭代数量。 脚本应该在一台计算机上运行(最好是以单个用户、单个事务 为基准),并在多个客户机(虚拟的或实际的客户机,请参见 下面的“需要考虑的特殊事项”)上重复。 完成标准: 单个事务或单个用户:在每个事务所预期或要求的时间范围内 成功地完成测试脚本,没有发生任何故障。 多个事务或多个用户:在可接受的时间范围内成功地完成测试 脚本,没有发生任何故障。 测试计划(标准版) 18 / 24 所设计的性能测试用例已全部执行。 所发现的缺陷除推迟解决的问题外已全部解决,推迟的问题需 经评审通过。 需考虑的特殊事项: 综合的性能测试还包括在服务器上添加后台工作量。 可采用多种方法来执行此操作,其中包括: 直接将“事务强行分配到”服务器上,这通常以“结构化查询语言” (SQL) 调用的形式来实现。 通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户 机。此负载可通过“远程终端仿真”(Remote Terminal Emulation) 工具来实现。此技术还可用于在网络中加载“流量”。 使用多台实际客户机(每台客户机都运行测试脚本)在系统上 添加负载。 性能测试应该在专用的计算机上或在专用的机时内执行,以便 实现完全的控制和精确的评测。 性能测试所用的数据库应该是实际大小或相同缩放比例的数据 库。 5.4.4 配置测试配置测试 配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中, 客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能 会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的 测试计划(标准版) 19 / 24 软件组合,从而占用不同的资源。 表表 1414 配置测试策略表配置测试策略表 测试目标: 核实测试对象可在所需的硬件和软件配置中正常运行。 技术: 使用功能测试脚本。 测试必须覆盖系统支持的操作系统和浏览器。 测试IE的COOKIES与历史记录全部清除与不清除两种 情况下,浏览的正确性。 测试IE的时区设置及时间格式设置对浏览操作的影响。 完成标准: 对于测试对象软件和非测试对象软件的各种组合,所有 事务都成功完成,没有出现任何故障。 所设计的配置测试用例已全部执行。 所发现的缺陷除推迟解决的问题外已全部解决,推迟的 问题需经评审通过。 需考虑的特殊事项: 需要、可以使用并可以通过桌面访问哪种非测试对象软 件? 通常使用的是哪些应用程序? 应用程序正在运行什么数据?例如,在 Excel 中打开的 大型电子表格,或是在 Word 中打开的 100 页文档。 作为此测试的一部分,应将整个系统、Netware、网络服 务器、数据库等都记录下来。 测试计划(标准版) 20 / 24 5.4.5 安全性测试安全性测试 说明是否进行 SQL 脚本注入、跨脚本注入和.BAK 文档检查测试。 表表 1515 安全性测试策略表安全性测试策略表 测试目标: 技术: 完成标准: 需考虑的特殊事项: 5.4.6 数据和数据库完整性测试数据和数据库完整性测试 在 中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些 子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS), 还需要进行深入的研究,以确定可以支持以下测试的工具和技术。 表表 1616 数据和数据库完整性测试策略表数据和数据库完整性测试策略表 测试目标: 确保数据库访问方法和进程正常运行,数据不会遭到损坏。 技术: 调用各个数据库访问方法和进程,并在其中填充有效的和无效 的数据(或对数据的请求)。 检查数据库,确保数据已按预期的方式填充,并且所有的数据 库事件都已正常发生;或者检查所返回的数据,确保为正当的 理由检索到了正确的数据 完成标准: 所有的数据库访问方法和进程都按照设计的方式运行,数据没 有遭到损坏。 需考虑的特殊事项: 测试可能需要 DBMS 开发环境或驱动程序在数据库中直接输 入或修改数据。 测试计划(标准版) 21 / 24 进程应该以手工方式调用。 应使用小型或最小的数据库(记录的数量有限)来使所有无法 接受的事件具有更大的可视度。 5.4.7 故障转移和恢复测试故障转移和恢复测试 故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论