1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/openharmony-xts_tools

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Это зеркальный репозиторий, синхронизируется ежедневно с исходного репозитория.
Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
4 месяцев назад
fix
3 месяцев назад
3 месяцев назад
4 лет назад
3 месяцев назад
3 месяцев назад
9 месяцев назад
3 месяцев назад
3 месяцев назад
год назад
Loading...
README.md

Введение

Подсистема тестового набора 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. Уровни тестовых случаев

Уровень Описание
Базовый Проверка основных функций системы
Средний Проверка расширенных функций системы
Высокий Проверка всех функций системы, включая крайние случаи

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

Уровень 0

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

Уровень 1

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

Уровень 2

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

Уровень 3

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

Уровень 4

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

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

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

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

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

Мощность

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

Надёжность

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

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

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

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

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

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

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

Тестирование совместимости программного обеспечения с соответствующим оборудованием.

Пользователь

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

Стандарт

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

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

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

Надёжность

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

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

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

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

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

Разработка тестовых случаев для мини-системы

Для поддержки тестовых случаев, разработанных на языке C, используется фреймворк HCTest, который был улучшен и адаптирован на основе открытого исходного кода фреймворка Unity.

  1. Получите доступ к репозиторию test/xts/acts, где будут храниться тестовые случаи.

    ├── acts
    │ └──subsystem_lite
    │ │ └── module_hal
    │ │ │ └── BUILD.gn
    │ │ │ └── src
    │ └──build_lite
    │ │ └── BUILD.gn
  2. Напишите тестовый случай в каталоге 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);
  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. Добавьте параметры сборки в файл 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"
            ]    
        }
    }
  5. Запустите команды сборки.

    Наборы тестов создаются вместе с версией сборки. ACTS создаётся вместе с отладочной версией. Тестирование тестовых случаев для мини-системы на основе C (для мини-системы)

Запись образа на плату разработки.

Выполнение теста

  1. Используйте инструмент последовательного порта для входа в плату разработки и сохраните информацию о последовательном порте.
  2. Перезагрузите устройство и просмотрите журналы последовательных портов.

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

Журнал для каждого набора тестов начинается с «Начать выполнение набора тестов:» и заканчивается «xx Тесты xx Сбои xx Игнорировано».

Разработка и компиляция тестовых случаев на C++ (для стандартных и малых систем) (Примеры стандартной системы см. в каталоге global/i18n_standard.)

Улучшается и адаптируется фреймворк HCPPTest на основе открытого исходного кода Googletest.

  1. Получите доступ к репозиторию test/xts/acts, где будут храниться тестовые случаи.

    ├── acts
    │ └──subsystem_lite
    │ │ └── module_posix
    │ │ │ └── BUILD.gn
    │ │ │ └── src
    │ └──build_lite
    │ │ └── BUILD.gn
  2. Напишите тестовый случай в каталоге src.

    1. Импортируйте заголовочный файл тестового фреймворка. В следующем утверждении используется gtest.h.
    #include "gtest/gtest.h"
    1. Определите 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 создаётся вместе с отладочной версией.
>![](figures/icon-note.gif) **Примечание:**
>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 )

Вы можете оставить комментарий после Вход в систему

Введение

Фреймворк для разработки и тестирования актов. Расширить Свернуть
Apache-2.0
Отмена

Обновления (1)

все
3 месяцев назад

Недавние действия

Загружен новый тег weekly_20240115-v 3 месяца назад
Загружен новый тег master-v 3 месяца назад
Загружен новый тег OpenHarmony-v4.1-Beta1 3 месяца назад
Загружен новый тег OpenHarmony-v4.0-Beta2 3 месяца назад
Загружен новый тег OpenHarmony-v4.0-Beta1 3 месяца назад
Загрузить больше
Больше нет результатов для загрузки
1
https://gitlife.ru/oschina-mirror/openharmony-xts_tools.git
git@gitlife.ru:oschina-mirror/openharmony-xts_tools.git
oschina-mirror
openharmony-xts_tools
openharmony-xts_tools
master