add 社区开发者测试贡献指南 and 社区测试体系介绍

社区开发者测试贡献指南.md

+# 社区开发者测试贡献指南
+
+openEuler社区作为一个开发，创新的平台，欢迎业界所有开发者参与贡献，社区质量保障体系同样需要开发者共同构筑。
+
+在进行贡献前，请先签署[CLA](https://openeuler.org/en/cla.html)
+
+开发者可以从单包级、版本级、工具级三个维度进行openEuler社区测试保障的贡献，详细介绍如下：
+
+## 单包级贡献
+
+### 介绍
+
+单包的质量保障包括如下两方面：
+
+- 开发者测试  
+- 社区众测  
+
+#### 开发者测试
+
+开发者贡献测试代码到软件包对应的上游社区中，通过spec文件中指定的make check动作，在OBS构建二进制包的时候会进行相应用例的测试执行。开发者也可以直接贡献代码到openEuler社区对应项目中。
+
+- 上游社区有相应测试代码时，开发者按照上游社区的贡献规则进行  
+- 上游社区没有相应测试代码时，开发者和上游社区maintainer讨论贡献规则并进行贡献  
+
+#### 社区众测
+
+##### 开发者参与openEuler社区即将发布新需求/特性的测试活动
+
+- 需求分析  
+
+  需求清单可结合[release-management](https://gitee.com/openeuler/release-management)团队的版本发布计划和[社区需求跟踪单](https://gitee.com/open_euler/dashboard/issues?issue_type_id=118737&search=20.09)来查找，详细实现细节可通过需求单评论区链接或者关联仓库查看。
+
+- 测试方案设计  
+
+  在了解清楚特性实现细节后，参考[测试设计方案模板]((https://gitee.com/openeuler/package-reinforce-test/blob/master/单软件包加固测试设计方案参考.mmap))进行测试设计，可通过提PR的方式到[QA](https://gitee.com/openeuler/QA)与QA团队进行方案的讨论
+
+- 编写测试代码  
+
+  openEuler社区已开放[mugen](https://gitee.com/openeuler/test-tools/tree/master/mugen)测试框架，开发者根据讨论后的测试方案按照[测试用例命名及代码编程规范](https://gitee.com/openeuler/package-reinforce-test/blob/master/测试用例命名及代码编程规范.md)编写代码和本地调试
+
+- 代码提交  
+
+  完成编码和调试后，开发者通过PR提交代码到[代码仓](https://gitee.com/openeuler/package-reinforce-test)
+
+##### 开发者参与openEuler社区发布软件包的加固测试
+
+此部分请参考[包加固测试](https://gitee.com/openeuler/package-reinforce-test)
+
+### 说明：
+
+- 虚拟化组件相关组件包测试代码贡献敬请期待  
+- 容器组件相关组件包测试代码贡献敬请期待  
+
+## 版本级测试贡献
+
+openEuler社区版本发布计划请移步[releasemanagement](https://gitee.com/openeuler/release-management)，开发者根据[社区测试体系介绍](https://gitee.com/openeuler/QA)中版本级的测试活动进行相应贡献，具体贡献仓库参见[QA](https://gitee.com/openeuler/QA)中repo地址列表和[repo仓库描述](https://gitee.com/openeuler/community/blob/master/repository/openeuler.yaml)
+
+## 工具贡献
+
+openEuler社区生态的构建和质量保障离不开高效快捷的工具，对QA团队也不例外。开发者可以贡献各类工具到[工具仓](https://gitee.com/openeuler/test-tools)，包括不限于：
+
+- 集成先进测试理念和能力的工具  
+- 高效率的测试框架  
+- 提高编码效率的工具
+

社区测试体系介绍.md

+# 社区测试体系介绍
+
+openEuler是一个开源、免费的Linux发行版平台，通过开放的社区形式与全球的开发者共同构建一个开放、多元并且架构包容的软件生态体系。openEuler发布上千个软件包，如何保障系统整体的质量成为衡量社区的一个重要指标。
+
+从单包级和版本级两个维度介绍openEuler社区是如何进行测试和质量保障的。
+
+## 单包级
+
+### 介绍
+
+openEuler社区软件包根据来源分为两类：上游社区和原创。对单软件包的质量保障从如下三个方面进行覆盖：
+
+- 门禁类检查  
+- 开发者测试  
+- 社区众测  
+
+#### 门禁类检查
+
+开发者通过PR的方式将对软件包的修改提交后，CI工程会自动触发门禁类检查，当门禁类检查通过后进行软件包的编译构建。当前openEuler社区规划的门禁类检查包括：license检查、基本信息检查、接口变更检查、敏感信息检查；各项目的maintainer需要对门禁检查结果进行检查。
+
+#### 开发者测试
+
+当上游社区已有开发者贡献测试代码到软件包的源码中，并且在spec文件中指定make check动作，则OBS构建二进制包的时候会进行相应用例的测试执行，以保证每次对源码的修改不会对软件包的基本接口/功能产生影响。
+
+此部分质量保障依赖开发者主动对软件包进行测试贡献，当开发者提交patch时，补充或者修改相应patch涉及的用例到源码包中，持续丰富单软件包的基本接口和功能验证能力；patch提交者也可通过在对应项目中发布任务类issue，任务中对合入patch进行必要的功能说明，以便其他开发者了解改动内容后贡献相应的测试用例。
+
+openEuler社区秉承’upstream first‘ 的原则，建议开发者直接贡献patch和相应用例代码到上游社区，openEuler社区会进行同步，当然openEuler社区也欢迎开发者直接贡献。
+
+#### 社区众测
+
+openEuler作为一个开放、创新的linux社区，欢迎业界所有开发者参与到社区的各类活动中。社区众测顾名思义需要更多的开发者投入到社区的质量保障活动中，对新特性引入/修改的软件包以及升级修改影响较大的包进行测试验证和质量保障。
+
+QA团队运维的测试开放日(test open day)就是为社区众测提供的一个平台，详见[测试开放日(敬请期待)]()
+
+## 版本级
+
+### 介绍
+
+openEuler社区版本发布计划请移步[releasemanagement](https://gitee.com/openeuler/release-management)，QA团队对规划的版本进行质量保障测试。openEuler社区版本按照构建分类如下：
+
+- daily build版本  
+- β版本  
+- release发布版本  
+
+#### daily build版本
+
+Daily build版本即日构建版本，CI工程从各个项目代码仓中拉取相应包编译构建后集成构建出ISO。成功构建后，自动触发版本的冒烟测试，具体覆盖项：
+
+- 安装部署  
+- 软件包安装/卸载   
+- 组件测试(内核/虚拟化/容器/编译器等)  
+- 系统集成类用户场景测试  
+- 系统服务类(登录/防火墙/分区/服务状态检查/日志/kdump)
+
+#### β版本
+
+β版本是在daily build版本基础上，合入正式发布版本规划的新需求和特性后提供给社区用户预使用的版本，此版本能够满足社区用户基本需求，版本质量基本稳定。在版本发布前，QA团队会进行和组织更全面的测试覆盖：
+
+- 冒烟测试内容  
+- 新需求/特性功能验证  
+- 性能测试   
+- 升级  
+- 社区众测  
+
+#### release版本
+
+release版本即社区规划的两年发布周期LTS版本和六个月发布周期创新版本，此版本是社区对外发布的正式版本，质量要求更高，具体测试覆盖如下：
+
+- β版本测试内容     
+- 压力稳定性测试  
+- 安全测试  
+- 兼容性测试  
+- 文档测试
+
+
+
+
+