跟着小白一起学鸿蒙(三)—手写一个测试用例

系统 OpenHarmony
这一节我们着重查看如何编写测试套件,编译并测试。

​想了解更多关于开源的内容,请访问:​

​51CTO 开源基础软件社区​

​https://ost.51cto.com​

开源鸿蒙测试初识

这一节我们着重查看如何编写测试套件,编译并测试。

1、目录结构

//目录位置:[鸿蒙代码]/test
.
├── arkXtest //js测试框架和ui测试框架
├── jsunit
└── uitest
├── developertest //开发测试组件
├── aw
├── config
├── examples
├── src
└── third_party
├── wukong //稳定性测试工具,冒烟测试
├── common
├── component_event
├── input_factory
├── report
├── shell_command
└── test_flow
├── xdevice //测试框架核心,提供执行用例的相关服务
├── BUILD.gn
├── extension
├── src
└── xts //兼容性测试套件
├── acts //应用兼容性测试套件
├── dcts //分布式兼容性测试套件
├── hats //硬件兼容性测试套件
└── tools

2、测试套件结构

我们选取比较简单的应用兼容性测试套件为例:

.
├── BUILD.gn //编译脚本
├── comm.gni //编译配置
├── src
├── ActsLibuvTestSuite.cpp //具体测试套件源文件
├── ActsLibuvTestSuite.h //具体测试套件头文件
└── Test.json //测试套件执行配置
  • 测试套件编译脚本-BUILD.gnimport("//test/xts/tools/build/suite.gni")。
 import("//test/xts/acts/graphic/libuv/comm.gni")
ohos_moduletest_suite("ActsLibuvTestSuite”) {
sources = [
"src/ActsLibuvTestSuite.cpp",
]
include_dirs = [ "//test/xts/acts/graphic/libuv/src" ]
cflags = [ "-Wno-error" ]}

BUILD.gn主要编写格式如下:

sources = [
"源文件",
]
include_dirs = [
"头文件目录",
],
deps = [
"依赖库路径:依赖库名称",
]
configs = [
"配置文件路径:配置文件名称"
]

具体解释如下:

  • sources:对应的就是需要编译的源文件。
  • include_dirs:对应的就是编译中的头文件的路径。
  • deps:对应的此程序依赖的其他的库,比如引入hilog,则增加 “//base/hiviewdfx/hilog/interfaces/native/innerkits:libhilog”。
  • configs: 对应编译的flags或者宏定义,如:
  • config("XX_config") {
    cflags_cc = [
    "-Wno-conversion",
    "-Wno-unused-function",
    ]
    defines = deqp_common_defines
    defines += [
    "_XOPEN_SOURCE=600"
    ]
    }

编译配置文件-comm.gni。

import("//test/xts/tools/build/suite.gni")
common_include = [
"//test/xts/acts/graphic/libuv/src",
]
common_depends = [
"//third_party/libuv:uv_static",
]

编译配置文件可以将共同的BUILD.gn内容放置在此,供其他gn文件或者gni文件使用。

具体测试套件源文件:

#include <gtest/gtest.h>
#include "ActsLibuvTestSuite.h"
namespace OHOS {
using namespace std;
using namespace testing::ext;
// Preset action of the test suite, which is executed before the first test case
void ActsLibuvTestSuite::SetUpTestCase(void)
{
}
// Test suite cleanup action, which is executed after the last test case
void ActsLibuvTestSuite::TearDownTestCase(void)
{
}
// Preset action of the test case
void ActsLibuvTestSuite::SetUp()
{
}
// Cleanup action of the test case
void ActsLibuvTestSuite::TearDown()
{
}
HWTEST_F(ActsLibuvTestSuite, testLibuvTestCase001, Function | MediumTest | Level2)
{
printf("------start ActsLibuvTestSuite------\n");
EXPECT_TRUE(true);
printf("------end ActsLibuvTestSuite------\n");
}
HWTEST_F(ActsLibuvTestSuite, testLibuvTestCase002, Function | MediumTest | Level2)
{
printf("------start ActsLibuvTestSuite------\n");
EXPECT_TRUE(false);
printf("------end ActsLibuvTestSuite------\n");
}
}

