成都网站建设设计

将想法与焦点和您一起共享

缺陷的JIRA管理文档

1、 文档简介

1.1 编写目的

创新互联公司2013年至今,是专业互联网技术服务公司,拥有项目成都做网站、成都网站建设网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元柏乡做网站,已为上家服务,为柏乡各地企业和个人服务,联系电话:18982081108

l 规范缺陷上报及处理流程

l 规范缺陷版本维护流程

l 提高缺陷质量

l 提高工作效率

对于测试人员,要严格按照“提案填报规范”中的要求填写上报缺陷;

开发人员和测试人员,要严格按照“提案处理原则”中对于各种状态缺陷的处理约定,及时对缺陷进行相应处理;

对于测试负责人,要严格按照“提案版本维护”中的要求对提案版本进行相应处理。

1.2 定义、首字母缩写词和缩略语

2. 缺陷填报规范

2.1 缺陷填报步骤

(用红色标识的是提案的必填项)

A. 选择项目和提案类型

缺陷的JIRA管理文档

【项目】选择所要填入的缺陷库

【提案类型】缺陷方面的提案选择“问题”

用户体验方面的提案选择“增进建议”

B. 输入提案的详细信息

缺陷的JIRA管理文档

【概要】缺陷或建议的标题,是对提案具体描述的概括,应言简意赅

【优先级】ABCDE五级区分,严重级别由A到E递减。

l 划分标准见<2.2 提案优先级的判定>

【预期日期】提案解决的日期,最长为下一轮测试开始的日期。可以不填写

【组件】问题所在部件

【影响版本】第一次发现问题的项目版本

【修正版本】该问题的解决版本

l 新报提案时,修正版本与影响版本选择一致

【被分配人】提案的解决人:

l 需求无异议的缺陷直接分配给开发负责人,由开发负责人安排解决

l 需要产品确认的缺陷分配给产品负责人,经确认确实是bug的提案,分配给开发负责人,否则分给测试负责人

【环境】测试环境:操作系统+浏览器版本

【描述】对问题或建议的具体描述,格式参见<2.2. 提案的描述格式>

2.2 缺陷优先级的判定

l A级故障:系统运行中出现的死机、系统瘫痪、关键数据无法获得、系统的关键功能 在某些情况丧失、系统关键性能不能达到设计指标等。

l B级故障:基本功能不稳定或者丧失、系统重要性能不能达到设计指标等。

l C级故障:主要功能不稳定或者丧失,但对系统其他功能没有严重影响。

l D级故障:系统的主要和基本功能都已实现,Bug 可以绕过,但功能实现不合理,存在某些界面问题,或者操作不方便,容易引起用户歧义或误操作,对系统功能实现没有大的影响的故障。

l E级故障:说明性,建议性的问题。系统功能、性能、界面、操作等各方面存在的需改进的地方。

2.3 缺陷描述的格式

【四个要素】测试帐号/url、操作步骤、预期结果、时间结果

举例:

缺陷的JIRA管理文档

2.4 缺陷提案的补充内容

【附加截屏】上传发现bug时的截屏到提案中,上报 Bug 时建议多采用粘贴截图附件的方式来形象呈现发现的缺陷

【附加文件】上传与提案相关的文件到提案中,该文件能够为提案的解决起到帮助作用

3. 缺陷提案的版本维护

提案版本维护由测试负责人,在每轮缺陷评审会议之后,进行操作

3.1 影响版本

影响版本是指,某缺陷的发现版本,至该缺陷验证关闭的所有版本

后期版本维护,不修改提案的影响版本。

3.2 修正版本

修正版本是指,该问题的解决版本。

后期版本维护需修改修正版本:

l 若经三方会议确认,某提案必须在本次项目中解决,则该提案的修正版本在保持原修改版本的基础上,添加新的修正版本。

举例:

缺陷的JIRA管理文档

此提案原修正版本为:Sina-Space-1.1第一轮系统测试

增加修正版本:Sina-Space-1.1第二轮系统测试

l 若上述提案在第二轮中被重开,则需继续添加修正版本,直到该提案验证通过,关闭为止。

缺陷的JIRA管理文档

l 若经三方会议确认,某提案可以不在本次项目中解决,则将该提案的修正版本改为“规划中版本”。

4. 缺陷处理原则

4.1 缺陷处理流程

缺陷的JIRA管理文档

A.

缺陷的JIRA管理文档

新报的提案,状态为“开放中”。

“已重开”提案,由开发人员处理。

点击【解决提案】

缺陷的JIRA管理文档

【Bug已修正】已解决此提案描述的Bug。

【Bug无法修正】此提案描述的Bug出于技术原因,无法解决。

【任务达成】完成任务类型的提案。

【是重复的】此提案描述的问题,之前已另有提案阐明,需注释重复的提案号。

【不完整】提案的描述内容不清楚,关键步骤缺失。

【无法再现】提案描述的Bug无法重现。

【Not a Bug】经产品人员确认后,确定提案描述的Bug不是Bug,产品定义就是如此。

【延迟处理】提案由于时间进度、上线等原因,经三方确认后,不在当前解决。

【放弃处理】提案由于技术、时间进度等原因,经三方确定后,放弃处理。

B.

缺陷的JIRA管理文档

回归测试不通过的提案,状态为“已重开”

“已重开”提案,由开发人员处理。

点击【解决提案】

缺陷的JIRA管理文档

【Bug已修正】已解决此提案描述的Bug。

【Bug无法修正】此提案描述的Bug出于技术原因,无法解决。

【任务达成】完成任务类型的提案。

【是重复的】此提案描述的问题,之前已另有提案阐明,需注释重复的提案号。

【不完整】提案的描述内容不清楚,关键步骤缺失。

【无法再现】提案描述的Bug无法重现。

【Not a Bug】经产品人员确认后,确定提案描述的Bug不是Bug,产品定义就是如此。

【延迟处理】提案由于时间进度、上线等原因,经三方确认后,不在当前解决。

【放弃处理】提案由于技术、时间进度等原因,经三方确定后,放弃处理。

C.

缺陷的JIRA管理文档

“已解决”提案,由测试人员处理。

回归验证不通过,点击【重开提案】,按照<4.3 提案注释原则>给予注释。

回归验证通过,点击【关闭提案】,按照<4.3 提案注释原则>给予注释。

4.2 缺陷关闭原则

开发人员不得关闭提案。

提案只能由测试人员关闭。

若发现开发人员关闭提案,应及时沟通,之后予以“重开提案”等操作。

4.3 缺陷注释原则

关闭提案,注释为:XXX第X轮系统测试(之冒烟测试X)验证通过

重开提案,注释为:XXX第X轮系统测试(之冒烟测试X)验证失败,原因XXXXX


文章标题:缺陷的JIRA管理文档
新闻来源:http://chengdu.cdxwcx.cn/article/jgcejo.html