issue_缺陷类_处理指导.md 4.7 KB
Newer Older
N
NEEN 已提交
1 2 3 4 5
## 缺陷来源

社区开发者提交的需求和测试sig在测试过程发现的缺陷提交的issue。
流程如下图:

N
NEEN 已提交
6
![图片说明](figures/issue.png)
N
NEEN 已提交
7
## 缺陷的创建
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
[规则 1]:所有缺陷创建按照模板提交
**【模块名_概率】简要描述:**

 **【环境信息】:** 
- 网络环境
- 硬件开发板型号
- 软件版本信息或tag节点
- 测试环境
- 其他

 **【预置条件】:**

 **【测试步骤】:**

 **【预期结果】:**

 **【实际结果】:**

 **【恢复手段】:**

 **【出现概率】:问题出现次数/实际测试次数**

 **【定位信息】:**

- 1. Log、截图、多媒体文件等,所有和问题有关的信息:

N
NEEN 已提交
34
## 缺陷审核
35 36 37 38 39 40 41
- [规则 1]:缺陷审核责任人:测试提交缺陷由测试sig组织确认和审核,社区开发者提交缺陷由sig组组织确认和审核<br>
- [规则 2]:issue各字段需要确保正确,正确的issue字段是度量的基础,在审核环节需要刷新issue的状态,issue的优先级、指定issue责任人<br>
- [规则 3]:如果经过审核和提交人达成一致,明确是非问题的,可以直接关闭,状态为“已取消”<br>
- [规则 4]:如果经过审核和提交人达成一致,明确是已知重复问题的,可以把已知issue号关联起来,可以直接关闭,状态为“已取消”<br>
- [规则 5]:如果经过审核和提交人达成一致,明确是问题,但是版本不解决,当前可以直接关闭,状态为“挂起”<br>
- [规则 6]:如果经过审核和提交人无法达成一致,此类缺陷提交到联合sig组,组织技术评审,按照评审结论执行,或解决或挂起<br>

N
NEEN 已提交
42
## 缺陷的修改
43 44
- [规则 1]:缺陷修改描述清楚问题发生原因和定位过程。<br>
- [规则 2]:先定位后修改,原因分析需填写原因分析和修改方案,如有设计文档,按需附上设计文档,指导后续的测试设计和验证。<br>
N
Neil 已提交
45 46
- [规则 3]:测试用例设计,白盒自动化用例要做到代码逻辑全覆盖,手工测试用例要做到修改场景上的覆盖。建议:如果修改代码量在50行以下,设计测试用例不少于5条;50行及以上,测试用例在代码行的10%以上;如果该issue因为缺少用例导致问题遗留到发布版本,修复问题的同时需要补充提交测试用例。<br>
- [规则 4]:如果问题单涉及多人、多sig组同步修改或上下层同时修改,建议新建issue,把相关issue关联起来。<br>
47 48 49 50 51 52
- [规则 5]:如果转给其他责任人修改,需要和对应sig组对齐达成一致后转移责任人,如果issue所属代码仓错误,和对应仓责任人沟通确认后编辑修改到正确代码仓。代码仓和责任人是issue度量的基础,度量看板严格按照代码仓和责任人卷积到对应组织。<br>
- [规则 6]:首问责任制:issue的处理按照首问责任制执行,issue提交到哪个代码仓下,首问哪个代码仓对应的sig组负责组织定位<br>
- [规则 7]:缺陷的状态是缺陷管理的基础,需要责任人及时更新缺陷的状态字段,OpenHarmony社区定义的状态有如下:<br>

|  序号 |状态   |处理责任人   |说明   |
| ------------ | ------------ | ------------ | ------------ |
N
Neil 已提交
53
| 1  | 待办的  | 提交者  |   |
54 55 56 57 58 59
| 2  | 已确认  | sig组  | 按照测试sig提交缺陷有测试组织确认,开发者提交缺陷由sig组组织确认  |
| 3  | 技术评审中  | 联合sig  | 对缺陷方案有争议,要到联合sig/PMC上决策  |
| 4  | 修复中  | sig组  | sig组负责修复并提交pr  |
| 5  | 验收中  | 测试或issue提交者  | pr提交后走到测试验收或对应提交者验收  |
| 6  | 已完成  | 测试或issue提交者  | 经过验收后状态走到已完成状态,表示issue处理闭环  |
| 7  | 已取消  | 测试或issue提交者  | 经过确认和提交者达成一致意见后可以取消  |
N
Neil 已提交
60
| 8  | 已拒绝  | sig组  | 经过确认和提交者达成一致意见后,可以拒绝  |
61 62
| 9  | 已挂起  | sig组  | 经过确认和提交者无法达成一致意见经过联合sig/PMC评审决策后问题可以挂起,暂不解决,明确后面版本解决计划  |

N
Neil 已提交
63 64 65 66 67 68 69 70 71
## 缺陷回归验证
- [规则 1]:社区issue修复后,需要由issue提交人确认关闭,修改人不能自己关闭。<br>
- [规则 2]:issue提交人收到修复方案后,如果30天内未进行确认,负责修改的sig可评估是否关闭issue。<br>
- [规则 3]:“验收中”环节回归测试后,要附上测试报告,不能直接关闭或简单评论后关闭。<br>
- 测试报告参考模板:

 **【回归测试结果】:**

 **【回归测试软件版本】:**
72

N
Neil 已提交
73
 **【单板信息】:**
74

N
Neil 已提交
75
 **【回归测试次数】:**
76

N
Neil 已提交
77
 **【测试过程】:**