!1001 更新issue处理规则

* update issue handle rules

sig/sig-QA/issue-缺陷类-处理指导.md

-# 缺陷类Issue处理指导
-
 ## 缺陷来源
 
 社区开发者提交的需求和测试sig在测试过程发现的缺陷提交的issue。
@@ -44,24 +42,36 @@
 ## 缺陷的修改
 - [规则 1]：缺陷修改描述清楚问题发生原因和定位过程。<br>
 - [规则 2]：先定位后修改，原因分析需填写原因分析和修改方案，如有设计文档，按需附上设计文档，指导后续的测试设计和验证。<br>
-- [规则 3]：测试用例设计，白盒自动化用例要做到代码逻辑全覆盖，手工测试用例要做到修改场景上的覆盖。建议：如果修改代码量在50行以下，设计测试用例不少于5条；50行及以上，测试用例在代码行的10%以上；<br>
-- [规则 4]：如果问题单涉及多人、多sig组同步修改或上下层同时修改，建议新建issue，把相关issue关联起来<br>
+- [规则 3]：测试用例设计，白盒自动化用例要做到代码逻辑全覆盖，手工测试用例要做到修改场景上的覆盖。建议：如果修改代码量在50行以下，设计测试用例不少于5条；50行及以上，测试用例在代码行的10%以上；如果该issue因为缺少用例导致问题遗留到发布版本，修复问题的同时需要补充提交测试用例。<br>
+- [规则 4]：如果问题单涉及多人、多sig组同步修改或上下层同时修改，建议新建issue，把相关issue关联起来。<br>
 - [规则 5]：如果转给其他责任人修改，需要和对应sig组对齐达成一致后转移责任人，如果issue所属代码仓错误，和对应仓责任人沟通确认后编辑修改到正确代码仓。代码仓和责任人是issue度量的基础，度量看板严格按照代码仓和责任人卷积到对应组织。<br>
 - [规则 6]：首问责任制：issue的处理按照首问责任制执行，issue提交到哪个代码仓下，首问哪个代码仓对应的sig组负责组织定位<br>
 - [规则 7]：缺陷的状态是缺陷管理的基础，需要责任人及时更新缺陷的状态字段，OpenHarmony社区定义的状态有如下：<br>
 
 |  序号 |状态   |处理责任人   |说明   |
 | ------------ | ------------ | ------------ | ------------ |
-|1   | 待办的  | 提交者  |   |
+| 1  | 待办的  | 提交者  |   |
 | 2  | 已确认  | sig组  | 按照测试sig提交缺陷有测试组织确认，开发者提交缺陷由sig组组织确认  |
 | 3  | 技术评审中  | 联合sig  | 对缺陷方案有争议，要到联合sig/PMC上决策  |
 | 4  | 修复中  | sig组  | sig组负责修复并提交pr  |
 | 5  | 验收中  | 测试或issue提交者  | pr提交后走到测试验收或对应提交者验收  |
 | 6  | 已完成  | 测试或issue提交者  | 经过验收后状态走到已完成状态，表示issue处理闭环  |
 | 7  | 已取消  | 测试或issue提交者  | 经过确认和提交者达成一致意见后可以取消  |
-| 8  | 已拒绝  | sig组  | 经过确认和提交者达成一致意见后，可以决绝  |
+| 8  | 已拒绝  | sig组  | 经过确认和提交者达成一致意见后，可以拒绝  |
 | 9  | 已挂起  | sig组  | 经过确认和提交者无法达成一致意见经过联合sig/PMC评审决策后问题可以挂起，暂不解决，明确后面版本解决计划  |
 
+## 缺陷回归验证
+- [规则 1]：社区issue修复后，需要由issue提交人确认关闭，修改人不能自己关闭。<br>
+- [规则 2]：issue提交人收到修复方案后，如果30天内未进行确认，负责修改的sig可评估是否关闭issue。<br>
+- [规则 3]：“验收中”环节回归测试后，要附上测试报告，不能直接关闭或简单评论后关闭。<br>
+- 测试报告参考模板：
+
+ **【回归测试结果】:**
+
+ **【回归测试软件版本】：**
 
+ **【单板信息】：**
 
+ **【回归测试次数】：**
 
+ **【测试过程】：**
\ No newline at end of file