From 794508a90180b75e68417b13ae76955731e0031e Mon Sep 17 00:00:00 2001 From: huazi Date: Tue, 14 Sep 2021 12:14:34 +0000 Subject: [PATCH 1/2] =?UTF-8?q?issue(=E9=9C=80=E6=B1=82=EF=BC=89=E5=A4=84?= =?UTF-8?q?=E7=90=86=E8=A7=84=E8=8C=83=E3=80=81=E7=89=88=E6=9C=AC=E8=B4=A8?= =?UTF-8?q?=E9=87=8F=E8=A6=81=E6=B1=82=E3=80=81=E4=BB=A3=E7=A0=81=E9=97=A8?= =?UTF-8?q?=E7=A6=81=E8=A6=81=E6=B1=82=E3=80=81=E9=9B=86=E6=88=90=E6=B5=8B?= =?UTF-8?q?=E8=AF=95=E7=B3=BB=E7=BB=9F=20Signed-off-by:=20xhuazi?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...04\347\220\206\346\214\207\345\257\274.md" | 42 +++ ...50\347\246\201\350\246\201\346\261\202.md" | 138 +++++++++ ...50\351\207\217\350\246\201\346\261\202.md" | 25 ++ ...13\350\257\225\344\273\213\347\273\215.md" | 265 ++++++++++++++++++ 4 files changed, 470 insertions(+) create mode 100644 "sig/sig-QA/issue\357\274\210\351\234\200\346\261\202\347\261\273\357\274\211\345\244\204\347\220\206\346\214\207\345\257\274.md" create mode 100644 "sig/sig-QA/\344\273\243\347\240\201\351\227\250\347\246\201\350\246\201\346\261\202.md" create mode 100644 "sig/sig-QA/\347\211\210\346\234\254\350\264\250\351\207\217\350\246\201\346\261\202.md" create mode 100644 "sig/sig-QA/\351\233\206\346\210\220\346\265\213\350\257\225\344\273\213\347\273\215.md" diff --git "a/sig/sig-QA/issue\357\274\210\351\234\200\346\261\202\347\261\273\357\274\211\345\244\204\347\220\206\346\214\207\345\257\274.md" "b/sig/sig-QA/issue\357\274\210\351\234\200\346\261\202\347\261\273\357\274\211\345\244\204\347\220\206\346\214\207\345\257\274.md" new file mode 100644 index 00000000..5465b592 --- /dev/null +++ "b/sig/sig-QA/issue\357\274\210\351\234\200\346\261\202\347\261\273\357\274\211\345\244\204\347\220\206\346\214\207\345\257\274.md" @@ -0,0 +1,42 @@ +### 需求的收集及决策： +- 需求收集责任人：社区开发者随时可以提交需求类issue，对应sig负责需求收集和整理。 +- 需求决策组织：sig组需求分析后提交PMC组织需求价值评审和排序，在PMC决策接纳或拒绝需求。 + +### 需求交付计划制定 +- 里程碑制定：release-sig组发布迭代交付里程碑。 +- 需求交付计划：所有需求经PMC评审后接纳的需求，需要明确交付计划，每个需求必须指定里程碑点，并按照计划交付。 + +### 需求分解及依赖管理 +原始需求颗粒度不同，需要经过分解形成可以指导开发的需求列表，一个需求如果描述不清楚需要分解到场景清晰、能够验收、质量目标明确（性能、功耗等基础特性）的粒度，需求的分解通过子任务和父任务进行关联关联，所有原始需求作为一级需求，每个原始需求建议分解到一个二级需求（子任务），如果二级需求依然粒度大，可以继续分解，直至能够达成需求描述可以直接指导开发实现的程度，建议最高分解到三级需求（三级子任务）： +- 建议所有原始需求要分解到二级需求。 +- 所有最终分解的需求达成场景清晰、可验收、质量目标明确的目标。 +- 最小化原则：每个最小粒度需求不跨仓，唯一一个开发者完成。 +- 如果需求和其他需求依赖，必须指定需求依赖关系。 +- 需求分解需要指定协作者，协作者需要包括测试，安全和资料，协作者负责对应领域的需求评审，所有需求必须经过协作者评审通过。 +- 每个需求分解需明确性能、功耗、安全等基础特性对应规格目标。 +- 每个需求如果涉及对外接口或对开发者使用有变化，必须分解一个文档类需求。 +- 设计方案变更或大粒度需求，要输出设计文档，每个sig组维护一个模块设计文档。 + +### 需求分配 +- 每个需求明确责任人。 +- 每个需求需预估工作量。 +- 开发者认领需求如果出现一次延期，可以申请交付计划变更一次，再次计划延期时间原则上不能超过原计划需求工作量的20%，如果出现再次延期，由sig组有权重新分配责任人或调整交付范围。 + + + ### 需求类issue各字段的要求 +- issue状态字段是跟踪管理issue重要的信息，需要在处理issue环节及时更新 +| 状态字段 | 负责人 | 描述 | +| ------------ | ------------ | ------------ | +| 待办 | 提交者 | 任何开发者都可以提交需求到社区，初始状态为待办 | +| 已确认 |sig组 |由sig组指定责任人收集需求，并和提交者确认 | +| 已分解 |sig组 |需求经过评审接纳后分解需求，组织需求分配责任人 | +| 设计中 |需求责任人 | 按照设计要求输出设计文档 | +| 开发中 |需求责任人 | 代码开发，本地验证，提交pr到社区，开发完成指定需求回归测试人员 | +| 验收中 |测试 |由测试人员回归验收需求 | +| 已完成 |测试 |经过测试验收后的需求 | +| 已拒绝 |sig组 |经和提交者确认或PMC评审，此需求不接纳 | + + + + + diff --git "a/sig/sig-QA/\344\273\243\347\240\201\351\227\250\347\246\201\350\246\201\346\261\202.md" "b/sig/sig-QA/\344\273\243\347\240\201\351\227\250\347\246\201\350\246\201\346\261\202.md" new file mode 100644 index 00000000..2c6d9333 --- /dev/null +++ "b/sig/sig-QA/\344\273\243\347\240\201\351\227\250\347\246\201\350\246\201\346\261\202.md" @@ -0,0 +1,138 @@ +# 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）。 + +图-1：代码门禁的主要活动和实践 + +![图一](figures/p1.png) + +图-2：在码云评论区可以直接查看代码门禁执行结果 + +![图-2](figures/p2.png) + +图-3：OpenHarmony的Ci门户网站，可以直接访问Http://Ci.openharmony.cn ;查看代码门禁、每日版本构建的详细情况。可点击每笔记录，查看详情。 + +![图-3](figures/P3.png) + + + + +# 代码门禁的质量要求：包含检查项、规范、及操作指南 + + 代码门禁的质量要求：涉及的PR提交代码等文件必须通过各项检查，才允许代码合入主干。 + 当前门禁检查项包含：编译告警（涉及多型号开发板及模拟器）、构建规范检查（鸿蒙构建规范）、CodeCheck（静态/安全/开源检查、敏感词/copyright扫描）、部署（烧录）、测试（冒烟测试和功能测试）4个部分，下面具体来说明每个部分的检查项及要求。 + +## 编译告警 + + 编译告警主要用于检查代码下载是否Ready(基线代码下载、PR代码获取)、编译环境是否Ready（prebuilds编译依赖工具、lfs二进制工具、node_modules、nodejs、build/lite等）、编译是否通过（全量编译、增量编译、缓存是否OK）、编译选项检查是否最优； + 编译选项检查主要是针对C/C++语言编译选项或系统配置的检查，检查规范涉及语言选项、警告选项、安全选项、总体选项、代码生成选项、架构选项、优化选项、编译宏等。 + +参考 [Openharmony 编译选项规范](Openharmony_Compile_Rule.md) + +## 构建规范检查 + + 为指导OpenHarmony的社区开发者开展构建工作，提升构建系统的可重复性、可维护性，提高构建质量，构建规范工作组分析总结了各种典型的构建问题，提炼相应的构建规则和建议，制订了规范，用于保障构建脚本的存放目录、文件格式、编写内容符合要求。 + +具体规范参考[Openharmony 构建规范](Openharmony_Build_Rule.md) + +## CodeCheck检查 & 屏蔽 + +#### CodeCheck检查 + CodeCheck支持静态扫描、安全扫描、代码度量、开源合规、敏感词扫描、Copyright等检查服务。对于检测问题存在争议，需要和Committer确认，是否为问题或者工具告警在当前代码上下文为非问题。Committer确认问题不用修改，可直接在Ci门户网站登录，系统会提供屏蔽功能，允许Committer屏蔽该问题，以保障该问题不再重复检测出现。 + +##### 工具及服务使用 + CI门户：选择任意一个PR的CodeCheck检查结果（包括“通过”、“不通过"、“失败”，若结果为“失败”表示未获取到扫描结果，即不支持查看），进入到代码检查结果查看页面。具体如下。 +1、选择任意一个代码门禁CI流水线执行记录，进入详情查看页面 +![](figures/P4.png) + +2、点击CodeCheck检查结果，例如：”不通过“，进入代码检查详情页面 +![](figures/P5.png) + + 码云：从码云选择提交的PR（对应仓库下的Pull Requests），或从CI门户上选择任意一个PR进入详情后点击合入请求即跳转码云对应的PR，根据评论中start build的时间找到对应的合入记录，即可查看CodeCheck检查返回的结果。具体如下。 + +1、选择任意一个PR的合入请求即可跳转码云对应的PR，如下 +码云入口： +![](figures/P6.png) + +CI门户入口： +![](figures/P7.png) + +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++、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) + +##### 代码度量 +支持单仓代码检查；支持代码行、重复率、重复文件数、函数数、圈复杂度总数统计和展示。 + + +##### 开源及第三方 +支持开源及第三方软件的源码文件、二进制文件扫描，提供风险扫描及评估能力。 + +##### 敏感词扫描 +支持配置敏感词清单，输出文件名、路径名、文件内容中的敏感词扫描结果。 + + +##### Copyright +支持基于文件夹、文件名、文件后缀配置Copyright规则，规则可以配置Copyright类型和逻辑。 + + +#### 屏蔽指导 +屏蔽操作主要针对一般以及上问题级别，未登录或者非代码仓的commiter用户无操作权限。当前的主要规则如下(黄区网络暂时无法屏蔽代码问题)： +1、未解决问题可以修改为已忽略问题； +2、已忽略问题可以修改为未解决问题； +3、未解决问题和已忽略问题都无法修改已解决问题 + +##### 单个问题状态修改 +根据过滤器查出出来的结果，选择问题，下拉菜单点击"已忽略"即可。 +![](figures/P8.png) + +##### 批量操作问题修改 +选择要修改的问题后点击 "批量操作"，设置修改后的问题状态为"已忽略"，然后“确认”即可。 +![](figures/P9.png) + +![](figures/P10.png) + +## 部署升级及测试 + 门禁流水线测试涉及的测试活动主要有部署升级、冒烟测试、功能测试、API看护测试。精准测试是对功能测试及API看护测试用例挑选后的精确测试，具体如下： + +#### 冒烟测试 + + 冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，关注的是阻塞型缺陷。 + 门禁冒烟测试用例是选择功能测试用例中level 0的用例，主要保障版本可以正常开关机，主功能可用，覆盖多种设备形态。 + +#### 功能测试 + 功能测试是对产品的各功能模块进行验证，包含全量测试用例中level 0~5的用例。根据功能用例覆盖结果，测试产品是否达到各模块功能的质量要求。 + +#### API看护测试 + 根据代码仓与api头文件的关联关系，通过识别所提交的代码对代码仓头文件的修改，触发对应形态下自身代码仓的XTS用例的执行。 + +#### 优化：精准构建&精准测试 + 根据代码仓与设备形态之间的关联关系，通过识别所提交的代码对代码仓文件的修改，触发对应形态下所修改的代码仓的TDD level0用例的执行。 + +#### 代码门禁测试用例上线规则 + +##### 门禁问题提单 +1、门禁用例问题第一时间转给第一责任人，经分析后，由第一责任人继续往下分解 + + +##### 门禁响应时间 +1、TDD 用例上线门禁后，定位出用例导致的测试失败，需要两小时内闭环 + +##### 门禁用例下线 +1、用例问题两小时未解决的，需对应的责任田即时下线，不影响后续的门禁 + +##### 门禁用例上线 +1、用例重新上线或者新用例上线，需要责任人提供两天以上的稳定报告并知会我们（门禁看护人）， +2、流水线这边压测48小时后才可重新上线 \ No newline at end of file diff --git "a/sig/sig-QA/\347\211\210\346\234\254\350\264\250\351\207\217\350\246\201\346\261\202.md" "b/sig/sig-QA/\347\211\210\346\234\254\350\264\250\351\207\217\350\246\201\346\261\202.md" new file mode 100644 index 00000000..02754502 --- /dev/null +++ "b/sig/sig-QA/\347\211\210\346\234\254\350\264\250\351\207\217\350\246\201\346\261\202.md" @@ -0,0 +1,25 @@ +| 分类说明 | Canary版本 |Beta版本 |正式/LTS版本 | +| :------------ | :------------ | :------------ | :------------ | +|能力目标 |尝鲜版本，支持厂商联调开发和验证 |基本功能稳定、支持厂商联调开发和验证 |功能稳定，通过专项测试、支持三方厂商商业化集成 | +| 发布周期 |事件驱动 |2个月 |半年/年度 | +| 获取渠道 |每日构建流水线 | XXX | XXX | + + + +| 质量要求小类 |Canary版本 |Beta版本 |正式版/LTS版本| 说明 | +| :------------ | :------------ | :------------ | :------------ | :------------ | +| 社区门禁&流水线检查| 通过 |通过 |通过 | | +| 冒烟测试通过率 | >95% |100% | 100% | | +| XTS测试通过率| NA |100% |100% | | +| 测试用例通过率|NA |>95% |100% | | +| 测试用例自动化测试比例 |NA |牵引80%但不阻塞 |80% | | +| 安装部署 |NA |通过 |通过 | 基于社区开源板部署| +| 升级（社区公版）|NA |NA |通过 | 满足社区已发布的历史公版升级 | +| 性能 | NA |满足Beta基线 |满足基线 | 基于社区开发板的性能规格 | +| 功耗 | NA |满足Beta基线 |满足基线 | 基于社区开发板的功耗规格 | +| 安全 | NA |通过 |通过 | | +| 稳定性 |NA |满足Beta基线 |满足基线 | | +| ROM/RAM空间（基于社区开源板）|NA |满足Beta基线 |满足基线 | | +| 兼容性（基于开源板和社区PCS文档） |NA |满足基线 |满足基线 | 基于开源板和社区PCS文档 | +| 遗留问题 |无关键阻塞问题|无安全红线问题、无关键阻塞问题| 无安全红线问题、无关键阻塞问题 | | +| 资料 |通过（Canary配套）| 通过（Beta配套） | 通过（正式版）| | diff --git "a/sig/sig-QA/\351\233\206\346\210\220\346\265\213\350\257\225\344\273\213\347\273\215.md" "b/sig/sig-QA/\351\233\206\346\210\220\346\265\213\350\257\225\344\273\213\347\273\215.md" new file mode 100644 index 00000000..39849073 --- /dev/null +++ "b/sig/sig-QA/\351\233\206\346\210\220\346\265\213\350\257\225\344\273\213\347\273\215.md" @@ -0,0 +1,265 @@ +# **开源社区集成测试介绍** + +关键词： OpenHarmony + +摘 要：本文档描述了OpenHarmony开源社区版本集成测试能力，包括了在测试过程中的环境搭建、测试过程的评估依据，以及测试的工具支持等。 + +缩略语清单： 对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中文解释。 + +| Abbreviations 缩略语 | Full spelling 英文全名 | Chinese explanation 中文解释 | +| -------------------- | ---------------------- | ---------------------------- | +| | | | +| | | | + +# 1 集成测试对象及环境介绍 + +## 1.1 社区集成测试对象描述 + +- [ ] | **测试对象** | **测试范围及质量建议** | + | ------------ | :----------------------------------------------------------- | + | LTS版本 | •完成社区发布版本集成测试；
•完成社区版本典型特性测试，如分布式特性；
•基于开源社区公板完成社区整机性能、功耗、稳定性、安全测试；
•通过器件模拟完成保障硬件兼容性测试； | + | 主干版本 | •完成社区新增代码集成测试，并提供新增代码XTS测试套；
•部署社区集成自动化流水线支撑社区版本每日构建；
•向社区贡献XTS测试套，构建社区兼容性测试标准，完成开放接口兼容性测试；
•构建社区DFX测试服务化能力，含组件的性能、功耗、安全、可靠性，完成社区DFX测试； | + +## 1.2 集成测试环境介绍 + +### 1.2.1 单机集成测试环境 + +​ 开发板3516DV300 调试环境部署方案，采用网口+串口方式，通过串口对单板发送命令，通过网口传递文件。不同的通道负责的业务不同： + +​ 通道1：通过串口线对测试单板进行刷机，调试命令下发，结果回读等业务（4pin USB转串口） + +​ 通道2：执行脚本动态加载 + +​ 通道3：通过网口连接NFS服务器，tftp服务器或通过网口升级大包 + +详细的用例环境部署及测试用例执行操作，可以参考XTS子系统描述：https://gitee.com/openharmony/xts_acts#section465982318513 + +![TestBed](figures/TestBed.png) + +### 1.2.2 分布式集成测试环境 + + （后续补充） + +# 2 测试类型介绍 + +## 2.1 功能测试 + +功能测试主要目标是检查系统的能力，通过给定的用户需求（使用该能力的对象）和预期的输出来验证。检查系统多个组件间是否按照预期来协同工作，确保关键的系统、应用程序能够正常开展工作。OpenHarmony开展功能测试环境搭建可以参考本文档章节1.2集成测试环境介绍，用例开发及执行方法可以参考XTS子系统描述：https://gitee.com/openharmony/xts_acts#section465982318513 + +## 2.2 兼容性测试 + +兼容性是系统演进过程中的基本要求，不同版本的API能力必须满足向后兼容，以保证基于老版本开发的应用程序在可正常运行在新版本的系统之上，不兼容的API设计和变更可能会导致基于老版本开发的应用程序在新版本上无法运行，开发者需要重新修改代码进行适配，这在增加开发成本的同时也给应用使用者带来不好的体验，因此需要对系统提供的API能力进行兼容性测试。 + +- 兼容性原则
+ 兼容性要求系统提供的API能力在演进过程中满足以下三点原则： + 1、源码兼容：系统版本演进后，开发者基于已有源代码可正常编译通过。
2、二进制兼容：系统版本演进后，开发者已有程序不用重新编译可正常链接和运行。
3、契约兼容：也称语义兼容，指系统版本演进后，开发者原有程序行为不发生变化。
+ +- 兼容性测试方法
1、API元素源码检视
+ + 通过对版本间API元素的对比检查，从而发现违反以上3点原则的API兼容性问题（删除和变更），常见的API兼容性的源码检视规则举例如下：
+ （1）任何API元素删除，如方法删除、变量删除、静态常量删除、枚举元素删除、结构体删除等。
+ （2）降低API元素的可见性，例如方法可见范围从protected修改为private，或者public修改为protected。
+ （3）方法原型发生变化，例如返回值类型修改、入参顺序修改、入参类型发生变化或参数由可选参数变为必选参数等。
+ （4）成员final/static等属性发生变化，例如非final成员变成final成员，或者非static的成员变为static。
+ + 2、API测试套交叉测试
+ + 分别在新、旧版本执行XTS测试套，检查是否可正常运行并返回期望结果，如果运行结果与预期不一致，则需对结果进行分析，以确定是否由于新版本上API形式或行为变更导致兼容性问题。API测试套的交叉测试可作为API源码检视测试的补充，同时可发现源码检视较难发现的契约兼容性问题。
+ +## 2.3 性能测试 + + 性能测试是基于用户对于系统直观体验的测试方法，为了使整个系统体验流畅，确保系统响应及时性，画面显示连续性 ，制定了如下的性能评价维度。
+ +![1631072515103](figures\1631072515103.png)
+ +**静态KPI 测试**
+ +典型应用的典型场景度量（完成时延、响应时延、帧率），衡量单点场景的端到端的性能体验 。本测试项主要测试系统应用的基础性能，通过在应用界面点击、滑动等操作，使用高速相机录制视频，针对视频数帧得到对应的测试指标。
+ +主要覆盖的场景为：应用启动完成时延，退出完成时延，应用内切换完成时延，列表滑动响应时延，列表滑动帧率，特定场景（录制视频、视频播放）响应、完成时延以及帧率等。
+ +完成时延的测试方法：【起点】手指离开屏幕前一帧，【终点】主界面显示完全
+ +样例：启动设置完成时延：【起点】手指点击桌面上的设置图标离开屏幕的前一帧，【终点】设置界面显示完全
+ +响应时延的测试方法：【起点】手指离开屏幕前一帧，【终点】显示发生变化的第一帧。
+ +样例：启动设置响应时延：【起点】手指点击桌面上的设置图标离开屏幕的前一帧，【终点】桌面发生变化的第一帧
+ +帧率的测试方法：【起点】画面开始有变化刷新，【终点】画面结束刷新。根据视频的起始点的总帧数和总时长跨度来计算帧率
+ +样例：设置列表滑动帧率：【起点】打开设置列表，用手指快速在屏幕上滑动，并离开屏幕，【终点】列表滑动完全停止并结束刷新

+ +小型系统静态KPI参考
+ +| 序号 | 场景 | 子场景 | 场景详细描述 | 指标 | 单位 | 指标值 | +| ---- | -------- | ------------ | ------------------------------------------------------------ | ---- | ---- | ------ | +| 1 | 设备开机 | 启动时间 | 计时起点：设备在关机状态下点击开机按钮后（如果无外部可标识点，需要增加打点日志）
计时结束点：进入系统（输出摄像头画面）
测试方法：数帧 | 时延 | ms | 1000 | +| 2 | 重启组网 | 重启组网时间 | 计时起点：已经组网的情况下，设备重启到设备重新加入网络的时延，起点与启动时间相同
计时结束点：手机上智慧生活设备状态更新(上线)
测试方法：数帧 | 时延 | ms | 3000 | + +
+ +**内存基线测试**
+ +内存作为整个系统的运行的核心指标。由于整个系统的物理内存是有限的，每个进程内存的增长对于整系统以及体验来讲是敏感的，需要严格控制。特制定开机内存、常驻内存、动态内存、场景内存等约束，保障整机系统资源的供给。
+ +![1631075360097](figures/1631075360097.png)
+ +开机内存是指系统启动到桌面界面后，开机静置5分钟，进程（或组件）的内存使用值。
+ +常驻内存是指应用运行结束退至后台、静置5分钟，进程（或组件）的内存使用值，申请未释放的CMA、DMA内存也视为常驻占用。
+ +动态内存是指应用在后台运行时，进程（或组件）的内存峰值。
+ +场景内存是指应用在前台运行时，相关依赖服务（前台、后台）的运行内存总量峰值。
+ +小型系统开机、常驻以及动态内存参考：
+ +| 进程名 | 3518 RAM基线(KB) | 3516 RAM基线(KB) | +| -------------- | ---------------- | ---------------- | +| sensor_service | | 932 | +| wms_server | | 6820 | +| media_service | 1192 | 1212 | +| appspawn | 952 | 3192 | +| bundle_daemon | 912 | 972 | +| foundation | 1748 | 3744 | +| apphilogcat | 636 | 636 | +| init | 748 | 752 | + +小型系统场景内存参考：
+ +| 产品 | 内核类型 | 场景 | 验收方法 | 指标 | 单位 | +| ---- | -------- | -------- | ------------------------------------------------------------ | ----- | ---- | +| 3516 | LiteOS | 相机预览 | 1. 开发板启动之后，点击桌面Camera图标，进入Camera
2. 等待1分钟稳定之后，通过VMM命令每隔10秒采集一次camera进程数据，共采集十组，以最大值作为测试值 | 11600 | KB | +| 3516 | LiteOS | 录像场景 | 1. 进入相机后点击录像开始进行录像，等待1分钟后，每隔10秒采集一次Camera进程数据，共采集十组，以最大值作为测试值 | 24532 | KB | +| 3516 | LiteOS | 播放场景 | 1. 将测试test.mp4文件放入到测试目录
2. 从相机直接进入图库
3. 播放test.mp4文件，等待1分钟后，每隔10秒采集一次Camera进程数据，共采集十组，以最大值作为测试值 | 28636 | KB | +| 3518 | LiteOS | 录像场景 | 1. 系统开机启动稳定后
2. 执行测试程序直接进行录像，等待1分钟后，每隔10秒采集一次Camera进程数据，共采集十组，以最大值作为测试值 | 16408 | KB | + +## 2.4 功耗测试 + +功耗就是消耗的能量，即功率的损耗，对应用来说，即应用工作时所消耗的电量（耗电），而对整机来说即在设备使用（包括待机、应用）时所消耗的电量。 随着移动互联网的快速发展，设备的功能越来越强大。日常使用中发现，电量很大的制约设备的使用时长，尤其是无源设备。有效的进行功耗测试，支撑OpenHarmony功耗质量客观评估，并能牵引整机功耗持续优化与续航提升 。 制定了待机功耗、场景功耗测试等维度。
+ +![1631081115273](figures/1631081115273.png)
+ +**待机功耗测试**
+ +在灭屏情况下，系统进入待机后的功耗表现。重点关注平均电流及异常（唤醒、不冷冻、持锁等）情况。
+ +根据当前系统的能力制定测试用例，对不同的系统功能（如蓝牙、WIFI等）开关单独或组合开启情况下进行系统待机电流测试。测试时间20分钟，重点关注平均电流和异常波形 。计算方法：耗电量mAh = 平均电流mA*时间h 。
+ +小型系统待机功耗参考：
+ +| 业务场景 | 结温（温度节点） | 总功耗(mW) | +| -------- | ---------------- | ---------- | +| 待机 | 40℃ | 565.32 | + +![1631082676359](figures/1631082676359.png)
**场景功耗测试**
+ +设备在亮屏的情况下，测试典型应用场景下的功耗表现。每个应用在各个固定场景下存在固定的软件行为，软件的所有行为最终都会有一定的功耗。应用场景的类型主要覆盖系统应用、三方应用及少部分热场景。典型的场景为视频播放、图片浏览等。测试时建议使用程控电源。
+ +小型系统场景功耗参考：
+ +| 业务场景 | 结温（温度节点） | 总功耗(mW) | +| ---------- | ---------------- | ---------- | +| 行车记录仪 | 40℃ | 655.91 | +| 电子猫眼 | 40℃ | 620.92 | + +举例：以设置浏览场景功耗为例， + +1、设备保持亮屏，点击进入设置，等待2s。 + +2、下滑5次，1次2s，滑动范围从屏幕1/4到3/4，匀速滑动。 + +3、停止测试，记录测试期间电流。 + +![1631082968281](figures\1631082968281.png)

+ +## 2.5 可靠性测试 + + 可靠性是系统基础体验的核心要素，为了提升整个系统的体验，需要及时发现系统的可靠性方面的问题，并牵引产品、系统不断的改进以创造良好的基础体验，特制定了以下几个维度的可靠性测试活动。
+ +- 应用界面随机操作的方式开展随机压力测试
+ +从UI界面作为入口进行压力测试，以发现应用或者系统导致的异常，本测试项是通过在应用界面进行随机的点击、滑动、界面切换、应用前后台切换等操作来发现应用或系统导致的应用Crash、卡死类的异常，具体操作如下：
+从桌面打开应用，随机打开每一个应用界面，并且在相应的界面上随机操作界面上所有的控件，操作完成当前页面后，返回上一级页面后再进入另外一个页面进行随机，并且在操作的过程中，随机进行返回桌面、切换至其它应用界面的操作，并且重复上述步骤，直至测试时长达到指定的要求。 + +通用测试标准：准备10台机器，每台运行时间至少大于6小时，10台机器中7台无故障运行大于等于6小时。 + +- 系统反复开关机压力测试
+ +系统/设备在开机的过程中如果发生了无法开机的问题，或者能够开机，但开机之后功能不可用的问题，会对用户带来比较大的影响，本测试项是通过触发反复重启，并且在重启后验证系统的基本功能（例如应用打开的功能），以验证系统是否能正常开机或者在开机后系统的功能是否可用。
+具体操作及指导，可以参考：https://gitee.com/openharmony/xts_tools/tree/master/reliability#section129654513264
+ +通用测试标准：总共测试50000次，无不开机问题或开机后功能不可用的问题，可通过增加机器数量来缩短测试时间。 + +- Native层压力测试
+ +系统/应用在调用Native层的处理时，如果出现了Crash或卡死类的异常时，会导致对应的功能不可用，会对用户体验带来影响，本测试是通过反复调用acts测试用例，对acts测试用例所对应模块的功能进行压力测试，以验证对应模块的模块的可靠性。
具体操作及指导，可以参考：https://gitee.com/openharmony/xts_tools/tree/master/reliability#native%E7%9A%84%E6%B5%8B%E8%AF%95%E7%94%A8%E4%BE%8B%E8%BF%9B%E8%A1%8C%E5%8F%8D%E5%A4%8D%E5%8E%8B%E5%8A%9B%E6%B5%8B%E8%AF%95%E6%89%A7%E8%A1%8C%E6%AD%A5%E9%AA%A4 + +通用测试标准：准备20台机器运行，总共运行2000小时（与下面js开发框架压测试项一起计算），平均无故障运行时间大于等于1000小时。 + +- js开发框架压力测试
+ +应用在调用js的处理时，如果在处理时发生了出现了Crash或卡死类的异常时，会导致对应的功能不可用，会对用户体验带来影响，本测试是通过反复调用js层提供的API接口来对指定模块进行压力测试，以验证通过API接口反复调用时的可靠性。
具体操作及指导，可以参考：https://gitee.com/openharmony/xts_tools/tree/master/reliability#js%E7%9A%84%E6%B5%8B%E8%AF%95%E7%94%A8%E4%BE%8B%E8%BF%9B%E8%A1%8C%E5%8F%8D%E5%A4%8D%E5%8E%8B%E5%8A%9B%E6%B5%8B%E8%AF%95%E6%89%A7%E8%A1%8C%E6%AD%A5%E9%AA%A4 + +通用测试标准：准备20台机器运行，总共运行2000小时（与上面的Native层压力测试项一起计算），平均无故障运行时间大于等于1000小时。 + +## 2.6 隐私保护及安全测试 + +OpenHamony开源社区需要遵守相应的隐私保护要求、安全规范和编码规范，各项要求及规范的详细内容请参考： + +隐私保护要求：https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/security/security-privacy-protection.md +​ 安全指南：https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/security/security-guidelines-overall.md +​ 安全编码规范：https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md + +隐私保护的主要目的是检查系统提供的涉及个人数据的功能是否满足隐私保护要求，主要涉及的范围包含：系统对个人数据收集、共享需要获取用户同意，数据采集、传输、处理、存储提供了有效保护措施防止个数据泄露，隐私声明明确描述了对个人数据收集范围、存储时长、处理方式等，个人数据收集满足最小化原则，涉及个人数据处理的场景，为数据主体提供了查询、更新、删除其数据等能力。详细的隐私保护规范要求及验证可以参考附表《OpenHarmony开源社区安全隐私设计规范基线用例》中隐私保护相关内容。 + + 安全测试则是验证系统符合安全需求定义和产品质量标准。安全测试检查内容主要包含： +​ 1、系统中组件公开漏洞检查，可以登录https://www.cnvd.org.cn/通过组件名搜索验证。 +​ 2、编码规范性检查，可以使用codecheck工具扫描。 +​ 3、系统不提供不必要的访问通道，使用满足安全标准会话标识及鉴权方式，使用业界认可的安全加密方式，对关键资产提供有效的保护措施，系统具备攻击防护能力，能识别和记录攻击等。详细的测试内容可参考附表《OpenHarmony开源社区安全隐私设计规范基线用例》中相关内容。 +​ 4、系统安全、权限配置检测及注入攻击。 + +附表：OpenHarmony开源社区安全隐私设计规范基线用例： + +| 维度(title) | 编号 | 要求 | 说明(要求的目的) | 测试策略/方法 | +| -------------------- | ---- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| 1.访问通道控制 | 1-1 | 为了防止系统和资源被非法访问，除非标准协议约定，所有能对系统进行管理的接口，应具备接入认证机制并缺省启用。 | 为减少系统攻击面，对于可对系统进行管理(包括配置、升级、调试等)的接口必须要启用认证机制，避免未授权的访问。 | 与开发人员访谈，梳理所有对外接口列表，沟通确认每个接口都有高强度的认证机制。 | +| | 1-2 | 只保留运行维护所必须的对外通信连接，关闭不需要连接、端口。 | 关闭不必要的通信端口，可大大降低安全威胁，是系统安全防护的基础手段。 | 遍历所有涉及联网的功能，在hdc shell下执行 busybox netstat -a -p -t -u -l -w -e，记录端口状态。所有扫描出的端口都必须是系统运行和维护必须的，给出实际使用场景。 | +| 2.应用安全 | 2-1 | 对于每一个需要授权访问的请求都需核实请求方的会话标识是否合法、请求方是否被授权执行此操作。 | 避免越权访问。 | 梳理所有授权访问列表，通过伪造会话标识进行请求，确认请求是否成功。 | +| | 2-2 | 认证处理过程在客户端实现是不可靠的，可被轻易绕过，因此对用户的最终认证处理过程必须放到服务端进行。 | 避免越权访问。 | 进行认证请求时，断开到服务器的链接，查看认证是否成功。 | +| 3.加密 | 3-1 | 应该使用经过验证的、安全的、公开的加密算法。 | 算法的安全性不在于算法本身的机密性。 | 检查使用的加密算法是否为安全指南中提供的加密算法。 | +| | 3-2 | 除标准协议外，避免使用差错控制编码（如奇偶校验、CRC）实现完整性校验。 | | 检查完整性保护是否使用安全指南中提供的加密算法。 | +| | 3-3 | 密码算法中使用到的随机数必须是密码学意义上的安全随机数。 | 使用了不安全的随机数，容易导致密码算法的强度降低甚至算法的失效。 | 密码算法中使用到的随机数必须是密码学意义上的安全随机数函数，或社区密码学应用技术（密码学专家组）认可的安全随机数函数。例如：
1) OpenSSL的RAND_bytes或RAND_priv_bytes；
2) OpenSSL FIPS模块中实现的DRBG；
3) JDK的java.security.SecureRandom；
4）类Unix平台的/dev/random文件；
5）Windows平台的CryptGenRandom。 | +| | 3-4 | 默认使用安全的密码算法，关闭或者禁用不安全的密码算法。在选择密码算法库时，应使用通过认证的或业界开源公认的或经评估认可的密码算法库 | 随着密码技术的发展以及计算能力的提升，一些密码算法变得不再安全，使用不安全的密码算法，有可能为用户的数据带来风险。同时非专业人员实现的密码算法，在技术上未经业界分析验证，有可能存在未知的缺陷，因此应使用通过认证的或业界开源公认的或经评估认可的密码算法库。 | 相关领域安全测试根据实际特性进行用例设计或者审核代码设计及实现，确认使用的密码算法。 | +| | 3-5 | 密钥材料及密钥组件在保存时须限定其权限（如权限600或400）。 | | 查询密钥材料的文本文件的权限（保存位置可以和开发者确认），检查其是否遵循了权限最小化原则，如权限配置为400，或根据设计规格，确保other组无权限。 | +| 4.敏感数据保护 | 4-1 | 口令等认证凭据应该加密存储并提供访问控制。 | | 获取应用中的密钥材料及密钥组件（保存位置可以和开发确认），检查其在本地保存时，是否加密保存；检查其是否遵循了权限最小化原则，如权限配置为400，或根据设计规格，确保other组无权限。 | +| | 4-2 | 认证凭据不需要还原的场景，应使用PBKDF2等不可逆的算法加密，对于性能敏感且安全性要求不高的场景可使用HMAC（认证凭据，盐值）（注：认证凭据、盐值位置可以互换）。
1、认证凭据使用PBKDF2算法计算口令单向哈希时，迭代次数最低1000次。
2、盐值Salt为密码学意义上的安全随机数，由系统随机生成，盐值salt至少16字节，并按用户区分。
3、避免使用HASH(用户名口令)、HMAC(用户名，口令)、HASH(口令 XOR salt)。 | | 审视代码，所有敏感加密场景，加密方法是否满足。 | +| | 4-3 | 敏感数据如需通过非信任网络传输，应支持安全传输通道或者将数据加密后再传输的机制。 | | 在wifi场景和数据业务场景下，遍历所有联网场景，并使用tcpdump抓取IP log，同时进入hdc shell，输入：busybox netstat -a -p -t -u -l -w -e，记下这个应用对应的服务器IP地址；使用wireshark打开IPLOG，在筛选框中筛选对应服务器IP（只筛IP可能存在漏测，建议先全量看报文，发现问题再通过IP定位是不是自己业务的），分析IPlog是否包含了明文敏感数据，或base64编码后的敏感数据。 | +| | 4-4 | 对敏感数据的访问，根据风险采取适当的安全机制（如认证、授权或加密等）。包含敏感数据的文件（例如，包含敏感数据的配置文件、日志文件、个人敏感数据文件、用户口令文件、密钥文件、证书文件、驱动文件、备份文件）和其目录的权限设置应只允许文件的属主或需要访问该文件/目录的用户拥有相应的权限。 | | 1、审核代码，是否有对敏感数据采用了安全的加密算法进行加密保存。
2、审核代码，是否对敏感数据采用了安全的加密算法加密传输，或采用通用的HTTPS传输
3、检查保存敏感数据的文件（保存位置可以和开发者确认）是否有设置访问权限，other组权限以及群组权限全为空
4、检测gps驱动节点权限，要求为crw-rw----或crw------，测试命令如下：1）hdc shell; 2）cd /dev; 3) ls -lR \| grep gps
5、检测sensorhub驱动节点权限，要求为crw-rw----，测试命令如下：1）hdc shell; 2）cd /dev; 3) ls -lR \| grep sensorhub | +| | 4-5 | 日志、调试信息、错误提示等中应过滤或者屏蔽认证凭据。 | | 遍历功能，触发异常分支场景，检查敏感信息错误提示、调试信息，不能存在明文的认证凭据（口令/私钥/预共享密钥）或与开发者审视代码实现。 | +| 5.系统管理和维护安全 | 5-1 | 对于系统自身操作维护类的接口的登录认证场景，应综合考虑实际业务场景及风险，采取下述一种或几种保护措施，实现口令防暴力破解机制：
1）锁定帐号；
2）锁定IP；
3）登录延迟；
4）验证码；" | | 有密码登录功能时涉及，其它场景无需测试。
1、口令安全检查
1）检查多次输入错误密码后的反应。
2）检查密码显示和尝试复制口令框里的密码。
3）检查是否支持修改口令
4）检查操作界面中的口令不能明文显示
5）如果在设备里存储了口令密文，检查访问控制权限。
2、所有需要账号密码输入的场景，尝试截屏和录屏，要求截屏和录屏均不会泄露用户密码
3、如果在设备里存储了口令密文，检查对应文件的访问控制权限，不能存在other组权限。 | +| | 5-2 | 对于系统自身操作维护类的口令，图形界面缺省不明文显示用户键入的所有口令。 | | 检查图形界面输入的口令/密码是否是显示为明文，默认不能明文显示。 | +| | 5-3 | 口令输入框不能支持口令拷出。 | | 选择口令输入框中的口令，右键/长按/选中等操作后无复制按钮，口令无法拷出 | +| | 5-4 | 应使用合适的安全协议，不安全协议应默认关闭。 | 安全协议举例：
SSHv2/TLS1.2/TLS1.3/IPSec/SFTP/SNMPv3等协议，及其业界最新安全版本。对于流密码算法，建议使用AES的OFB和CTR模式或chacha20流加密算法替换RC4算法。
不安全协议举例：
TFTP、FTP、Telnet、SSL2.0、SSL3.0、TLS1.0、TLS1.1、SNMP v1/v2和SSHv1.x。
| 遍历所有涉及联网的功能，使用netstat命令检查当前状态是否有不安全的协议端口：
不安全的协议端口如下：
Telnet：23
FTP：20/21
TFTP：69
snmp：161/162
SSH：22
即必须默认关闭不安全的协议：Telnet、FTP、SSH v1.x、tftp、SNMP v1/v2c，未使用这些协议。 | +| | 5-5 | 基于权限最小化原则，系统新建账号默认不授予任何权限，或者默认只指派最小权限（如：只读权限）的角色。 | 保证当授权机制出现问题或授权机制被绕过时非法用户获得的权限也是最少的。 | 1、根据产品功能新建一个可用的账号，如建立时有权限配置，则默认不进行权限配置建立新账号；
2、检查建立的账号实际权限是否为设计要求的最小权限，例如新创建的账号无法删除之前账号及账号数据。 | +| 6.隐私保护 | 6-1 | 收集或使用个人数据前以及将该个人数据发送给第三方之前，应明确提示用户，并获得用户的同意。 | 增加透明性及用户控制能力，满足GDPR等法律法规要求。 | 1、启动后收集个人数据需要用户同意
2、披露给三方需获取用户选择和同意权利 | +| | 6-2 | 正常业务需要的情况下，采集、处理、存储个人数据，应根据实际安全风险提供必要的安全保护机制（如认证、权限控制、日志记录等），以防止个人数据被泄漏、丢失、破坏。 | 防止个人数据被泄漏、丢失、破坏。 | 1、存储数据文件的权限检查，不能存在other组权限
2、hdc logcat抓取日志，检查敏感信息是否存在个人数据。 | +| | 6-3 | 对产品涉及用户隐私的功能进行描述：该功能处理用户个人数据的目的、范围、处理方式、时限。要求使用该功能时遵从当地适用的法律法规。 | 加透明性，满足GDPR等法律法规要求。 | 1、检查input设备的other组可读可写权限检查：ls -l /dev/input， 要求记录中，本领域相关的input设备节点的other组无任何权限
2、确认other组有写权限的目录是否存在安全风险：1）hdc shell； 2）find -perm -o=w -type d -exec ls -ld {} \; > /data/otherw.txt；3）cat /data/otherw.txt检查此txt文件中内容； 要求查询结果中无本领域相关目录，如有需要开发说明加other组权限的必要性，且保证该目录下未运行root的可执行脚本或程序，可执行脚本或脚本也不会被root权限的其它进程或可执行程序调用。
3、确认other组有写权限的文件是否存在安全风险：1）hdc shell；2）find -perm -o=w \( -type f -o -type c -o -type b -o -type s -type p \) -exec ls -l {} \; > /data/other.txt；3）cat /data/other.txt检查此txt文件中内容； 要求查询结果中无本领域相关目录，如有需要开发说明加other组权限的必要性。
4、确认未经授权的SUID与SGID是否可执行：1）hdc shell；2） find \( -perm -04000 -o -perm -02000 \) -exec ls -ld {} \; > /data/finds.txt；3）cat /data/finds.txt检查此txt文件中内容；要求文件中只能有run-as,ping,netcfg,procrank,procmem,pcscd,以qmux_为前缀的项。
5、禁止other组可读文件存在个人数据
6、存储个人生物识别信息采用技术措施处理后再进行存储。 | +| | 6-4 | 对于所涉及的个人数据，应支持在呈现界面上（如显示界面、文件存储/导出等）进行过滤或匿名化或假名化。 | 降低个人隐私泄露的风险。 | 同6-3 | +| | 6-5 | 为避免位置追踪，除了有明确的需求之外，不能出于故障定位等维护目的进行用户精确位置信息定位。 | 精确位置信息非常敏感，故障定位无需精确定位。 | 非必要，不提供涉及采集位置数据的能力：
1、检查logcat打印日志是否有用户精确位置
2、如有采集，需要开发者及组织提供采集的理由及采集精确位置涉及的需求来源。 | +| | 6-6 | 收集个人数据需基于使用目的所必需，满足最小化原则。用于问题定位的日志中记录个人数据遵循最小化原则。 | 用于问题定位的日志如果出现个人数据，会引起用户的质疑。应避免打印个人数据，如果必须打印个人数据（如调试目的），必须对个人数据进行匿名化处理。 | 1、使用敏感信息检查工具检查系统及文件中的个人数据或敏感数据或内部信息
2、设备标识符的采集应该满足最小化原则 | +| | 6-7 | 涉及个人数据处理的场景，需要提供相关机制，确保数据主体能够查询、更新以及删除所有数据主体的个人数据。 | 确保数据主体的权利。 | 在个人数据录入页面，录入个人数据，保存成功；查询、修改和删除第一步录入的用户个人信息，可以正常查询、修改和删除个人数据。 | + + + +​ + +# 3 测试工具介绍 + +## 3.1 XTS测试套环境链接 + +https://gitee.com/openharmony/xts_acts#section465982318513 + + + -- Gitee From 6b8ba9074010bec610ab962e38baa0c91abc7917 Mon Sep 17 00:00:00 2001 From: huazi Date: Thu, 16 Sep 2021 01:49:19 +0000 Subject: [PATCH 2/2] =?UTF-8?q?update=20sig/sig-QA/issue=EF=BC=88=E9=9C=80?= =?UTF-8?q?=E6=B1=82=E7=B1=BB=EF=BC=89=E5=A4=84=E7=90=86=E6=8C=87=E5=AF=BC?= =?UTF-8?q?.md.=20=E5=88=B7=E6=96=B0=E6=A0=BC=E5=BC=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...7\274\211\345\244\204\347\220\206\346\214\207\345\257\274.md" | 1 + 1 file changed, 1 insertion(+) diff --git "a/sig/sig-QA/issue\357\274\210\351\234\200\346\261\202\347\261\273\357\274\211\345\244\204\347\220\206\346\214\207\345\257\274.md" "b/sig/sig-QA/issue\357\274\210\351\234\200\346\261\202\347\261\273\357\274\211\345\244\204\347\220\206\346\214\207\345\257\274.md" index 5465b592..f4161d20 100644 --- "a/sig/sig-QA/issue\357\274\210\351\234\200\346\261\202\347\261\273\357\274\211\345\244\204\347\220\206\346\214\207\345\257\274.md" +++ "b/sig/sig-QA/issue\357\274\210\351\234\200\346\261\202\347\261\273\357\274\211\345\244\204\347\220\206\346\214\207\345\257\274.md" @@ -25,6 +25,7 @@ ### 需求类issue各字段的要求 - issue状态字段是跟踪管理issue重要的信息，需要在处理issue环节及时更新 + | 状态字段 | 负责人 | 描述 | | ------------ | ------------ | ------------ | | 待办 | 提交者 | 任何开发者都可以提交需求到社区，初始状态为待办 | -- Gitee