12-软件测试项目管理.ppt

1、软件测试技术,章晓芳,6.1 测试项目管理概述 6.2 测 试 文 档 6.3 软件测试计划 6.4 测试的组织与人员管理 6.5 软件测试过程管理,6.1 测试项目管理概述,6.1.1 测试项目与测试项目管理 1测试项目 测试项目是在一定的组织机构内，利用有限的人力和财力等资源，在指定的环境和要求下，对特定软件完成特定测试目标的阶段性任务。该任务应满足一定质量、数量和技术指标等要求。,测试项目一般具有如下一些基本特性。 （1）项目的独特性 （2）项目的组织性 （3）测试项目的生命期 （4）测试项目的资源消耗特性 （5）测试项目目标冲突性 （6）测试项目结果的不确定因素,2测试项目管理 测试项

2、目管理就是以测试项目为管理对象，通过一个临时性的专门的测试组织，运用专门的软件测试知识、技能、工具和方法，对测试项目进行计划、组织、执行和控制，并在时间成本、软件测试质量等方面进行分析和管理活动。 测试项目管理贯穿整个测试项目的生命周期。,测试项目管理有以下基本特征。 （1）系统工程的思想贯穿测试项目管理的全过程。 （系统性，阶段性） （2）测试项目管理的组织有一定的特殊性。 （临时性，柔性）,（3）测试项目管理的要点是创造和保持一个使测试工作顺利进行的环境，使置身于这个环境中的人员能在集体中协调工作以完成预定的目标。 （4）测试项目管理的方法、工具和技术手段具有先进性。,6.1.2 测试项目

3、的范围管理 测试项目范围管理就是界定项目所必须包含且只需包含的全部工作，并对其他的测试项目管理工作起指导作用，以确保测试工作顺利完成。,项目目标确定后，下一步过程就是确定需要执行哪些工作，或者活动来完成项目的目标，这就是要确定一个包含项目所有活动在内的一览表。,准备这样的一览表通常有两种方法： 一种是让测试小组利用“头脑风暴法”根据经验，集思广益来形成。这种方法比较适合小型测试项目。 另一种是对更大更复杂的项目建立一个工作分解结构WBS (Work Breakdown Structure)和任务的一览表。,6.2 测 试 文 档,测试文档是对要执行的软件测试及测试的结果进行描述、定义、规定和报

4、告的任何书面或图示信息。,测试文档不只是在测试阶段才考虑的，它应该在软件开发初期的需求分析阶段就开始着手。 测试文档与用户的密切关系： 用户了解开发过程 用户理解开发的应用系统 用户澄清模糊的认识 项目小组认清用户的要求,测试文档：设计方案 测试文档：测试阶段工作的指导与评价 测试文档：再测试或回归测试 测试文档的编写是测试管理的一个重要组成部分。,6.2.1 测试文档的作用 测试文档的重要作用可从以下几个方面看出。 1促进项目组成员之间的交流沟通 2便于对测试项目的管理,3决定测试的有效性 4检验测试资源 5明确任务的风险 6评价测试结果 7方便再测试 8验证需求的正确性,6.2.2 测试文

5、档的类型 根据测试文档所起的不同作用，通常把它分成两类。 测试计划及测试用例的文档属于前置作业文档。 后置作业文档在测试完成后提交的，主要包括软件缺陷报告和分析总结报告。 根据测试文档编制的不同方法，分为手工编制和自动编制。,6.2.3 主要软件测试文档 根据一定的标准编写文档，具备一致的外观、结构和质量。 1软件测试文档 给出了软件测试主要文档的类型。,2软件测试计划 主要对软件测试项目、所需要进行的测试工作、测试人员所应该负责的测试工作、测试过程、测试所需的时间和资源，以及测试风险等做出预先的计划和安排。,3测试设计规格说明 用于每个测试等级，以指定测试集的体系结构和覆盖跟踪。,4软件测试

