Слияние кода завершено, страница обновится автоматически
XTS子系统
Введение
Тип системы
Каталог
Ограничения
Инструкция по использованию
Руководство по разработке сценариев использования
Связанные репозитории
XTS — это набор сертифицированных тестовых комплектов для экосистемы OpenHarmony. В настоящее время он включает в себя ACTS (Application Compatibility Test Suite) — набор тестов на совместимость приложений, который впоследствии будет расширен за счёт DCTS (Distributed Compatibility Test Suite), набора тестов на распределённую совместимость, и HATS (Hardware Abstract Test Suite), набора тестов абстрактного уровня совместимости оборудования.
В настоящее время XTS включает в себя следующие компоненты:
OpenHarmony поддерживает следующие типы систем:
Предназначена для процессоров класса MCU, таких как Arm Cortex-M и RISC-V 32-бит. Ресурсы ограничены, минимальная поддерживаемая память устройства составляет 128 КБ, поддерживает различные лёгкие сетевые протоколы, лёгкую графическую структуру и богатый набор компонентов для IOT-шин. Подходит для таких продуктов, как модули подключения для умного дома, датчики и носимые устройства.
Предназначена для прикладных процессоров, таких как Arm Cortex-A. Поддерживает минимальную память устройства 1 МБ, обеспечивает более высокий уровень безопасности, стандартную графическую структуру, видеокодирование и декодирование для мультимедийных возможностей. Подходит для таких продуктов, как IP-камеры для умного дома, электронные кошачьи глаза, маршрутизаторы и регистраторы поездок для интеллектуальных транспортных средств.
Также предназначена для прикладных процессоров, таких как Arm Cortex-A. Поддерживает минимальную память устройства 128 МБ, предоставляет расширенные возможности взаимодействия, 3D GPU и аппаратное синтезирование, а также более богатые элементы управления и анимационные эффекты для графической структуры. Подходит для таких продуктов, как холодильники с дисплеями высокого класса.
/test/xts
├── acts # Исходный код тестов
│ └── subsystem # Подсистема для стандартных систем
│ └── subsystem_lite # Подсистема для лёгких и малых систем
│ └── BUILD.gn # Конфигурация сборки для стандартных систем
│ └── build_lite # Конфигурация сборки для лёгких и малых систем
│ └── BUILD.gn # Конфигурация сборки для лёгких и малых систем
└── tools # Исходный код инструментов
Язык разработки сценариев использования для лёгких систем — C, для малых и стандартных систем — C++.
Таблица 1. Уровни сценариев использования.
| Уровень | Определение | Область тестирования |
|---|---|---|
| Level0 | Дымовой тест | Проверка основных функций и ключевых точек на наиболее распространённых входных данных, чтобы убедиться, что функции работают корректно. |
| Level1 | Базовый | Проверка всех основных функций на обычных входных данных, чтобы подтвердить возможность тестирования функций. |
| Тестовый тип | Определение тестового типа |
|---|---|
| Function | Проверка правильности реализации бизнес-функций, которые предоставляются пользователю (которым может быть конечный пользователь или разработчик). Бизнес-функции включают в себя как бизнес-функциональность, так и функциональность платформы. |
| Performance | Проверка способности тестируемого объекта обрабатывать нагрузку в определённых условиях. Способность к обработке обычно измеряется количеством операций, выполняемых за единицу времени, таких как звонки в секунду, частота кадров в секунду или количество обрабатываемых событий в секунду. |
| Power | Проверка энергопотребления тестируемого объекта при определённой нагрузке в течение определённого периода времени. |
| Reliability | Проверка поведения тестируемого объекта в нормальных и аномальных условиях ввода данных, а также при высоких нагрузках и длительном непрерывном использовании. Включает тестирование на стабильность, нагрузочное тестирование, тестирование на отказоустойчивость и Monkey-тестирование. |
| Security | Проверка защиты системы от злонамеренных угроз, включая несанкционированный доступ, использование, утечку, повреждение, модификацию и уничтожение данных. Также включает проверку соблюдения различных стандартов безопасности, таких как стандарты проектирования безопасности, красные линии безопасности и стандарты сертификации безопасности. |
| Global | Проверка наличия поддержки международных данных и локализации в тестируемом объекте. Включает проверку языкового отображения, привычек ввода/вывода, отображения времени и региональных особенностей, таких как валюта и часовые пояса. |
| Compatibility | Проверка совместимости тестируемого объекта с различными средами и устройствами. Тестирование программного обеспечения |
В зависимости от того, что именно тестируется (объект тестирования), выделяют следующие виды тестирования:
Тестирование приложения включает в себя проверку на обратную совместимость объекта тестирования с его собственными данными, на совместимость с системой и различными пользовательскими данными.
При тестировании системы проверяется обратная совместимость системы с её собственными данными и совместимость с часто используемыми приложениями в экосистеме.
Если объектом тестирования является программное обеспечение, то проверяется его совместимость с соответствующим оборудованием.
Также выделяют следующие типы тестирования:
Пример разработки тестового случая для облегчённой системы
В настоящее время используется тестовая среда hctest. Она основана на открытом исходном коде Unity и была расширена и адаптирована для использования с C.
Структура каталогов тестовых примеров: тестовые примеры хранятся в каталоге test/xts/acts.
├── acts
│ └──subsystem_lite
│ │ └── module_hal
│ │ │ └── BUILD.gn
│ │ │ └── src
│ └──build_lite
│ │ └── BUILD.gn
Написание тестовых примеров в каталоге src:
2.1. Импортируйте заголовочный файл hctest.h:
```
#include "hctest.h"
```
2.2. Используйте макрос LITE_TEST_SUIT для определения имени подсистемы, модуля и набора тестов:
```
/**
* @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);
```
2.3. Определите функции Setup и TearDown:
Названия функций должны соответствовать шаблону: имя набора тестов + Setup или TearDown. Эти функции должны существовать, но могут быть пустыми.
2.4. Используйте макрос LITE_TEST_CASE для создания тестовых примеров:
Включает три параметра: имя набора тестов, имя тестового примера и атрибуты теста (тип теста, детализация теста и уровень теста).
```
LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1)
{
//do something
};
```
2.5. Используйте макрос RUN_TEST_SUITE для регистрации набора тестов:
```
RUN_TEST_SUITE(IntTestSuite);
```
Конфигурация тестового модуля в файле BUILD.gn:
Создайте новый файл 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" ]
}
Добавление параметров компиляции в файл acts/BUILD.gn:
Добавьте тестовый модуль в файл сборки acts/build_lite/BUILD.gn.
lite_component("acts") {
...
if(board_name == "liteos_m") {
features += [
...
"//xts/acts/subsystem_lite/module_hal:ActsDemoTest"
]
}
}
Команды компиляции тестовых наборов:
Существует два способа компиляции:
Способ 1:
./test/xts/tools/lite/build.sh product=wifiiot xts=acts
Способ 2:
hb set
选择 设备类型
hb build --gn-args build_xts=true
(注)：若不追加--gn-args build_xts=true，不会编译acts测试套件。
Примечание: во время компиляции тестового набора acts промежуточный результат представляет собой статическую библиотеку, которая в конечном итоге связывается с зеркальным изображением версии.
После того как зеркальное изображение версии будет записано на целевую плату разработки, выполните следующие шаги для выполнения тестовых примеров.
Анализ результатов тестирования основан на журнале последовательного вывода. Каждый набор тестов начинается с «Start to run test suite» и заканчивается «xx Tests xx Failures xx Ignored».
Пример разработки тестовых примеров для небольшой системы (см. конкретный пример каталога global/i18n_standard для стандартной системы):
Текущая используемая тестовая структура — hcpptest, основанная на открытом исходном коде googletest.
Структура каталогов тестовых примеров соответствует стандарту: тестовые примеры сохраняются в каталоге test/xts/acts.
├── acts
│ └──subsystem_lite
│ │ └── module_posix
│ │ │ └── BUILD.gn
│ │ │ └── src
│ └──build_lite
│ │ └── BUILD.gn
Написание тестовых примеров в каталоге src:
#include "gtest/gtest.h"
Необходимо определить функцию SetUpTestCase() для предварительной настройки тестового комплекта и функцию TearDownTestCase() для очистки после последнего тестового примера. Также необходимо определить функции SetUp() и TearDown() для каждого тестового примера.
Пример:
using namespace std;
using namespace testing::ext;
class TestSuite: public testing::Test {
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()
{
}
};
Определение обычного тестового примера: HWTEST (имя набора тестов, имя тестового примера, атрибут теста). Определение тестовых случаев, содержащих SetUp и TearDown, для тестирования HWTEST_F (тестовый набор, тестовый случай, метка случая)
Макроопределение включает три параметра: название тестового набора, название тестового случая, атрибут случая (тип теста, уровень детализации, уровень случая).
HWTEST_F(TestSuite, TestCase_0001, Function | MediumTest | Level1) {
// do something
}
Пример конфигурации файла тестового модуля в BUILD.gn
В каждом каталоге тестового модуля создаётся файл компиляции BUILD.gn для указания имени исполняемого файла после компиляции, зависимых заголовочных файлов и библиотек; каждый тестовый модуль компилируется отдельно в исполняемый файл .bin, который можно напрямую загрузить на одноплатный компьютер для тестирования.
Пример:
import("//test/xts/tools/lite/build/suite_lite.gni")
hcpptest_suite("ActsDemoTest") {
suite_name = "acts"
sources = [
"src/TestDemo.cpp"
]
include_dirs = [
"src",
...
]
deps = [
...
]
cflags = [ "-Wno-error" ]
}
Добавление параметров компиляции в каталог acts
Тестовый модуль добавляется в скрипт компиляции каталога acts, скрипт компиляции: test/xts/acts/build_lite/BUILD.gn.
lite_component("acts") {
...
else if(board_name == "liteos_a") {
features += [
...
"//xts/acts/subsystem_lite/module_posix:ActsDemoTest"
]
}
}
Команды компиляции тестового набора — два способа компиляции
L1_LiteOS:
Способ 1:
python3 build.py -p ipcamera_hispark_taurus@hisilicon --gn-args build_xts=true
Способ 2:
hb set
Выбор устройства
hb build --gn-args build_xts=true
(Примечание): если не добавить --gn-args build_xts=true, тестовый набор acts не будет скомпилирован.
L1_Linux:
Способ 1:
python3 build.py -p ipcamera_hispark_taurus_linux@hisilicon --gn-args build_xts=true
Способ 2:
hb set
Выбор устройства
hb build --gn-args build_xts=true
(Примечание): если не добавить --gn-args build_xts=true, тестовый набор acts не будет скомпилирован.
Примечание: малые системы acts компилируются отдельно в исполняемые файлы (формат bin), которые архивируются в каталоге suites\acts после компиляции.
Пример выполнения тестовых случаев для малой системы
Текущее выполнение тестовых случаев использует общий доступ NFS, монтируемый на одноплатную систему для выполнения.
Настройка среды
Формат: mount \[IP-адрес сервера NFS\]:\[/каталог общего доступа NFS\] \[/каталог платы разработки\] nfs
Например:
mount 192.168.1.10:/nfs /nfs nfs
Выполнение тестовых случаев
Запуск тестового набора ActsDemoTest.bin запускает выполнение тестовых случаев. Анализ выполняется на основе данных, выводимых через последовательный порт.
Текущая используемая среда тестирования — HJSUnit, которая поддерживает автоматизированное тестирование приложений OpenHarmony, особенно тех, которые разработаны на основе JavaScript и используют фреймворк JavaScript для приложений.
Основы синтаксиса написания тестовых случаев
Тестовые случаи написаны на языке JavaScript и должны соответствовать стандартам программирования JavaScript:
Таблица 5
| Тестовый синтаксис | Описание | Требования |
|---|---|---|
| beforeAll | Условие установки перед всеми тестовыми случаями на уровне тестового набора. Выполняется один раз перед началом всех тестовых случаев и может принимать функцию предварительного действия в качестве параметра. | Необязательно |
| afterAll | Условие очистки после завершения всех тестовых случаев на уровне тестового набора. Выполняется один раз после завершения всех тестовых случаев и может принимать функцию очистки в качестве параметра. | Необязательно |
Предварительное условие, которое выполняется перед всеми тестами в наборе.
beforeEach
Условие предварительного тестирования, выполняемое перед каждым тестом. Количество выполнений соответствует количеству определённых тестов it. Поддерживает один параметр: функцию предварительного действия.
afterEach
Условия очистки после тестирования, которые выполняются после каждого теста. Количество исполнений соответствует количеству определённых тестов it. Поддерживает один параметр: функция очищающего действия.
describe
Определяет набор тестов. Поддерживает два параметра: название набора тестов и функция набора тестов. В describe можно вкладывать другие блоки, такие как beforeAll, beforeEach, afterEach и afterAll.
it
Описывает отдельный тест. Поддерживает три параметра: имя теста, параметры фильтрации и тестовая функция. Обязательно
Используется стандартная грамматика Jasmine, формат поддерживает ES6.
Пример использования режима FA:
Структура каталога тестовых случаев соответствует стандартам: тестовые случаи хранятся в каталоге src/main/js/test.
├── BUILD.gn
├── Test.json # файл ресурсов hap не требует Test.json
├── signature
│ └──openharmony_sx.p7b # инструмент подписи
└──src
│ └──main
│ │ └──js
│ │ │ └──MainAbility
│ │ │ │ └──app.js
│ │ │ │ └──pages
│ │ │ │ │ └──index
│ │ │ │ │ │ └──index.js
│ │ │ └──test # каталог хранения тестового кода
│ │ │ │ │ └──List.test.js
│ │ │ │ │ └──Ability.test.js
│ │ │ └──TestAbility # шаблон файла входа в тестовую среду, после добавления не требуется модификация
│ │ │ │ └──app.js
│ │ │ │ └──pages
│ │ │ │ │ └──index
│ │ │ │ │ │ └──index.js
│ │ │ └──TestRunner # шаблон файла входа в тестовую среду, после добавления не требуется модификация
│ │ │ │ └──OpenHarmonyTestRunner.js
│ └── resources # каталог ресурсов hap
│ └── config.json # файл конфигурации hap
Пример OpenHarmonyTestRunner.js:
//импорт js тестовой среды
import AbilityDelegatorRegistry from '@ohos.application.abilityDelegatorRegistry'
...
export default {
...
onRun() {
console.log('OpenHarmonyTestRunner onRun run')
var abilityDelegatorArguments = AbilityDelegatorRegistry.getArguments()
var abilityDelegator = AbilityDelegatorRegistry.getAbilityDelegator()
var testAbilityName = abilityDelegatorArguments.parameters['-p'] + '.MainAbility'
var cmd = 'aa start -d 0 -a ' + testAbilityName + ' -b ' + abilityDelegatorArguments.bundleName
...
}
};
Пример index.js:
export default {
...
onShow() {
console.info('onShow finish!')
},
...
}
Пример app.js:
//загрузка тестовых примеров
import { Hypium } from '@ohos/hypium'
import testsuite from '../test/List.test'
export default {
onCreate() {
console.info('TestApplication onCreate');
var abilityDelegator = AbilityDelegatorRegistry.getAbilityDelegator()
var abilityDelegatorArguments = AbilityDelegatorRegistry.getArguments()
console.info('start run testcase!!!')
Hypium.hypiumTest(abilityDelegator, abilityDelegatorArguments, testsuite)
},
...
};
Пример модульного теста:
// Example1: использование HJSUnit для модульного тестирования
describe('appInfoTest', function () {
it('app_info_test_001', 0, function () {
var info = app.getInfo()
expect(info.versionName).assertEqual('1.0')
expect(info.versionCode).assertEqual('3')
})
})
Пример конфигурации тестового модуля в режиме FA_JS (BUILD.gn):
import("//test/xts/tools/build/suite.gni")
ohos_js_hap_suite("ActsDemoTest") {
hap_profile = "./src/main/config.json"
deps = [
":hjs_demo_js_assets",
":hjs_demo_resources",
]
certificate_profile = "./signature/openharmony_sx.p7b" //файл подписи
hap_name = "ActsDemoTest" //тестовый комплект, начинается с Acts и заканчивается на Test, используется верблюжий регистр
part_name = "..." //компонент
subsystem_name = "..." //подсистема
}
ohos_js_assets("hjs_demo_js_assets") {
js2abc = true
hap_profile = "./src/main/config.json"
source_dir = "./src/main/js"
}
ohos_resources("hjs_demo_resources") {
sources = [ "./src/main/resources" ]
hap_profile = "./src/main/config.json"
}
Пример конфигурации тестового модуля в режиме FA_TS (BUILD.gn):
import("//test/xts/tools/build/suite.gni")
ohos_js_hap_suite("ActsDemoTest") {
hap_profile = "./src/main/config.json"
deps = [
":ace_demo_ets_assets",
":ace_demo_ets_resources",
":ace_demo_ets_test_assets",
]
ets2abc = true
certificate_profile = "./signature/openharmony_sx.p7b" //файл подписи
hap_name = "ActsDemoTest" //тестовый комплект, начинается с Acts и заканчивается на Test, используется верблюжий регистр
part_name = "..." //компонент
subsystem_name = "..." //подсистема
} **ohos_js_assets("ace_demo_ets_assets")**
source_dir = "./src/main/ets/MainAbility"
**ohos_js_assets("ace_demo_ets_test_assets")**
source_dir = "./src/main/ets/TestAbility"
**ohos_resources("ace_demo_ets_resources")**
sources = [ "./src/main/resources" ]
hap_profile = "./src/main/config.json"
*FA_JS 模式适配指导请参考*
[JS工程目录结构（FA模型）](https://gitee.com/openharmony/xts_acts/wikis/XTS_%E7%99%BE%E7%A7%91%E6%8C%87%E5%AF%BC/JS%E5%B7%A5%E7%A8%8B%E7%9B%AE%E5%BD%95%E7%BB%93%E6%9E%84%EF%BC%88FA%E6%A8%A1%E5%9E%8B%EF%BC%89)
*FA_TS 模式适配指导请参考*
[eTS工程目录结构（FA模型）](https://gitee.com/openharmony/xts_acts/wikis/XTS_%E7%99%BE%E7%A7%91%E6%8C%87%E5%AF%BD/eTS%E5%B7%A5%E7%A8%8B%E7%9B%AE%E5%BD%95%E7%BB%93%E6%9E%84%EF%BC%88FA%E6%A8%A1%E5%9E%8B%EF%BC%89)
**以Stage 模式为例:**
1. 规范用例目录：测试用例存储到 src/main/js/test目录。
├── BUILD.gn # 配置文件
├── Test.json # 资源依赖hap不需要Test.json文件
├── signature
│ └──openharmony_sx.p7b # 签名工具
├── AppScope
│ └──resource
│ └──app.json
├── entry
│ └──src
│ │ └──main
│ │ │ └──ets
│ │ │ └──test # 测试代码存放目录
│ │ │ ├── List.test.ets
│ │ │ └── Ability.test.ets
│ │ │ └── MainAbility
│ │ │ ├── MainAbility.ts
│ │ │ └── pages
│ │ │ └── index
│ │ │ └── index.ets
│ │ │ └── TestAbility
│ │ │ ├── TestAbility.ts # 测试用例启动入口 ability
│ │ │ └── pages
│ │ │ └── index.ets
│ │ │ └── Application
│ │ │ ├── AbilityStage.ts
│ │ │ └── TestRunner # 测试框架入口模板文件，添加后无需修改
│ │ │ └── OpenHarmonyTestRunner.js
│ │ └── resources # hap资源存放目录
│ │ └── module.json # hap配置文件
2. OpenHarmonyTestRunner.ts 示例
【注】在TestRunner目录下的 OpenHarmonyTestRunner.ts 文件中的 async onRun() 方法下存在拉起测试套入口xxxAbility的cmd 命令：
例如：
var cmd = 'aa start -d 0 -a TestAbility' + ' -b ' + abilityDelegatorArguments.bundleName
需与module.json中 "abilities" 下的 "name" 字段保持一致，保证拉起的是我们需要的测试入口。
import TestRunner from '@ohos.application.testRunner' import AbilityDelegatorRegistry from '@ohos.application.abilityDelegatorRegistry'
...
export default class OpenHarmonyTestRunner implements TestRunner { ... async onRun() { console.log('OpenHarmonyTestRunner onRun run') abilityDelegatorArguments = AbilityDelegatorRegistry.getArguments() abilityDelegator = AbilityDelegatorRegistry.getAbilityDelegator() var testAbilityName = abilityDelegatorArguments.bundleName + '.TestAbility' let lMonitor = { abilityName: testAbilityName, onAbilityCreate: onAbilityCreateCallback, }; abilityDelegator.addAbilityMonitor(lMonitor, addAbilityMonitorCallback) var cmd = 'aa start -d 0 -a TestAbility' + ' -b ' + abilityDelegatorArguments.bundleName ... } };
3. index.ets示例
import router from '@ohos.router';
@Entry @Component struct Index {
aboutToAppear(){ console.info("start run testcase!!!!") }
build() { ... } }
4. app.js示例
//加载测试用例 import Ability from '@ohos.app.ability.UIAbility' import AbilityDelegatorRegistry from '@ohos.application.abilityDelegatorRegistry' import { Hypium } from '@ohos/hypium' import testsuite from '../test/List.test'
export default class TestAbility extends Ability { onCreate(want, launchParam) { console.log('TestAbility onCreate') var abilityDelegator: any abilityDelegator = AbilityDelegatorRegistry.getAbilityDelegator() var abilityDelegatorArguments: any abilityDelegatorArguments = AbilityDelegatorRegistry.getArguments() console.info('start run testcase!!!') Hypium.hypiumTest(abilityDelegator, abilityDelegatorArguments, testsuite) }
from devicetest.core.test_case import Step from devicetest.core.suite.test_suite import TestSuite
class TestSuite(TestSuite): def setup(self): Step("Setup")
def teardown(self):
Step("Teardown")
**Интерфейс**
| Интерфейс | Параметр | Значение | Описание |
| --- | --- | --- | --- |
| execute_shell_command(command, timeout) | command: обязательно, строка команды оболочки <br> timeout: необязательно, время ожидания выполнения команды в миллисекундах, при превышении времени ожидания возникает исключение | вывод команды оболочки | выполнение команды оболочки |
| reboot() | — | — | перезагрузка устройства |
| install_package(package_path) | package_path: обязательно, путь к пакету приложения | вывод команды установки пакета | установка приложения |
| uninstall_package(package_name) | package_name: обязательно, имя пакета приложения | вывод команды удаления пакета | удаление приложения |
| pull_file(remote, local) | remote: обязательно, путь файла на устройстве <br> local: обязательно, локальный путь файла | — | загрузка файла с устройства на локальный компьютер |
| push_file(local, remote) | local: обязательно, локальный путь файла <br> remote: обязательно, путь файла на устройстве | — | отправка файла с локального компьютера на устройство |
*Примечание: интерфейсы, начинающиеся с install*, *push* и т. д., требуют размещения локальных файлов в каталоге resource и использования функции get_resource_path() для получения пути к файлу.*
**Компиляция**
Файл конфигурации BUILD.gn в основном копирует файлы тестовых случаев py и json в выходной каталог xts. Пример файла конфигурации (на примере режима тестового случая):
// BUILD.gn
import("//build/ohos.gni")
group("ActsDemoTest") { testonly = true deps = [ ":PyTestCase" ] } ohos_copy("PyTestCase") { subsystem_name = "..." part_name = "..." sources = [ "./TestCase.json", "./testcase1.py", ] outputs = [ root_out_dir + "/suites/acts/acts/testcases/{{source_file_part}}" ] }
**Выполнение Python-скриптов**
Режим тестового примера:
``` run -l TestCase ```
Режим набора тестов:
Полное выполнение: ``` run -l TestSuite ```
Частичное выполнение: ``` run -l TestSuite -ta class:testcase1,testcase3 ```
Исключение частичного выполнения: ``` run -l TestSuite -ta notClass:testcase1,testcase3 ```
**Полная компиляция (для стандартной системы)**
1. Полная компиляция: выполните команду компиляции в каталоге test/xts/acts:
./build.sh product_name=rk3568 system_size=standard
2. Компиляция отдельного подсистемы: выполните команду компиляции в каталоге test/xts/acts:
./build.sh product_name=rk3568 system_size=standard target_subsystem=××××
3. Компиляция одного модуля: выполните команду компиляции в каталоге test/xts/acts:
```./build.sh suite=acts system_size=standard target_subsystem=××××```
или
```./build.sh product_name=rk3568 system_size=standard suite=xxx```
suite после этого добавляется в шаблон ohos_js_hap_suite в файле BUILD.gn.
Выходной каталог тестовых примеров: out/rk3568/suites/acts/testcases
Общий выходной каталог тестов и фреймворка: out/rk3568/suites/acts (при компиляции тестовых наборов также будет скомпилирован исполняемый файл фреймворка).
**Полное выполнение тестовых примеров (подходит для небольших систем и стандартных систем)**
Установите Python версии 3.7 или выше на рабочей станции Windows и убедитесь, что рабочая станция и тестируемое устройство подключены нормально.
*Обратите внимание: в более новых версиях Python нет easy_install, можно установить версию setuptools ниже 52.0.0 для решения этой проблемы.*
```pip install setuptools==50.0.0```
Каталог выполнения тестов (соответствует сгенерированному каталогу out/release/suites/acts):
| Каталог | Назначение |
| :-- |:-- |
| testcase | Файлы тестовых наборов |
| xxx.hap | Исполняемые файлы тестовых наборов |
| xxx.json | Конфигурационные файлы для выполнения тестовых наборов |
| tools | Каталог инструментов тестового фреймворка |
| run.bat | Файл запуска тестового набора в Windows |
| report | Каталог отчётов о тестах |
Выполнение тестов:
1. Найдите каталог тестовых наборов, скопированный с сервера Linux, в рабочей среде Windows и перейдите в соответствующий каталог в командной строке Windows. Выполните acts\run.bat.
2. После запуска интерфейса введите команду выполнения теста.
Полное выполнение: ```run acts```
Выполнение модуля (конкретный модуль можно посмотреть в \acts\testcases\): ```run –l ActsSamgrTest```
Выполнение одного пакета (подходит для OH-драйвера):
```run -l uitestActs -ta class:UiTestCase#testChecked```
uitestActs: тестовый набор hap
UiTestCase: тестовый набор
testChecked: тестовый пример
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )