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修复成本。
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的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.系统日志、审计。
jirabug管理系统使用说明
Jira bug 管理系统使用说明1.登陆jira系统Jira的外网访问地址是内网访问地址是注:内网访问速度会快很多,但是考虑到工程师经常出差,所以将外网同时开放了。
管理员为软件二部的每位工程师都注册了一个用户名,用户名是工程师的中文名字,初始密码是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提交规范1.认识jiraJIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件.JIRA创建的问题类型包括New Feature、Bug、Task和Improvement 四种,还可以自己定义,所以它也一是过程管理系统。
JIRA融合了项目管理、任务管理和缺陷管理,许多著名的开源项目都采用了JIRA。
用它管理项目,跟踪任务、bug,通过JIRA的邮件通知功能进行协作通知,在实际工作中使工作效率提高很多,效果非常不错!安全性、可扩展性方面发挥到了极致!JIRA不仅仅是一个缺陷跟踪系统,通过Jira,可以整合客户、开发人员、测试人员,各人各司其职,信息很快得到交流和反馈,让大家感到软件开发在顺利快速的进行,向意想的目标迈进。
eclipse和IDEA 下的Jira插件,主要为开发人员服务,实时将信息反馈给开发人员,开发人员同时迅速地将修复的结果信息反馈到跟踪系统中,最后通过持续集成,软件迅速地完成了更新,这些方便便捷的操作会极大地鼓舞软件开发中的各方人员,甚至包括客户,及时响应,相信是每一个客户都会欣赏的。
JIRA还拥有众多插件的支持,包括生成报表,XP编程,与SVN集成等,极大的丰富了其功能。
跟同类软件产品TestTracker、ClearQuest、TestDirector相比,JIRA 的性价比最好!(Tips:具体的可以去百度查看。
/view/1094245.htm)2.JIRA在工作中的应用每个进公司的员工都会拥有一个一自己名字为用户名的JIRA账户,以后我们的bug提交的工作都需要在上面处理。
(Tips:具体的用户名密码会在入职后由运维创建和发放。
)登陆到JIRA后我们可以在左上角看到面板,项目,问题等选项。
在我们的工作中我们主要用到项目和问题两个选项。
项目:点击项目可以看到几个我们公司的项目。
我们可以从这边进入我们工作的项目。
点击我们工作的项目后,我们可以看到我们工作的项目总的一个情况。
Jira管理项目基本规范
Jira管理项目基本规范
Jira 规范
1、问题类型
Epic:比较大的用户故事;
Story:比较小的用户故事,即功能;
Task & Sub-Task:一般会将用户故事分解为任务或子任务,每个任务只有唯一的经办人;
Bug:生产或测试过程中的缺陷。
图1 问题类型的关系图
【注】一个版本中可以存在多个EPIC,或只有Story
2、
总体流程
针对项目流程,如《项目管理办法》所述,制定相应的Jira 流程,明确每一个步骤所负责的角色,并加以说明,具体如图2。
图2 Jira 流程角色图3、
状态定义及各流程定义需求的状态定义及流程:
表1 Epic/Story/T ask/Sub-Task的状态
缺陷的状态定义及流程(包括线上问题的bug):
表2 BUG的状态
【注】
所有不予解决的bug,必须由产品经理确认后,才可以挂起4、问题字端定义
BUG类型:
●BUG优先级:
●BUG描述:包括前提条件/操作步骤/实际结果/期望结果
5、模块定义
由产品经理提供
6、版本定义
由产品经理提供。
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.系统日志、审计。
Jira使用规范
Jira使用规范
Jira使用规范:
1、开发需要合代码,请将jira指派给<发版人>,然后,去<xxx 项目 Git Merge Group >群里@发版人,告知下分支号。
2、如无紧急需求,禁止私自在Release 上提交代码/合并代码。
如因特殊原因提交或合并代码,需经PM/开发经理批准,并在群内说明让大家感知到。
(注:附加内容)
3、Jira 开发完,一定要将状态改为<Code Completed>,如果还发现是待办状态指派给测试,当未开发完处理,将jira打回。
4、Jira 必须写注释发布哪些项目、分支号、若有定时任务、系统参数配置、pts新菜单等也需写明。
5、Stage上,正在测试且有少量问题的jira,状态可改Testing,不用直接打回;测试通过,状态改Test Past,若标记有UAT字样,则状态改为UAT;
Pro测试通过,状态改为“完成”。
(注:特殊情况改“完成”点:重复问题jira,已完成未关闭的jira /etc)。
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提交标准规范JIRA管理软件提交的bug做到:言简意赅,语意明确bug报告内容:产品模块选择产品模块项目选择项目主题填写该缺陷名称,在提交bug时,bug主题要描述言简意赅,语意明确,让开发人员一眼看出哪里有问题。
优先级选择优先级所属项目选择所属项目影响版本当前指派选择指派给开发人员Bug标题填写该缺陷名称,在提交bug时,bug标题要描述言简意赅,语意明确,让开发人员一眼看出哪里有问题。
如:龙旅在线前台系统->修改个人资料,修改用户名姓名“XX”改为“张三”重现步骤步骤自动生成,可进行修改,内容需尽可能详细,使开发人员可以重现该bug。
如有前置条件请说明前置条件:如特定的操作方式,特殊的用户,特殊的浏览器等,能有利于bug复现的操作尽量进行提供。
如:前置条件:系统登录成功,使用登录账号:zhangcui 密码:asd123 浏览器:firefox操作步骤:1、点击“修改个人资料”2、修改姓名为“张三”3、点击“保存”预期结果:保存成功,姓名修改为“张三”实际结果:提示保存失败!数据库存储相关的bug(和设计的字段不符合,和设计的长度不符合等)需要以bug记录。
其他存储,如redis相关的需要以bug进行记录。
相关需求:有相关需求则选择相关需求,么有则不选择相关任务:有相关任务则选择相关任务,没有则不选择类型/严重程度:选择问题类型,根据bug定义规则判断问题严重程度(如:1:致命缺陷;2:严重缺陷;3:一般缺陷;4:轻微缺陷)系统/浏览器:选择当前测试所属系统及浏览器抄送给:可以选择要抄送的人员关键词:填写该缺陷需要注意的事项添加附件:(如:图片、word、excel、txt等文档)当有bug描述说明不清楚时,可附上截图加以说明(类型分为:1、不容易描述清晰的;2、有特殊性的如需要特殊的数据日子截图)注:bug致命和严重问题必须全部解决,一般问题不能超过3个,轻微问题小于5个方可达到上线(视情况而定)。
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验证结果,并提交问题具体解决的版本号。
对于缺陷管理系统jira配置的一点总结(需要陆续完善)
对于缺陷管理系统jira配置的⼀点总结(需要陆续完善)1. 测试⼈员提交bug时,相关界⾯需要完善的地⽅:当jira系统⽤的⼈较多时,bug很多字段都会出现问题,以下总结各个字段的优化情况----分配⼈----提交时bug时,分配⼈员⼀栏设置成该项⽬负责审核bug的⼈员(⽐如:测试主管,测试组长)在其他⼈修改bug时,设置成按照项⽬组⼈员进⾏筛选,不⾄于出现在下拉列表中50-100个⼈中选⼈,很浪费时间-----模块-----系统最好划分模块和⼦模块,也就是说,提bug时,分为2个字段,模块和⼦模块字段⼦模块随着模块联动,也就是说,模块变动时,⼦模块随着变动这2个字段最好有需求⼈员或负责该项⽬的测试组长来填写,jira配置⼈员只负责配置字段,不负责参与具体项⽬的模块和⼦模块字段的编写(职责明确)----可重现率-----增加可重现率字段,同时说明各个百分⽐代表的情况----测试平台-----增加测试平台字段,包括操作系统和浏览器平台2个字段内容设置成可以多选----bug优先级、严重程度----bug优先级和严重程度字段必须有(优先级可以按照:P1\P2\P3\P4来标识,严重性可以按照星级符合或英⽂字母Critical、Major、Minor......来标识)在设置字段的同时,需要在字段后⾯增加?,相关⼈员点击?可以查看该字段代表的含义和等级划分的标准,也便于整个测试管理规范的推⼴(个⼈觉得这是个不错的建议)2. 开发⼈员在修复bug时,需要优化的字段:----估计修复时间-----开发⼈员在修改bug状态时,需要填写此字段,⽤以衡量每个bug的⼯作量字段以⼩时为单位,建议默认字段设置成1h(包括开发查看bug、验证bug、修复bug的时间)----估计修复版本-----开发⼈员在修改bug状态时,需要填写此字段----bug产⽣原因----定位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.。