mirror of https://gitee.com/openkylin/qa.git
113 lines
5.5 KiB
Markdown
113 lines
5.5 KiB
Markdown
|
||
## openKylin 缺陷issue处理流程
|
||
|
||
### 一、 **提交**
|
||
|
||
所有版本内发现的缺陷均需要以issue的形式提交到码云。
|
||
|
||
内部测试人员需注册账号，签署员工CLA，并按照文档指南进行issue提交： [openKylin社区地址](https://gitee.com/openkylin)
|
||
|
||
进入openKylin社区并点击“任务”，在各个组件仓库下提交并处理缺陷issue，如系统级或无法定位组件的，可提交到QA。
|
||
|
||
提交方法见 [openKylin版本测试参与指南](https://gitee.com/openkylin/qa/blob/master/openKylin版本测试参与指南.md)
|
||
|
||
细节规范：
|
||
|
||
1. 总体要求同禅道bug规范；
|
||
|
||
2. 平板模式下独有缺陷，需在bug标题标注【平板模式】
|
||
|
||
3. RISC-V和ARM架构开发板发现的问题，标题需带有开发板名称，如【RISC-V】【树莓派】,同样在对应组件仓库下提交issue
|
||
|
||
4. 按照规范等级原则设置相应优先级，码云优先级包括$\color{#FF7D00}{严重、主要、次要、不重要}$ ，对齐禅道$\color{#FF7D00}{致命、高、中、低}$，禅道$\color{#FF7D00}{建议}$等级缺陷，在码云也提交为$\color{#FF7D00}{不重要}$等级。
|
||
|
||
当前由于普通账号无权限，需在标题标明【严重/主要/次要/不重要】，由测试审核员审核时跟进标题标注进行选择
|
||
|
||
5. 如果是已在码云或禅道提交过的且未解决的缺陷，无需重复提交
|
||
|
||
### 二、 **确认**
|
||
|
||
1. 测试审核员审核issue，确认此issue类型为缺陷，提交细节符合规范，将该issue状态设置为$\color{#FF0000}{已确认}$，该issue打上$\color{#00FF00}{bug}$标签
|
||
|
||
2. 将issue指派给对应组件仓库Maintainer或对应研发人员
|
||
|
||
3. 如果是与其他issue重复的，测试审核员回复重复issue ID，并打上$\color{#00FF00}{duplicated}$标签并将状态修改为$\color{#FF0000}{已拒绝}$
|
||
|
||
|
||
|
||
### 三、缺陷修复验证
|
||
|
||
研发人员修复问题进行自测，通过后将issue状态修改为$\color{#FF0000}{已修复}$并指回给issue提交测试人员，在issue评论中说明自测通过，备注影响域，如有其他测试建议，也需在评论备注
|
||
|
||
由版本组导出changelog，包括修复issue_ident及包列表，确认提测内容并自测后提测
|
||
|
||
**1. 镜像版本验证**
|
||
|
||
测试人员使用回归版本，根据issue中研发人员评论内容中的影响域进行缺陷验证测试及影响域测试
|
||
|
||
**1）缺陷验证通过**
|
||
|
||
①修改issue状态为$\color{#FF0000}{已验收}$
|
||
|
||
②根据issue中研发人员评论内容中的影响域进行影响域测试
|
||
|
||
③影响域验证发现其他引入问题，提交新的issue
|
||
|
||
**2）缺陷验证不通过**
|
||
|
||
①原缺陷验证不通过时，评论当前现象并将该issue状态设置为$\color{#FF0000}{修复中}$，并将需要指回的issue指派回研发人员，并打$\color{#00FF00}{reopen}$标签
|
||
|
||
②部分验证通过时，原问题修改状态为$\color{#FF0000}{已验收}$，提交新issue，备注说明当前验证情况及新issue_ident
|
||
|
||
**2. 更新升级推送验证**
|
||
|
||
测试人员使用当前发布版本+更新proposed源，根据issue中研发人员评论内容中的影响域进行缺陷验证测试及影响域测试
|
||
|
||
**1）缺陷验证通过**
|
||
|
||
①影响域验证通过，修改issue状态为$\color{#FF0000}{已验收}$并在issue评论中说明验证通过，指派给版本组
|
||
|
||
②影响域验证发现其他引入问题，修改issue状态为$\color{#FF0000}{已验收}$并在issue中进行评论描述此issue验证通过且告知引入问题，指派给版本组
|
||
|
||
③测试汇总当次提测验证情况，回复版本组，版本组根据整个改动测试结果确认合并推送哪些包到release源
|
||
|
||
④版本组将已推送解决的issue状态修改为$\color{#FF0000}{已发布}$
|
||
|
||
**2）缺陷验证不通过**
|
||
|
||
①原缺陷验证不通过时，评论当前现象并将该issue状态设置为$\color{#FF0000}{修复中}$，并将需要指回的issue指派回研发人员，并打$\color{#00FF00}{reopen}$标签
|
||
|
||
②部分验证通过时，原问题修改状态为$\color{#FF0000}{已验收}$，提交新issue，备注说明当前验证情况及新issue_ident
|
||
|
||
### 四、 缺陷属于无效缺陷
|
||
|
||
1. 若研发人员认为issue属于无效问题，包括无法复现、设计如此等，则将$\color{#FF0000}{已确认}$状态的issue状态修改为$\color{#FF0000}{已拒绝}$并指回给对应测试人员
|
||
|
||
2. 对于已拒绝的issue，需要产品、研发、测试等多方评审后进行处理
|
||
|
||
|
||
|
||
**说明**：上文提到的issue_ident指的是如图所示issue标识
|
||
|
||
### 五、 缺陷暂缓处理
|
||
|
||
1. 缺陷经评审后可进行暂缓处理
|
||
|
||
2. 测试人员将可暂缓处理的issue关联$\color{#FF0000}{未来版本}$里程碑
|
||
|
||
3. 后续版本经评审后需要解决的issue则从里程碑中删除，关联至对应版本里程碑
|
||
### 六、 缺陷无法复现
|
||
|
||
1. 不可复现的，打question，与提交者确认详细信息，确认详细情况，确实属于缺陷后，打$\color{#00FF00}{bug}$标签
|
||
|
||
2. 缺陷3个版本后无法复现，或超过3个月反馈者未提供进一步信息，暂先关闭，标记$\color{#FF0000}{已拒绝}$，再次复现或可提供后续信息后，可再次打开，标记$\color{#FF0000}{已确认}$
|
||
|
||
### 七、设置缺陷默认处理时效
|
||
针对新发现并提交的缺陷issue，Release SIG将对其设置默认修复排期，具体如下：
|
||
严重：一周；
|
||
主要：两周；
|
||
次要：一个月；
|
||
不重要：两个月
|
||
|
||
备注：开发者排查问题后如需延长修复时间，请联系Release SIG组进行审核
|