测试计划模板标准版.docx

1、测试计划模板标准版文档编号：CIECC-EP-TP-0I2 项目名称测试计划（标准版）V1.0(版本号)拟 制 人_审 核 人_批 准 人_2010年9月9日中国国际电子商务中心China International Electronic Commerce Center变更历史记录日期版本说明作者审核批准2010-09-091.0首次建立项目测试计划（标准版）模板文建东赵明秀2013-11-041.1对部分文字及格式进行微调丁晓蓓赵明秀 第1章 引言1.1 目的简述本计划的目的，旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。测试计划在策略和方法的高度说明如何计划、组织和管理测试项目

2、。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。在计划目的中需要指明读者对象。1.2 名词解释列出本计划中使用的专用术语及其定义列出本计划中使用的全部缩略语全称及其定义表1 名词解释表缩写词或术语中文解释1.3 测试摘要这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。1.3

3、.1 重点事项列出测试的重点事项。可以将问题按重要程度和优先级罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。1.3.2 测试前约定列出测试前开发和测试之间的约束。1.3.3 风险评估列出可能会影响测试设计、开发或实施的所有风险或意外事件。列出可能会影响测试设计、开发或实施的所有约束1.3.4 时间进度简要说明测试开始时间与发布时间。1.3.5 测试目标简要说明测试发布的质量目标。例：测试计划中所有测试方法和模块已经执行通过所有的测试案例已经执行过所有的重要等级为严重/重要的Bug已经解决并由测试验证第2章 项目背景2.1 测试范围说明

4、本计划涵盖的测试范围，比如功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。（1）简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。（2）如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。（3）列出可能会影响测试设计、开发或实施的所有风险或意外事件。（4）列出可能会影响测试设计、开发或实施的所有约束。提示和技巧：需要测试和特别注意测试那些部分？测试是否专么针对与某些问题的解决?哪些部分不需要测试，为什么？哪些部分需要推迟测试,为什么?是否要验

5、证每个模块的稳定性？测试的优先级和先后顺序2.2 测试来源（谁提交的测试的测试申请、服务器放在什么地方等信息）2.3 联系方式列出项目参与人员的职务、姓名、E-mail 和电话。表2 联系方式表职务姓名E-Mail电话开发工程师CVS Builder总协调人开发经理测试负责人测试人员2.4 测试文档列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置，测试完成后应产生的文档。2.4.1 测试参考文档列出本计划各处参考的经过核准的全部文档和主要文献。表3 参考文档表文档名称文档版本号/标识/日期2.4.2 测试输出文档表4 测试输出文档表文档说明作者文档位置测试计划测试用例性能测试计划性

6、能测试报告测试报告2.5 测试需求列出需要测试的内容。2.5.1 功能测试注：如开发部门提供需求文档，则测试需求引用此文档；如开发部门不提供需求文档或需求文档不完整，则测试需求中列出高级别测试需求。举例说明：核实是否可以输入和检索订户信息。核实是否可以插入和显示内容和类别。核实是否可以输入和显示广告商简档和账户信息。核实是否可以跟踪特定订户的使用信息。 2.5.2 用户界面测试注：根据界面规范列出用户界面测试的要点。举例说明：核实必录字段是否为红色。核实系统中所有字体大小是否统一。2.5.3 性能测试注：如开发部门提供需求文档，则测试需求引用此文档；如开发部门不提供需求文档或需求文档不完整，则

7、测试需求中列出高级别测试需求。举例说明：单用户操作数据录入中保存一条记录时间不超过5秒。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章 质量目标描述本阶段测试目标和要求。质量目标应该包括产品的质量目

8、标和测试小组的质量目标。质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的？3.1 产品质量目标可以是产品的质量达到什么样的目标，产品的流程联通性达到什么样的要求。表5 产品质量目标表测试质量目标确认者测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确产品规定的操作和运行稳定3.2 测试质量目标

9、评价本项目的测试质量目标可以有：表6 测试质量目标表测试质量目标确认者所设计的测试用例覆盖率应达到软件需求的100%所有的测试案例已经执行过所有的测试脚本已经执行通过所有的严重、重要Bug已经解决并由测试验证每一部分的测试已经被Test Lead确认完成发现错误等级为严重、重要、一般的Bug的速率正在下降并接近0在最后的三天内没有发现错误等级为严重、重要的Bug量测统计数不能超10%=（问题总数-原问题总数）/问题总数量测统计，应该无严重BUG，重要问题不能超5%=（总重要问题数-原重要问题数）/问题总数第4章 资源需求4.1 培训资料表7 培训资料表培训需求培训内容培训人员开始时间完成时间业

10、务流程安装配置工具使用4.2 测试环境按下表格记录测试。表8 测试环境表服务器端序号机型网速IP地址cpu内存操作系统软件预计空间1客服端序号机型/机器名网速IP地址cpu内存操作系统软件预计空间4.3 测试工具此项目将使用以下工具：注：可适当地删除或添加工具项。表9 工具使用情况表工具产商/自产版本测试管理缺陷跟踪用于功能性测试的 ASQ 工具用于性能测试的 ASQ 工具配置管理DBMS 工具4.4 人力资源下表列出了在此项目的人员配备方面所作的各种假定。注：可适当地删除或添加角色项。表10 角色分派表人力资源角色所推荐的最少资源（所分配的人员）具体职责或注释测试设计员如有多个人员，则详细说

11、明具体的工作内容。如设计测试用例，要说明具体设计哪些模块的测试用例（考虑对不同系统的公共模块避免重复进行测试设计）。职责： 生成测试计划 生成测试用例 评估测试测试员执行测试职责： 按照测试用例执行测试 提交错误报告第5章 测试策略测试策略提供了对测试对象进行测试的推荐方法。对于每种测试，都应提供测试说明，并解释其实施和执行的原因。如果将不实施和执行某种测试，则应该用一句话加以说明，并陈述这样做的理由。例如，“将不实施和执行该测试。该测试不合适”。制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境

12、中使用已知的、有控制的数据库来执行。5.1 单元测试单元测试由研发人员进行单元测试代码编写、执行。5.2 集成测试集成测试的目的是确保程序满足概要设计说明书的要求。它所测试的内容包括模块的功能，模块间的接口以及集成后的功能，并且对以前集成的build进行增量式测试。集成测试策略：描写集成测试策略。例：主要在系统测试的第一轮中进行。开发完一个模块，就测一个模块，确保集成测试与开发进度相吻合。集成测试以功能测试为主，同时兼顾用户界面测试，易用性测试，数据和数据库完整性测试及性能测试。5.3 系统测试系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过确认测

13、试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在模拟实际运行（使用）环境下，对系统进行的测试。系统测试主要进行业务流程方面的测试，同时进行回归测试。系统测试策略：描写系统测试策略。例本次一共分三轮测试。使用交叉测试法、因果关系法、等价划分法和约束法。第一轮测试 开发完一个模块，就测一个模块。以功能测试为主，同时兼顾用户界面测试，易用性测试，数据和数据库完整性测试及性能测试。尽可能将存在的问题暴露出来。确保业务流程能走通，尽可能将需求中的功能点核实。所设计的测试用例都执行完。并补充相应的测试用例。第二轮测试 保证系统正常功能正确的

14、情况下对边界和一些特殊的情况。保证系统界面符合界面规范和友好性符合用户操作习惯。保证多用户并发操作时模块功能实现正确。系统中所有功能按正常流程都能正确实现。在规定的测试时间段内按要求完成测试。经过测试保证系统符合项目规范；网页可读性；网页下载速度；系统便用性；浏览器兼容性等多个方面。第三轮测试 达到第3章质量目标 5.4 测试类型 可以根据产品或项目的实际情况对下方的测试类型进行删减5.4.1 功能测试对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图

15、形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：表11 功能测试策略表测试目标：确保测试对象的功能正常，满足功能需求技术：利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。完成标准：所设计的功能测试用例已全部执行。所发现的缺陷除推迟解决的问题外已全部解决，推迟的问题需经评审通过。需考虑的特殊事项：确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的

16、）5.4.2 用户界面测试用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。 表12 用户界面测试策略表测试目标：核实以下内容：通过测试对象进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab 健、鼠标移动、和快捷键）的使用窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。符合界面规范。技术：为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可

17、正确地进行浏览，并处于正常的对象状态。完成标准：成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准。符合界面规范。所设计的界面测试用例已全部执行。所发现的缺陷除推迟解决的问题外已全部解决，推迟的问题需经评审通过。需考虑的特殊事项：并不是所有定制或第三方对象的特征都可访问。5.4.3 性能测试对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。注：以下所说的事务是指“逻辑业务事务”。这种事务被定义为将由系统的某个 Actor 通过使

