BUG的提交与管理

BUG的提交与管理什么是bug•Bug按照英文直译过来叫“虫子”。任何事物都不是完美的，何况是需要被测测试的物体。简单的来说，bug就是事物的缺陷。现实生活中充满了bug：人生病了，我们可以理解为有了bug；汽车抛锚了，我们可以理解为出了bug，电脑死机了，更是一个bug。如何判断Bug•但不是所有的问题都是bug。严格来说，是产品在规定范围或正常操作下出现的错误，才能称为bug。如前面提到的汽车抛锚了，如果是因为汽车使用年限超过了应该的年限，或者是司机的错误操作，都不能称为bug。下面是一个bug举例：•WindowsXP支持的最大共享文件夹名长度为80个英文字母或40个汉字，但设置共享文件夹名时可输入的范围是80个英文字符或80个汉字，如果共享文件夹名在41～80个汉字之间，系统会提示该共享名包含无效的字符摂。•其实真正的原因是共享文件夹名超长。找Bug的目的•测试究竟是用来做什么的？bug又有什么用处？测试不是为了找bug这么简单，测试的目的是通过找bug来提高产品质量，提高产品开发流程，继而满足市场和客户的要求。没有bug的完美产品是不存在的，一轮接一轮的测试就是为了让产品更加稳定，让bug被限制到尽可能小的范围。测试的目的•测试目的仅仅是为了寻找bug和修复bug吗？•Bug的严重等级是对被测设备表现的一个评判。被测设备错误表现的严重性就决定了bug的严重等级。各家公司和机构对于严重等级的划分标准不一，但大体上可以按照下面的方式来定义：–Priority1•被测设备挂起或崩溃。•被测设备重启。•内存泄漏，系统配置丢失。Bug的严重等级–Priority2•功能或模块不工作,测试就结果或行为与预期不一致，且没有避开BUG的替代方法。•功能缺失。•系统性能与参考值相差太大。–Priority3•功能或模块不工作,测试就结果或行为与预期不一致，但有避开BUG的替代方法。•Bug的优先级别•Bug的优先级别是从客户需求角度来说的，用户认为重要的特性出了问题，哪怕只是小小的显示信息错误，也应该在第一时间解决。Bug的生命历程•Bug也是有生命的，从bug的发现，到bug的修复。就是一个bug的生命历程：N(ew)OpenthisBug?O(pen)R(esolve)Bugfixed?V(erify)测试人员提交bug报告J(Reject)开发人员修复bug测试人员验证bug是否修复开发人员，测试组长决定C(lose)NoNoYesYes2.如何找到更好更多的bugBug从那里来？•一个产品从设计到开发，凝聚了所有系统设计师，开发人员，设计人员，管理人员的心血。从另一个方面来讲，这些不同的环节和不同人的工作，却是导致bug的原因。举例来说，可能出现bug的情况有：–新特性的增加–对设计意图的错误理解–代码的反复修改–不严格的代码维护–开发人员的素质–紧张的开发进度–。。。。。。怎么找bug？•找bug决不是件简单的事情。一个高素质的测试人员应该做好一下的工作：–熟悉产品设计需求–熟悉标准协议规范–熟悉产品操作手册–熟悉测试工具仪器的使用–有丰富的测试经验当bug出现时•当我们在发现一个产品的问题时，怎么确定就是一个bug？这也不是个简单的问题，确定bug的过程称为bug定位。一般来说，可以按照一下几步来做：•排除非正确因素：需要排除的因素包括是否按照合理的测试步骤，是否在合理的测试场景，是否在产品规格范围内，等等。只有排除了这些正常因素，而被测设备依然会有不正常行为，才能初步定位为bug。•收集bug相关信息•Bug出现时，应该保存好设备的配置，测试仪器的配置，设备的日志，屏幕输出等等。这些要素都是分析bug，修复bug的重要参考。•寻找重现步骤•这是bug定位中的难点，特别对于多功能多模块的系统测试，bug产生的原因会很复杂，不是简单的表面现象就能找到重现条件。•寻求开发人员的帮助•Bug找到了以后需要开发人员的确认和修复，测试人员需要和开发人员一起确认bug的原因，帮助开发人员找到bug的根源。•报告bug•这时找到bug需要做的最后一步，通常会有专业的bug管理软件，如bugzilla，clearDDTS等等。•什么是高质量的bug？•找到了Bug的重现条件，从测试的角度来说，工作就完成了一大半。重现条件能够帮助开发人员更方便地定位，甚至开发人员会依赖于重现条件才能定位。找Bug的意义在于修复bug，不能重现的bug往往不能找到原因，更谈不上修复。分析Bug趋势图•Bug不是越多越好，在适当的时候发现适当数量和质量的bug才是产品经理所希望看到的。如何报告bug•在有些公司里，程序员几乎会把一半的测试bug返回给测试组，因为那些bug不可再现、发现bug同设计要求一致，或者bug报告根本无法操作。为了防止这类问题，要提交好的测试bug，作为一个好的测试人员，必须遵循以下步骤：•1)总结：简要描述客户或用户的质量体验和观察到的一些特征。•2)压缩：精简任何不必要的信息，特别是冗余的测试步骤。•3)去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。•4)中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。•5)评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在你提交测试报告或测试评估报告之前先自己读一遍。•好的测试bug描述是告诉读者测试人员发现了什么，而不是测试人员做了什么。因此只需要根据上述步骤写下最少的必需重现步骤如何提交bug•一个好的错误跟踪系统包括了错误的必要信息，如果做得不好，会造成迷惑，并误导读者。好的故障描述应该包括十个基本部分：标题、项目、所属模块、优先级、重要性、异常等级、可重复性、现象、操作过程和附件。标题•使用一两句话来描述错误，告诉经理、开发人员以及其他读者为什么应该关心该问题。好的标题应该着重于出现的bug现象。但是过于简洁易引起误导，使得原本重要的问题被忽视。因此必须应该采用简洁、切中要害的概要，这样才能引起读者的重视。不重要的就描述比较轻微，例如：“联系人的email没有检查合法性”；重要的就要体现比较严重，例如：“填了运营商仍然提示运营商不能为空，使得无法进行下一步的操作”，会更容易让开发人员理解究竟是什么问题及其重要性，并及时处理。•②项目•是指该错误属于哪一个项目，归哪个项目组解决，使不同的项目组看到和及时定位自己项目的错误。•③所属模块•是指准确说明发异常等级生错误的模块，切忌发生错误指派模块，导致后续流程错误；•④优先级•分为以下4级：1级：“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求；2级：“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现；3级：“正常处理”，即进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的数据库等；4级：“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。•⑤重要性•分为以下5级：1级：“非常严重”，表示缺陷不修改整个系统流程不能继续；2级：“比较严重”，表示缺陷不修改不影响系统其他流程，但是本模块流程不能继续；3级：“一般”，表示缺陷不影响流程；4级：“轻微”，表示缺陷可以延期解决；5级：“优化”，表示修改以后流程会更好。•⑥异常等级•有以下5级：系统崩溃－指该错误使得操作系统死机等致命性的错误；应用程序崩溃－指该错误使得测试程序崩溃，即无任何反应；应用程序异常－指错误使得应用程序结果不符合逻辑或是最初的需求；轻微异常－指错误有，但是无伤大雅，例如错别字等；建议－指改进后更好，不改进也对程序无碍。•⑦可重复性•是针对问题是否通过执行“操作步骤”就可以重新出现，如果是就“可再现”；如果这个bug只出现了一次，就再也不出现了，称这类问题为“不可再现”；其余的就是“未知”，如每隔几天才出现一次；•⑧现象•是对标题的详细描述，因为标题不宜过长，所以现象也是对标题的具体化。•⑨操作过程•是指对于可重现的bug，执行这些操作步骤就可以出现该bug；对于不可重现和重现概率为未知的bug，通过备份的数据库和操作过程就可以重现该bug。•⑩附件•是粘贴必要的附件，如果是可重复性是“可重现”的bug，则可以参考步骤是否复杂，如果很复杂，则可以粘贴附件，从而使得开发人员直接可以明白是什么问题，提高开发人员的修改效率；如果步骤不多有能够重现，则可以不粘贴附件。如果可重复性是“不可再现”的，这种情况必须粘贴附件，以备份出现问题后的情形；如果是未知的，也必须粘贴附件，因为开发人员不可能把时间耗费在等待bug的重现上一个bug报告