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

A项目组软件测试BUG管理策略研究 摘要：在软件开发过程中测试作为其中重要的环节，对软件的质量有至关重要的作用，其中BUG管理又是软件测试的重要组成部分。Bug管理不仅依靠合理的管理理念，还要有适合项目的bug管理工具。在微软研发人员能够保持统一的思维模式、做事及语言习惯，与整个研发流程的配套工具密不可分， 其中最重要的就是通过 bug管理工具Product Studio 把整个产品的研发有机的联系起来。通过阅读每个 Bug，可以详细的看到大家讨论解决该问题的完整思路。微软 Project 2002 产品的 Architect 写的一个备忘录，其中提到： 如果 Raid 是别家的产品，需要微软每年付出一笔巨大的费用， Bill Gates 会支付这笔钱吗？ He wouldn’t 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项目组存在的问题测试人员对bug描述不清楚，导致后续工作难以进行在软件测试过程中，很多时候软件测试工程师对于自己发现的问题或是简单的描述，又或是描述的过于繁琐，导致开发人员修改的时候不能迅速定位问题出现的原因。最糟糕的是等到测试人员自己回归测试的时候，不知道当初自己为什么提出这样的问题。过于简单的bug描述：不准确bug描述准确的bug描述合同退保计算结果错误万能险合同退保没有计算当月截止到退保日的利息，导致计算结果错误。过于繁琐的bug描述不准确bug描述准确的bug描述第一：在新单录入页面首先录入被保险人，然后在被保险人下录入定期寿险，定期寿险保险期间录入20年，保险期间显示错误。定期寿险保险期间录入“20年”后，页面显示不正确。配有相应的截图Bug修改不及时，影响需求上线在项目进行的过程中，有些时候开发人员可能会因为赶进度而忽略了bug修改，或者开发人员会觉得这个问题不严重可以延迟修改等原因，bug修改延迟的情况经常出现，测试人员经常可怜兮兮和开发人员说“你能把某个bug修改一下吗？”往往会出项当需求即将上线的时候，还有bug没有修改。这时候匆忙的修改，既不能保证修改的质量也不能保证测试的质量，会给项目组带来很大的风险。没有专用的bug管理工具，导致bug管理混乱项目组建立初期没有相关的bug管理工具，bug只是在excel中简单的登记。使用excel管理容易使数据混乱，当在excel中插入很多附件的时候不容易维护，有时候会出现数据丢失的情况。同时，使用过程中只能依靠人为的传递信息，当某个环节信息传递不及时就会影响提交或修改的实效，比如测试人员只是登记了excel而没有及时的邮件通知开发人员，结果导致bug修改延迟。第三，测试发现问题时可能单独找开发人员沟通，确定问题，理所当然的认为这样bug就不用记录，反正开发人员已经知道了，到时候就会修改，导致bug管理、统计混乱。A项目组BUG管理的发展策略完善BUG管理流程明确bug等级首先是明确bug的严重等级，根据严重等级来确定bug修改的时间。问题的严重等级分为五级，为紧急、非常高、高、中和低级。T级-紧急：紧急问题及时反馈对大批业务数据有影响的，会对客户造成大批的数据错误或严重的数据错误或对客户造成严重的经济损失等的问题1-非常高：非常高问题根据对测试进程的影响分为 即时反馈；系统崩溃（跳出）或无法运行；所实现的功能与需求完全不符。如按照需求要求完成保单借款功能，但实现的 却是保单贷款功能；核心功能未能提供合理的和可接受的结果以实现甲方任务所期望的特定目标。如分红红利计算错误；安装包在执行安装测试过程中异常退出。2-高：高等级的问题要求在2日内反馈；相同类型的缺陷在很多程序或模块中出现，需要改正每一个缺陷。如系统各模块在录入前都没有进行初始化；功能实现有错误。如修改后的数据没有保存上，系统已有的数