4.3  项目测试计划的基本结构和内容

软件测试计划是对测试过程的整体设计，通过收集项目和产品相关的信息，对测试范围、测试风险进行分析，对测试用例、工作量、资源和事件等进行估算，对测试采用的策略、方法、环境、资源、进度等做出合理的安排。

4.3.1  测试目的和测试项目简介

案例1：（两条*****线内的是案例文档部分）

*************************************************************************

1.简介

1.1 目的

XXXX系统的“测试计划”文档有助于实现以下目标。

Ø  保障所开发项目的质量，使其符合客户的需求。

Ø  控制项目测试进度，保障按期交付，降低公司运营风险。

Ø  确定本次测试工作的实施思路和步骤。

Ø  明确项目需要测试的内容和关注点。

Ø  对测试的工作量进行估计，确定所需资源及人员分工。

Ø  确定出可采用的测试策略，并对确定的方法策略进行说明。

1.2背景

项目名称：XXXX编辑系统。

任务提出者：某某公司。

开发者：某公司某部门。

用户：某某公司。

1.2.1  XXXX编辑系统的项目背景

XXXX编辑系统用于视音频节目的后期制作。主要针对独立的视音频制作人员、电教中心、视音频制作中心，以及电视台，用于电视专题片、商业演示、简单MTV、简单广告节目的制作。

XXXl.0~3.0都是基于M板卡开发的非编辑系统，从XXX4.0开始是基于T系列板卡开发的编辑系统。

1.2.2  XXXX编辑系统的基本功能

输入输出功能包括视音频信号输入输出和文件输入输出。视音频输入输出提供视音频信号采集、录制、播放等功能；文件输入输出支持读写多种不同格式的视频、音频、图像文件。

项目管理功能指以项目方式管理视音频片段、图像、字幕等素材，将用户制作节目时相关的原始素材、节目片段，以及相关设置集中起来管理，称为一个项目，不同的节目可以由建立的不同项目进行管理。项目管理功能主要包括项目设置、素材库管理、素材排序等功能。编剪功能针对专题片的制作，包括素材剪裁、节目的快速串编、设置切换特技、设置实时效果特技等功能。

1.2.3 特技功能

特技功能为实时特技。实时特技由硬件平台（T板卡）提供，包括常用切换特技、二维效果特技、抠像、颜色校正、透明度调整等功能。

1.3 范围

测试的各个阶段如下：

Ø  测试设计：根据需求规格说明书和最终的系统设计，制定测试计划、测试方案，包括收集测试方法、测试用例及可能的测试工具等。

Ø  集成测试：前期主要针对单个的功能和模块及简单的功能组合，后期主要针对基本的流程，同时对新加入的测试人员进行培训。

Ø  系统测试：前期根据需求规格说明书进行功能测试，中期是针对重点模块的性能测试，后期是模拟用户的业务测试，并结合可能的用户测试。

Ø  验收测试：根据用户手册对功能进行检查，复查报告库中的所有缺陷，对提交发布版本进行安装测试，典型配置环境的裸机测试及加密测试。

********************************************************************************

1. 测试目的

测试计划第一个条目是定义测试的目标，不同的测试工作有不同的测试目标，这是项目小组全部成员必须认可的最基本的内容，但是常常被忽视。因为它们被认为“太明显”，每个人当然了解，但是优秀的测试员知道永远不要假定任何事情。

Ø  测试计划过程和软件测试计划的目的是什么?是否所有人都知道?他们同意和支持这个测试计划过程吗?

Ø  测试的是什么产品?是新程序还是维护升级的?是一个独立程序还是由多个小程序组成?

Ø  产品的质量和可靠性目标是什么?由于测试小组将会测试产品的质量和可靠性，因此必须知道目标是什么，否则不能清楚知道软件是否达到目标，并且所有人必须一致同意这些目标才行。

制定测试计划的第一步就是了解以上问题，了解测试项目的范围、目标，对实现测试目标中起作用的每个细节都清清楚楚。

2. 测试项目的背景

接下来就是对要测试项目的基本情况进行调研。为了使测试工作成功，必须完全了解被测对象，了解它的应用领域、开发背景、主要功能及使用范围。对于大的测试项目，还要包括测试的目的和侧重点。我们可以从需求说明书得到产品的这些描述。

产品基本情况调研的具体要点如下：

Ø  产品规格：产品名称、制造商和产品版本号的说明。

Ø  产品信息：产品的用户、开发该产品的背景。

