Руководство по разработке примеров использования
Подсистема XTS представляет собой набор сертификационных тестовых сценариев OpenHarmony, включающий ACTS (Application Compatibility Test Suite) — компонент совместимости приложений, а также планируется расширение до DCTS (Distributed Compatibility Test Suite) — компонента совместимости распределённых систем и HATS (Hardware Abstract Test Suite) — компонента совместимости аппаратного уровня.
На данный момент подсистема XTS состоит из двух пакетов:- ACTS, содержащий исходные коды и конфигурационные файлы для тестовых случаев ACTS. Цель этих тестов — раннее выявление проблем совместимости между программами и OpenHarmony, чтобы обеспечивать соответствие программных продуктов требованиям OpenHarmony на протяжении всего цикла разработки.
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++.
Проверка всех функциональных точек основных функций / базовых свойств DFX при обычных входах, что показывает возможность базовой проверки функций.
Проверка всех функциональных точек промежуточных функций / промежуточных свойств DFX при обычных входах, что показывает возможность более глубокого тестирования функций.
Таблица 2 Описание гранулярности случаев использования
Бизнес-функционал/полносценарные характеристики/целый аппарат и сценарий уровня DFX
Используйте как можно более реалистичное оборудование для тестирования
Модуль/интеграция подсистемы в устройство после его установки/DFX
Проведите проверку с использованием настоящего устройства, возможно имитация сообщений, минимизация использования MOCK для функций
Выполните проверку с использованием минимального набора данных, используйте 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"]
}
Добавление опций сборки в BUILD.gn для каталога acts:
Для того чтобы добавить тестовый модуль в скрипт сборки каталога acts, необходимо внести изменения в файл BUILD.gn, расположенный по пути test/xts/acts/build_lite/BUILD.gn
.
Запустите образ версии на платформе разработки.#### Шаги тестирования
Анализируйте данные на основе вывода консоли;
каждый тестовый набор начинается с Start to run test suite
и заканчивается xx Tests xx Failures xx Ignored
.
Используется тестовая система hcpptest, которая является расширенной версией открытого тестового фреймворка googletest.
Нормализация каталога тестовых случаев: тестовые случаи хранятся в хранилище test/xts/acts.
├── acts
│ └── subsystem_lite
│ └── module_posix
│ └── BUILD.gn
│ └── src
│ └── build_lite
│ └── BUILD.gn
Пример написания тестовых случаев в модуле src:
Необходимо указать gtest.h, например: #include "gtest/gtest.h".
#include "gtest/gtest.h"
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) {
// выполните что-то
}
Пример конфигурационного файла 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" ]
}
Добавление компонентов сборки (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"
]
}
Команды сборки тестовых наборов.
Сборка выполняется вместе с версией продукта; при сборке отладочной версии также происходит сборка тестового набора Acts.
Примечание: Маленький системный тестовый набор Acts собирается независимо в исполняемый файл bin, который архивируется в директорию suites\acts сборки продуктов.
Пример: выполнение тестовых примеров для маленькой системы
Сейчас тестовые примеры выполняются путём использования NFS для совместного доступа, затем монтирования на одноплатный компьютер для выполнения.
Настройка среды
mount 192.168.1.10:/nfs /nfs nfs
Используется тестовый фреймворк HJSUnit для автоматизации тестирования приложений на основе OpenHarmony (в частности, приложений, созданных с использованием языка JavaScript в рамках JS-фреймворка).
Тестовые случаи должны быть написаны на языке JavaScript и соответствовать стандартам программирования на этом языке.Таблица 5
<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
```
Пример файла 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() {
},
}
Пример единичного тестового сценария
// Пример 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 )