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

OSCHINA-MIRROR/openharmony-testfwk_developer_test

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
README_zh.md 41 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 24.11.2024 19:50 c0b36c1

Разработка и тестирование программного обеспечения с помощью OpenHarmony

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++)

  • Соглашения об именах файлов тестовых сценариев: Имена файлов тестовых сценариев соответствуют их содержанию и имеют формат [функция]_[подфункция]_test, где подфункция может быть дополнительно разделена.

Однопоточный пример: 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);
    }

Более подробно:

  1. Добавьте информацию о заголовке файла тестового сценария.
    /*
     * Copyright (c) 2021 XXXX Device Co., Ltd.
     * Licensed under the
    ``` **Apache License, Version 2.0**
    

(«Лицензия»);

  • вы не можете использовать этот файл, кроме как в соответствии с Лицензией.

  • Вы можете получить копию Лицензии по адресу:

    http://www.apache.org/licenses/LICENSE-2.0

  • Если это не требуется применимым законодательством или не согласовано в письменной форме, программное обеспечение, распространяемое по Лицензии, распространяется на условиях «КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ ИЛИ УСЛОВИЙ ЛЮБОГО РОДА, явных или подразумеваемых. См. Лицензию для конкретного языка, регулирующего разрешения и ограничения по Лицензии.

2. Ссылка на заголовочный файл тестового фреймворка и пространство имён

#include <gtest/gtest.h> using namespace testing::ext;

  1. Включить заголовочный файл тестируемого класса
#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 }

> **Примечание:** При определении тестового набора имя тестового набора должно соответствовать цели компиляции, используя стиль больших верблюжьих букв.
  1. Реализация тестовых случаев, включая комментарии к случаям и логическую реализацию
/**
 * @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

Подробное содержание:

  1. Добавить комментарий заголовка файла тестового случая.

Примечание: Соответствует стандарту однопоточного случая.

  1. Ссылаться на заголовочные файлы тестового фреймворка и пространства имён.
#include <gtest/gtest.h>
#include <gtest/hwext/gtest-multithread.h> ```
#include <unistd.h>
using namespace testing::ext;
using namespace testing::mt;
  1. Добавляем заголовочный файл тестируемого класса:
#include "base_object.h"
  1. Определяем тестовый набор (тестовый класс):
class AAFwkBaseObjectTest : public testing::Test {......}

Примечание: соответствует стандартам однопоточных сценариев использования.

  1. Реализуем тестовые сценарии, включая комментарии к сценариям и логическую реализацию:
// 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 означают следующее:

  • Параметр A — имя тестового набора.
  • Параметр B — имя сценария использования, которое должно соответствовать формату [функциональная точка]_[номер], номер состоит из трёх цифр, начиная с 001.
  • Параметр C — уровень сценария использования, всего пять уровней: уровень блокировки gate level0 и уровни без блокировки non-gate level1–level4, где уровень без блокировки level1–level4 определяется следующим образом: чем важнее функция, тем ниже уровень.
  • Параметр D — количество потоков для многопоточного выполнения сценария использования.

Примечание:

  • В сценарии использования должны быть соответствующие утверждения.
  • Сценарий использования должен иметь уровень.
  • Рекомендуется реализовать тестовое тело в соответствии с шаблоном.
  • Информация о сценарии использования должна быть записана в стандартном формате @tc.xxx value, комментарий должен содержать имя сценария использования, описание сценария использования, тип сценария использования и номер требования. Среди типов сценариев использования @tc.type, можно обратиться к следующей таблице.
  • При использовании HWMTEST_F для написания многопоточного сценария выполнения необходимо указать количество потоков. | Тип тестирования | Тип кодирования | | ------------|------------| | Функциональное тестирование | FUNC| | Тестирование производительности | PERF| | Надёжное тестирование | RELI| | Безопасное тестирование | SECU| | Нечёткое тестирование | FUZZ|

TDD тестирование (JS)

  • Правила именования файлов сценариев использования Тестовые файлы сценариев использования используют стиль больших горбов, заканчиваются на TEST, формат: [функция][подфункция]TEST, подфункция может быть дополнительно разделена. Пример:
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"]
}

Подробное содержание:

  1. Добавить файл заголовка с комментариями:
# Copyright (c) 2021 XXXX Device Co., Ltd.
  1. Импортировать файл шаблона сборки:
import("//build/test.gni")
  1. Указать путь вывода файла:
модуль_оутпут_путь = "developer_test/calculator"

Примечание: этот путь является именем модуля или компонента.

  1. Настроить конфигурацию включаемых каталогов:
конфиг("module_private_config") {
  видимость = [ ":*" ]
   
  include_dirs = [ "../../../../include" ]
}

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

  1. Определить имя выходного файла для тестового случая:
ohos_unittest("CalculatorSubTest") {
}
  1. Написать конкретный сценарий компиляции тестового примера (добавить файлы исходного кода, конфигурацию и зависимости):
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 — модульный тест и т. д.

  1. Группировать тестовые примеры по условиям:
груп("unittest") {
  тестонли = тру
  депс = [":CalculatorSubTest"]
}

Примечание: цель группировки заключается в том, чтобы выборочно выполнять определённые типы тестов во время выполнения. Совместимый: 4,
Цель: 5 // Согласно версии тестируемого SDK, в данном примере это SDK5.

Далее идёт код на языке программирования, который не был переведён.

6. Группировка тестовых случаев по условиям

group("unittest") { testonly = true deps = [ ":GetAppInfoJsTest" ] }

Примечание: Цель группировки по условиям — при выполнении тестов можно выборочно запускать определённый тип тестов.

Пример конфигурации для компиляции тестовых сценариев модели этапа

Copyright (C) 2022 XXXX Device Co., Ltd.

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 настраиваются тесты для соответствующего модуля.

Конфигурация ресурсов для тестов

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

Шаги по настройке файлов ресурсов для зависимостей тестов:

  1. Создайте каталог resource в каталоге test компонента. В каталоге resource создайте соответствующий модуль, а затем поместите файлы ресурсов, необходимые модулю, в этот каталог.

  2. Текст запроса:

在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"/>
  1. 在测试用例的编译配置文件中定义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": 表示测试资源位于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 -&gt; /data/test/resource" src="res"/>
      <option name="push" value="libc++.z.so -&gt; /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

Руководство по покрытию кода тестами

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

    python3 build_before_generate.py

    Выберите соответствующий компонент и выполните команду, например:

    run -tp partname
    run -tp partname1 partname2
  2. Перед компиляцией версии сначала измените параметры компиляции, добавив поле --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
  1. Подключите удаленное устройство, измените IP-адрес в usr_config.xml:

  2. Выполните команду:

    ./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.

  1. Путь к отчёту о покрытии кода:

Код покрытия: /test/testfwk/developer_test/localCoverage/codeCoverage/results/coverage/reports/cxx/html

Отчёт о покрытии интерфейса: /test/testfwk/developer_test/localCoverage/interfaceCoverage/results/coverage/interface_kits/html

Связанные ресурсы

test_xdevice

Описание версии выпуска

Номер версии выпуска Описание функций выпуска
3.2.1.0 1、Добавлена возможность выполнения тестовых примеров ACTS с использованием фреймворка
2、Добавлены различные уровни детализации выполнения для ACTS, такие как подсистема и компонент
3.2.2.0 1、Добавлена функция статистики тестовых задач, максимум 10 задач
2、Добавлена функция выполнения тестовой задачи по указанному идентификатору тестовой задачи
3、Добавлена функция повторного тестирования неудачных тестовых примеров
3.2.3.0 1、Добавлено покрытие кода

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

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

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