鸿蒙测试计划

序

华为的鸿蒙系统手机操作系统已经发布好几个月了。作为国产操作系统，它寄予了我们深深的希望。手机、平板、智能手表等消费电子产品。当然是鸿蒙系统系统大会的主角，智能汽车作为华为冉冉的新业务领域，也被纳入系统生态，也引起了业界的广泛关注。

作为鸿蒙系统的新系统，难免会有很多问题，汽车领域对代码编码的要求极其严格。因此，本文将使用汽车行业主流的静态分析工具，对鸿蒙系统系统代码与汽车行业通用编码标准的符合性进行分析和测试。考虑到标准鸿蒙系统系统中代码量巨大，本文仅以OpenHarmony_1.0.1_release分支中的Hi3861 WLAN模块代码为例，对部分代码进行静态测试。

编译鸿蒙系统系统

Ubuntu编译环境准备

系统要求:Ubuntu16.04及以上64位系统版本。

本文使用的是虚拟机内置的Ubuntu 18.0系统。编译环境的构建分为以下步骤:

获取源代码

安装和配置Python

Gn安装

安装忍者

安装LLVM

安装hb

详细配置步骤请移至鸿蒙系统开源项目教程指南，本文不再详细介绍。按照文档一步一步来，就可以获得鸿蒙系统轻量级系统的源代码，完成编译环境的构建。

请注意，我们目前还不能编译鸿蒙系统系统，需要完成后续开发板环境才能正常编译鸿蒙系统系统。

Hi3861开发板环境建设

为了在源代码中正常编译wifiiot_hispark_pegasus项目，我们需要在刚刚设置好的Ubuntu编译环境中构建Hi3861开发板环境。如果需要编译其他项目，需要搭建相应的开发板环境。

请转到安装Hi3861开发板环境，了解详细的构建步骤。

编译鸿蒙系统系统

设置好Hi3861开发环境后，我们就可以正常在源代码中编译wifiiot_hispark_pegasus项目了。具体步骤如下:

转到下载的源代码的根目录，执行hb set，然后会提示输入源代码的根目录。输入当前路径，然后按Enter键。选择wifiiot_hispark_pegasus项目完成编译准备。

执行hb build编译wifiiot_hispark_pegasus项目。如果编译结果如下图所示，说明您已经成功编译了该项目。

wifiiot_hispark_pegasus项目编译成功后，就可以进行后续的静态分析了。

鸿蒙系统系统静态分析

鸿蒙系统系统编译环境配置

利用编译环境配置文件生成工具，我们可以很容易地生成鸿蒙系统编译环境的配置文件。由于wifiiot_hispark_pegasus项目是C项目，所以只需要配置C编译器的环境即可。考虑到鸿蒙系统使用的是C99标准，在生成配置文件时需要添加-std=C99，如下图所示:

然后在静态测试工具中导入配置文件。

静态分析执行

为了便于后续将鸿蒙系统的静态分析流程部署到持续集成平台，本文通过命令行演示静态分析操作。具体步骤如下:

使用以下命令创建QAC项目:

QA CLI admin-qaf-project-config-qaf-project。-CCT "/首页/周/。config/Perforce/Helix-QAC-2021.1/config/CCT/GNU _ GCC-riscv 32-unknown-elf-GCC _ 7 . 3 . 0-riscv 32-unknown-elf-C-c99 . CCT "-ACF "/home/周/。config/Perforce/Helix-QAC-2021.1/config/ACF/hmos . ACF "-RCF "/home/周/。QAC-2021.1/config/rcf/HMOS.rcf "

为了全面了解鸿蒙系统系统的代码质量，本文在QAC项目的分析配置文件HMOS.acf中增加了MISRA C 2012符合性模块、CERT C符合性模块和CWE C符合性模块。

MISC 2012:为安全关键系统的开发提供编码标准，广泛应用于汽车软件开发。

CERT:信息安全编码标准，它可以确保您的软件免受潜在的软件安全漏洞的影响。

CWE C:常见漏洞的枚举列表确定了软件和硬件中的软件安全漏洞。

过滤鸿蒙系统中包含的第三方源代码，命令如下:

QA CLI PP rops-P .-sync-setting FILE _ FILTER-set "/home/Zhou/Downloads/open harmony/third _ party "

通过这个命令，我们可以从QAC项目中过滤掉鸿蒙系统项目中包含的第三方源代码，这样就可以通过QAC的分析结果更好的衡量鸿蒙系统源代码的代码质量。

将wifiiot_hispark_pegasus项目的源代码加载到QAC项目中。具体命令如下:

QA CLI sync-P .-t MonITOR " CD/home/Zhou/Downloads/open harmony HB clean HB build "

该命令通过监控wifiiot_hispark_pegasus项目的编译过程，自动将编译过程中调用的源文件和头文件添加到QAC项目中。

进行QAC分析，具体命令如下:

qacli analyze -P . -cf

生成合规报告:

qacli报告

将分析结果上传到QAC的网页上，以便查看。该命令如下所示:

qacli上传-P .-qav-上传-上传-项目HMOS -快照-名称v1.0 -上传-源ALL-U https://192 . 168 . 9 . 126:8081/-用户名管理-密码管理

静态分析结果的分析

模块wifiiot_hispark_pegasus的总体符合性如下:

QAC总共报告了107，618条诊断消息，总共有290，264条违规，其中302条违规，216条符合性规则。由于模块的文档达标率高达94.19%，而项目的达标率仅为41.70%，可见违规现象集中在少数源文件中。

