429 Star 2.3K Fork 515

OpenHarmony / docs

Create your Gitee Account
Explore and code with more than 5 million developers,Free private repositories !:)
Sign up
Clone or download
x-test-suite-certification-subsystem.md 18.55 KB
Copy Edit Web IDE Raw Blame History
NEEN authored 2020-09-25 09:48 . !134 Docs Update 0924

X Test Suite Certification Subsystem

Overview

X test suite is a set of OpenHarmony certification test suites, including the currently supported application compatibility test suite (ACTS) and the device compatibility test suite (DCTS) that will be supported in the future.

The test/xts repository contains the acts directory and tools software package.

  • The acts directory stores the source code and configuration files of ACTS test cases. The ACTS helps device vendors detect the software incompatibility as early as possible and ensures that the software is compatible to OpenHarmony during the entire development process.
  • The tools software package stores the test case development framework related to acts.

Directory Structure

The directory structure of the test/xts repository is as follows:

├── acts

│ ├── BUILD.gn #Compilation configuration of test cases

│ └── subsystem_lite # Test case source code

└── tools

│ └── build #Templates and scripts related to test cases compilation

│ └── hcpptest #Source code of the development framework for SmartVision device (IP camera) test cases

│ └── hctest #Source code of the development framework for IoTLink module test cases

│ └── BUILD.gn #Compilation configuration

│ └── build.sh #Compiling entry

Constraints

You must use the C language to develop IoTLink module ACTS cases, and C++ for SmartVision device (IP camera) ACTS cases.

ACTS Cases for the IoTLink Module

The HCTest framework is used.

The HCTest framework supports the C language and allows you to execute your test cases on the connecting module. The framework is enhanced and adapted based on the open-source test framework Unity.

  1. Store test cases in the test/xts/acts repository.

├── acts

│ ├── BUILD.gn

│ └──subsystem_lite

│ │ └── module_hal

│ │ │ └── BUILD.gn

│ │ │ └── src

  1. Write the test case stored in the src directory.

(1) Import the test framework.

#include "hctest.h"

(2) Use the LITE_TEST_SUIT macro to define names of the subsystem, module, and test suite.

/**  
* @brief  register a test suit named "IntTestSuite"  
* @param  test subsystem name  
* @param  example module name  
* @param  IntTestSuite test suit name  
*/
LITE_TEST_SUIT(test, example, IntTestSuite);

(3) Define Setup and TearDown.

Format: test suite name+Setup, test suite name+TearDown.

The Setup and TearDown functions must exist, but function bodies can be empty.

(4) Use the LITE_TEST_CASE macro to write the test case.

Three parameters are involved: test suite name, test case name, and test case level.

The case level can be one of the following:

Level0, Level1, Level2, Level3, and Level4.

LITE_TEST_CASE(IntTestSuite, TestCase001, Level0) 
{  
  // Do something.
};

The following table describes the case levels.

Level

Definition

Testing Scope

Level0

Smoke

Verifies basic functionalities of key features and basic DFX attributes with the most common input. The pass result indicates that the features are runnable.

Level1

Basic

Verifies basic functionalities of key features and basic DFX attributes with common input. The pass result indicates that the features are testable.

Level2

Major

Verifies basic functionalities of key features and basic DFX attributes with common input and errors. The pass result indicates that the features are functional and ready for beta testing.

Level3

Regular

Verifies functionalities of all key features, and all DFX attributes with common and uncommon input combinations or normal and abnormal preset conditions.

Level4

Rare

Verifies functionalities of key features under extremely abnormal presets and uncommon input combinations.

(5) Use the RUN_TEST_SUITE macro to register the test suite.

RUN_TEST_SUITE(IntTestSuite);
  1. Create the configuration file of the test module.

Create a BUILD.gn (example) compilation file in each test module directory. Specify the name of the compiled static library and its dependent header file and library in the compilation file. The format is as follows:

import("//test/xts/tools/build/suite_lite.gni")
hctest_suite("ActsDemoTest") {
    suite_name = "acts"
    sources = [
        "src/test_demo.c",
    ]
    include_dirs = [ ]
    cflags = [ "-Wno-error" ]
}
  1. Add compilation options to the BUILD.gn file in the acts directory.

You need to add the test module to the test/xts/acts/BUILD.gn script in the acts directory.

lite_component("acts") {
    ...
    if(board_name == "liteos_riscv") {
        features += [
            ...
            "//xts/acts/subsystem_lite/module_hal:ActsDemoTest"
        ]
    }
}
  1. Run compilation commands.

(1) python build.py wifiiot -b debug

(2) out/wifiiot

Note: The ACTS compilation middleware used for IoTLink modules is a static library, which will be linked to the version image Hi3861_wifiiot_app_allinone.bin.

ACTS Cases for the SmartVision Device (IP Camera)

The HCPP Test framework is enhanced and adapted based on the open-source googletest framework.

  1. Store test cases in the test/xts/acts repository.

├── acts

│ ├── BUILD.gn

