BUGFREE使用手册V03.docx
- 文档编号:30466075
- 上传时间:2023-08-15
- 格式:DOCX
- 页数:32
- 大小:835.88KB
BUGFREE使用手册V03.docx
《BUGFREE使用手册V03.docx》由会员分享,可在线阅读,更多相关《BUGFREE使用手册V03.docx(32页珍藏版)》请在冰豆网上搜索。
BUGFREE使用手册V03
BugFree使用说明
修订记录
日 期
修订
版本
修改
章节
修改描述
修订人
20130912
V0.1
整理Bugfree使用手册
梁肖肖
20130917
V0.2
6.7
新增Bug操作说明
梁肖肖
20130925
V0.3
全文
新增缺陷规程综述,调整章节布局
梁肖肖
目录
1.引言4
1.1目的4
1.2适用范围4
1.3参考资料4
2.缺陷规程综述4
2.1角色与职责4
2.2缺陷的定义4
2.3缺陷的生命周期5
2.4缺陷的严重性状态5
2.5缺陷的优先级状态7
2.6缺陷的严重性与优先级的关系7
2.7缺陷的类型7
2.8缺陷来源8
2.9缺陷状态9
2.10缺陷解决9
定义9
解决Build9
解决方案9
2.11缺陷流程10
流程图10
缺陷流程详述11
注意事项11
3.BugFree简介12
4.BugFree界面13
4.1登陆界面13
4.2主界面13
4.3创建界面14
5.Bug管理15
5.1Bug字段说明15
5.2Bug操作说明16
5.3Bug的状态17
6.查询结果17
6.1设置查询条件17
6.2快速筛选17
6.3自定义显示字段18
6.4查询结果排序18
7.后台管理19
7.1BugFree管理员角色19
7.2用户管理20
7.3用户组管理21
7.4产品管理23
7.5系统设置25
7.6管理日志25
7.7用户日志26
1.引言
1.1目的
为了建立我们的bug跟踪系统,为了更好地管理我们开发出来的系统存在的bug,方便相关人员进行沟通,及时去发现,及时去回复,及时去处理,让开发人员开发出来的系统更加接近完美。
1.2适用范围
适用于所有软件开发项目。
1.3参考资料
资料名称
内容
《BugFree2.0使用帮助》
2.缺陷规程综述
2.1角色与职责
角色
职责描述
测试人员/用户
1.发现缺陷,在BugFree中新增缺陷
2.回归测试,激活或关闭缺陷
开发人员
1.确认缺陷
2.修正缺陷
2.2缺陷的定义
a.软件没有达到《产品需求说明书》表明的功能;
b.软件出现了《产品需求说明书》不一致的表现;
c.软件功能超出《产品需求说明书》的范围;
d.软件没有达到用户期望的目标(虽然《产品需求说明书》中没有要求);
e.测试员或用户认为软件的易用性、美观性等差符合以上内容之一就称之为缺陷。
2.3缺陷的生命周期
新建的Bug处于Active状态,可以通过编辑指派给合适的解决者。
解决Bug之后,Bug状态变为Resolved,并自动指派给创建者。
创建者验证Bug。
如果未修复,再重新激活,Bug状态重新变为Active;如果已经修复则可以关闭,Bug状态变为Closed,Bug生命周期结束。
已经Closed的Bug如果重新复现,也可以直接激活。
具体流程如下图所示。
2.4缺陷的严重性状态
Ø定义
软件缺陷对软件质量的破坏程度。
在软件测试中,软件缺陷的严重性的判断应该从软件最终用户的观点做出判断,即判断缺陷的严重性要为用户考虑,考虑缺陷对用户使用造成的恶劣后果的严重性。
Ø严重性划分
定级划分
界定标准
1-VeryHigh
致命缺陷
系统不工作。
系统的有效部分无法操作且没有可供使用的工作区。
●系统安装失败造成测试无法进行
●在规格书中所描述的主体功能没有实现
●应用程序异常中止
●造成系统运行环境被破坏(包括死机、服务器程序死锁等)
●导致操作系统崩溃(如系统蓝屏或系统致命错误等)
●导致操作系统不响应
●程序退出没有释放资源
●导致其它应用程序出现异常(如无法启动、不响应、异常退出)
●卸载时不提示客户确认即删除公用程序(公用DLL等)
●造成重大安全隐患情况(如机密性数据的泄密)
●其它导致操作系统或其它应用程序异常的情况
2-High
严重缺陷
系统无法满足基本的业务要求且没有便捷可用的工作区。
性能、功能或使用方面严重不达标。
●功能基本实现,在特定的情况下导致功能失败
●功能部分失败,对整体功能的实现不造成大的影响
●用户操作将导致重要数据被破坏
●系统运行效率差,处理及响应时间过长
●UserManual中出现明显误导用户的内容
●出现频率极低,会对功能实现造成非致命影响
●应用程序本身挂起
●被测应用程序异常退出
●系统无法正常安装、卸载或升级
●其它导致被测系统本身出现无法正常运行的错误
●导致输出的数据错误(数据内容出错、格式错误、无法打开等)
导致其它功能模块无法正常执行,如:
·功能不完整或功能实现不正确;·导致数据最终操作结果错误·文件或数据传输不完整或不正确·对数据格式不进行检测·提示语句易误导用户,造成数据丢失等重大问题
●其它导致被测应用系统其它模块无法正常运行或出现错误结果的情况
3-Medium
一般缺陷
系统能够满足业务要求。
有快捷方便的工作区可供使用。
性能、功能或使用方面并不是严重不达标。
●功能部分失败,对整体功能的实现基本不造成影响
●UI中出现以下问题(文字内容错误,图片不正确)
●UserManual中出现以下问题(文字内容错误、图片不正确、链接错误)
●出现频率极低,会对功能实现造成非致命影响
●影响当前操作结果
●数据修改后没有保存提示
●系统出错提示不正确或没有捕获系统出错信息
●数据的重要操作(如删除、添加等)没有提示
●其它影响被测模块/功能正常执行的情况
4-Low
微小缺陷
微小修改,提出建议,最好能够修正,但不是必需的。
在发布准确性或实用性方面不会产生重大影响。
●UI中出现以下问题(拼写错误、界面不友好、页面中有乱码、风格不一致等)
●UserManual中出现以下问题(拼写错误、界面不友好、页面中有乱码、风格不一致等)
●页面布局不合理
●字体不一
●语言不一致(如:
中英文混合)
●页面提示不明确
●系统易用性不好
●其它对被测模块功能实现没有影响的情况
2.5缺陷的优先级状态
Ø定义
优先级是表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。
Ø优先级划分
优先级
描述说明
高
影响测试执行,需要马上修改或当天修改。
中
必须修改但并不影响测试执行的缺陷,下一版本修改。
低
需要完善的界面或功能,可以根据开发进度和项目质量要求,决定是否修改和修改时间。
2.6缺陷的严重性与优先级的关系
缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。
它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地,严重性程度高的软件缺陷具有较高的优先级。
严重性高说明缺陷对软件造成的质量危害性大,需要优先处理,而严重性低的缺陷可能只是软件不太尽善尽美,可以稍后处理。
但是,严重程度和优先级并不总是一一对应。
有时候严重性高的软件缺陷,优先级不一定高,甚至不需要处理,而一些严重性低的缺陷却需要及时处理,具有较高的优先级。
确定软件缺陷优先级,更多的是站在软件开发工程师的角度考虑问题,因为缺陷的修正顺序是个复杂的过程,有些不是纯粹技术问题,需要综合考虑市场发布和质量风险等问题。
2.7缺陷的类型
Ø定义
缺陷类型是根据缺陷的自然属性划分的缺陷种类。
Ø缺陷类型的划分
缺陷类型
描述说明
代码错误
出现程序错误或错误代码的提示
用户界面
操作易用性建议及操作界面错误。
界面错误如:
界面不规范、界面文字错误、打印内容、格式错误等
需求变动
需求变更导致的缺陷
新增需求
新增需求导致的缺陷
设计文档
文档的缺陷,影响发布和维护,包括注释
配置相关
与配置相关的缺陷,包括软硬件冲突等
安装部署
编辑、其他支持系统问题
安全相关
达不到对安全性的要求
性能压力
不满足系统可测量的属性值;如:
执行时间、事务处理速率
标准规范
不符合各种标准的要求,如编码规范等
测试脚本
测试脚本无法执行或执行是出错
事务跟踪
无法跟踪某一特定事务或跟踪时出错
其他
除以上类型外的其他缺陷
2.8缺陷来源
Ø目的
判断缺陷来源的目的在于加强对缺陷的分析跟踪能力。
Ø缺陷来源的划分
缺陷来源
描述说明
功能测试
由于功能测试的问题引起的缺陷
需求检查
由于需求的问题引起的缺陷
代码检查
由于编码的问题引起的缺陷
单元测试
由于单元测试的问题引起的缺陷
版本验证测试
由于版本验证测试的问题引起的缺陷
集成测试
由于集成的问题引起的缺陷
系统联调
在系统联调时产生的缺陷
冒烟测试
冒烟测试阶段发现的缺陷
上线遗漏
上线前遗漏的缺陷
BugBash
BugBash(Bug大扫除)通常发生在项目开发各阶段(微软叫里程碑)的末期,比如Beta版发布前,划出一个专门的时间段(通常1-3天),在这期间所有参与项目的人员,集中全部精力,运用各方面的知识,尽全部智慧来搜寻项目的Bug。
随机测试
随机测试时发现的缺陷
回归测试
回归测试时发现的缺陷
客户反馈
客户反馈的问题对应的缺陷
合作伙伴
合作伙伴反馈的问题对应的缺陷
其他
除以上来源外的其他途径的缺陷
2.9缺陷状态
Ø定义
缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
Ø缺陷状态的划分
状态
说明
Active(活动)
Bug的初始状态。
任何新建的Bug状态都是Active。
可以通过编辑修改Bug的内容,并指派给合适的人员解决。
Resolved(已解决)
解决Bug之后的状态。
Closed(已关闭)
已修复Bug在验证无误之后关闭,该Bug处理完毕。
如果没有真正解决或者重新复现,可以重新激活,Bug状态重新变为Active。
2.10缺陷解决
Ø定义
开发人员修复缺陷之后的具体信息。
Ø解决Build
格式:
[日期].[数字升序]。
用例:
权限系统2013年6月1日发布的第六个版本20130601.06。
Ø解决方案
类型
解决方案
详细说明
三种无效的Bug
ByDesign
设计需求就是这么设计的
Duplicate
这个问题别人已经发现
NotRepro
无法复现的问题
四种有效的Bug
Fixed
问题被修复
External
外部原因(比如浏览器、操作系统、其他第三方软件)造成的问题
Postponed
发现的太晚了,下一个版本讨论是否解决
Won’tFix
是个问题,但是不值得修复
2.11缺陷流程
Ø流程图
Ø缺陷流程详述
●发现缺陷
测试执行过程中,测试人员或用户发现缺陷。
●新增缺陷
测试人员或用户在发现缺陷后,登录缺陷管理系统BugFree。
将发现的缺陷登录到BugFree中。
新增缺陷时要设置缺陷的严重性、优先级、Bug类型和如何发现等,同时要填写清楚创建Build(当前软件版本号)。
测试人员或用户提交缺陷后,缺陷在BugFree系统中的缺陷状态为“Active”。
●确认缺陷
测试人员或用户在BugFree系统中提交缺陷后,开发人员登录BugFree系统。
对新增的缺陷进行确认。
确认是缺陷的,开发人员针对缺陷进行修改,此时在BugFree系统中,此缺陷的状态为“Active”。
经过确认不是缺陷的,将缺陷直接进行解决,解决的缺陷在BugFree系统中的状态为“Resolved”,解决方案可以依情况选择:
ByDesign,Duplicate,NotRepro。
●修正缺陷
开发人员对缺陷进行调查和修正。
开发人员修正缺陷完毕后,登录BugFree。
在BugFree系统中记录修正缺陷的“解决Build(开发版本号)”、“解决方案”和“处理状态”。
修正的缺陷在BugFree系统中的状态为“Resolved”,解决方案可以依情况选择:
Fixed,External,Postponed,Won'tFix。
●回归测试
开发人员修正缺陷后,测试人员或用户对缺陷进行回归测试。
测试人员或用户回归测试该缺陷已被修复,登录BugFree系统将缺陷关闭。
关闭的缺陷在BugFree系统中的状态为“Closed”。
测试人员或用户回归测试该缺陷未被修复,测试人员或用户将缺陷重新激活。
重新激活的缺陷在BugFree系统中的状态为“Active”。
由开发组长重新分派修正,如此迭代,直到此缺陷被修复。
Ø注意事项
(1)改变缺陷状态时必须添加相应说明。
(2)项目经理、测试经理、测试人员可以对缺陷进行关闭,开发人员不能擅自将缺陷进行关闭,也不能将缺陷返回给测试人员,项目经理也不可将测试人员提交的缺陷再分派给测试人员。
(3)超过三天没有解决的缺陷,测试人员将根据情况将缺陷等级增加。
(4)请大家安装BugFreeHelper(缺陷状态提醒软件),下载地址
(5)当修改好Bug对应的代码文件,提交到SVN上时,务必在信息处填写“fixbug#10”(不含引号,其中10为BugFree中对应的BugID,注意不能换行)。
提交代码文件到SVN之后,会给相应人员发电子邮件,请注意查收,注意可能会发送到垃圾邮箱内。
(6)Build说明:
1软件版本号
创建Build:
nn.nn.nn.nn=[架构][主要功能][小功能][bug修改],用例:
∙7月初的第一次发布,所有系统应为3.0.0.0
∙7月15日,权限系统bug修改,那么权限系统的版本为3.0.0.1
∙7月25日,权限系统增加了一个功能,并修复了3个bug,版本为:
3.0.1.1
∙10月1日,权限系统增加了3个主要功能,并修复了一些bug,版本为:
3.1.1.1
2开发版本号
解决Build:
[日期].[数字升序],用例:
权限系统2013年6月1日发布的第六个版本20130601.06。
3.BugFree简介
BugFree基于PHP和MySQL开发,是免费且开发源代码的缺陷管理系统。
服务器端在Linux和Windows平台上都可以运行;客户端无需安装任何软件,通过IE,FireFox等浏览器就可以自由使用。
BugFree集成了TestCase和TestResult的管理功能。
具体使用流程是:
首先创建TestCase(测试用例),运行TestCase产生TestResult(测试结果),运行结果为Failed的Case,可以直接创建Bug。
TestCase标题、步骤和TestResult运行环境等信息直接复制到新建的Bug中。
如下图所示。
4.BugFree界面
4.1登陆界面
在浏览器中输入BugFree地址:
http:
//IP或域名/bugfree/index.php/site/login
直接打开登陆页面。
4.2主界面
输入系统提供的默认管理员用户名:
admin,密码(原始):
123456;语言选择默认“简体中文”。
点击“登录”按钮,来到Bugfree主界面,输入用户名和密码登录成功后,显示BugFree主界面:
● 项目选择框①:
可以快速切换当前项目,项目模块框②和查询结果框⑥显示相应的模块结构和记录。
● 项目模块框②:
显示当前项目的模块结构。
点击某一模块,查询结果框⑥会显示所选模块的所有记录。
● 个性显示框③:
a) 我的标记:
保存查询框⑤中已标记的查询条件,点击后在查询框⑤和查询结果框⑥显示相关已标记的相关信息
b) 指派给我:
显示最近指派给我的记录数量,点击后在查询框⑤和查询结果框⑥显示相关指派给我的相关信息
c) 抄送给我:
显示最近抄送给我的记录数量,点击后在查询框⑤和查询结果框⑥显示相关抄送给我的相关信息
d) 由我创建:
显示最近由我创建的记录数量,点击后在查询框⑤和查询结果框⑥显示由我创建的相关信息
● 模式切换标签④:
切换Bug,TestCase和TestResult模式。
默认登陆为Bug模式。
● 查询框⑤:
设置查询条件。
● 查询结果框⑥:
显示当前查询的结果。
a) 自定义显示:
设置查询结果的显示字段。
b) 统计报表:
显示当前查询结果的统计信息。
c) 导出:
将查询结果显示的自定义字段导出到XML文件。
最多可同时导出5000条记录。
d) 导入(仅支持TestCase模式):
可以将导出的XML文件在Excel进行编辑后,再导入到BugFree中,实现TestCase批量编辑。
最大支持2M大小的XML文件。
e) 批量运行(仅支持TestCase模式):
可以对查询结果的TestCase同时创建TestResult。
最多支持100个TestCase。
● 导航栏⑦:
显示当前登录用户名等信息。
4.3创建界面
为了保持用户体验的一致性,新建Bug,TestCase和TestResult的界面布局基本保持一致,只是具体填写字段有所不同。
以新建Bug为例,在主界面模式切换标签选择Bug,点击[新建Bug]打开新建Bug页面。
如下图,黄色标注字段为必填项。
5.Bug管理
5.1Bug字段说明
Bug标题:
为包含关键词的简单问题摘要,要有利于其他人员进行搜索或通过标题快速了解问题。
项目名/模块路径:
指定问题出现在哪个项目的哪个模块。
Bug处理过程中,需要随时根据需要修改项目或模块,方便跟踪。
如果后台管理指定了模块负责人,选择模块时,会自动指派给负责人。
新建或修改Bug时,一定要定义清晰模块,便于后续分析统计。
指派给:
Bug的当前处理人。
如果不知道Bug的处理人,可以指派给Active,项目或模块负责人再重新分发、指派给具体人员。
如果设定了邮件通知,被指派者会收到邮件通知。
状态为Closed的Bug,默认会指派给Closed,表示Bug生命周期的结束。
抄送给:
需要通知相关人员时填写,例如测试主管或者开发主管等。
可以同时指派多个,人员之间用逗号分隔。
如果设定了邮件通知,当Bug有任何更新时,被指派者都会收到邮件通知。
严重程度:
Bug的严重程度。
由Bug的创建者视情况来指定,具体参见缺陷的严重性状态。
优先级:
Bug处理的优先级。
由Bug的处理人员按照当前业务需求、开发计划和资源状态指定,具体参见缺陷的优先级状态。
其余选项字段(Bug类型、如何发现、操作系统、浏览器):
可以通过编辑Lang/ZH_CN_UTF-8/_COMMON.php来自定义。
创建Build:
Bug是在哪个版本(Build或者Tag)被发现的。
解决Build:
Bug是在哪个版本(Build或者Tag)被解决的。
解决方案:
参考Bug的七种解决方案。
如果解决方案为Duplicated,需要指定重复Bug的编号。
处理状态:
Bug处理过程的附属子状态,例如LocalFix表示已在本地修复;CheckedIn表示修复代码已经提交;Can’tRegress表示修复的问题暂无法验证等。
机器配置:
测试运行的硬件环境,例如DellG2802G/200G。
关键词:
主要用于自定义标记,方便查询。
关键词之间用逗号或者空格分隔。
例如,对于跨团队的项目开发,可以约定一个关键词统一标记项目。
相关Bug:
与当前Bug相关的Bug。
例如,相同代码产生的不同问题,可以在相关Bug注明。
相关Case:
与当前Bug相关的Case。
例如,测试遗漏的Bug可以在补充了Case之后,在Bug的相关Case注明。
上传附件:
上传Bug的屏幕截图,Log日志或者CallStack等,方便处理人员。
复现步骤:
最好关联到测试用例的相关编号,建议可追溯性;[步骤]要描述清晰,简明扼要,步骤数尽可能少,按此操作应可重现Bug;[结果]说明Bug产生的错误结果;[期望]说明正确的结果。
可以在[备注]提供一些辅助性的信息,例如,这个bug在上个版本是否也能复现,方便处理人员。
5.2Bug操作说明
系统前台页面,查询结果框⑥默认显示所有派送给当前用户的Bug信息。
通过点击标题,可自动通过标题进行排序。
点击Bug标题的具体信息,可打开对应的Bug,展示Bug的详细信息。
Bug详细信息与新建Bug页面的信息基本一致,后台根据提交的相关信息,自动补充了修改者、修改日期、注释等相关信息
页面共8个按钮
上一个:
显示当前序号的上一个的BUG信息,快捷键
下一个:
显示当前序号的下一个的BUG信息
编辑:
编辑状态下用户可根据BUG的处理情况,修改BUG相关信息,添加注释信息,点击保存后修改当前BUG的相关信息。
系统会根据修改记录添加系统注释信息。
编辑状态下可另存为模板
复制:
利用当前BUG新建相类似的新BUG。
复制状态下可另存为模板
新建Case:
当前的BUG无对应的Case与之匹配,可通过新建Case,保证Case的覆盖率
解决:
将当前BUG状态由Active置为Resolved,同时给出对应的解决方案
关闭:
将当前BUG状态由Resolved置为Closed
激活:
已关闭的BUG,同样的问题又复现;点击激活按钮,将BUG的状态修改为Active,激活次数+1
5.3Bug的状态
在BugFree中,一个Bug只有3种状态:
Active、Resolved、Closed。
实践中经常有不熟悉的用户通过“编辑(Edit)”来改变所有的状态,那是不合适的。
正确的状态转换方法应该是:
1.某个状态自己到自己的改变,使用“编辑(Edit)”。
比如一个Active的Bug,从一个人指派到另外一个人;
2.Active->Resolved只能用“解决(Resolve)”;Resolved->Closed只能用“关闭(Closed)”;3.Resolved->Active和Closed->Active只能使用“激活(Activate)”。
6.查询结果
6.1设置查询条件
BugFree默认显示2个查询组,每组有3个查询字段(总共6个查询字段)。
假设要查询项目Project1,Project2和Project3从2008年1月1日起所有未关闭的Bug,可
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- BUGFREE 使用手册 V03