我们选取的此测试套件是模块测试套件,所以使用gtest测试框架进行测试。

gtest测试框架采用TestSuite + TestCase的组成方式,所以我们定义了ActsLibuvTestSuite作为测试Suite,然后添加两个testLibuvTestCase001,testLibuvTestCase002作为测试Case。

判断一个测试是否通过可以用EXPECT_TRUE(true),EXPECT_TRUE(false)进行验证,其他还可以使用的断言如下:

  • EXPECT_TRUE(condition)
  • EXPECT_FALSE(condition)
  • EXPECT_EQ(val1, val2)
  • EXPECT_NE(val1, val2)
  • EXPECT_LE(val1, val2)
  • EXPECT_LT(val1, val2)
  • EXPECT_GE(val1, val2)
  • EXPECT_GT(val1, val2)
  • EXPECT_STREQ(val1, val2)
  • EXPECT_STRNE(s1, s2)
  • EXPECT_STRCASEEQ(s1, s2)
  • EXPECT_STRCASENE(s1, s2)
  • EXPECT_FLOAT_EQ(val1, val2)
  • EXPECT_DOUBLE_EQ(val1, val2)

具体测试套件头文件:

#ifndef LIBUV_TESTCASE_H
#define LIBUV_TESTCASE_H
#include <gtest/gtest.h>
namespace OHOS {
class ActsLibuvTestSuite : public testing::Test {
public:
protected:
// Preset action of the test suite, which is executed before the first test case
static void SetUpTestCase(void);
// Test suite cleanup action, which is executed after the last test case
static void TearDownTestCase(void);
// Preset action of the test case
virtual void SetUp();
// Cleanup action of the test case
virtual void TearDown();
};
} // namespace OHOS

#endif // LIBUV_TESTCASE_H

测试套件执行配置文件:

{
"description": "Config for ActsLibuvTestSuite test cases",
"driver": {
"module-name": "ActsLibuvTestSuite",
"native-test-timeout": "120000",
"native-test-device-path": "/data/local/tmp",
"runtime-hint": "100s",
"type": "CppTest"
},
"kits": [
{
"pre-push" : [
],
"post-push" : [
"chmod -R 777 /data/local/tmp/*"
],
"push": [
"ActsLibuvTestSuite->/data/local/tmp/ActsLibuvTestSuite"
],
"type": "PushKit"
},
{
"type": "ShellKit",
"run-command": [
"remount",
"mkdir /data/test",
"cd /data/local/tmp"
]
}
]
}

测试套件配置文件是伴随测试套件运行的文件,在执行测试套件的时候,xdevice根据配置文件的具体命令执行测试用例,详细说明如下:

  • “description”:测试套件的文字说明
  • “driver”: 测试套件执行驱动配置
  • “module-name”: 配置测试套件名称
  • “native-test-timeout”: 套件超时设置
  • “native-test-device-path”: 套件运行目录
  • “runtime-hint”: 套件执行时间预估
  • “type”: 套件类型
  • “kits”: 测试套件工具配置
  • “PushKit”:传送工具
  • “pre-push”:从上位机推送到设备前的准备工作;
  • “push”: 从上位机推送到设备的动作;
  • “post-push”: 上位机推送后需要做的动作;
  • “ShellKit”:运行工具
  • “run-command”: 执行测试套件前需要配置的命令

3、编译测试套件

上面写的测试用例需要有一个入口进行加载,在此文章我们选取graphic的gn进行依赖添加路径:

路径:test/xts/acts/graphic/BUILD.gn
import("//build/ohos_var.gni")
group("graphic") {
testonly = true
if (is_standard_system) {
deps = [
"webGL:webGL_hap_test",
"windowStage:ActsWindowStageTest",
"windowstandard:window_hap_test",
#增加下面这行引入依赖
"libuv:ActsLibuvTestSuite",
]
} else {
deps = [
"appaccount:appaccount_hap",
"osaccount:osaccount_hap",
]
}
}