Ø  技术结构：介绍产品的主要功能，可以借助图表的格式表述。

3. 测试范围

测试范围主要指“处理、活动和影响的程度，操作的范围”。描述测试的各个阶段（例如，单元测试、集成测试或系统测试）的测试类型（如功能测试或性能测试），分别简要地列出将要进行测试的功能点和性能指标。

4.3.2  测试参考文档和测试提交文档

案例2：（两条*****线内的是案例文档部分）

*********************************************************************************

2.测试参考文档和测试提交文档

2.1 测试参考文档

Ø  产品需求说明书

Ø  产品概要设计

Ø  产品使用说明书

2.2测试提交文档

2.2.1  测试用例

通过测试前的准备和测试后的总结，不断完善测试用例，并在模块内分出优先级。

2.2.2  测试日志

测试人员每天或阶段性进行小结，记录进行了哪些工作，包括未发现问题的部分和对系统（模块）现状的评价，以上记录保存到Notes库（XXX4.0开发数据库）中。

定期（每周）进行测试例会（可能的话，最好是开发和测试例会一起开），及时交流大家对系统现状的看法和急需解决的问题等，以上记录保存到Notes库（XXX4.0开发数据库）中。

2.2.3 缺陷报告

使用Notes上的报告库（X4.0集成测试库和X4.0系统测试库）记录和管理缺陷报告。

2.2.4 测试总结报告

测试完成后，对报告库（X4.0集成测试库和X4.0系统测试库）进行整理和分析。

验收测试总结报告：验收测试完成后，按照要求填写验收测试总结报告，对整个测试过程进行小结。

2.2.5 备注

此测试计划不包含单元测试的内容。

**********************************************************************************

1. 测试参考文档

测试计划中会引用其他的文档或书籍，我们要在计划中列出有关资料的名称、文件编号及其发表日期、出版单位、作者等，并说明参考文件的来源。参考资料包括如下一些。

Ø  经核准的计划任务书，上级机关批文、合同等。

Ø  本项目的其他已发表的文件。

Ø  引用文件、资料、软件开发标准。

2. 测试提交文档

如同前面的课程中提到的，测试人员在测试过程中还会产生一些文档，对这部分文档，测试人员要在测试计划中规定它们的格式、提交方式，以及使用何种应用程序来制作等规则，在以后的使用中所有人都要遵循该规则。

Ø  测试用例：建立测试用例内容模板，规定用例的编号规则。

Ø  测试日志：建立测试日志内容模板，确定记录日志所使用的应用程序。

Ø  缺陷报告：确定缺陷报告的内容：确定要使用的缺陷提交方式，使用缺陷跟踪系统还是通过电子文档提交?确定缺陷的严重程度的分类方法：确定修复缺陷的优先级等。

其中，缺陷的严重程度和修复的优先级在第三章已经学过，这里简单的回顾一下。

缺陷的严重程度（致命、严重、一般、低级、建议）：

1）影响测试进度的问题（严重）

2）死机问题（致命）

3）功能问题（一般）

4）界面问题（一般或建议）

5）建议

优先级（P1,P2,P3,P4）表示修复缺陷的重要程度和应该何时修复：

1）应立即修复的问题 (P1)

2）在产品发布之前必须修复的问题(P2,P3)

3）如果时间允许，应该修复的问题(P4)

4）可以在发布版本中存在的问题(P4)

Ø  测试总结：建立测试总结内容模板。

4.3.3  术语和定义

该条目定义了开发产品项目或测试过程中常用术语的含义，使程序员、测试员和其他人员对产品项目中的常用术语有一致的理解。常常会发生这样的情况，即程序员和测试人员因为对同一个术语或定义的理解不同，而在测试过程中发生争执。通过在测试计划中确定术语的含义，可以使所有人在测试过程中达成一致。

4.3.4  测试策略

案例3：（两条*****线内的是案例文档部分）

*************************************************************************

3.1测试策略

Ø  数据库测试：针对与数据库相关的功能进行测试，通过对数据的读写操作测试数据库。以数据库运行正常，数据不丢失为标准。

Ø  功能确认测试：集成测试阶段主要针对大的功能实现进行测试，系统测试阶段依据需求规格说明书逐项测试，验收测试阶段依据说明书逐项测试。以按需求或用户手册所列功能检查一遍为标准（每个版本周期内）。

Ø  界面测试：只在系统测试阶段进行，按照相关规定进行检查。以按相关要求规定检查一遍为标准。

