全程软件测试(五十三):软件测试项目的进度管理—读书笔记(软件测试进度安排)

全程软件测试(五十三):软件测试项目的进度管理—读书笔记(软件测试进度安排)

项目的进度管理是一门艺术,是一个动态的过程,需要不断调度、协调,保证项目的均衡发展,实现项目整体的动态平衡。在项目进度的管理过程中,项目的实施与项目的计划是互动的。

项目开始前的计划对软件的测试需求有一个大体的认识,但深度不够,进度表可能只是一个时间上的框架,一定程度上是靠计划制订者的经验来把握的。随着时间的推移、测试的不断深入,相关人员对软件会有进一步的认识,对很多问题都不再停留在比较粗的估算上,项目进度表会变得越来越详细,越来越准确。

项目的进度管理主要通过里程碑、关键路径的控制并借助工具来实现,同时需要把握好进度与质量、成本的关系,以及充分了解进度的数量和质量双重特性。

软件测试项目的里程碑和关键路径

软件测试项目的计划书中都会有一个与软件测试项目明确相关的日程进度表。关于如何对项目进行阶段划分、如何控制进度、如何控制风险等,目前存在一系列方法,其中最成熟的技术是里程碑管理和关键路径的控制。

1.里程碑的定义和控制

一般来说,里程碑是项目中完成阶段性工作的标志,即对一个过程性的任务用一个结论性的标志来描述明确的任务起止点,一系列的起止点就构成引导整个项目进展的里程碑。一个里程碑标志着上一阶段的结束以及下一阶段的开始,即定义当前阶段完成的标准和下个新阶段启动的条件或前提。里程碑的特征表述如下。

(1)里程碑有一定层次,即可在父里程碑下定义子里程碑。

(2)不同类型的项目,里程碑可能不同。

(3)在不同规模的项目中,里程碑的数量是不一致的。里程碑可以合并或分解。

在软件测试周期中,建议定义六个父里程碑、十多个子里程碑,具体如下所示。

M1:需求分析和设计的审查

M11:市场/产品需求审查

M12:产品规格说明书审查

M13:产品和技术知识传递

M14:系统/程序设计审查

M2:测试计划和设计

M21:测试计划的制订

M22:测试计划的审查

M23:测试用例的设计

M24:测试用例的审查

M25:测试工具的设计和选择

M26:测试脚本的开发

M3:代码(包括单元测试)完成

M4:测试执行

M41:集成测试完成

M42:功能测试完成

M43:系统测试完成

M44:验收测试完成

M45:安装测试完成

M5:代码冻结

M6:测试结束

M61:为产品发布进行最后一轮测试

M62:编写测试和质量报告

你也可以调整子里程碑,并在子里程碑下定义更小的里程碑,即孙里程碑,如表1所示。

全程软件测试(五十三):软件测试项目的进度管理—读书笔记(软件测试进度安排)

表1 软件测试进度表示例

在一个里程碑到来之前,需要进行检查,了解测试状态以确定是否能在预期时间内达到里程碑阶段标准,若存在较大差距,则需要采取相应措施,争取在预期时间内达到里程碑的标准,即使不能,也需要尽量减小差距。每到一个里程碑,对实际完成情况必须严格检查,查看是否符合已定义的标准,并且应及时对前一阶段的测试工作进行总结;若有需要,则可对后续测试工作计划进行调整,例如,增加资源,延长时间,以实现下一个里程碑的目标。

在项目管理进度跟踪的过程中,给予里程碑事件足够的重视,往往可以起到事半功倍的作用。保证里程碑事件的按时完成,整个项目的进度就有了初步保障。根据里程碑可较为容易地确定软件测试进度表。

2.项目的关键路径

每个项目可根据各项任务的工作量估计、资源条件限制和日程安排,事先确定一条关键路径。关键路径是一系列能确定计算出完成日期的任务构成的日程安排线索。当关键路径上的最后一个任务完成时,整个项目也随之完成;关键路径上的任何一项任务延迟,整个项目就会延期。为了确保项目如期完成,应密切关注关键路径上的任务和为其分配的资源,上述要素将决定项目能否准时完成。

