摘要:本文主要介绍ACTS应用兼容性测试用例开发编译。

本文分享自华为云社区《移植案例与原理 - XTS子系统之应用兼容性测试用例开发》,作者: zhushy 。

XTS(X Test Suite)子系统是OpenHarmony生态认证测试套件的集合,当前包括:

  • acts(application compatibility test suite)应用兼容性测试套件,看护北向HAP兼容、OpenHarmony开发API兼容。
  • hats(Hardware Abstraction Test Suite )硬件抽象测试套,看护HDI层接口。
  • dcts(Distributed Compatibility Test Suite )分布式兼容性测试套,看护分布式兼容(待上线)

在移植芯片开发板后,需要运行应用兼容性测试套件。对于大部分工程师,是不需要开发ACTS测试用例的。但是了解一下这些知识,在问题定位等会带来极大的方便。本文主要介绍下ACTS应用兼容性测试用例开发编译。使用的编程语言为C语言。

1、XTS测试套件目录

XTS的ACTS应用兼容性测试套件目录test\xts\acts,器目录如下,包含各个子系统的测试用例源代码及测试工具代码。

/test/xts
├── acts # 测试代码存放目录
│ └── aafwk # 标准系统的 元能力框架子系统 测试用例源码存放目录
│ └── aafwk_lite # 轻量系统、小型系统的 元能力框架 子系统测试用例源码存放目录
│ └── communication # 标准系统的 communication子系统 测试用例源码存放目录
│ └── communication_lite # 轻量系统、小型系统的 communication 子系统测试用例源码存放目录
| └── ....... # 其他子系统的测试用例源码存放目录
│ └── BUILD.gn # 标准系统测试用例编译配置
│ └── build_lite # 轻量系统、小型系统测试用例编译配置存放目录
│ └── BUILD.gn # 轻量系统、小型系统测试用例编译配置
└── tools # 测试工具代码存放目录

2、测试用例级别、粒度和类型

测试用例分为5个级别,分布为Level0、Level1、Level2、Level3、Level4,这几个宏定义在文件test\xts\tools\lite\hctest\include\hctest_internal.h。对这几个级别的解释可以从文章尾部的参考站点上可以了解。

/**
* test case level
*/
enum TestRank {
Level0 = 1,
Level1 = 2,
Level2 = 3,
Level3 = 4,
Level4 = 5
};

用例粒度分为LargeTest、MediumTest和SmallTest,同样在文件test\xts\tools\lite\hctest\include\hctest_internal.h中定义。

/**
* test size
*/
enum TestSize {
SmallTest = 1 << 4,
MediumTest = 2 << 4,
LargeTest = 3 << 4
};

测试类型分为Function、Performance、Power、Reliability、Security、Global、Compatibility、User、Standard、Safety和Resilience。宏定义如下,具体含义见参考站点中链接。

/**
* test type
*/
enum TestType {
Function = 1 << 8,
Performance = 2 << 8,
Power = 3 << 8,
Reliability = 4 << 8,
Security = 5 << 8,
Global = 6 << 8,
Compatibility = 7 << 8,
User = 8 << 8,
Standard = 9 << 8,
Safety = 10 << 8,
Resilience = 11 << 8
};

3、C语言用例开发编译指导

根据测试系统选择测试框架和对应测试用例语言。系统类型和测试框架、开发语言对应关系如下:

我们主要看下轻量系统产品用例开发。轻量系统测试使用的测试框架是hctest,hctest测试框架支持使用C语言编写测试用例,是在开源测试框架unity的基础上进行增强和适配。

3.1 用例目录规范

我们上文已经看到了ACTS的目录, 测试用例存储到test/xts/acts仓中。假如我们在一个名为subsystem_lite的子系统中为module_hal部件开发用例,目录如下:

├── acts
| └── ......
│ └── subsystem_lite
│ │ └── module_hal
│ │ │ └── BUILD.gn
│ │ │ └── src
│ └──build_lite
│ │ └── BUILD.gn

可以参考已经存在的用例的目录,比如test\xts\acts\utils_lite\file_hal、test\xts\acts\utils_lite\kv_store_hal、test\xts\acts\startup_lite\bootstrap_hal等等。

3.2 编写用例样例

3.2.1 引用测试框架

hctest.h 文件位于./test/xts/tools/lite/hctest/include/目录,定义了LITE_TEST_SUIT、LITE_TEST_CASE、RUN_TEST_SUITE等测试套件的宏。

#include "hctest.h"

3.2.2 定义子系统、模块、测试套件名称

需要3个参数,分别为子系统名称、子系统的部件名称、测试套件名称。

/**
* @brief register a test suit named "IntTestSuite"
* @param test subsystem name
* @param example module name
* @param IntTestSuite test suit name
*/
LITE_TEST_SUIT(test, example, IntTestSuite);

