# 缺陷类Issue处理指导
## 缺陷来源
社区开发者提交的需求和测试sig在测试过程发现的缺陷提交的issue。
流程如下图:
![图片说明](figures/issue.png)
## 缺陷的创建
[规则 1]:所有缺陷创建按照模板提交
**【模块名_概率】简要描述:**
**【环境信息】:**
- 网络环境
- 硬件开发板型号
- 软件版本信息或tag节点
- 测试环境
- 其他
**【预置条件】:**
**【测试步骤】:**
**【预期结果】:**
**【实际结果】:**
**【恢复手段】:**
**【出现概率】:问题出现次数/实际测试次数**
**【定位信息】:**
- 1. Log、截图、多媒体文件等,所有和问题有关的信息:
## 缺陷审核
- [规则 1]:缺陷审核责任人:测试提交缺陷由测试sig组织确认和审核,社区开发者提交缺陷由sig组组织确认和审核
- [规则 2]:issue各字段需要确保正确,正确的issue字段是度量的基础,在审核环节需要刷新issue的状态,issue的优先级、指定issue责任人
- [规则 3]:如果经过审核和提交人达成一致,明确是非问题的,可以直接关闭,状态为“已取消”
- [规则 4]:如果经过审核和提交人达成一致,明确是已知重复问题的,可以把已知issue号关联起来,可以直接关闭,状态为“已取消”
- [规则 5]:如果经过审核和提交人达成一致,明确是问题,但是版本不解决,当前可以直接关闭,状态为“挂起”
- [规则 6]:如果经过审核和提交人无法达成一致,此类缺陷提交到联合sig组,组织技术评审,按照评审结论执行,或解决或挂起
## 缺陷的修改
- [规则 1]:缺陷修改描述清楚问题发生原因和定位过程。
- [规则 2]:先定位后修改,原因分析需填写原因分析和修改方案,如有设计文档,按需附上设计文档,指导后续的测试设计和验证。
- [规则 3]:测试用例设计,白盒自动化用例要做到代码逻辑全覆盖,手工测试用例要做到修改场景上的覆盖。建议:如果修改代码量在50行以下,设计测试用例不少于5条;50行及以上,测试用例在代码行的10%以上;
- [规则 4]:如果问题单涉及多人、多sig组同步修改或上下层同时修改,建议新建issue,把相关issue关联起来
- [规则 5]:如果转给其他责任人修改,需要和对应sig组对齐达成一致后转移责任人,如果issue所属代码仓错误,和对应仓责任人沟通确认后编辑修改到正确代码仓。代码仓和责任人是issue度量的基础,度量看板严格按照代码仓和责任人卷积到对应组织。
- [规则 6]:首问责任制:issue的处理按照首问责任制执行,issue提交到哪个代码仓下,首问哪个代码仓对应的sig组负责组织定位
- [规则 7]:缺陷的状态是缺陷管理的基础,需要责任人及时更新缺陷的状态字段,OpenHarmony社区定义的状态有如下:
| 序号 |状态 |处理责任人 |说明 |
| ------------ | ------------ | ------------ | ------------ |
|1 | 待办的 | 提交者 | |
| 2 | 已确认 | sig组 | 按照测试sig提交缺陷有测试组织确认,开发者提交缺陷由sig组组织确认 |
| 3 | 技术评审中 | 联合sig | 对缺陷方案有争议,要到联合sig/PMC上决策 |
| 4 | 修复中 | sig组 | sig组负责修复并提交pr |
| 5 | 验收中 | 测试或issue提交者 | pr提交后走到测试验收或对应提交者验收 |
| 6 | 已完成 | 测试或issue提交者 | 经过验收后状态走到已完成状态,表示issue处理闭环 |
| 7 | 已取消 | 测试或issue提交者 | 经过确认和提交者达成一致意见后可以取消 |
| 8 | 已拒绝 | sig组 | 经过确认和提交者达成一致意见后,可以决绝 |
| 9 | 已挂起 | sig组 | 经过确认和提交者无法达成一致意见经过联合sig/PMC评审决策后问题可以挂起,暂不解决,明确后面版本解决计划 |