关键路径法(Critical Path Method,CPM)是国际公认的项目进度管理办法,其计算方法简单,许多项目管理工具(如Microsoft Project)可自动计算关键路径。随着项目的实施,关键路径可能由于当前关键路径上的某些任务发生变化(延迟)而变化,从而产生新的关键路径,因此,关键路径也是动态可变的,但这种动态性需要控制在最小范围内。关键路径的这种变化可能导致原来不在关键路径上的任务成为关键路径的必经节点,因此,测试组长或项目经理需要随时关注项目进展,跟踪项目的最新计划,确保关键路径上的任务及时完成。

软件测试项目进度的特性及外在关系

任何一项工作,在最开始的时候较为容易看到工作推进的进度,例如,建造房子,从无到有变化非常明显,但随着时间的推移,房子框架搭建起来之后,所能观察到的进度就越来越不明显。软件测试也是如此,在测试之初,缺陷较为容易发现,但测试的进展并不是按照缺陷数量来计算的,测试越进行到后期,缺陷就越难发现。因此,若要提高测试质量,需要将严重的、关键的问题尽可能地在第一时间发现,如此才不至于在最后阶段使开发人员对代码进行大规模的修改。若大规模修改代码,则无法保证测试的时间,最终会影响软件的质量。上述内容就是测试项目进度的数量和质量双重特性,在关注进度的同时需要把握好这两个特性,在注重速度的同时,还需要观察前期的质量。如图1所示。

图1表示一个为期10天的测试项目,在项目中测试工程师实际发现了60个缺陷,其缺陷数量的日期(横坐标)分布呈渐渐回落之势,即一开始发现的缺陷最多,随着时间的推移,发现的缺陷越来越少,最后2~3天不再报告新的缺陷,而只是验证已被修正的缺陷。在理想情况下,问题的难度也应呈降序排列,前期发现最不易解决的问题,因为在解决这些问题时,往往会产生新的缺陷,及早报告,有利于更好地解决问题。当然,在做具体项目时,不容易保证完全做到理想状态,这与测试工程师本身的技能和经验有很大关系。

全程软件测试(五十三):软件测试项目的进度管理—读书笔记(软件测试进度安排)

图1 测试项目进度的特性图

1.进度与质量的关系

测试项目管理的基本原则是保证在不超预算并满足软件质量的前提下,按进度完成项目。因此,进度与质量存在一定程度上的矛盾关系:有时要想保证质量,进度就必须放慢,使测试时间充足;有时要想保证进度,质量就受到一定影响或存在比较大的风险。质量与进度的关系应该是保证质量为前提,然后考虑资源的调度和进度的调整。

首先,尽量利用历史数据,参考以前完成过的项目来进行类比分析,以确定质量和进度之间的制约关系,进而控制进度和管理质量。

其次,可采用对进度管理计划添加质量参数的方法,即通过调整参数来调整进度和质量的关系(此方法需要有一定量的历史数据)。例如,从历史数据中得知,若完成子项目的时间是5天,测试后遗留15个问题;若完成同样子项目的时间是7天,测试后遗留12个问题;若完成该子项目的时间是8天,测试后遗留5个问题;……。

随着数据的不断增多,采用二维坐标图,即可得到一些离散的点(不考虑资源的差异),并形成一条曲线,如图2所示。管理者可考虑项目允许的质量范围,对照图中的数据,找出相应的参数;根据得到的参数,确定一个合适的进度计划

全程软件测试(五十三):软件测试项目的进度管理—读书笔记(软件测试进度安排)

图2 通过参数调整进度和质量的关系

2.进度与成本的关系

在项目管理水平不够高的情况下,经常出现进度拖延,成本(人力资源×时间)居高不下的情况,此时需要提高测试项目中进度与成本关系的控制水平。软件测试项目受规格说明书修改、设计修改、代码修改等影响比较大,一旦在某些地方进行简单修改,可能开发只要花很少的时间人力资源,但测试由于得不到足够信息或过多采用黑盒测试方法,成本会大幅上升。

另外需要注意的一点是要对学习曲线有深刻的认识。在软件开发过程中,学习曲线可以起到很大的作用,通常情况下,在开发与上一个相似或同类型的新软件时,会比上一次节省15%~20%的时间。

软件测试项目进度的管理方法和工具

软件测试管理中最重要、最基本的是测试进度跟踪。众所周知,在进度压力之下,通常被压缩的是测试时间,这导致随着时间的推移,实际的进度与最初制订的计划相差越来越远。而若有了正式的度量方法,上述情况就不容易出现,因为在其出现之前相关人员就有可能采取行动解决问题。下面介绍两种测试项目进度的管理方法,分别是测试进度S曲线法和缺陷跟踪曲线法。缺陷跟踪又可分为新发现缺陷跟踪法和累计缺陷跟踪法,其中累计缺陷跟踪法更好。常用的缺陷跟踪曲线法是NOB(Number of Open Bug,打开的缺陷数)曲线法。

