jira规范

版本声明：转载请注明出处。未经允许，禁止商业用途。

说明：jira系统部署时的设置，管理员创建jira项目的方式，创建jira项目的设置，这些都会影响jira的行为和使用方式。主要影响的是有哪些字段，和字段有哪些可选的取值，角色分组和其权限。关键的bug描述和bug处理流程不受影响。

本规范适用于所有产品。

一      判断是否bug的几个依据：

1. 系统行为与需求规格说明书不符，包括功能、性能指标。
2. 系统没有达到用户期望的目标(虽然需求规格说明书中没有要求)
3. 系统不符合标准或者不兼容标杆企业产品（如果标准中没有明确说明,依次优先参考思科,华为/华三,其它厂商产品。）
4. 界面缺陷，比如易用性差
5. 测试人员认为对用户使用有影响，就应该提交缺陷。开发人员置为invalid后，如果测试人员不同意该处理方式，可以重开。

注：没有需求规格说明书时就需要把系统本身当做需求规格说明书。通过探索测试逐项了解软件的功能，记录软件的行为。如果两处的行为有矛盾，则必定至少有一处存在bug。比如要弄清楚被测产品中，ACL隐含的最后一个条目是permit any，还是deny any。

注：不能重现的bug也要提交jira，以后测试中进行观察，如果再次遇到则找开发看现场并且添加注释。

注：设计如此的缺陷也要提交jira归档。比如：重发布OSPF路由时，不能引入local OSPF路由。开发置为won't fix或者later。开发知道的，就自己提。测试发现的，就测试提。工作中经常把需求规格说明书的书写也说成设计。比如为了实现方便，某个值在某中状态下不能修改，但是参考厂商可以修改，那就影响了用户的正常使用，是缺陷。比如修改配置之后，进程会自动重启，不符合企业级设备的可用性要求，是缺陷。

NRSBUG-5773 OSPF中配置redistribute static没有引入默认路由。cisco中也是这样实现的，所以不是bug。

 

二       创建问题

项目权限根据分组设置：
例如如下分为三级。权限依次增加
users:可查看、提交、编辑、分配bug、建议。管理对应issue的watcher。添加注释、编辑自己的注释。添加附件。
developers：可以解决bug、建议，创建dev。管理对应issue的watcher。
administrators：管理项目，添加删除字段，删除、移动issue。

2.1 项目

1. 各产品bug和建议选择相应的项目，例如NGR BUGS、NGR SUGGEST、NGR DEV。

2.2 问题类型

开发任务记录有epic、feature、story、task，依次逐级细化工作。另外还有Improvement。测试人员报告选择bug和suggestion。缺陷则选择"Bug"。建议选择"suggestion"。如果没有suggestion类型，bug标题中注明是建议。

三       填写问题的详细情况

3.1 概要

简单描述问题的环境、操作和结果,包含基本信息又不能过长。建议不要超过50个字。如果重现条件不易概括，标题中要写明“特定情况下”、“特定操作下”等，表明其并非一般性失效。偶然遇到的bug，标题中注明“遇到”。概率性出现的bug，标题中注明“偶尔”、“有时”、“可能”、“很可能”、“概率性”。
如果 OSPF邻居建立之后测试仪通告1万条路由，先将两侧的接口MTU改大，然后再将两侧的MTU改小，然后修改两侧的Hello interval，之后OSPF邻居无法建立。假如每个条件都是必须的，就可以写作，特定操作下，OSPF邻居无法建立。

3.2 优先级（priority）

有的项目还有emergency字段，可选值为high、medium、low。

Blocker

系统、整机基本运行出现故障。如：
1 设备不能正常启动
2 设备崩溃、死机、自动重启
3 板卡不能正常加载、数据不能转发、接口不通
4 CPU、内存资源耗尽（非性能测试，不可恢复）
5 系统级资源耗尽
6 内核、NSM挂起

Critical

模块崩溃；模块基本功能、关键功能出现问题；存在严重的安全问题。如：

1  ISIS进程挂起
2 OSPF邻居不能建立
3 CP、NP表项不一致
4 路由计算错误
5 计费数值计算错误
6 密码明文显示
7 死锁、死循环
8 严重的内存泄露
9 用户数据丢失

Major

模块一般性的功能存在问题；与其它厂商产品不兼容；命令未生效；
命令配置顺序问题。如：
1 vlink没有按照协议标准填写dd包的mtu值
2 MAX-HOPS 在MSTI中应用失败
3 Vrrp md5认证与cisco不兼容
4 VRF下配置maximum命令没有生效
5 命令写starting-config失效或者错误；

Minor

很难出现或者复杂、生僻环境和操作才会出现的功能问题；功能细节问题；生僻功能存在问题；不会对数据转发、用户业务产生影响的问题；对事件响应不及时；UI存在错误；如：
1 OSPF的LSA老化超时未删除
2 查询值、调试信息中的错误
3 提示错误、描述有误
4 命令写running-config失效或者错误；
5 参数范围错误