同**《#跟着小白一起学鸿蒙# [一]运行OpenHarmony》**一样,在鸿蒙代码根目录执行以下命令:

./build.sh --product-name rk3568 --gn-args build_xts=true --build-target "acts" --gn-args is_standard_system=true

深入技巧:我们会发现每次编译都会消耗大量时间,这里我们浅论下鸿蒙的编译方式。

  1. build.sh: 源码路径下的编译脚本,其主要目标就是找vender目录和productdefine目录下对应的编译目标,然后对其目标进行gn编译。
  2. gn编译:根据目标的build.gn文件生成build.ninja文件,总的build.ninja位于out/product目录下。
  3. ninja:根据目标的build.ninja编译生成产出问题件。

总结:所以如果不改动gn文件,但是改动源文件或者头文件的情况下,我们可以不用build.sh脚本生成代码,而是直接用ninja命令进行编译,如 ninja -C out/rk3568 uv_static。

4、执行测试套件

同**《#跟着小白一起学鸿蒙# [一]运行OpenHarmony》**一样,在鸿蒙代码根目录/out/rk3568/suites/acts执行以下命令:

//此命令的前提是:
//1, 开发板和上位机进行建立连接,没有配置网络的时候建议usb连接
//上位机执行:hdc_std shell (此命令可以进入开发板的shell,进行后续命令输入)
//2, 开发板的hdcd服务配置完协议类型和端口
//板上执行:param set persist.hdc.mode all
//板上执行:param set persist.hdc.port 10178
//板上执行:pkill hdcd (用来重启hdcd以便使用新配置)
//3, 开发板配置ip地址,并确认网络
//板上查看ip地址命令:ifconfig
//如果没有eth0则需要执行: ifconfig eth0 up
//如果有eth0则可以配置ip地址:ifconfig eth0 192.168.137.105
//检验网络是否通畅:ping 上位机IP地址
python -m xdevice

5、查看测试套件执行结果

在鸿蒙代码根目录/out/rk3568/suites/acts/reports内可以看到最新时间戳的目录即为刚才运行的测试记录。

.
├── 2022-08-16-14-15-25.zip
├── details_report.html //详细测试用例
├── log
│ ├── device_hilog_192.168.137.105_10178.log //系统hilog日志
│ └── task_log.log //测试用例输出日志
├── result
│ └── ActsLibuvTestSuite.xml //测试结果汇总
├── summary.ini
├── summary_report.hash
├── summary_report.html //测试报告大纲
├── summary_report.xml

测试报告。

测试报告详情。

#跟着小白一起学鸿蒙# [三]手写一个测试用例-开源基础软件社区

​想了解更多关于开源的内容,请访问:​

​51CTO 开源基础软件社区​

​https://ost.51cto.com​​。

责任编辑:jianghua 来源: ​​51CTO开源基础软件社区
相关推荐

2022-12-02 14:20:09

Tetris鸿蒙

2022-11-29 16:35:02

Tetris鸿蒙

2022-09-28 13:57:41

鸿蒙开源

2022-11-14 17:01:34

游戏开发画布功能

2023-03-30 09:32:27

2022-08-29 17:25:19

鸿蒙应用开发

2022-11-25 16:48:54

鸿蒙Stage HAP

2023-02-27 16:30:32

鸿蒙开源协议分析

2023-03-30 09:19:54

SELinux安全子系统

2022-08-19 19:02:20

开源鸿蒙操作系统

2022-09-30 14:08:26

Hap应用鸿蒙

2023-04-04 09:24:11

鸿蒙HiDumper

2022-10-10 14:47:04

蓝牙应用鸿蒙

2023-01-03 15:09:10

鸿蒙常用工具

2022-10-20 16:40:16

JS应用控制LED鸿蒙

2022-10-09 15:05:50

NAPI框架鸿蒙

2022-12-06 15:39:16

鸿蒙主干代码

2023-03-15 16:19:03

BinderIPC工具

2022-11-24 14:34:41

Hap程序鸿蒙

2022-11-03 15:47:04

HTTP通信协议
点赞
收藏

51CTO技术栈公众号