Bug管理系统使用说明

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。

常⽤的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 管理系统使用说明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跟踪流程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 管理系统使用说明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添加附件、截图提交问题完成之后我们可以给提交的问题添加附件和截图。

目录 (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． 可输入区域和只读区域没有明显的 区描述所产生的问题导致系统崩溃，蓝屏，停 顿；缺少主要功能或者主要功能毫无作用， 导致无法进行下一步测试。

缺陷管理系统(BMS)*修改类型分为A - ADDED M - MODIFIED D– DELETED目的：定义软件需求，为后期的设计打下基础背景、备注：定义：参考：1概述为了管理软件公司的软件产品所存在的缺陷问题，我们开发了这套“BMS缺陷管理系统“项目。

在软件公司的软件产品开发过程中，最主要有三个角色，分别是项目经理、开发人员和测试人员。

每个角色在项目中承担着不同的职责。

项目经理负责确定需求并完成对每个功能特性的设计文档。

开发人员则是通过编写代码实现项目经理制定的需求和设计。

测试人员负责检查开发人员实现的功能是否符合项目经理定义的功能需求和设计文档。

项目经理、开发人员和测试人员三者之间有效合作并制衡，“三权分立”。

当开发人员和测试人员对某个Bug的解决方案产生分歧时，由代表用户的项目经理做出裁决；整个软件产品的研发过程中，特别是在测试软件产品、修复Bug的中后期，团队中所有人都参与到了修改缺陷的过程中，所有发现的Bug要统一管理起来，所有人都可以自由的查看，并按照一定的流程进行修改操作。

1.1 软件名缺陷管理系统(BMS)1.2 版本1.01.3 背景实现公司对软件缺陷的管理1.4 用户群所有软件公司的开发者，包括项目经理，软件开发人员，测试人员还有浏览项目缺陷人员。

1.5 产品理念规范、高效、友好.1.6 文档约定1.7 需求优先级说明[A1]: 优先级1，优先，必须做；[A2]: 优先级2，中等，争取做；[A3]: 优先级3，下等，可不做；备注：需求项没有特别说明优先级的，表示为[A1]。

1.8 预期的读者和阅读建议此需求规格说明文档的预期读者是项目开发人员，测试人员，项目经理。

1.9 参考文献2需求描述2.1 整体结构描述首先，使用本系统的用户需要登陆，在登陆页面输入正确的用户名和密码后进入系统主页。

进入系统主页所能看到和操作的界面是和登录用户的权限相关的。

系统用例如下：用户管理本系统主要功能模块包括：用户管理、项目管理、BUG管理用户登陆成功以后，管理员进入用户管理界面，而其它用户则进入项目的览界面2.2 综合描述2.2.1公共页面2.2.1.1 概述普通用户模块2.2.1.2 典型模块2.2.1.2.1用户登录用户在登录页面输入用户名和密码点击【登录】，系统验证通过后才能登录本系统。

目录Bugnet使用说明 (2)1、注册bugnet账号 (2)1．1、进入bugnet 网站 (2)1.2、注册用户名 (2)2、Bugnet的使用 (4)2.1、登录Bugnet (4)2.2、我的问题页面 (5)2.3、某个项目的所有问题统计 (6)2.4、创建问题 (6)2.5、问题修改 (7)3、管理员特有权限 (8)3.1、项目管理 (8)3.1.1、增加项目 (9)3.1.2项目权限群组（角色）设置 (13)3.2、用户管理 (14)3.3、bugnet系统基本信息设置 (15)3.4、错误信息日志查看 (16)Bugnet使用说明1、注册bugnet账号1．1、进入bugnet 网站在网页浏览器地址栏里输入url,如http://192.168.1.101:8887/ ，进入Bugnet的登录界面,如下图:1.2、注册用户名点击bugnet的登录页面“Register”，转到以下界面：注意：注册输入的邮箱必须为其他用户没有用过的邮箱，默认的新注册用户只有[游客]的身份权限，其它一些权限的设定需要管理员另行配置在此页面输入自定义的帐号和有效的E-MAIL，字符串，点击“”。

如果成功注册将会出现以下页面：点击继续，进入系统首页界面如下图：导航栏为当前用户有权限的功能栏，左侧为系统基本系统介绍，右侧为当前用户能访问的项目列表。

2、Bugnet的使用2.1、登录Bugnet在登录的页面，输入注册的用户名(此用管理员身份示列说明)，进入Bugnet的首页界面。

如下图：Home：首页，显示当前系统的基本信息，能访问的项目列表2.2、我的问题页面My Issues：和当前用户相关的所有问题情况，如下图左侧统计各问题状态的数量，有侧跟状态的问题详细列表。

2.3、某个项目的所有问题统计首页项目列表里面，点击某一个项目进入“Project Summary”，显示当前项目所有问题的统计情况，如下图：按照项目版本，项目问题类型，项目团队成员，问题状态，优先级来统计这个项目问题的数量。