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

OSCHINA-MIRROR/openharmony-xts_tools

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
README_zh.md 59 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 09.03.2025 07:16 a33e7c5

Подсистема XTS

Обзор

Подсистема XTS представляет собой набор сертификационных тестовых сценариев OpenHarmony, включающий ACTS (Application Compatibility Test Suite) — компонент совместимости приложений, а также планируется расширение до DCTS (Distributed Compatibility Test Suite) — компонента совместимости распределённых систем и HATS (Hardware Abstract Test Suite) — компонента совместимости аппаратного уровня.

На данный момент подсистема XTS состоит из двух пакетов:- ACTS, содержащий исходные коды и конфигурационные файлы для тестовых случаев ACTS. Цель этих тестов — раннее выявление проблем совместимости между программами и OpenHarmony, чтобы обеспечивать соответствие программных продуктов требованиям OpenHarmony на протяжении всего цикла разработки.

  • Tools, содержащий разработанные для ACTS фреймы работы с тестовыми случаями.

Типы систем

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

  • Легковесная система (mini system)

    Предназначена для устройств с процессорами типа MCU, таких как Arm Cortex-M и RISC-V 32-bit, имеющих ограниченные ресурсы. Минимальная память составляет 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 Уровень описания примеров

Уровень имени

Основное определение

Область тестирования

Level0

Сигаретный дым

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

Level1

Базовый уровень

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

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

Level2

Промежуточный уровень

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

Важно

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

Уровень 3

Обычное

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

Уровень 4

Редкое

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

Таблица 2 Описание гранулярности случаев использования

Размер тестового случая

Объект тестирования

Тестовая среда

LargeTest

Бизнес-функционал/полносценарные характеристики/целый аппарат и сценарий уровня DFX

Используйте как можно более реалистичное оборудование для тестирования

MediumTest

Модуль/интеграция подсистемы в устройство после его установки/DFX

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

SmallTest

Код/методы/классы/функции

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

Модуль/подсистема/функция

Используйте простую среду для тестирования, используйте MOCK для функций

2 "><p id="p54141541181018"><a name="p54141541181018"></a><a name="p54141541181018"></a>Модуль/класс/функция</p>
</td>
<td class="cellrowborder" valign="top" width="45.  23452345234523%" headers="mcps1.  2.  4.  1.  3 "><p id="p1841494131013"><a name="p1841494131013"></a><a name="p1841494131013"></a>Тестирование в личной среде разработчика, минимизация зависимости от других модулей, использование большого количества MOCK</p>
</td>
</tr>
</tbody>
</table>

Таблица 3 Описание типов тестов

Тип теста

Определение типа теста

Функциональность

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

