禅道bug提交管理规范
BUG管理规范与流程
实用标准文档BUG管理流程与规范目录1概述 (4)1.1编写目的 (4)1.2适用范围 (4)2关键角色及应负责任 (4)3BUG流程图 (5)4活动描述 (5)5BUG书写规范 (7)5.1测试人员BUG提交 (7)5.1.1主题 (7)5.1.2步骤 (7)5.1.3实际结果 (7)5.1.4预期结果 (7)5.1.5备注 (8)5.2开发人员解决BUG (8)6BUG严重等级 (9)6.1致命 (9)6.2严重 (9)6.3一般 (10)6.4优化 (10)7BUG优先级 (10)7.1紧急 (10)7.2高 (11)7.3中 (11)7.4低 (11)8BUG解决方案 (11)8.1设计如此 (11)8.2重复BUG (11)8.3已解决 (11)8.4无法重现 (11)8.5延期处理 (11)8.6新增/变更需求 (11)9BUG状态 (11)9.1激活 (11)9.2已解决 (11)9.3关闭 (11)10其他要求 (12)11相关文件 (12)12附件 (12)1概述1.1编写目的本文档定义bug的整个生命周期，规范bug的管理流程。
Bug在流转的过程中有章可循。
规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。
1.2适用范围本文档适用测试人员、开发人员。
2关键角色及应负责任5BUG书写规范5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题，不要写成一大段•以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题•描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号，一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤，避免问题被以“不能重现”关掉•设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；•尽量用动词作为开头，描述每个步骤。
禅道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)1.目的本文档定义了bug管理流程及其bug相关信息容。
本文档适用围：●本文档适用于新产品以及以后新产品的项目。
原有项目的bug管理仍然用JIRA系统进行管理。
●本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。
2. 禅道系统Bug流程图3. Bug流程操作及其Bug相关信息解释3.1.测试人员发现bug3.2.测试人员创建Bug测试人员登录禅道系统，创建Bug。
Bug状态为激活（未确认）创建Bug页面截图：页面字段注释：所属产品：选择发现Bug的产品，必填项。
所属模块：选择发现Bug的对应模块，必填项。
所属项目：选择测试所属的项目。
必填项。
影响版本：选择发现bug的版本。
必填项。
当前指派：选择指派的开发人员。
必填项。
Bug标题：用简单明了的语句说明Bug容，相当于BUG的中心语句。
必填项。
在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。
必填项。
[环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在重现步骤里详细描述环境信息，以便于开发定位和解决问题。
[步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。
[结果]：写明操作的实际结果。
[期望]：写明操作的期望结果。
相关需求：选择与Bug相关的需求。
如果Bug关联测试用例，系统会自动关联测试用例的需求。
相关任务：选择与Bug相关的任务。
这里的任务是在『项目』->『任务』中创建的任务。
Bug类型如下：●代码错误：功能性错误。
禅道bug流程
bug管理规范及流程1 概述本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。
Bug在流转的过程中有章可循。
规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决；2 关键角色及职责3 Bug的生命周期4 Bug解决方案Bug解决方案分为：已解决、外部原因、设计如此、重复bug、无法重现、延期解决、不予解决一、无争议类A.解决方案已解决开发已修复的bug：bug解决方案置为已解决；同时添加说明错误原因、解决办法；示例：问题原因：未作条件判断解决方法：进行合理边界判断B.解决方案外部原因开发认为不是bug：bug解决方案置为外部原因；指派给bug提出者；同时注明置为外部原因的理由；示例：C.解决方案无法重现无法重现的bug：主要依赖日志分析问题原因，然后进行对应的修改；开发修改后，测试追溯3个版本、或者使用测试工具反复测试，如没有重现则先关闭；并注明关闭版本号；D.解决方案延期解决需延期的bug：将bug解决方案置为延期解决，并注明延期理由；示例：E．解决方案重复bug开发认为bug重复：将bug解决方案置为重复bug，并标注重复bug的ID，并备注原因。
二、争议类测试、开发有争议的bug：备注争议内容，并指派给对应产品，进行讨论确认修改方案；讨论后产品备注解决办法，并指派给对应的开发or测试；A、产品确认需要修改的bug：将bug指派给对应的开发人员，并注明修改内容；示例：B、产品确认不需要修改的bug：将bug解决方案置为设计如此、不予解决，并注明不需要修改原因，指派给bug创建人员；示例：三、测试关注点：开发已修复，测试验证通过的bug：关闭bug，并注明通过或者现状；示例：验证通过开发已修复，测试验证不通过的bug：将bug激活，并根据实际情况注明激活理由；示例：5 Bug状态激活：开发还未解决的问题状态；已解决：开发人员已确认或已修复的问题状态；已关闭：测试验证，确定已解决的问题状态；6 Bug严重程度1级：不能执行正常的功能操作，或者因产品原因导致系统死机，需马上修复的问题示例：程序无法启动，或者登录；程序崩溃、停止运行，系统死机，无法进行下一步的操作2级：部分功能存在严重缺陷，尚可继续测试，不影响产品稳定性；示例：偶现的程序崩溃、停止运行功能未实现数据不同步功能错误，无法进行后续操作3级：次要功能或者界面存在的一些错误，不影响正常测试；示例：界面UI显示和效果图不一致；提示语不正确；错别字；查询结果显示错误4级：测试对于产品的一些改进建议；7 Bug优先级4级：对产品的影响比较小，在时间不允许的情况下可以暂时不修改；3级：必须修改，不一定马上修改，需讨论确定在某个特定的里程碑前修改完；2级：必须在版本发布之前修改完；1级：影响测试，需立即或者下一个版本修复；8 其他注意事项1) 开发人员没有关闭bug的权限，所有问题均需经过测试验证无误后才可关闭；2) 开发、测试双方有争议的bug，必须经过产品的确认才可进行下一步的操作；3) 测试需及时验证已修复bug；4) 产品人员可以根据产品的阶段性需求重新分配bug解决的优先级；5) 重新指派bug后，需要口头或者QQ告知对方；6) bug的优先级划分比较重要；7) 开发人员解决bug时，动了已经测试通过的模块，需要备注一下影响范围；（注：专业文档是经验性极强的领域，无法思考和涵盖全面，素材和资料部分来自网络，供参考。
禅道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)1.目的本文档定义了bug管理流程及其bug相关信息内容。
本文档适用范围：●本文档适用于新产品以及以后新产品的项目。
原有项目的bug管理仍然用JIRA系统进行管理。
●本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。
2. 禅道系统Bug流程图3. Bug流程操作及其Bug相关信息解释3.1.测试人员发现bug3.2.测试人员创建Bug测试人员登录禅道系统，创建Bug。
Bug状态为激活（未确认）创建Bug页面截图：页面字段注释：所属产品：选择发现Bug的产品，必填项。
所属模块：选择发现Bug的对应模块，必填项。
所属项目：选择测试所属的项目。
必填项。
影响版本：选择发现bug的版本。
必填项。
当前指派：选择指派的开发人员。
必填项。
Bug标题：用简单明了的语句说明Bug内容，相当于BUG的中心语句。
必填项。
在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。
必填项。
[环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在重现步骤里详细描述环境信息，以便于开发定位和解决问题。
[步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。
[结果]：写明操作的实际结果。
[期望]：写明操作的期望结果。
相关需求：选择与Bug相关的需求。
如果Bug关联测试用例，系统会自动关联测试用例的需求。
相关任务：选择与Bug相关的任务。
这里的任务是在『项目』->『任务』中创建的任务。
Bug类型如下：代码错误：功能性错误。
禅道使用规范
-----WORD格式--可编辑--专业资料-----
1、常用模块：“我的地盘”我做主
2、优先级说明：数值越小优先级越高，1的优先级最高，4最低
3、任务处理说明：原则上按照任务截止日期安排处理
4、测试人员创建bug规范
4.1 标题：简明扼要
4.2 问题描述：
1）【操作步骤】要简明清晰，按照实际操作步骤记录
2）【结果】要描述清楚，必须要有截图，标记处错误位置，按照需要配有说明文字3）【预期】给出正确的预期结果
4.3 优先级按照实际标出
4.4 环境、浏览器要按照实际选择
4.5 对与登录用户的，需提供用户账户信息
5、测试人员bug处理规范
5.1 原则上当天4点前的bug当天回归结束
5.2 测试失败的bug，激活，要写明激活原因和现象描述
5.3 未写明问题原因的bug，激活处理
6、开发bug处理说明
6.1 无法重现的bug要跟bug提出人确认后关闭，减少bug激活次数
6.2 原则上不允许出现不予解决
6.3关闭bug要选择原因分析，备注说明具体的原因，否则测试退回处理
7、线上bug建任务处理，标题以【bug】开头
--完整版学习资料分享----。
(完整word版)禅道项目管理系统操作规范V1
项目管理系统（禅道）操作规范V1。
0编写人:审核人:目录前言 (4)项目侧 (5)一、创建项目 (5)二、组建团队 (6)三、关联需求 (7)四、需求分解: (7)五、创建版本: (8)六、提交测试: (9)七、文档管理 (12)八、项目维护 (13)产品侧 (14)一、创建产品 (14)二、创建需求 (15)三、评审需求 (17)四、变更需求 (18)五、添加产品模块 (19)六、文档 (21)七、建立计划 (22)八、发布 (23)开发侧 (25)一、参加项目计划会议, 领取分解任务 (22)二、领取任务, 并每天更新任务 (22)三、确认bug, 解决bug (23)测试侧 (29)一、创建测试用例 (29)二、执行用例 (30)三、评审用例 (30)四、管理测试任务 (31)五、提交bug (33)六、验证bug (33)售后侧 (35)一、录入在线bug (35)二、跟踪bug (36)前言本规范用于公司使用禅道管理系统时的操作规范,明确各个角色按照本规范对项目管理进行操作和录入.实现公司项目组在项目、产品、研发、测试上的统一管理。
适用范围: 大研发体系各项目组项目侧一、创建项目➢项目副组长角色进入项目视图,点击右侧的”添加项目“链接。
图1➢项目添加的页面项目副组长需要在这个页面设置项目名称、代号、起止时间、可用工作日、团队名称、项目、项目描述和关联产品, 访问权限。
图2●注意事项:●项目代号是一种隐喻, 最终以合同号为准。
●团队名称, 可以自己定义,比如叫做“XX开发团队”等等。
二、在添加项目的时候, 选择关联与之相关的产品, 以便后续进行需求的关联.三、项目可以控制它的访问权限, 分为默认、私有和自定义白名单三种。
四、组建团队➢项目组建之后要做的事情就是设置团队图3➢进入团队管理页面项目副组长需在“用户”列指定组建的项目团队成员, 角色列可自定义也可用该用户的默认角色,并且需补充每个用户的可用工日和每天的可用工时.图4注意事项:五、可用工作日和可用工时每天需要仔细设置。
bug管理规范及流程
bug管理规范及流程1、概述本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。
Bug在流转的过程中有章可循。
规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决；2、关键角色及职责3、Bug生命周期4、Bug书写规范4.1 BUG标题1)以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问题；2)描述问题时要简练、直接切入主题，但是要抓住要点；3)偶现bug在主题前标注出现的次数；4)有些模块功能比较多，可以在主题描述前标注上具体得操作；示例：【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息【偶现2次】添加载体库时程序停止运行4.2重现步骤说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志1) 用数字编号，一步步的描述问题的重现步骤；2) 不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个bug汇报一个问题；3) 偶现问题必须明确bug出现的时间、提供截图以及日志；5、Bug解决方案当天提交的新建状态bug，对应的开发人员需在2天内全部审核一遍，将bug分成以下3类：拒绝、进行中、延期、反馈（给产品）；开发已修复的bug：将bug状态置为已解决；同时添加说明验证版本号、错误原因、解决办法；示例：验证版本：V1.0.1.1101（1101表示在11月1号可以验证）问题原因：未作条件判断解决方法：进行合理边界判断开发认为不是bug：将bug状态置为已拒绝；指派给bug提出者；同时注明拒绝理由；示例：参考XXX设计，测试人员理解错误；bug缺乏必要的信息，无法重现：将bug状态置为已拒绝（无法重现）；指派给bug提出者；同时注明拒绝理由；示例：缺少必须日志；开发已修复，测试验证通过的bug：将bug状态置为关闭，并注明通过版本号；示例：V1.0.1.1103验证通过开发已修复，测试验证不通过的bug：将bug状态置为打回（激活），并根据实际情况注明反馈理由；示例：V1.0.1.1103版本验证此问题仍然存在；步骤：XXX出现时间：XXX测试环境：XXX截图、日志；测试、开发有争议的bug：指派给对应产品经理，进行讨论确认修改方案；由产品经理编辑bug状态为激活/不予处理/转为需求，并注明理由。
禅道bug管理流程
禅道bug管理流程在软件开发过程中，bug管理是一个至关重要的环节。
禅道作为一款优秀的项目管理工具，其bug管理流程也是非常完善的。
接下来，我们将详细介绍禅道bug管理的流程。
首先，需要明确的是，bug管理的目标是及时发现和解决软件中存在的问题，保证软件的质量。
在禅道中，bug管理流程主要包括bug的提交、确认、分配、解决和验证等步骤。
1. Bug的提交。
在禅道中，任何一个项目成员都可以提交bug。
当发现软件中存在问题时，需要及时将bug提交到禅道中。
在提交bug时，需要填写详细的bug描述，包括bug的现象、复现步骤、期望结果和实际结果等信息。
同时，需要选择bug的严重程度、优先级和所属模块等属性，以便后续的处理和跟踪。
2. Bug的确认。
提交bug后，项目负责人或测试人员会对bug进行确认。
他们会根据提交的bug描述和复现步骤，尝试复现bug并确认其有效性。
如果确认bug有效，则会继续进行后续的处理；如果确认bug无效，则会关闭该bug，并给出相应的解释。
3. Bug的分配。
确认有效的bug会被分配给相应的开发人员进行处理。
在分配bug时，需要考虑bug的严重程度和优先级，合理安排开发人员的工作任务。
同时，需要及时通知开发人员bug的相关信息，确保他们能够及时了解bug的情况并进行处理。
4. Bug的解决。
开发人员接收到bug后，会进行分析和定位，并尽快进行bug的修复。
在修复bug时，需要编写相应的代码，并进行测试验证。
修复完成后，需要将代码提交到版本控制系统中，并将bug状态更新为“已解决”。
5. Bug的验证。
在bug被解决后，测试人员会对bug进行验证。
他们会根据bug的描述和修复情况，尝试复现bug并验证其是否已经被解决。
如果bug已经被成功解决，则会关闭该bug，并进行相应的记录；如果bug未能被解决，则会重新打开该bug，并通知开发人员进行修复。
通过以上流程，禅道能够有效地管理bug，确保bug能够被及时发现和解决。
提交测试流程规范
提交测试流程规范
一．创建版本
由项目负责人创建版本。
登陆禅道系统（http://10.0.1.200/zentao）
选项卡选择项目->版本->创建版本
点击创建版本，进行版本的创建
选择需要发布版本的产品，平台，版本名称编号，构建者，打包日期，为必填项。
源代码地址，下载地址，上传发行包，为选填。
描述中需要填写改版本发布的注意事项，比如更新SQL或者修改了哪些bug等等。
输入完成点击保存
二．提交测试
由研发人员提交测试。
登陆禅道系统（http://10.0.1.200/zentao）选项卡选择项目->测试->提交测试
点击提交测试，进入提交测试页面
选择本次提交测试的产品、项目、版本、测试负责人、测试优先级、开始日期结束日期、当前版本的测试状态，本次提交测试的名称（可以按大模块来写）+版本号，描述内容可以大概写一下当前提测版本的功能。
抄送给各组负责人和总监。
保存成功，提交测试流程结束。
测试提交后，测试人员针对该版提测计划开始测试，点击【开始】按钮进行测试。
bug 登记时，应选择这个版本为影响版本,这样做的目的，是为了能统计每个版本提交后的bug 数。
禅道管理bug流程
禅道管理bug流程嘿，朋友！咱今儿来聊聊禅道管理中的那个让人头疼的 bug 流程。
你想想，这 bug 就像个调皮的小怪兽，时不时就冒出来捣乱。
要是没个好法子来对付它，那可真是能把咱的项目搅得一团糟！禅道管理中的 bug 流程，那可是个精细活儿。
就好比做一顿丰盛的大餐，每一个步骤都得拿捏得准准的。
当发现一个 bug 时，咱得像侦探一样敏锐，迅速把它的“行踪”和“特征”给记录下来。
这记录可不能马虎，得详细又准确，不然就像做菜忘了放盐，没滋味！然后呢，给这 bug 分分类。
是小打小闹的“小怪”，还是能掀翻桌子的“大boss”？这分类就像给不同的病人分诊，得搞清楚轻重缓急。
接下来，给负责解决的小伙伴安排任务。
这可得找对人，不然就像让厨子去修水管，能行吗？而且还得给个明确的期限，不然他拖拖拉拉，项目不就耽误啦？在解决 bug 的过程中，咱得时刻盯着，就像盯着锅里的汤，别煮干了。
时不时问问进展，给点建议，可不能让小伙伴跑偏了。
等 bug 解决了，可别高兴得太早。
得好好检验检验，这就像新衣服到手，得看看有没有线头、有没有瑕疵。
要是没检验好，回头它又蹦出来捣乱，那不白忙活了？还有啊，整个过程中的沟通特别重要。
要是大家都闷着头干，信息不流通，那不成了打乱仗？就像拔河比赛，劲儿不往一处使，能赢吗？所以说，禅道管理 bug 流程，得细心、得用心、得有耐心。
每一个环节都不能掉链子，每一个决定都得明智。
只有这样，才能把那些讨厌的 bug 收拾得服服帖帖，让咱们的项目顺顺利利地推进。
总之，禅道管理 bug 流程可不是闹着玩的，咱得认真对待，才能在项目的道路上一路畅通无阻！。
禅道BUG维护规范
归时重新激活
禅道BUG维护规范
序号
1 2 3 4 5 6 7 8 BUG维护 BUG填写规范 操作步骤填写 已解决状态的维护 BUG的回归 当前不处理的BUG
规范类别
规范内容
BUG需维护全面信息 标题填写信息
BUG严重程度与优先级定义
类别 级别
一级
二级 严重程度 三级四级 Nhomakorabea一级
优先级别
二级 三级 四级
禅道BUG维护规范
细节说明
所属模块,所属项目,影响版本,指派到,BUG类型,严重程度,优先级等不要漏了 标题填写信息概括操作或错误,不要大段描述,描述放到BUG详情的操作步骤 操作步骤描述详细,准确(包括前置条件),原则上操作步骤不允许贴图 实际结果可使用贴图,但需在图中标注或说明出错误处 预期结果要符合需求设计,或设计开发规范,不能是主观臆想的"需求" 当前提供版本不能回归的BUG,禁止开发人员维护成已解决状态,如果维护了,那测试回归时重新激活 回归通过的BUG,关闭时填写备注"测试通过";回归不通过的BUG,备注填写实际验证结果 延期处理和当前不处理的BUG进行跟踪,每个阶段结束后,汇总整理,有价值的作为优化需求提出
BUG严重程度与优先级定义
定义说明 系统级风险问题(如崩溃,闪退,卡死无响应) 核心功能没实现或实现错误(如设计了某功能需求由于个人失误没做) 金额计算或处理错误 用户数据丢失错误 安全漏洞 影响分支流程的阻断性错误 功能实现了但与需求不符(非主要功能) 前后端接口未对接好,无法正常进行操作 一般性但极容易触发的错误 影响分支流程的非阻断性错误 一般性但较隐蔽,特定条件下才会触发的错误 关键信息的显示错误 提示性错误 非关键信息的显示错误 界面排版,显示错误 建议类问题 需要紧急修复的问题 阻碍主流程测试的问题 极度影响使用的问题 用户极容易察觉,发现的问题 阻碍分支流程测试的问题 核心功能通畅,但使用有一定影响 对使用影响小,非紧急问题 问题出现概率小 对使用基本无影响 建议性问题 暂时没影响,可后续确定方案的问题
禅道bug处理指导
禅道b u g处理指导 The manuscript was revised on the evening of 2021
禅道bug处理指导
一、bug的处理流程有两种情况：
1.测试人员提交bug => 开发人员解决bug => 测试人员验证关闭；
2.测试人员提交bug => 开发人员解决bug => 测试人员验证未通过 => 激活bug => 重新解决=>验证关闭。
二、一个bug的生命周期
三、处理bug
登录禅道，查看“指派给我”的缺陷：
对缺陷进行分析与重视，如果发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。
如果确认为缺陷则需要对其进行处理，解决或转交。
解决缺陷需要选择正确的解决方案和解决版本：
解决方案说明：
设计如此=> 设计如此，无需改动。
重复Bug => 重复Bug，以前已经有同样的bug。
外部原因=> 外部原因，非本系统原因。
已解决=> 已解决。
无法重现=> 无法重现，无非重现bug。
延期处理=> 延期处理，确实是bug，但现在不解决，放在以后。
不予解决=> 不予解决,跟提交者协商一致，决定不予解决。
软件开发缺陷管理流程规范
Bug登记流程规范一、规范目标BUG是软件过程中的重要环节，为了提高工作效率,降低沟通及管理成本，引入禅道用于BUG管理。
良好的BUＧ管理也是团队做好知识积累的基础.特制定本规范，以达到以下目标：1、 为BUG流转的整个过程提供指导，每个过程都描述操作的意义、具体方法、要求及关键点。
2、 为版本发布计划提供保证，通过理顺测试流程及特殊情况的处理的方法,为不同情况下发版提供应对方法。
二、执行效果本规范启用后公司所有拥有BUG登记权限者能够根据规范顺利完成BＵG登记流转工作，不需要过多的额外指导.三、ＢＵG的定义在登记BＵG前,根据此定义判断需要提交的问题到底是BUＧ，还是需求。
BUG:系统中已有功能在使用不能完全正常的使用。
需求：系统目前没有的功能,不论大小.建议:用户根据自己的业务需要对系统提出的优化要求，会同时包含BＵG和需求两类信息。
其中BUG 类的如：提示信息看不懂、信息描述不清、错别字、界面缺少按钮、所有的用户看不懂的异常报错;其中需求类的如：功能优化、界面优化、性能优化、新增功能；四、BUＧ登记前准备工作(必须)1、查看已有项目数据进入项目分页中，如下图：点击图中“倒三角"按钮,在下拉列表中查看是否有你要登记BUG所属的项目?如有，可跳过这个准备工作。
如无，则点击“+添加项目"按钮，创建一个你需要的项目(不要添加重复的项目信息）２、项目新增使用项目管理中的“添加项目”按钮，进行项目添加A:填写项目名称，如项目属于XＸX产品的个性化定制商品,则命名规则为:所属产品名称—个性化 商品名称；项目代号为项目简称。
B:如有明确的结束日期，则按实际情况选择，如无则选择“一年”。
C：目前项目均属于【运价系统】这个产品的个性化商品定制，关联产品必须要选择“运价系统”否则无法给项目添加需求。
保存后,弹出设置界面(此操作必须执行,否则新登记的BＵG或需求数据都无法指派给相应人员)选择“设置团队”点击“团队管理”因复制团队功能权限问题暂时不能直接使用，请手动选择上图中所有“研发”及“测试”到团队 中,保存数据。
禅道系统-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 : 需要完成的一任务。
禅道项目管理系统使用规范
禅道工程管理系统使用标准一、标题命名标准禅道工程管理系统提供模块名显示功能，通过以下操纵显示。
这样标题的命名规那么上我们可以规定：#工程标签#【{创立时间}】《{产品/子产品}》{方案/需求/任务/Bug}命名格式：【{创立时间}】《{产品/子产品}》{方案/需求/任务/Bug}例子：【20210907】《iOS》找回登录密码( /邮箱)没有证件号输入项命名格式：功能模块-子模块-子模块例子：财务功能—人民币相关业务功能财务功能—数字货币相关业务功能用户注册登录功能命名格式：{工程/子工程}{版本号}〔{状态}〕例子：App 1.8〔研发中〕App 1.7〔已发布〕二、工程开发方案流程标准创立一个主线产品，假设这个产品涉及多个平台，那么根据父子关系创立树标准事项：1〕产品只能由超级管理员建立。
2〕每个主线产品，自身再细分不同平台的子产品。
如果你已经创立了产品树，那么新建一个主线工程后，它将会关联整个产品的树结构，如上图所示标准事项：1〕工程只能由超级管理员建立。
2〕只要创立好产品体系，直接创立一个主线工程会有对应产品的子工程。
为了更好维护工程，我们采用阶段性迭代开发方式。
每个开发阶段都以唯一的版本号命名方案，每个阶段都合理汇总需求及要修复的bugs，尽可能地确定及控制每个阶段开发时间及人力本钱。
使工程开发能做到高效率与高稳定兼顾。
1〕由工程经理创立“方案〞描述方案的版本号，工作概述，开发时间等。
〔时间尽量预松，以备摸索时遇到坑〕2〕为方案创立需求及关联需本次迭代修复的bugs创立这个方案要实现的需求，及要在这次开发方案中修复的bugs标准事项：1〕开发方案只能由工程经理等人员建立。
2〕开发方案尽力做到小而精准，做好需求分析，做出符合用户需要的功能。
3〕开发方案中列明开发人员及职责，尽量不要一个人员同时在进行多个方案，防止其进度无法把握。
4〕开发方案的时间预估应该要合理，必须包含需求分析，原型设计，编程开发，功能测试等时间，时间安排不合理会造成偷工减料，Bugs频繁出现。
禅道规范指南
禅道规范指南
禅道是个很好⽤的国产项⽬管理软件。
但在wiki上⽆论中英⽂暂时都未定义该词条。
⼀、什么是禅道？
项⽬管理软件是国产的开源项⽬管理软件,专注研发项⽬管理,内置需求管理、任务管理、bug管理、缺陷管理、⽤例管理、计划发布等功能,实现了软件的完整⽣命周期管理。
⼆、为什么要使⽤禅道？
进⾏项⽬管理，⽅便团队协作开发；监控开发的流程，⽅便后期审查。
三、如何使⽤禅道？
四、研发提交bug格式整理
1. 解决bug信息记录
1. 问题描述和原因：
麒麟扫描的desktop⽂件未增加中⽂翻译，位置在 /usr/share/applications/kylin-scanner.desktop 。
2. 问题分析和解决⽅案：
在 /usr/share/applications/kylin-scanner.desktop 增加以下⾏：
Comment[zh_CN]=⼀款可⽤于普通扫描、⼀键美化、智能纠偏和⽂字识别的界⾯友好扫描仪软件。
3. 其他问题影响：
只影响麒麟扫描desktop的中⽂化，不影响其他应⽤和麒麟扫描其他组件。
4. 修改后测试情况
测试通过，测试后解决⽅案截图见附件 scanner-startup-translate.png 。
5. 最好添加附件说明，同时增加解决版本号。
禅道bug管理使用说明
禅道bug管理使用说明禅道BUG管理使用说明一、登录禅道访问地址： http://192.168.1.3/bug用户名为姓名的全拼简称，如chenjin初始密码为123456若提示帐号不存在，请联系陈进进行开通。
二、测试流程测试BUG基本流程为：测试人员提出bug -> 开发人员解决bug -> 测试人员验证关闭。
演示具体的使用方法。
1、提出bug选择导航菜单测试—>bug，点击页面右上角“+提bug”按钮我们就可以来创建bug了。
BUG创建页面：在创建bug的时候，必填的字段是影响版本、bug标题、重现步骤✧BUG类型、严重程度（数字越小代表该BUG越严重）请必须填写有利于开发人员及时准修复BUG。
✧重现步骤请尽量详细的填写并附截图。
✧相关产品、相关需求、操作系统、浏览器版本可以忽略。
✧创建bug的时候，可以直接指派给某一个人员去处理。
如果暂时不清楚的话，可以保留为空。
2、解决bug当一个bug指派给某一位研发人员之后，他可以来验证解决这个bug。
2.1 通过各种标签和检索条件找到需要自己处理的bug在对bug进行出来之前，需要先要找到需要自己处理的bug。
禅道提供了各种各样的检索方式：✧首页->我的地盘可快速找到指派给我的BUG：测试->bug->指派给我，可以列出所有需要我处理的bug。
2.2 解决bug✧研发人员解决bug，选择解决方案，一般来讲有效的解决bug方案是”已解决“。
✧备注请尽量详细填写并附解决完成的截图有利于测试人员进行验证。
3、关闭bug当研发人员解决了bug之后，bug会重新指派到bug的创建者。
这时候测试人员可以来验证这个bug是否已经修复。
如果验证通过，则可以关闭该bug，那么该BUG表示已经修复并验证完成。
4、重新激活BUG如果已经关闭的BUG之后验证又出现的同样的问题，这时测试人员可以新建一个BUG或者重新激活该BUG。
选择测试->Bug->所有，可以显示该项目的所有BUG查看一条已经关闭的BUG详情，点击激活，重新编辑保存即可激活，备注请详细填写。
禅道项目管理系统使用规范
禅道项目管理系统使用规范一、标题命名规范禅道项目管理系统提供模块名显示功能，通过以下操纵显示。
这样标题的命名规则上我们可以规定：#项目标签#【{创建时间}】《{产品/子产品}》{计划/需求/任务/Bug} 1.计划/需求/任务命名命名格式：【{创建时间}】《{产品/子产品}》{计划/需求/任务/Bug}例子：【20160907】《中国比特币》v1.8版研发计划【20160907】《App》v1.8版研发计划【20160907】《iOS》v1.8版研发计划【20160907】《Web》v1.8版研发计划【20160907】《iOS》找回登录密码(手机/邮箱)没有证件号输入项2.测试用例命名命名格式：功能模块-子模块-子模块例子：财务功能—人民币相关业务功能财务功能—数字货币相关业务功能用户注册登录功能3.发布版本命名命名格式：{项目/子项目}{版本号}（{状态}）例子：App 1.8（研发中）App 1.7（已发布）二、项目开发计划流程规范1.创建产品创建一个主线产品，若这个产品涉及多个平台，则根据父子关系创建树规范事项：1）产品只能由超级管理员建立。
2）每个主线产品，自身再细分不同平台的子产品。
2.创建项目如果你已经创建了产品树，则新建一个主线项目后，它将会关联整个产品的树结构，如上图所示规范事项：1）项目只能由超级管理员建立。
2）只要创建好产品体系，直接创建一个主线项目会有对应产品的子项目。
3.创建工作计划为了更好维护项目，我们采用阶段性迭代开发方式。
每个开发阶段都以唯一的版本号命名计划，每个阶段都合理汇总需求及要修复的bugs，尽可能地确定及控制每个阶段开发时间及人力成本。
使项目开发能做到高效率与高稳定兼顾。
1）由项目经理创建“计划”描述计划的版本号，工作概述，开发时间等。
（时间尽量预松，以备摸索时遇到坑）2）为计划创建需求及关联需本次迭代修复的bugs创建这个计划要实现的需求，及要在这次开发计划中修复的bugs规范事项：1）开发计划只能由项目经理等人员建立。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
禅道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)
1.目的
本文档定义了bug管理流程及其bug相关信息内容。
本文档适用范围：
●本文档适用于新产品以及以后新产品的项目。
原有项目的bug管理仍然用JIRA系
统进行管理。
●本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。
2. 禅道系统Bug流程图
3. Bug流程操作及其Bug相关信息解释
3.1.测试人员发现bug
3.2.测试人员创建Bug
测试人员登录禅道系统，创建Bug。
Bug状态为激活（未确认）
创建Bug页面截图：
页面字段注释：
所属产品：选择发现Bug的产品，必填项。
所属模块：选择发现Bug的对应模块，必填项。
所属项目：选择测试所属的项目。
必填项。
影响版本：选择发现bug的版本。
必填项。
当前指派：选择指派的开发人员。
必填项。
Bug标题：用简单明了的语句说明Bug内容，相当于BUG的中心语句。
必填项。
在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。
必填项。
[环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在
重现步骤里详细描述环境信息，以便于开发定位和解决问题。
[步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。
[结果]：写明操作的实际结果。
[期望]：写明操作的期望结果。
相关需求：选择与Bug相关的需求。
如果Bug关联测试用例，系统会自动关联测试用例的需求。
相关任务：选择与Bug相关的任务。
这里的任务是在『项目』->『任务』中创建的任务。
Bug类型如下：
●代码错误：功能性错误。
●界面优化
●设计缺陷
●配置相关
●安装部署
●安全相关
●性能问题
●标准规范
●测试脚本
●其他
系统/浏览器：选择出现问题的系统平台和使用的浏览器信息。
必填项。
抄送给：选择需要抄送的人员。
关键词：填写关键词，便于搜索查找。
附件：如需必要，附加可以说明bug的文件，截图，dump等信息。
注：如果Bug是关联测试用例创建的，系统会自动取测试用例的信息（标题，前置条件，步骤，期望结果，需求）作为Bug的信息。
3.3.开发人员设定Bug优先级别并确认Bug
第一步：开发人员查看指派给自己的Bug列表，编辑bug并确定每个bug的优先级别。
优先级别根据时间，紧急度，重要程度综合确定。
优先级别由开发人员自己定义，开发负责人具有复查/重定义/监督的责任。
页面字段注释：
优先级别：如下表。
必填项。
Bug严重度等级描述
1 – Urgent 立即修复。
2 – High 产品发布前必须修改完成。
3 – Medium 时间允许，产品发布前应该修改。
4 – Low 产品发布前可能修改。
不影响发布。
第二步：确定Bug的优先级别后，开发工程师根据Bug的优先级别开始解决（复现/调试等），此时需要确认bug，表明Bug正在处理。
通过已确认/未确认状态可以查询开发人
员已开始处理/未开始处理的Bug信息。
Bug状态为激活（已确认）。
3.4.开发人员解决Bug
开发人员解决bug后，执行『解决』操作。
填写解决方案，指派给，备注信息。
Bug 状态为已解决。
之后开发人员等待build的创建，如果build创建完毕，开发及时确认在此次创建build上解决的bug，并修改bug的解决版本。
Build的创建参见迭代开发流程。
针对延期处理的Bug，需要单独创建一个Build，名称例如为“下一版本”。
如果开发解决了延期处理的Bug，需要修改Bug的解决方案，解决版本等信息。
针对重复的Bug，开发需要在重复bug中写明重复bug的ID。
新Build创建后，开发人员需要及时复查在新build上解决的Bug，并修改Bug的解决版本信息。
测试人员需要及时提醒开发人员完成此项工作。
页面字段注释：
名称英文对照
设计如此Bydesign
重复Bug Duplicate
外部原因External
转为需求Tostory
已解决Fixed
无法重现Not Reproduce
延期处理Postponed
不予解决willnotfix
解决版本：选择创建的build。
Build来自与『项目视图』->『Build』中创建的Build。
必填项。
指派给：选择验证Bug的测试人员。
默认为Bug的创建者。
必填项。
备注：开发人员填写bug的原因及解决办法。
3.5.测试人员验证Bug
测试人员验证状态为已解决并解决版本不为空的bug。
验证结果一：如果验证bug在build上已经解决，测试人员『关闭』Bug并填写验证信息。
Bug状态为已关闭。
后续操作：如果Bug来自与case的执行，测试人员需要重新执行对应Case，确保
Case最终状态是通过。
如果Case的执行仍然发现bug，将进入新一轮的Bug流程。
验证结果二：如果验证bug，没有通过，测试人员填写验证信息，并『激活』bug。
Bug状态为激活（已确认）。
页面字段注释：
指派给：将正在激活的bug指派给对应开发人员。
必填项。
影响版本：选择复现Bug的build。
必填项。
备注：填写验证信息。
附件：附加相关可以证明bug的附件，例如截图，错误文本，dump等。
各解决方案，测试人员对应操作。
名称对应操作
设计如此如果同意，关闭Bug；如果不同意，写明原因，激活Bug。
重复Bug 确认重复，关闭Bug；如果不重复，写明原因，激活Bug。
外部原因如果同意，关闭Bug，并考虑是在用户手册/FAQ记录问题；如果不同意，写明原因，激活Bug。
转为需求如果同意，转为需求，关闭Bug，之后由需求负责人跟踪；如果不同意，写明原因，激活Bug
已解决如果验证已解决，写明验证结果，关闭Bug，重新执行测试用例；如果验证没有解决，写明验证信息，激活Bug。
无法重现测试人员需要帮助开发人员复现Bug。
如果复现，保留测试环境，提供给开发人员进行调试；
11/ 11。