Ø  值域测试：只在系统测试阶段进行，针对总结(测试过程中逐步总结)出的常用项进行检查。以常用功能项检查一遍为标准。

Ø  版本验证测试：在系统测试和验收测试阶段进行，尽量避免因开发组版本控制问题而影响测试效果。进行必要的报告返测和系统的基本功能测试，一般时间为一天。以确认版本是否值得进行测试为标准。

Ø  可用性测试：在系统测试的中后期展开，主要针对重点模块进行。测试编剪的响应速度、节目播放的实时性、与字幕的配合、采集录制的帧精确性、素材和用户信息的真实准确性等与非编系统基本要求相关的内容。以满足足够多的基本要求为标准。

Ø  强度测试：在系统测试的中后期展开，通过模拟用户的测试进行，验证系统的健壮性。

Ø  首先进行一些必要的负载测试，在达到一定稳定性的基础上，开始模拟用户的测试，并与可能的用户测试相结合，找出一般测试不能发现的问题。连续正常使用不死机的时间在允许范围之内(1天死机1次)，出错后数据丢失在允许范围内为标准。

Ø  安全性测试：在系统测试阶段进行。针对与之相关的模块的测试同步进行。以满足基本的安全要求为标准。

Ø  裸机测试：在系统测试的中后期和验收测试阶段进行。在干净的环境中，进行与其他测试环境相同的测试，应包括所有的测试内容。标准是在裸机环境上程序运行正常。

Ø  安装测试：在系统测试的中后期和验收测试阶段进行。以安装正常，并且卸载正常为标准。

Ø  加密测试、在系统测试的中后期和验收测试进行。主要是针对加密狗问题的测试。标准是"加密+可以使用"与"不加密+不能使用"两个方面都保证是正常的。

3.1.1  数据库测试

表4-1数据库测试要求

3.1.2  功能测试

表4-2功能测试要求

3.1.3 界面测试

表4-3界面测试要求

3.1.4  值域测试

表4-4值域测试要求

3.1.5 版本验证测试

表4-5版本验证测试要求

3.1.6  可用性测试

表4-6可用性测试要求

3.1.7 强度测试

表4-7强度测试要求

3.1.8 安全性测试

表4-8安全性测试要求

3.1.9  裸机测试

表4-9裸机测试要求

3.1.10安装测试

表4-10安装测试要求

3.1.11加密测试

表4-11加密测试要求

3.2工具

表4-12 本项目测试使用的工具

*****************************************************************************

测试策略是整个测试计划的重点所在，测试策略描述测试小组用于测试整体和每个阶段的方法。确定测试策略要从模块、功能、整体、系统、版本、压力、性能、配置和安装等各个方面来考虑，要尽可能地考虑到细节，越详细越好。通常要确定如下一些注意事项。

Ø  是使用黑盒测试还是白盒测试，或者综合使用这两种技术?在软件的哪些部分及什么时候应用它们?

Ø  哪些代码用手工测试?哪些代码用工具或自动化测试?

Ø  如果要使用工具，是否需要开发，或者能够买到已有的商用解决方案?

Ø  是否需要把整个测试工作提交到专业的测试公司?

Ø  进行不同的测试有没有要注意的特殊事项?

测试计划过程还应该明确规定测试阶段，并规定开始和结束不同测试阶段的必要标准。我们将其称为进入标准和退出标准。

每一个测试阶段都必须有绝对的标准表示本阶段结束及下一阶段开始。假如没有明显的进入和退出标准，测试工作就会陷入一种毫无头绪的状态，想到哪里做到哪里。

4.3.5  确定测试内容

案例4：

确定测试内容的样式如表4-13所示。

表4-13 测试内容表

这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。具体要点如下。

Ø  功能的测试：理论上测试要覆盖所有的功能项。

Ø  设计的测试：对一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

Ø  整体考虑：要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。

通过列出所有要测试的功能项，有时会发现软件产品中包含的内容不必测试。这些内容可能是以前发布过或者测试过的软件部分。我们需要验明软件的每一部分，知道它是否要被测试，如果没有测试，就要说明这样做的理由。如果因为误解而使部分代码在整个开发周期被漏掉，未做任何测试，就可能导致灾难性的结果。

在软件开发过程中通常会划分功能的优先级，开发组会首先交付优先级最高的功能。相应地，测试人员也要首先测试这些功能。可以根据不同标准来划分测试功能项的优先级。

Ø  风险最高到风险最低。将开发和测试的精力首先集中在风险最高的特性上。

