From a6400ecd89a68a6b056a09e4c739a155d740be1c Mon Sep 17 00:00:00 2001 From: "ester.zhou" Date: Thu, 30 Dec 2021 15:21:47 +0800 Subject: [PATCH 1/3] update docs Signed-off-by: ester.zhou --- .../subsystems/subsys-testguide-test.md | 109 +++++++++--------- 1 file changed, 57 insertions(+), 52 deletions(-) diff --git a/en/device-dev/subsystems/subsys-testguide-test.md b/en/device-dev/subsystems/subsys-testguide-test.md index ac5aa3e7466..ff5fccb4dc0 100644 --- a/en/device-dev/subsystems/subsys-testguide-test.md +++ b/en/device-dev/subsystems/subsys-testguide-test.md @@ -39,21 +39,23 @@ subsystem # Subsystem │ │ ├── unittest # Unit test │ │ │ ├── common # Common test cases │ │ │ │ ├── BUILD.gn # Build file of test cases -│ │ │ │ ├── testA_test.cpp # Source code of unit test cases +│ │ │ │ └── testA_test.cpp # Source code of unit test cases │ │ │ ├── phone # Test cases for mobile phones │ │ │ ├── ivi # Test cases for head units │ │ │ └── liteos-a # Test cases for the IP cameras that use the LiteOS kernel -│ │ └── resource # Dependency resources -│ │ └── ohos_test.xml +│ │ ├── moduletest # Module test +│ │ ... +│ │ │ ├── moduleB # Module B │ ├── test -│ │ └── moduletest # Module test -│ │ ├── common -│ │ ├── phone -│ │ ├── ivi -│ │ └── liteos-a -│ │ ... -│ └── ohos_build # Build entry configuration +│ │ └── resource # Dependency resources +│ │ ├── moduleA # Module A +│ │ │ ├── ohos_test.xml # Resource configuration file +│ │ ... └── 1.txt # Resources +│ │ +│ ├── ohos_build # Build entry configuration +│ ... +│ ... ``` > **Note:** Test cases are classified into common test cases and device-specific test cases. You are advised to place common test cases in the **common** directory and device-specific test cases in the directories of the related devices. @@ -131,7 +133,7 @@ Example: { // Step 1 Call the function to obtain the result. int actual = Sub(4, 0); - + // Step 2 Use an assertion to compare the obtained result with the expected result. EXPECT_EQ(4, actual); } @@ -157,7 +159,7 @@ Example: 2. Add the test framework header file and namespace. ``` #include - + using namespace testing::ext; ``` 3. Add the header file of the test class. @@ -173,22 +175,22 @@ Example: void SetUp(); void TearDown(); }; - + void CalculatorSubTest::SetUpTestCase(void) { // Set a setup function, which will be called before all test cases. } - + void CalculatorSubTest::TearDownTestCase(void) { // Set a teardown function, which will be called after all test cases. } - + void CalculatorSubTest::SetUp(void) { // Set a setup function, which will be called before each test case. } - + void CalculatorSubTest::TearDown(void) { // Set a teardown function, which will be called after each test case. @@ -200,7 +202,7 @@ Example: ``` /** * @tc.name: integer_sub_001 - * @tc.desc: Verify the sub function. + * @tc.desc: Verify the sub-function. * @tc.type: FUNC * @tc.require: Issue Number */ @@ -208,14 +210,14 @@ Example: { // Step 1 Call the function to obtain the test result. int actual = Sub(4, 0); - + // Step 2 Use an assertion to compare the obtained result with the expected result. EXPECT_EQ(4, actual); } ``` The following test case templates are provided for your reference. - | Template| Description| + | Type| Description| | ------------| ------------| | HWTEST(A,B,C)| Use this template if the test case execution does not depend on setup or teardown.| | HWTEST_F(A,B,C)| Use this template if the test case execution (excluding parameters) depends on setup and teardown.| @@ -230,11 +232,15 @@ Example: - The expected result of each test case must have an assertion. - The test case level must be specified. - It is recommended that the test be implemented step by step according to the template. - - The comment must contain the test case name, description, type, and requirement number, which are in the @tc.xxx: value format. The test case type @tc.type can be any of the following: + - The comment must contain the test case name, description, type, and requirement number, which are in the @tc.*xxx*: *value* format. The test case type @**tc.type** can be any of the following: - | Test Case Type|Function test|Performance test|Reliability test|Security test|Fuzz test| - | ------------|------------|------------|------------|------------|------------| - | Code|FUNC|PERF|RELI|SECU|FUZZ| + | Test Case Type|Code| + | ------------|------------| + |Function test|FUNC| + |Performance test|PERF| + |Reliability test|RELI| + |Security test|SECU| + |Fuzz test|FUZZ| **JavaScript Test Case Example** @@ -297,7 +303,7 @@ Example: it("appInfoTest001", 0, function () { // Step 1 Call the function to obtain the test result. var info = app.getInfo() - + // Step 2 Use an assertion to compare the obtained result with the expected result. expect(info != null).assertEqual(true) }) @@ -324,7 +330,7 @@ Example: 2. Import the APIs and JSUnit test library to test. ``` import app from '@system.app' - + import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index' ``` 3. Define the test suite (test class). @@ -361,7 +367,7 @@ Example: it("appInfoTest001", 0, function () { // Step 1 Call the function to obtain the test result. var info = app.getInfo() - + // Step 2 Use an assertion to compare the obtained result with the expected result. expect(info != null).assertEqual(true) }) @@ -407,7 +413,7 @@ The following provides templates for different languages for your reference. deps = [":CalculatorSubTest"] } ``` - The build file is configured as follows: + The procedure is as follows: 1. Add comment information for the file header. ``` @@ -535,7 +541,7 @@ The following provides templates for different languages for your reference. certificate_profile = "//test/developertest/signature/openharmony_sx.p7b" } ``` - **config.json** is the configuration file required for HAP build. You need to set **target** based on the tested SDK version. Default values can be retained for other items. The following is an example: + **config.json** is the configuration file required for HAP build. You need to set **target** based on the tested SDK version. Default values can be retained for other items. The following is an example: ``` { @@ -606,9 +612,9 @@ The following provides templates for different languages for your reference. } ``` > **Note**: Grouping test cases by test type allows you to execute a specific type of test cases when required. - -#### Configuring ohos.build +#### Configuring ohos.build + Configure the part build file to associate with specific test cases. ``` "partA": { @@ -632,9 +638,9 @@ Configure the part build file to associate with specific test cases. Test case resources include external file resources, such as image files, video files, and third-party libraries, required for test case execution. Perform the following steps: -1. Under the **test** directory of a part or module, create the **resource** directory to store resource files. +1. Create the **resource** directory in the **test** directory of the part, and create a directory for the module in the **resource** directory to store resource files of the module. -2. In the **resource** directory, create the **ohos_test.xml** file in the following format: +2. In the module directory under **resource**, create the **ohos_test.xml** file in the following format: ``` @@ -649,14 +655,13 @@ Perform the following steps: 3. In the build file of the test cases, configure **resource\_config\_file** to point to the resource file **ohos\_test.xml**. ``` ohos_unittest("CalculatorSubTest") { - resource_config_file = "//system/subsystem/partA/calculator/test/resource/ohos_test.xml" + resource_config_file = "//system/subsystem/partA/test/resource/calculator/ohos_test.xml" } ``` >**Note:** - >- **target_name** indicates the test suite name defined in the **BUILD.gn** file in the **test** directory. - >- **preparer** indicates the action to perform before the test suite is executed. - >- **src="res"** indicates that the test resources are in the **resource** directory under the **test** directory. - >- **src="out"** indicates that the test resources are in the **out/release/$(part)** directory. + >- **target_name** indicates the test suite name defined in the **BUILD.gn** file in the **test** directory.**preparer** indicates the action to perform before the test suite is executed. + >- **src="res"** indicates that the test resources are in the **resource** directory under the **test** directory. **src="out"** indicates that the test resources are in the **out/release/$(*part*)** directory. + ## Executing Test Cases Before executing test cases, you need to modify the configuration based on the device used. @@ -715,18 +720,19 @@ Test cases cannot be built on Windows. You need to run the following command to ``` ./build.sh --product-name Hi3516DV300 --build-target make_test ``` ->**Note:** -> - --**product-name**: specifies the name of the product to build, for example, **Hi3516DV300**. -> - --**build-target**: specifies the target to build. It is optional. **make_test** indicates all test cases. You can set the build options based on requirements. +>Note: +>- **product-name**: specifies the name of the product to build, for example, **Hi3516DV300**. +>- **build-target**: specifies the test case to build. **make_test** indicates all test cases. You can specify the test cases based on requirements. -When the build is complete, the test cases are automatically saved in the **out/hi3516dv300/packages/phone/tests** directory. +After the build is complete, the test cases are automatically saved in **out/ohos-arm-release/packages/phone/tests**. #### Setting Up the Execution Environment 1. On Windows, create the **Test** directory in the test framework and then create the **testcase** directory in the **Test** directory. 2. Copy **developertest** and **xdevice** from the Linux environment to the **Test** directory on Windows, and copy the test cases to the **testcase** directory. + >**Note**: Port the test framework and test cases from the Linux environment to the Windows environment for subsequent execution. - + 3. Modify the **user_config.xml** file. ``` @@ -757,15 +763,15 @@ When the build is complete, the test cases are automatically saved in the **out/ ``` In the command: ``` - -t [TESTTYPE]: specifies the test type, which can be UT, MST, ST, or PERF. This parameter is mandatory. + -t [TESTTYPE]: specifies the test case type, which can be UT, MST, ST, or PERF. This parameter is mandatory. -tp [TESTPART]: specifies the part to test. This parameter can be used independently. -tm [TESTMODULE]: specifies the module to test. This parameter must be specified together with -tp. - -ts [TESTSUITE]: specifies the test suite. This parameter can be used independently. - -tc [TESTCASE]: specifies the test case. This parameter must be specified together with -ts. - You can run -h to display help information. + -ts [TESTSUITE]: specifies a test suite. This parameter can be used independently. + -tc [TESTCASE]: specifies a test case. This parameter must be specified together with -ts. + -You can run h to display help information. ``` ### Executing Test Cases on Linux -#### Mapping Remote Port +#### Mapping the Remote Port To enable test cases to be executed on a remote Linux server or a Linux VM, map the port to enable communication between the device and the remote server or VM. Configure port mapping as follows: 1. On the HDC server, run the following commands: ``` @@ -797,12 +803,12 @@ To enable test cases to be executed on a remote Linux server or a Linux VM, map ``` In the command: ``` - -t [TESTTYPE]: specifies the test type, which can be UT, MST, ST, or PERF. This parameter is mandatory. + -t [TESTTYPE]: specifies the test case type, which can be UT, MST, ST, or PERF. This parameter is mandatory. -tp [TESTPART]: specifies the part to test. This parameter can be used independently. -tm [TESTMODULE]: specifies the module to test. This parameter must be specified together with -tp. - -ts [TESTSUITE]: specifies the test suite. This parameter can be used independently. - -tc [TESTCASE]: specifies the test case. This parameter must be specified together with -ts. - You can run -h to display help information. + -ts [TESTSUITE]: specifies a test suite. This parameter can be used independently. + -tc [TESTCASE]: specifies a test case. This parameter must be specified together with -ts. + -You can run h to display help information. ``` ## Viewing the Test Report @@ -832,4 +838,3 @@ reports/platform_log_xxxx_xx_xx_xx_xx_xx.log ``` reports/latest ``` - -- Gitee From 5b3fbefa675de0f7f077f3614258b6d30c06ead4 Mon Sep 17 00:00:00 2001 From: "ester.zhou" Date: Thu, 30 Dec 2021 15:44:44 +0800 Subject: [PATCH 2/3] update docs Signed-off-by: ester.zhou --- en/device-dev/porting/Readme-EN.md | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/en/device-dev/porting/Readme-EN.md b/en/device-dev/porting/Readme-EN.md index 9200b31c666..57b44217b5c 100644 --- a/en/device-dev/porting/Readme-EN.md +++ b/en/device-dev/porting/Readme-EN.md @@ -1,4 +1,4 @@ -# Development Board Porting +# Introduction OpenHarmony has organized a Special Interest Group (SIG) [SIG_DevBoard](https://gitee.com/openharmony/community/blob/master/sig/sig-devboard/sig_devboard.md) to provide support for third-party development boards. Before learning about how to port the code of a development board, take a look at the device classification on OpenHarmony. The porting methods vary according to the device type. @@ -9,7 +9,7 @@ Before learning about how to port the code of a development board, take a look a | Small-system devices| Memory > 1 MB, with MMU| LiteOS-A and Linux| | Standard-system devices| Memory > 128 MB| Linux | -## Code Preparation +# Code Preparation OpenHarmony has created repositories for vendors in openharmony-sig. To participate in the repository development, you need to use the following method to initialize and download the code. @@ -19,7 +19,7 @@ repo init -u https://gitee.com/openharmony-sig/manifest.git -b master -m devboar The download steps for other resources are the same as those in the mainline version. -## Porting Procedure +# Porting Procedure - [Mini System SoC Porting Guide](porting-minichip.md) - [Porting Preparations](porting-chip-prepare.md) @@ -49,11 +49,10 @@ The download steps for other resources are the same as those in the mainline ver - [Overview](porting-smallchip-driver-overview.md) - [Platform Driver Porting](porting-smallchip-driver-plat.md) - [Device Driver Porting](porting-smallchip-driver-oom.md) -- [Standard System Porting Guide](standard-system-porting-guide.md) -- [A Method for Rapidly Porting the OpenHarmony Linux Kernel](porting-linux-kernel-overview.md) - -# Third-Party Library Porting Guide - -- [Overview](porting-thirdparty-overview.md) -- [Porting a Library Built Using CMake](porting-thirdparty-cmake.md) -- [Porting a Library Built Using Makefile](porting-thirdparty-makefile.md) +- Standard System SoC Porting Guide + - [Standard System Porting Guide](standard-system-porting-guide.md) + - [A Method for Rapidly Porting the OpenHarmony Linux Kernel](porting-linux-kernel.md) +- [Third-Party Library Porting Guide for Mini and Small Systems](porting-thirdparty.md) + - [Overview](porting-thirdparty-overview.md) + - [Porting a Library Built Using CMake](porting-thirdparty-cmake.md) + - [Porting a Library Built Using Makefile](porting-thirdparty-makefile.md) \ No newline at end of file -- Gitee From cef816b21a73e7643bb65689837623858b6bf799 Mon Sep 17 00:00:00 2001 From: "ester.zhou" Date: Thu, 30 Dec 2021 15:50:49 +0800 Subject: [PATCH 3/3] update docs Signed-off-by: ester.zhou --- en/device-dev/porting/Readme-EN.md | 233 ++++++++++++++++++++++------- 1 file changed, 175 insertions(+), 58 deletions(-) diff --git a/en/device-dev/porting/Readme-EN.md b/en/device-dev/porting/Readme-EN.md index 57b44217b5c..bbe11a57349 100644 --- a/en/device-dev/porting/Readme-EN.md +++ b/en/device-dev/porting/Readme-EN.md @@ -1,58 +1,175 @@ -# Introduction -OpenHarmony has organized a Special Interest Group (SIG) [SIG_DevBoard](https://gitee.com/openharmony/community/blob/master/sig/sig-devboard/sig_devboard.md) to provide support for third-party development boards. - -Before learning about how to port the code of a development board, take a look at the device classification on OpenHarmony. The porting methods vary according to the device type. - -| Device Type| Hardware Requirement| Supported Kernel| -|---------|-------------|----------------| -| Mini-system devices| Memory > 128 KB| LiteOS-M | -| Small-system devices| Memory > 1 MB, with MMU| LiteOS-A and Linux| -| Standard-system devices| Memory > 128 MB| Linux | - -# Code Preparation - -OpenHarmony has created repositories for vendors in openharmony-sig. To participate in the repository development, you need to use the following method to initialize and download the code. - -```shell -repo init -u https://gitee.com/openharmony-sig/manifest.git -b master -m devboard.xml --no-repo-verify -``` - -The download steps for other resources are the same as those in the mainline version. - -# Porting Procedure - -- [Mini System SoC Porting Guide](porting-minichip.md) - - [Porting Preparations](porting-chip-prepare.md) - - [Before You Start](oem_transplant_chip_prepare_knows.md) - - [Building Adaptation Process](porting-chip-prepare-process.md) - - [Kernel Porting](porting-chip-kernel.md) - - [Overview](porting-chip-kernel-overview.md) - - [Basic Kernel Adaptation](porting-chip-kernel-adjustment.md) - - [Kernel Porting Verification](porting-chip-kernel-verify.md) - - [Board-Level OS Porting](porting-chip-board.md) - - [Overview](porting-chip-board-overview.md) - - [Board-Level Driver Adaptation](porting-chip-board-driver.md) - - [Implementation of APIs at the HAL](porting-chip-board-hal.md) - - [System Modules](porting-chip-board-component.md) - - [lwIP Module Adaptation](porting-chip-board-lwip.md) - - [Third-party Module Adaptation](porting-chip-board-bundle.md) - - [XTS](porting-chip-board-xts.md) - - [FAQ](porting-chip-faqs.md) -- [Small System SoC Porting Guide](porting-smallchip.md) - - [Porting Preparations](porting-smallchip-prepare.md) - - [Before You Start](porting-smallchip-prepare-needs.md) - - [Compilation and Building](porting-smallchip-prepare-building.md) - - [Kernel Porting](porting-smallchip-kernel.md) - - [LiteOS Cortex-A](porting-smallchip-kernel-a.md) - - [Linux Kernel](porting-smallchip-kernel-linux.md) - - [Driver Porting](porting-smallchip-driver.md) - - [Overview](porting-smallchip-driver-overview.md) - - [Platform Driver Porting](porting-smallchip-driver-plat.md) - - [Device Driver Porting](porting-smallchip-driver-oom.md) -- Standard System SoC Porting Guide - - [Standard System Porting Guide](standard-system-porting-guide.md) - - [A Method for Rapidly Porting the OpenHarmony Linux Kernel](porting-linux-kernel.md) -- [Third-Party Library Porting Guide for Mini and Small Systems](porting-thirdparty.md) - - [Overview](porting-thirdparty-overview.md) - - [Porting a Library Built Using CMake](porting-thirdparty-cmake.md) - - [Porting a Library Built Using Makefile](porting-thirdparty-makefile.md) \ No newline at end of file +# Overview + +- [System Types](#section767218232110) +- [Document Outline](#section19810171681218) + +This topic provides a panorama of all documents for you to obtain helpful information quickly. These documents are classified based on your learning progress and development scenarios of OpenHarmony. + +## System Types + +It is good practice to understand the system types for you to find useful documents that can guide your development. + +OpenHarmony is an open-source distributed operating system for all scenarios. It uses a component-based design to tailor its features to better suit devices with 128 KiB to GiB-level of RAM. You can integrate a flexible combination of system components based on the hardware capabilities of the device. + +To make the integration simple and easy on different hardware, OpenHarmony defines three basic system types. You only need to select a suitable system type and configure the mandatory component set, thereby developing a system for your device at the minimum workload. The definitions of the basic system types are provided as follows for your reference: + +- 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. + +- 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. + +- 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. + + +In addition, OpenHarmony provides a series of optional system components that can be configured as required to support feature extension and customization. These system components are combined to form a series of system capabilities that, for better understanding, are described as features or functions for you to choose. + +## Document Outline + +- [Mini and Small System Development Guidelines](#table3762949121211) +- [Standard System Development Guidelines](#table17667535516) + +**Table 1** Mini and small system development guidelines \(reference memory < 128 MB\) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Topic

