A项目组软件测试BUG管理策略研究.docx

软件质量管理与测试 软件测试项目管理A项目组软件测试BUG管理策略研究 摘要：在软件开发过程中测试作为其中重要的环节，对软件的质量有至关重要的作用，其中BUG管理又是软件测试的重要组成部分。Bug管理不仅依靠合理的管理理念，还要有适合项目的bug管理工具。在微软研发人员能够保持统一的思维模式、做事及语言习惯，与整个研发流程的配套工具密不可分， 其中最重要的就是通过 bug管理工具Product Studio 把整个产品的研发有机的联系起来。通过阅读每个 Bug，可以详细的看到大家讨论解决该问题的完整思路。微软 Project 2002 产品的 Architect 写的一个备忘录，其中提到： 如果 Raid 是别家的产品，需要微软每年付出一笔巨大的费用， Bill Gates 会支付这笔钱吗？ He wouldnt be happy, but you bet he would. Microsoft depends on Raid to get the job done.关键词： BUG概念 BUG等级 BUG状态 BUG管理工具QC项目组背景：某保险公司核心业务系统，支持保险公司基础业务。包括：新契约录单：实现保单的新单录入、人工核保、收费签单等功能；保全：实现保单的变更功能，如犹豫期退保、合同退保等功能；理赔：实现保单的理赔功能；财务接口:实现所有业务产生的财务数据的处理。A项目组组织架构图：软件测试中对bug的定义和bug管理的定义：BUG 概念：软件的Bug，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。Bug 管理是指对开发，测试，设计等过程中一系列活动过程中出现的bug问题给予纪录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除等一系列活动状态的管理，最后出相应图表统计，email通知修改者等功能。一、 A项目组存在的问题1.1 测试人员对bug描述不清楚，导致后续工作难以进行在软件测试过程中，很多时候软件测试工程师对于自己发现的问题或是简单的描述，又或是描述的过于繁琐，导致开发人员修改的时候不能迅速定位问题出现的原因。最糟糕的是等到测试人员自己回归测试的时候，不知道当初自己为什么提出这样的问题。过于简单的bug描述：不准确bug描述准确的bug描述合同退保计算结果错误万能险合同退保没有计算当月截止到退保日的利息，导致计算结果错误。过于繁琐的bug描述不准确bug描述准确的bug描述第一：在新单录入页面首先录入被保险人，然后在被保险人下录入定期寿险，定期寿险保险期间录入20年，保险期间显示错误。定期寿险保险期间录入“20年”后，页面显示不正确。配有相应的截图1.2 Bug修改不及时，影响需求上线在项目进行的过程中，有些时候开发人员可能会因为赶进度而忽略了bug修改，或者开发人员会觉得这个问题不严重可以延迟修改等原因，bug修改延迟的情况经常出现，测试人员经常可怜兮兮和开发人员说“你能把某个bug修改一下吗？”往往会出项当需求即将上线的时候，还有bug没有修改。这时候匆忙的修改，既不能保证修改的质量也不能保证测试的质量，会给项目组带来很大的风险。1.3 没有专用的bug管理工具，导致bug管理混乱项目组建立初期没有相关的bug管理工具，bug只是在excel中简单的登记。使用excel管理容易使数据混乱，当在excel中插入很多附件的时候不容易维护，有时候会出现数据丢失的情况。同时，使用过程中只能依靠人为的传递信息，当某个环节信息传递不及时就会影响提交或修改的实效，比如测试人员只是登记了excel而没有及时的邮件通知开发人员，结果导致bug修改延迟。第三，测试发现问题时可能单独找开发人员沟通，确定问题，理所当然的认为这样bug就不用记录，反正开发人员已经知道了，到时候就会修改，导致bug管理、统计混乱。二、 A项目组BUG管理的发展策略22.1 完善BUG管理流程2.1.1 明确bug等级首先是明确bug的严重等级，根据严重等级来确定bug修改的时间。问题的严重等级分为五级，为紧急、非常高、高、中和低级。T级-紧急：紧急问题及时反馈对大批业务数据有影响的，会对客户造成大批的数据错误或严重的数据错误或对客户造成严重的经济损失等的问题1-非常高：非常高问题根据对测试进程的影响分为 即时反馈；1） 系统崩溃（跳出）或无法运行；2） 所实现的功能与需求完全不符。如按照需求要求完成保单借款功能，但实现的 却是保单贷款功能；3） 核心功能未能提供合理的和可接受的结果以实现甲方任务所期望的特定目标。如分红红利计算错误；4） 安装包在执行安装测试过程中异常退出。2-高：高等级的问题要求在2日内反馈；1） 相同类型的缺陷在很多程序或模块中出现，需要改正每一个缺陷。如系统各模块在录入前都没有进行初始化；2） 功能实现有错误。如修改后的数据没有保存上，系统已有的数据查询不出来；3） 健壮性不强。如非常规操作会导致在运行期间所执行任务的实际结果与预期的结果有差别；4） 实际的操作规程与操作手册上描述的规程不符；5） 安装包能够被顺利执行，但所需加载的数据不完整，导致系统无法正常运行。3-中：中等问题要求在2日内反馈1） 不影响甲方继续前进，但会带来不便，如在当前窗口提供的打印快捷键无法实现打印功能，只能退出到外面一层的打印菜单才能实现打印；2） 由于数据的精度或长度不充分而引起的不正确或不精确，例如：显示长度不够，不能完整显示信息。4-低：低等级问题在一周内反馈错误是表面化的或微小的，不违反实务，不影响软件产品的性能。如界面的布局不够合理，用户的帮助或提示信息不够完善等。2.1.2 规范Bug流转状态及人员职责 新建bug：bug描述既不能太简单，也不能像操作手册那样繁琐。测试人员在新建bug的时候尽量详细、准确的描述bug产生的现象、结果，在必要的时候截图，将bug现象通过图片和文字配套的方式传达给其他人，在bug描述中必须有保单号。当出现bug的时候，页面流程须停留在bug出现的页面，不能撤销操作，这样开发人员就可以通过bug出现的页面重新复现，通过后台日志直接定位bug出现的原因，不用再重新做保单复现bug，这样就减少了修改bug的时间。同时，如果开发不能明白bug描述的意思可以直接在bug出现的页面查看，减少不必要的沟通。修改bug：开发人员在确认bug后，对bug做出修改，修改完成后将bug状态修改为已修改，将bug指给配置管理人员。配置管理人员在接到bug更新后，将状态修改为已更新然后指给测试人员。在修改bug状态的同时，要具体描述bug出现的原因和解决方案。项目组把bug出现的原因具体分为8大类：程序错误、需求不明、操作错误、环境问题、版本发布错误、交叉开发导致、需求变更导致、开发提交文件导致。Bug回归测试：测试人员接到修改完成后的bug执行回归测试。根据开发人员对bug出现的原因和解决方案执行合理的回归测试，部分回归测试或全部回归测试。Bug关闭：测试人员在回归测试完成确定没有问题后关闭Bug。Bug拒绝：当测试人员提交的bug不被开发人员认可的时候，可以将其状态置为拒绝，同时给出拒绝的原因。拒绝后的bug流转到测试人员，在确认bug不存在的情况下取消。拒绝的bug也可能是由于下一版本提交后就会自动解决，那么测试人员确认后将其状态改为消失。Bug重新打开：在接到开发人员提交已经修改的bug，在回归测试后发现其仍然存在问题，这样bug需要重新打开，再次分配给开发人员。下图是项目组bug流转图：在bug管理的过程中会有一些特殊的情况，如开发人员不接受bug，而测试认为bug应该修改，那么需要项目内其他相关人员共同讨论，确认是否是问题，是否要做修改，怎么修改等。对于生产机出现的问题，不允许修改完成后直接上线，必须也经过严格的测试。2.2 BUG管理工具QC(Quality Center)只靠制度而没有良好的 Bug 管理软件，根本无法确保 Bug 管理的有效性，因为仅靠这些规章制度很可能流于形式、走过场。正如源代码管理一样，如果没有类似 CVS 或 VSS 的工具，很难想象一个较大项目中的源代码仅仅靠公司的源代码管理制度和大家的自觉性，就可以让多个程序员之间的不同版本源程序保持同步、不冲突。光有制度是不行的，必须有配套工具来保证这些制度落到实处。2.2.1 QC的记录功能QC可以完备的记录、跟踪 Bug 的一生：从出生（创建新的 Bug） 、不断成长（记录相关人员寻找产生 Bug 的原因的讨论过程） 、 发育成熟 （找到了一个处理办法） 到最后死亡 （关闭） ，同时也要允许 Bug 的复活（问题重现），继续其生长过程。 在bug描述的同时可以添加附件，如在接口测试的时候可以将返回错误信息的请求报文和返回报文附加在bug上，这样开发人员可以快速的定位bug出现的位置和原因。QC可以详细的记录每一次操作的轨迹，这样可以跟踪bug的修改轨迹及提交时间2.2.2 QC的查询、统计功能1. 方便的查询功能，快速找到你关心的 Bug。比如：1） 最近 N 个指派给某人的 Bug2） 最近 N 个由某人创建的 Bug3） 各种自定义条件的查询2. 提供各种 Bug 统计信息。比如每个人头上有多少个 Bug、到目前为止 Bug 总数的统计。3. 方便的项目和模块管理，可以有很多项目、每个项目有多个模块，要能够很方便的增加、删除、修改。4. 简单的用户管理。作为一个可独立使用的系统，需要能够增加、删除用户。5. 需求与bug的关联，在新建bug的时候必须关联到需求上，方便后续的统计、跟踪、测试报告的编写。三、 总结A项目组通过制定bug管理流程，很大程度上提高了项目组bug管理