Ø  复杂度最高到复杂度最低。首先测试最复杂的功能，可以最大限度地减少进度的延迟。

Ø  客户的需要。为了推动产品的市场和销售，一般都根据客户的需要来确定功能交付的优先级。

在制定功能项的优先级时，通常要综合使用上面的标准。我们可以为每个功能项的风险、复杂度、用户需要和其他因素进行打分。一旦完成，就可以按得分总和的高低进行排序，这样就得到了每个功能项的优先级列表。

4.3.6  资源

案例5：

*************************************************************************

5. 资源

5.1 角色

表4-14列出了在此项目的人员配备方面所做的各种假定。

表4-14项目人员资源配备

5.2 系统

测试项目所需的系统资源。

硬件资源如下。

Ø  CPU：P4 1.5G以上，或者双PIII 800M以上。

Ø  主板：Pinnacle推荐的主板，带有AGP插槽，5个PCI32插槽。如果需要支持3路无压缩视频流实时播放，则需要带有2个PCI64插槽。

Ø  内存：256MB(最好512MB)。

Ø  显卡：支持双屏显示，带有OpenGL加速的显卡，显存不低于32MB。支持2048X768真彩色，支持YUV直接显示。如ELSA Synergy III (NVIDIA QUADRO MXR)、AGP、32MB、Dual Monitor Support。

Ø  视频卡：b系列及配套的接口箱。

Ø  SCSI卡：支持SCSI 160的双通道SCSI卡。

Ø  机箱：带有配套视频接口背板的机箱。

Ø  硬盘：1块IDE或SCSI系统硬盘(20GB以上)，SCSI硬盘阵列(4块或者8块10000转以上的SCSI硬盘)。

软件环境如下。

Ø  Windows 2000十SP2。

Ø  b系列的SDK驱动。

Ø  XXXX编辑系统4.0。

*********************************************************************

计划资源需求是确定实现测试策略必备条件的过程。在软件测试之前，要制定一个项目资源计划，包含每一个阶段的任务、所需的资源，当发生类似到了使用期限或资源共享的事情时，要更新这个计划。在该计划中，项目期间测试可能用到的任何资源都要考虑到，例如：

Ø  人员：人数、经验和专长，全职还是兼职?

Ø  设备：计算机、测试硬件、打印机、测试工具。

Ø  办公室和实验室空间：在哪里?空间有多大?怎样排列?

Ø  软件：字处理程序、数据库程序和自定义工具。要购买哪些东西?要写什么材料?

Ø  提交测试公司：用他们吗?选择使用有什么原则?他们的费用如何?

Ø  其他供应：软盘、电话、参考书、培训资料，在项目期间还需要别的吗?

具体资源需求取决于项目、小组和公司，因此测试计划工作要仔细估算测试软件的要求。开始不做好预算，到项目后期获取资源通常很困难，甚至无法做到，因此创建完整清单是不容忽视的。

4.3.7  测试进度

案例6：

*********************************************************************

6.1各测试阶段的资源要求及时间安排

表4-15 各测试阶段的资源要求及时间计划

6.2项目里程碑

表4-16项目里程碑

对于新加入测试人员的培训，前期提供了一些参考书和资料，供他们自学，估计只能达到初步了解的效果：由于时间比较紧，只能在集成测试阶段，针对X4.0系统进行必要的培训；系统测试阶段也需要新加入的测试人员一边测试，一边了解相关的知识；希望通过这次的测试，使新加入的测试人员能够积累一定的经验。

*********************************************************************

计划项目的进度需要根据以上的全部信息。该项目在计划中至关重要。我们会遇到很多以为很容易测试的特性在正式测试中被认为非常耗时的情况，所以完成一个合理的进度安排可以为产品开发和管理者提供信息，以便更好地安排整个项目的进度。他们甚至会根据测试进度决定去掉产品中的一些特性，或者将其推迟到下一个版本中推出。

关于测试计划的一个重要问题是，测试工作不能平均分布在整个产品开发周期中。在有些测试中，早期先进行说明书和代码审查、工具开发等，随着开发的进展，测试任务的数量、人员和测试花费的时间的不断增长，在产品发布之前会形成短期的高峰，如图4-6所示。

测试开发和执行的时间不足会降低测试工程实施过程的效率，而且还需要额外的测试工作去纠正错误或疏忽。所以安排好测试的进度是至关重要的。在进行测试进度和人员安排时，可以从以下方面进行。

Ø  每次都记录当前项目每项任务实际花费的人员和时间。这些数据可在未来的测试进度的估算中起到参考的作用。

