Bug管理系统使用说明
BugFree使用手册
1BugFree介绍1.1关于BugFreeBugFree基于PHP和MySQL开发，是免费且开放源代码的缺陷管理系统.服务器端在Linux和Windows平台上都可以运行；客户端无需安装任何软件,通过IE，FireFox等浏览器就可以自由使用。
1.2主页面登录后，默认主页面如下：1.产品选择框①：可以快速切换当前产品，产品模块框②和查询结果框⑥显示相应的模块结构和记录。
2.产品模块框②：显示当前产品的模块结构。
点击某一模块，查询结果框⑥会显示所选模块的所有记录。
3.个性显示框③：i.我的标记，指派给我，由我创建为系统设定的查询条件；ii.用户可以保存自己的查询条件；4.模式切换标签④：切换Bug, Test Case和Test Result模式。
默认登录为Bug模式。
5.查询框⑤：设置查询条件.6.查询结果框⑥：显示当前查询的结果。
i.自定义显示:设置查询结果的显示字段;ii.统计报表：显示当前查询结果的统计信息;iii.导出：将查询结果显示的自定义字段导出到XML文件.最多可同时导出5000条记录；iv.导入（仅支持Test Case模式）:可以将导出的XML文件在Excel 进行编辑后,再导入到BugFree中，实现Test Case批量编辑。
最大支持2M大小的XML文件；v.批量运行（仅支持Test Case 模式)：可以对查询结果的Test Case 同时创建Test Result。
最多支持100个Test Case。
（未实现）7.导航栏⑦：显示当前登录用户名等信息。
8.导航栏⑧：新建及从模板新建。
1.3Test Case管理页面1.4Test Result管理页面1.5Bug管理页面2BugFree使用BugFree集成了Test Case、Test Result和Bug的管理功能。
具体使用流程：首先创建Test Case（测试用例），（一般是先有设计草稿（Excel）)；然后评审测试用例；修改测试用例；最后将评审后的测试用例导入BugFree；根据测试计划运行Test Case产生Test Result（测试结果)，运行结果为Failed的Case，可以直接创建Bug。
BugFree中BUG状态
Postponed：是个问题，发现的太晚了，目前不必修理了，下一个版本讨论是否解决或推迟到以后再解决
Won’t Fix：是个问题，但是不值得修复 ，不管它吧
4、处理状态说明（即Bug处理过程的附属子状态）
Local Fix：表示已在本地修复；
Checked In：表示修复代码已经提交；
关于bugfree管理系统的使用和bug状态的说明
发布时间: 2011-8-26 11:40 作者: 第四城技术团队 来源: 51Testing软件测试网采编
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推荐标签： BugFree 缺陷管理工具 开源测试工具
2、三种无效的Bug
By Design：设计需求就是这么设计的，无效的Bug
Duplicate：这个问题别人已经发现，重复的Bug
Not Repro：无法复现的问题，无效的Bug
3、四种有效的Bug
Fixed：问题被修复
External：外部原因（比如浏览器、操作系统、其他第三方软件）造成的问题
目前，我们bug跟踪采用bugfree管理系统来控制，它忠实的记录着每个问题的处理过程， 不断提醒我们存在的问题，永远不会丢失和忘记。如果参与过较大软件项目或产品的研发TX， 就会理解它对软件可持续发展是至关重要的。希望我们项目和产品中的缺陷越来越少直到没有，Free嘛。。。通过bug流程控制，来不断提高工作效率和产品质量！但是在使用过程中，发现同学们对一些定义还不是特别清楚，所以整理了一下，供大家参考查阅！
关闭bug：bug发起人经本地服务器测试通过之后，在bug列表选择该bug标题，进入bug详细页，点击关闭按钮，填写测试说明，选择解决状态和版本号，点击保存按钮。
常用的BUG管理系统
常⽤的BUG管理系统⼀般BUg管理⼤致流程是：1.测试⼈员提交新的Bug⼊库，错误状态为New。
2.⾼级测试⼈员验证错误，如果确认是错误，分配给相应的开发⼈员，设置状态为open。
如果不是错误，则拒绝，设置为Declined状态。
3.开发⼈员查询状态Open的Bug，如果不是错误，则置状态为Declined；如果是Bug，则修复并置状态为Fixed。
不能解决的Bug，要留下⽂字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发⼈员⾃⼰决定，⼀般需要通过某种会议（评审会）通过才能认可。
4.测试⼈员查询状态为Fixed的Bug，验证Bug是否已解决，如解决置Bug的状态为Closed，如没有结局置状态为Reopen。
⼀般的Bug管理系统虽然可以满⾜⽇常的Bug管理，但依然存在很多问题。
例如：功能臃肿复杂，沟通难度⼤，上⼿难度⾼，需要线下部署，安装复杂。
专业版本收费⾼昂，增⼤了企业负担等等。
以下，简单整理了⼏款Bug管理⼯具的优缺点，具体的使⽤问题还需待⼀⼀实践后整理记录。
1.QC（Quality Center）QC前⾝是TD，即TestDirector，原属于Mercury Interactive公司（被HP收购），后改名为QC。
QC是⼀个基于web的测试管理⼯具，基于J2EE(Java 2 Enterprise Edition)，可以组织和管理应⽤程序测试流程的所有阶段，包括制定测试需求、计划测试、执⾏测试和跟踪缺陷。
此外，通过Quality Center还可以创建报告和图来监控测试流程。
需要安装IIS和数据库，系统资源消耗较⼤，功能很强⼤，和其他的测试⼯具，⽐如loadrunner测试⼯具的接⼝做得⽐较好，数据可以在它们中共享。
英⽂版的易⽤性不是很好，最重要的是收费且价格不菲，破解版的费事且性能不那么稳定。
资源地址：2.BugzillaBugzilla是由Mozilla公司提供的基于web⽅式，免费的开源的⼀款强⼤的缺陷跟踪系统(Bug-Tracking System)，是专门为Unix定制开发的，有强⼤的检索功能，强⼤的后台数据库⽀持，丰富多样的配置设定等；安装需要Perl和配置MYSQL数据库，过程⽐较繁琐，修改配置⽂件⽐较⿇烦。
jira-bug管理系统使用说明
Jira bug 管理系统使用说明1.登陆jira系统Jira的外网访问地址是http：//121.15.134.158：8001内网访问地址是http：//10。
98.89。
111:8001注：内网访问速度会快很多，但是考虑到工程师经常出差，所以将外网同时开放了.管理员为软件二部的每位工程师都注册了一个用户名,用户名是工程师的中文名字,初始密码是szclou，请各位再首次登陆时修改自己的密码2.JIRA 系统的使用2。
1提交问题2。
1。
1新建问题点击提交问题，选择项目和问题类型问题类型分为两种：•缺陷：产品中的错误,生产环境使用中和测试报告的.•需求变更：原有功能不够完善，不够好用而进行的修改针对两种不同的问题类型，填写的详细资料也不同，先做如下说明2.1.1。
1 缺陷填写的详细资料o问题描述:尽量简短地描述故障o优先级：分为危急严重一般次要轻微5个级别o截止日期：问题解决的最后期限o模块: 选择项目种对应的模块o受影响版本:当前出问题的版本o修复版本: 规划要解决的版本，一般为出问题的版本o分派给：选择分配给特定的人，如果不指定，则分选自动。
o报告人：提交问题的人o环境：例如操作系统，软件信息，硬件规格(包括适用于本任务单的）等等信息。
一般地，我们在这里添上联系人,联系方式等信息。
o详细描述:详细描述，越详细越好。
.。
提供需要什么时候完成等等信息.最后能够附上出问题的URL地址,以方便追查故障。
详细描述包括如下内容o场景：问题对应的功能项o预期结果：程序应该输出的结果o结果：程序实际输出的结果o分析：程序不过出现的原因（可选项）o注意事项:补充说明(可选项）2。
1.1。
1 需求变更填写的详细资料和缺陷填写的详细资料一样，只是详细描述的格式不一致详细描述包括如下内容o变更内容：简要描述需求的内容o变更原因:需求变更的原因o变更影响相关程序：影响的模块（中心控制或者web等）o基本路径：填写基本的业务流o补充说明：（可选项)2.1.2添加附件、截图提交问题完成之后我们可以给提交的问题添加附件和截图。
bug跟踪管理系统bug跟踪流程
bug跟踪管理系统 bug跟踪流程Bug跟踪流程1. 目的本文档主要是为了规范产品缺陷的跟踪解决、保证每个发现的缺陷都能有效跟踪，直到缺陷解决关闭。
2. 适用范围本文档适用于公司所有产品的缺陷跟踪。
需要测试、软件开发人员、硬件开发人员协调执行。
3. 角色和职责 3.1 测试工程师测试工程师负责问题提交、问题验证。
测试工程师不能把new状态、reopen状态的bug更改为fixed等其他状态。
测试工程师不能把没有修改的问题直接关闭。
测试工程师要及时验证问题，确保问题的及时关闭；如果验证不通过的问题要及时reopen，以便软件工程师能尽快了解情况，尽快解决问题。
3.2 开发工程师软、硬件工程师负责修改问题，在问题修改完把问题状态修改为fixed状态。
如果软、硬件工程师认为是非问题的，要及时和测试工程师讨论决定，如果不能形成一致意见的，可以上报上一级主管讨论。
如果经过讨论后一致认为不是问题的可以置为Invalid，或者确认是问题、讨论后决定不修改的问题可以置为wontfix, 然后由问题提交人关闭问题。
如果软、硬件工程师自己发现问题，原则上要求软、硬件工程师自己提交问题，把问题纳入跟踪。
软、硬件工程师不能关闭不是自己提交的问题。
3.3 缺陷库管理员缺陷库管理员一般由测试主管兼任，负责缺陷库的日常管理、维护。
在特殊情况下可以直接关闭部分问题（例如软件或硬件、测试一致同意关闭的问题）。
4. Bug跟踪流程流程图：过程说明：A．New bug：测试人员、市场反馈的问题由测试人员填写bug。
开发人员发现的问题由开发人员填写。
Bug填写完成后提交给相应的软、硬件开发人员。
Bug填写要求见“bug填写规范”。
B．Fix bug：开发人员修改自己负责的bug；修改完成并合入版本后把bug的状态修改成fixed。
C．Close bug：问题验证通过后，由问题提交人关闭bug。
D．Reopen：问题验证没有通过，发现问题还存在，或者问题只修改了一部分，则重新打开这个bug。
jira-bug管理系统使用说明教程文件
Jira bug 管理系统使用说明1.登陆jira系统Jira的外网访问地址是http://121.15.134.158:8001内网访问地址是http://10.98.89.111:8001注：内网访问速度会快很多，但是考虑到工程师经常出差，所以将外网同时开放了。
管理员为软件二部的每位工程师都注册了一个用户名，用户名是工程师的中文名字，初始密码是szclou，请各位再首次登陆时修改自己的密码2.JIRA 系统的使用2.1提交问题2.1.1新建问题点击提交问题，选择项目和问题类型问题类型分为两种：∙缺陷：产品中的错误，生产环境使用中和测试报告的。
∙需求变更：原有功能不够完善，不够好用而进行的修改针对两种不同的问题类型，填写的详细资料也不同，先做如下说明2.1.1.1 缺陷填写的详细资料o问题描述：尽量简短地描述故障o优先级：分为危急严重一般次要轻微5个级别o截止日期：问题解决的最后期限o模块：选择项目种对应的模块o受影响版本:当前出问题的版本o修复版本: 规划要解决的版本，一般为出问题的版本o分派给：选择分配给特定的人，如果不指定，则分选自动。
o报告人：提交问题的人o环境:例如操作系统，软件信息，硬件规格（包括适用于本任务单的）等等信息。
一般地，我们在这里添上联系人，联系方式等信息。
o详细描述：详细描述，越详细越好。
提供需要什么时候完成等等信息。
最后能够附上出问题的URL地址，以方便追查故障。
详细描述包括如下内容o场景：问题对应的功能项o预期结果：程序应该输出的结果o结果：程序实际输出的结果o分析：程序不过出现的原因（可选项）o注意事项：补充说明（可选项）2.1.1.1 需求变更填写的详细资料和缺陷填写的详细资料一样，只是详细描述的格式不一致详细描述包括如下内容o变更内容：简要描述需求的内容o变更原因：需求变更的原因o变更影响相关程序：影响的模块（中心控制或者web等）o基本路径：填写基本的业务流o补充说明:（可选项）2.1.2添加附件、截图提交问题完成之后我们可以给提交的问题添加附件和截图。
Bugzilla操作指南
Bugzilla操作流程 Bugzilla操作流程： 操作流程
Bugzilla操作指南1 Bugzilla操作指南1：注册 操作指南
打开IE在地址栏里输入：http://192.168.1.251/bugzilla进入bugzilla主页面，正常情况下应该显 示如下界面
点击New Account，输入注册用的E-mail，随后在E-mail中会收到一封来自bugzilla的邮件，根 据第一段下给出的相对地址，在IE中输入http://192.168.1.251/cgi-bin/bugzilla/相对地址， 进入注册页面，输入real name、密码以及密码确认，然后点击send就完成了。
4.用户管理 1）“Edit”一栏中的Users Users参数选项介绍如下： 这里主要用来查看和添加用户 Users
点击进入后可以修改用户相关信息
2）修改用户
name： Login name：登陆名称，这里设置email的名称 name： Real name：真实名称 Password： Password：可以为用户设置一个新密码 text： Disable text：如果这里不为空则用户帐号将被禁用，这里用来解释被禁原因 access： Group access： 在组访问设置里面有两列构选框， 第一列（左边列）：可以为别的用户设置成为这个组的成员，既是说如果我把一个用户某一组第一列勾选，则授权 这个用户就可以添加其他用户到这个组，相当于管理这个组。 第二列（右边列）：成为这个组的成员。 由下图中的勾选及提示就可看出：
4.查询My Bugs
这个选项在Saved Searches下作为一个默认的保存查询，点击这里可以看到当前用户提交的所有bug
Bugzilla操作指南5 保存My Bugzilla操作指南5：保存My Bugs 操作指南 我们可以在Search页面中保存自己的搜索： 例如我们查找状态（status）为all，产品（product）为GEB4.0的所有bug
禅道bug提交管理系统要求规范
目录 (2)1. 目的 (3)2. 禅道系统 Bug 流程图 (4)3. Bug 流程操作及其 Bug 相关信息解释 (5)3.1.测试人员发现 bug (5)3.2.测试人员创建 Bug (5)3.3.开辟人员设定 Bug 优先级别并确认 Bug (7)3.4.开辟人员解决 Bug (8)3.5.测试人员验证 Bug (9)本文档定义了 bug 管理流程及其 bug 相关信息内容。
本文档合用范围：本文档合用于新产品以及以后新产品的项目。
原有项目的bug 管理仍然用 JIRA 系统进行管理。
本文档合用于新产品以及以后新产品的项目相关的测试人员和开辟人员。
测试人员登录禅道系统，创建 Bug。
Bug创建 Bug 页面截图：页面字段注释：选择发现 Bug 的产品，必填项。
：选择发现 Bug 的对应模块，必填项。
：选择测试所属的项目。
必填项。
bug 的版本。
必填项。
Bug 内容，相当于 BUG 的中心语句。
必填项。
在标题上注明 bug 浮现的频率(稳定浮现/时常浮现/很少浮现/浮现一次)[环境] Bug 的环境，需要在重现步骤里详细描述环境信息，以便于开辟定位和解决问题。
[步骤]：写明浮现 Bug 的操作步骤，要求简单，去掉与 Bug 无关的步骤。
[结果]：写明操作的实际结果。
[期望]：写明操作的期望结果。
：选择与 Bug 相关的需求。
如果 Bug 关联测试用例， 系统会自动关联测试用例的需求。
：选择与 Bug 相关的任务。
这里的任务是在『->『 中创建的任务。
Bug 类型如下：代码错误：功能性错误。
界面优化设计缺陷 配置相关 安装部署 安全相关 性能问题 标准规范 测试脚本 其他Bug 严重程度如下：范例1．系统蓝屏，崩溃2．由于程序所引起的死机,非法退出 3． 死循环4． 数据库发生死锁5． 因错误操作导致的程序中断 6．与数据库连接错误 7． 数据通讯错误 1． 功能不符 2． 程序接口错误3． 数据库的表、业务规则、缺省值未 加完整性等约束条件 4． 主要功能错误1． 操作界面错误(包括数据窗口内列 名定义、含义是否一致) 2． 打印内容、格式错误3． 简单的输入限制未放在前台进行控 制4． 删除操作未给出提示 5． 数据库表中有过多的空字段 1． 界面不规范 2． 辅助说明描述不清晰 3． 输入输出不规范 4． 长期操作未给用户提示 5． 提示窗口文字未采用行业术语 6． 可输入区域和只读区域没有明显的 区描述所产生的问题导致系统崩溃，蓝屏，停 顿；缺少主要功能或者主要功能毫无作用， 导致无法进行下一步测试。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Bug管理系统使用说明
说明
该工具是为了协调和监控团队项目中Bug的处理流程而搭建。
工具是使用了微软TFS(Team Foundation Server)团队管理工具自带的功能，与开发工具VS(Visual Studio)进行了无缝集成(并提供java版和IOS版插件)，简化了开发人员处理Bug的流程。
选择Bug管理工具的原则：简单易用、管理方便、能够跟踪Bug状态并提醒、尽量减少工具数量。
该文档适用于新入职或对Bug管理工具使用流程不熟悉的车音网员工。
使用详解
一、连接到团队项目
在进行Bug提交或修改Bug之前需先连接到你的团队项目中：
在VS中菜单栏选择团队→连接到Team Foundation Server
在弹出的连接对话框中选择服务器→添加→输入服务地址(找管理员)→确定
弹出系统权限验证对话框输入管理员给你的账户密码→点击确定按钮
关闭添加/删除TFS 对话框
选择左侧团队项目集合中的集合→选择右侧团队项目中的项目→点击链接
打开了团队资源管理器(右侧红框)
二、Bug生命周期管理
1.提交/新建Bug
工作项右键→新建工作项→Bug
输入标题、指派给、详细信息其他为默认(状态、优先级别、严重级别) →点击左上角的保存工作项即完成了Bug的新建
2.查询Bug
在团队资源管理器→项目→工作项→我的查询右键→新建查询
选择合适的查询条件并保存
查询所有Bug
查询我的活动状态的Bug
查询我创建的Bug
3.开发人员修改Bug
双击查询我的活动状态Bug查看到提交给我的Bug
开发人员根Bug描述进行修改，并自测→提交代码并更新到测试平台→修改Bug状态为已解决→保存结果
4.测试人员关闭Bug
双击查询我创建的Bug查看到我提交到所有Bug
测试人员查询状态为已解决的Bug→回归测试→确认Bug已经解决→修改Bug状态为已关闭→保存结果
5.查看Bug更新记录
点击任意Bug→查看历史记录。