OSCHINA-MIRROR/openharmony-xts

Введение

Подсистема тестового набора X (XTS) содержит набор сертификационных тестовых наборов OpenHarmony, включая поддерживаемый в настоящее время набор тестов на совместимость приложений (ACTS) и набор тестов на совместимость устройств (DCTS), который будет поддерживаться в будущем.

Эта подсистема содержит программный пакет acts и tools.

В каталоге acts хранится исходный код и файлы конфигурации тестовых случаев ACTS. ACTS помогает поставщикам оборудования как можно раньше обнаруживать несовместимость программного обеспечения и обеспечивает совместимость программного обеспечения с OpenHarmony в течение всего процесса разработки.
Программный пакет tools хранит среду разработки тестовых сценариев, связанную с acts.

Типы систем

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 Уровни тестовых случаев

Уровень	Описание
Базовый	Проверяет основные функции системы.
Расширенный	Проверяет расширенные функции системы.

Область применения

Level0

Smoke — проверяет основные функциональные возможности ключевых функций и базовые атрибуты DFX с наиболее распространённым вводом. Положительный результат проверки означает, что функции работоспособны.

Level1

Basic — проверяет основные функциональные возможности ключевых функций и базовые атрибуты DFX со стандартным вводом. Положительный результат проверки свидетельствует о том, что функции тестируемы.

Level2

Major — проверяет основные функциональные возможности ключевых функций и базовые атрибуты DFX со стандартным и ошибочным вводом. Положительный результат проверки указывает на то, что функции функциональны и готовы к бета-тестированию.

Level3

Regular — проверяет функциональные возможности всех ключевых функций, а также все атрибуты DFX при стандартных и нестандартных комбинациях ввода или нормальных и аномальных предустановленных условиях.

Level4

Rare — проверяет функциональные возможности ключевых функций в условиях чрезвычайно аномальных предустановок и нестандартных комбинаций ввода. Таблица 2. Масштабы тестовых случаев

Масштаб теста	Тестируемые объекты	Среда тестирования
LargeTest	Функциональности сервисов, все сценарии функций и среда механической мощности (MPE), а также DFX на уровне сценариев	Устройства, близкие к реальным устройствам
MediumTest	Модули, функциональности подсистем после интеграции модулей и DFX	Одно устройство, которое действительно используется. Можно выполнять симуляцию сообщений, но не следует имитировать функции
SmallTest	Модули, классы и функции	Локальный ПК. Используйте большое количество имитаций для замены зависимостей другими модулями

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

Тип	Определение
Function	Проверяет правильность функциональностей как сервиса, так и платформы, предоставляемых тестируемым объектом конечным пользователям или разработчикам

Тестирует способность к обработке тестируемого объекта в заданных условиях и при определённой нагрузке. Способность к обработке измеряется объёмом услуг, который может быть обработан за единицу времени, например, количество вызовов в секунду, кадров в секунду или объём обработки событий в секунду.

Мощность

Тестирует энергопотребление тестируемого объекта за определённый период времени в заданных условиях и при определённых нагрузках.

Надёжность

Проверяет производительность сервиса тестируемого объекта при обычных и необычных входных условиях, а также при заданном давлении объёма услуг и длительном непрерывном использовании. Тест включает стабильность, обработку давления, внедрение ошибок и время тестирования Monkey.

Безопасность

Проверяет способность защищаться от угроз безопасности, включая несанкционированный доступ, использование, раскрытие, повреждение, модификацию и уничтожение, чтобы обеспечить конфиденциальность, целостность и доступность информации.
Тестирует возможность защиты конфиденциальности, чтобы гарантировать, что сбор, использование, хранение, раскрытие и удаление личных данных пользователей соответствуют законам и правилам.
Проверяет соответствие различным спецификациям безопасности, таким как дизайн безопасности, требования безопасности и сертификация безопасности Министерства промышленности и информационных технологий (MIIT).

Глобальность

Тестирует возможности интернационализации данных и локализации тестируемого объекта, включая многоязычное отображение, различные привычки ввода/вывода, форматы времени и региональные особенности, такие как валюта, время и культурные табу.

Совместимость

Проверяется обратная совместимость приложения с собственными данными, прямая и обратная совместимость с системой и совместимость с различными пользовательскими данными, такими как содержимое аудиофайлов проигрывателя и интеллектуальные SMS-сообщения.
Исследуется обратная совместимость системы с собственными данными и совместимость с предыдущими версиями системы. Совместимость приложений в экосистеме
Совместимость программного обеспечения с соответствующими аппаратными средствами.

Тестирование пользовательского опыта

Тестирование пользовательского восприятия объекта в реальных сценариях использования. Все выводы и комментарии должны исходить от пользователей, что является субъективной оценкой в данном случае.

Соответствие стандартам

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

Безопасность

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

Устойчивость

Тест на устойчивость тестируемого объекта, чтобы гарантировать, что он может выдержать и поддерживать определённое рабочее состояние (включая понижение), когда подвергается атаке, а также восстанавливаться после атак и адаптировать защиту для выполнения миссии.

Рекомендации по разработке тестовых сценариев

Необходимо выбрать подходящий язык программирования и целевую среду тестирования для разработки тестовых случаев.

Таблица 4: Среды тестирования и языки тестовых примеров для различных систем

Система	Среда тестирования	Язык
Mini	HCTest	C

В тексте запроса нет кода или специальных символов, требующих перевода. ### Разработка и компиляция тестовых случаев на основе 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 тест Имя подсистемы
* @param пример Имя модуля
* @param IntTestSuite Имя набора тестов
*/
LITE_TEST_SUIT(тест, пример, 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.
1. Импортируйте заголовочный файл фреймворка тестирования.
В следующем утверждении используется gtest.h.

#include "gtest/gtest.h"


    2. Определите Setup и TearDown.

    ```
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 (уровень 0 теста), LEVEL1 (уровень 1 теста), LEVEL2 (уровень 2 теста), LEVEL3 (уровень 3 теста) и LEVEL4 (уровень 4 теста).

Используйте стандартный синтаксис 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')
        })
    }) 
    ```