JIRA的BUG编写规范
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-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提交规范
JIRA作为1个需求、Bug共享的一个平台为了方便大家提高工作效率、更加清楚、理解需求和Bug，减少对需求或Bug等的确认时间现对需求、Bug的创建格式特做如下要求：需求包括的基本要素：（标题、备注、功能位置、界面上添加功能点的要求说明、操作要求及预期结果）1）标题表述的意思简洁、明确、完整必录项2）备注描述清楚比较含糊的或不明确的信息可选项3）功能位置指要增加的这个功能需求是在哪个功能模块：（例如：功能位置：[病理管理]-->[病理条码录入]）必录项4）操作要求及预期结果指这个功能是如何去操作的，每个操作的预期结果分别是什么？必录项Bug包括的基本要素：（标题、功能位置、详细操作步骤、测试结果、附件截图）1）标题需要简洁明了、完整必录项2）前提条件：这个Bug的执行是否是在其它功能操作的基础上进行的，如有描述出来可选项3）功能位置：指这个Bug是发生在哪个功能模块位置（例如：功能位置：[病理管理]-->[病理条码录入]）必录项4）详细操作步骤：指这个Bug是如何操作才发生的必须写出操作步骤（1、2、3、4…….）必录项5）测试结果：指这个Bug执行详细操作步骤后发生的测试结果必录项6）附件截图如对这个Bug的描述很难讲述清楚可以贴图更容易让人明白可选项截图工具推荐：Snagit中文破解版可以编辑文字、备注、画图等功能，具体安装或使用不明白的可以私下交流。
一个规范明了的Bug或需求节省了大家为这个需求或者Bug不明确而急切弄明白的烦恼，并且节省了讲解人与被讲解人的时间；如果讲解人讲解需求推迟给被讲解人工作带来的进度延后的风险。
如何做到规范：每次在JIRA上提交前先想想----自己写得需求或Bug别人能够看得明白吗？站在其他人角度去思考这个需求或Bug真的明白、完整了吗? 怎样才能写得更清晰明了呢？好处：节省大家工作时间、降低沟通理解难度、提高工作效率如下是一个完整的需求例子：例子：JIRA—185标题：外勤在系统中扫入条码后，需要看到汇总数，即他当天总共扫入了多少家医院，每家医院有多少个病理标本的一个汇总清单备注：把显示条码的列表称为"条码列表" ，显示医院及医院对应标本数的列表称为"医院列表"功能位置：[病理管理]-->[病理条码录入]界面添加功能要求：1、在窗口标本收集人信息栏（回执单条码）文本框位置下方添加【查询】按钮2、新添加1个"医院列表" 添加（客户名称、标本数量）属性列其顶部添加"客户总数"3、"条码列表"中顶部位置"标本数"改为"总标本数"。
JIRA的介绍和填写规范
王才
JIRA的管理范围
• 当前纳入JIRA的管理范围
– 故障 – 待解决问题 – 新功能(新特性) – 改进和建议(当前暂不使用此类型) – 数据库变更 – 需求变更
故障
• 使用场景—什么时候用
– 范围定义
• 功能故障和建议 • 页面、性能等的故障和建议 • 设计故障和建议
新功能(新特性)
• 使用场景—什么时候用
– 相互接口,需要新增加一些特性的时候
• 例如,WEIHF需要GAOZHEN提供一个用户接口 • 新增某个特性
– 报告人员仅为开发人员
• 和需求变更的区别
– 开发内部,技术需求产生的特性基本可以放在这里
改进和建议
• 使用场景—什么时候用
– 客户对功能和特性的改进的提议
• JIRA提供的常用操作
– 问题维护（创建、编辑、移动、删除、上传文 件和界面截图） – 问题处理（开始处理、 复制、分配、监视、解 决问题、关闭问题、重开问题） – 查询问题（高级查询、简单查询、过滤器、收 藏、热门） – 统计问题（Agile、图表等）
– 提出变更
• 将要变更的通知
– 实施变更
• 变更实现后的通知
– 变更信息的填写规范
• 变更什么表 • 变更原因和内容 • 影响的已开发模块
数据库变更-填写规范
需求变更
• 使用场景—什么时候用
– 范围定义
• 旧需求变更。 • 新需求。
– 报告人员
• 开发经理 • 业务经理 • 测试经理
JIRA常用操作
– 报告人员
• 测试人员：全过程 • 开发人员：自测、内部测试 • 业务人员：内部测试
待解决问题
• 使用场景—什么时候用
缺陷编写规范V1 1
缺陷编写规范V1 1缺陷编写规范一、目的统一缺陷编写的规范，为了测试工程师提供缺陷编写的指导，提高编写的缺陷的可读性、无歧义性、可操作性。
为开发工程师更好的复现缺陷，理解问题发生现象，提高效率，最终提高公司整个产品的质量。
二、范围适用于缺陷报告编写，辅助工具为Jira三、背景描述目前JIRA里提交的BUG很多表述含糊，过于简练，缺少URL、用户或密码信息造成程序员没有办法明白这个BUG的含义，也无法重现该问题，很难分析问题产生的原因，延误了BUG修改时间，同时增加了很多沟通成本，为了解决这个问题，BUG报告必须按照规范来编写。
四、JIRA中提交BUG的规范➢每个bug状态表示的具体含义说明如下：状态描述Open Bug已经确认，等待被处理In Progress Bug正在处理中Resolved Bug已处理，待确认Closed确认被修复的Bug，如果已修复，置为此状态Reopen确认被修复的Bug，如果没修复，置为此状态已处理，待确认状态中，处理结果又包含(fixed,won’t fix,duplicate,incomplete,cannot reproduce,Work as Design) 分别对应(修改完成，不需要修改，重复提交的bug ，描述不完整，不能复现，按设计来实现的不需要修改各状态);不需要修改和推迟修改的状态时请开发或相关人员加备注说明下原因,修改完成的bug 需要开发人员写上问题产生原因.➢优先级别的定义和举例说明✧5级：致命缺陷✧修复优先级:✧阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试;例如：导致系统崩溃、死机、死循环、数据丢失、计算错误、安装错误;播放黑屏、flash崩溃、程序崩溃、数据库崩溃、服务器不能访问或崩溃；需求中的功能未实现；产品logo和其他影响品牌形象的界面错误；占有率比较大的浏览器页面严重错位；404、500错误&报黄页(即指向未知页面错误页)等；✧4级：严重功能缺陷✧修复优先级:✧必须修改,且在短时间内必须修复.例如：开发实现的功能跟产品确认的功能不一致；业务流程处理不正确；占有率比较大的浏览器样式问题，主要的一级功能有bug，如登录、退出，正常播放、主页和二级分类页不能正常访问；播放窗口错位、面板错位、面板打开无法关闭等；✧3级：主要缺陷✧修复优先级:✧必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正(如第一轮测试结束前或上线前)例如：查询结果不正确、有调试信息、前后端未进行数据校验、数据长度不一致、翻页错误等；✧2级：次要缺陷, 错误是表面化或微小的, 对功能几乎没有影响，产品及属性仍可使用；✧修复优先级:✧如果时间允许应该修改,指明修复日期或版本例如：提示信息不太准确友好、错别字、UI 布局或罕见故障等，应该本页打开却打开新窗口；✧1级：建设性的意见或建议✧修复优先级:✧允许不修改例如:网友使用不便;没有给出用户友好提示等五、缺陷报告编写原则1.1可理解缺陷可理解指的是：尽量用短句客观的描述缺陷，避免使用修饰性的词汇和复杂句型。
禅道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 缺陷管理使用说明
JIRA 缺缺缺缺缺缺缺缺Bug缺缺
路径
选择 [xxxx项目] ，选择 [Bug看板]
创建
有项目归属的，在项目下创建子任务：
子任务的问题类型选择Sub-Bug:
Bug缺缺
Bug缺缺缺缺缺缺
A. Summary缺缺缺缺缺缺bug缺缺缺缺缺
B. Resolved缺缺缺缺缺缺bug缺缺缺缺缺
Bug缺缺缺缺缺缺
Bug缺缺缺缺缺
Bug缺缺缺缺
Bug缺缺状态流转图
说明
可以通过拖拽卡片到不同的泳道，实现状态的改变。
状态变化之间没有限制。
初始状态为“待办”；
开发正在修复，状态为“处理中”；
开发修复完毕，自测通过，测试可以验证，状态为“已解决”；
测试验证通过，关闭bug,状态为“已关闭”；
延期处理的问题，状态为“挂起”。
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修复成本。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
∙一、摘要
∙二、名词解释
∙三、目的
∙四、范围
∙五、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修复成本。
5）涉及界面UI的文字，用双引号标注，比如：集采销售-招标计划列表：列表字段“报送时间”取值错误。
2. 描述
描述是对Bug标题的详细补充，对于复杂Bug，标题不足以帮助开发定位问题，需要详细步骤来支撑。
1）对于标题就能描述清楚的Bug，描述可以与标题完全一致。
2）对于标题不能描述清楚的Bug，描述一般格式如下：
1.【重现步骤】
2.【实际结果】
3.【期望结果】
在实际编写过程，可以省略某一部分，比如标题清晰表达了问题现象，此时再“【期望结果】”就能清晰表达问题。
3）对于需要复杂数据准备的Bug，在描述里备注账号格式为：账号/密码，比如，lotus009@qq.coom
3. 环境
环境为产生Bug时，用户使用的浏览器、操作系统、分辨率、账号等，主要用于辅助开发排查问题。
1）URL：Bug产生的页面URL，方面开发快速找到修改代码的地方。
2）浏览器、操作系统、分辨率：如果是兼容性问题，需要在此注明产生问题的环境。
4. 截图
一份好的截图，可以方便开发人员快速确认错误的表现形式和错误的位置。
1）截图工具统一使用：FSCapture.exe。
2）不要仅仅截图，需要在图上标注出有问题的地方，并文字进行辅助说明。
3）如果问题为500、404等错误，需要附上日志截图，方便开发定位代码行。
4）如果Bug为与需求不符Bug，截图需要同时包括需求与系统实现，减少开发查阅需求的时间。
5）如果Bug为读取数据错误，截图需要同时包括数据库的存储结果及系统数据的展示的对比图。
5. 其他
1）正确选择“Bug分类”
2）正确选择Bug的优先级
3）正确选择Bug所属模块Bug模块主要是用于Bug分析和输出测试报告时，做模块Bug统计。
六、注意事项
1.
一个Bug只能包括一个错误同一个Bug里包括多个问题，开发修改Bug的时候，容易遗漏，导致Bug被多次Reopen。
2.
3.
所有Bug统一记录在JIRA中，测试人员在测试过程中发现的或非测试人员本身发现的Bug，无特殊情况，不能用其他工具记录，同时不允许以口头方式直接告知开发人员，统一记录在JIRA中以便统一管理，一方面，有利于项目资产的建立及项目过程问题的分析，另一方面，避免造成记录丢失或遗忘。
4.
5.
避免重复提交Bug，Bug的重复提交会增加测试人员的工作量，同时也可能增加开发人员的心理压力，所以在多人测试的时候，一方面，避免多人同时测试同一个功能点，另一方面，提Bug之前，先确认Bug库中是否已经存在，第三，发现问题的时候，可以告知主负责该模块的测试人员，由他来提交Bug。
6.
7.
对于无效Bug，目前测试人员有删除Bug的权限，建议通过删除来处理无效的Bug，以免影响Bug的统计。
8.。