Здесь "пользователи" могут быть конечные пользователи или разработчики. Функциональность включает как бизнес-функции, так и платформенные.
<tr id="row1821930154611">
<td class="cellrowborder" valign="top" width="19.040000000000003%" headers="mcps1.2.3.1.1">
<p id="p591714474612"><a name="p591714474612"></a><a name="p591714474612"></a>Производительность</p>
</td>
<td class="cellrowborder" valign="top" width="80.96%" headers="mcps1.2.3.1.2">
<p id="p15917154410463"><a name="p15917154410463"></a><a name="p15917154410463"></a>Проверка способности объекта тестирования обрабатывать данные при определённых условиях или нагрузках. Производительность обычно измеряется количеством обрабатываемых данных за единицу времени, таким образом как вызовы/секунду, кадры/секунду, количество обработанных событий/секунду и т. д.</p>
</td>
</tr>
<tr id="row13821030104616">
<td class="cellrowborder" valign="top" width="19.040000000000003%" headers="mcps1.2.3.1.1">
<p id="p691711440467"><a name="p691711440467"></a><a name="p691711440467"></a>Энергопотребление</p>
</td>
<td class="cellrowborder" valign="top" width="80.96%" headers="mcps1.2.3.1.2">
<p id="p159171544104616"><a name="p159171544104616"></a><a name="p159171544104616"></a>Проверка энергопотребления объекта тестирования при определённых условиях или нагрузках в течение определённого периода времени.</p>
</td>
</tr>
<tr id="row6821330114618">
<td class="cellrowborder" valign="top" width="19.040000000000003%" headers="mcps1.2.3.1.1">
<p id="p13917164454612"><a name="p13917164454612"></a><a name="p13917164454612"></a>Надёжность</p>
</td>
<td class="cellrowborder" valign="top" width="80.96%" headers="mcps1.2.3.1.2">
<p>Проверка надёжности объекта тестирования, которая включает проверку его способности работать корректно при различных условиях и нагрузках, а также его способности восстанавливаться после отказов или ошибок.</p>
</td>
</tr>
```<p id="p159171544104618"><a name="p159171544104618"></a><a name="p159171544104618"></a>Проверка надежности работы объекта тестирования при различных условиях и нагрузках.</p>
</td>
</tr>
</tbody>
</table>```markdown
<tr>
    <td class="cellrowborder" valign="top" width="19. 040000000000003%">
        <p id="p11917194416465"><a name="p11917194416465"></a><a name="p11917194416465"></a>Stability and Stress Testing</p>
    </td>
    <td class="cellrowborder" valign="top" width="80. 96%">
        <p id="p1791784410463"><a name="p1791784410463"></a><a name="p1791784410463"></a>Проверка производительности объекта тестирования при нормальных/некорректных входных данных, а также при воздействии нагрузки и длительной непрерывной работе. Включает в себя проверки стабильности, стрессовых условий, внедрения сценариев отказа и случайных действий (Monkey тест).</p>
    </td>
</tr>
<tr id="row11821930184612">
    <td class="cellrowborder" valign="top" width="19. 040000000000003%">
        <p id="p1691774474618"><a name="p1691774474618"></a><a name="p1691774474618"></a>Безопасность</p>
    </td>
    <td class="cellrowborder" valign="top" width="80. 96%">
        <p id="p1791784410463"><a name="p1791784410463"></a><a name="p1791784410463"></a>Проверка способности системы противостоять злонамеренным угрозам, включая, но не ограничиваясь, несанкционированным доступом, использованием, утечками, уничтожением, модификацией и уничтожением информации. Это обеспечивает конфиденциальность, целостность и доступность информации.</p>
    </td>
