Local automated testing methods for openEuler Embedded systems based on oebuild extension support
By integrating the mugen plugin into oebuild, we have achieved fully automated testing of the openEuler Embedded system, solving the problem of low efficiency in traditional testing methods and improving development efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- QUFU NORMAL UNIV
- Filing Date
- 2026-03-12
- Publication Date
- 2026-06-19
Smart Images

Figure FT_1 
Figure FT_2 
Figure FT_3
Abstract
Description
Technical Field
[0001] This invention belongs to the field of cloud computing and virtualization technology, specifically relating to a local automated testing method for the openEuler Embedded system based on oebuild extension support. Background Technology
[0002] With the rapid development of IoT and 5G technologies, embedded systems have been widely used in smart homes, industrial automation, and intelligent transportation. These systems typically require high reliability, low power consumption, and real-time response capabilities, placing higher demands on the stability and security of the operating system. openEuler Embedded, an operating system version released by the openEuler community specifically for the embedded field, is designed to provide a stable, secure, and efficient operating environment for embedded devices. In the development of embedded systems, testing is a crucial step in ensuring system quality; however, traditional testing methods rely on manual operation, which is inefficient and prone to errors.
[0003] oebuild, as the core development tool of the openEuler Embedded project, integrates functions such as operating system building, cross-compilation chain building, and online package deployment. However, oebuild currently lacks testing capabilities, which limits the testing efficiency for developers during the openEuler Embedded project development process. The openEuler community has launched the mugen testing framework to improve the level of testing automation and coverage, but...
[0004] Mugen suffers from low automation when testing openEuler Embedded projects, resulting in low testing efficiency. Furthermore, the disconnect between oebuild and Mugen, which are core tools for developing openEuler Embedded projects, also restricts the development speed of developers when working on related projects. Summary of the Invention
[0005] To address the aforementioned issues in local testing of the openEuler Embedded embedded operating system, this invention proposes a local automated testing method for the openEuler Embedded system based on oebuild extension support, thereby automating local testing of the openEuler Embedded system.
[0006] The local automated testing method for the openEuler Embedded system based on oebuild extension support described in this invention includes the following four steps:
[0007] S1: Test environment preparation and image building;
[0008] S2: Design of the algorithm required by the oebuild plugin;
[0009] S3: Design and registration of the oebuild plugin;
[0010] S4: Running the oebuild plugin.
[0011] Furthermore, the local automated testing method for the openEuler Embedded system based on the oebuild extension is characterized by the following: the test environment preparation and image building in step S1 are specifically described as follows:
[0012] S11: Install the host packages necessary for performing tests and building the image;
[0013] S111: Install the lshw package;
[0014] S112: Install the git package;
[0015] S113: Install the python3 package;
[0016] S114: Install the python3-pip package;
[0017] S115: Install the Docker package;
[0018] S116: Enable oebuild developer mode;
[0019] (1) Clone the oebuild source code;
[0020] (2) Switch to the oebuild directory;
[0021] (3) Install oebuild in developer mode;
[0022] S117: Cloning the Mugen source code;
[0023] S118: Install the necessary dependencies for mugen using mugen's dep_install;
[0024] S12: Build and run the openEuler Embedded image and configure the network;
[0025] S121: Initialize the oebuild build environment;
[0026] S122: Build an ARM64 QEMU image;
[0027] S123: Running ARM64 QEMU image;
[0028] S124: Configure the openEuler Embedded network interface card;
[0029] S125: Confirm network connectivity between the host machine and the openEuler Embedded system;
[0030] S13: Copy the plugin source files from oebuild;
[0031] S131: Switch to the oebuild / src / oebuild / app / plugins / demo directory;
[0032] S132: Copy the demo.py file as the initial file for the plugin. The demo.py file is the oebuild plugin example file.
[0033] Furthermore, the local automated testing method for the openEuler Embedded system based on the oebuild extension is characterized by the following: the design of the algorithm required by the oebuild plugin in step S2 is specifically described as follows:
[0034] S21: Design an environment dependency management algorithm that iterates through a predefined list of environment dependency tools and checks whether each tool is installed. For tools that are not installed, the package manager will be called to execute the installation command. If the command fails, the tool is determined to be not installed and an exception is thrown.
[0035] S22: Design a test scheduling algorithm that uses a dictionary data structure to map user-input numeric identifiers (1-4) to predefined test suite names. These mapped test suites include: 1-Tiny image test, 2-OS basic test, 3-Embedded security configuration test, and 4-Embedded basic development test. After user input, the algorithm checks the validity of the input. If the input is invalid, an exception is thrown, terminating the process. If the input is valid, standardized test commands are generated through string interpolation.
[0036] S23: Design a test result analysis algorithm. The algorithm first opens and reads the raw log file generated by the Mugen testing framework line by line, scanning each line of log content using regular expression matching technology. When the keyword "Test casepassed" is detected, the passed test case counter is incremented if successful. If the keyword "ERROR" is detected, an auxiliary function is called to extract the names of failed test cases and error details. The algorithm stores the matching results in a dictionary structure containing two core fields: a numeric type to record the total number of passed test cases and an array type to store the list of failed test cases. The algorithm can generate a structured test report based on the dictionary, including the pass rate and failure reason classification.
[0037] Furthermore, the local automated testing method for the openEuler Embedded system based on the oebuild extension is characterized by the following: the design and registration of the oebuild plugin in step S3 is specifically described as follows:
[0038] S31: Open the file demo.py using a text editor and start writing the plugin code;
[0039] S32: Create an instance of the class and initialize it;
[0040] S321: Initialize the MugenTest class, setting its command name, help information, and description;
[0041] S322: Add a command-line argument parser and define the necessary parameters, including the Mugen installation path, IP address, test system username, test system password, and test system machine port.
[0042] S33: Parse and obtain the parameter values input by the user;
[0043] S331: Parse command-line arguments and obtain the parameter values entered by the user;
[0044] S332: Check if there is a help option. If there is a help option, print help information and exit the program.
[0045] S333: Parse unknown parameters and obtain the complete parameter object. If the user inputs unknown parameters, the program will print an error message and exit the program. The user can obtain help information and restart the program by entering the help option.
[0046] S34: Check environment dependencies and configure the test environment;
[0047] S341: Add an environment dependency management algorithm as described in S21 to the program to detect whether the user has installed the environment dependencies required for testing.
[0048] S342: Switch to the Mugen installation directory to configure the Mugen remote testing environment and clean up the old configuration files. The old configuration files are the env.json files in the conf subdirectory of the Mugen installation directory. The env.json file is the configuration file used to store Mugen environment configuration information.
[0049] S343: Obtain the Mugen installation path, prioritizing the user-specified path, otherwise using the default path set in the program;
[0050] S344: Check if Mugen is installed in the user-specified path. If Mugen is not installed in either the user-specified path or the default path, prompt the user to install Mugen and exit the program. After the user has finished installing Mugen, the program can be restarted.
[0051] S35: User selects test suite;
[0052] S351: Add a test scheduling algorithm as described in S22 to the program, which can dynamically map test suites for user selection. The test suite list includes: 1-Tiny image test, 2-OS basic test, 3-Embedded security configuration test, and 4-Embedded basic development test.
[0053] S352: Obtain the test suite number selected by the user;
[0054] S353: Verify whether the test suite number selected by the user is valid. If the user enters an invalid number, an error message will be displayed and the program will exit. The user can restart the program after understanding the error.
[0055] S36: Execute the test suite selected by the user;
[0056] S361: Retrieve the corresponding test suite name based on the test suite number selected by the user;
[0057] S362: Build and execute Mugen remote environment configuration commands to configure the remote testing environment;
[0058] S363: Check the execution result of the remote environment configuration command. If successful, continue; if it fails, print an error message and exit the program. The plugin command can be re-executed after the user has finished troubleshooting the error.
[0059] S364: Builds and executes test suite run commands to run the user-selected test suite;
[0060] S365: Add a test result analysis algorithm as described in S23 to the program to convert the raw text logs generated by the mugen test framework into structured text reports;
[0061] S37: Registration of the oebuild plugin;
[0062] S371: Switch to the oebuild / src / oebuild / app / conf directory;
[0063] S372: Open the plugins.yaml file using a text editor. The plugins.yaml file is used to record oebuild plugin information, including the plugin name, plugin path, and plugin class name.
[0064] S373: Add registration information for the oebuild plugin;
[0065] (1) Add the plugin name mugentest;
[0066] (2) Add the class name of the mugentest plugin;
[0067] (3) Add the path to the mugentest plugin. The path to the plugin is the path to the file demo.py after modification using a text editor.
[0068] S374: Save the file and exit the text editor to complete the registration.
[0069] Furthermore, the local automated testing method for the openEuler Embedded system based on the oebuild extension is characterized by the following: the execution of the oebuild plugin in step S4 is specifically described as follows:
[0070] According to the help information, after filling in the relevant parameters, execute the oebuild mugentest command with parameters to start the test.
[0071] After executing the oebuild mugentest command, the plugin will display and allow the user to select a test suite. After the user selects a test suite, the plugin will automatically configure the remote environment based on the information entered by the user and the selected test suite, automatically complete the test, and output the test results to the user.
[0072] Compared with the prior art, the present invention has the following beneficial effects;
[0073] This invention implements a local automated testing method for openEuler Embedded systems based on oebuild extension support, seamlessly integrating mugen into oebuild, and realizing a one-stop, full-process automated testing solution for openEuler Embedded from system building and environment configuration to test execution. Attached Figure Description
[0074] Figure 1 This is a system parameter configuration diagram of the local automated testing method for the openEuler Embedded system based on the oebuild extension supported by this invention.
[0075] Figure 2 This is a flowchart of the local automated testing method for the openEuler Embedded system based on the oebuild extension supported by this invention.
[0076] Figure 3 This is a user help diagram illustrating the mugentest command for the local automated testing method of the openEuler Embedded system supported by the oebuild extension of this invention.
[0077] Figure 4 This is a diagram illustrating the execution process of the local automated testing method for the openEuler Embedded system based on the oebuild extension supported by this invention. Detailed Implementation
[0078] The present invention will be further described below with reference to the accompanying drawings and embodiments:
[0079] This invention provides a method for local automated testing of the openEuler Embedded system based on the oebuild extension under the openEuler 24.03 operating system. Figure 1 This is a system configuration diagram for the openEuler 24.03 operating system.
[0080] The openEuler 24.03 operating system supports local automated testing methods for OpenEuler Embedded systems based on the oebuild extension, including the following four steps:
[0081] S1: Environment configuration required for the oebuild mugentest command on the openEuler 24.03 operating system;
[0082] S11: Install the required dependency packages;
[0083] S111 uses `yum install lshw git python3 python3-pip docker -y` to install the required dependencies.
[0084] S112: Cloning the source code package:
[0085] Clone the source code for the oebuild and mugen instruction sets using the commands `git clone https: / / gitee.com / openeuler / oebuild.git` and `git clone https: / / gitee.com / openeuler / mugen.git`.
[0086] S113: Configure Docker environment:
[0087] Use `sudo usermod -a -G docker $(whoami)` to add the current user to the user group;
[0088] Use `sudo systemctl daemon-reload && sudo systemctl restart docker` to reload the system service configuration and restart the Docker service;
[0089] Use `sudo chmod o+rw / var / run / docker.sock` to grant all users read and write permissions.
[0090] S12: Build and run openEuler Embedded and configure the network;
[0091] S121: Initialize the oebuild build environment:
[0092] Use oebuild init<work_dir> Create a working directory.<work_dir> The working directory to be created;
[0093] Use cd<work_dir> Switch to the working directory;
[0094] Use oebuild update to pull the build container and yocto-meta-openeuler project code.
[0095] S122: Building an ARM64 QEMU image:
[0096] Use cd<work_dir> Switch to the working directory to perform the operation;
[0097] Use `oebuild generate -p qemu-aarch64 -d build_arm64` to create the configuration file `compile.yaml` for the `openeuler-image-qemu-arm64` image;
[0098] Use `cd build / build_arm64 / ` to switch to the build space directory containing `compile.yaml`, such as `build / build_arm64 / `.
[0099] Use oebuild bitbake openeuler-image to switch to the build_arm64 build directory as prompted and start building.
[0100] S123: Running ARM64 QEMU image:
[0101] In the output directory under the build directory, you can find the zImage file, the openeuler-image-qemu-xxx.cpio.gz file, the openeuler-image-qemu-aarch64-xxx.iso file, and the vmlinux file. These correspond to the kernel image, standard root file system image, iso format image, and corresponding vmlinux image of the built openEuler Embedded system, respectively.
[0102] Install QEMU using `sudo yum install qemu-system-aarch64`.
[0103] Use `qemu-system-aarch64 -M virt-4.0 -m 1G -cpu cortex-a57 -nographic`
[0104] -kernel zImage \
[0105] -initrd openeuler-image-qemu-aarch64-*.rootfs.cpio.gz,
[0106] Executing this command starts the image. After QEMU runs successfully and you log in, you will be presented with an openEuler Embedded shell.
[0107] S124: Configure the network interface card for openEuler Embedded;
[0108] Modify the configuration of the wireless network card wlan0 in the / etc / network / interfaces file. For example, if the wireless network card driver used by the current Raspberry Pi is the nl80211 series, then change wpa-driver wext to wpa-driver nl80211 to start wpa_supplicant correctly. After making the changes, restart the networking service for the configuration to take effect.
[0109] Add a Wi-Fi network by modifying the wpa_supplicant configuration file. If you are concerned about the plaintext password being leaked in the configuration file, you can use the wpa_passphrase tool to encrypt it before writing it into the configuration file. It uses ifup to start the Wi-Fi connection and automatically obtains an IP address.
[0110] S125: Confirm connectivity between the host machine and the openEuler Embedded network:
[0111] Use the ifconfig command to check the wlan0 network interface card.
[0112] S13: Copy the plugin source files from oebuild;
[0113] S131: Switch to the oebuild / src / oebuild / app / plugins / demo directory;
[0114] S132: Copy the demo.py file as the initial file for the plugin. The specific steps are as follows:
[0115] (1) Create a directory to store the source files of the copied plugin for subsequent work and name it mugentest. Use cd mugentest to enter the new directory;
[0116] (2) By executing the cp command, copy the plugin source file demo.py provided by oebuild to the working directory and name it mugentest.py. The plugin source file path entered when copying the file is: oebuild / src / oebuild / app / plugins / demo / demo.py, and the target path entered when copying the file is: oebuild / src / oebuild / app / plugins / mugentest / mugentest.py. Copy the plugin source file provided by oebuild to the corresponding working directory.
[0117] S2: Algorithm Design:
[0118] S21: Design an environment dependency management algorithm;
[0119] S22: Design and test the scheduling algorithm;
[0120] S23: Design an algorithm for analyzing test results;
[0121] S3: OpenEuler 24.03 operating system, use the oebuild mugentest command to write plugin code and register plugins;
[0122] S31: Open the file demo.py using a text editor and start writing the plugin code;
[0123] Use vim mugentest.py to open the plugin file and start writing.
[0124] S32: Create an instance of the class and initialize it;
[0125] S33: Parse and obtain the parameter values input by the user;
[0126] S34: Check and configure the test environment;
[0127] S35: User selects test suite;
[0128] S36: Execute the test suite selected by the user;
[0129] The plugin execution flow, which involves plugin design and code writing in steps S32-S36 above, is as follows: Figure 2 As shown.
[0130] S37: Switch to the oebuild / src / oebuild / app / conf directory;
[0131] S38: Open the plugins.yaml file using a text editor. The plugins.yaml file is used to record oebuild plugin information, including the plugin name, plugin path, and plugin class name.
[0132] S39: Add the name of mugentest, the plugin path, and the name of the plugin class;
[0133] S4: Run the plugin;
[0134] S41: Use the command oebuild mugentest --help or oebuild mugentest -h to query the usage and help information of the mugentest plugin;
[0135] The execution result of querying help using the oebuild mugentest command is as follows: Figure 3 As shown;
[0136] The following is the testing process using the oebuild mugentest command:
[0137] S42: Run the oebuild mugentest command, which is: oebuild mugentest [--mugen-path] / path / to / mugen [--ip] $ip [--user] $user [--password] $password [--port] $port for local automated testing of openEuler Embedded;
[0138] S43: The parameter --mugen-path is used to specify the installation path of Mugen, --ip is used to specify the IP address of the test system, --user is used to specify the username of the test system, --password is used to specify the password of the test system, and --port is an optional parameter used to specify the machine port of the test system.
[0139] S44: After executing the oebuild mugentest command, the plugin will display and allow the user to select a test suite. After the user selects a test suite, the plugin will automatically complete the configuration of the remote environment based on the information entered by the user and the selected test suite, automatically complete the test, and output the test results to the user.
[0140] The results of the test using the oebuild mugentest command are shown in the image above. Figure 4 As shown.
[0141] The present invention, described above in conjunction with the accompanying drawings, provides a local automated testing method for the openEuler Embedded system based on oebuild extension support. By deeply integrating oebuild and mugen, and constructing the oebuild plugin mugentest, local automated testing of the openEuler Embedded system can be achieved by executing the parameterized oebuild mugentest command. This includes tiny image testing, OS basic testing, embedded security configuration testing, and embedded basic development testing. This invention enables deep integration of oebuild and mugen, eliminating the disconnect between the oebuild and mugen toolchains, thereby ensuring that local automated testing of the openEuler Embedded system requires minimal manual intervention. However, the present invention is not limited to the described embodiments. Modifications, substitutions, and alterations to the embodiments without departing from the principles and spirit of the present invention still fall within the protection scope of the present invention.
Claims
1. A local automated testing method for openEuler Embedded systems based on the oebuild extension, comprising the following four steps: S1: Test environment preparation and image building; S2: Design of the algorithm required by the oebuild plugin; S3: Design and registration of the oebuild plugin; S4: Running the oebuild plugin.
2. The local automated testing method for the openEuler Embedded system based on oebuild extension support according to claim 1, characterized in that: The test environment preparation and image building in step S1 are specifically described as follows: S11: Install the host packages necessary for performing tests and building the image; S111: Install the lshw software package; S112: Install the git package; S113: Install the python3 package; S114: Install the python3-pip package; S115: Install the Docker package; S116: Enable oebuild developer mode; (1) Clone the oebuild source code; (2) Switch to the oebuild directory; (3) Install oebuild in developer mode; S117: Cloning the Mugen source code; S118: Install the necessary dependencies for mugen using mugen's dep_install; S12: Build and run the openEuler Embedded image and configure the network; S121: Initialize the oebuild build environment; S122: Build an ARM64 QEMU image; S123: Running ARM64 QEMU image; S124: Configure the openEuler Embedded network interface card; S125: Confirm network connectivity between the host machine and the openEuler Embedded system; S13: Copy the plugin source files from oebuild; S131: Switch to the oebuild / src / oebuild / app / plugins / demo directory; S132: Copy the demo.py file as the initial file for the plugin. The demo.py file is the oebuild plugin example file.
3. The local automated testing method for the openEuler Embedded system based on oebuild extension support according to claim 1, characterized in that: The design of the algorithm required by the oebuild plugin in step S2 is specifically described as follows: S21: Design an environment dependency management algorithm that iterates through a predefined list of environment dependency tools and checks whether each tool is installed. For tools that are not installed, the package manager will be automatically called to execute the installation command. If the command fails, the tool is determined to be not installed and an exception is thrown. S22: Design a test scheduling algorithm that uses a dictionary data structure to map user-input numeric identifiers (1-4) to predefined test suite names. These mapped test suites include: 1-Tiny image test, 2-OS basic test, 3-Embedded security configuration test, and 4-Embedded basic development test. After user input, the algorithm checks the validity of the input. If the input is invalid, an exception is thrown, terminating the process. If the input is valid, standardized test commands are generated through string interpolation. S23: Design a test result analysis algorithm. The algorithm first opens and reads the raw log file generated by the Mugen testing framework line by line, scanning each line of log content using regular expression matching technology. When the keyword "Test case passed" is detected, the passed test case counter is incremented if successful. If the keyword "ERROR" is detected, an auxiliary function is called to extract the name of the failed test case and error details. The algorithm stores the matching results in a dictionary structure containing two core fields: a numeric type to record the total number of passed test cases and an array type to store the list of failed test cases. The algorithm can generate a structured test report based on the dictionary, including the pass rate and failure reason classification.
4. The local automated testing method for the openEuler Embedded system based on oebuild extension support according to claim 1, characterized in that: The design and registration of the oebuild plugin in step S3 is specifically described as follows: S31: Open the file demo.py using a text editor and start writing the plugin code; S32: Create an instance of the class and initialize it; S321: Initialize the MugenTest class, setting its command name, help information, and description; S322: Add a command-line argument parser and define the necessary parameters, including the Mugen installation path, IP address, test system username, test system password, and test system machine port. S33: Parse and obtain the parameter values input by the user; S331: Parse command-line arguments and obtain the parameter values entered by the user; S332: Check if there is a help option. If there is a help option, print help information and exit the program. S333: Parse unknown parameters and obtain the complete parameter object. If the user inputs unknown parameters, the program will print an error message and exit the program. The user can obtain help information and restart the program by entering the help option. S34: Check environment dependencies and configure the test environment; S341: Add an environment dependency management algorithm as described in S21 to the program to detect whether the user has installed the environment dependencies required for testing. S342: Switch to the Mugen installation directory to configure the Mugen remote testing environment and clean up the old configuration files. The old configuration files are the env.json files in the conf subdirectory of the Mugen installation directory. The env.json file is the configuration file used to store Mugen environment configuration information. S343: Obtain the Mugen installation path, prioritizing the user-specified path, otherwise using the default path set in the program; S344: Check if Mugen is installed in the user-specified path. If Mugen is not installed in either the user-specified path or the default path, prompt the user to install Mugen and exit the program. After the user has finished installing Mugen, the program can be restarted. S35: User selects test suite; S351: Add a test scheduling algorithm as described in S22 to the program, which can dynamically map test suites for user selection. The test suite list includes: 1-Tiny image test, 2-OS basic test, 3-Embedded security configuration test, and 4-Embedded basic development test. S352: Obtain the test suite number selected by the user; S353: Verify whether the test suite number selected by the user is valid. If the user enters an invalid number, an error message will be displayed and the program will exit. The user can restart the program after understanding the error. S36: Execute the test suite selected by the user; S361: Retrieve the corresponding test suite name based on the test suite number selected by the user; S362: Build and execute Mugen remote environment configuration commands to configure the remote testing environment; S363: Check the execution result of the remote environment configuration command. If successful, continue; if it fails, print an error message and exit the program. The plugin command can be re-executed after the user has finished troubleshooting the error. S364: Builds and executes test suite run commands to run the user-selected test suite; S365: Add a test result analysis algorithm as described in S23 to the program to convert the raw text logs generated by the mugen test framework into structured text reports; S37: Registration of the oebuild plugin; S371: Switch to the oebuild / src / oebuild / app / conf directory; S372: Open the plugins.yaml file using a text editor. The plugins.yaml file is used to record oebuild plugin information, including the plugin name, plugin path, and plugin class name. S373: Add registration information for the oebuild plugin; (1) Add the plugin name mugentest; (2) Add the class name of the mugentest plugin; (3) Add the path to the mugentest plugin. The path to the plugin is the path to the file demo.py after modification using a text editor. S374: Save the file and exit the text editor to complete the registration.
5. The local automated testing method for the openEuler Embedded system based on oebuild extension support according to claim 1, characterized in that: The execution of the oebuild plugin in step S4 is specifically described as follows: According to the help information, after filling in the relevant parameters, execute the oebuild mugentest command with parameters to start the test.