1.测试进度S曲线法

测试进度S曲线法通过将计划中的进度、尝试的进度与实际的进度三者进行对比来实现,其采用的基本数据主要是测试用例或测试点的数量,这些数据需要按周统计,每周统计一次,并将统计数据反映在图表中。“S”代表随着时间的推移,积累的数据形成的曲线越来越像S形。一般的测试过程包含三个阶段,初始阶段、紧张阶段和成熟阶段,第一和第三个阶段所执行的测试数量(强度)远小于中间的第二个阶段,由此导致曲线的形状像一个扁扁的S。

x轴代表时间,y轴代表当前累计的测试用例或测试点数量,如图3所示。

全程软件测试(五十三):软件测试项目的进度管理—读书笔记(软件测试进度安排)

图3 计划中的、尝试的与实际进度曲线图

图3包含了如下信息。

(1)趋势曲线(上方实线)代表计划中的测试用例数量,该曲线是在形成测试计划后,在实际测试执行之前绘制的。

(2)测试开始时,图上只有计划曲线。此后,每周添加两条柱状数据,浅色柱状数据代表当前周累计尝试执行的测试用例数,深色柱状数据为当前周累计实际执行的测试用例数。

(3)在测试快速增长期(紧张阶段),尝试执行的测试用例数略低于计划用例数,实际执行的用例数略高于尝试执行的用例数,此情况是经常出现的。

由于测试用例的重要程度不同,因此,在实际测试中经常会给测试用例加上权重。加权归一化使S曲线更加准确地反映测试进度(如此y轴数据就是测试用例的加权数量),加权后的测试用例通常被称为测试点。

一旦有一个严格的计划曲线放在项目组面前,它将成为奋斗的动力,整个小组都将关注计划、尝试与实际之间的偏差。因此,严格的评估是S曲线成功的基本保证,例如,人力是否足够,测试用例之间是否存在相关性。一般而言,计划或者尝试数与实际执行数之间存在15%~20%的偏差就需要启动应急行动进行弥补。

一旦计划曲线被设定,任何对计划的变更都必须经过审查。一般而言,最初的计划应作为基准,即使计划有变更,基准也留作参考。该曲线与后来的计划曲线对比显现的不同之处需要有详尽的理由作为说明,同时这也是今后制订计划的经验来源之一。

2.测试进度NOB曲线法

测试所发现的软件缺陷数量,会在一定程度上代表软件的质量,通过对它的跟踪来控制进度也是一种比较现实的方法,受到测试过程管理人员的高度重视。NOB曲线法主要收集当前所有打开的(激活的)缺陷数,也可将严重级别高的缺陷分离出来进行控制,从而形成 NOB 曲线。NOB曲线在一定程度上反映了软件的质量和测试的进度。

在 NOB 曲线法中,最重要的是确定基线数据或典型数据,即为测试进度设计一套计划曲线或理想曲线。至少在跟踪开始时,需将项目进度关键点(里程碑)预期的NOB 限制等级设置好,以及确定 NOB达到高峰的时间、NOB在测试产品发布前能否降到足够低。较为理想的模式是,相对于先前发布的版本或基线,NOB曲线的高峰出现得更早,且在发布前降到足够低并稳定下来。需要提醒的是,在这种度量方法中仅注意数量是不够的,为了尽早达到系统的稳定,缺陷的类型和优先级都是必须关注的。

尽管 NOB应该一直都被控制在合理的范围内,但功能测试的进展是最主要的开发事件时,应关注测试的有效性和测试的执行,并在最大程度上鼓励缺陷的发现。过早地关注NOB减少,将导致目标冲突,导致潜在的缺陷遗漏或缺陷发现的延迟。因此,在测试紧张阶段,主要应关注阻碍测试进展的那些关键缺陷的修复。当然,在测试接近完成时,就应强烈关注 NOB的减少,因为 NOB曲线的后半部分尤为重要,与质量问题密切相关。如图4所示。

全程软件测试(五十三):软件测试项目的进度管理—读书笔记(软件测试进度安排)

图4 NOB进度曲线示意图

