Слияние кода завершено, страница обновится автоматически
OpenHarmony предоставляет разработчикам полный набор инструментов для разработки и тестирования ПО — OHA-developer_test. Это помогает разработчикам создавать тестовые сценарии, соответствующие их потребностям, и выявлять недостатки на этапе разработки, что значительно повышает качество кода.
В этой статье рассматривается работа с фреймворком для разработки и тестирования OpenHarmony: базовая среда, создание тестовых сценариев, компиляция и выполнение.
Фреймворк для разработки и тестирования зависит от среды выполнения Python версии 3.8.X. Перед использованием фреймворка рекомендуется ознакомиться со следующими ресурсами:
Для использования фреймворк полагается на тестовую систему управления testfwk_xdevice. При использовании оба фреймворка должны находиться в одном каталоге.
Структура каталогов фреймворка для разработчиков выглядит следующим образом:
test # Тестовая подсистема
├── developer_test # Фреймворк для разработчиков
│ ├── aw # Статическая библиотека тестовой системы
│ ├── config # Конфигурация тестовой системы
│ | | ...
│ | └── user_config.xml # Пользовательская конфигурация
│ ├── examples # Примеры тестовых сценариев
│ ├── src # Исходный код тестовой системы
│ ├── third_party # Адаптация сторонних компонентов для тестовой системы
│ ├── reports # Отчёты о результатах тестирования
│ ├── BUILD.gn # Входная точка компиляции тестовой системы
│ ├── start.bat # Входной файл для тестирования (Windows)
│ └── start.sh # Входной файл для тестирования (Linux)
└── xdevice # Компоненты, от которых зависит тестовая система
При использовании фреймворка можно организовать тестовые сценарии по следующей структуре:
subsystem # Подсистема
├── partA # Часть A
│ ├── moduleA # Модуль A
│ │ ├── include
│ │ ├── src # Бизнес-код
│ │ └── test # Каталог тестовых сценариев
│ │ ├── unittest # Модульные тесты
│ │ │ ├── common # Общие сценарии
│ │ │ │ ├── BUILD.gn # Конфигурации компиляции сценариев
│ │ │ │ └── testA_test.cpp # Код модульного теста
│ │ │ ├── phone # Сценарии для мобильных устройств
│ │ │ ├── ivi # Сценарии для автомобильных головных устройств
│ │ │ └── liteos-a # Сценарии для IP-камер с ядром LiteOS
│ │ ├── moduletest # Тесты модулей
│ │ ...
│ ├── moduleB # Модуль B
│ ├── test
│ │ └── resource # Зависимые ресурсы
│ │ ├── moduleA # Модуль A
│ │ │ ├── ohos_test.xml # Файл конфигурации ресурсов
│ │ ... └── 1.txt # Ресурсы
│ │
│ ├── bundle.json # Конфигурация входа компиляции
│ ...
|
...
Примечание: Тестовые сценарии могут быть общими или специфичными для определённого типа устройства. Рекомендуется хранить общие сценарии в каталоге common, а специфические — в соответствующих каталогах устройств.
Фреймворк поддерживает различные типы тестов и предоставляет шаблоны для написания сценариев в зависимости от типа теста. TDD-тестирование (C++)
Однопоточный пример:
calculator_sub_test.cpp
/*
* Copyright (c) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include "calculator.h"
#include <gtest/gtest.h>
using namespace testing::ext;
class CalculatorSubTest : public testing::Test {
public:
static void SetUpTestCase(void);
static void TearDownTestCase(void);
void SetUp();
void TearDown();
};
void CalculatorSubTest::SetUpTestCase(void)
{
// input testsuit setup step，setup invoked before all testcases
}
void CalculatorSubTest::TearDownTestCase(void)
{
// input testsuit teardown step，teardown invoked after all testcases
}
void CalculatorSubTest::SetUp(void)
{
// input testcase setup step，setup invoked before each testcases
}
void CalculatorSubTest::TearDown(void)
{
// input testcase teardown step，teardown invoked after each testcases
}
/**
* @tc.name: integer_sub_001
* @tc.desc: Verify the sub function.
* @tc.type: FUNC
* @tc.require: issueNumber
*/
HWTEST_F(CalculatorSubTest, integer_sub_001, TestSize.Level1)
{
// step 1:调用函数获取结果
int actual = Sub(4，0)；
// Step 2:使用断言比较预期与实际结果
EXPECT_EQ(4, actual);
}
Более подробно:
/*
* Copyright (c) 2021 XXXX Device Co., Ltd.
* Licensed under the
``` **Apache License, Version 2.0**
(«Лицензия»);
вы не можете использовать этот файл, кроме как в соответствии с Лицензией.
Вы можете получить копию Лицензии по адресу:
Если это не требуется применимым законодательством или не согласовано в письменной форме, программное обеспечение, распространяемое по Лицензии, распространяется на условиях «КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ ИЛИ УСЛОВИЙ ЛЮБОГО РОДА, явных или подразумеваемых. См. Лицензию для конкретного языка, регулирующего разрешения и ограничения по Лицензии.
2. Ссылка на заголовочный файл тестового фреймворка и пространство имён
#include <gtest/gtest.h> using namespace testing::ext;
#include "calculator.h"
4. Определение тестового набора (тестового класса)
class CalculatorSubTest : public testing::Test { public: static void SetUpTestCase(void); static void TearDownTestCase(void); void SetUp(); void TearDown(); };
void CalculatorSubTest::SetUpTestCase(void) { // input testsuit setup step, setup invoked before all testcases }
void CalculatorSubTest::TearDownTestCase(void) { // input testsuit teardown step, teardown invoked after all testcases }
void CalculatorSubTest::SetUp(void) { // input testcase setup step, setup invoked before each testcases }
void CalculatorSubTest::TearDown(void) { // input testcase teardown step, teardown invoked after each testcases }
> **Примечание:** При определении тестового набора имя тестового набора должно соответствовать цели компиляции, используя стиль больших верблюжьих букв.
/**
* @tc.name: integer_sub_001
* @tc.desc: Verify the sub function.
* @tc.type: FUNC
* @tc.require: issueNumber
*/
HWTEST_F(CalculatorSubTest, integer_sub_001, TestSize.Level1) {
//step 1:вызов функции для получения результата
int actual = Sub(4, 0);
//Step 2:использование утверждения для сравнения ожидаемого и фактического результатов
EXPECT_EQ(4, actual);
}
Примечание: @tc.require формат должен начинаться с AR/SR или issue, например: issueI56WJ7.
Пример многопоточности:
base_object_test.cpp
Многопоточный пример случая:
// Заголовочный комментарий файла тестового примера и комментарий случая аналогичны однопоточному примеру.
#include "base_object.h"
#include <gtest/gtest.h>
#include <gtest/hwext/gtest-multithread.h>
#include <unistd.h>
using namespace testing::ext;
using namespace testing::mt;
namespace OHOS {
namespace AAFwk {
class AAFwkBaseObjectTest : public testing::Test {...}
// Step 1:функция для тестирования, возвращающая результат факториала
int factorial(int n) {
int result = 1;
for (int i = 1; i <= n; i++) {
result *= i;
}
printf("Factorial Function Result : %d! = %d\n", n, result);
return result;
}
// Step 2:используя утверждение для сравнения ожидаемого и фактического результатов
void factorial_test() {
int ret = factorial(3); // вызов функции для получения результата
std::thread::id this_id = std::this_thread::get_id();
std::ostringstream oss;
oss << this_id;
std::string this_id_str = oss.str();
long int thread_id = atol(this_id_str.c_str());
printf("running thread...: %ld\n", thread_id); // вывод текущего идентификатора потока
EXPECT_EQ(ret, 6);
}
HWTEST_F(AAFwkBaseObjectTest, Factorial_test_001, TestSize.Level1) {
SET_THREAD_NUM(4);
printf("Factorial_test_001 BEGIN\n");
GTEST_RUN_TASK(factorial_test);
printf("Factorial_test_001 END\n");
}
HWMTEST_F(AAFwkBaseObjectTest, Factorial_test_002, TestSize.Level1, 6) {
printf("Factorial_test_002 BEGIN\n");
factorial_test();
printf("Factorial_test_002 END\n");
}
} // namespace AAFwk
} // namespace OHOS
Подробное содержание:
Примечание: Соответствует стандарту однопоточного случая.
#include <gtest/gtest.h>
#include <gtest/hwext/gtest-multithread.h> ```
#include <unistd.h>
using namespace testing::ext;
using namespace testing::mt;
#include "base_object.h"
class AAFwkBaseObjectTest : public testing::Test {......}
Примечание: соответствует стандартам однопоточных сценариев использования.
// Step 1: тестируемая функция, возвращающая результат факториала
int factorial(int n)
{
int result = 1;
for (int i = 1; i <= n; i++) {
result *= i;
}
printf("Factorial Function Result : %d! = %d\n", n, result);
return result;
}
// Step 2: используем утверждения для сравнения ожидаемых и фактических результатов
void factorial_test()
{
int ret = factorial(3); // вызываем функцию для получения результата
std::thread::id this_id = std::this_thread::get_id();
std::ostringstream oss;
oss << this_id;
std::string this_id_str = oss.str();
long int thread_id = atol(this_id_str.c_str());
printf("running thread...: %ld\n", thread_id); // выводим идентификатор текущего потока
EXPECT_EQ(ret, 6);
}
// GTEST_RUN_TASK(TestFunction) запускает многопоточную функцию, параметр — пользовательская функция.
// Если не вызвать SET_THREAD_NUM(), по умолчанию будет 10 потоков.
HWTEST_F(AAFwkBaseObjectTest, Factorial_test_001, TestSize.Level1)
{
SET_THREAD_NUM(4); // устанавливаем количество потоков, в одном тестовом наборе можно динамически устанавливать количество потоков.
printf("Factorial_test_001 BEGIN\n");
GTEST_RUN_TASK(factorial_test); // запускаем многопоточное выполнение factorial_test
printf("Factorial_test_001 END\n");
}
// HWMTEST_F(TEST_SUITE, TEST_TC, TEST_LEVEL, THREAD_NUM)
// THREAD_NUM позволяет установить количество потоков для выполнения теста.
// HWMTEST_F создаёт указанное количество потоков и выполняет тестируемую функцию.
HWMTEST_F(AAFwkBaseObjectTest, Factorial_test_002, TestSize.Level1, 6)
{
printf("Factorial_test_002 BEGIN\n");
factorial_test();
printf("Factorial_test_002 END\n");
}
// Добавляем многопоточный интерфейс MTEST_ADD_TASK(THREAD_ID,ThreadTestFunc), регистрируем многопоточность, но не выполняем в этом сценарии использования, а затем выполняем все зарегистрированные многопоточные сценарии использования вместе.
// THREAD_ID начинается с 0 для определения разных потоков, также можно использовать случайный THREAD_ID, то есть передать RANDOM_THREAD_ID, в этом случае THREAD_ID не повторяется.
// MTEST_POST_RUN() используется для выполнения ранее зарегистрированных многопоточных сценариев использования.
Примечание: комментарии к сценарию соответствуют стандартам однопоточного сценария использования. При написании сценариев мы предоставляем четыре шаблона сценариев использования на выбор: | Тип | Описание | | ------------| ------------| | HWTEST(A,B,C)| Можно выбрать, если выполнение сценария не зависит от Setup&Teardown | | HWTEST_F(A,B,C)| Можно выбрать, если сценарий выполнения (без параметров) зависит от Setup&Teardown| | HWMTEST_F(A,B,C,D)| Можно выбрать, если многопоточный сценарий выполнения зависит от Setup&Teardown| | HWTEST_P(A,B,C)| Можно выбрать, если сценарий выполнения (с параметрами) зависит от Set&Teardown|
Где параметры A, B, C, D означают следующее:
Примечание:
TDD тестирование (JS)
AppInfoTest.js
/*
* Copyright (C) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import app from '@system.app'
import {describe, beforeAll, beforeEach,
``` **После каждого, после всех, это, ожидать} из 'deccjsunit/index'**
describe("AppInfoTest", function () {
beforeAll(function() {
// input testsuit setup step，setup invoked before all testcases
console.info('beforeAll caled')
})
afterAll(function() {
// input testsuit teardown step，teardown invoked after all testcases
console.info('afterAll caled')
})
beforeEach(function() {
// input testcase setup step，setup invoked before each testcases
console.info('beforeEach caled')
})
afterEach(function() {
// input testcase teardown step，teardown invoked after each testcases
console.info('afterEach caled')
})
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
* @tc.type: FUNC
* @tc.require: issueNumber
*/
it("appInfoTest001", 0, function () {
//step 1:调用函数获取结果
var info = app.getInfo()
//Step 2:使用断言比较预期与实际结果
expect(info != null).assertEqual(true)
})
})
**Подробное содержание:**
1. Добавление тестового файла с заголовком:
```
/*
* Copyright (C) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
```
2. Импорт тестируемого API и библиотеки jsunit:
```
import app from '@system.app'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
```
3. Определение тестового набора (теста):
```
describe("AppInfoTest", function () {
beforeAll(function() {
// input testsuit setup step，setup invoked before all testcases
console.info('beforeAll caled')
})
afterAll(function() {
// input testsuit teardown step，teardown invoked after all testcases
console.info('afterAll caled')
})
beforeEach(function() {
// input testcase setup step，setup invoked before each testcases
console.info('beforeEach caled')
})
afterEach(function() {
// input testcase teardown step，teardown invoked after each testcases
console.info('afterEach caled')
})
```
4. Реализация тестовых случаев:
```
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
* @tc.type: FUNC
* @tc.require: issueNumber
*/
it("appInfoTest001", 0, function () {
//step 1:调用函数获取结果
var info = app.getInfo()
//Step 2:使用断言比较预期与实际结果
expect(info != null).assertEqual(true)
})
```
*Примечание:* @tc.require должен начинаться с AR/SR или issue, например, issueI56WJ7. Конфиг("module_private_config") {
видимость = [ ":*" ]
include_dirs = [ "../../../../include" ]
}
ohos_unittest("CalculatorSubTest") {
модуль_аут_путь = модуль_оутпут_путь
сорсес = [
"../../../../include/calculator.h",
"../../../../src/calculator.cpp",
]
сорсес += [ "calculator_sub_test.cpp" ]
конфигс = [ ":module_private_config" ]
депс = [ "//third_party/googletest:gtest_main" ]
}
груп("unittest") {
тестонли = тру
депс = [":CalculatorSubTest"]
}
Подробное содержание:
# Copyright (c) 2021 XXXX Device Co., Ltd.
import("//build/test.gni")
модуль_оутпут_путь = "developer_test/calculator"
Примечание: этот путь является именем модуля или компонента.
конфиг("module_private_config") {
видимость = [ ":*" ]
include_dirs = [ "../../../../include" ]
}
Примечание: обычно здесь устанавливаются соответствующие конфигурации, которые можно напрямую ссылаться в сценарии компиляции тестовых случаев.
ohos_unittest("CalculatorSubTest") {
}
ohos_unittest("CalculatorSubTest") {
модуль_аут_путь = модуль_оутпут_путь
сорсес = [
"../../../../include/calculator.h",
"../../../../src/calculator.cpp",
"../../../test/calculator_sub_test.cpp"
]
сорсес += [ "calculator_sub_test.cpp" ]
конфигс = [ ":module_private_config" ]
депс = [ "//third_party/googletest:gtest_main" ]
}
Примечание: в зависимости от типа теста, можно выбрать различные типы тестов при написании конкретных сценариев: ohos_unittest — модульный тест, ohos_js_unittest — тест модели JavaScript, ohos_moduletest — модульный тест и т. д.
груп("unittest") {
тестонли = тру
депс = [":CalculatorSubTest"]
}
Примечание: цель группировки заключается в том, чтобы выборочно выполнять определённые типы тестов во время выполнения. Совместимый: 4,
Цель: 5 // Согласно версии тестируемого SDK, в данном примере это SDK5.
…
Далее идёт код на языке программирования, который не был переведён.
…
6. Группировка тестовых случаев по условиям
group("unittest") { testonly = true deps = [ ":GetAppInfoJsTest" ] }
Примечание: Цель группировки по условиям — при выполнении тестов можно выборочно запускать определённый тип тестов.
— Пример конфигурации для компиляции тестовых сценариев модели этапа
import("//build/test.gni")
want_output_path = "developer_test/stage_test"
ohos_js_stage_unittest("ActsBundleMgrStageEtsTest") { hap_profile = "entry/src/main/module.json" deps = [ ":actbmsstageetstest_js_assets", ":actbmsstageetstest_resources", ] ets2abc = true certificate_profile = "signature/openharmony_sx.p7b" hap_name = "ActsBundleMgrStageEtsTest" subsystem_name = "developer_test" part_name = "stage_test" // Имя компонента module_out_path = want_output_path // Необходимо определить путь вывода } ohos_app_scope("actbmsstageetstest_app_profile") { app_profile = "AppScope/app.json" sources = [ "AppScope/resources" ] } ohos_js_assets("actbmsstageetstest_js_assets") { source_dir = "entry/src/main/ets" } ohos_resources("actbmsstageetstest_resources") { sources = [ "entry/src/main/resources" ] deps = [ ":actbmsstageetstest_app_profile" ] hap_profile = "entry/src/main/module.json" } group("unittest") { testonly = true deps = [] deps += [ ":ActsBundleMgrStageEtsTest" ] }
Примечание: Цель группировки по условиям — при выполнении тестов можно выборочно запускать определённый тип тестов.
Файл конфигурации входа для сборки bundle.json
После завершения написания конфигурационного файла для компиляции тестов необходимо дополнительно написать файл конфигурации для сборки компонентов, чтобы связать его с конкретными тестами.
"build": {
"sub_component": [
"//test/testfwk/developer_test/examples/app_info:app_info",
"//test/testfwk/developer_test/examples/detector:detector",
"//test/testfwk/developer_test/examples/calculator:calculator"
],
"inner_list": [
{
"header": {
"header_base": "////test/testfwk/developer_test/examples/detector/include",
"header_files": [
"detector.h"
]
},
"name": "//test/testfwk/developer_test/examples/detector:detector"
}
],
"test": [ // Конфигурация тестов модуля calculator
"//test/testfwk/developer_test/examples/app_info/test:unittest",
"//test/testfwk/developer_test/examples/calculator/test:unittest",
"//test/testfwk/developer_test/examples/calculator/test:fuzztest"
}
Примечание: В test_list настраиваются тесты для соответствующего модуля.
Ресурсы, необходимые для выполнения тестов, включают файлы изображений, видеофайлы и внешние библиотеки, которые нужны тестам во время выполнения. На данный момент поддерживается только конфигурация статических ресурсов.
Шаги по настройке файлов ресурсов для зависимостей тестов:
Создайте каталог resource в каталоге test компонента. В каталоге resource создайте соответствующий модуль, а затем поместите файлы ресурсов, необходимые модулю, в этот каталог.
Текст запроса:
在resource目录下对应的模块目录中创建一个ohos_test.xml文件，文件内容格式如下:
<?xml version="1.0" encoding="UTF-8"?>
<configuration ver="2.0">
<target name="CalculatorSubTest">
<preparer>
<option name="push" value="test.jpg -> /data/test/resource" src="res"/>
<option name="push" value="libc++.z.so -> /data/test/resource" src="out"/>
</preparer>
</target>
</configuration>
**说明：**若某些push上去的二进制文件需要增量生成数据字典，则新增一行：
<option name="shell" value="hilog -d /设备中的二进制文件路径"/>
// 例如
<option name="shell" value="hilog -d /data/test/resource/test.z.so"/>
ohos_unittest("CalculatorSubTest") {
resource_config_file = "//system/subsystem/partA/test/resource/calculator/ohos_test.xml"
}
说明：
- target_name: 测试套的名称，定义在测试目录的BUILD.gn中。preparer: 表示该测试套执行前执行的动作。
- src="res": 表示测试资源位于test目录下的resource目录下，src="out"：表示位于out/release/$(部件)目录下。
Перевод текста на русский язык:
В каталоге resource соответствующего модуля создайте файл ohos_test.xml. Формат файла:
<?xml version="1.0" encoding="UTF-8"?>
<configuration ver="2.0">
<target name="CalculatorSubTest">
<preparer>
<option name="push" value="test.jpg -> /data/test/resource" src="res"/>
<option name="push" value="libc++.z.so -> /data/test/resource" src="out"/>
</preparer>
</target>
</configuration>
Примечание: Если для некоторых файлов, которые вы отправляете с помощью команды push, необходимо создать инкрементный словарь данных, добавьте следующую строку:
<option name="shell" value="hilog -d /путь к двоичному файлу на устройстве"/>
# Например
<option name="shell" value="hilog -d /data/test/resource/test.z.so"/>
В файле конфигурации компиляции тестового примера определите resource_config_file, чтобы указать соответствующий файл ресурсов ohos_test.xml:
ohos_unittest("CalculatorSubTest") {
resource_config_file = "/system/subsystem/partA/test/resource/calculator/ohos_test.xml"
}
Примечание: target_name — имя набора тестов, которое определяется в файле BUILD.gn каталога тестов. preparer — действие, выполняемое перед выполнением набора тестов. src="res" — ресурсы теста находятся в каталоге resource, который находится в каталоге test. src="out" — ресурсы находятся в каталоге out/release/(компонент). Данный каталог содержит следующие категории результатов: | Тип | Описание| | ------------ | ------------ | | result/ | Результаты форматирования тестовых случаев| | log/plan_log_xxxx_xx_xx_xx_xx_xx.log | Журналы тестовых случаев | | summary_report.html | Сводный отчёт о тестировании | | details_report.html | Подробный отчёт о тестировании|
reports/platform_log_xxxx_xx_xx_xx_xx_xx.log
(Необязательно к выполнению) Чтобы скрыть избыточные данные о ветвлении, которые генерируются неключевым кодом, можно выполнить следующее перед компиляцией исходного кода:
python3 build_before_generate.py
Выберите соответствующий компонент и выполните команду, например:
run -tp partname
run -tp partname1 partname2
Перед компиляцией версии сначала измените параметры компиляции, добавив поле --coverage в соответствующие опции cflags или ldflags в файле build.gn для вашей подсистемы:
ldflags = [ "--coverage" ]
C: cflags = [ "--coverage" ]
C++: cflags_cc = [ "--coverage" ]
Рекомендуется: Также можно использовать метод для оконных подсистем (рекомендуется), см. ссылку: https://gitee.com/openharmony/window_window_manager/pulls/1274/files 3. Для выполнения покрытия кода необходимо установить следующие зависимости:
1) Установите lcov, используя команду: sudo apt install lcov
2) Установите dos2unix, используя команду: apt install dos2unix.
3) Установите lxml, используя команду pip install lxml
4) Установите selectolax, используя команду pip install selectolax
5) Установите CppHeaderParser, используя команду pip install CppHeaderParser
Подключите удаленное устройство, измените IP-адрес в usr_config.xml:
Выполните команду:
./start.sh
Пример команды: run -t UT -tp 部件名 -cov coverage run -t UT -ss 子系统名 -cov coverage run -t UT -ss 子系统名 -tp 部件名 -cov coverage run -t UT MST ST -tp 部件名 -cov coverage
Примечание: Обязательно добавьте параметр -cov coverage.
Код покрытия: /test/testfwk/developer_test/localCoverage/codeCoverage/results/coverage/reports/cxx/html
Отчёт о покрытии интерфейса: /test/testfwk/developer_test/localCoverage/interfaceCoverage/results/coverage/interface_kits/html
| Номер версии выпуска | Описание функций выпуска |
|---|---|
| 3.2.1.0 | 1、Добавлена возможность выполнения тестовых примеров ACTS с использованием фреймворка 2、Добавлены различные уровни детализации выполнения для ACTS, такие как подсистема и компонент |
| 3.2.2.0 | 1、Добавлена функция статистики тестовых задач, максимум 10 задач 2、Добавлена функция выполнения тестовой задачи по указанному идентификатору тестовой задачи 3、Добавлена функция повторного тестирования неудачных тестовых примеров |
| 3.2.3.0 | 1、Добавлено покрытие кода |
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )