未验证 提交 84b2fc10 编写于 作者: O openharmony_ci 提交者: Gitee

!10575 增加测试指南目录

Merge pull request !10575 from ry/master
# 自动化测试框架使用指南
## 概述
为支撑OpenHarmony操作系统的自动化测试活动开展,我们提供了支持JS/TS语言的单元及UI测试框架,支持开发者针对应用接口或系统接口进行单元测试,并且可基于UI操作进行UI自动化脚本的编写。
本指南重点介绍自动化测试框架的主要功能,同时介绍编写单元/UI自动化测试脚本的方法以及执行过程。
### 简介
OpenHarmony自动化测试框架arkxtest,作为OpenHarmony工具集的重要组成部分,提供了OpenHarmony自动化脚本编写和运行的基础能力。编写方面提供了一系列支持测试脚本编写的API,包括了基础流程API、断言API以及UI操作相关的API,运行方面提供了识别测试脚本、调度执行测试脚本以及汇总测试脚本执行结果的能力。
### 实现原理
框架重要分为两大部分:单元测试框架和UI测试框架。
- 单元测试框架
单元测试框架是测试框架的基础底座,提供了最基本的用例识别、调度、执行及结果汇总的能力。主要功能如下图所示:
![](figures/UnitTest.PNG)
单元测试脚本的基础运行流程如下图所示,依赖aa test命令作为执行入口,该命令可具体参考[对应指南。](../ability/ability-delegator.md)
![](figures/TestFlow.PNG)
- UI测试框架
UI测试框架主要对外提供了[UiTest API](../reference/apis/js-apis-uitest.md)供开发人员在对应测试场景调用,而其脚本的运行基础还是上面提到的单元测试框架。
UI测试框架的主要功能如下图所示:
![](figures/Uitest.PNG)
### 约束与限制
- UI测试框架的能力在OpenHarmony 3.1 release版本之后方可使用,历史版本不支持使用。
- 单元测试框架的部分能力与其版本有关,具体能力与版本匹配信息可见代码仓中的[文档介绍](https://gitee.com/openharmony/testfwk_arkxtest/blob/master/README_zh.md)
## 环境准备
### 环境要求
OpenHarmony自动化脚本的编写主要基于DevEco Studio,并建议使用3.0之后的版本进行脚本编写。
脚本执行需要PC连接OpenHarmony设备,如RK3568开发板等。
### 搭建环境
DevEco Studio可参考其官网介绍进行[下载](https://developer.harmonyos.com/cn/develop/deveco-studio#download),并进行相关的配置动作。
## 新建测试脚本
1. 在DevEco Studio中新建应用开发工程,其中ohos目录即为测试脚本所在的目录。
2. 在工程目录下打开待测试模块下的ets文件,将光标置于代码中任意位置,单击**右键 > Show Context Actions** **> Create Ohos Test**或快捷键**Alt+enter** **> Create Ohos Test**创建测试类,更多指导请参考DevEco Studio中[指导](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-openharmony-test-framework-0000001267284568)
## 编写单元测试脚本
```TS
import { describe, beforeAll, beforeEach, afterEach, afterAll, it, expect } from '@ohos/hypium'
import abilityDelegatorRegistry from '@ohos.application.abilityDelegatorRegistry'
const delegator = abilityDelegatorRegistry.getAbilityDelegator()
export default function abilityTest() {
describe('ActsAbilityTest', function () {
it('testUiExample',0, async function (done) {
console.info("uitest: TestUiExample begin");
//start tested ability
await delegator.executeShellCommand('aa start -b com.ohos.uitest -a MainAbility').then(result =>{
console.info('Uitest, start ability finished:' + result)
}).catch(err => {
console.info('Uitest, start ability failed: ' + err)
})
await sleep(1000);
//check top display ability
await delegator.getCurrentTopAbility().then((Ability)=>{
console.info("get top ability");
expect(Ability.context.abilityInfo.name).assertEqual('MainAbility');
})
done();
})
function sleep(time) {
return new Promise((resolve) => setTimeout(resolve, time));
}
})
}
```
单元测试脚本需要包含如下基本元素:
1、依赖导包,以便使用依赖的测试接口。
2、测试代码编写,主要编写测试代码的相关逻辑,如接口调用等。
3、断言接口调用,设置测试代码中的检查点,如无检查点,则不可认为一个完整的测试脚本。
## 编写UI测试脚本
UI测试脚本是在单元测试框架的基础上编写,主要就是增加了UI测试框架提供的接口调用,实现对应的测试逻辑。
下面的示例代码是在上面的测试脚本基础上增量编写,首先需要增加依赖导包,如下示例代码所示:
```js
import {UiDriver,BY,UiComponent,MatchPattern} from '@ohos.uitest'
```
然后是具体测试代码编写,场景较为简单,就是在启动的应用页面上进行点击操作,然后增加检查点检查用例。
```js
export default function abilityTest() {
describe('ActsAbilityTest', function () {
it('testUiExample',0, async function (done) {
console.info("uitest: TestUiExample begin");
//start tested ability
await delegator.executeShellCommand('aa start -b com.ohos.uitest -a MainAbility').then(result =>{
console.info('Uitest, start ability finished:' + result)
}).catch(err => {
console.info('Uitest, start ability failed: ' + err)
})
await sleep(1000);
//check top display ability
await delegator.getCurrentTopAbility().then((Ability)=>{
console.info("get top ability");
expect(Ability.context.abilityInfo.name).assertEqual('MainAbility');
})
//ui test code
//init uidriver
var driver = await UiDriver.create();
await driver.delayMs(1000);
//find button by text 'Next'
var button = await driver.findComponent(BY.text('Next'));
//click button
await button.click();
await driver.delayMs(1000);
//check text
await driver.assertComponentExist(BY.text('after click'));
await driver.pressBack();
done();
})
function sleep(time) {
return new Promise((resolve) => setTimeout(resolve, time));
}
})
}
```
## 执行测试脚本
执行测试脚本可以直接在DevEco Studio中通过点击按钮执行,当前支持以下执行方式:
1、测试包级别执行即执行测试包内的全部用例。
2、测试套级别执行即执行describe方法中定义的全部测试用例。
3、测试方法级别执行即执行指定it方法也就是单条测试用例。
![](figures/Execute.PNG)
## 查看测试结果
测试执行完毕后可直接在DevEco Studio中查看测试结果,如下图示例所示:
![](figures/TestResult.PNG)
# 开发自测试执行框架使用指南
## 概述
OpenHarmony为开发者提供了一套全面的开发自测试框架developer_test,作为OpenHarmony测试工具集的一部分,提供给开发者自测试使用。开发者可根据测试需求开发相关测试用例,开发阶段提前发现缺陷,大幅提高代码质量。
本文从基础环境构建,用例开发,编译以及执行等方面介绍OpenHarmony开发自测试执行框架如何运行和使用。
### 简介
OpenHarmony系统开发人员在新增或修改代码之后,希望可以快速的验证修改代码的功能的正确性,而系统中已经存在了大量的已有功能的自动化测试用例,比如TDD用例或XTS用例等。开发者自测试执行框架目的就是为了提升开发者的自测试执行效率,方便开发人员可以快速便捷的执行指定的自动化测试用例,将测试活动左移到开发阶段。
### 约束与限制
- 框架使用时必须提前连接OpenHarmony设备方可执行测试用例。
## 环境准备
开发自测试框架依赖于python运行环境,python版本为3.8.X,在使用测试框架之前可参阅以下方式进行配置。
- [环境配置](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-testguide-test.md#%E7%8E%AF%E5%A2%83%E9%85%8D%E7%BD%AE)
- [源码获取](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/get-code/sourcecode-acquire.md)
## 编写测试用例
本测试框架支持多种类型测试,针对不同测试类型提供了不同的用例编写模板以供参考。_
**TDD测试(C++)**
用例源文件命名规范
测试用例源文件名称和测试套内容保持一致,文件命名采用全小写+下划线方式命名,以test结尾,具体格式为:[功能]_[子功能]_test,子功能支持向下细分。
示例:
```
calculator_sub_test.cpp
```
用例示例
```
/*
* Copyright (c) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include "calculator.h"
#include <gtest/gtest.h>
using namespace testing::ext;
class CalculatorSubTest : public testing::Test {
public:
static void SetUpTestCase(void);
static void TearDownTestCase(void);
void SetUp();
void TearDown();
};
void CalculatorSubTest::SetUpTestCase(void)
{
// input testsuit setup step,setup invoked before all testcases
}
void CalculatorSubTest::TearDownTestCase(void)
{
// input testsuit teardown step,teardown invoked after all testcases
}
void CalculatorSubTest::SetUp(void)
{
// input testcase setup step,setup invoked before each testcases
}
void CalculatorSubTest::TearDown(void)
{
// input testcase teardown step,teardown invoked after each testcases
}
/**
* @tc.name: integer_sub_001
* @tc.desc: Verify the sub function.
* @tc.type: FUNC
* @tc.require: issueNumber
*/
HWTEST_F(CalculatorSubTest, integer_sub_001, TestSize.Level1)
{
// step 1:调用函数获取结果
int actual = Sub(4,0);
// Step 2:使用断言比较预期与实际结果
EXPECT_EQ(4, actual);
}
```
详细内容介绍:
1.添加测试用例文件头注释信息
```
/*
* Copyright (c) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
```
2.引用测试框架头文件和命名空间
```
#include <gtest/gtest.h>
using namespace testing::ext;
```
3.添加被测试类的头文件
```
#include "calculator.h"
```
4.定义测试套(测试类)
```
class CalculatorSubTest : public testing::Test {
public:
static void SetUpTestCase(void);
static void TearDownTestCase(void);
void SetUp();
void TearDown();
};
void CalculatorSubTest::SetUpTestCase(void)
{
// input testsuit setup step,setup invoked before all testcases
}
void CalculatorSubTest::TearDownTestCase(void)
{
// input testsuit teardown step,teardown invoked after all testcases
}
void CalculatorSubTest::SetUp(void)
{
// input testcase setup step,setup invoked before each testcases
}
void CalculatorSubTest::TearDown(void)
{
// input testcase teardown step,teardown invoked after each testcases
}
```
> **注意:** 在定义测试套时,测试套名称应与编译目标保持一致,采用大驼峰风格。
5.测试用例实现,包含用例注释和逻辑实现
```
/**
* @tc.name: integer_sub_001
* @tc.desc: Verify the sub function.
* @tc.type: FUNC
* @tc.require: issueNumber
*/
HWTEST_F(CalculatorSubTest, integer_sub_001, TestSize.Level1)
{
//step 1:调用函数获取结果
int actual = Sub(4,0);
//Step 2:使用断言比较预期与实际结果
EXPECT_EQ(4, actual);
}
```
> **注意:** @tc.require: 格式必须以AR/SR或issue开头: 如:issueI56WJ7
在编写用例时,我们提供了三种用例模板供您选择。
| 类型 | 描述 |
| --------------- | ------------------------------------------------ |
| HWTEST(A,B,C) | 用例执行不依赖Setup&Teardown时,可选取 |
| HWTEST_F(A,B,C) | 用例执行(不含参数)依赖于Setup&Teardown时,可选取 |
| HWTEST_P(A,B,C) | 用例执行(含参数)依赖于Set&Teardown时,可选取 |
其中,参数A,B,C的含义如下:
- 参数A为测试套名。
- 参数B为测试用例名,其命名必须遵循[功能点]_[编号]的格式,编号为3位数字,从001开始。
- 参数C为测试用例等级,具体分为门禁level0 以及非门禁level1-level4共五个等级,其中非门禁level1-level4等级的具体选取规则为:测试用例功能越重要,level等级越低。
**注意:**
- 测试用例的预期结果必须有对应的断言。
- 测试用例必须填写用例等级。
- 测试体建议按照模板分步实现。
- 用例描述信息按照标准格式@tc.xxx value书写,注释信息必须包含用例名称,用例描述,用例类型,需求编号四项。其中用例测试类型@tc.type参数的选取,可参考下表。
| 测试类型名称 | 类型编码 |
| ------------ | -------- |
| 功能测试 | FUNC |
| 性能测试 | PERF |
| 可靠性测试 | RELI |
| 安全测试 | SECU |
| 模糊测试 | FUZZ |
**TDD测试(JS)**
- 用例源文件命名规范
测试用例原文件名称采用大驼峰风格,以TEST结尾,具体格式为:[功能][子功能]TEST,子功能支持向下细分。
示例:
```
AppInfoTest.js
```
- 用例示例
```
/*
* Copyright (C) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import app from '@system.app'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
describe("AppInfoTest", function () {
beforeAll(function() {
// input testsuit setup step,setup invoked before all testcases
console.info('beforeAll caled')
})
afterAll(function() {
// input testsuit teardown step,teardown invoked after all testcases
console.info('afterAll caled')
})
beforeEach(function() {
// input testcase setup step,setup invoked before each testcases
console.info('beforeEach caled')
})
afterEach(function() {
// input testcase teardown step,teardown invoked after each testcases
console.info('afterEach caled')
})
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
* @tc.type: FUNC
* @tc.require: issueNumber
*/
it("appInfoTest001", 0, function () {
//step 1:调用函数获取结果
var info = app.getInfo()
//Step 2:使用断言比较预期与实际结果
expect(info != null).assertEqual(true)
})
})
```
详细内容介绍:
1. 添加测试用例文件头注释信息
```
/*
* Copyright (C) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
```
2. 导入被测api和jsunit测试库
```
import app from '@system.app'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
```
3. 定义测试套(测试类)
```
describe("AppInfoTest", function () {
beforeAll(function() {
// input testsuit setup step,setup invoked before all testcases
console.info('beforeAll caled')
})
afterAll(function() {
// input testsuit teardown step,teardown invoked after all testcases
console.info('afterAll caled')
})
beforeEach(function() {
// input testcase setup step,setup invoked before each testcases
console.info('beforeEach caled')
})
afterEach(function() {
// input testcase teardown step,teardown invoked after each testcases
console.info('afterEach caled')
})
```
4. 测试用例实现
```
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
* @tc.type: FUNC
* @tc.require: issueNumber
*/
it("appInfoTest001", 0, function () {
//step 1:调用函数获取结果
var info = app.getInfo()
//Step 2:使用断言比较预期与实际结果
expect(info != null).assertEqual(true)
})
```
> **注意:** @tc.require: 格式必须以AR/SR或issue开头: 如:issueI56WJ7
**Fuzz测试**
[Fuzz用例编写规范](https://gitee.com/openharmony/test_developertest/blob/master/libs/fuzzlib/README_zh.md)
**Benchmark测试**
[Benchmark用例编写规范](https://gitee.com/openharmony/test_developertest/blob/master/libs/benchmark/README_zh.md)_
## 编译测试用例
根据测试用例目录规划,当执行某一用例时,测试框架会根据编译文件逐层查找,最终找到所需用例进行编译。下面通过不同示例来讲解gn文件如何编写。
**TDD测试**
针对不同语言,下面提供不同的编译模板以供参考。
- **C++用例编译配置示例**
```
# Copyright (c) 2021 XXXX Device Co., Ltd.
import("//build/test.gni")
module_output_path = "developertest/calculator"
config("module_private_config") {
visibility = [ ":*" ]
include_dirs = [ "../../../include" ]
}
ohos_unittest("CalculatorSubTest") {
module_out_path = module_output_path
sources = [
"../../../include/calculator.h",
"../../../src/calculator.cpp",
]
sources += [ "calculator_sub_test.cpp" ]
configs = [ ":module_private_config" ]
deps = [ "//third_party/googletest:gtest_main" ]
}
group("unittest") {
testonly = true
deps = [":CalculatorSubTest"]
}
```
详细内容如下:
1. 添加文件头注释信息
```
# Copyright (c) 2021 XXXX Device Co., Ltd.
```
2. 导入编译模板文件
```
import("//build/test.gni")
```
3. 指定文件输出路径
```
module_output_path = "developertest/calculator"
```
> **说明:** 此处输出路径为部件/模块名。
4. 配置依赖包含目录
```
config("module_private_config") {
visibility = [ ":*" ]
include_dirs = [ "../../../include" ]
}
```
> **说明:** 一般在此处对相关配置进行设置,在测试用例编译脚本中可直接引用。
5. 指定测试用例编译目标输出的文件名称
```
ohos_unittest("CalculatorSubTest") {
}
```
6. 编写具体的测试用例编译脚本(添加需要参与编译的源文件、配置和依赖)
```
ohos_unittest("CalculatorSubTest") {
module_out_path = module_output_path
sources = [
"../../../include/calculator.h",
"../../../src/calculator.cpp",
"../../../test/calculator_sub_test.cpp"
]
sources += [ "calculator_sub_test.cpp" ]
configs = [ ":module_private_config" ]
deps = [ "//third_party/googletest:gtest_main" ]
}
```
> **说明:根据测试类型的不同,在具体编写过程中可选择不同的测试类型:**
> - ohos_unittest:单元测试
> - ohos_moduletest:模块测试
> - ohos_systemtest:系统测试
> - ohos_performancetest:性能测试
> - ohos_securitytest:安全测试
> - ohos_reliabilitytest:可靠性测试
> - ohos_distributedtest:分布式测试
7. 对目标测试用例文件进行条件分组
```
group("unittest") {
testonly = true
deps = [":CalculatorSubTest"]
}
```
> **说明:** 进行条件分组的目的在于执行用例时可以选择性的执行某一种特定类型的用例。
- **JavaScript用例编译配置示例**
```
# Copyright (C) 2021 XXXX Device Co., Ltd.
import("//build/test.gni")
module_output_path = "developertest/app_info"
ohos_js_unittest("GetAppInfoJsTest") {
module_out_path = module_output_path
hap_profile = "./config.json"
certificate_profile = "//test/developertest/signature/openharmony_sx.p7b"
}
group("unittest") {
testonly = true
deps = [ ":GetAppInfoJsTest" ]
}
```
详细内容如下:
1.添加文件头注释信息
```
# Copyright (C) 2021 XXXX Device Co., Ltd.
```
2.导入编译模板文件
```
import("//build/test.gni")
```
3.指定文件输出路径
```
module_output_path = "developertest/app_info"
```
> **说明:** 此处输出路径为部件/模块名。
4.指定测试用例编译目标输出的文件名称
```
ohos_js_unittest("GetAppInfoJsTest") {
}
```
> **说明:**
> - 使用模板ohos_js_unittest定义js测试套,注意与C++用例区分。
> - js测试套编译输出文件为hap类型,hap名为此处定义的测试套名,测试套名称必须以JsTest结尾。
5.指定hap包配置文件config.json和签名文件,两个配置为必选项
```
ohos_js_unittest("GetAppInfoJsTest") {
module_out_path = module_output_path
hap_profile = "./config.json"
certificate_profile = "//test/developertest/signature/openharmony_sx.p7b"
}
```
config.json为hap编译所需配置文件,需要开发者根据被测sdk版本配置“target”项,其余项可默认,具体如下所示:
```
{
"app": {
"bundleName": "com.example.myapplication",
"vendor": "example",
"version": {
"code": 1,
"name": "1.0"
},
"apiVersion": {
"compatible": 4,
"target": 5 // 根据被测sdk版本进行修改,此例为sdk5
}
},
"deviceConfig": {},
"module": {
"package": "com.example.myapplication",
"name": ".MyApplication",
"deviceType": [
"phone"
],
"distro": {
"deliveryWithInstall": true,
"moduleName": "entry",
"moduleType": "entry"
},
"abilities": [
{
"skills": [
{
"entities": [
"entity.system.home"
],
"actions": [
"action.system.home"
]
}
],
"name": "com.example.myapplication.MainAbility",
"icon": "$media:icon",
"description": "$string:mainability_description",
"label": "MyApplication",
"type": "page",
"launchType": "standard"
}
],
"js": [
{
"pages": [
"pages/index/index"
],
"name": "default",
"window": {
"designWidth": 720,
"autoDesignWidth": false
}
}
]
}
}
```
6.对目标测试用例文件进行条件分组
```
group("unittest") {
testonly = true
deps = [ ":GetAppInfoJsTest" ]
}
```
> **说明:** 进行条件分组的目的在于执行用例时可以选择性的执行某一种特定类型的用例。
**Fuzz测试**
[Fuzz编译文件编写规范](https://gitee.com/openharmony/test_developertest/blob/master/libs/fuzzlib/README_zh.md)
**Benchmark测试**
[Benchmark编译文件编写规范](https://gitee.com/openharmony/test_developertest/blob/master/libs/benchmark/README_zh.md)
**编译入口配置文件ohos.build**
当完成用例编译配置文件编写后,需要进一步编写部件编译配置文件,以关联到具体的测试用例。
```
"partA": {
"module_list": [
],
"inner_list": [
],
"system_kits": [
],
"test_list": [ //配置模块calculator下的test
"//system/subsystem/partA/calculator/test:unittest",
"//system/subsystem/partA/calculator/test:fuzztest",
"//system/subsystem/partA/calculator/test:benchmarktest"
}
```
> **说明:** test_list中配置的是对应模块的测试用例。
## 测试资源配置
试依赖资源主要包括测试用例在执行过程中需要的图片文件,视频文件、第三方库等对外的文件资源。
依赖资源文件配置步骤如下:
1.在部件的test目录下创建resource目录,在resource目录下创建对应的模块,在模块目录中存放该模块所需要的资源文件
2.在resource目录下对应的模块目录中创建一个ohos_test.xml文件,文件内容格式如下:
```
<?xml version="1.0" encoding="UTF-8"?>
<configuration ver="2.0">
<target name="CalculatorSubTest">
<preparer>
<option name="push" value="test.jpg -> /data/test/resource" src="res"/>
<option name="push" value="libc++.z.so -> /data/test/resource" src="out"/>
</preparer>
</target>
</configuration>
```
3.在测试用例的编译配置文件中定义resource_config_file进行指引,用来指定对应的资源文件ohos_test.xml
```
ohos_unittest("CalculatorSubTest") {
resource_config_file = "//system/subsystem/partA/test/resource/calculator/ohos_test.xml"
}
```
>**说明:**
>- target_name: 测试套的名称,定义在测试目录的BUILD.gn中。preparer: 表示该测试套执行前执行的动作。
>- src="res": 表示测试资源位于test目录下的resource目录下,src="out":表示位于out/release/$(部件)目录下。
## 执行测试用例
### 配置文件
在执行测试用例之前,针对用例使用设备的不同,需要对相应配置进行修改,修改完成即可执行测试用例。
#### user_config.xml配置
```
<user_config>
<build>
<!-- 是否编译demo用例, 默认为false,如果需要编译demo可修改为true -->
<example>false</example>
<!-- 是否编译版本, 默认为false -->
<version>false</version>
<!-- 是否编译测试用例, 默认为true,若已完成编译,再执行用例之前可修改为false,防止重新编译 -->
<testcase>true</testcase>
<!-- 在编译测试用例的情况下,选择编译target_cpu是64位的还是32位的,默认为空(32bit)可以选择: arm64 -->
<parameter>
<target_cpu></target_cpu>
</parameter>
</build>
<environment>
<!-- 配置远程映射机器的IP及端口,以支持HDC连接的设备 -->
<device type="usb-hdc">
<ip></ip>
<port></port>
<sn></sn>
</device>
<!-- 配置设备的串口信息,以支持串口连接的设备 -->
<device type="com" label="ipcamera">
<serial>
<com></com>
<type>cmd</type>
<baud_rate>115200</baud_rate>
<data_bits>8</data_bits>
<stop_bits>1</stop_bits>
<timeout>1</timeout>
</serial>
</device>
</environment>
<!-- 配置测试用例路径,若测试用例未编译,即<testcase>标签属性为true时,此处默认不填写;若编译已完成,需在此处指定测试用例的实际路径 -->
<test_cases>
<dir></dir>
</test_cases>
<!-- 配置覆盖率编译路径 -->
<coverage>
<outpath></outpath>
</coverage>
<!-- NFS挂载信息配置,被测设备仅支持串口连接时配置,指定NFS的映射路径,host_dir为PC侧的NFS目录,board_dir为板侧创建的目录 -->
<NFS>
<host_dir></host_dir>
<mnt_cmd></mnt_cmd>
<board_dir></board_dir>
</NFS>
</user_config>
```
>**说明:** 在执行测试用例之前,若使用HDC连接设备,用例仅需配置设备IP和端口号即可,其余信息均默认不修改。
### 执行命令说明
1. 启动测试框架
```
start.bat
```
2. 选择产品形态
进入测试框架,系统会自动提示您选择产品形态,请根据实际的开发板进行选择。
如需手动添加,请在config/framework_config.xml的\<productform\>标签内增加产品项。
3. 执行测试用例
当选择完产品形态,可参考如下指令执行测试用例。
```
run -t UT -ts CalculatorSubTest -tc interger_sub_00l
```
执行命令参数说明:
```
-t [TESTTYPE]: 指定测试用例类型,有UT,MST,ST,PERF,FUZZ,BENCHMARK等。(必选参数)
-tp [TESTPART]: 指定部件,可独立使用。
-tm [TESTMODULE]: 指定模块,不可独立使用,需结合-tp指定上级部件使用。
-ts [TESTSUITE]: 指定测试套,可独立使用。
-tc [TESTCASE]: 指定测试用例,不可独立使用,需结合-ts指定上级测试套使用。
-h : 帮助命令。
#### Windows环境执行
由于Windows环境下无法实现用例编译,因此执行用例前需要在Linux环境下进行用例编译,用例编译命令:
```
./build.sh --product-name {product_name} --build-target make_test
```
>说明:
>- product-name:指定编译产品名称。
>- build-target:指定所需编译用例,make_test表示指定全部用例,实际开发中可指定特定用例。
编译完成后,测试用例将自动保存在out/ohos-arm-release/packages/phone/tests目录下。
##### 搭建执行环境
1. 在Windows环境创建测试框架目录Test,并在此目录下创建testcase目录
2. 从Linux环境拷贝测试框架developertest和xdevice到创建的Test目录下,拷贝编译好的测试用例到testcase目录下
>**说明:** 将测试框架及测试用例从Linux环境移植到Windows环境,以便后续执行。
3. 修改user_config.xml
```
<build>
<!-- 由于测试用例已编译完成,此标签属性需改为false -->
<testcase>false</testcase>
</build>
<test_cases>
<!-- 由于已将测试用例拷贝到Windows环境下,测试用例输出路径发生改变,需要修改为拷贝后所存放的路径 -->
<dir>D:\Test\testcase\tests</dir>
</test_cases>
```
>**说明:** `<testcase>`标签表示是否需要编译用例;`<dir>`标签表示测试用例查找路径。
#### Linux环境执行
如是直接连接Linux机器,则可直接使用上面的执行命令执行命令
##### 远程端口映射
为支持Linux远程服务器以及Linux虚拟机两种环境下执行测试用例,需要对端口进行远程映射,以实现与设备的数据通路连接。具体操作如下:
1. HDC Server指令:
```
hdc_std kill
hdc_std -m -s 0.0.0.0:8710
```
>**说明:** IP和端口号为默认值。
2. HDC Client指令:
```
hdc_std -s xx.xx.xx.xx:8710 list targets
```
>**说明:** 此处IP填写设备侧IP地址。
## 查看测试结果
### 测试报告日志
当执行完测试指令,控制台会自动生成测试结果,若需要详细测试报告您可在相应的数据文档中进行查找。
### 测试结果
测试结果输出根路径如下:
```
test/developertest/reports/xxxx_xx_xx_xx_xx_xx
```
>**说明:** 测试报告文件目录将自动生成。
该目录中包含以下几类结果:
| 类型 | 描述 |
| ------------------------------------ | ------------------ |
| result/ | 测试用例格式化结果 |
| log/plan_log_xxxx_xx_xx_xx_xx_xx.log | 测试用例日志 |
| summary_report.html | 测试报告汇总 |
| details_report.html | 测试报告详情 |
### 测试框架日志
```
reports/platform_log_xxxx_xx_xx_xx_xx_xx.log
```
### 最新测试报告
```
reports/latest
```
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册