Myers 有一个著名的关于软件测试的反直觉原则:在测试中发现缺陷多的地方,还将发现更多的缺陷。此现象产生的原因是,若测试效率没有被显著改善,则在修复缺陷时,将引入更多的缺陷。对这种度量方法的诠释如下。

(1)若缺陷发生率与先前发布的版本(或模板)相同或更低,应考虑当前版本的测试是否低效或根本未起到任何作用。若不是,则质量的前景还是较为乐观的;若是,则需要进行额外的测试。除了需要对当前的项目采取措施,还需要对开发和测试的过程进行改善。

(2)若缺陷发生率比先前发布的版本(或模板)更高,则应考虑是否为提高测试效率做了计划,并实际已做到显著提高测试效率。若没有,则质量将得不到保证;若有,质量将得到保证或可以说质量的前景是很乐观的。

上述度量法经常用于特定测试中缺陷的度量,如功能测试、产品级测试、系统集成测试。

3.测试进度管理工具

“工欲善其事,必先利其器”。要做好项目管理,首先需要一个可规划、跟踪、控制和改进项目管理的工具。微软公司推出的 Microsoft Project 就是一个常用的、专业的项目管理工具,提供了项目管理所需的基本功能,可细致地反映项目进行的整个过程,便于跟踪项目的进展、项目的分工等。它把一个任务划分为比较基准计划(原始计划)、当前计划、实际计划和待执行计划(剩余计划或未完成计划)4个阶段进行管理。

(1)比较基准计划(原始计划):此处的计划数据记录了最初制订项目计划时项目的状态。由于项目一旦开始运作执行,项目计划总是处于动态变化中,因此为了评价计划的实施情况或计划本身设计的问题,需要随时可获得原始计划数据。Microsoft Project把最初编制的计划作为“比较基准”存储起来,在项目调整过程中始终保持不变。

(2)当前计划(正在进行):项目启动后,由于主观或客观的原因,计划总是处在变化中,因此,需要反映项目实际执行情况的计划。由于当前计划是根据实际已经发生的计划和任务间的制约关系计算的,因此对于项目计划的管理和预测都具有现实指导意义。

(3)实际计划(已完成的):指那些未完成但已开始实施,或已全部完成的任务计划。已实际执行的计划在项目管理中的重要性有两点:一,它是计算项目产值的依据;二,它也是规划和预测当前和未来计划的基本信息。

(4)待执行计划(未完成的):项目组不仅需要考虑已完成的任务量,还必须知道剩余的需要完成的工作量,即待执行计划。若一个任务已经开始但还未做完,系统将根据任务完成情况自动计算剩余工作量,并重新测算工期和成本。

对于时刻处在变化之中的项目计划来说,人工统计资源在整个项目中的分布是一件非常烦琐的事情,Microsoft Project提供的“资源使用状态”视图,逐个列出资源承担的任务和在每个任务上工作的日期、人数、工作量、费用,以及累计工作量和累计费用等,从多角度以丰富的图表来描述测试进度。

(1)网络图:以描述任务关系为重点,可选择任意5种任务信息进行显示。通过选择不同类别的信息,可建立基本信息网络图、基线网络图、跟踪网络图、费用网络图等。

(2)横道图:以表述任务时间关系为重点,显示出工序的关系线,即每个任务的开始、结束时间,而且能够显示任务的紧前和紧后工序。横道图可将每个任务的基线计划、当前计划、实际计划、完成百分比、时差同时显示出来,便于进行综合分析。

(3)资源图:以反映资源使用状况为重点,为资源分析和跟踪提供了8种图形,即资源需求曲线图、资源工作量图、资源累计工作量图、超分配工作量图、资源已经分配的百分数图、资源当前可用工作量图、成本图、累计费用图等。

(4)Microsoft Project内置了多种筛选器,帮助建立各种文字报告,内容覆盖面广,可直接使用。

(5)项目摘要报告:项目汇总报告。

(6)任务报告:未开始的、正在进行的、已经完成的、推迟开始的、马上开始的、进度拖后的等各种任务报告,还包括关键任务的、使用某种资源的、超出预算的、本周/月/季的等各种任务报告及任务基本信息报告。

(7)资源报告:预算报告;超强度分配、超出预算等资源报告;资源工作安排报告;工作量报告;周/月/季/年现金流报告;资源基本信息报告。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022年10月28日 上午8:08
下一篇 2022年10月28日 上午8:10

相关推荐