Подсистема тестового набора X (XTS) содержит набор сертификационных тестовых наборов OpenHarmony, включая поддерживаемый в настоящее время набор тестов на совместимость приложений (ACTS) и набор тестов на совместимость устройств (DCTS), который будет поддерживаться в будущем.
Эта подсистема содержит программный пакет acts и tools.
OpenHarmony поддерживает следующие типы систем:
Мини-система Мини-система работает на устройствах с объёмом памяти не менее 128 КиБ и оснащённых микроконтроллерами MCU, такими как ARM Cortex-M и 32-разрядные RISC-V. Эта система предоставляет несколько облегчённых сетевых протоколов и графических фреймворков, а также широкий спектр компонентов чтения/записи для шины IoT. Типичные продукты включают модули подключения, датчики и носимые устройства для умного дома.
Малая система Малая система работает на устройствах с объёмом памяти не менее 1 МиБ и оснащённых прикладными процессорами, такими как ARM Cortex-A. Эта система обеспечивает более высокие возможности безопасности, стандартные графические фреймворки и возможности кодирования и декодирования видео. Типичными продуктами являются интеллектуальные домашние IP-камеры, электронные кошачьи глаза и маршрутизаторы, а также регистраторы событий (EDR) для интеллектуальных путешествий.
Стандартная система Стандартная система работает на устройствах с объёмом памяти не менее 128 МиБ и оснащённых прикладными процессорами, такими как ARM Cortex-A. Эта система предоставляет полный прикладной фреймворк, поддерживающий расширенное взаимодействие, 3D GPU, аппаратный композитор, разнообразные компоненты и богатые анимации. Эта система применяется к дисплеям холодильников высокого класса.
/test/xts
├── acts # Тестовый код
│ └── subsystem # Исходный код тестовых примеров подсистемы для стандартной системы
│ └── subsystem_lite # Исходный код подсистемных тестовых примеров для мини- и малых систем
│ └── BUILD.gn # Конфигурация сборки тестовых примеров для стандартной системы
│ └── build_lite
│ └── BUILD.gn # Конфигурация сборки тестовых примеров для мини- и малых систем
└── tools # Код инструмента тестирования
Тестовые примеры для мини-системы должны быть разработаны на основе C, а для малой системы — на основе C++.
Таблица 1. Уровни тестовых случаев
Уровень | Описание |
---|---|
Базовый | Проверка основных функций системы |
Средний | Проверка расширенных функций системы |
Высокий | Проверка всех функций системы, включая крайние случаи |
Область применения
Уровень 0
Smoke — проверяет основные функции ключевых возможностей и базовые атрибуты DFX с наиболее распространённым вводом. Положительный результат проверки означает, что функции работоспособны.
Уровень 1
Basic — проверяет основные функции ключевых возможностей и базовые атрибуты DFX со стандартным вводом. Положительный результат проверки означает, что функции тестируемы.
Уровень 2
Major — проверяет основные функции ключевых возможностей и базовые атрибуты DFX со стандартным и ошибочным вводом. Положительный результат проверки означает, что функции функциональны и готовы к бета-тестированию.
Уровень 3
Regular — проверяет функции всех ключевых возможностей и все атрибуты DFX при стандартных и нестандартных комбинациях ввода или нормальных и аномальных предустановленных условиях.
Уровень 4
Rare — проверяет функции ключевых возможностей в крайне аномальных предустановках и нестандартных комбинациях ввода. Таблица 2. Масштабы тестирования
Масштаб тестирования | Тестируемые объекты | Среда тестирования |
---|---|---|
LargeTest | Функционал сервисов, все сценарии функций и среда механической мощности (MPE), а также DFX на уровне сценариев. | Устройства, близкие к реальным устройствам. |
MediumTest | Модули, функциональность подсистем после интеграции модулей и DFX. | Одно устройство, которое действительно используется. Можно выполнять симуляцию сообщений, но не следует имитировать функции. |
SmallTest | Модули, классы и функции. | Локальный ПК. Используйте большое количество имитаций для замены зависимостей другими модулями. |
Таблица 3. Типы тестов
Тип | Определение |
---|---|
Function | Проверяет правильность функциональности как сервиса, так и платформы, предоставляемой тестируемым объектом для конечных пользователей или разработчиков. |
Тестирует способность к обработке тестируемого объекта в заданных условиях и при определённой нагрузке. Способность к обработке измеряется объёмом услуг, который может быть обработан за единицу времени, например, количество вызовов в секунду, кадров в секунду или объём обработки событий в секунду.
Мощность
Тестирует энергопотребление тестируемого объекта за определённый период времени в заданных условиях и при определённых нагрузках.
Надёжность
Проверяет производительность сервиса тестируемого объекта при обычных и необычных входных условиях, а также при заданном давлении объёма услуг и длительном непрерывном использовании. Тест включает стабильность, обработку давления, внедрение ошибок и время тестирования Monkey.
Безопасность
Глобальность
Тестирует возможности интернационализации данных и локализации тестируемого объекта, включая многоязычное отображение, различные привычки ввода/вывода, форматы времени и региональные особенности, такие как валюта, время и культурные табу.
Совместимость
Тестирование совместимости программного обеспечения с соответствующим оборудованием.
Пользователь
Тестирует пользовательский опыт объекта в реальных сценариях использования. Все выводы и комментарии должны исходить от пользователей, что в данном случае является субъективной оценкой.
Стандарт
Проверяет соответствие отраслевым стандартам, протоколам и спецификациям компании. Стандарты здесь не включают стандарты безопасности, которые следует классифицировать как тесты безопасности.
Безопасность
Исследует свойство безопасности тестируемого объекта, чтобы избежать возможных угроз личной безопасности, здоровью и самому объекту.
Надёжность
Оценивает надёжность тестируемого объекта, гарантируя, что он может выдержать и поддерживать определённое рабочее состояние (включая понижение), когда подвергается атаке, а также восстанавливаться после атак и адаптироваться к ним для обеспечения выполнения миссии.
Следует выбрать подходящий язык программирования и целевую среду тестирования для разработки тестовых сценариев.
Таблица 4: Среды тестирования и языки тестовых сценариев для различных систем
Система | Среда тестирования | Язык |
---|---|---|
Mini | HCTest | C |
Разработка тестовых случаев для мини-системы
Для поддержки тестовых случаев, разработанных на языке C, используется фреймворк HCTest, который был улучшен и адаптирован на основе открытого исходного кода фреймворка Unity.
Получите доступ к репозиторию test/xts/acts, где будут храниться тестовые случаи.
├── acts
│ └──subsystem_lite
│ │ └── module_hal
│ │ │ └── BUILD.gn
│ │ │ └── src
│ └──build_lite
│ │ └── BUILD.gn
Напишите тестовый случай в каталоге src.
1 Импортируйте заголовочный файл фреймворка теста.
#include "hctest.h"
2 Используйте макрос LITE_TEST_SUIT, чтобы определить имена подсистемы, модуля и набора тестов.
/**
* @brief Регистрирует набор тестов с именем IntTestSuite.
* @param test Имя подсистемы
* @param example Имя модуля
* @param IntTestSuite Имя набора тестов
*/
LITE_TEST_SUIT(test, example, IntTestSuite);
3 Определите Setup и TearDown.
Формат: имя набора тестов + Setup, имя набора тестов + TearDown.
Функции Setup и TearDown должны существовать, но тела функций могут быть пустыми.
4 Используйте макрос LITE_TEST\CASE, чтобы написать тестовый случай.
Участвуют три параметра: имя набора тестов, имя тестового случая и свойства тестового случая (включая тип, детализацию и уровень).
LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1)
{
// Do something
};
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" ]
}
Добавьте параметры сборки в файл BUILD.gn в каталог acts.
Вам нужно добавить тестовый модуль в скрипт test/xts/acts/build_lite/BUILD.gn в каталоге acts.
lite_component("acts") {
...
if(board_name == "liteos_m") {
features += [
...
"//xts/acts/subsystem_lite/module_hal:ActsDemoTest"
]
}
}
Запустите команды сборки.
Наборы тестов создаются вместе с версией сборки. ACTS создаётся вместе с отладочной версией. Тестирование тестовых случаев для мини-системы на основе C (для мини-системы)
Запись образа на плату разработки.
Выполнение теста
Анализ результатов теста Просмотрите журналы последовательного порта, формат которых следующий:
Журнал для каждого набора тестов начинается с «Начать выполнение набора тестов:» и заканчивается «xx Тесты xx Сбои xx Игнорировано».
Разработка и компиляция тестовых случаев на C++ (для стандартных и малых систем) (Примеры стандартной системы см. в каталоге 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"
using namespace std; using namespace testing::ext; class TestSuite: public testing::Test { protected: // Предустановленное действие тестового набора, которое выполняется перед первым тестовым случаем static void SetUpTestCase(void){ } // Очистка тестового набора, которая выполняется после последнего тестового случая static void TearDownTestCase(void){ } // Предустановленное действие тестового случая virtual void SetUp() { } // Действие очистки тестового случая virtual void TearDown() { } };
3. Используйте макрос **HWTEST** или **HWTEST_F** для написания тестового примера.
**HWTEST**: определение общих тестовых примеров, включая название тестового набора, имя тестового примера и аннотацию случая.
**HWTEST_F**: определение тестовых случаев SetUp и TearDown, включая название тестового набора, название тестового примера и свойства тестового примера (включая тип, детализацию и уровень).
Три параметра: название тестового набора, название тестового примера, свойства тестового примера \(включая тип, детализации и уровень\).
HWTEST_F(TestSuite, TestCase_0001, Function | MediumTest | Level1) { // Сделайте что-нибудь }
3. Создайте конфигурационный файл (**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" ]
}
4. Добавьте параметры сборки в файл **BUILD.gn** в каталог **acts**.
Добавьте тестовый модуль в скрипт **test/xts/acts/build_lite/BUILD.gn** каталога **acts**.
lite_component("acts") {
...
else if(board_name == "liteos_a") {
features += [
...
"//xts/acts/subsystem_lite/module_posix:ActsDemoTest"
]
}
}
5. Запустите команды сборки.
Тестовые наборы создаются вместе с версией сборки. ACTS создаётся вместе с отладочной версией.
> **Примечание:**
>ACTS для небольшой системы самостоятельно собирается в исполняемый файл (.bin) и архивируется в каталоге suites\\acts результата сборки. **Выполнение тестовых случаев для небольшой системы**
В настоящее время тестовые случаи совместно используются NFS и монтируются на плату разработки для выполнения.
**Настройка окружения**
1. Используйте сетевой кабель или беспроводную сеть для подключения платы разработки к вашему ПК.
2. Настройте IP-адрес, маску подсети и шлюз для платы разработки. Убедитесь, что плата разработки и ПК находятся в одном сегменте сети.
3. Установите и зарегистрируйте сервер NFS на ПК и запустите службу NFS.
4. Выполните команду mount для платы разработки, чтобы убедиться, что плата разработки может получить доступ к общим файлам NFS на ПК.
Формат: mount *NFS server IP address*:/*NFS shared directory*/*development board directory* nfs
Пример:
```
mount 192.168.1.10:/nfs /nfs nfs
```
**Выполнение тестовых случаев**
Выполните ActsDemoTest.bin, чтобы запустить выполнение тестового случая, и проанализируйте журналы последовательного порта, созданные после завершения выполнения.
### Разработка тестовых случаев на основе JavaScript (для стандартной системы)
Используется фреймворк HJSUnit для поддержки автоматизированного тестирования приложений OpenHarmony, разработанных с использованием языка JavaScript на основе JS-фреймворка приложений.
**Базовый синтаксис тестовых случаев**
Тестовые случаи разрабатываются на языке JavaScript и должны соответствовать спецификациям программирования языка.
Таблица 5
| Синтаксис | Описание | Обязательно |
|:---|:---|:---:|
| beforeAll | Устанавливает действие уровня набора тестов, выполняемое только один раз перед выполнением всех тестовых случаев. Можно передать функцию действия в качестве единственного параметра. | Нет |
| afterAll | Устанавливает действие очистки уровня набора тестов, которое выполняется только один раз после выполнения всех тестовых случаев. Можно передать функцию очистки в качестве единственного параметра.| Нет |
| beforeEach | Устанавливает действие уровня тестового случая. | — | **Выполняется перед каждым тестовым случаем. Количество выполнений равно количеству тестовых случаев, определённых параметром it.**
Можно передать функцию действия в качестве единственного параметра.
**Выполняется после каждого тестового случая. Количество выполнений равно количеству тестовых случаев, определённых параметром it.**
Можно передать функцию очистки в качестве единственного параметра.
**Определяет тестовый набор.** Можно передать два параметра: имя тестового набора и функция тестового набора. Оператор describe поддерживает вложение. В каждом операторе describe можно использовать beforeall, beforeEach, afterEach и afterAll.
**Определяет тестовый случай.** Можно передать три параметра: название тестового случая, параметр фильтра и функция тестового случая.
*Использование параметра фильтра:*
Значение параметра фильтра представляет собой 32-разрядное целое число. Установка разных битов на 1 означает разные конфигурации:
— бит 0: влияет ли параметр фильтра. 1 означает, что тестовый пример используется для функционального теста, а другие настройки параметра не действуют;
— биты 0–10: категории тестовых примеров;
— биты 16–18: тестовые примеры... **Тестовые случаи**
Биты 0–10 указывают на тип теста: FUNCTION (функциональный тест), PERFORMANCE (тест производительности), POWER (тест энергопотребления), RELIABILITY (надёжность), SECURITY (проверка соответствия требованиям безопасности), GLOBAL (целостность), COMPATIBILITY (совместимость), USER (пользовательский тест), STANDARD (стандартный тест), SAFETY (проверка функций безопасности) и RESILIENCE (отказоустойчивость).
Биты 16–18 указывают на масштаб теста: SMALL (небольшой масштаб), MEDIUM (средний масштаб) и LARGE (большой масштаб).
Биты 24–28 указывают уровень теста: LEVEL0 (нулевой уровень), LEVEL1 (первый уровень), LEVEL2 (второй уровень), LEVEL3 (третий уровень) и LEVEL4 (четвёртый уровень).
Используйте стандартный синтаксис Jasmine для написания тестовых случаев. Поддерживается спецификация ES6.
1. Храните тестовые случаи в каталоге **entry/src/main/js/test**, структура которого выглядит следующим образом:
```
├── BUILD.gn
│ └──entry
│ │ └──src
│ │ │ └──main
│ │ │ │ └──js
│ │ │ │ │ └──default
│ │ │ │ │ │ └──pages
│ │ │ │ │ │ │ └──index
│ │ │ │ │ │ │ │ └──index.js # Entry file
│ │ │ │ │ └──test # Тестовый код
│ │ │ └── resources # Ресурсы HAP
│ │ │ └── config.json # Файл конфигурации HAP
```
2. Запустите тестовый фреймворк JS и загрузите тестовые примеры. Ниже приведён пример для **index.js**.
```
// Запускаем тестовый фреймворк JS и загружаем тестовые примеры.
import {Core, ExpectExtend} from 'deccjsunit/index'
export default {
data: {
title: ""
},
onInit() {
this.title = this.$t('strings.world');
},
onShow() {
console.info('onShow finish')
const core = Core.getInstance()
const expectExtend = new ExpectExtend({
'id': 'extend'
})
core.addService('expect', expectExtend)
core.init()
const configService = core.getDefaultService('config')
configService.setConfig(this)
require('../../../test/List.test')
core.execute()
},
onReady() {
}
}
```
3. Напишите модульный тест, используя следующий пример:
```
// Используйте 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')
})
})
```
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Комментарии ( 0 )