背景
程序开发与单元测试二者密不可分,是每个开发人员的基本业务。当功能性代码开发完成后,要自行测试其是否满足设计预期,如果不满足就要回去完善代码,满足则可以提交功能代码及测试用例。
测试用例的另一个重要作用就是阅读者了解代码的“一扇窗”,因为测试用例是程序的入口。
测试用例要覆盖每个接口所有分支,即保证每个待测函数的功能是正常的。
多个接口序列化功能需要提供完整序列化组合测试用例,例如: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
五、小结
单元测试用例地编写属于简单的、必要的、能够体现产出的工作
总是有很多小伙伴反馈说:OpenHarmony开发不知道学习哪些技术?不知道需要重点掌握哪些OpenHarmony开发知识点? 为了解决大家这些学习烦恼。在这准备了一份很实用的鸿蒙全栈开发学习路线与学习文档给大家用来跟着学习。
针对一些列因素,整理了一套纯血版鸿蒙(HarmonyOS Next)全栈开发技术的学习路线,包含了鸿蒙开发必掌握的核心知识要点,内容有(OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony驱动开发、系统定制移植……等)技术知识点。
OpenHarmony 开发环境搭建:https://gitcode.com/HarmonyOS_MN/733GH/overview
《OpenHarmony源码解析》
搭建开发环境
系统架构分析
- 构建子系统
- 启动流程
- 子系统
- 分布式任务调度子系统
- 分布式通信子系统
- 驱动子系统
- ……