18、用测试对象来执行的特定用例，例如，添加或修改给定的合同。表13 性能测试策略表测试目标：核实所指定的事务或业务功能在以下情况下的性能 行为：正常的预期工作量预期的最繁重工作量技术：使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项”）上重复。完成标准：单个事务或单个用户：在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障。多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，

19、没有发生任何故障。所设计的性能测试用例已全部执行。所发现的缺陷除推迟解决的问题外已全部解决，推迟的问题需经评审通过。需考虑的特殊事项：综合的性能测试还包括在服务器上添加后台工作量。 可采用多种方法来执行此操作，其中包括： 直接将“事务强行分配到”服务器上，这通常以“结构化查询语言”(SQL) 调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。此负载可通过“远程终端仿真”(Remote Terminal Emulation) 工具来实现。此技术还可用于在网络中加载“流量”。使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。 性能测试应该在专用的计算机上

20、或在专用的机时内执行，以便实现完全的控制和精确的评测。性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。5.4.4 配置测试配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。表14 配置测试策略表测试目标：核实测试对象可在所需的硬件和软件配置中正常运行。技术：使用功能测试脚本。测试必须覆盖系统支持的操作系统和浏览器。测试IE的COOKIES与历史记录全部清除与不清除两种情况下，

21、浏览的正确性。测试IE的时区设置及时间格式设置对浏览操作的影响。完成标准：对于测试对象软件和非测试对象软件的各种组合，所有事务都成功完成，没有出现任何故障。所设计的配置测试用例已全部执行。所发现的缺陷除推迟解决的问题外已全部解决，推迟的问题需经评审通过。需考虑的特殊事项：需要、可以使用并可以通过桌面访问哪种非测试对象软件？通常使用的是哪些应用程序？应用程序正在运行什么数据？例如，在 Excel 中打开的大型电子表格，或是在 Word 中打开的 100 页文档。作为此测试的一部分，应将整个系统、Netware、网络服务器、数据库等都记录下来。 5.4.5 安全性测试说明是否进行SQL脚本注入、跨

22、脚本注入和.BAK文档检查测试。表15 安全性测试策略表测试目标：技术：完成标准：需考虑的特殊事项：5.4.6 数据和数据库完整性测试在 中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和技术。表16 数据和数据库完整性测试策略表测试目标：确保数据库访问方法和进程正常运行，数据不会遭到损坏。技术：调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据（或对数据的请求）。检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件都已正常发生；或

23、者检查所返回的数据，确保为正当的理由检索到了正确的数据完成标准：所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。需考虑的特殊事项：测试可能需要 DBMS 开发环境或驱动程序在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库（记录的数量有限）来使所有无法接受的事件具有更大的可视度。5.4.7 故障转移和恢复测试故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。 故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何

24、数据或事务。恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。表17 故障转移和恢复测试策略表测试目标：技术：完成标准：需考虑的特殊事项：5.4.8 业务周期测试业务周期测试应模拟在一段时间内对 执行的活动或该项目的业务流程。5.4.9 可靠性测试对 运行结果的可靠性5.4.10 病毒测试对软件程序的杀毒5.4.11 文档测试针对手册评审和帮助测试第6章 项目里程碑 对 的

25、测试应包括上面各节所述的各项测试的测试活动。应该为这些测试确定单独的项目里程碑，以通知项目的状态和成果。在制定时间时应把测试的风险所延误的时间考虑在内。表18 测试进度表任务开始时间结束时间相关工作量（人/日）测试计划测试用例测试计划评审测试用例评审测试执行第一轮测试性能测试第二轮测试第N轮测试测试评估测试报告评审第7章 附录 ：项目任务以下是一些与测试有关的任务：测试计划1) 确定测试需求2) 评估风险3) 制定测试策略4) 确定测试资源5) 创建时间表6) 生成测试计划测试设计1) 准备工作量分析文档2) 确定并说明测试用例3) 确定测试过程，并建立测试过程的结构4) 复审和评估测试覆盖 测试开发1) 记录或通过编程创建测试脚本2) 确定设计与实施模型中的测试专用功能3) 建立外部数据集测试执行1) 执行测试过程2) 评估测试的执行情况3) 恢复暂停的测试4) 核实结果5) 调查意外结果6) 记录缺陷测试评估1) 评估测试用例覆盖2) 分析缺陷