证书合规性

wifi _ hispark _ pegasus源代码一般违反CERT的情况如下:

图中的图例是CERT C的规则组的缩写，具体如下:

02_DCL声明和初始化

10 _环境环境

11 _信号信号

04_INT整数

09_FIO输入输出

14_CON并发08_MEM内存管理

07_STR字符和字符串

03 _表达式

违反的前10条CERT C规则如下:

违反CERT C规则的分布如下:

图中的正方形区域表示代码量，颜色的深浅表示违反CERT的严重程度。从上图可以看出，CERT C的违规主要集中在以下源文件中:

CMS _ task _ func _ test.c:有3182行代码，违反了CERT C的1951条诊断消息；

CMS _ task _ pri _ func _ test.c有1635行代码，违反了CERT C的1144条诊断消息；

Tcp_session_manager.c:有1230行代码，违反了CERT C的912条诊断消息；

Huks_adapter.c:有1705行代码违反了CERT C的862条诊断消息；

Coap_adapter.c:有638行代码违反了CERT C的579条诊断消息。

圈复杂度最高的10个函数如下:

下面，我们将摘录一些违反规则的代码进行分析说明:

1.DCL37不声明或定义保留标识符。

规则解释:

根据C标准7.1.3 [ISO/IEC 9899:2011]，

所有以下划线和大写字母或其他下划线开头的标识符总是保留使用。

所有以下划线开头的标识符总是被保留，并用作通用名称空和标签名称空之间的文件范围的标识符。

违规示例:

/HMOS/base/hiviewdfx/hievent _ lite/frameworks/hiview _ event . c，L28:

#定义事件值最大值16

此处的代码不兼容，因为宏“EVENT_VALUE_MAX_NUM”将来可能会与“”中的宏冲突。

Iso: c90语言[7.13]，iso: c99语言[7.26]

2.INT02了解整数转换规则。

规则解释:

转换可以作为强制转换的结果显式发生，也可以根据操作的要求隐式发生。虽然正确执行程序通常需要转换，但它们也可能导致数据丢失或误解。将操作数值转换为兼容类型不会导致值或表示形式发生变化。

C整数转换规则定义了C编译器如何处理转换。这些规则包括整数提升、整数转换级别和通用算术转换。该规则的目的是确保转换会产生相同的值，并且这些值会将其余计算中的意外情况降至最低。Prestandard C通常倾向于保留类型的签名。

违规示例:

/HMOS/base/hiviewdfx/hievent _ lite/frameworks/hi view _ EVENT . c，L57:e . common . mark = EVENT _ INFO _ HEAD；

此处的代码不兼容，因为“本质上有符号”类型的整型常量在赋值期间被转换为“无符号”类型。

3.DCL23保证相互可见标识符是唯一的。

规则解释:

根据C标准[ISO/IEC 9899:2011]第6.2.7条，

引用同一对象或函数的所有声明都应该具有兼容的类型；否则，行为是未定义的。

此外，根据6.4.2.1的说法，

任何重要字符中的不同标识符都是不同的标识符。如果两个标识符仅在不重要的字符上有所不同，则该行为是未定义的。

违规示例:

/HMOS/base/hiviewdfx/hievent _ lite/interfaces/native/innerkits/hiview _ event . h，L85:

void HiEventPutInteger

这里的代码是不兼容的，因为外部标识符匹配其他外部标识符的前6个字符——程序不符合严格的ISO:C90。

参考:ISO:c90语言[6.1.2]，安全问题

4.DCL00常量限定不可变对象。

规则解释:

不可变对象应该用const限定。使用const限制来增强对象的不变性有助于确保应用程序的正确性和安全性。例如，ISO/IEC TR 24772建议将参数标记为常数，以避免无意中修改函数参数[ISO/IEC TR 24772]。STR 05-C .在引用字符串文字时使用指向const的指针描述了这个提议的特殊情况。

违规示例:

/HMOS/base/hiviewdfx/hievent _ lite/frameworks/hiview _ event . c，L50:

void HiEventPrintf

这里的代码不兼容，因为形参“type”永远不会被修改，所以可以用“const”限定符声明它。

参考:，ISO:c90语言[6.5.3]，安全问题

5.MEM34-C .仅动态分配空闲内存。

规则解释:

c标准[ISO/IEC 9899: 2011]的附录J指出，以下行为未定义:

或者freerealloc函数的指针参数与内存管理函数之前返回的指针不匹配，或者空已经通过调用free或realloc释放。

释放非动态分配的内存可能会导致堆栈损坏和其他严重错误。不要对非标准内存分配函数(如malloc、calloc、realloc或aligned_alloc)返回的指针调用free。

违规示例:

/hmos/base/security/device auth/frameworks/device auth _ lite/source/struct/parse data . c，第76行:

免费有效载荷)；

这里的代码是不兼容的，因为是非动态内存palyload变量的释放，有效载荷定义在/hmos/base/security/device auth/frameworks/device auth _ lite/source/struct/parse data . c，L53:

payload = json _ to _ string

由于篇幅的限制，这里没有展示MISRA C和CWE C的符合性。

结束语

通过对鸿蒙系统系统部分代码的静态测试，试图了解鸿蒙系统系统对汽车行业常用代码编程规范的遵从性。我们希望鸿蒙系统在未来通过不断的迭代开发，提高代码合规性，进一步提高代码质量，成为优秀的车载操作系统。