X Test Suite

• Introduction

• Devices

• Directory Structure

• Constraints

• Usage Guidelines

• Test Case Development Guidelines

  • C-based Test Case Development and Compilation (for Mini-System Devices)
  • C-based Test Case Execution (for Mini-System Devices)

• Repositories Involved

Introduction

The X test suite (XTS) subsystem contains 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.

This subsystem contains the ACTS 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.

Devices

OpenHarmony supports the following device types:

• Mini-System Devices (reference memory ≥ 128 KB)

  Such devices are equipped with MCU processors such as ARM Cortex-M and 32-bit RISC-V. They provide rich short-distance connection and peripheral bus access capabilities. Typical products include LinkIoT module devices and sensors in the smart home field. The LinkIoT module is usually used for smart Internet of Things (IoT) devices as the hardware module that implements connectivity functions. In the smart home field, the LinkIoT module is integrated into devices by vendors. For example, a LinkIoT module provides WLAN/Bluetooth access and data connection, and it usually communicates with the chip of smart home devices via a universal asynchronous receiver-transmitter (UART) or general-purpose input/output (GPIO) interface.

• Small-System Devices (reference memory ≥ 1 MB)

  Such devices are equipped with application processors such as ARM Cortex-A. They provide higher security capabilities, standard graphics framework, and multimedia capabilities for video encoding and decoding. Typical products include IP cameras, electronic cat eyes, and routers in the smart home field, as well as event data recorders (EDRs) in the smart travel field.

Directory Structure

/test/xts
├── acts                 # Test code
│   └── subsystem       # Source code of subsystem test cases for large-system devices
│   └── subsystem_lite  # Source code of subsystems test cases for mini- and small-system devices
│   └── BUILD.gn        # Build configuration of test cases for large-system devices
│   └── build_lite      # Build configuration of test cases for mini-and small-system devices
│       └── build_lite    # Build configuration
└── tools                # Test tool code

Constraints

Test cases for mini system devices must be developed based on C, and those for small system devices must be developed based on C++.

Usage Guidelines

Table 1 Test case levels

Table 2 Test case granularities

Table 3 Test types

Test Case Development Guidelines

You should select the appropriate programming language and your target test framework to develop test cases for the devices to test.

Table 4 Test frameworks and test case languages for different devices

C-based Test Case Development and Compilation (for Mini-System Devices)

Developing test cases for mini-system devices

The HCTest framework is used to support test cases developed with the C language. HCTest is enhanced and adapted based on the open-source test framework Unity.

1. Access the test/xts/acts repository where the test cases will be stored.

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

2. Write the test case in the src directory.

   1 Import the test framework header file.

   #include "hctest.h"
   2. Use the LITE_TEST_SUIT macro to define names of the subsystem, module, and test suite.

   /**  
   * @brief  Registers a test suite named IntTestSuite.
   * @param  test Subsystem name
   * @param  example Module name
   * @param  IntTestSuite Test suite 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 properties (including type, granularity, and level).

   LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1) 
   {  
     // Do something 
   };
   5. Use the RUN_TEST_SUITE macro to register the test suite.

   RUN_TEST_SUITE(IntTestSuite);

3. Create the configuration file (BUILD.gn) 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/lite/build/suite_lite.gni")
   hctest_suite("ActsDemoTest") {
       suite_name = "acts"
       sources = [
           "src/test_demo.c",
       ]
       include_dirs = [ ]
       cflags = [ "-Wno-error" ]
   }

4. 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_lite/BUILD.gn script in the acts directory.

   lite_component("acts") {  
       ...
       if(board_name == "liteos_m") {
           features += [    
               ...
               "//xts/acts/subsystem_lite/module_hal:ActsDemoTest"
           ]    
       }
   }

5. Run compilation commands.

   Test suites are compiled along with version compilation. The ACTS is compiled together with the debug version.

   NOTE: The ACTS compiles middleware as a static library, which will be linked to the image.

C-based Test Case Execution (for Mini-System Devices)

Executing test cases for mini-system devices

Burn the image into the development board.

Executing the test

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.

Analyzing the test result

View the serial port logs, whose 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.

Repositories Involved

xts_acts

xts_tools