</tr>Проверка защиты личных данных пользователей, чтобы гарантировать, что сбор, использование, хранение, раскрытие и удаление этих данных соответствуют законодательству, защищая права пользователя на конфиденциальность. Проверка соблюдения различных стандартов безопасности, таких как стандарты безопасного дизайна, красные линии безопасности и стандарты сертификации безопасности Министерства информационных технологий КНР.</p>
</td>
</tr>
<tr id="row16825307467">
<td class="cellrowborder" valign="top" width="19.040000000000003%">
<p id="p129188444462"><a name="p129188444462"></a><a name="p129188444462"></a>Международная поддержка и локализация</p>
</td>
<td class="cellrowborder" valign="top" width="80.96%">
<p id="p179186444465"><a name="p179186444465"></a><a name="p179186444465"></a>Проверка наличия международной поддержки и локализации объекта тестирования, включая отображение языковых сообщений, привычки ввода/вывода, отображение времени, региональные особенности, такие как валюты, временные зоны и т. д.</p>
</td>
</tr>
<tr id="row08211308464">
<td class="cellrowborder" valign="top" width="19.040000000000003%">
<p id="p191814447465"><a name="p191814447465"></a><a name="p191814447465"></a>Совместимость</p>
</td>
<td class="cellrowborder" valign="top" width="80.96%">Пожалуйста, предоставьте текст для перевода, чтобы я мог его исправить согласно указанным правилам.```markdown
 <p id="p179186444465"><a name="p179186444465"></a><a name="p179186444465"></a>Проверка совместимости объекта тестирования с различными платформами, устройствами и версиями программного обеспечения, чтобы убедиться, что он работает правильно во всех поддерживаемых средах.</p>
 </td>
 </tr>
 
<tr id="row1782730124618">
 <td class="cellrowborder" valign="top" width="19.040000000000003%" headers="mcps1.2.3.1.1">
 <p id="p13918144134614"><a name="p13918144134614"></a><a name="p13918144134614"></a>Пользователь</p>
 </td>
 <td class="cellrowborder" valign="top" width="80.96%" headers="mcps1.2.3.1.2">
 <p id="p1291844494611"><a name="p1291844494611"></a><a name="p1291844494611"></a>Тестовые случаи, проверяющие опыт использования продукта в реальных сценариях взаимодействия с пользователями. Важно отметить, что в данном случае нет объективной "правильности" или "неудачи"; все выводы и оценки должны основываться на отзывах пользователей.</p>
 </td>
 </tr>
 <tr id="row58243024617">
 <td class="cellrowborder" valign="top" width="19.040000000000003%" headers="mcps1.2.3.1.1">
 <p id="p1291884474614"><a name="p1291884474614"></a><a name="p1291884474614"></a>Стандарт</p>
 </td>
 <td class="cellrowborder" valign="top" width="80.96%" headers="mcps1.2.3.1.2">
 <p id="p0918124424614"><a name="p0918124424614"></a><a name="p0918124424614"></a>Тестовые случаи, проверяющие соответствие продукта отраслевым и внутренним стандартам/протоколам/нормам. Здесь "стандарты" не включают никакие безопасностные стандарты; тестовые случаи, связанные с безопасностью, относятся к типу "Безопасность".</p>
 </td>
 </tr>
 <tr id="row382830124619">
 <td class="cellrowborder" valign="top" width="19.040000000000003%" headers="mcps1.2.3.1.1">
 ```<p id="p119181044164619"><a name="p119181044164619"></a><a name="p119181044164619"></a>Безопасность</p>
</td>
<td class="cellrowborder" valign="top" width="80.96%" headers="mcps1.2.3.1.2">
<p id="p1291818443468"><a name="p1291818443468"></a><a name="p1291818443468"></a>Тестовые случаи, проверяющие безопасность продукта, чтобы избежать возможных угроз здоровью и безопасности людей, а также повреждений самого продукта.</p>
</td>
</tr>
``````markdown
<tr id="row1083153014465">
<td class="cellrowborder" valign="top" width="19.040000000000003%" headers="mcps1.2.3.1.1 ">
<p id="p119181044164619"><a name="p119181044164619"></a><a name="p119181044164619"></a>Совместимость</p>
</td>
<td class="cellrowborder" valign="top" width="80.96%" headers="mcps1.2.3.1.2 ">
<p id="p1291818443468"><a name="p1291818443468"></a><a name="p1291818443468"></a>Тестовые случаи, проверяющие совместимость продукта с другими системами, приложениями и устройствами. Это может включать обратную совместимость данных внутри продукта, совместимость системы как целого, совместимость с данными различных пользователей и совместимость с экосистемой приложений.</p>
</td>
</tr>
<tr id="row39187441469">
<td class="cellrowborder" valign="top" width="19.040000000000003%" headers="mcps1.2.3.1.1 ">
<p id="p39187441469"><a name="p39187441469"></a><a name="p39187441469"></a>Устойчивость</p>
</td>
<td class="cellrowborder" valign="top" width="80.96%" headers="mcps1.2.3.1.2 ">
<p id="p891815444462"><a name="p891815444462"></a><a name="p891815444462"></a>Проверка устойчивости тестируемого объекта, чтобы гарантировать, что система при атаках способна выдерживать и сохранять определённое состояние работы (включая понижение производительности), восстанавливаться и адаптироваться к атакам для обеспечения выполнения задачи.</p>
</td>
</tr>
</tbody>
</table>
## Руководство по разработке тестовых случаев<a name="section3695134065513"></a>