│ └──subsystem_lite

│ │ └── module_posix

│ │ │ └── BUILD.gn

│ │ │ └── src

  1. Write the test case stored in the src directory.

(1) Import the test framework.

The following statement imports gtest.h.

#include "gtest/gtest.h"

(2) Define Setup and TearDown.

class TestSuite: public testing::Test {
protected:
// Preset action of the test suite, which is executed before the first test case
static void SetUpTestCase(void){
}
// Test suite cleanup action, which is executed after the last test case
static void TearDownTestCase(void){
}
// Preset action of the test case
virtual void SetUp()
{
}
// Cleanup action of the test case
virtual void TearDown()
{
}
};

(3) Use the HWTEST or HWTEST_F macro to write the test case.

HWTEST: definition of common test cases, including the test suite name, test case name, and case marking.

HWTEST_F: definition of SetUp and TearDown test cases, including the test suite name, test case name, and case marking.

A macro definition contains three parameters: test suite name, test case name, and test case level.

The case level can be one of the following:

Level0, Level1, Level2, Level3, and Level4.

HWTEST_F(TestSuite, TestCase_0001, Level0) {
// Do something.
}

The following table describes the case levels.

Level

Definition

Testing Scope

Level0

Smoke

Verifies basic functionalities of key features and basic DFX attributes with the most common input. The pass result indicates that the features are runnable.

Level1

Basic

Verifies basic functionalities of key features and basic DFX attributes with common input. The pass result indicates that the features are testable.

Level2

Major

Verifies basic functionalities of key features and basic DFX attributes with common input and errors. The pass result indicates that the features are functional and ready for beta testing.

Level3

Regular

Verifies functionalities of all key features, and all DFX attributes with common and uncommon input combinations or normal and abnormal preset conditions.

Level4

Rare

Verifies functionalities of key features under extremely abnormal presets and uncommon input combinations.

  1. Create the configuration file of the test module.

Create a BUILD.gn (example) compilation file in each test module directory. Specify the name of the compiled static library and its dependent header file and library in the compilation file. Each test module is independently compiled into a .bin executable file, which can be directly mounted to the development board for testing.

The following is an example:

import("//test/xts/tools/build/suite_lite.gni")

hcpptest_suite("ActsDemoTest") {
    suite_name = "acts"
    sources = [
        "src/TestDemo.cpp"
    ]

    include_dirs = [
        "src",
        ...
    ]
    deps = [
        ...
    ]
    cflags = [ "-Wno-error" ]
}
  1. Add compilation options to the BUILD.gn file in the acts directory.

You need to add the test module to the test/xts/acts/BUILD.gn script in the acts directory.

 lite_component("acts") {
...
else if(board_name == "liteos_a") {
        features += [
            ...
            "//xts/acts/subsystem_lite/module_posix:ActsDemoTest"
        ]
    }
}
  1. Run compilation commands.

1.1 Hi3518EV300

(1) python build.py ipcamera_hi3518ev300 -b debug

(2) out/ipcamera_hi3518ev300

1.2 Hi3516DV300

(1) python build.py ipcamera_hi3516dv300 -b debug

(2) out/ipcamera_hi3516dv300

Note: The ACTS for the SmartVision device (IP camera) is independently compiled to a .bin executable file, which can be directly mounted to the development board for testing.

Executing ACTS Cases for the IoTLink Module

  1. Obtain the testing software package.

Obtain the image from the out\wifiiot\Hi3861_wifiiot_app_allinone.bin directory.

Note: To check whether the ACTS is integrated into the current image, go to out\wifiiot\Hi3861_wifiiot_app.map to check whether the corresponding .a file is compiled.

  1. Burn the image into the development board.

  2. Perform testing.

(1) Use a serial port tool to log in to the development board and save information about the serial port.

(2) Restart the device and view serial port logs.

  1. Analyze the test result.

View the serial port logs, and the format is as follows:

The log for each test suite starts with Start to run test suite: and ends with xx Tests xx Failures xx Ignored.

Executing ACTS Cases for the SmartVision Device (IP Camera)

Currently, test cases are shared by the NFS and mounted to the development board for execution.

  1. Set up the environment.

  2. Use a network cable or wireless network to connect the IP camera development board to your personal computer (PC).

  3. Configure the IP address, subnet mask, and gateway for the IP camera development board. Ensure that the development board and the PC are in the same network segment.

  4. Install and register the NFS server on the PC and start the NFS service.

  5. Run the mount command for the IP camera development board to ensure that the development board can access NFS shared files on the PC.

    Format: mount NFS server IP address:/NFS shared directory/IP camera development board directory** nfs**

    Example:

    mount 192.168.1.10:/nfs /nfs nfs
  6. Execute test cases.

(1) Analyze serial port logs.

(2) Run the ./Test module.bin command to execute test cases of each test suite.

Repositories Involved

xts_acts

xts_tools_lite

1
https://gitee.com/openharmony/docs.git
git@gitee.com:openharmony/docs.git
openharmony
docs
docs
master

Search