+

Development Scenario

+

Documents

+

About OpenHarmony

+

Getting familiar with OpenHarmony

+		 +

Development resources

+

Preparing for your development

+		 +

Quick start

+

Getting started with setup, build, burning, debugging, and running of OpenHarmony

+

Mini and Small Systems

+

Basic capabilities

+

Using basic capabilities of OpenHarmony

+		 +

Advanced development

+

Developing smart devices based on system capabilities

+		 +

Porting and adaptation

+
  • Porting and adapting the OpenHarmony to an SoC
  • Porting and adapting the OpenHarmony to a third-party library
+		 +

Contributing components

+

Contributing components to OpenHarmony

+		 +

Reference

+

Referring to development specifications

+		 +
+ +**Table 2** Standard system development guidelines \(reference memory ≥ 128 MB\) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Topic

+

Development Scenario

+

Documents

+

About OpenHarmony

+

Getting familiar with OpenHarmony

+		 +

Development resources

+

Preparing for your development

+		 +

Quick start

+

Getting started with setup, build, burning, debugging, and running of OpenHarmony

+

Standard System

+

Basic capabilities

+

Using basic capabilities of OpenHarmony

+		 +

Advanced development

+

Developing smart devices based on system capabilities

+		 +

Porting and adaptation

+

Porting and adapting the OpenHarmony to a third-party library

+		 +

Contributing components

+

Contributing components to OpenHarmony

+		 +

Reference

+

Referring to development specifications

+		 +
+ -- Gitee