6、用例规格说明文档 用于描述测试用例。,5测试规程 用于指定执行一个测试用例集的步骤。 6测试日志 由于记录测试的执行情况不同，可根据需要选用。,7软件缺陷报告 用来描述出现在测试过程或软件中的异常情况，这些异常情况可能存在于需求、设计、代码、文档或测试用例中。 8测试总结报告 用于报告某个测试完成情况。,6.3 软件测试计划,测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。 实现全生命周期测试，测试管理的基础。,6.3.1 制定测试计划的目的 1使软件测试工作进行更顺利 （考虑和计划测试采用的模式、方法、步骤、

7、问题和风险等） 2促进项目参加人员彼此的沟通 （测试人员间，测试人员与产品开发小组） 3使软件测试工作更易于管理 （两种重要管理方式：工作分解结构WBS，监督和控制）,6.3.2 制定测试计划的原则 制定测试计划是软件测试中最有挑战性的一个工作。以下原则将有助于制定测试计划工作。 1制定测试计划应尽早开始 2保持测试计划的灵活性 3保持测试计划简洁和易读 4尽量争取多渠道评审测试计划 5计算测试计划的投入（1/3工作量）,6.3.3 制定测试计划时面对的问题 制定测试计划时，测试人员可能面对以下问题，必须认真对待，并妥善予以处理。 1与开发者意见不一致 2缺乏测试工具 3培训不够,4管理部门缺

8、乏对测试工作的理解和支持 5缺乏用户的参与 6测试时间不足 7过分依赖测试人员 8测试人员处于进退两难的状态 9不得不说“不” （进度和费用）,6.3.4 制定测试计划 制定测试计划时，由于各软件公司的背景不同，测试计划文档也略有差异。实践表明，制定测试计划时，使用正规化文档通常比较好。,根据IEEE8291998软件测试文档编制标准的建议，测试计划包含了16个大纲要项，简要说明如下。 1测试计划标识符 一个测试计划标识符是一个由公司生成的惟一值，它用于标识测试计划的版本、等级，以及与该测试计划相关的软件版本。,2介绍 在测试计划的介绍部分主要是测试软件基本情况的介绍和测试范围的概括性描述(包

9、含哪些阶段的测试)。,3测试项 测试项部分主要是纲领性描述在测试范围内对哪些具体内容进行测试，确定一个包含所有测试项在内的一览表。具体要点如下。 功能的测试 设计的测试 整体测试 （数据流）,IEEE标准中指出，可以参考下面的文档来完成测试项： 需求规格说明 用户指南 操作指南 安装指南 与测试项相关的事件报告,4需要测试的功能 测试计划中这一部分列出了待测的功能。 （用户的角度） VS 测试项 （开发者或程序管理者的角度） 5方法（策略） 这部分内容是测试计划的核心所在，所以有些软件公司更愿意将其标记为“策略”，而不是“方法”。,测试策略主要描述如何进行测试，以及解释测试成功与否起决定左右的

10、所有相关问题。 测试策略描述测试小组用于测试整体和每个阶段的方法。,6不需要测试的功能 测试计划中这一部分列出了不需要测试的功能，具有相对低的风险。 当测试落后于进度表时： 需要测试的功能 - 不需要测试的功能,7测试项通过/失败的标准 测试计划中这一部分给出了“测试项”中描述的每一个测试项通过/失败的标准，由通过/失败的测试用例，缺陷数量、类型、严重性和位置，可靠性或稳定性等来描述。,下面是通过/失败的标准的一些例子： 通过测试用例所占的百分比； 缺陷的数量、严重程度和分布情况； 测试用例覆盖； 用户测试的成功结论； 文档的完整性； 性能标准。,8测试中断和恢复的规定 常用的测试中断标准如下

