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

缺陷管理系统(BMS)

缺陷管理系统(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操作说明

目录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”，显示当前项目所有问题的统计情况，如下图：按照项目版本，项目问题类型，项目团队成员，问题状态，优先级来统计这个项目问题的数量。

mantis_基本操作文档

MANTIS使用文档(Bug管理系统)一、mantis功能介绍mantis是一个基于PHP技术的轻量级的缺陷跟踪系统，是以Web操作的形式提供项目管理及缺陷跟踪服务。

我们经常需要用到的界面有：“我的视图”、“查看问题”、“提交问题”三个页面。

1.“我的视图”界面（如图1）：图1 “我的视图”该界面的的右上角有一个下拉菜单，有来选择所要提交或者查询的内所属内容。

如图3，可以选择“数据管理系统”、及其子模块“元数据管理模块”，“数据标准管理模块和电子审批流程模块”。

图3 项目种类“我的视图”主界面由5个部分组成，分别为“未分派的”、“我报告的”、“已解决的”、“最近修改”和“我监视的”。

未分派的list中显示的bug均为提交后但没有指定分配给谁的缺陷；“我的报告”list中显示的是有登陆用户本人所提交的bug；“已解决的”list显示的是测试核实后已经closed的bug；“最近修改”list显示的是最近有过bug状态更改和最新的bug，按照时间修改的时间顺序排列。

一般我们只需要关注“我的报告”和“未分派的”两个list。

图4 状态注释如图，页面底部的状态注释栏解释了再list我们看到不同背景色的bug所代表的不同状态。

例如绿色背景色的bug表示已经解决了，而灰色背景色的bug表示已经关闭的缺陷。

2.“查看问题”界面“查看问题”页面主要是列出所有的缺陷，并提供便利的查询条件。

图5查询条件页首的这个是条件查询框。

在这里选择查询条件可以很方便的找到需要的缺陷信息。

例如点击“分配给”三个字的时候再其下就会出现一个下拉列表用来选择非配给的对象，然后点击下面的“筛选”按钮可以按照选定的分配给对象进行查询，并在此条件选择框的下方返回一个符合查询条件的缺陷list。

查询框体的下面就是显示缺陷list的位置。

3.“提交问题”页面提交问题页面是由一个大的框体和多个输入框组成，如图：图6“提交问题”页面此页面具体的使用过程会在接下来的“提交bug基本流程”中详细介绍。

使用手册缺陷管理系统使用说明书版要点

1缺陷管理系统《使用说明书》文档修改记录目录1序言....................................... 错误!未定义书签。

1.1 什么是Bugzilla ............................................................................ 错误!未定义书签。

1.2为何使用Bugzilla...................................................................... 错误!未定义书签。

2BUGZILLA基本操作............................ 错误!未定义书签。

3BUG提交过程................................. 错误!未定义书签。

4BUG处理流程................................. 错误!未定义书签。

5对于BUG旳不一样处理状况................... 错误!未定义书签。

6有关权限阐明............................... 错误!未定义书签。

7查询操作................................... 错误!未定义书签。

8管理员操作指南............................. 错误!未定义书签。

2序言2.1 什么是Bugzilla●Bugzilla是Mozilla企业向我们提供旳一种开源旳免费缺陷跟踪工具。

作为一种产品缺陷旳记录及跟踪工具, 它可以为我们建立一种完善旳Bug跟踪体系, 包括汇报Bug、查询Bug记录并产生报表、处理处理、管理员系统初始化和设置四部分。

并具有如下特点:●基于Web方式, 安装简朴、运行以便快捷、管理安全。

有助于缺陷旳清晰传达。

本系统使用数据库进行管理, 提供全面详尽旳汇报输入项, 产生原则化旳Bug汇报。

bug管理流程

Bug的属性Bug重现环境这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。

操作系统这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。

对于不同的操作系统，其可能存在差异（如：win xp 与win 7）或本质的区别（如win 7 与CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。

浏览器对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。

不同的浏览器之间（IE、firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug前提条件之一。

其它（这个“其它”非常重要）对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。

对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使用造成影响。

这些都是重现问题的必须描述的环境。

问题类型根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题（其实，他只是将bug做为一子类而已）。

JIRA系统缺省提供的问题类型（大部分的系统都可以自定义类型的，这样就增加了灵活性。

）•Bug : 测试过程、维护过程发现影响系统运行的缺陷。

（这就是一般测试人员所提交的bug）•New Feature : 对系统提出的新功能。

（单个的小需求可以，如果大的话，就相当于一个需求，放到这里是不合理的。

）•Task : 需要完成的一任务。

Bugfree使用手册

Bugfree使用手册1. Bugfree简介1.1 BugFree网站/1.2 BugFree的Logo1.3 BugFree的来源BugFree是借鉴微软的研发流程和Bug管理理念，使用PHP+MySQL独立写出的一个Bug 管理系统。

简单实用、免费并且开放源代码(遵循GNU GPL)。

如何有效地管理软件产品中的Bug，是每一家软件企业必须面临的问题。

遗憾的是很多软件企业还是停留在作坊式的研发模式中，其研发流程、研发工具、人员管理不尽人意，无法有效地保证质量、控制进度，并使产品可持续发展。

BugFree就是为了解决上述问题而开发的。

1.4 BugFree名称的含义命名BugFree 有两层意思：一是希望软件中的缺陷越来越少直到没有；二是表示它是免费且开放源代码的，大家可以自由使用传播。

1.5 BugFree的功效对软件开发出现的问题进行有效的跟踪管理；协调开发人员、测试人员和需求三方的关系，规范软件的研发流程；通过对问题的有效跟踪管理，可以持续地改进产品的质量；记录对问题的处理过程，可以作为知识的积累；还可以通过自由的定制以让BugFree更适合贵公司的研发流程。

1.6 BugFree适合谁用BugFree适用于所有的中小IT企业、大规模IT企业的各部门、小组、各种技术开发小组或者团队。

1.7 BugFree的一些特色理念先进BugFree借鉴了微软公司成熟的研发流程和Bug管理理念。

相比于其他的Bug管理软件来讲，BugFree的处理方式更加科学、简洁。

B/S结构浏览器/服务器的结构部署起来非常方便，用户无需使用客户端，只要有浏览器(如IE、FireFox等)就可以非常方便的使用BugFree对Bug进行跟踪管理。

跨平台BugFree是采用PHP作为开发语言，采用MySQL作为数据库存储，这两者都是跨平台的，所以BugFree可以安装在所有支持PHP、MySQL的平台上面。

多项目管理BugFree可以同时对多个项目进行管理，非常方便。

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管理教程

n 求软C）件o。测py试r员ig认h为t 软20件1难9-以2理01解9、A不s易p使o用se、P运t行y速L度td缓. 慢，
或者最终用户认为不好。 n 需要注意的是，测试人员报告Bug时，应当保证Bug是可
以重现的。对于有时不可重现的Bug，应当反复测试，直
到最终确定Bug的发生场景为止。
8
报告Bug的基本原则
关闭 bug
整个产品发布后，才可以由测试人员将 bug的状态由 Verified
修改为 CLOSED；开发调试阶段不得关闭 bug
11
有效描述Bug
n 短小：只解释事实和演示、描述Bug必需的细节；
n 单一：每一个报告中针对一个Bug；
果有更多的信息出现，请重新分配这个 bug，而现在只把它归
Resolve&fixed bug 档。
如还有问题， Reopened
验证 bug Verified bug
测试人员验证已修改的 Bug 1、测试人员查询开发者已修改的 bug，即 Status为 "R esolved",R esolution 为 "Fixed".进行重新测试。 2、经验证无误后，修改 R esolution 为 V E R IFIE D 3、若还有问题， REOPENED ，状态重新变为 “ New"，并发邮件通知
过长，C则o会py引r起ig程ht 2019-2019 Aspose Pty Ltd.
序崩溃。