Выбираете тестовый фреймворк и язык для тестовых случаев в зависимости от системы тестирования.
```**Таблица 4** Соответствие систем, тестовых фреймворков и языков программирования<a name="table4418343171415"></a>

<table>
<thead align="left">
<tr id="row34183435145">
<th class="cellrowborder" valign="top" width="33.33333333333333%" id="mcps1.2.4.1.1"><p id="p941874311148"><a name="p941874311148"></a><a name="p941874311148"></a>Система</p></th>
<th class="cellrowborder" valign="top" width="33.33333333333333%" id="mcps1.2.4.1.2"><p id="p1841804341413"><a name="p1841804341413"></a><a name="p1841804341413"></a>Тестовый фреймворк</p></th>
<th class="cellrowborder" valign="top" width="33.33333333333333%" id="mcps1.2.4.1.3"><p id="p2418104311148"><a name="p2418104311148"></a><a name="p2418104311148"></a>Язык программирования</p></th>
</tr>
</thead>
<tbody>
<tr id="row8419164319148">
<td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.2.4.1.1"><p id="p7419194312143"><a name="p7419194312143"></a><a name="p7419194312143"></a>Легкая система</p></td>
<td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.2.4.1.2"><p id="p10419124312145"><a name="p10419124312145"></a><a name="p10419124312145"></a>hctest</p></td>
<td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.2.4.1.3"><p id="p11419643191410"><a name="p11419643191410"></a><a name="p11419643191410"></a>C</p></td>
</tr>
<tr id="row141915438147">
<td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.2.4.1.1"><p id="p441911436141"><a name="p441911436141"></a><a name="p441911436141"></a>Маленькая система</p></td>
<td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.2.4.1.2"><p id="p541916432142"><a name="p541916432142"></a><a name="p541916432142"></a>hcpptest</p></td>
<td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.2.4.1.3"><p id="p54191643131416"><a name="p54191643131416"></a><a name="p54191643131416"></a>C++</p></td>
</tr>
<tr id="row4419134341417">
<td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.2.4.1.1"><p id="p341964313143"><a name="p341964313143"></a><a name="p341964313143"></a>Стандартная система</p></td>
<td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.2.4.1.2">```markdown
<table>
 <tbody>
 <tr>
 <td class="cellrowborder" valign="top" width="33.3333%"><p id="p10419443171416"><a name="p10419443171416"></a><a name="p10419443171416"></a>HJSUnit, hcpptest</p></td>
 <td class="cellrowborder" valign="top" width="33.3333%"><p id="p10419443171416"><a name="p10419443171416"></a><a name="p10419443171416"></a>C++</p></td>
 </tr>
 </tbody>
</table>

```javascript
<p id="p9419143181414"><a name="p9419143181414"></a><a name="p9419143181414"></a>JavaScript, C++</p>

### Правила разработки примеров тестирования на C (для легковесных систем)

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

Используется тестовый фреймворк hctest, который позволяет писать тестовые примеры на языке C. Этот фреймворк является расширением открытого тестового фреймворка Unity.

1. **Структура каталогов для хранения тестовых примеров:**

   Тестовые примеры должны храниться в каталоге `test/xts/acts`.

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


2. **Примеры написания тестовых примеров в каталоге src:**

1. Включение тестового фреймворка:

    ```c
    #include "hctest.h"
    ```

2. Определение имени подсистемы, модуля и тестового набора с помощью макроса `LITE_TEST_SUIT`:

    ```c
    /**
     * @brief  регистрация тестового набора "IntTestSuite"
     * @param  имя подсистемы
     * @param  имя модуля
     * @param  имя тестового набора
     */
    LITE_TEST_SUIT(test, example, IntTestSuite);
    ```

3. Определение методов `Setup` и `TearDown`:

    Названия методов должны быть следующими: `<название_тестового_набора>Setup`, `<название_тестового_набора>TearDown`. Эти методы обязательны, но могут быть пустыми.   4. Определение тестовых примеров с использованием макроса `LITE_TEST_CASE`:

    Макрос принимает три аргумента: имя тестового набора, имя тестового примера, свойства тестового примера (тип теста, размер теста, уровень).

    ```c
    LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1)
    {
      // выполните что-то
    };
    ```

5. Регистрация тестового набора с использованием макроса `RUN_TEST_SUITE`:

    ```c
    RUN_TEST_SUITE(IntTestSuite);
    ```

3. **Пример конфигурационного файла BUILD.gn для тестового модуля:**

В каждом каталоге тестового модуля создается файл BUILD.gn, который указывает настройки компиляции, такие как имя статической библиотеки, необходимые заголовочные файлы и зависимости от других библиотек; пример записи:

```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"]
}
  1. Добавление опций сборки в BUILD.gn для каталога acts:

    Для того чтобы добавить тестовый модуль в скрипт сборки каталога acts, необходимо внести изменения в файл BUILD.gn, расположенный по пути test/xts/acts/build_lite/BUILD.gn.