Ø  考虑测试组织的测试成熟度。例如，一个组织以前根本不重视测试工作，没有形成成熟的测试过程；或者测试组刚经过重大的人员调整。这些都要作为影响测试进度的因素考虑。

图4-6 测试资源和开发进度关系图

Ø  测试需求范围。必须完成的测试可能包含功能测试、性能测试、界面测试、负载测试、安全性测试、内存泄露测试、可用性测试，以及其他测试。

Ø  测试工程师的技术水平。执行测试的个人的技术能力和水平。

Ø  使用测试工具的熟练程度。自动测试的使用使项目测试人员的工作更加复杂。学习工具需要有一个过程，而编写测试脚本需要有编程方面的专业技术。

Ø  商业知识。测试组成员对应用程序业务领域的熟悉程度。

Ø  测试程序的范围。一个有效的自动测试程序本身就需要一定的开发工作量，其中包括规划测试和目标、测试需求定义、分析、设计和编码。

Ø  测试工作的启动。测试计划和测试活动应该在项目早期开始。这意味着为了防止分析和设计错误，测试工程师必须参与分析和设计的评审活动。测试人员及早介入，就可以更透彻地了解需求和设计，因此能够构建更合理的测试环境和生成更全面的测试设计。

Ø  软件计划升级的版本个数。许多软件专业人士都有这样的经验，使用自动测试工具可以显著地减少测试工作的人•小时数，或者降低测试计划和执行的复杂度。使用自动测试工具可以节约资金，使得时间变得充裕。但是事实上，测试组最初使用某种特定的自动测试工具时，这种节约几乎体现不出来，而在应用软件的后续版本中才会获得好的效果。

Ø  高风险的应用程序。如果软件失灵对人的生命产生威胁，那么这种软件的测试工作所要求的深度和广度要远远大于那些不会产生很大风险的应用软件。

Ø  另外，大多数计划都应该包含测试项目的里程碑事件的计划。测试管理员要将注意力集中在这些高级别的重大事件上。

4.3.8  测试员的任务分配

定义了测试阶段、测试策略和资源要求，这些信息加上需求说明书就可以为每个测试员分配任务了。表4-17给出了简单的xxx程序的测试员任务分配表，明确测试员负责软件的哪些部分及哪些可测试特性。

表4-17测试员任务分配表

4.3.9  风险和问题

实际责任表更加详细，确保软件的每一部分都分配有人测试。每一个测试员都会清楚地知道自己负责什么，而且有足够的信息开始设计测试案例。

案例7：

*************************************************************************

7. 可能的影响或风险

Ø  市场的压力。

Ø  测试时间不够，主要是功能冻结后的系统测试的时间可能不够。

Ø  测试资源的及时到位(设备和人员)。

Ø  测试人员的培训。

Ø  开发进度的变化，需求或设计的变更。

Ø  测试人员的基础培训。

Ø  开发组的版本控制。

*************************************************************************

这部分明确地指出了测试过程中的潜在问题或风险，这些事件会为制定测试计划带来困难，或者使计划难以执行。例如，人员经验不足，需要培训；开发进度的变化，需求或设计的变更等。测试人员必须与管理者交换意见，提出这些问题，使他们在整体进度安排中给予考虑。

在测试工作中，主要的风险表现有以下几点：

（1）需求风险。对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，同步时存在误差。

（2）测试用例风险。测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求；测试用例没有得到全部执行，有些用例被有意或者无意的遗漏。

（3）缺陷风险。某些缺陷偶发，难以重现，容易被遗漏。

（4）代码质量风险。软件代码质量差，导致缺陷较多，容易出现测试的遗漏。

（5）测试环境风险。有些情况下测试环境与生产环境不能完全一致，导致测试结果存在误差。

（6）测试技术风险。某些项目存在技术难度，测试能力和水平导致测试进展缓慢，项目延期。

（7）回归测试风险。回归测试一般不运行全部测试用例，可能存在测试不完全。

（8）沟通协调风险。测试过程中涉及的角色较多，存在不同人员、角色之间的沟通、协作，难免存在误解、沟通不畅的情况，导致项目延期。

（9）其它不可预计风险。一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。

以上是测试过程中可能发生的风险，其中有的风险是难以避免的，如缺陷风险等。有的风险从理论上可以避免，但实际操作过程中出于时间和成本的考虑，也难以完全回避，如回归测试风险等。对于难以避免的风险，我们的目标是将风险降到最低水平。