Trivial

易用性问题。如：
1 排版混乱、颜色不当
2 单词拼写错误、语法错误
3 缺少必要的警告信息、出错提示读不懂、缺少或者多余的删除确认
44 界面不友好、操作不方便

注意：不能重现的bug优先级应该适当降低。另外还要考虑是否有规避方法、恢复难度等。

一些举例：

特性重要程度	是否一般性失效	是否必现	缺陷优先级	举例
关键特性	一般性失效	必现	block	NGRBUG-1  缺少PIM功能命令
关键特性	特定情况下失效	偶发性失效	critical	NGRBUG-3534 X8-2上同板转发数据时，删除路由，有时会导致XFE下线。
重要特性	一般性失效	必现	critical	NGRBUG-3551 bgp4+路由图功能不生效。
重要特性	特定情况下失效	偶发性失效	major	NACDEV-1236 执行设备上查看不在线的交换机配置时，界面一直显示进度条，10分钟后弹出窗口提示失败。
一般特性	一般性失效	必现	major	NGRBUG-3560 X1上把正常的unicast frame报文也统计到了pause frame上
一般特性	特定情况下失效	偶发性失效	minor
并非特性失效			trivial	命令解释拼写错误

注意：bug优先级按照实际使用时对用户的影响来评估，不考虑目前系统的开发阶段（刚交测、迭代期、临近发布），不考虑现阶段系统的阶段性目标（演示、试用、实际使用）。

3.3 产品

由报告人选择发现问题的产品，开发者判断其它产品是否存在同样问题后补充选择。比如共用某一块代码的多个产品，就有相同的缺陷。
开发者不能判断时，通知报告人测试后补充。
在以后测试中，若发现其它平台存在同样问题，应补充选择。

3.4 模块（component）

选择问题所属的模块。缺少模块应通知jira管理员。

3.5 影响版本

选择发现问题的版本。

3.6 修复版本

有的项目中此项为必选，报告人提交BUG时指定一个版本（一般同"影响版本"），开发者可根据BUG修订计划修改

3.7 开发者（Assignee）

报告人选择问题所对应的开发人员，不能选"自动"。开发部应公布各模块维护人员列表，有变化时及时通知测试部。
PS：由jira管理员指定模块和开发者绑定关系，根据模块自动指定开发者，对于使用者来说最方便。

3.8 环境

根据需要写软件版本、硬件版本、固件版本、硬件序列号。
测试DS700应用识别时，除了DS700的版本外，还要写明具体应用的版本，如QQ的版本号。
用浏览器测试时相关内容时，要写明浏览器的名称和版本号。

3.9 描述

Bug相关记录字段必须清晰、准确；
格式统一为：

测试拓扑：
...

预置条件：
...

测试步骤：（必选）
1 ...
2 ...

预期结果：（必选）
1 ...
2 ...

测试结果：（必选）
1 ...
2 ...

其它信息(可选)：
CPU，内存，LOG，debug等相关信息。
在不能重现的bug中，应尽可能收集多的信息。（如路由表、mac表、arp表、show inter summ等）

对比测试（可选）：
确认bug有效性做的对比测试（比如硬件相关的故障需要更换板卡、设备测试，确认是硬件损坏还是设计问题）。总结重现条件做的对比测试。确认bug影响范围做的对比测试（比如更换不同版本的子卡）。注意充分利用之前已经进行过的类似测试。

失效定位（可选）：
对失效的位置做初步定位，比如表项的某个字段错误。

原因分析（可选）：
对bug的代码级原因做推测，比如解引用空指针

影响范围（可选）：
从用户实际使用的角度来进一步补充失效造成的影响。比如bug描述的是报文中某个字段的处理有问题，那么这对使用的影响是什么呢，是最基本的功能都失效了，还是非常特殊的环境下才会失效？

恢复方法（可选）：
使设备重新恢复正常工作状态的方法

规避方法（可选）：
使用其它方式达到同样功能效果。

重现情况（必选，次数不包括第一次出现的那次）：
尝试X次(X>=1)，出现X次。必现。
尝试X次(X>=2)，出现Y次（Y>=1）。有把握重现（测试人员认为操作和结果的因果关系强）。
尝试X次(X>=2)，出现Y次（Y>=1）。没有把握重现（测试人员认为操作和结果的因果关系弱）。
尝试X次(X>=3)，未能重现。
测试1次，出现1次。暂时没有尝试重现。（这是一种暂时的处理方式，当之后时间、条件允许时应该立刻尝试重现）
偶然遇到，未能重现。
偶然遇到，暂时没有尝试重现。（这是一种暂时的处理方式，当之后时间、条件允许时应该立刻尝试重现）
偶然遇到，不知如何尝试重现。（失效前没有操作和环境变化，没有可疑的对象）