Пример выполнения тестового случая для легковесной системы

Запустите образ версии на платформе разработки.#### Шаги тестирования

  1. Войдите в систему через утилиту последовательного соединения и сохраните вывод консоли.
  2. Перезагрузите устройство и просмотрите логи последовательного соединения.

Инструкция по анализу результатов тестирования

Анализируйте данные на основе вывода консоли;

каждый тестовый набор начинается с 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:

    1. Указание тестовой системы:

    Необходимо указать gtest.h, например: #include "gtest/gtest.h".

    #include "gtest/gtest.h"
    1. Определение методов Setup и TearDown```markdown
    using namespace std;
    using namespace testing::ext;
    class TestSuite : public testing::Test {
    protected:
    // Предварительные действия перед первым тестовым случаем
    static void SetUpTestCase() {
    }
    // Чистка после последнего тестового случая
    static void TearDownTestCase() {
    }
    // Предварительные действия перед каждым тестовым случаем
    virtual void SetUp() {
    }
    // Чистка после каждого тестового случая
    virtual void TearDown() {
    }
    };
    ```3. Для написания тестовых примеров используйте макросы HWTEST или HWTEST_F.

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

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

   ```cpp
   HWTEST_F(TestSuite, TestCase_0001, Function | MediumTest | Level1) {
       // выполните что-то
   }
  1. Пример конфигурационного файла 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" ]
    }
    
  2. Добавление компонентов сборки (BUILD.gn) в директорию 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" ] }

  3. Команды сборки тестовых наборов.

    Сборка выполняется вместе с версией продукта; при сборке отладочной версии также происходит сборка тестового набора Acts.

    Примечание: Маленький системный тестовый набор Acts собирается независимо в исполняемый файл bin, который архивируется в директорию suites\acts сборки продуктов.

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

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

Сейчас тестовые примеры выполняются путём использования NFS для совместного доступа, затем монтирования на одноплатный компьютер для выполнения.

Настройка среды

  1. Подключите отладочную плату к компьютеру с помощью Ethernet-кабеля или беспроводной сети.
  2. Настройте IP-адрес, маску подсети и шлюз на отладочной плате так, чтобы она находилась в одной сети с компьютером.
  3. Установите NFS-сервер на компьютере, зарегистрируйте его и запустите службу NFS.
  4. Настройте команду mount на отладочной плате, чтобы обеспечить доступ к NFS-разделам, расположенным на компьютере.Формат: mount [ip-адрес_nfs_сервера]:[/каталог_nfs_общего_пользования] [/каталог_разработки] nfsПример:
mount 192.168.1.10:/nfs /nfs nfs

Руководство по разработке тестовых случаев на языке JavaScript (для стандартной системы)

Используется тестовый фреймворк HJSUnit для автоматизации тестирования приложений на основе OpenHarmony (в частности, приложений, созданных с использованием языка JavaScript в рамках JS-фреймворка).

Основные правила написания тестовых случаев

Тестовые случаи должны быть написаны на языке JavaScript и соответствовать стандартам программирования на этом языке.Таблица 5

Синтаксис примера

Описание

Требования

beforeAll

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

Необязательно

afterAll

Условие завершения уровня тестового набора, выполняется после всех тестовых случаев один раз и принимает один аргумент: функцию завершения.

Необязательно

Необязательный

beforeEach

<tr id="row69811335175215">
<td class="cellrowborder" valign="top" width="17.92179217921792%" headers="mcps1.2.4.1.1">
<p id="p149811335175215"><a name="p149811335175215"></a><a name="p149811335175215"></a>Предварительные условия уровня тест-кейса выполняются перед началом каждого тест-кейса, количество выполнений равно количеству тест-кейсов, определённых в it. Поддерживает один параметр: функцию предварительной подготовки.</p>
</td>
<td class="cellrowborder" valign="top" width="13.19131913191319%" headers="mcps1.2.4.1.3">
<p id="p13981133585212"><a name="p13981133585212"></a><a name="p13981133585212"></a>Необязательный</p>
</td>
</tr>
<tr id="row6982435115219">
<td class="cellrowborder" valign="top" width="17.92179217921792%" headers="mcps1.2.4.1.1">
<p id="p19982133517525"><a name="p19982133517525"></a><a name="p19982133517525"></a>afterEach</p>
</td>
<td class="cellrowborder" valign="top" width="68.88688868886888%" headers="mcps1.2.4.1.2">
<p id="p1398213575219"><a name="p1398213575219"></a><a name="p1398213575219"></a>Уровень тест-кейса очистка условий выполняется после завершения каждого тест-кейса, количество выполнений равно количеству тест-кейсов, определённых в it. Поддерживает один параметр: функцию очистки.</p>
</td>
<td class="cellrowborder" valign="top" width="13.19131913191319%" headers="mcps1.2.4.1.3">
<p id="p159821535195219"><a name="p159821535195219"></a><a name="p159821535195219"></a>Необязательный</p>
</td>
</tr>
```<p id="p598203510527"><a name="p598203510527"></a><a name="p598203510527"></a>describe</p>
</td>
<td class="cellrowborder" valign="top" width="68. 88688868886888%" headers="mcps1. 2. 4. 1. 2 ">
<p id="p5982123595215"><a name="p5982123595215"></a><a name="p5982123595215"></a>Определяет набор тестов с двумя параметрами: название набора тестов и функцию набора тестов; describe поддерживает вложенность, внутри каждого describe можно определить beforeAll, beforeEach, afterEach и afterAll.</p>
</td>
<td class="cellrowborder" valign="top" width="13. 19131913191319%" headers="mcps1. 2. 4. 1. 3 ">
<p id="p898217352527"><a name="p898217352527"></a><a name="p898217352527"></a>Обязательный</p>
</td>
</tr>
<tr id="row6982113518526">
<td class="cellrowborder" valign="top" width="17. 92179217921792%" headers="mcps1. 2. 4. 1. 1 ">
<p id="p17982123510526"><a name="p17982123510526"></a><a name="p17982123510526"></a>it</p>
</td>
<td class="cellrowborder" valign="top" width="68. 88688868886888%" headers="mcps1. 2. 4. 1. 2 ">
```Пожалуйста, предоставьте текст для перевода, чтобы я мог его исправить согласно указанным правилам.```markdown
 <p id="p17982123510526"><a name="p17982123510526"></a><a name="p17982123510526"></a>Определяет отдельный тест-кейс с двумя параметрами: описание тест-кейса и функцию тест-кейса.</p>
 </td>
 <td class="cellrowborder" valign="top" width="13. 19131913191319%" headers="mcps1. 2. 4. 1. 3 ">
 <p id="p17982123510526"><a name="p17982123510526"></a><a name="p17982123510526"></a>Обязательный</p>
 </td>
 </tr>