已经存在的示例,可以参考test\xts\acts\utils_lite\kv_store_hal\src\kvstore_func_test.c,为utils子系统的kvStore部件注册KvStoreFuncTestSuite测试套件。

/**
* @tc.desc : register a test suite, this suite is used to test basic flow and interface dependency
* @param : subsystem name is utils
* @param : module name is kvStore
* @param : test suit name is KvStoreFuncTestSuite
*/
LITE_TEST_SUIT(utils, kvStore, KvStoreFuncTestSuite);

3.2.3 定义Setup与TearDown

命名方式:测试套件名称+Setup,测试套件名称+TearDown。Setup与TearDown必须存在,可以为空函数。示例可以参考test\xts\acts\utils_lite\kv_store_hal\src\kvstore_func_test.c,如下:

/**
* @tc.setup : setup for all testcases
* @return : setup result, TRUE is success, FALSE is fail
*/
static BOOL KvStoreFuncTestSuiteSetUp(void)
{
UtilsSetEnv(DATA_PATH);
return TRUE;
} /**
* @tc.teardown : teardown for all testcases
* @return : teardown result, TRUE is success, FALSE is fail
*/
static BOOL KvStoreFuncTestSuiteTearDown(void)
{
printf("+-------------------------------------------+\n");
return TRUE;
}

3.2.4 使用宏定义LITE_TEST_CASE写测试用例

LITE_TEST_CASE函数宏包括三个参数:测试套件名称,测试用例名称,用例属性(测试类型、用例粒度、用例级别)。示例代码中创建测试用例,名称为TestCase001,属于测试套件IntTestSuite,测试用例属性为功能测试、测试用例粒度为MediumTest,用例级别Level1。

LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1)
{
//do something
};

示例可以参考test\xts\acts\utils_lite\kv_store_hal\src\kvstore_func_test.c,如下,测试套件KvStoreFuncTestSuite中创建测试用例testKvStoreSetValue001,测试kvstore部件的UtilsSetValue和UtilsDeleteValue接口。

/**
* @tc.number : SUB_UTILS_KV_STORE_0100
* @tc.name : UtilsSetValue parameter legal test
* @tc.desc : [C- SOFTWARE -0200]
*/
LITE_TEST_CASE(KvStoreFuncTestSuite, testKvStoreSetValue001, Function | MediumTest | Level1)
{
char key[] = "rw.sys.version";
char value[] = "Hello world !";
int ret = UtilsSetValue(key, value);
TEST_ASSERT_EQUAL_INT(0, ret); ret = UtilsDeleteValue(key);
TEST_ASSERT_EQUAL_INT(0, ret);
};

3.2.5 使用宏定义 RUN_TEST_SUITE注册测试套件

RUN_TEST_SUITE(IntTestSuite);

3.3 测试模块的构建配置文件

在每个测试模块目录subsystem_lite/module_hal下新建BUILD.gn编译文件,用于指定编译后静态库的名称、依赖的头文件、依赖的库等;具体写法如下:

import("//test/xts/tools/lite/build/suite_lite.gni")
hctest_suite("ActsDemoTest") {
suite_name = "acts"
sources = [
"src/test_demo.c",
]
include_dirs = [ ]
cflags = [ "-Wno-error" ]
}

3.4 acts下BUILD.gn增加编译选项

需要将测试模块加入到acts目录下的编译脚本中,编译脚本路径:test/xts/acts/build_lite/BUILD.gn。

lite_component("acts") {
...
if(board_name == "liteos_m") {
features += [
...
"//xts/acts/subsystem_lite/module_hal:ActsDemoTest"
]
}
}

3.5 编译烧录运行

随版本编译,debug版本编译时会同步编译acts测试套件。acts测试套件编译中间件为静态库,最终链接到版本镜像中 。将版本镜像烧录进开发板。重启设备,查看串口日志。每个测试套件执行以Start to run test suite开始,以xx Tests xx Failures xx Ignored结束。

参考站点

参考了下述站点,或者推荐读者阅读下述站点了解更多信息。

点击关注,第一时间了解华为云新鲜技术~