11、： 关键路径上的未完成任务 大量的缺陷 严重的缺陷 不完整的测试环境 资源短缺 恢复测试：重新设计、修改错误、替代等,9测试完成所提交的材料 测试完成所提交的材料包含了测试工作开发设计的所有文档、工具等。 例如，测试计划、测试设计规格说明、测试用例、测试日志、测试数据、自定义工具、测试缺陷报告和测试总结报告等。,10测试任务 测试计划中这一部分给出了测试工作所需完成的一系列任务。在这里还列举了所有任务之间的依赖关系和可能需要的特殊技能。 通常与“测试人员的工作分配”一起描述,11环境需求 环境需求是确定实现测试策略必备条件的过程。 例如： 人员 设备 办公室和实验室空间 软件 其他资源,12测

12、试人员的工作职责 测试人员的工作职责是明确指出了测试任务和测试人员的工作责任。 有时测试需要定义的任务类型不容易分清。复杂的任务可能有多个执行者，或者由多人共同负责。 利用表格来组织测试人员的工作职责P141,13人员安排与培训需求 人员安排与培训需求是指明确测试人员具体负责软件测试的哪些部分、哪些可测试性能，以及他们需要掌握的技能等。实际责任表会更加详细，确保软件的每一部分都有人进行测试。 P142 测试人员任务分配表,14进度表 测试进度是围绕着包含在项目计划中的主要事件（如文档、模块的交付日期，接口的可用性等）来构造的。 作为测试计划的一部分，完成测试进度计划安排，可以为项目管理员提供信

13、息，以便更好地安排整个项目的进度。 进度危机 表6-3 固定日期,表6-4 相对日期，摆脱进度危机,15潜在的问题和风险 软件测试人员要明确地指出计划过程中的风险，并与测试管理员和项目管理员交换意见。 这些风险应该在测试计划中明确指出，在进度中予以考虑。 尽早明确指出，以免在项目晚期发现时感到惊慌。,勾画出风险的轮廓，将有助于测试人员排定待测试项的优先顺序，并且有助于集中精力去关注那些极有可能发生失效的领域。, 不现实的交付日期 与其他系统的接口 处理巨额现金的特征 极其复杂的软件 有过缺陷历史的模块 发生过许多或者复杂变更的模块 安全性、性能和可靠性问题 难于变更或测试的特征,16审批 审批

14、人应该是有权宣布已经为转入下一个阶段做好准备的某个人或某几个人。 审批人除了在适当的位置签署自己的名字和日期外，还应该签署表明他们是否建议通过评审的意见。,6.4 测试的组织与人员管理,6.4.1 测试的组织与人员管理概述 测试项目成功完成的关键因素之一就是要有高素质的软件测试人员，并将他们有效地组织起来，分工合作，形成一支精干的队伍，使他们发挥出最大的工作效率。,“人”的重要性：关键资源，难以管理 测试的组织与人员管理就是对测试项目相关人员在组织形式、人员组成与职责方面所做的规划和安排。,测试的组织与人员管理的任务是： （1）为测试项目选择合适的组织结构模式； （2）确定项目组内部的组织形式

15、； （3）合理配备人员，明确分工和责任； （4）对项目成员的思想、心理和行为进行有效地管理，充分发挥他们的主观能动性，密切配合实现项目的目标。,测试的组织与人员管理应注意的原则是： （1）尽快落实责任 测试的准备工作在分析和设计阶段就开始了，在软件项目的开始就要尽早指定专人负责，让他有权去落实与测试有关的各项事宜。,（2）减少接口 要尽可能地减少项目组内人与人之间的层次关系，缩短通信的路径，方便人员之间的沟通，提高工作效率。 （3）责任明确、均衡 项目组成员都必须明确自己在项目组中的地位、角色和职责，各成员所负的责任不应比委任的权力大，反之亦然。,6.4.2 测试人员的组织结构 组织结构是指用