2 "><p id="p598211352522"><a name="p598211352522"></a><a name="p598211352522"></a>Определите тестовый случай с поддержкой трех параметров: имя тестового случая, фильтрация параметров и функция тестового случая.</p>
<p id="p6965058101"><a name="p6965058101"></a><a name="p6965058101"></a>Фильтрация параметров: это параметр типа int размером в 32 бита. Положение 0 указывает на то, что если установлено значение 1, то отбор не производится, а выполнение происходит по умолчанию; положения 0-10 указывают на <strong id="b9169154410212"><a name="b9169154410212"></a><a name="b9169154410212"></a>тип тестового случая</strong>; положения 16-18 указывают на <strong id="b1427947428"><a name="b1427947428"></a><a name="b1427947428"></a>масштаб тестового случая</strong>; положения 24-28 указывают на <strong id="b289818491213"><a name="b289818491213"></a><a name="b289818491213"></a>уровень тестового случая</strong>.</p>
<p id="p7965165151011"><a name="p7965165151011"></a><a name="p7965165151011"></a><strong id="b69449534215"><a name="b69449534215"></a><a name="b69449534215"></a>Тип тестового случая</strong>.
```Установка значений 0-10 соответственно указывает на следующие типы тестовых случаев: FUNCTION — методический тест, PERFORMANCE — тест производительности, POWER — тест энергопотребления, RELIABILITY — тест надежности, SECURITY — тест безопасности, GLOBAL — глобальный тест, COMPATIBILITY — тест совместимости, USER — тест пользователя, STANDARD — тест стандартов, SAFETY — тест безопасных характеристик, RESILIENCE — тест устойчивости. </p>
<p id="p199651555102"><a name="p199651555102"></a><a name="p199651555102"></a><strong id="b10114125712211"><a name="b10114125712211"></a><a name="b10114125712211"></a>Масштаб тестового случая</strong>. Установка значений 16-18 соответственно указывает на следующие масштабы тестовых случаев: SMALL — малый тест, MEDIUM — средний тест, LARGE — большой тест. </p>
<p id="p296545151020"><a name="p296545151020"></a><a name="p296545151020"></a><strong id="b167975581223"><a name="b167975581223"></a><a name="b167975581223"></a>Уровень тестового случая</strong>. Установка значений 24-28 соответственно указывает на следующие уровни тестовых случаев: LEVEL0-0 — уровень 0 теста, LEVEL1-1 — уровень 1 теста, LEVEL2-2 — уровень 2 теста, LEVEL3-3 — уровень 3 теста, LEVEL4-4 — уровень 4 теста. </p>

Обратите внимание, что структура и разметка были сохранены при переводе. При написании сценариев тестирования используется стандартная грамматика Jasmine, поддерживающая формат ES6.1. Структура каталога тестовых сценариев: тестовые сценарии хранятся в директории entry/src/main/js/test.

```
├── BUILD.gn   
│ └── entry
│   └── src
│     └── main
│       └── js
│         └── default               
│           └── pages
│             └── index             
│               └── index.js        # Входной файл
│         └── test                  # Каталог для хранения тестового кода  
│       └── resources                # Каталог для хранения ресурсов HAP
│       └── config.json              # Конфигурационный файл HAP
```
  1. Пример файла 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() {
        },
    }
  2. Пример единичного тестового сценария

    // Пример 1: использование HJSUnit для проведения единичного тестирования
    describe('appInfoTest', function () {    
        it('app_info_test_001', function () {
            var info = app.getInfo()
            expect(info.versionName).toEqual('1.0')
            expect(info.versionCode).toEqual(3)
        })
    }) 
    ```### Руководство по компиляции и сборке приложений на языке JavaScript <a name="section445519106559"></a>
    

Компиляция пакета HAP выполнена согласно руководству по разработке приложений на языке JavaScript для стандартной системы.

Связанные репозитории

xts_acts инструменты XTS

Опубликовать ( 0 )

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

1
https://api.gitlife.ru/oschina-mirror/openharmony-xts_tools.git
git@api.gitlife.ru:oschina-mirror/openharmony-xts_tools.git
oschina-mirror
openharmony-xts_tools
openharmony-xts_tools
master