@@ -15,15 +15,15 @@ OpenHarmony supports the following system types:
- Mini system
A mini system runs on the devices whose memory is greater than or equal to 128 KiB and that are equipped with MCU processors such as ARM Cortex-M and 32-bit RISC-V. This system provides multiple lightweight network protocols and graphics frameworks, and a wide range of read/write components for the IoT bus. Typical products include connection modules, sensors, and wearables for smart home.
A mini system runs on the devices whose memory is greater than or equal to 128 KiB and that are equipped with MCU processors such as ARM Cortex-M and 32-bit RISC-V. This system provides multiple lightweight network protocols and graphics frameworks, and a wide range of read/write components for the IoT bus. Typical products include connection modules, sensors, and wearables for smart home. Typical boards include Multi-modalV200Z-R.
- Small system
A small system runs on the devices whose memory is greater than or equal to 1 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides higher security capabilities, standard graphics frameworks, and video encoding and decoding capabilities. Typical products include smart home IP cameras, electronic cat eyes, and routers, and event data recorders \(EDRs\) for smart travel.
A small system runs on the devices whose memory is greater than or equal to 1 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides higher security capabilities, standard graphics frameworks, and video encoding and decoding capabilities. Typical products include smart home IP cameras, electronic cat eyes, and routers, and event data recorders \(EDRs\) for smart travel. Typical boards include Hispark_Taurus.
- Standard system
A standard system runs on the devices whose memory is greater than or equal to 128 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides a complete application framework supporting the enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. This system applies to high-end refrigerator displays.
A standard system runs on the devices whose memory is greater than or equal to 128 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides a complete application framework supporting the enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. This system applies to high-end refrigerator displays. Typical boards include HopeRun DAYU200.
## Directory Structure
...
...
@@ -110,88 +110,94 @@ The HCTest framework is used to support test cases developed with the C language
│ │ └── BUILD.gn
```
2.Write the test case in the **src** directory.
2. Write the test case in the **src** directory.
1 Import the test framework header file.
1. Import the test framework header file.
```
#include "hctest.h"
```
```
#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);
```
2. Use the **LITE\_TEST\_SUIT** macro to define names of the subsystem, module, and test suite.
3. Define Setup and TearDown.
```
/**
* @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);
```
Format: Test suite name+Setup, Test suite name+TearDown.
3. Define Setup and TearDown.
The Setup and TearDown functions must exist, but function bodies can be empty.
Format: Test suite name+Setup, Test suite name+TearDown.
4. Use the **LITE\_TEST\_CASE** macro to write the test case.
The Setup and TearDown functions must exist, but function bodies can be empty.
Three parameters are involved: test suite name, test case name, and test case properties \(including type, granularity, and level\).
4. Use the **LITE\_TEST\_CASE** macro to write the test case.
```
LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1)
{
// Do something
};
```
Three parameters are involved: test suite name, test case name, and test case properties \(including type, granularity, and level\).
5. Use the **RUN\_TEST\_SUITE** macro to register the test suite.
```
LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1)
{
// Do something
};
```
```
RUN_TEST_SUITE(IntTestSuite);
```
3. Create the configuration file \(**BUILD.gn**\) of the test module.
5. Use the **RUN\_TEST\_SUITE** macro to register the test suite.
Create a **BUILD.gn** \(example\) build file in each test module directory. Specify the name of the built static library and its dependent header file and library in the build file. The format is as follows:
4. Add build options to the **BUILD.gn** file in the **acts** directory.
3. Create the configuration file \(**BUILD.gn**\) of the test module.
You need to add the test module to the **test/xts/acts/build\_lite/BUILD.gn** script in the **acts** directory.
Create a **BUILD.gn**\(example\) build file in each test module directory. Specify the name of the built static library and its dependent header file and library in the build file. The format is as follows: