总是很难忘记生活的点点滴滴, 脑海中总是闪过好多的曾经, 美好的回忆, 但成长中却让我们失去了很多, 很想在忙碌的生活中淡淡忘记; 不曾放低的东西却始终让我忘记不了, 但我还要在忙碌的生活中继续生活!

【转载】巧破软件测试缺陷管理之痛

上一篇 / 下一篇  2008-09-04 17:31:20 / 个人分类:转载好东西

人世间最痛苦的事莫过于——我所在项目开发正陷于混乱不堪的缺陷之中。因为缺乏一套缺陷管理的有效解决方案,使程序的缺陷无法回溯,无法跟踪,解决没解决不清楚,整一个就是一片模糊。

  由于没有得到足够的重视,软件缺陷管理处于失控状态。软件测试人员报告的缺陷常常被遗忘掉;或没有人知道在新的软件版本里究竟纠正了哪些缺陷,还有哪些缺陷未被纠正。更重要的是纠正过程是否引入了新的缺陷也没有人知道,再或者就是缺陷报告书写不规范,使得开发人员不得不一次次找到测试人员来面谈,还有许多无效的文档使缺陷状态混乱,相关人员无法及时获得有关的变更信息。

  什么是开发的缺陷管理?

  软件中的缺陷(Defect或BUG)是软件开发过程中的“副产品”。通常,缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件开发团队都必须知道如何妥善处理软件中的缺陷,这关系到软件生存、发展的质量根本。可遗憾的是,并非所有的软件开发团队都知道如何有效地管理软件中的缺陷。

  软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动。狭义地讲,BUG是写程序过程中造成的错误。广义地讲,BUG是影响客户正常使用的任何问题。就是说,BUG不仅仅是编程中出现的问题,还包括客户需求和功能规范等方面。

  (1)缺陷管理的目标

  一般而言,缺陷的跟踪和管理需要达到以下两个目标:一是确保每个被发现的缺陷都能够被解决,二是收集缺陷数据并根据缺陷趋势曲线识别和预防缺陷的频繁发生。

  在谈到缺陷管理时,一般人都会只想到如何修正缺陷,而对根据缺陷分析进行有效预防缺陷却很容易忽视。其实,在一个运行良好的项目开发中,缺陷数据的收集和分析是很重要的,从缺陷数据中可以得到很多与软件质量相关的数据。例如通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。常见的的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。

  (2)缺陷管理重在预防缺陷

  正如我们所知,BUG应该尽早地在开发过程中被发现。修正处于开发阶段的BUG的成本远远低于修正处于验收阶段的BUG,而相对与修正已经发布给客户的产品BUG的成本更是可以忽略不计。因此,越晚修正BUG,需要重做的事情就越多。

  对很多人来说,零缺陷的软件产品似乎是不切实际的。因此,我们总是听到许多软件开发人员说:“软件永远有BUG”。软件产品含有BUG并不奇怪,不幸的是发布一个包含很多BUG的产品给客户仍然不让人感到惊讶,这就是一件值提深思的事情了。

  事实上,每个软件开发团队都可以通过一些简单的方法,在不增加额外资源的情况下预防BUG。为了能够预防BUG,我们首先需要了解BUG的来源。软件BUG可以分为几个类别:第一类BUG可能是随机的,它们通常是因为一时的疏忽造成的。尽管这些BUG可能由于其随机性很难预防。但是,适当的分析将有助于避免这些BUG。另一类的BUG来自于需求误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术,这类BUG共同的特点是都来自于开发人员。

  但有一个好消息是,软件中的BUG往往倾向于重复出现,即使是一个随机出现的BUG。软件BUG的不断出现不仅表现在同一个开发人员的工作上,而且表现在同一个项目上。这当然不是说项目中的每一个开发人员都会犯同样的错误。但是,至少其中一些的错误足以成为经常性出现的问题。因此,BUG的预防尤为重要。

  缺陷管理的核心:缺陷分析

  缺陷预防的着眼点在于缺陷的共性原因(Common Cause)。通过寻找、分析和处理缺陷的共性原因,实现缺陷预防。BUG预防并不是一个不切实际的目标,但是不能期望它在一夜之间发生。我们在开发过程中应该积极为开发小组提供缺陷分析,使BUG逐渐改善。因此,缺陷管理的最终目标是预防BUG,不断提高整个开发团队的技能和实践经验,而不只是修正它们。

  BUG预防策略非常简单和容易实现,策略是发现BUG,找出BUG的根源,然后寻找一个方法来预防类似的BUG在将来出现。这策略并不需要昂贵的花费,但是却可带来极大的额外价值。

  (1)BUG记录

  BUG分析的第一步是记录BUG,值得注意的是记录BUG不应该满足于记录BUG的表面症状。测试的一个重要职责就是试图发现BUG的根本原因,在测试时不应将产品看作一个黑盒,而应该像开发人员那样了解产品的内在,包括深入源代码,理解产品的设计和实现。

  (2)利用BUG分析了解开发质量趋势

  对于测试出来的BUG进行缺陷分类,找出那些关键的缺陷类型,进一步分析其产生的根源,从而针对性的制定改进措施。缺陷分析非常关键的一步就是寻找一个预防类似缺陷再次发生的方法。这一方法不仅涉及到开发、测试人员,还涉及到不直接负责代码编写的资深开发人员。利用这一阶段的实践成果,开发人员可以预防BUG的发生,而不仅仅是修正这些BUG。

  BUG预防分析是整个BUG分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性,分析某个具体BUG的投入将很容易被收回。在这个时候,BUG分析提供了两个非常重要的参数,一个是缺陷数量的趋势,另一个是缺陷修复的趋势。缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。