【OpenHarmony移植案例与原理】XTS子系统之应用兼容性测试用例开发的更多相关文章

  1. OpenHarmony移植案例与原理:startup子系统之syspara_lite系统属性部件

    摘要:本文介绍下移植开发板时如何适配系统属性部件syspara_lite,并介绍下相关的运行机制原理. 本文分享自华为云社区<openharmony移植案例与原理 - startup子系统之sy ...

  2. OpenHarmony移植:如何适配utils子系统之KV存储部件

    摘要:本文介绍移植开发板时如何适配utils子系统之KV存储部件,并介绍相关的运行机制原理. 本文分享自华为云社区<OpenHarmony移植案例与原理 - utils子系统之KV存储部件> ...

  3. OpenHarmony移植案例: build lite源码分析之hb命令__entry__.py

    摘要:本文介绍了build lite 轻量级编译构建系统hb命令的源码,主要分析了_\entry__.py文件. 本文分享自华为云社区<移植案例与原理 - build lite源码分析 之 hb ...

  4. elasticsearch 亿级数据检索案例与原理

    版权说明: 本文章版权归本人及博客园共同所有,转载请标明原文出处( https://www.cnblogs.com/mikevictor07/p/10006553.html ),以下内容为个人理解,仅 ...

  5. JDK动态代理案例与原理分析

    一.JDK动态代理实现案例 Person接口 package com.zhoucong.proxy.jdk; public interface Person { // 寻找真爱 void findlo ...

  6. SpringBoot定时任务 - 经典定时任务设计:时间轮(Timing Wheel)案例和原理

    Timer和ScheduledExecutorService是JDK内置的定时任务方案,而业内还有一个经典的定时任务的设计叫时间轮(Timing Wheel), Netty内部基于时间轮实现了一个Ha ...

  7. 【直播回顾】OpenHarmony知识赋能第四期第四课——音频驱动开发

    3月31日晚上19点,知识赋能第四期直播的第四节,也是本期最后一节直播课​<OpenHarmony标准系统HDF框架之音频驱动开发>​,在OpenHarmony开发者成长计划社群内成功举办 ...

  8. 【直播回顾】OpenHarmony知识赋能第四期第三课——I2C驱动开发

    3月24日晚上19点,​知识赋能第四期直播的第三节课<OpenHarmony标准系统HDF框架之I2C驱动开发>​,在OpenHarmony开发者成长计划社群内成功举办. 本期课程,由​拓 ...

  9. (24/24) webpack小案例--自己动手用webpack构建一个React的开发环境

    通过前面的学习,对webpack有了更深的认识,故此节我们就利用前面相关知识自己动手用webpack构建一个React的开发环境,就算是一个小案例吧. 注:此处使用的开发工具是Webstorm. 1. ...

随机推荐

  1. Spring 是怎么处理循环依赖的?

    Java语法中的循环依赖 首先看一个使用构造函数的循环依赖,如下: public class ObjectA { private ObjectB b; public ObjectA(ObjectB b ...

  2. [源码解析] NVIDIA HugeCTR,GPU 版本参数服务器 --(1)

    [源码解析] NVIDIA HugeCTR,GPU版本参数服务器 --(1) 目录 [源码解析] NVIDIA HugeCTR,GPU版本参数服务器 --(1) 0x00 摘要 0x01 背景 1.1 ...

  3. TCP/IP详解 读书笔记:TCP:传输控制协议

    TCP的服务 TCP为应用层提供一种面向连接的.可靠的字节流服务. 一个TCP连接中,仅有两方进行彼此通信,所以广播和多播不能用于TCP. TCP通过以下方式提供可靠性: 应用数据被切割为TCP认为最 ...

  4. 黑客高端de浏览器使用秘籍

    搜索引擎已经成为上网必不可少的工具之一,聪明的黑客们发现,搜索引擎也能成为发动网络攻击的工具. Google Hacking,原指利用Google搜索引擎搜索信息来进行入侵的技术和行为,如今已不再局限 ...

  5. IDEA自带Http Client替代Postman校验接口

    对比Postman的优势 对于数据格式变动可以更为敏锐的观察到.生成的接口请求文件可以同步到代码库,支持多人使用. 使用说明 创建请求文件 使用IDEA,在项目的Scratches下创建Http Re ...

  6. pytest(5)-断言

    前言 断言是完整的测试用例中不可或缺的因素,用例只有加入断言,将实际结果与预期结果进行比对,才能判断它的通过与否. unittest 框架提供了其特有的断言方式,如:assertEqual.asser ...

  7. Smartbi实践:制作可视化分析报表的感悟

    ​估计看到这篇文章的朋友,都是有使用过Smartbi制作数据可视化图表的.但是不是制作过程跟制作效果并没有让自己那么满意.使用过程也经常遇到一些问题解决不了?那是因为你使用的方法不对.你是否在使用Sm ...

  8. MethodImpl 特性

    5,MethodImpl 特性 此特性在 System.Runtime.CompilerServices 命名空间中,指定如何实现方法的详细信息. 内联函数使用方法可参考 https://www.wh ...

  9. 每日一算之变位词(C#)

    今天看编程珠玑里面,看到一个关于查找变位词的题目,大概意思如下:post,stop,tops这几个是变位词,找出类似的这些词语来. 解题思路一:既然是变位词,1.他们的长度一定是一致的:2.还有就是他 ...

  10. Jenkins——为什么使用持续集成?

    一.开发模型 1.瀑布开发模型:过程线性不可逆的开发模型 优势: 1)简单易懂 2)当前阶段完成后只需要关注后续阶段 3)为项目提供了按阶段划分的检查节点 劣势: 1)各个阶段的划分完全固定,阶段之间 ...