16、一定的模式对责任、权威和关系进行安排，直至通过这种结构发挥功能。测试组织结构设计时主要考虑以下因素。 垂直还是平缓 集中还是分散 分级还是分散 专业人员还是工作人员 功能还是项目,选择合理高效的测试组织结构方案的准则是： （1）提供软件测试的快速决策能力； （2）利于合作，尤其是产品开发与测试开发之间的合作； （3）能够独立、规范、不带偏见地运作并具有精干的人员配置；,（4）有利于满足软件测试与质量管理的关系； （5）有利于满足软件测试过程管理要求； （6）有利于为测试技术提供专有技术； （7）充分利用现有测试资源，特别是人； （8）对测试者的职业道德和事业产生积极的影响。,进行软件测试的测试

17、组织结构形式很多， 目前常见的测试组织结构有独立的测试小组和集成的测试小组两种形式。,1独立测试小组 独立的测试小组，即主要工作是进行测试的小组，他们专门从事软件的测试工作。 测试组长与开发组长在项目中的地位是同级、平等的关系。 优势：客观地对待被测软件 劣势：如何尽早开始工作，排除开发设计人员的阻碍,2集成测试小组 集成测试小组是由需要向同一个项目经理汇报工作的测试人员和开发人员组成。 可以减少开发人员与测试人员合作时的不利因素。,6.4.3 测试人员 测试人员的能力应包括以下几项。 （1）一般能力 （2）测试技能及方法 （3）测试规划能力 （4）测试执行能力 （5）测试分析、报告和改进能力

18、,测试组织管理者的工作能力在很大程度上决定测试工作的成功与否，测试组织的管理者必须具备： （1）了解与评价软件测试政策、标准、过程、工具、培训和度量的能力； （2）领导一个测试组织的能力； （3）吸引并留住杰出测试专业人才的能力； （4）领导、沟通、支持和控制的能力； （5）有提出解决问题方案的能力； （6）测试时间、质量和成本控制的能力。,6.4.4 人员的通信方式 （1）正式非个人方式，如正式会议等； （2）正式个人之间交流，如成员之间的正式讨论等（一般不形成决议）； （3）非正式个人之间交流，如个人之间的自由交流等； （4）电子通信，如E-mail、BBS等； （5）成员网络，如成员与小

19、组之外或公司之外有经验的相关人员进行交流； （5）的通信效率最高，其次是（1）。,6.4.5 测试人员管理的激励机制 测试人员管理的激励机制的关键点是： 管理者习惯用对自己有效的因素激励测试人员，很可能发现无效； 过多行使权力、资金或处罚手段很可能导致项目失败； 注意采取卓有成效的非货币形式的激励措施； 在项目进行过程中，而不仅是在项目结果时实施激励措施；, 奖励应该在工作获得认同后尽快兑现； 对项目成员的工作表现出真诚的兴趣，是对他们最好的奖励； 已经满足的需要很可能不再成为激励因素。 激励因素是影响个人行为的东西，是因人而异、因时而异的。因此，管理者必须明确各种激励的方式，并合理使用。,测

20、试工件的7条效率原则是： 主动思考，积极行动； 一开始就牢记目标，不迷失方向； 重要的事情放在首位（但常常把紧急的事情放在首位）； 先理解人，后被人理解； 寻求双赢； 互相合作，追求1+12； 终生学习，自我更新，不断进步。,6.4.6 测试人员的培训 1软件测试培训内容 2制定测试人员培训计划,6.4.7 测试的组织与人员管理中的风险管理 在进行测试的组织与人员管理时，我们往往重视招聘、培训、考评、薪资等各个具体内容的操作，而忽视了其中的风险管理问题。 高新技术企业，对人的依赖更大。,6.5 软件测试过程管理,6.5.1 测试项目的跟踪与监控 6.5.2 测试的配置管理 6.5.3 软件测试

21、风险管理 6.5.4 软件测试成本管理,6.5 软件测试过程管理,6.5.1 测试项目的跟踪与监控 软件的测试过程管理基于广泛采用的“V”模型。“V”模型支持系统测试周期的任何阶段。,对软件测试过程进行跟踪、检查，并与测试计划进行对比。测试计划经批准生效后，将被用来作为对测试过程跟踪与监控的依据。 测试项目的跟踪与监控的基础是软件测试计划。,主要方法：选取测试的某个时刻，比较实际测试工作的工作量、投入、成本、进度、风险等与计划的差距。 纠正措施： 修改测试计划以反映实际进度， 重新计划剩余部分工作的实施， 采取相应提高效率的措施。,在具体的测试项目的跟踪与监控过程中，可以采用周报、日报、例会，

