Jira上Bug处理流程
Jira_需求管理_Bug管理
Jira_需求管理_Bug管理需要实现如下⽬标：1. 需求管理, ⼦需求管理（⼀个需求可能拆分成若⼲个细的需求）2. Bug管理3. 需求/⼦需求和Bug相关联，可以看到每个需求相关的Bug数量及进度4. 可以根据条件进⾏搜索，⽐如说想看有多少Open的Bug, 每个开发⼈员Fix bug的进度等Step1: Create Project, select "Basic Software Development" modelNote: The issue type are: New Feature, Task, Sub-task, Bug, you can set different workflow for different issue types.e.g. For New feature workflow, you can set it as New > In progress > Done; For bug workflow, you can set it as: New > Fixed > Closed or New > Fixed > Reopen > Fixed > Closed, it's depend on youThe detail steps to configure workflow for different issue type:1.1 (Set workflow for "New Feature")Project settings > issue types > New Feature > Workflow > Edit1.2 (Set workflow for "Bug")Project settings > issue types > New Feature > Workflow > EditStep2: Create issue for New Feature/bug typeStep3: Create BoardsStep4: Create Sub-task for New feature/task(sub-task是⼤功能下⾯分出来的⼩功能)，只能在看板下⾯创建sub-task？？Note: You can link bugs to related sub-task, then it's clear to know all the bug status for the sub-taskStep5: Configure board, such as only need New, In progress and Done columns5.1 Project settings > Kanban board > Board > Configure > Columns5.2 Modify columsPicture_Step1_1: create projectPicture_Step1_2: default workflowPicture_1.1: configure workflow for different issue types_new featurePicture1.2: configure workflow for different issue types_bugPicture_Step2: create issue for new feature/bug typePicture_Step3: create boardPicture_Step4: create sub-task(open board first)Picture_Step4: create sub-taskPicture_5.1: configure board Picture5.2。
Jira上Bug处理流程
J i r a上B u g处理流程内部编号：（YUUT-TBBY-MMUT-URRUY-UOOY-DBUYI-0128）J i r a上B u g处理流程第一章LIT的Jira上问题处理流程具体处理流程如下：1、LIT测试过程中发现问题，在JIRA上新建Bug，分配Bug给相关Team组长，Bug为Open状态；2、组长接收到邮件通知后，将Bug分配给相应开发人员，Bug保持Open状态；3、开发人员接收到邮件通知后分析问题，若需要修改将Bug状态改为In progress；若不需要修改直接将Bug状态改为Resolved(Won't Fix )；4、开发人员修改Bug完毕后，将Bug状态变更为Resolved(Fixed)；5、LIT对状态为Resolved的Bug进行验证，若验证通过，将Bug状态改为Closed，若验证不通过，将Bug状态改为Reopen；6、对于Reopen状态的bug，重新按上面3-5步骤进行处理，直至问题Closed；7、对于Open或Reopen状态的Bug若是暂时无法解决可以采取挂起的方式，修改Bug为Resolved状态，并设置解决方式为Pending。
第二章 SIT的Jira上问题处理流程SIT的Jira上问题处理流程分为早期版本和新版本（将来版本）两种，对于新版本的流程在Jira上有单独标识，没有标识的即为早期版本。
两种处理流程有所差异。
2.1 早期版本处理流程1、SIT测试过程中发现问题，在JIRA上新建Bug，分配Bug给相关Team组长，Bug为Open状态；2、组长接收到邮件通知后，将Bug分配给相应开发人员，Bug保持Open状态；3、开发人员接收到邮件通知后分析问题，若不需要修改直接将Bug状态改为Resolved(Won't Fix)；若需要修改，在Bug修改完毕后，将Bug状态改为In progress；4、LIT对In Progress状态的Bug进行验证，若验证通过，将Bug状态改为Resolved（Fixed），若验证不通过，将Bug状态改为先Resolved，然后再改为Reopen（受Jira定义的业务流程限制只能按照这种方式来Reopen）；5、SIT对Resolved的Bug进行验证，若验证通过，将Bug状态改为Closed，若验证不通过，将Bug状态改为Reopen；6、对于Reopen状态的Bug，重新按上面3-5步骤进行处理，直至问题Closed；7、对于Open或Reopen状态的Bug若是暂时无法解决可以采取挂起的方式，修改Bug为Resolved状态，并设置解决方式为Pending。
JIRA培训以及缺陷管理
保存的查询 您可以将设定好的查询条件保存起来，作为一个 ‘问题过滤器’，
‘过滤器’可以与其他用户共享，并且可以将‘过滤器’添加到您的 JIRA主面板上。
强大的自由文本内容查询 JIRA 的自由文本搜索支持一套丰富的查询语法，包括逻辑操作，模糊 查询，近似搜索等。
4. 问题报告 JIRA具有高度灵活的报告功能，您可以对JIRA系统中的Issue做出多 种形式的g的问题)
填写缺陷的详细信息
可以在这个页面上进行任务的分配，bug的修复等 、。
分配到这个缺陷的用户会在登陆后看到这个缺陷
（在assign to me）中
接收到这个缺陷可以的用户，在这个缺陷或者任务 上双击，打开如下页面，可以处理这个缺陷
打开“进行中”选项卡，该缺陷就处于in prograss状态。
一个优秀的配比规则:
团队规模
5 6 7 8 9
同时进行的story(WIP) 2 3 3 4 4
引用燃尽图检查，sprint是否按照正常轨道按时完成。 这个评估必须在每天结束时的站会完成。
日常工作: 所有Scrum团队展开一个每日15分钟的站会，在Jira中输入task/所有者/小时 数，输入defects和修复的S1-S2的defects在每一个sprint的结尾，使用燃尽
工作日志
上传界面截图到此问题 可以将剪贴板中的截图附加进来
添加注释 可以添加注释信息到此问题，便于对某些问题的强调
监视 可以监视此问题，所监视问题的状态会实时显示在主页面上
SVN状态监视 上传文件时必须将文件信息描述成带对应问题序号的字符
6. 常用操作
修改密码 可点击右上角个人姓名进入用户资料页面，进行修改密码等操作
做一枚螺丝钉，那里需要那里上。20 .11.23 08:34 :3408 :34No v-202 3-Nov -20
JIRA操作简要说明
JIRA操作简要说明鉴于新平台已经开始在各个项目上开始应用，暴露出来的问题较多，很多问题我们仅仅通过腾讯通、邮件、或者自定义的工具都无法很好的处理Bug流程，这些工具的缺点是他们只能反映问题却不能反映问题解决的过程，不能进行查询和统计，以及积累。
为解决这个问题，我们准备开始试用JIRA管理工具，该工具不仅能够管理缺陷处理流程，还可以处理任务、新功能、完善和改进等，操作极其简单，按照以下说明，几分钟就能上手。
由于是试用，试用过程中出现的问题请及时反馈给黄涌，以便查找解决。
一．提交问题进入http://10.72.6.217:8080弹出如下界面输入用户名和口令进入后，右上角有个创建问题按钮点击创建问题后，会弹出如下界面其中项目包含：集成平台_Net：所有客户端和.Net有关的都选这个。
集成平台_JAVA：所有客户端和JAVA有关的都选这个。
数据管理平台：所有和老平台相关的都选这个。
问题类型包括：缺陷、任务、新功能、完善和改进，大家根据自己的实际情况来选其中一个选择项目和问题类型后，点击创建按钮，将出现以下界面该界面一看就懂，可以上传附件。
注意最好把问题细化，一个问题作为一个缺陷来提交，不然多个问题纠结在一起，既不好分配也不好回复。
这里对优先级做一下说明，也可以点击字段边的?按钮查看：无法进行阻塞开发或测试的工作进度，或影响系统无法运行的错误关键性的系统崩溃，丢失数据或内存溢出等严重错误，或者必须完成的任务重要主要的功能无效、新增功能建议一般功能部分无效或对现有系统的改进建议拼写错误、文本未对齐等模块如果不知道，就选未知描述完问题后，点击创建按钮，问题就创建完了，将会自动提交到我这里。
二．查询问题问题创建后，如果想要了解问题的实时状态，可以选择选择查找问题，将会进入如下页面：在界面的左边就是构造查询条件的编辑界面，一般来讲，只要选择报告人为当前用户就可以了，然后点击查看>>按钮。
结果就出来了，如下图：右边就是查询结果，字段解释如下关键字：为自动生成，可以不管它。
Bug处理流程
杭州家和物联技术有限公司附件2：Bug 处理流程Bug 处理流程市场客服产品测试继续处理研发测试报告填写缺陷与限制，bug 入库，设置状态New研发对提交的Bug 进行重现、评估Bug 收集整理邮件抄送邮件发送Bug 处理判定为无效Bug ，在反馈的测试报告上状态设为Invalid否在JIRA 上创建问题，状态设置为”开始“是判定为拒绝修改或搁置的Bug 测试、产品研发讨论是否搁置是Bug 是否解决JIRA 平台将问题状态设为”已解决“测试测试报告中设Bug 状态为解决是测试报告中将Bug 状态设为Wontfix 并注明原因否缺陷与限制邮件反馈验证Bug 是否修正缺陷与限制邮件反馈是在JIRA 平台上将对应问题状态设为“重新打开”否定期跟踪关注未解决的Bug继续解决JIRA 平台相问题注释进度。
测试报告中设Bug 状态为未解决测试报告中将Bug 状态设置为close否报告Bug ，填写描述情况。
紧急bug 的处理综合技术的Bug 处理结果，更新缺陷与限制分表在JIRA 平台上将对应问题状态设置为“关闭”Bug 管理邮件抄送回复客户反馈流程说明：1、 测试员提交的测试报告缺陷与限制分表将新的Bug 入库，错误状态为New 。
2、 测试员将测试报告发送给相应的开发人员并抄送给产品。
3、 研发对测试报告的缺陷与限制分表中的bug 进行评估反馈。
4、 对于测试报告提交的无效Bug ，研发在表格上其状态置为Invalid 。
5、 对于测试报告提交的Bug ，研发拒绝修改或搁置不改的在表格上设置为Wontfix 。
6、 对于测试报告提交的普通Bug,，研发在JIRA 问题管理平台上创建相关条目，并开始处理，该问题状态为开始，研发修复Bug 后，在平台上将其状态设置为已解决。
7、 对于不能修改或者建议不修改的问题，及时反馈给测试和产品，经讨论决定后，才能置为暂时不修改Wontfix 。
8、 测试员在JIRA 问题管理平台上查询状态为已解决的Bug ，然后验证Bug 是否已解决，如解决则将测试报告缺陷与限制分表中设置Bug 的状态为Close ，如没有解决则让研发在JIRA 问题管理平台上将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． 可输入区域和只读区域没有明显的 区描述所产生的问题导致系统崩溃，蓝屏，停 顿；缺少主要功能或者主要功能毫无作用， 导致无法进行下一步测试。
JIRA的BUG编写规范
∙一、摘要∙二、名词解释∙三、目的∙四、范围∙五、Bug编写规范o 1. 主题o 2. 描述o 3. 环境o 4. 截图o 5. 其他∙六、注意事项一、摘要本文档主要描述了技术产品部测试人员提交Bug时需要遵守的规范。
二、名词解释∙JIRA JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
三、目的规范Bug编写，一方面，可以方便开发人员根据Bug描述快速进行定位问题原因，减少沟通成本，另一方面，可以帮助测试经理、非技术人员、产品经理、开发经理及其他测试人员等了解Bug，第三，可以体现测试团队的专业性、严谨性。
四、范围该文档适合技术产品部测试人员使用，适合于任何产品和项目。
五、Bug编写规范1. 主题为了节约开发阅读Bug时间，同时考虑到开发人员容易通过Bug标题来猜想Bug，所以，Bug标题显得尤为重要。
以下为Bug标题编写时需要遵守的规范。
1）用简短的语句描述问题，主题文字过多，增加开发阅读Bug时间。
2）格式：在什么位置，在什么条件下，做什么操作，操作的结果。
∙在什么位置：问题所在的路径，格式为“XX-页面：”∙在什么条件下：如果问题为兼容性Bug，比如浏览器兼容或者分辨率兼容。
格式为“在IE11浏览器下，”，如果Bug不属于兼容性问题，不用加此描述。
∙做什么操作：问题触发的动作，比如：“执行审批通过”。
∙操作的结果：即问题的表象，比如：字段“报送时间”取值不对、报404错误。
格式举例：采购中心-招标计划详情：在IE11浏览器下，展开“查看参与人员”，内容错乱。
3）除了第二点描述的格式，对于Bug描述，除了描述实际的结果外，有时候我们会直接描述期望结果，比如，集采销售-招标计划列表：列表字段“填报时间”应该修改为“报送时间”。
4）描述无歧义。
Bug描述如果有歧义，开发容易因为改错Bug，导致增加Bug修复成本。
Jira工具操作手册
Jira工具操作手册Jira工具操作手册关于本文档主题Jira工具操作手册说明说明需求管理及bug管理流程操作适用对象所有员工修订历史版本章节类型日期作者说明类型说明：创建（C）、修改（U）、删除（D）、增加（A）；评审记录角色签名日期说明目录1.登录 (1)1.1.登录网址 (1)1.2.登录操作 (1)2.总体流程 (2)2.1.需求管理流程 (2)2.2.缺陷管理流程 (3)3.需求管理操作流程 (3)3.1.新建需求 (3)3.2.需求分析 (5)3.3.需求评审 (6)3.4.创建子任务 (7)3.5.需求评审完成 (9)3.6.排期 (9)3.7.开发 (11)3.8.待升级测试环境 (12)3.9.待测试 (13)3.10.集成测试 (14)3.11.待升级UAT环境 (15)3.12.UAT冒烟测试 (16)3.13.待UAT测试 (17)3.14.UAT测试 (18)3.15.待业务验收 (19)3.16.待升级冻结环境 (20)3.17.待冻结测试 (21)3.18.待升级生产环境 (22)3.19.已上线 (23)3.20.打回 (24)3.21.暂停 (25)3.22.取消 (26)4.缺陷管理操作流程 (28)4.1.新建B UG (28)4.2.开始进行 (29)4.3.解决 (30)4.4.关闭 (31)5.其他操作 (33)5.1.编辑 (33)5.2.分配 (34)5.3.问题分类查看 (35)1.登录1.1.登录网址登录网址：http://localhost:8000/用户名：姓名全拼默认密码：1234561.2.登录操作输入登录网址，进入登录界面，如下图所示。
图错误!文档中没有指定样式的文字。
-1输入用户名、密码，点击登录，进入jira管理工具首页，如下图所示。
目前安心创建为大家创建了两个公共面板，左侧为正在进行中的任务，右侧公共面板正在配置。
图错误!文档中没有指定样式的文字。
JIRA bug提交管理规范
1. BUG 管理工具介绍 (3)2. BUG 定义 (3)1. BUG 分类 (3)2. Bug 等级 (3)3. Bug 状态 (4)4. Bug 优先级 (4)3. BUG 的生命周期 (4)4. BUG 管理规范 (5)1) 项目的创建 (5)项目名称及代号规范 (5)项目的模块及版本划分规范 (5)用户角色权限分配规范 (6)2) BUG 提交规范 (6)BUG 的报告内容 (6)主题，即BUG 简要描述 (7)严重程度选择 (7)优先级选择 (8)模块及版本选择 (8)环境 (9)BUG 详细描述 (9)其他规范 (9)3) BUG 分配及处理 (10)BUG 的分配 (10)BUG 处理 (10)4) BUG 验证及关闭 (10)常用的BUG 管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb 等。
我们公司采用的是JIAR，JIRA 是Atlassian 公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求采集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
BUG 就是指系统存的各种缺陷，可以从不少角度对BUG 进行分类。
A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。
A.界面不美观，控件罗列、格式不统一，焦点控制不合理或者不全面；B.缺少匡助信息，或者匡助信息不彻底；C.功能操作复杂，提示信息不合理，易产生歧义。
A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或者认证不合理；D.数据产生缺乏随机性；E．网络安全性：开放端口、服务；F ．系统日志、审计。
A.数据存贮的可靠性；B.业务处理的可靠性；C．硬件可靠性：如打印机；D.应急处理措施；E ．数据备份、恢复。
A．并发量；B．吞吐量； C ．响应时间。
A．硬件兼容性； B ．软件兼容性。
A．可扩展性； B ．方便升级。
jira常见问题的工作流程
jira常见问题的工作流程Jira是一种流行的项目管理工具，广泛应用于各种组织中。
在使用Jira时，经常会遇到一些常见问题，需要有一定的工作流程来解决。
下面将介绍一种常见的工作流程来处理Jira常见问题。
首先，当用户遇到Jira中的问题时，他们可以通过创建工单来报告问题。
工单应包含详细的描述，以及任何属于问题的相关信息，例如截图或日志文件。
接下来，问题将被分配给相应的团队成员进行处理。
可以通过在Jira中设定责任人来实现分配。
责任人应该具备解决该问题所需的技能和知识。
一旦问题被分配，责任人将开始进行问题的调查和分析。
这可能涉及检查Jira 配置、检查日志文件、尝试重现问题等。
在此过程中，责任人可能会与报告问题的用户进行沟通，以获取更多的细节或进行进一步的测试。
一旦问题的根本原因被确定，责任人将开始制定解决方案。
这可能包括修复配置问题、应用补丁、更新软件版本等。
在此阶段，责任人可以在Jira中添加注释，以便其他团队成员了解解决方案的进展。
解决方案准备好后，责任人将开始实施，并在Jira中进行相应的更改或修复。
他们还可以为将来遇到类似问题的其他用户创建文档或知识库条目，以便可以更好地解决类似问题。
一旦问题解决，责任人可以关闭工单，并通知报告问题的用户。
如果问题尚未解决，责任人可以将工单重新打开，并继续进行进一步的调查和解决。
总结起来，处理Jira常见问题的工作流程包括报告问题、分配责任人、调查和分析问题、制定解决方案、实施和验证解决方案，以及关闭工单。
通过规范化问题处理流程，可以更高效地解决Jira中遇到的问题，并提供更好的用户体验。
JIRA用户使用手册
1登陆1、要进入JIRA的BUG跟踪系统，用户需要打开浏览器输入如下地址：2、用户需要输入JIRA验证，用户名就是管理员分配的用户名，密码是管理员给设置的初始密码（用户登录后可自行修改密码和用户名，但用户名只是JIRA界面内你自己看到的用户名而不是你登录时输入的名字）3、接着会进入JIRA的主界面2创建问题2.1 创建问题2.1.1 可实现功能◆创建一个新的问题。
2.1.2 操作步骤◆在首页左上角单击“创建问题”，进入选择选项目和问题类型界面。
◆单击“下一步”◆添加所有信息，然后单击“Create”完成操作。
◆在添加完的界面里：1、单击“分配”可以进入分配界面，把问题再分配给别的人处理。
2、单击“上传附件”可以把和这个问题有关的信息以附件形式上传，便于沟通。
3、单击“屏幕截图”可以更直观的把不能用文字描述的问题让被分配人员了解。
4、单击“复制”可以对这个问题进行复制，便于项目内部的问题重复修改。
（注：本功能点的复制只能是项目内部的不能是部门间项目的复制）5、单击“写备注”可以对问题进行详细描述。
6、单击“删除”可以对问题进行删除。
7、单击“链接”可以把部门内部多个项目间的问题进行关联，便于管理问题的重复开发和修改。
8、单击“移动”可以把一个问题从一个项目移到另一个项目，可以缓解部门间有些项目组忙时的压力。
9、单击“监测”，可以设置你监测此问题，方便部门内部大家的互相学习，把自己不会的看别人怎么解决。
3配置管理3.1 配置管理3.1.1 可实现功能◆管理自己的信息，修改自己需要的设置。
3.1.2 操作步骤◆在首页的右上角单击“配置”，在这个页面里你可以看到自己的配置信息。
3.2 个人分布图3.2.1 可实现功能◆查看所有项目和自己能修改的项目分布图,通过查看全局分布图可以看到各种与自己相关的报告信息和选择过滤器浏览相关问题信息。
3.2.2 操作步骤◆单击“个人分布图”，进入界面页面。
3.3 你的投票3.3.1 可实现功能◆投票可以设置你对某个问题的态度是支持还是反对。
bugzilla使用说明
如有你有帮助，请购买下载，谢谢！一：提交bug的过程：1.点击登陆2.登陆后选择File a bug 然后点击所要提交产品的名称3.在bug页面填写相应的信息包括组件、版本、bug概述、详述添加附件、提交bug描述bug的时候最好按详述里了的格式进行描述添加附件点击“浏览”选择好附件路径及添加附件描述4.点击“Submit Bug”提交后就进入下一级页面。
QA contact 是默认的暂时不做选择在Assigned处选择相关的项目负责人、在Status处选在“UNCONFIRMED”、在CC List里面添加要抄送人，然后点击”Save change”就可以了。
二：搜索bug的流程1.登陆之后点击search 进入一般搜索页面，选择所要查找的状态、产品或者输入关键字然后点击search 按钮就ok了2.在高级搜索页面选择相应的搜索项或者输入关键字进行搜索就ok了三：特殊说明：1.关于Flags说明如图中：“？”表示被用户请求“+”表示通过“-”表示拒绝Bug和附件里面都有Flags 表示bug和附件是通过还是拒绝2 .bug操作流程图1）测试人员提交bug给项目负责人（assigned）2）项目负责人负责确认bug 并且分配bug。
（若不是bug直接把状态改成resoloved I invalid，若是bug就把bug状态修改为confirmed然后分配给开发人员）3）若分配错开发人员可直接返回项目负责人让其进行重新分配4）开发人员修改bug的时候bug状态为confirmed5）修改好后bug状态有confirmed变成Resoloved fixed6）测试人员看到Resoloved fixed状态后或者是收到邮件后进行bug验证7）验证通过就直接关闭，若不通过就reopen然后在返回给项目负责人。
1页。
JIRA-缺陷生命周期流程图
JIRA-缺陷生命周期流程图
NEW
缺陷发现者发现并确认缺陷，最后提交缺陷。
POSTPONE OPEN
DUPLICATE ABANDON
PM/CCB 发现提交的缺陷是优先级低的，决
定延迟
PM/CCB 发现提交的缺陷是优先级比较高的，决定打开缺陷
PM/CCB 发现提交的缺陷并不是真正的缺陷
PM/CCB 发现提交的缺陷和以前的缺陷重
复了
DEV （开发人员）
FIXED
TESTER （测试人员）
REOPEN
最后期限初始化
CLOSED
REJECTED
开发人员认为该缺陷不是DEFECT
PM/CBB （项目经理/变更控制委员
会）
开发人员确认该缺陷是DEFECT
在测试中后期，PM/CCB 不得不打开延迟的DEFECT TESTER （测试人员）
回归测试未通过
回归测试通过
测试人员发现该缺陷确实是DEFEC T
测试人员发现该缺陷确实重复
PM/CBB （项目经理/变更控制委员会）测试人员认为确实是DEFE CT TESTER （测试人员）
测试人员发现提交的缺陷并不是真正的缺陷。
JIRA的BUG管理规范
XXXXXXXXXXXXXXXXXXXXXXXXXX 测试组BUG管理规范版本历史目录1BUG管理工具介绍 (3)2BUG定义 (3)2.1BUG分类 (3)2.2Bug等级 (4)2.3Bug状态 (4)2.4Bug优先级 (5)3BUG的生命周期 (5)4BUG管理规范 (6)4.1项目的创建 (6)4.1.1项目名称及代号规范 (7)4.1.2项目的模块及版本划分规范 (7)4.1.3用户角色权限分配规范 (7)4.2BUG提交规范 (7)4.2.1BUG的报告内容 (8)4.2.2问题类型选择 (9)4.2.3BUG简要描述 (11)4.2.4优先级选择 (11)4.2.5模块及版本选择 (11)4.2.6BUG详细描述 (11)4.2.7其他规范 (12)4.3BUG分配及处理 (12)4.3.1BUG的分配 (12)4.3.2BUG处理 (13)4.4BUG验证及关闭 (13)1BUG管理工具介绍常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。
我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
2BUG定义2.1BUG分类BUG 就是指系统存的各种缺陷，可以从很多角度对BUG进行分类。
1、从功能方面分，产生BUG的原因大体可以归结为以下四种：A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。
2、从易用性方面分，可以归结为三点：A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不完全；C.功能操作复杂，提示信息不合理，易产生歧义。
3、从安全性方面分，BUG可以划分为以下几类：A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或认证不合理；D.数据产生缺乏随机性；E．网络安全性：开放端口、服务； F．系统日志、审计。
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 : 需要完成的一任务。
JIRA使用说明-使用者-基本功能
JIRA使⽤说明-使⽤者-基本功能JIRA操作说明——基本设置、问题的建⽴与解决梁红坡郑州研发中⼼编程课上海瑞星软件有限公司⽬录1. 使⽤要求 (1)2. 关于问题的概念 (1)2.1. 问题类型 (1)2.2. 优先级 (1)2.3. 状态 (2)2.4. 解决 (3)3. 个⼈信息的设置： (3)4. 基本操作 (3)4.1. 新建问题 (3)4.2. 处理问题 (6)4.3. 问题解决完毕 (7)Jira是澳⼤利亚atlassian公司开发的⼀款优秀的问题跟踪及管理软件⼯具，可以对各种类型的问题进⾏跟踪管理，包括缺陷、任务、需求、改进等。
本⽂档主要介绍jira基本的⽤户设置，以及如何建⽴和解决问题。
⽂档中的截图来⾃jira4.4.1。
1. 使⽤要求使⽤IE7及以上版本，jira 4.4.1不⽀持IE6.0运⾏过程中可能产⽣⼤量IE缓存⽂件，所以请及时清理，以免造成运⾏速度越来越慢，最后导致浏览器⽆法打开或死机。
系统采⽤BS模式，登录地址为http://192.168.1.253:8080/secure/Dashboard.jspa，通过浏览器登录并操作，不需要进⾏下载安装。
2. 关于问题的概念JIRA跟踪问题（issue），这些问题可以是BUG，功能请求或者任何其他你想要跟踪的任务。
以下是⼀些关于问题的基本概念。
2.1. 问题类型jira系统跟踪多种不同的问题，你可以⽤问题类型区分Bug 测试过程、维护过程发现影响系统运⾏的缺陷New feature 对系统提出的新功能Task 需要完成的任务Improvement 对现有系统功能的改进2.2. 优先级表⽰问题的严重级别，以下为jira的默认设定Blocker 阻塞开发或测试的⼯作进度，或影响系统⽆法运⾏的错误Critical 系统崩溃，丢失数据或内存溢出等严重错误，或者必须完成的任务Major 主要的功能⽆效、新增功能建议Minor 功能部分⽆效或对现有系统的改进Trivial 拼写错误，⽂本未对齐等2.3. 状态⽤来表明问题所处的阶段，问题通常开始于open状态，然后开始处理/progress，再到解决/resolved，然后被关闭/closed。
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添加附件、截图提交问题完成之后我们可以给提交的问题添加附件和截图。
Jira上Bug处理流程
J i r a上B u g处理流程第一章LIT的Jira上问题处理流程具体处理流程如下：1、LIT测试过程中发现问题,在JIRA上新建Bug,分配Bug给相关Team组长,Bug为Open状态；2、组长接收到邮件通知后,将Bug分配给相应开发人员,Bug保持Open状态；3、开发人员接收到邮件通知后分析问题,若需要修改将Bug状态改为In progress；若不需要修改直接将Bug状态改为ResolvedWon't Fix ；4、开发人员修改Bug完毕后,将Bug状态变更为ResolvedFixed；5、LIT对状态为Resolved的Bug进行验证,若验证通过,将Bug状态改为Closed,若验证不通过,将Bug状态改为Reopen；6、对于Reopen状态的bug,重新按上面3-5步骤进行处理,直至问题Closed；7、对于Open或Reopen状态的Bug若是暂时无法解决可以采取挂起的方式,修改Bug为Resolved状态,并设置解决方式为Pending;第二章 SIT的Jira上问题处理流程SIT的Jira上问题处理流程分为早期版本和新版本将来版本两种,对于新版本的流程在Jira上有单独标识,没有标识的即为早期版本;两种处理流程有所差异;2.1 早期版本处理流程1、SIT测试过程中发现问题,在JIRA上新建Bug,分配Bug给相关Team组长,Bug为Open状态；2、组长接收到邮件通知后,将Bug分配给相应开发人员,Bug保持Open状态；3、开发人员接收到邮件通知后分析问题,若不需要修改直接将Bug状态改为ResolvedWon't Fix；若需要修改,在Bug修改完毕后,将Bug状态改为In progress；4、LIT对In Progress状态的Bug进行验证,若验证通过,将Bug状态改为ResolvedFixed,若验证不通过,将Bug状态改为先Resolved,然后再改为Reopen受Jira定义的业务流程限制只能按照这种方式来Reopen；5、SIT对Resolved的Bug进行验证,若验证通过,将Bug状态改为Closed,若验证不通过,将Bug状态改为Reopen；6、对于Reopen状态的Bug,重新按上面3-5步骤进行处理,直至问题Closed；7、对于Open或Reopen状态的Bug若是暂时无法解决可以采取挂起的方式,修改Bug为Resolved状态,并设置解决方式为Pending;2.2 新版本将来版本处理流程1、SIT测试过程中发现问题,在JIRA上新建Bug,分配Bug给相关Team组长,Bug为Open状态；2、组长接收到邮件通知后,将Bug分配给相应开发人员,Bug变更为Assign状态,若是选择Accept表示将问题分配给自己；3、开发人员接收到邮件通知后分析问题,若不需要修改直接将Bug状态改为ResolvedWon't Fix；若需要修改,在Bug修改完毕后,将Bug状态改为ResolvedFixed；4、LIT对Resolved状态的Bug进行验证,若验证通过,将Bug状态改为LIT Verified,若验证不通过,将Bug 状态改为Reopen；5、SIT对LIT Verified状态的Bug进行验证,若验证通过,将Bug状态改为Closed,若验证不通过,将Bug状态改为Reopen；6、对于Reopen状态的Bug,重新按上面3-5步骤进行处理,直至问题Closed；7、对于Assigned或Reopen状态的问题若是暂时无法解决可以采取挂起的方式,修改Bug为Pending;第三章备注在上述LIT的Jira处理流程和SIT的Jira处理流程中,研发对于Bug状态的修改必须添加相应备注信息;备注信息说明如下：1、开发人员修改Bug状态时,应在备注中填写问题产生的原因和解决方案；2、LIT测试人员修改Bug状态时,应在备注中填写Bug验证结果,并提交问题具体解决的版本号。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
J i r a上B u g处理流程第一章LIT的Jira上问题处理流程
具体处理流程如下：
??1、LIT测试过程中发现问题，在JIRA上新建Bug，分配Bug给相关Team组长，Bug为Open状态；
???2、组长接收到邮件通知后，将Bug分配给相应开发人员，Bug保持Open状态；
???3、开发人员接收到邮件通知后分析问题，若需要修改将Bug状态改为Inprogress；若不需要修改直接将Bug 状态改为Resolved(Won'tFix)；
???4、开发人员修改Bug完毕后，将Bug状态变更为Resolved(Fixed)；
???5、LIT对状态为Resolved的Bug进行验证，若验证通过，将Bug状态改为Closed，若验证不通过，将Bug状态改为Reopen；
6、对于Reopen状态的bug，重新按上面3-5步骤进行处理，直至问题Closed；
7、对于Open或Reopen状态的Bug若是暂时无法解决可以采取挂起的方式，修改Bug为Resolved状态，并设置解决方式为Pending。
第二章SIT的Jira上问题处理流程
???SIT的Jira上问题处理流程分为早期版本和新版本（将来版本）两种，对于新版本的流程在Jira上有单独标识，没有标识的即为早期版本。
两种处理流程有所差异。
2.1早期版本处理流程
??1、SIT测试过程中发现问题，在JIRA上新建Bug，分配Bug给相关Team组长，Bug为Open状态；
???2、组长接收到邮件通知后，将Bug分配给相应开发人员，Bug保持Open状态；
???3、开发人员接收到邮件通知后分析问题，若不需要修改直接将Bug状态改为Resolved(Won'tFix)；若需要修改，在Bug修改完毕后，将Bug状态改为Inprogress；
???4、LIT对InProgress状态的Bug进行验证，若验证通过，将Bug状态改为Resolved（Fixed），若验证不通过，将Bug状态改为先Resolved，然后再改为Reopen（受Jira定义的业务流程限制只能按照这种方式来Reopen）；
???5、SIT对Resolved的Bug进行验证，若验证通过，将Bug状态改为Closed，若验证不通过，将Bug状态改为Reopen；
???6、对于Reopen状态的Bug，重新按上面3-5步骤进行处理，直至问题Closed；
7、对于Open或Reopen状态的Bug若是暂时无法解决可以采取挂起的方式，修改Bug为Resolved状态，并设置解决方式为Pending。
2.2新版本（将来版本）处理流程
1、SIT测试过程中发现问题，在JIRA上新建Bug，分配Bug给相关Team组长，Bug为Open状态；
???2、组长接收到邮件通知后，将Bug分配给相应开发人员，Bug变更为Assign状态，若是选择Accept表示将问题分配给自己；
???3、开发人员接收到邮件通知后分析问题，若不需要修改直接将Bug状态改为Resolved(Won'tFix)；若需要修改，在Bug修改完毕后，将Bug状态改为Resolved（Fixed）；
???4、LIT对Resolved状态的Bug进行验证，若验证通过，将Bug状态改为LITVerified，若验证不通过，将Bug 状态改为Reopen；
???5、SIT对LITVerified状态的Bug进行验证，若验证通过，将Bug状态改为Closed，若验证不通过，将Bug 状态改为Reopen；
6、对于Reopen状态的Bug，重新按上面3-5步骤进行处理，直至问题Closed；
7、对于Assigned或Reopen状态的问题若是暂时无法解决可以采取挂起的方式，修改Bug为Pending。
第三章备注
在上述LIT的Jira处理流程和SIT的Jira处理流程中，研发对于Bug状态的修改必须添加相应备注信息。
备注信息说明如下：
1、开发人员修改Bug状态时，应在备注中填写问题产生的原因和解决方案；
2、LIT测试人员修改Bug状态时，应在备注中填写Bug验证结果，并提交问题具体解决的版本号。