【鸿蒙南向开发】—— TEST测试：OpenHarmony unittest单元测试的编写

📚往期学习笔录📰：

📰 鸿蒙（OpenHarmony）南向开发保姆级知识点汇总~
📰 鸿蒙应用开发与鸿蒙系统开发哪个更有前景？
📰 嵌入式开发适不适合做鸿蒙南向开发？看完这篇你就了解了~
📰 鸿蒙岗位需求突增！移动端、PC端、IoT到底该怎么选？
📰 记录一场鸿蒙开发岗位面试经历~
📰 持续更新中……

背景

程序开发与单元测试二者密不可分，是每个开发人员的基本业务。当功能性代码开发完成后，要自行测试其是否满足设计预期，如果不满足就要回去完善代码，满足则可以提交功能代码及测试用例。

测试用例的另一个重要作用就是阅读者了解代码的“一扇窗”，因为测试用例是程序的入口。

测试用例要覆盖每个接口所有分支，即保证每个待测函数的功能是正常的。

多个接口序列化功能需要提供完整序列化组合测试用例，例如：Open(), DoSomething(), Close()。

以下用 msdp 组件 device_status 子系统下待测 utility.cpp 源文件为例进行说明。

一、向 Utility.cpp 增加单元测试

待测源文件属于通用的、独立的功能性 API，所以直接调用每个接口。

1. 待测源文件所在目录

.\base\msdp\device_status\utils\common\include\utility.h
.\base\msdp\device_status\utils\common\src\utility.cpp

2. UtilityTest 测试用例代码

不存在的文件进行添加，存在的进行修改。

3. UtilityTest 单元测试的编译

UtilityTest 名称是在./base/msdp/device_status/test/unittest/utils/BUILD.gn 中规定的。

./build.sh --product-name rk3568 --build-target UtilityTest --fast-rebuild
// 或者
./build.sh --product-name rk3568 --build-target ./base/msdp/device_status/test/unittest/utils:UtilityTest --fast-rebuild

4. UtilityTest 生成物目录

二、测试

将编译生成的物拷贝到本地测试目录，然后运行脚本，在测试目录 log 下查看运行日志

1. UtilityTest 测试目录

将生成物拷贝到测试目录下：

2. 运行 test_UtilityTest.bat 脚本进行测试

将如下脚本写到 test_UtilityTest.bat 文件， 放置在 D:\Test\ 目录下。每次测试时就直接双击它就可以了，运行时的日志在 D:\Test\log\ 目录。

hdc shell mount -o rw,remount /
hdc hdc file send D:\Test\device_status\unit_out\UtilityTest /data 
pause

hdc shell power-shell setmode 602
hdc shell chmod 777 ./data/UtilityTest

hdc shell hilog -b D -D 0XD002220
hdc shell rm -rf ./data/log/hilog/*
hdc shell rm -rf ./data/log/faultlog/faultlogger/*
hdc shell hilog -w start
hdc shell hilog -r

hdc shell ./data/UtilityTest

hdc shell hilog -w stop
mkdir log\hilog
mkdir log\faultlogger
hdc file recv  ./data/log/hilog/ .\log\
hdc file recv ./data/log/faultlog/faultlogger/ .\log\
pause

3. 测试过程的日志

.\log\hilog: 当前用例执行的一般日志；
.\log\faultlogger: 当前用例执行的 Crash 崩溃日志，一般为空，若出现必须消除；

三、复盘覆盖率

有专业分支覆盖率测试工具检查用例执行后分支的覆盖情况，一般情况下每个函数不管是公有或者私有都调用到，则可以满足 60% 的覆盖率要求。但是本地没有这样的工具时，就要在待测源文件中每个函数的分支添加上特别的日志，执行用例后查看是否到达。

添加完日志，势必要编译源码所在子系统，编译完成后，将必要的文件推送到板子上，重启板子，然后进行如上测试。

1. 编译 device_status 子系统

 ./build.sh --product-name rk3568 --ccache --build-target device_status --fast-rebuild

编译完成后进行推送

2. 将子系统生成物拷贝到本地，然后推送到板子上已有位置，进行替换

生成物目录图：

拷贝到本地目录图：

3. 执行推送并重启板子的脚本

@echo off
::重新挂载
::author: wangyeyu
hdc shell mount -o rw,remount /

::@echo off
::指定起始文件夹， "%cd%"当前文件夹；%DIR%设置一个变量；%TAR_DIR_SYSTEM_LIB%表示手机下的目的路径
set DIR="%cd%"
echo DIR=%DIR%
set TAR_DIR_SYSTEM_LIB="/system/lib/"
set TAR_DIR_LIB="/lib/"
set TAR_DIR_SYSTEM_LIB_PLATFORMSDK="/system/lib/platformsdk/"
set TAR_DIR_LIB_PLATFORMSDK="/lib/platformsdk/"

set TAR_DIR_SYSTEM_LIB_MODULE="/system/lib/module/"
set TAR_DIR_LIB_MODULE="/lib/module/"

echo TAR_DIR_SYSTEM_LIB="%TAR_DIR_SYSTEM_LIB%"

:: 参数 /R 表示需要遍历子文件夹,去掉表示不遍历子文件夹
:: %%f 是一个变量,类似于迭代器,但是这个变量只能由一个字母组成,前面带上%%
:: 括号中是通配符,可以指定后缀名,*.*表示所有文件

for /R %DIR% %%f in (*.so) do ( 
    echo %%f
   hdc file send %%f %TAR_DIR_SYSTEM_LIB%
   hdc file send %%f %TAR_DIR_LIB%

   hdc file send %%f %TAR_DIR_SYSTEM_LIB_PLATFORMSDK%
   hdc file send %%f %TAR_DIR_LIB_PLATFORMSDK%

   hdc file send %%f %TAR_DIR_SYSTEM_LIB_MODULE%
   hdc file send %%f %TAR_DIR_LIB_MODULE%
)

::重启设备
hdc shell reboot
@pause

四、测试用例编写的注意细节

• 函数、文件、文件夹、生成物命名要符合已有规范；
• 测试用例放置的位置首先符合已有规划，如果首次在子系统中添加单元测试，一般集中放置在子系统根目录，但是子系统非常庞大，则放置在待测源码就近位置；
• 测试用例要覆盖到待测接口中的所有分支，极其意外的分支无法覆盖除外；
• 每个测试用例测试一条分支；
• 测试用例必须包括正常用例和异常用例；
• 测试用例一般从最外接口调起，他会从上到下覆盖所有正常分支；
• 构造对象及参数直接调用待测源文件接口的情况：暂时不能覆盖待测源文件中大部分正常分支，或者从上层无法构造待测源文件中包含的异常分支（场景），待测源文件可能远离接口；
• 对于新增加的文件，版权年份必须是当前年份；
• 直接调用待测接口及私有、保护函数、变量时，需要在 BUILD.gn 中添加

  cflags = [
    "-Dprivate=public",
    "-Dprotected=public",
  ]

• 修改或者新添加的 BUILD.gn 要用格式化命令进行格式： 例如：

$ sudo gn format ./base/msdp/device_status/test/unittest/utils/BUILD.gn 
// 或者
$ ./prebuilts/build-tools/linux-x86/bin/gn format ./base/msdp/device_status/test/unittest/utils/BUILD.gn 

五、小结

单元测试用例地编写属于简单的、必要的、能够体现产出的工作