XTS子系统

Введение

XTS子系统 — это набор комплектов для тестирования на соответствие экосистеме OpenHarmony. В настоящее время он включает в себя комплект тестов на совместимость приложений (acts), который будет расширен комплектом тестов на совместимость устройств (dcts) в будущем.

В настоящее время XTS включает в себя acts и tools:

• acts — содержит исходный код и файлы конфигурации для тестов на совместимость с acts. Его цель — помочь производителям терминального оборудования как можно раньше обнаружить несовместимость программного обеспечения с OpenHarmony и обеспечить соответствие программного обеспечения требованиям совместимости OpenHarmony на протяжении всего процесса разработки.
• tools — содержит среду разработки для тестов на совместимость acts.

Типы систем

OpenHarmony поддерживает следующие типы систем:

• Лёгкая система (mini system) — ориентирована на процессоры класса MCU, такие как Arm Cortex-M и RISC-V 32-битные. Ресурсы оборудования крайне ограничены, а минимальная поддерживаемая память составляет 128 КБ. Поддерживает различные лёгкие сетевые протоколы, лёгкие графические фреймворки и богатый набор компонентов для подключения к шинам IOT. Подходит для таких продуктов, как модули подключения для умного дома, сенсорные устройства и носимые устройства.
• Малая система (small system) — ориентирована на прикладные процессоры, такие как Arm Cortex-A. Минимальная поддерживаемая память составляет 1 МБ. Обеспечивает более высокий уровень безопасности, стандартные графические фреймворки, возможности кодирования и декодирования видео для мультимедийных приложений. Подходит для таких продуктов, как IP-камеры для умного дома, электронные кошачьи глаза, маршрутизаторы и регистраторы поездок для интеллектуальных транспортных средств.
• Стандартная система (standard system) — ориентирована на прикладные процессоры, такие как Arm Cortex-A. Минимальная поддерживаемая память составляет 128 МБ. Предоставляет расширенные возможности взаимодействия, 3D GPU и аппаратное синтезирование, больше элементов управления и более богатые графические эффекты, а также полную прикладную структуру. Подходит для таких продуктов, как холодильники с дисплеями высокого класса.

Структура каталогов

/test/xts
├── acts                # Тестовый код
│   └── subsystem       # Подсистема стандартной системы
│   └── subsystem_lite  # Подсистемы лёгкой и малой систем
│   └── BUILD.gn        # Конфигурация компиляции для стандартной системы
│   └── build_lite      # Конфигурация компиляции для лёгкой и малой систем
│       └── BUILD.gn    # Конфигурация компиляции
└── tools               # Код инструментов

Ограничения

Язык разработки для лёгких систем — C, для малых систем — C++.

Использование

Таблица 1. Уровни тестов

Примечание: оригинальный текст не содержит ошибок. В запросе текст технической направленности из области разработки и тестирования программного обеспечения. Основной язык текста запроса — китайский.

В среде разработчика для личного использования проводится тестирование, по возможности не зависящее от других модулей, с большим количеством MOCK.

Таблица 3. Типы тестирования

HJSUnit, hcpptest.

Руководство по разработке и компиляции примеров использования C для лёгковесных систем (подходит для разработки сценариев использования лёгких продуктов)

Пример: разработка сценария использования теста для легковесной системы

В настоящее время используется тестовая среда hctest, которая поддерживает разработку тестов на языке C. Она основана на открытой тестовой среде Unity.

1. Каталог структуры каталогов примеров: примеры тестов хранятся в папке test/xts/acts.

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

2. Написание примеров в каталоге src.

   2.1. Ссылка на тестовую среду:

   #include "hctest.h"

   2.2. Использование макроопределения LITE_TEST_SUIT для определения имени подсистемы, модуля и набора тестов.

   LITE_TEST_SUIT(test, example, IntTestSuite);

   2.3. Определение Setup и TearDown.

   Имена: имя набора тестов + 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);

3. Файл конфигурации модуля тестирования (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" ] }

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"
        ]
    }
}

5. Команда компиляции набора тестов:

При компиляции версии промежуточное звено набора тестов acts будет скомпилировано в статическую библиотеку, а затем связано с зеркальным изображением версии.

Примечание: Промежуточное звено набора тестов acts при компиляции — это статическая библиотека, которая в конечном итоге связана с зеркальным отображением версии.

Инструкции по выполнению тестов на C (подходят для разработки сценариев использования лёгковесных систем)