一般在项目的开始阶段发现缺陷数曲线会呈上升趋势,到项目中后期被修复缺陷数曲线会趋于上升,而发现缺陷数曲线应总体趋于下降。同时处于OPEN状态的缺陷也应该总体呈下降趋势,到项目最后,三条曲线都趋向于零。项目经理可通过持续观察这张图表,确保项目开发健康发展。同时,通过分析预测项目测试缺陷趋于零的时间,以制定产品质量验收和发布的时间。

  实际上,BUG分析图表会告诉我们很多有价值的信息。比如说,可分析开发和测试在人力资源的配比上是否恰当,可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动,如本来应该越测试越收敛的,却到了某个点发现的故障数反而呈上升趋势,那么意味着往往有一些特殊事件的发生。通过对测试缺陷分析,能够给予我们很多改进研发和测试工作的信息。

  (3)发布BUG分析经验,提高团队成员能力

  分析得出来的BUG实践经验应该被记录并发布,这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库,这将使得新的知识在项目内流动并被相关的开发人员所学习。

  BUG分析带来了很多的好处。第一个好处就是帮助产生BUG的开发人员总结经验,并使他在将来避免类似的BUG。有时只修正一个具体的BUG而不去分析它产生的原因并不会帮助开发人员在日后得到提高,只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。

  从这个角度来看,BUG分析的价值不仅仅是缺陷的预防,更大的好处是通过记录和分析BUG,项目内的其他开发人员知道如何发现类似的错误。所以,我们可以通过某个开发人员产生的一个BUG提高整个项目团队的实践经验,而不仅仅是尽快修正它。这样,因为一个缺陷所浪费的时间也可以转化为收益:确保类似的错误不会再发生。除了分享项目内的测试知识和经验,BUG分析过程还可以促进开发更好的测试技术和工具,从而帮助发现类似的BUG。

  如何高效地进行缺陷管理

  (1)清晰缺陷分类,明确处理责任

  首先要改变以前那种凡是BUG就是由开发人员负责的观念。跟据缺陷内容可分为需求BUG与程序BUG。对于程序BUG是由相关开发人员进行处理,需求BUG则要交由需求人员进行处理,对于这种分法的好处就是明确了BUG处理的责任人。

  测试人员从本质上来说与程序员还是对立的,如果为了一个不是软件程序本身的问题形成与开发人员的对立,则会出现赢得战役而丢失整个战争的情况。测试人员协调好与开发人员的关系,可让他们更高效的关注软件本身的缺陷。

  (2)建立缺陷处理流程,减少无效运作

  建立缺陷处理流程,这对测试人员和开发人员来说都是很有帮助的。BUG处理流程其实就是定义BUG处理过程的职责和权限,用明确的流程去指导如何对BUG进行日常管理,提高运作效率。

  (3)使用缺陷管理工具:BUG管理库

  为了跟踪和控制测试质量,便于管理测试发现的BUG,我们需要为项目配置一个专用的缺陷跟踪数据库,以便报告、查询、分类、跟踪、处理和验证缺陷。因此,开发过程中使用一套BUG管理工具是非常必要。

  缺陷管理工具应便于项目组和管理人员获取正确、足够的信息,以简化信息共享流程,最大限度减少重复工作。BUG管理库就是记录、评估缺陷,并执行及维护系统配置,创造一个高效管理环境的最好工具。例如使用缺陷管理库可以很方便制作各种缺陷分析图表,从而预测项目风险或解释测试结果。整个开发过程是BUG数从少到多,再到少的过程。从BUG数量的变化,也可以推断软件产品的成熟性,推断产品的发布期。

  (4)把管理制度和配置策略相结合

  有了先进的缺陷管理工具,还需要有相应的管理制度与之相配套,否则BUG管理就只是一个摆设。目前BUG管理制度方面主要的问题是不重视测试,认为测试人员无关大局,随便测测就行了,再或者就是虽然认识到测试的重要性,但却走向了极端,制定了极其严格的规章制度。

  例如无数琐碎、难用的测试工单,非常严密的层级权力控制等。把一个需要灵活变化的工作变成了工业制造车间流水线的一个工种,让测试人员陷入制度的泥潭,不能把主要精力投入测试工作本身。再或者就是项目负责人也没有制订明确的BUG处理流程及相关指导原则,让测试人员在黑暗中摸索,走到哪儿算哪儿,不能给他们以切实有效的指导和帮助,把软件的质量保证责任一股脑推到测试人员身上,任何问题都去指责测试人员。

  最后,BUG管理制度还有一种常见的错误考核制度,就是项目主管用BUG个数去衡量测试人员的工作成绩,谁发现的BUG多谁的工作就做的好。这是一个十分危险的倾向,将直接导致测试人员去重视BUG个数这个数字本身、而不是产品的真正质量。最后重申强调一点:BUG不仅仅是被修正,更重要的是根据BUG管理来提高软件产品质量。


TAG: 测试管理 考核 转载好东西

 

评分:0

我来说两句

Open Toolbar