代码拉取完成，页面将自动刷新
同步操作将从 OpenHarmony/docs 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
The testing subsystem provides a one-click Python-based self-test platform for developers. It supports cross-platform tests and extension to third-party testing frameworks. The subsystem consists of modules for compiling, managing, scheduling and distributing, and executing test cases, collecting test results, generating test reports, creating test case templates, managing test environments, and many others.
Before development using the testing subsystem, you need to understand the following concepts:
Test case compilation
This operation compiles the source code of test cases into binary files that can be executed on the tested device.
Test case scheduling & distributing
This operation distributes test cases to different tested devices through the network port or serial port, and allocates a specific executor for each test case.
Test case executor
A test case executor defines the execution logic of each test case, such as its pre-processing, execution, and result recording.
Test case template
A test case template defines respective unified formats for test cases and for GN files.
Test platform kits
The test platform provides common methods to be used during the running of the test tool, for example, providing the test case directory to mount the file system to a tested device, distributing test cases to the tested device, or obtaining test results from the tested device.
Test report generation
This operation defines a template for generating self-test reports and web test reports.
Test environment management
The tested devices can be managed through the USB port or serial port, including discovering a device and querying the device status.
Figure 1 Platform architecture
Figure 2 Running sequence of the test platform
The test platform is started using a shell script. It executes a series of testing commands entered on the command line interface (CLI) and prints the command output.
Table 1 Environment requirements
(Optional) If the test environment runs Linux, run the following command to install system component Readline:
sudo apt-get install libreadline-dev
If the installation is successful, the following prompts are displayed:
Reading package lists... Done
Building dependency tree
Reading state information... Done
libreadline-dev is already the newest version (7.0-3).
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
Install Python extension plug-ins Setuptools. Install RSA, Paramiko, and pySerial if the device supports the serial port only.
pip install setuptools
If the installation is successful, the following prompts are displayed:
Requirement already satisfied: setuptools in d:\programs\python37\lib\site-packages (41.2.0)
pip install rsa
If the installation is successful, the following prompts are displayed:
Installing collected packages: pyasn1, rsa
Successfully installed pyasn1-0.4.8 rsa-4.7
pip install paramiko
If the installation is successful, the following prompts are displayed:
Installing collected packages: pycparser, cffi, pynacl, bcrypt, cryptography, paramiko
Successfully installed bcrypt-3.2.0 cffi-1.14.4 cryptography-3.3.1 paramiko-2.7.2 pycparser-2.20 pynacl-1.4.0
pip install pyserial
If the installation is successful, the following prompts are displayed:
Requirement already satisfied: pyserial in d:\programs\python37\lib\site-packages\pyserial-3.4-py3.7.egg (3.4)
(Optional) Install the NFS server. This step is mandatory for tested devices that support serial ports only.
Windows OS
Download and install haneWIN NFS Server 1.2.50 at https://www.hanewin.net/nfs-e.htm.
Linux OS
sudo apt install nfs-kernel-server
After the environment is installed, you can conduct coding and debugging for a test platform in an integrated development environment (IDE) (DevEco Studio is recommended).
Table 2 Environment verification
You can call the APIs to conduct white box tests of service code.
The testing framework integrates the open-source unit testing framework and expands the macros of the test cases. For details about the framework, see the official open-source documentation.
Table 3 Expanded macros of the framework
Define a test suite file based on the test case directory, for example, test/developertest/examples/lite/cxx_demo/test/unittest/common/calc_subtraction_test.cpp. The class in this test suite should be inherited from the testing::Test class and named in the format of "Tested feature_Test".
/*
* Copyright (c) 2020 OpenHarmony.
* 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 <gtest/gtest.h>
using namespace std;
using namespace testing::ext;
class CalcSubtractionTest : public testing::Test {
public:
static void SetUpTestCase(void);
static void TearDownTestCase(void);
void SetUp();
void TearDown();
};
NOTE: You must write test cases by observing the following specifications:
- Naming The source file name of a test case must be consistent with the test suite content. Each test suite has multiple test cases and a test source file that is globally unique and named in [Feature]_[Function]_[Subfunction 1]_[Subfunction 1.1] format (subfunctions can be further divided). The file name can contain only lower-case letters and underscores (_) and must end with test, for example, developertest/examples/lite/cxx_demo.
- Coding The test cases must comply with the coding specifications for feature code. In addition, case descriptions are required for further clarification. For details, see Test case template.
- Compilation and configuration The test cases must be compiled using GN, and the configurations must comply with the compilation guide of this open-source project. For details, see Compilation and Building Guidelines.
- Test case template For details, see the example test case developertest/examples/lite/cxx_demo/test/unittest/common/calc_subtraction_test.cpp.
Implement the preprocessing (via the SetUp function) and postprocessing (via the TearDown function) operations required by the execution of the test suite.
void CalcSubtractionTest::SetUpTestCase(void)
{
// step 1: input testsuite setup step
}
void CalcSubtractionTest::TearDownTestCase(void)
{
// step 2: input testsuite teardown step
}
void CalcSubtractionTest::SetUp(void)
{
// step 3: input testcase setup step
}
void CalcSubtractionTest::TearDown(void)
{
// step 4: input testcase teardown step
}
Compile a test case based on the feature to be tested. The following code uses HWTEST_F as an example:
/**
* @tc.name: integer_sub_001
* @tc.desc: Test Calculator
* @tc.type: FUNC
* @tc.require: AR00000000 SR00000000
*/
HWTEST_F(CalcSubtractionTest, integer_sub_001, TestSize.Level1)
{
EXPECT_EQ(0, Subtraction(1, 0));
}
- @tc.name: test case name, which briefly describes the test purpose
- @tc.desc: detailed description of the test case, including the test purpose, test procedure, and expected result
- @tc.type: test type, which can be FUNC, PERF, SECU, or RELI.
- @tc.require: requirement ID or issue ID, which is used to associate the modification with the test case
Compile the GN file of the test case, including defining the compilation target, adding compilation dependencies, and setting the source file.
Example file path: test/developertest/examples/lite/cxx_demo/test/unittest/common/BUILD.gn
import("//build/lite/config/test.gni")
unittest("CalcSubTest") {
output_extension = "bin"
sources = [
"calc_subtraction_test.cpp"
]
include_dirs = []
deps = []
}
Add the compilation target to the subsystem compilation configuration to ensure that the test case is compiled with the version distribution. The following is an example:
For devices that support connection to the Harmony device connector (hdc), the example compilation configuration directory is test/developertest/examples/ohos.build.
{
"subsystem": "subsystem_examples",
"parts": {
"subsystem_examples": {
"module_list": [
"//test/developertest/examples/detector:detector",
...
],
"test_list": [
"//test/developertest/examples/detector/test:unittest",
...
]
},
...
}
For devices that support serial ports only, the example compilation configuration directory is test/developertest/examples/lite/BUILD.gn.
import("//build/lite/config/test.gni")
subsystem_test("test") {
test_components = []
if(ohos_kernel_type == "liteos_riscv") {
features += [
]
}else if(ohos_kernel_type == "liteos_a") {
test_components += [
"//test/developertest/examples/lite/cxx_demo/test/unittest/common:CalcSubTest"
]
}
}
Create a resource configuration file for the test case to use static resources.
Create the resource directory in the test directory of a component or module.
Create a directory for a device type, for example, phone, in the resource directory.
Create a folder named after the module in the device type directory, for example, testmodule.
Create the ohos_test.xml file in the folder named after the module. The file content is in the following format:
<?xml version="1.0" encoding="UTF-8"?>
<configuration ver="2.0">
<target name="DetectorFileTest">
<preparer>
<option name="push" value="test.txt -> /data/test/resource" src="res"/>
</preparer>
</target>
</configuration>
Define resource_config_file in the compilation configuration file of the test case to specify the resource file ohos_test.xml.
Execute the test case after it is compiled (the preceding steps are complete).
- For devices that support connection to the hdc, test cases can be compiled separately.
- For devices that support serial ports only, to compile the test case, run the commands in the root directory for compiling the debug code. For details about how to execute a test case, see How to Use the Test Platform.
The code repository of the testing subsystem provides complete demo cases, which are available in the test/developertest/examples/ directory. The following is an example of compiling a test case for a subtraction function:
The tested code is as follows:
static int Subtraction(int a, int b)
{
return a - b;
}
The test case code is as follows:
/**
* @tc.name: integer_sub_002
* @tc.desc: Verify the Subtraction function.
* @tc.type: FUNC
* @tc.require: AR00000000 SR00000000
*/
HWTEST_F(CalcSubtractionTest, integer_sub_002, TestSize.Level1)
{
EXPECT_EQ(1, Subtraction(2, 1));
}
(Optional) Install the XDevice component. XDevice can be used as a Python extension package.
Go to the installation directory test/xdevice and run the following command:
python setup.py install
If the installation is successful, the following prompts are displayed:
...
Installed d:\programs\python37\lib\site-packages\xdevice-0.0.0-py3.7.egg
Processing dependencies for xdevice==0.0.0
Searching for pyserial==3.4
Best match: pyserial 3.4
Processing pyserial-3.4-py3.7.egg
pyserial 3.4 is already the active version in easy-install.pth
Installing miniterm.py script to D:\Programs\Python37\Scripts
Using d:\programs\python37\lib\site-packages\pyserial-3.4-py3.7.egg
Finished processing dependencies for xdevice==0.0.0
Modify the developertest/config/user_config.xml file to configure the Developertest component.
For devices that support connection to the hdc, modify the configuration file as follows:
Between the device tags with the "usb-hdc" attribute, modify the IP address of the device and the port number matching the HDC connection. For example:
<device type="usb-hdc">
<ip>192.168.1.1</ip>
<port>9111</port>
<sn></sn>
</device>
For devices that support serial ports only, modify the configuration file as follows:
Between the device tags with the "ipcamera" attribute, modify the serial port information, including the COM port and baud rate. For example:
<device type="com" label="ipcamera">
<serial>
<com>COM1</com>
<type>cmd</type>
<baud_rate>115200</baud_rate>
<data_bits>8</data_bits>
<stop_bits>1</stop_bits>
<timeout>1</timeout>
</serial>
</device>
(Optional) Modify the Developertest configuration. If a test case has been compiled, specify the compilation output path of the test case. In this case the test platform will not recompile the test case.
Modify the config/user_config.xml file.
Specify the output path of the test case, that is, the compilation output directory between the test_cases tags. Example:
<test_cases>
<dir>/home/opencode/out/release/tests</dir>
</test_cases>
For devices that support serial ports only, specify the NFS directory on the PC (host_dir) and the corresponding directory on the board (board_dir) between the NFS tags. For example:
<NFS>
<host_dir>D:\nfs</host_dir>
<board_dir>user</board_dir>
</NFS>
(Optional) Prepare the test environment. If devices to be tested support only serial ports, check whether the environment is ready:
Start the test platform and execute the test case.
Start the test framework, go to the test/developertest directory, and execute the startup script.
Run the following command to start the test framework in Windows:
start.bat
Run the following command to start the test framework in Linux:
./strat.sh
Select a device type.
Configure the device type based on the development board in the configuration file, for example, developertest/config/framework_config.xml.
Run test commands.
To query the subsystems, modules, product form, and test types supported by test cases, run the show commands.
Usage:
show productlist Query supported product forms
show typelist Query the supported test type
show subsystemlist Query supported subsystems
show modulelist Query supported modules
Run test commands. -t is mandatory, and -ss and -tm are optional. The following is an example:
run -t ut -ss subsystem_examples -tm calculator
Specify the arguments to execute the test suite for a specific feature or module.
usage: run [-h] [-p PRODUCTFORM] [-t [TESTTYPE [TESTTYPE ...]]]
[-ss SUBSYSTEM] [-tm TESTMODULE] [-ts TESTSUIT]
[-tc TESTCASE] [-tl TESTLEVEL]
Optional arguments:
-h, --help Show this help message and exit.
-p PRODUCTFORM, --productform PRODUCTFORM Specified product form
-t [TESTTYPE [TESTTYPE ...]], --testtype [TESTTYPE [TESTTYPE ...]]
Specify test type(UT,MST,ST,PERF,ALL)
-ss SUBSYSTEM, --subsystem SUBSYSTEM Specify test subsystem
-tm TESTMODULE, --testmodule TESTMODULE Specified test module
-ts TESTSUIT, --testsuite TESTSUIT Specify test suite
-tc TESTCASE, --testcase TESTCASE Specify test case
-tl TESTLEVEL, --testlevel TESTLEVEL Specify test level
View the test framework help if needed.
Run the following command query test commands that are supported by the test platform:
help
Exit the test platform.
Run the following command to exit the test platform:
quit
View the test result and logs. The test logs and reports are generated in the developertest/reports directory after you run the test commands.
The test result is displayed on the console. The root path of the test result is as follows:
reports/xxxx-xx-xx-xx-xx-xx
The test case formatting result is stored in the following directory:
result/
The test logs are stored in the following directory:
log/plan_log_xxxx-xx-xx-xx-xx-xx.log
The report summary file is as follows:
summary_report.html
The report details file is as follows:
details_report.html
The log directory of the test platform is as follows:
reports/platform_log_xxxx-xx-xx-xx-xx-xx.log
The source code of XDevice is stored in the test/xdevice directory. The following table describes the xdevice directory structure.
Table 4 XDevice structure
The source code of Developertest is stored in the test/developertest directory. The following table describes the developertest directory structure.
Table 5 Developertest structure
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。