!521 update sig-QA docs

* update sig-QA docs

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

-### 缺陷来源
-分两种：社区开发者提交的需求和测试sig在测试过程发现的缺陷提交的issue。
-<br>
-整体出来过程如下图：
+# 缺陷类Issue处理指导
 
-![图片说明](http://image.huawei.com/tiny-lts/v1/images/f81aa437fe1f4f18531aa956ead45a00_1035x656.png@900-0-90-f.png)
-### 缺陷的创建
+## 缺陷来源
+
+社区开发者提交的需求和测试sig在测试过程发现的缺陷提交的issue。
+流程如下图：
+
+![图片说明](figures\issue.png)
+## 缺陷的创建
 [规则 1]：所有缺陷创建按照模板提交
 **【模块名_概率】简要描述：**
 
@@ -31,7 +33,7 @@
 
 - 1. Log、截图、多媒体文件等，所有和问题有关的信息：
 
-### 缺陷审核
+## 缺陷审核
 - [规则 1]：缺陷审核责任人：测试提交缺陷由测试sig组织确认和审核，社区开发者提交缺陷由sig组组织确认和审核<br>
 - [规则 2]：issue各字段需要确保正确，正确的issue字段是度量的基础，在审核环节需要刷新issue的状态，issue的优先级、指定issue责任人<br>
 - [规则 3]：如果经过审核和提交人达成一致，明确是非问题的，可以直接关闭，状态为“已取消”<br>
@@ -39,7 +41,7 @@
 - [规则 5]：如果经过审核和提交人达成一致，明确是问题，但是版本不解决，当前可以直接关闭，状态为“挂起”<br>
 - [规则 6]：如果经过审核和提交人无法达成一致，此类缺陷提交到联合sig组，组织技术评审，按照评审结论执行，或解决或挂起<br>
 
-### 缺陷的修改
+## 缺陷的修改
 - [规则 1]：缺陷修改描述清楚问题发生原因和定位过程。<br>
 - [规则 2]：先定位后修改，原因分析需填写原因分析和修改方案，如有设计文档，按需附上设计文档，指导后续的测试设计和验证。<br>
 - [规则 3]：测试用例设计，白盒自动化用例要做到代码逻辑全覆盖，手工测试用例要做到修改场景上的覆盖。建议：如果修改代码量在50行以下，设计测试用例不少于5条；50行及以上，测试用例在代码行的10%以上；<br>

sig/sig-QA/代码门禁要求.md

-# OpenHarmony 代码门禁质量要求、活动定义及实践介绍
+# OpenHarmony代码门禁质量要求、活动定义及实践介绍
 
-    代码门禁的使用场景：当开发者完成一个issue（Feature、Task、Bug），准备提交PR合入开源主干，在代码合入主干前，会触发代码检视、代码门禁流水线，其中代码门禁负责检查待合入PR新增或者修改的所有文件是否达到质量要求。达到质量要求才允许合入开源主干；否则该PR需要开发者修订检查出来的问题，继续重复提交PR动作。
-    
-    注意：代码门禁的触发以issue为单位，支持一个Issue下面挂多个PR的情况，原因是研发中存在一个Issue单需要多人联合开发场景，或者说多个PR存在关联关系，为了避免代码门禁的重复构建或者PR间的相互依赖，需要以Issue为单位多PR提交后，再触发代码门禁执行。
-     
-    代码门禁的活动定义及实践：代码门禁活动主要分为流水线触发（码云触发流水线执行：webhook模式）、代码下载、构建、部署、测试几个步骤，可参考图-1；其中主要的检查项包含：编译检查、静态/安全/开源检查、敏感词/copyright扫描、部署、冒烟测试、功能测试；因为OpenHarmony涉及多型号开发板验证，为了提升门禁执行效率，使用了基于提交PR识别的精准构建和精准测试。门禁检查结果可以通过码云提交PR的评论区查看（参考图-2）或者直接访问Http://ci.openharmony.cn查看结果（参考图-3）。
+**代码门禁的使用场景**：当开发者完成一个issue（Feature、Task、Bug），准备提交PR合入开源主干，在代码合入主干前，会触发代码检视、代码门禁流水线，其中代码门禁负责检查待合入PR新增或者修改的所有文件是否达到质量要求。达到质量要求才允许合入开源主干；否则该PR需要开发者修订检查出来的问题，继续重复提交PR动作。
+
+注意：代码门禁的触发以issue为单位，支持一个Issue下面挂多个PR的情况，原因是研发中存在一个Issue单需要多人联合开发场景，或者说多个PR存在关联关系，为了避免代码门禁的重复构建或者PR间的相互依赖，需要以Issue为单位多PR提交后，再触发代码门禁执行。
+
+## 代码门禁活动定义
+
+**代码门禁的活动定义及实践**
+
+代码门禁活动主要分为流水线触发（码云触发流水线执行：webhook模式）、代码下载、构建、部署、测试几个步骤，如下图所示。
 
 图-1：代码门禁的主要活动和实践
 
 ![图一](figures/p1.png)
 
+其中主要的检查项包含：编译检查、静态/安全/开源检查、敏感词/copyright扫描、部署、冒烟测试、功能测试。由于OpenHarmony涉及多型号开发板验证，为了提升门禁执行效率，基于提交PR识别精准构建和精准测试。
+
+门禁检查结果可以通过码云提交PR的评论区查看（参考图-2）或者直接访问Http://ci.openharmony.cn查看结果（参考图-3）。
+
 图-2：在码云评论区可以直接查看代码门禁执行结果																							
 
 ![图-2](figures/p2.png)
 
-图-3：OpenHarmony的Ci门户网站，可以直接访问Http://Ci.openharmony.cn ;查看代码门禁、每日版本构建的详细情况。可点击每笔记录，查看详情。
+可以直接访问Http://Ci.openharmony.cn ，查看代码门禁、每日版本构建的详细情况。可点击每笔记录，查看详情。
 
-![图-3](figures/P3.png)
+图-3：OpenHarmony的Ci门户网站
 
+![图-3](figures/P3.png)
 
 
 
-# 代码门禁的质量要求：包含检查项、规范、及操作指南
 
-      代码门禁的质量要求：涉及的PR提交代码等文件必须通过各项检查，才允许代码合入主干。
-      当前门禁检查项包含：编译告警（涉及多型号开发板及模拟器）、构建规范检查（鸿蒙构建规范）、CodeCheck（静态/安全/开源检查、敏感词/copyright扫描）、部署（烧录）、测试（冒烟测试和功能测试）4个部分，下面具体来说明每个部分的检查项及要求。
+## 代码门禁的质量要求：包含检查项、规范、及操作指南
+代码门禁的质量要求：涉及的PR提交代码等文件必须通过各项检查，才允许代码合入主干。
+当前门禁检查项包含：编译告警（涉及多型号开发板及模拟器）、构建规范检查（OpenHarmony构建规范）、CodeCheck（静态/安全/开源检查、敏感词/copyright扫描）、部署（烧录）、测试（冒烟测试和功能测试）4个部分，下面具体来说明每个部分的检查项及要求。
 
-## 编译告警 <a name="section20979554791"></a>
+### 编译告警 <a name="section20979554791"></a>
 
     编译告警主要用于检查代码下载是否Ready(基线代码下载、PR代码获取)、编译环境是否Ready（prebuilds编译依赖工具、lfs二进制工具、node_modules、nodejs、build/lite等）、编译是否通过（全量编译、增量编译、缓存是否OK）、编译选项检查是否最优；
     编译选项检查主要是针对C/C++语言编译选项或系统配置的检查，检查规范涉及语言选项、警告选项、安全选项、总体选项、代码生成选项、架构选项、优化选项、编译宏等。
 
-参考 [Openharmony 编译选项规范](Openharmony_Compile_Rule.md)    
+参考 [OpenHarmony编译规范](编译规范.md)
 
-## 构建规范检查 <a name="section20979554791"></a>
+### 构建规范检查 <a name="section20979554791"></a>
 
-    为指导OpenHarmony的社区开发者开展构建工作，提升构建系统的可重复性、可维护性，提高构建质量，构建规范工作组分析总结了各种典型的构建问题，提炼相应的构建规则和建议，制订了规范，用于保障构建脚本的存放目录、文件格式、编写内容符合要求。 
+为指导OpenHarmony的社区开发者开展构建工作，提升构建系统的可重复性、可维护性，提高构建质量，构建规范工作组分析总结了各种典型的构建问题，提炼相应的构建规则和建议，制订了规范，用于保障构建脚本的存放目录、文件格式、编写内容符合要求。 
 
-具体规范参考[Openharmony 构建规范](Openharmony_Build_Rule.md)    
+具体规范参考《OpenHarmony构建规范 》
 
-## CodeCheck检查 & 屏蔽
+### CodeCheck检查 & 屏蔽
 
 #### CodeCheck检查
-      CodeCheck支持静态扫描、安全扫描、代码度量、开源合规、敏感词扫描、Copyright等检查服务。对于检测问题存在争议，需要和Committer确认，是否为问题或者工具告警在当前代码上下文为非问题。Committer确认问题不用修改，可直接在Ci门户网站登录，系统会提供屏蔽功能，允许Committer屏蔽该问题，以保障该问题不再重复检测出现。
+CodeCheck支持静态扫描、安全扫描、代码度量、开源合规、敏感词扫描、Copyright等检查服务。对于检测问题存在争议，需要和Committer确认，是否为问题或者工具告警在当前代码上下文为非问题。Committer确认问题不用修改，可直接在Ci门户网站登录，系统会提供屏蔽功能，允许Committer屏蔽该问题，以保障该问题不再重复检测出现。
 
 #####  工具及服务使用
-      CI门户：选择任意一个PR的CodeCheck检查结果（包括“通过”、“不通过"、“失败”，若结果为“失败”表示未获取到扫描结果，即不支持查看），进入到代码检查结果查看页面。具体如下。
-1、选择任意一个代码门禁CI流水线执行记录，进入详情查看页面
+CI门户：选择任意一个PR的CodeCheck检查结果（包括“通过”、“不通过"、“失败”，若结果为“失败”表示未获取到扫描结果，即不支持查看），进入到代码检查结果查看页面。具体如下。
+1、选择任意一个代码门禁CI流水线执行记录，进入详情查看页面。
 ![](figures/P4.png)
 
-2、点击CodeCheck检查结果，例如：”不通过“，进入代码检查详情页面
+2、点击CodeCheck检查结果，例如：”不通过“，进入代码检查详情页面。
 ![](figures/P5.png)
 
-      码云：从码云选择提交的PR（对应仓库下的Pull Requests），或从CI门户上选择任意一个PR进入详情后点击合入请求即跳转码云对应的PR，根据评论中start build的时间找到对应的合入记录，即可查看CodeCheck检查返回的结果。具体如下。
+说明：从Gitee码云选择提交的PR（对应仓库下的Pull Requests），或从CI门户上选择任意一个PR进入详情后点击合入请求即跳转Gitee码云对应的PR，根据评论中start build的时间找到对应的合入记录，即可查看CodeCheck检查返回的结果。具体如下。
 
 1、选择任意一个PR的合入请求即可跳转码云对应的PR，如下
-码云入口：
+Gitee码云入口：
 ![](figures/P6.png)
 
 CI门户入口：
 ![](figures/P7.png)
 
-2、根据评论中start build的时间找到对应的合入记录，即可查看CodeCheck检查返回的结果
+2、根据评论中start build的时间找到对应的合入记录，即可查看CodeCheck检查返回的结果。
 
 ![](figures/P2.png)
 
 ##### 静态扫描 
-支持通用&安全编程规范集成；支持C/C++、JAVA、JS。
-具体规则参考 [Openharmony 通用编码规范](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md) 
+支持通用&安全编程规范集成；支持C/C++、JS、Java。
+具体规则参考 [OpenHarmony 通用编码规范](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md) 
 
 ##### 安全扫描
-支持C/C++、Java、JS语言安全编程规范的检查。
-具体规则参考[Openharmony 安全编码规范](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md) 
+支持C/C++、JS、Java语言安全编程规范的检查。
+具体规则参考[OpenHarmony 安全编码规范](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md) 
 
 ##### 代码度量
 支持单仓代码检查；支持代码行、重复率、重复文件数、函数数、圈复杂度总数统计和展示。
@@ -89,13 +98,14 @@ CI门户入口：
 
 
 #### 屏蔽指导
-屏蔽操作主要针对一般以及上问题级别，未登录或者非代码仓的commiter用户无操作权限。当前的主要规则如下(黄区网络暂时无法屏蔽代码问题)：
-1、未解决问题可以修改为已忽略问题；
-2、已忽略问题可以修改为未解决问题；
-3、未解决问题和已忽略问题都无法修改已解决问题
+屏蔽操作主要针对一般以及上问题级别，未登录或者非代码仓的committer用户无操作权限。当前的主要规则如下(黄区网络暂时无法屏蔽代码问题)：
+
+1. 未解决问题可以修改为已忽略问题。
+2. 已忽略问题可以修改为未解决问题。
+3. 未解决问题和已忽略问题都无法修改已解决问题。
 
 #####  单个问题状态修改
-根据过滤器查出出来的结果，选择问题，下拉菜单点击"已忽略"即可。
+根据过滤器查看结果，选择问题，下拉菜单点击"已忽略"即可。
 ![](figures/P8.png)
 
 #####  批量操作问题修改
@@ -105,34 +115,34 @@ CI门户入口：
 ![](figures/P10.png)
 
 ## 部署升级及测试
-      门禁流水线测试涉及的测试活动主要有部署升级、冒烟测试、功能测试、API看护测试。精准测试是对功能测试及API看护测试用例挑选后的精确测试，具体如下： 
+门禁流水线测试涉及的测试活动主要有部署升级、冒烟测试、功能测试、API看护测试。精准测试是对功能测试及API看护测试用例挑选后的精确测试，具体如下： 
 
 #### 冒烟测试
 
-      冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，关注的是阻塞型缺陷。
-      门禁冒烟测试用例是选择功能测试用例中level 0的用例，主要保障版本可以正常开关机，主功能可用，覆盖多种设备形态。
+冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，关注的是阻塞型缺陷。
+门禁冒烟测试用例是选择功能测试用例中level 0的用例，主要保障版本可以正常开关机，主功能可用，覆盖多种设备形态。
 
 #### 功能测试
-      功能测试是对产品的各功能模块进行验证，包含全量测试用例中level 0~5的用例。根据功能用例覆盖结果，测试产品是否达到各模块功能的质量要求。
+功能测试是对产品的各功能模块进行验证，包含全量测试用例中level 0~5的用例。根据功能用例覆盖结果，测试产品是否达到各模块功能的质量要求。
 
 #### API看护测试 
-      根据代码仓与api头文件的关联关系，通过识别所提交的代码对代码仓头文件的修改，触发对应形态下自身代码仓的XTS用例的执行。
+根据代码仓与api头文件的关联关系，通过识别所提交的代码对代码仓头文件的修改，触发对应形态下自身代码仓的XTS用例的执行。
 
 #### 优化：精准构建&精准测试
-      根据代码仓与设备形态之间的关联关系，通过识别所提交的代码对代码仓文件的修改，触发对应形态下所修改的代码仓的TDD level0用例的执行。
+根据代码仓与设备形态之间的关联关系，通过识别所提交的代码对代码仓文件的修改，触发对应形态下所修改的代码仓的TDD level0用例的执行。
 
 #### 代码门禁测试用例上线规则
 
 ##### 门禁问题提单
-1、门禁用例问题第一时间转给第一责任人，经分析后，由第一责任人继续往下分解
+门禁用例问题第一时间转给第一责任人，经分析后，由第一责任人继续往下分解。
 
 
 ##### 门禁响应时间
-1、TDD 用例上线门禁后，定位出用例导致的测试失败，需要两小时内闭环
+TDD 用例上线门禁后，定位出用例导致的测试失败，需要两小时内闭环。
 
 ##### 门禁用例下线
-1、用例问题两小时未解决的，需对应的责任田即时下线，不影响后续的门禁
+用例问题两小时未解决的，需对应的责任田即时下线，不影响后续的门禁。
 
 ##### 门禁用例上线
-1、用例重新上线或者新用例上线，需要责任人提供两天以上的稳定报告并知会我们（门禁看护人），
-2、流水线这边压测48小时后才可重新上线
\ No newline at end of file
+1. 用例重新上线或者新用例上线，需要责任人提供两天以上的稳定报告并知会我们（门禁看护人）。
+2. 流水线这边压测48小时后才可重新上线。
\ No newline at end of file

sig/sig-QA/Openharmony 编译规范.md → sig/sig-QA/编译规范.md

-# Openharmony 编译规范
+# OpenHarmony编译规范
 
 ## 目的和范围
 
-Openharmony 编译规范用于指导开发者规范地编写和修改编译相关的源码、脚本和工具，保证编译过程正确，可信，可重复和高效。
+OpenHarmony编译规范用于指导开发者规范地编写和修改编译相关的源码、脚本和工具，保证编译过程正确，可信，可重复和高效。
 
 ## 术语
 
 ### 编译框架
 
-Openharmony的编译系统就是用来构建Openharmony操作系统的一组软件，主要由模块编译模板，配置框架、发布框架组成。
+OpenHarmony的编译系统就是用来构建OpenHarmony操作系统的一组软件，主要由模块编译模板，配置框架、发布框架组成。
 
-Openharmony的编译系统主要由GN语言和python编写完成，通常GN用于描述编译过程和依赖关系，python用于执行特定的编译目标
+OpenHarmony的编译系统主要由GN(Generate Ninja)语言和Python编写完成，通常GN用于描述编译过程和依赖关系，Python用于执行特定的编译目标
 
-本文主要描述GN的相关编写要求
+本文主要描述GN的相关编写要求。
 
 ### GN
 
-GN : Generate Ninja,   开源的编译工具，使用.gn文件定义和描述编译过程，并生成最终的编译过程清单，即ninja文件
+GN : Generate Ninja,   开源的编译工具，使用.gn文件定义和描述编译过程，并生成最终的编译过程清单，即ninja文件。
 
 ### Ninja
 
-Ninja: 开源的编译执行工具，高效执行ninja文件描述的编译过程清单
+Ninja: 开源的编译执行工具，高效执行ninja文件描述的编译过程清单。
 
 ## GN 编写规范
 
@@ -29,13 +29,13 @@ Ninja: 开源的编译执行工具，高效执行ninja文件描述的编译过
 **禁止** ：在gn中调用外部编译工具编译软件模块。
 **反例** ：在gn中使用action调用automake和Make来编译三方组件。
 **要求**  ：需要将外部组件移植成gn的编译形式，避免编译过程对环境产生不必要的依赖，而且可获得编译框架提供的公共能力，包括不限于：安全编译选项，ASAN等。
-**例外**  ：Linux Kernel 编译框架实际完成的用户态程序编译，内核完全可以在编译框架之外完成独立编译。某些平台实现为了实现一键编译，使用gn将内核编译加在编译过程中，是可以接 受的
+**例外**  ：Linux Kernel 编译框架实际完成的用户态程序编译，内核完全可以在编译框架之外完成独立编译。某些平台实现为了实现一键编译，使用gn将内核编译加在编译过程中，是可以接受的。
 
 ### 规则1.2
 
 **禁止** ：禁止在模块的gn文件中，再次添加编译系统已经添加的安全编译选项。
 **反例** ：在模块的编译添加 `` -fstack-protector-strong``	
-**要求**  ：对于全局已经添加的默认选项，模块开发者应当知晓，不需要为了满足内外部规则再次添加
+**要求**  ：对于全局已经添加的默认选项，模块开发者应当知晓，不需要为了满足内外部规则再次添加。
 
 | 编译选项  | 编译参数  | 默认值  |
 |--|--|--|
@@ -44,27 +44,27 @@ Ninja: 开源的编译执行工具，高效执行ninja文件描述的编译过
 
 ### 规则1.3
 
-**禁止** ：在gn中添加和默认编译选项相反的编译选项
-**反例** ：在自研模块中添加 ``-wno-unused`` 以消除编译告警
-**要求**  ：默认的编译选项代表了系统的默认能力，自研模块有特殊情况需要去掉部分能力，必须有足有的理由
-**例外**  ：移植三方组件，或者使用因为三方组件时，可根据三方组件的要求覆盖默认的编译选项
+**禁止** ：在gn中添加和默认编译选项相反的编译选项。
+**反例** ：在自研模块中添加 ``-wno-unused`` 以消除编译告警。
+**要求**  ：默认的编译选项代表了系统的默认能力，自研模块有特殊情况需要去掉部分能力，必须有足有的理由。
+**例外**  ：移植三方组件，或者使用因为三方组件时，可根据三方组件的要求覆盖默认的编译选项。
 
 ### 规则 2.1
 
-**要求** ：使用gn format 对添加或者修改的gn文件进行格式化，满足格式和排版的需求
+**要求** ：使用gn format 对添加或者修改的gn文件进行格式化，满足格式和排版的需求。
 
 ### 规则 2.2
 
-**建议** ：编写action时，使用python而不是shell
-**说明** :  python 环境更容易保持统一，可以比较容易的多重操作系统上运行，并且扩展性可读性可测试更好
+**建议** ：编写action时，使用Python而不是shell。
+**说明** :  Python 环境更容易保持统一，可以比较容易的多重操作系统上运行，并且扩展性可读性可测试更好。
 
 ### 规则 2.3
-**规则**：禁止在gn和ninja执行过程修改源码目录的内容
-**说明**：包括但不限于给源码目录打patch，向源码目录中拷贝，在源码目录中执行编译，在源码目录生成中间文件等
+**规则**：禁止在gn和ninja执行过程修改源码目录的内容。
+**说明**：包括但不限于给源码目录打patch，向源码目录中拷贝，在源码目录中执行编译，在源码目录生成中间文件等。
 
 ### 规则 2.4
-**规则**：编译脚本的编码格式设置为utf-8，换行符设置为unix格式
-**反例** ：在windows上编写脚本后，使用了中文注释并保存为本地编码
+**规则**：编译脚本的编码格式设置为utf-8，换行符设置为unix格式。
+**反例** ：在windows上编写脚本后，使用了中文注释并保存为本地编码。