2022-10-20 17:00:39 +08:00
|
|
|
|
|
|
|
|
|
## openKylin 缺陷issue处理流程
|
|
|
|
|
|
|
|
|
|
### 一、 **提交**
|
|
|
|
|
|
|
|
|
|
进入openKylin社区并点击“任务”,在各个组件仓库下提交并处理缺陷issue,如系统级或无法定位组件的,可提交到community。
|
|
|
|
|
|
|
|
|
|
提交规范见 [openKylin版本测试参与指南](https://gitee.com/openkylin/qa/blob/master/openKylin版本测试参与指南.md)
|
|
|
|
|
|
|
|
|
|
细节规范:
|
|
|
|
|
|
|
|
|
|
1. 总体要求同禅道bug规范;
|
|
|
|
|
|
|
|
|
|
2. 平板模式下独有缺陷,需在bug标题标注【平板模式】
|
|
|
|
|
|
|
|
|
|
3. 按照规范等级原则设置相应优先级,码云优先级包括$\color{#FF7D00}{严重、主要、次要、不重要}$ ,对齐禅道$\color{#FF7D00}{致命、高、中、低}$,禅道$\color{#FF7D00}{建议}$等级缺陷,在码云也提交为$\color{#FF7D00}{不重要}$等级。
|
|
|
|
|
|
|
|
|
|
当前由于普通账号无权限,需在标题标明【严重/主要/次要/不重要】,由测试审核员审核时跟进标题标注进行选择
|
|
|
|
|
|
2022-11-11 14:18:57 +08:00
|
|
|
|
4. 如果是已在码云或禅道提交过的且未解决的缺陷,无需重复提交
|
|
|
|
|
|
2022-10-20 17:00:39 +08:00
|
|
|
|
### 二、 **确认**
|
|
|
|
|
|
|
|
|
|
1. 测试审核员审核issue,确认此issue类型为缺陷,提交细节符合规范,将该issue状态设置为$\color{#FF0000}{已确认}$,该issue打上$\color{#00FF00}{bug}$标签
|
|
|
|
|
|
|
|
|
|
2. 将issue指派给对应组件仓库Maintainer或对应研发人员
|
|
|
|
|
|
2022-10-20 17:38:51 +08:00
|
|
|
|
3. 如果是与其他issue重复的,测试审核员打上$\color{#00FF00}{duplicated}$标签并将状态修改为$\color{#FF0000}{已完成}$
|
2022-10-20 17:00:39 +08:00
|
|
|
|
|
2022-11-11 14:18:57 +08:00
|
|
|
|
|
|
|
|
|
|
2022-10-20 17:00:39 +08:00
|
|
|
|
### 三、缺陷修复验证
|
|
|
|
|
|
|
|
|
|
研发人员修复问题进行自测,通过后将issue状态修改为$\color{#FF0000}{已修复}$并指回给issue提交测试人员,在issue评论中说明自测通过,备注影响域,如有其他测试建议,也需在评论备注
|
|
|
|
|
|
|
|
|
|
由版本组导出changelog,包括修复issue_ident及包列表,确认提测内容并自测后提测
|
|
|
|
|
|
|
|
|
|
**1. 镜像版本验证**
|
|
|
|
|
|
|
|
|
|
测试人员使用回归版本,根据issue中研发人员评论内容中的影响域进行缺陷验证测试及影响域测试
|
|
|
|
|
|
2022-10-20 17:38:51 +08:00
|
|
|
|
**1)缺陷验证通过**
|
2022-10-20 17:00:39 +08:00
|
|
|
|
|
|
|
|
|
①修改issue状态为$\color{#FF0000}{已验收}$
|
|
|
|
|
|
|
|
|
|
②根据issue中研发人员评论内容中的影响域进行影响域测试
|
|
|
|
|
|
|
|
|
|
③影响域验证发现其他引入问题,提交新的issue
|
|
|
|
|
|
2022-10-20 17:38:51 +08:00
|
|
|
|
**2)缺陷验证不通过**
|
2022-10-20 17:00:39 +08:00
|
|
|
|
|
2022-11-11 14:18:57 +08:00
|
|
|
|
①原缺陷验证不通过时,评论当前现象并将该issue状态设置为$\color{#FF0000}{修复中}$,并将需要指回的issue指派回研发人员,并打$\color{#00FF00}{reopen}$标签
|
2022-10-20 17:00:39 +08:00
|
|
|
|
|
|
|
|
|
②部分验证通过时,原问题修改状态为$\color{#FF0000}{已验收}$,提交新issue,备注说明当前验证情况及新issue_ident
|
|
|
|
|
|
|
|
|
|
**2. 更新升级推送验证**
|
|
|
|
|
|
|
|
|
|
测试人员使用当前发布版本+更新proposed源,根据issue中研发人员评论内容中的影响域进行缺陷验证测试及影响域测试
|
|
|
|
|
|
2022-10-20 17:38:51 +08:00
|
|
|
|
**1)缺陷验证通过**
|
2022-10-20 17:00:39 +08:00
|
|
|
|
|
|
|
|
|
①影响域验证通过,修改issue状态为$\color{#FF0000}{已验收}$并在issue评论中说明验证通过,指派给版本组
|
|
|
|
|
|
|
|
|
|
②影响域验证发现其他引入问题,修改issue状态为$\color{#FF0000}{已验收}$并在issue中进行评论描述此issue验证通过且告知引入问题,指派给版本组
|
|
|
|
|
|
|
|
|
|
③测试汇总当次提测验证情况,回复版本组,版本组根据整个改动测试结果确认合并推送哪些包到release源
|
|
|
|
|
|
|
|
|
|
④版本组将已推送解决的issue状态修改为$\color{#FF0000}{已发布}$
|
|
|
|
|
|
2022-10-20 17:38:51 +08:00
|
|
|
|
**2)缺陷验证不通过**
|
2022-10-20 17:00:39 +08:00
|
|
|
|
|
2022-11-11 14:18:57 +08:00
|
|
|
|
①原缺陷验证不通过时,评论当前现象并将该issue状态设置为$\color{#FF0000}{修复中}$,并将需要指回的issue指派回研发人员,并打$\color{#00FF00}{reopen}$标签
|
2022-10-20 17:00:39 +08:00
|
|
|
|
|
|
|
|
|
②部分验证通过时,原问题修改状态为$\color{#FF0000}{已验收}$,提交新issue,备注说明当前验证情况及新issue_ident
|
|
|
|
|
|
|
|
|
|
### 四、 缺陷属于无效缺陷
|
|
|
|
|
|
|
|
|
|
1. 若研发人员认为issue属于无效问题,包括无法复现、设计如此等,则将$\color{#FF0000}{已确认}$状态的issue状态修改为$\color{#FF0000}{已拒绝}$并指回给对应测试人员
|
|
|
|
|
|
|
|
|
|
2. 对于已拒绝的issue,需要产品、研发、测试等多方评审后进行处理
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**说明**:上文提到的issue_ident指的是如图所示issue标识
|
2022-11-11 14:12:19 +08:00
|
|
|
|
![输入图片说明](image/image-2.png)
|