Поместите зеркальное отображение версии на целевую плату разработки, а затем войдите в систему с помощью последовательного порта и сохраните информацию о последовательном порту. Перезагрузите устройство и просмотрите журнал последовательного порта.

Анализ результатов теста:

Каждый набор тестов начинается с «Start to run test suite» и заканчивается «xx Tests xx Failures xx Ignored».

Инструкция по разработке и компиляции тестов на C++ (подходит для небольших систем и стандартных систем)

Пример: Разработка тестов для небольшой системы (стандартные системы см. конкретный каталог образцов: global/i18n_standard).

Текущая используемая тестовая среда — hcpptest, основанная на открытом тестовом фреймворке googletest.

1. Структура каталога примеров: тестовые примеры хранятся в папке test/xts/acts.

   ├── acts
   │ └──subsystem_lite
   │ │ └── module_posix
   │ │ │ └── BUILD.gn
   │ │ │ └── src
   │ └──build_lite
   │ │ └── BUILD.gn

2. Примеры в src:

   2.1. Ссылка на тестовый фреймворк:

   Необходимо включить gtest.h, например: #include «gtest/gtest.h».

   #include "gtest/gtest.h"

   2.2. Определите 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() { } };

   2.3. Используйте HWTEST или HWTEST_F для написания тестовых примеров.

Обычное определение тестового примера: HWTEST (имя набора тестов, имя тестового примера, примечание к примеру).

Определение тестового примера с SetUp и TearDown: HWTEST_F (имя набора тестов, имя тестового примера, примечания к примеру).

Макроопределение включает три параметра: имя набора тестов, имя тестового примера и атрибуты тестового примера (тип теста, детализация теста, уровень теста).

HWTEST_F(TestSuite, TestCase_0001, Function | MediumTest | Level1) {
// do something
}

3. Конфигурационный файл тестового примера в модуле (BUILD.gn):

Атрибуты файла конфигурации тестового примера включают имя набора тестов и имя тестового примера. afterEach

Условие очистки на уровне тестовых случаев, выполняется после завершения каждого тестового случая. Количество выполнений соответствует количеству определённых тестовых случаев в it. Поддерживает один параметр: функция действия очистки.

describe

Определяет тестовый набор. Поддерживает два параметра: имя тестового набора и функция тестового набора. describe поддерживает вложение, и каждый describe может определять beforeAll, beforeEach, afterEach и afterAll.

it

Описывает один тестовый случай. Поддерживает три параметра: название случая, параметры фильтрации и функция случая.

Примечание:

Параметры фильтрации: 32-битный параметр типа Int, где 0 бит означает отсутствие фильтрации, а по умолчанию выполняется; 0–10 бит означают тип тестового примера; 16–18 бит — масштаб тестового примера; 24–28 бит — уровень теста.

Типы тестовых примеров: — 0–1 бит: FUNCTION — тестирование метода класса; — 2–3 бита: PERFORMANCE — тестирование производительности; — 4–5 бит: POWER — тестирование энергопотребления; — 6–7 бит: RELIABILITY — надёжное тестирование; — 8–9 бит: SECURITY — тестирование безопасности; — 10–11 бит: GLOBAL — интеграционное тестирование; — 12–13 бит: COMPATIBILITY — тестирование совместимости; — 14–15 бит: USER — пользовательское тестирование; — 16–17 бит: STANDARD — стандартное тестирование; — 18–19 бит: SAFETY — тестирование характеристик безопасности; — 20–21 бит: RESILIENCE — нагрузочное тестирование.

Масштаб тестовых примеров: — 16 бит: SMALL — небольшой тест; — 17 бит: MEDIUM — средний тест; — 18 бит: LARGE — большой тест.

Уровень тестов: — 24 бит: LEVEL0-0 — нулевой уровень тестирования; — 25–26 бит: LEVEL1-1 — первый уровень тестирования; — 27–28 бит: LEVEL2-2 — второй уровень тестирования; — 29–30 бит: LEVEL3-3 — третий уровень тестирования; — 31–32 бит: LEVEL4-4 — четвёртый уровень тестирования. ``` 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. Пример юнит-теста:

// 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') }) })

### Компиляция и упаковка кода на JS (для стандартных систем)

Для компиляции пакета hap см. [Руководство по разработке приложений на JS для стандартных систем](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/build_overview-0000001055075201).

## Связанные репозитории:
* [xts_acts](https://gitee.com/openharmony/xts_acts)
* [xts_tools](https://gitee.com/openharmony/xts_tools)