如何通过BugFree对缺陷进行管理.docx

如何通过BugFree对缺陷进行管理(一) 关键字：创建Bug,解决Bug,关闭Bug,编辑Bug状态 我们对缺陷的管理是通过定义缺陷的状态来实现的。在BugFree屮，缺陷的状态有三种，分 别是 Active, Resolved, Closed。 Active:测试人员新提交了缺陷。 Resolved:开发人员处理解决了缺陷。 Closed:测试人员检验缺陷不再发生关闭了缺陷。 TesterTesterTesterDe-ueloper Tester Tester Tester De-ueloper 一、测试人员如何提交缺陷(Active) 测试人员通过自己的账号进入缺陷管理系统，在Bug模块选择“新建Bug”按钮，进入 新建Bug页面。如下图所示： 页而上输入框背景色为“黄色”的区域是必填项，包括：Bug标题，项目名称/模块路径, 指派给，创建Build,严重程度，Bug类型，如何发现。 我们在此规定，重现步骤与附件也同是必填项，对于界面类型的缺陷，可以直接用附件 图片來说明问题而不用在重现步骤里过多描述。 Bug标题：是对缺陷现彖的一个概括性描述。 项目名称/模块路径：对应着该缺陷所属的项目及模块名称。 指派给：此处填写的是该项目的项目经理的名字。 创建Build:填写上缺陷发生的软件版本号。 严重程度：分为四个等级，数字越小代表严重程度越高。 Bug类型：选择该缺陷所属的类型。 发何发现：此处下拉列表选择缺陷的发现方式。 缺陷报告的注意事项： 确保缺陷能重现（要求测试人员提交缺陷报告之前至少耍重现三次） 描述语言简洁，准确，完整 重现步骤只要求写出关键步骤 有必要附上附件（图片或日志） 一个缺陷报告对应一个缺陷 描述语咅要客观，只针对出现问题，可以适当加入作为用户的主观想法，但语咅要 平和，不要批评开发人员的设计。 附件的相关规定： 当需要提交图片附件时，图片格式为*.jpeg或是*.jpg； 如果涉及缺陷重现步骤的附件，图片应截取重现过程的整个流稈（包括每一步的操作图片）; 图片的命名应遵循见名知义原则，即通过图片的名字能大概了解图片的内容； 在截取问题区域图片时，尽量不要让图片上留下大片无用的空白区域，图片排列整齐美观； 在附件图片上的标示颜色统一用红色，包括文字和各种图形框； 如需输入文字，文字大小为“宋体” “12号” “加粗” “红色”。 如果附件里同时有多张图片，在命名时要注意区分； 如果一张附件图片里有多张小图的拼贴，一定要注意排布整齐； 标示时，用直线工具，不要手工去画直线； 图片总体要求：整齐美观，规范统一。 二、开发人员如果处理缺陷（Resolved） 开发人员可以登陆BugFree查看自己名下的缺陷。请注意，在搜索自己名下的缺陷时一 定要限定缺陷的状态为“Active”的缺陷才是需要开发人员处理的缺陷。 点开一个待处理的Bug,如下图所示： 啊E冷热a）?ig Q 1Sample/IMOBug M 金 BugE洪给，■程虔 啊E 冷热a） ?ig Q 1 Sample/ IMO Bug M 金 Bug E洪给 ，■程虔 tt先级 Bug Afi 帧吾 ■后炫改巳■ Act^t ActW A日 rirlr as 201(M?4)3 1 代爲!■* 功 KMiX nawB 艾■誇 Bug AM IB 关 Buq B 关 Cwe 啊关R?uh mn XwJ admn 2010-0%03 2?1(H冷 2?1(H冷03 W:5M3 Opened y admtn [^9] [??]0 Internet | [??] 0 Internet | AFflm； BR g ▼ *1100% ▼ 当开发人员已完成修复工作，则在该Bug页面上选择“解决”按钮， 会出现以下界面, 见下图： E Bug x2 1 ? Windows Internet Explorer G J ， 192.168A75/bugfrce/Bug.php^u9ID ? 2 卜，科底 P ■i4 ??? w EJT 卜，科底 P ■ BugrreeWff(S)BS 毎 91 |1￥目名除/■檢SB経 | Simple(Mo她?0氛2Resoled gw H尸童程IS 仕先级 eug Afi tlH??淆癸at?后t:改8*10 丽血’?□. El Bugrree Wff(S) BS 毎 91 |1 ￥目名除/■檢SB経 | Simple (Mo她 ?0氛2 Resoled gw H 尸童程IS 仕先级 eug Afi tlH?? 淆癸at ?后t:改8* 10 丽血’? □ . El 3dnw) 2010-0%03 ?日B ■日 sttirir决决决 创笛mss ■ 2010-0^)3 2010^943 □ 处 ASMS关?? Buq