注意：有的项目设置了重现性字段，可选值有必现、易现、难现、极难（无法重现）

注：

• 像CLI等问题可省略拓扑。
• 复杂的配置要先概要描述，然后再贴上show run中相关配置。如果是不能重现的bug，要提交完整show run信息（可以附件提交。）
• 预期结果和测试结果编号要与操作步骤相对应，不重要的操作步骤可不写对应的预期结果和测试结果。
• bug现场已经不再，bug报告中已经描述了必现的方法，开发人员也有条件进行重现的，由开发人员自行重现。

四       其它操作

4.1 分配

如果指定了错误的"开发者",可用此操作重新指定.
误操作由报告者进行更正，模块交叉或者开发者不明确时由原开发者重新指定。常发生前台开发人员把缺陷转给后台开发人员，上层模块开发人员把缺陷转给下层模块开发人员。

4.2 上传附件

如果拓扑比较复杂,配置,LOG文件较大或者对故障现象进行截图,可利用"上传附件"把图片/文件上传。

4.3 写备注

对bug的补充说明/测试/验证，可在备注里添加。开发有了初步结论，写备注。

4.4 编辑问题

如果原有描述存在错误,可重新编辑.

4.5 监测

重要bug可以添加合作开发者或者领导为监测者。

4.6 查找问题

• 在右上角"快速搜索:"里输入要查找的关键字,或者BUG ID.
• 点击"查找问题",可以使用filter. 通过"另存为" ,可以保存filter.

4.7 缺陷分类

有两种分类方式
从用户角度分类：Function、Performance、User Interface。
从开发角度分类：模块内部错误、模块间接口（调用）错误、代码库管理或者编译错误。

4.8 缺陷来源

需求获取、需求分析、概要设计、详细设计、编码

五       JIRA bug处理流程（黑色箭头为测试部工作，红色箭头为开发部工作）

Jira有5种状态：Open、In Progress、Resolved、Closed、Reopend。

其中resolution有6种：Fixed、Later、Won’t Fix、Cannot Reproduce、Duplicate、Invalid。

ps：开发置为invalid和duplicate的bug，测试也可以reopen。cannot reproduce的bug经过两轮完整测试都没有再出现，则关闭。如果后来又出现了，则reopen bug。

开发fix bug时需要添加注释。内容需要结构化为1、缺陷原因。2、解决办法。3、提交版本。不良注释举例，OSPF收到lsa后修改metric。这是缺陷原因还是解决办法。看不出来。

invalid的原因可能是对用户需求理解错误、对需求规格说明理解错误、测试设计有误、操作有误（比如使能开关没有打开）、环境问题、其它厂商的设备/软件故障、观察有误。例如：假设产品中ACL最后隐含的条目是deny any。SWBUG-1673 将配置了permit条目的mac acl应用到接口出方向，ixia发送匹配的数据也被丢弃了。原因是三层转发后SMAC和DMAC都变化了，数据流其实已经不能匹配到permit条目了。

Later、Won’t Fix、Cannot Reproduce、Duplicate、Invalid实际中被开发人员误用的情况比较多。比如把Won't fix、Cannot Reproduce、Duplicate的缺陷置为invalid，把invalid的bug置为fixed，没有时间修改的bug没有置为later。

六       对测试部的要求

• 发现bug后,建议先与开发人员沟通,以分析现场或者确认bug,然后再提交到jira。
• 所有bug都要提交到jira。对于发现非本任务的bug，可以自己提交，也可以通知该模块测试人员/模块负责人员提交，被通知人不得推诿。
• 经常浏览其他人提交的bug，避免重复定位和提交，也可举一反三，从其他人提交的bug中发现本模块漏测部分。
• 所填内容必须真实准确，"概要"要能反映出现条件、重现情况、出现频率或者出现的可能性，"描述"必须描述清楚，对解决、追踪Bug提供必要的帮助，有新的信息时应该及时修改bug报告，使之更准确。
• 一个"问题"只能包含一个bug。
• close或者reopen bug时要在备注中注明结果和版本(不能用私人映像)。
• 验证bug时不能仅验证jira上的现象，还要回归修改可能影响的特性。尽量由reporter验证bug，由非reporter验证bug时要注意验证的有效性。
• 在验证bug时，不要关闭later和won't fixed的bug。测试人员可以先搜索jira上未close的缺陷，得知已知缺陷。
• 开发部提交的bug除了开发人员自己验证外，还需要测试部验证，测试部进行关闭。如果开发描述不够清楚或者不易懂，由开发关闭。
• 禁止利用JIRA进行讨论，如果对问题有分歧请利用其它方式沟通,并对沟通结论及时备注；