22、以及里程碑评审会等方式来了解测试项目的进展情况，建立、收集和分析项目的实际状态数据，对项目进行跟踪与监控，达到项目管理的目的。,6.5.2 软件测试风险管理 1风险的基本概念 风险可定义为“伤害、损坏或损失的可能性；一种危险的可能或一种冒险事件。” 风险涉及到一个事件发生的可能性，涉及到该事件产生的不良后果或影响。,软件风险是指开发不成功引起损失的可能性，这种不成功事件会导致公司商业上的失败。 在软件测试中，不可能对系统的所有方面进行测试，会存在用户发现缺陷的可能性，称为测试风险。,测试计划模板中：风险与应对措施 测试风险的基本特征：p20 图3-1 通过风险分析，测试人员识别软件中高风险的部

23、分，并进行严格彻底地测试；确定潜在的隐患软件构件，对其进行重点测试。 （涉及测试资源的分配）,2软件风险分类 不同类型的测试项目有不同的风险。 相同类型的项目，测试风险也各不相同，取决于：测试环境、客户、项目团队、采用的技术和工具等 。 分为技术风险和管理风险。,技术风险： 新的技术 学习曲线 需求变更和描述不清 第三方代码 系统复杂度 ,3软件风险识别 是测试风险管理的第一步，最重要的基础。 采用的方法：头脑风暴法 访谈 风险检查表,4软件风险分析 风险分析的目标： 确定测试对象 测试的优先级 测试的深度 确定不予测试的对象,人员：开发人员、测试人员、用户、客户、销售人员和其他人员。 风险分

24、析应该尽早开始，在需求确定后就可以马上进行。 对发生变动的部分应进行风险的再次评审。 在测试项目进行的过程中，实时对风险分析结果进行评审。,风险分析的过程： （1）确定测试范围的功能点和性能属性 （2）确定测试风险发生的可能 （3）确定测试风险发生后产生的影响程度 （4）计算测试风险优先级 （5）确定测试风险的优先级 （分割线）,通常风险分析采用两种方法：表格分析法和矩阵分析法。通用的风险分析表包括以下几项内容。 （1）风险标识：表示风险事件的惟一标识； （2）风险问题：风险问题发生现象的简单描述； （3）发生可能性：风险发生可能性的级别（110）；,（4）影响的严重性：风险影响的严重性的级别

25、（110）； （5）风险预测值：风险发生可能性与风险影响的严重性的乘积； （6）风险优先级：风险预测值从高向低的排序。,表格分析法的风险优先级：风险预测值，即可能性与严重性的乘积从高向低的排序 矩阵分析法的风险优先级：风险可能性与严重性的等级值之和，存在5个风险等级 高(1) 中(2) 低(3) 确定测试风险的优先级 （分割线）,5软件计划风险的应对措施 测试计划的风险一般指测试进度滞后或出现非计划事件，就是针对计划好的测试工作造成消极影响的所有因素。 常见的计划风险包括：交付日期、测试需求、测试范围、测试资源、测试环境、测试工具等。,计划风险分析的工作重点是提前制定计划风险发生时应采取的应急措施。 可能采用的应急措施有：缩小范围、推迟实现、增加资源、减少质量过程等措施。,软件风险分析和测试计划风险分析与应急措施是相辅相成的。 软件风险、计划风险、重点测试、不测试，甚至整个软件的测试与应急措施都是围绕“用风险来确定测试工作优先级”这样的原则来构造的。,6.5.3 软件测试的成本管理 对于一般项目，项目的成本主要由项目直接成本、管理费用和期间费用等构成。,1测试费用有效性 确定了软件存在的缺陷是否可以接受