搜索
第6章软件测试项目管理6.1测试项目管理概述6.2测试文档6.3软件测试计划6.4测试的组织与人员管理6.5软件测试过程管理6.1测试项目管理概述6.1.1测试项目与测试项目管理1．测试项目测试项目是在一定的组织机构内，利用有限的人力和财力等资源，在指定的环境和要求下，对特定软件完成特定测试目标的阶段性任务。该任务应满足一定质量、数量和技术指标等要求。测试项目一般具有如下一些基本特性。（1）项目的独特性（2）项目的组织性（3）测试项目的生命期（4）测试项目的资源消耗特性（5）测试项目目标冲突性（6）测试项目结果的不确定因素2．测试项目管理测试项目管理就是以测试项目为管理对象，通过一个临时性的专门的测试组织，运用专门的软件测试知识、技能、工具和方法，对测试项目进行计划、组织、执行和控制，并在时间成本、软件测试质量等方面进行分析和管理活动。（一种高级管理方法）测试项目管理贯穿整个测试项目的生命周期，是对测试项目的全过程进行管理。测试项目管理有以下基本特征。（1）系统工程的思想贯穿测试项目管理的全过程。（2）测试项目管理的组织有一定的特殊性。（3）测试项目管理的要点是创造和保持一个使测试工作顺利进行的环境，使置身于这个环境中的人员能在集体中协调工作以完成预定的目标。（4）测试项目管理的方法、工具和技术手段具有先进性。6.1.2测试项目的范围管理测试项目范围管理就是界定项目所必须包含且只需包含的全部工作，并对其他的测试项目管理工作起指导作用，以确保测试工作顺利完成。项目目标确定后，下一步过程就是确定需要执行哪些工作，或者活动来完成项目的目标，这就是要确定一个包含项目所有活动在内的一览表。准备这样的一览表通常有两种方法：一种是让测试小组利用“头脑风暴法”根据经验，集思广益来形成。这种方法比较适合小型测试项目。另一种是对更大更复杂的项目建立一个工作分解结构WBS和任务的一览表。工作分解结构是将一个软件测试项目分解成易于管理的更多部分或细目，所有这些细目构成了整个软件测试项目的工作范围。工作分解结构是进行范围规划时所使用的重要工具和技术之一，它是测试项目团队在项目期间要完成或生产出的最终细目的等级树，它组织并定义了整个测试项目的范围，未列入工作分解结构的工作将排除在项目范围之外。进行工作分解是非常重要的工作，它在很大程度上决定项目能否成功。对于细分的所有项目要素需要统一编码，并按规范化进行要求。这样，WBS的应用将给所有的项目管理人员提供一个一致的基准，即使项目人员变动时，也有一个互相可以理解和交流沟通的平台。6.2测试文档测试文档是对要执行的软件测试及测试的结果进行描述、定义、规定和报告的任何书面或图示信息。由于软件测试是一个很复杂的过程，同时也涉及到软件开发中其他一些阶段的工作，因此，必须把对软件测试的要求、规划、测试过程等有关信息和测试的结果，以及对测试结果的分析、评价，以正式的文档形式给出。测试文档对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时还会用到测试文档。测试文档的编写是测试管理的一个重要组成部分。6.2.1测试文档的作用测试文档的重要作用可从以下几个方面看出。1．促进项目组成员之间的交流沟通2．便于对测试项目的管理3．决定测试的有效性4．检验测试资源5．明确任务的风险6．评价测试结果7．方便再测试8．验证需求的正确性6.2.2测试文档的类型根据测试文档所起的不同作用，通常把它分成两类，即前置作业文档和后置作业文档。测试计划及测试用例的文档属于前置作业文档。后置作业文档是在测试完成后提交的，主要包括软件缺陷报告和分析总结报告。6.2.3主要软件测试文档1．软件测试文档给出了软件测试主要文档的类型。IEEE829－1998软件测试文档编制标准软件测试文档模板目录测试计划测试设计规格说明测试用例说明测试规程规格说明测试日志测试缺陷报告测试总结报告2．软件测试计划主要对软件测试项目、所需要进行的测试工作、测试人员所应该负责的测试工作、测试过程、测试所需的时间和资源，以及测试风险等做出预先的计划和安排。IEEE829－1998软件测试文档编制标准软件测试计划文档模板目录1．测试计划标识符2．介绍3．测试项4．需要测试的功能5．方法（策略）6．不需要测试的功能7．测试项通过/失败的标准8．测试中断和恢复的规定9．测试完成所提交的材料10．测试任务11．环境需求12．职责13．人员安排与培训需求14．进度表15．潜在的问题和风险16．审批3．测试设计规格说明用于每个测试等级，以指定测试集的体系结构和覆盖跟踪。IEEE829－1998软件测试文档编制标准软件测试设计规格说明文档模板目录测试设计规格说明标识符待测试特征方法细化测试标识通过/失败准则4．软件测试用例规格说明文档用于描述测试用例。IEEE829－1998软件测试文档编制标准软件测试用例规格说明文档模板目录测试用例规格说明标识符测试项输入规格说明输出规格说明环境要求特殊规程需求用例之间的相关性5．测试规程用于指定执行一个测试用例集的步骤。6．测试日志由于记录测试的执行情况不同，可根据需要选用。7．软件缺陷报告用来描述出现在测试过程或软件中的异常情况，这些异常情况可能存在于需求、设计、代码、文档或测试用例中。8．测试总结报告用于报告某个测试完成情况。6.3软件测试计划测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。6.3.1制定测试计划的目的一个计划一定是为了某种目的而产生的，对于软件质量管理而言，制定测试计划的目的主要有3个。1．使软件测试工作进行更顺利2．促进项目参加人员彼此的沟通3．使软件测试工作更易于管理6.3.2制定测试计划的原则制定测试计划是软件测试中最有挑战性的一个工作。以下原则将有助于制定测试计划工作。1．制定测试计划应尽早开始2．保持测试计划的灵活性3．保持测试计划简洁和易读4．尽量争取多渠道评审测试计划5．计算测试计划的投入6.3.3制定测试计划时面对的问题制定测试计划时，测试人员可能面对以下问题，必须认真对待，并妥善予以处理。1．与开发者意见不一致2．缺乏测试工具3．培训不够4．管理部门缺乏对测试工作的理解和支持5．缺乏用户的参与6．测试时间不足7．过分依赖测试人员8．测试人员处于进退两难的状态9．不得不说“不”6.3.4制定测试计划制定测试计划时，由于各软件公司的背景不同，测试计划文档也略有差异。实践表明，制定测试计划时，使用正规化文档通常比较好。为了使用方便，在这里给出IEEE软件测试计划文档模板。IEEE829－1998软件测试文档编制标准软件测试计划文档模板目录1．测试计划标识符2．介绍3．测试项4．需要测试的功能5．方法（策略）6．不需要测试的功能7．测试项通过/失败的标准8．测试中断和恢复的规定9．测试完成所提交的材料10．测试任务11．环境需求12．测试人员的工作职责13．人员安排与培训需求14．进度表15．潜在的问题和风险16．审批根据IEEE829－1998软件测试文档编制标准的建议，测试计划包含了16个大纲要项，简要说明如下。1．测试计划标识符一个测试计划标识符是一个由公司生成的惟一值，它用于标识测试计划的版本、等级，以及与该测试计划相关的软件版本。2．介绍在测试计划的介绍部分主要是测试软件基本情况的介绍和测试范围的概括性描述。3．测试项测试项部分主要是纲领性描述在测试范围内对哪些具体内容进行测试，确定一个包含所有测试项在内的一览表。具体要点如下。功能的测试设计的测试整体测试IEEE标准中指出，可以参考下面的文档来完成测试项：需求规格说明用户指南操作指南安装指南与测试项相关的事件报告4．需要测试的功能测试计划中这一部分列出了待测的功能。5．方法（策略）这部分内容是测试计划的核心所在，所以有些软件公司更愿意将其标记为“策略”，而不是“方法”。测试策略描述测试小组用于测试整体和每个阶段的方法。要描述如何公正、客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响，要尽可能地考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备。测试记录具体说明如下。公正性声明测试用例特殊考虑经验判断设想6．不需要测试的功能测试计划中这一部分列出了不需要测试的功能。7．测试项通过/失败的标准测试计划中这一部分给出了“测试项”中描述的每一个测试项通过/失败的标准。正如每个测试用例都需要一个预期的结果一样，每个测试项同样都需要一个预期的结果。下面是通过/失败的标准的一些例子：通过测试用例所占的百分比；缺陷的数量、严重程度和分布情况；测试用例覆盖；用户测试的成功结论；文档的完整性；性能标准。8．测试中断和恢复的规定测试计划中这一部分给出了测试中断和恢复的标准。常用的测试中断标准如下：关键路径上的未完成任务大量的缺陷严重的缺陷不完整的测试环境资源短缺9．测试完成所提交的材料测试完成所提交的材料包含了测试工作开发设计的所有文档、工具等。例如，测试计划、测试设计规格说明、测试用例、测试日志、测试数据、自定义工具、测试缺陷报告和测试总结报告等。10．测试任务测试计划中这一部分给出了测试工作所需完成的一系列任务。在这里还列举了所有任务之间的依赖关系和可能需要的特殊技能。11．环境需求环境需求是确定实现测试策略必备条件的过程。例如：人员——人数、经验和专长。他们是全职、兼职、业余还是学生？设备——计算机、测试硬件、打印机、测试工具等。办公室和实验室空间——在哪里？空间有多大？怎样排列？软件——字处理程序、数据库程序和自定义工具等。其他资源——软盘、电话、参考书、培训资料等。12．测试人员的工作职责测试人员的工作职责是明确指出了测试任务和测试人员的工作责任。有时测试需要定义的任务类型不容易分清，不像程序员所编写的程序那样明确。复杂的任务可能有多个执行者，或者由多人共同负责。13．人员安排与培训需求前面讨论的测试人员的工作职责是指哪类人员（管理、测试和程序员等）负责哪些任务。人员安排与培训需求是指明确测试人员具体负责软件测试的哪些部分、哪些可测试性能，以及他们需要掌握的技能等。实际责任表会更加详细，确保软件的每一部分都有人进行测试。每一个测试员都会清楚地知道自己应该负责什么，而且有足够的信息开始设计测试用例。培训需求通常包括学习如何使用某个工具、测试方法、缺陷跟踪系统、配置管理，或者与被测试系统相关的业务基础知识。培训需求各个测试项目会各不相同，它取决于具体项目的情况。14．进度表测试进度是围绕着包含在项目计划中的主要事件（如文档、模块的交付日期，接口的可用性等）来构造的。作为测试计划的一部分，完成测试进度计划安排，可以为项目管理员提供信息，以便更好地安排整个项目的进度。表6-4给出了一个例子。表6-4相对日期的测试进度测试任务开始日期期限测试计划完成说明书完成之后7天4周测试案例完成测试计划完成12周第1阶段测试通过代码完成6周第2阶段测试通过Beta构造6周第3阶段测试通过发布构造4周进度安排会使测试过程容易管理。通常，项目管理员或者测试管理员最终负责进度安排，而测试人员参与安排自己的具体任务。15．潜在的问题和风险软件测试人员要明确地指出计划过程中的风险，并与测试管理员和项目管理员交换意见。这些风险应该在测试计划中明确指出，在进度中予以考虑。有些风险是真正存在的，而有些最终证实是无所谓的，重要的是尽早明确指出，以免在项目晚期发现时感到惊慌。一般而言，大多数测试小组都会发现自己的资源有限，不可能穷尽测试软件所有方面。如果能勾画出风险的轮廓，将有助于测试人员排定待测试项的优先顺序，并且有助于集中精力去关注那些极有可能发生失效的领域。下面是一些潜在的问题和风险的例子：不现实的交付日期与其他系统的接口处理巨额现金的特征极其复杂的软件有过缺陷历史的模块发生过许多或者复杂变更的模块