Software testing method and system based on module compilation tool MBS, and medium

Abstract

This invention provides a software testing method, system, and medium based on the module compilation tool MBS, comprising: developers saving the bash shell scripts to be executed to CaseDB, binding them with test item names, and specifying corresponding test items for modules, saving the correspondence to CaseDB; listening to messages on the fedmsg message bus where MBS is located, and filtering the obtained messages through ansibleconsumer; based on the module information obtained from the fedmsg messages, searching for the corresponding test items and bash scripts in the database; converting the obtained bash scripts into beakerlib scripts; building an Ansible playbook for the module based on the obtained test items, and calling Ansible to execute the playbook to complete the test tasks. Developers can easily write test tasks that meet the requirements using bash scripts.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology for server operating system software, specifically to a software testing method, system, and medium based on the module compilation tool MBS. Background Technology

[0002] In early Linux distributions, each distribution only supported a specific version of a particular software. For some users, if the system version was released too quickly and included the latest software version, it could lead to application compatibility issues. Users who wanted to use a specific version of the software had to build the package themselves. With the development of operating systems, the concept of modularity emerged. This allows software packages to be modularized, making it easier for package builders to create alternative versions of software and for users to install and use these software streams more easily. The Module Build Service (MBS) tool was created for modular building. It provides a series of interfaces for building modules, validates the module.md files that define modules, prepares the compilation environment for the Koji build system, and submits compilation tasks to Koji to complete the module compilation.

[0003] The existing MBS tool was designed to use taskotron (a framework for automating tasks) for software testing, but taskotron's lifecycle ended in May 2020, and it is no longer developed or maintained.

[0004] Existing automated testing methods have three main problems when interfacing with MBS tools: First, to ensure compatibility with most situations, these methods are often large in scale, requiring complex deployment and configuration to achieve satisfactory results, and incurring high learning costs for developers. Second, they typically only test a single software package, which does not conform to the concept of a module. Third, existing automated testing methods are incompatible with existing module compilation technologies in terms of communication methods and formats, making them unable to be directly integrated with MBS tools. These issues cause significant inconvenience for developers using MBS. Summary of the Invention

[0005] One of the objectives of this invention is to provide a software testing method based on the module compilation tool MBS, in order to solve the problems that exist when using MBS to compile software in a modular fashion, such as the lack of directly compatible module testing tools, the need for complex configuration or even secondary development of existing automated testing tools, and the high learning cost for developers.

[0006] The second objective of this invention is to provide a software testing system based on the module compilation tool MBS, in order to solve the problems that exist when using MBS to compile software in a modular fashion, such as the lack of directly compatible module testing tools, the need for complex configuration and even secondary development of existing automated testing tools, and the high learning cost of testing tools for developers.

[0007] The third objective of this invention is to provide a computer-readable storage medium to address the problems that exist when using MBS tools for modular software compilation, such as the lack of directly compatible module testing tools, the need for complex configurations or even secondary development of existing automated testing tools, and the high learning cost for developers.

[0008] One of the objectives of this invention is achieved as follows: The present invention provides a software testing method based on the module compilation tool MBS, comprising the following steps: Step S1: Developers save the bash shell scripts that need to be executed to CaseDB, bind them with test item names, and specify the corresponding test items for each module, saving the correspondence to CaseDB. Step S2: fedmsg-hub listens for messages on the fedmsg message bus where MBS is located and passes them to the ansibleconsumer module. The ansibleconsumer module filters the messages it receives. If the message indicates that a module has been compiled, it proceeds to the next step; otherwise, it is ignored. Step S3: The ansibleconsumer module obtains module information from the fedmsg message and searches for the corresponding test item and bash shell script in the CaseDB database. Step S4: The ansibleconsumer module converts the obtained bash shell script into a beakerlib script; Step S5: The ansibleconsumer module builds ansible playbooks for the module based on the obtained test items, and calls ansible to execute the playbooks to complete the test tasks.

[0009] The process of calling the Ansible execution script to complete the test task involves creating a container based on a customized Docker image, executing the test task in the container, and then uploading the test results to resultsDB.

[0010] The specific steps for creating a container based on a customized Docker image, executing test tasks within the container, and then uploading the test results to resultsDB are as follows: Step S6: Ansible runs a container environment using a customized Docker image based on the Ansible script, passes the beakerlib script to the container and executes it to complete the test task, stores the test results in a specified temporary directory outside the container, and finally destroys the container. Step S7: The ansibleconsumer module collects the test results output by ansible executing ansible playbook and saves them to the specified directory.

[0011] Step S8: The ansibleconsumer module uploads the test results corresponding to each test item to resultsDB through the API provided by resultsDB.

[0012] CaseDB is used to store module test items and their corresponding bash shell script contents.

[0013] In step S1, the CaseDB frontend provides web services via Python Flask, and the backend uses PostgreSQL for data storage. CaseDB has a test case table (case_table) and a mapping table (mapping_table) that maps module names to test cases. In the test case table, the test item name (case_name) and its corresponding script (case_shell) have a one-to-one relationship, while in the mapping table, the module name (module_name) and the test item name (case_name) have a many-to-many relationship.

[0014] Specifically, the AnsibleConsumer class inherits all the contents of the fedmsg.consumers.FedmsgConsumer class, and makes the following changes to the AnsibleConsumer class: Set the member variable topic to " "" is used to listen to all topics; the member variable config_key is set to "ansibleconsumer" to activate it in fedmsg-hub; Add process and que members to store child processes and task queues; Overload the __init__ function, initialize multiple child processes that run the tester function in the constructor to execute test tasks, save the child processes to the child process array process, and initialize a process-safe queue que to store task information; Overload the __del__ function to wait for the child process to exit before destroying it.

[0015] Override the consumer function to check the message type and module status. If the conditions are met, put the message into the task queue que.

[0016] The specific customization process of the Docker image in step S6 is as follows: Based on the Fedora image, replace the yum repository with a local area network yum repository to solve the network restriction problem; Install the beakerlib, rsync, make, and beakerlib-libraries packages as the beakerlib runtime environment; Install modulemd-tools and its dependencies as the module build environment.

[0017] The second objective of this invention is achieved as follows: The present invention provides a software testing system based on the module compilation tool MBS, used to implement the software testing method based on the module compilation tool MBS described above, characterized in that it includes an ansibleconsumer module, CaseDB, ansible, a Docker image, and a Docker container for running the Docker image. The ansibleconsumer module obtains test case information from CaseDB via web API. The ansibleconsumer passes the generated ansible script and the data required for testing to ansible through a subprocess call. Ansible runs a Docker container from the Docker image and passes the required information to the Docker container by copying and mounting directories, and obtains the test results output by the Docker container.

[0018] Specifically, the ansibleconsumer module obtains MBS compilation information through fedmsg; developers provide test items and bash scripts to CaseDB via the web API; and the ansibleconsumer module provides test results to ResultsDB via the web API.

[0019] The Docker image is a customized Docker image. The customization process of the Docker image is as follows: based on the Fedora image, the yum source is replaced with a local area network yum source to solve the network limitation problem; the beakerlib, rsync, make, and beakerlib-libraries packages are installed as the beakerlib runtime environment; and modulemd-tools and its dependent packages are installed as the module build environment.

[0020] The third objective of this invention is achieved as follows: A computer-readable storage medium storing a computer program, characterized in that the computer program, when executed by a processor, implements the above-described software testing method based on the module compilation tool MBS.

[0021] The beneficial effects of this invention are: In this invention, during the compilation process using the MBS tool, the testing process is automatically triggered upon module compilation completion. After the testing tasks are completed, the MBS tool determines the subsequent steps based on the test results in ResultsDB. Developers can easily write satisfactory test tasks using bash script syntax, reducing the self-testing cost for developers when developing software based on the MBS tool and helping to improve the overall quality of the module. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a software testing method based on the module compilation tool MBS according to the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Example 1: like Figure 1 As shown, a software testing method based on the module compilation tool MBS according to the present invention includes the following steps: Step S1: Developers save the bash shell scripts that need to be executed to CaseDB, bind them with test item names, and specify the corresponding test items for each module, saving the correspondence to CaseDB.

[0025] Step S2: The fedmsg-hub listens for messages on the fedmsg message bus where MBS is located and passes them to the ansibleconsumer module. The ansibleconsumer module filters the messages it receives. If the message indicates that a module has been compiled, it proceeds to the next step; otherwise, it is ignored.

[0026] Step S3: The ansibleconsumer module obtains module information from the fedmsg message and searches for the corresponding test item and bash shell script in the CaseDB database.

[0027] Step S4: The ansibleconsumer module converts the obtained bash shell script into a beakerlib script.

[0028] Step S5: The ansibleconsumer module builds ansible playbooks for the module based on the obtained test items, and calls ansible to execute the playbooks to complete the test tasks.

[0029] The Ansible script execution method is used to complete the test tasks. This includes creating a container based on a custom Docker image, executing the test tasks within the container, and then uploading the test results to resultsDB. The specific content of the resultsDB is as follows: Step S6: Ansible runs a container environment using a customized Docker image based on the Ansible script, passes the beakerlib script to the container and executes it to complete the test task, stores the test results in a specified temporary directory outside the container, and finally destroys the container.

[0030] Step S7: The ansibleconsumer module collects the test results output by ansible executing ansible playbook and saves them to the specified directory.

[0031] Step S8: The ansibleconsumer module uploads the test results corresponding to each test item to resultsDB through the API provided by resultsDB.

[0032] CaseDB is used to store module test items and corresponding bash shell script content; the Python module ansibleconsumer is responsible for communicating with the MBS tool, building test tasks based on the test item information obtained from CaseDB, and uploading test results; and a customized Docker image is used to create containers to run test tasks.

[0033] In step S1, the CaseDB frontend provides web services via Python Flask, while the backend uses PostgreSQL for data storage. In this embodiment, the CaseDB frontend provides a web API for CRUD operations via Python Flask, which can convert web requests into SQL statements for execution and return results. The specific implementation is as follows: (1) Create routes using Flask, and when an access request for "query", "insert", or "delete" is received, call the corresponding Python function; (2) Obtain the GET parameters of the request in the corresponding Python function and fill them into the SQL statement template; (3) Submit the SQL statement to PostgreSQL and obtain the results; (4) Provide the results as the return value of the web API to the requester.

[0034] CaseDB contains a test case table (case_table) and a mapping table (mapping_table) that maps module names to test cases. In the test case table, the test item name (case_name) and its corresponding script (case_shell) have a one-to-one relationship, while in the mapping table, the module name (module_name) and the test item name (case_name) have a many-to-many relationship.

[0035] There is a special prefix "default_case" in case_table. Before Python returns the result of the corresponding test item in the query module, the test item with this prefix is ​​queried and appended to the result. Using Python to perform this operation avoids database complexity. The specific implementation method is as follows: (1) In the Python function of query, if the column of case_name in mapping_table is to be queried, after submitting the SQL statement to PostgreSQL and getting the result, a database query operation is performed on case_table to get the case_name with the prefix of default_case, which is added to the result of submitting the SQL statement to PostgreSQL and getting the result. The result is also provided to the requester as the return value of the web API.

[0036] Specifically, the AnsibleConsumer class inherits all the contents of the fedmsg.consumers.FedmsgConsumer class, and makes the following changes to the AnsibleConsumer class: Set the member variable topic to " "" is used to listen to all topics; the member variable config_key is set to "ansibleconsumer" to activate it in fedmsg-hub; Add process and que members to store child processes and task queues; Overload the __init__ function, initialize multiple child processes that run the tester function in the constructor to execute test tasks, save the child processes to the child process array process, and initialize a process-safe queue que to store task information; Overload the __del__ function to wait for the child process to exit before destroying it.

[0037] Override the consumer function to check the message type and module status. If the conditions are met, put the message into the task queue que.

[0038] In this embodiment, the specific process of executing the test task through the tester function is as follows: The `tester` function blocks as it retrieves tasks from the task queue `que`. If there are no tasks in the queue, the process will automatically sleep until it retrieves a task.

[0039] a2. After receiving the task, the tester function ends its sleep, retrieves the module ID and the task_id of the component package compiled in this case from the message, and concatenates the four strings name, stream, version, and context in the message in order to form the module's identity string.

[0040] a3. The tester function uses the module ID and the API provided by MBS to obtain the task_id of other dependent packages required by the module, and records them together with the task_id of the package compiled this time.

[0041] a4. Based on the task_id obtained in a3, retrieve all binary package links from koji and save them to the specified temporary file.

[0042] a5. Query the corresponding test item name and shell script from the API provided by CaseDB based on the module name.

[0043] a6. Convert the bash shell script to a beakerlib script and save it to a specified temporary location according to the test item names. The specific content is as follows: a6.1 Divide the shell script text into several units line by line.

[0044] a6.2 performs syntactic analysis on a unit-by-unit basis on the shell script text. If an incomplete for, while, or if statement is encountered, or if the text ends with a '\' symbol, the next unit is merged with the current unit until the syntactic text is complete or there are no more '\' symbols at the end of the line.

[0045] a6.3 If a unit contains multiple lines of text after parsing, rewrite it into a single line. If the line ends with a backslash ('\'), delete the backslash and merge the text; otherwise, add a semicolon (';') at the end of the line before merging.

[0046] a6.4 Adds a new unit before an existing unit. Its text content is a preset shell script with the following functions: a6.4.1 Downloads the URLs of the packages listed in the specified temporary file generated in a4 to the specified temporary directory; a6.4.2 Organizes these packages into a local repository as modules; a6.4.3 Adds a local repository entry to the yum repository directory; a6.4.4 Installs this module using the yum command.

[0047] a6.5 Replace single quotes “'” in the text within each cell with “\” to achieve quote escaping.

[0048] a6.6 At the beginning of the beakerlib script, import the runtime environment definition file provided by beakerlib, and add the beakerlib-defined start recording function "rlJournalStart" and test start function "rlPhaseStartTest".

[0049] a6.7 adds the prefix "rlRun '" and the suffix "'" to the text of each cell and writes it into the beakerlib script.

[0050] a6.8 Add the test end function "rlPhaseEnd", the print function "rlJournalPrintText", and the end recording function "rlJournalEnd" to the end of the beakerlib script.

[0051] a7. Generate an Ansible script based on the Ansible script template to execute beakerlib scripts within a specific target container. The specific content is as follows: a7.1 Specify in the script that the target image for running the container is a pre-defined Docker image.

[0052] a7.2 Adds the test item names obtained from a5 to the tests property section of the default role standard-test-beakerlib to execute the test scripts generated by a6.

[0053] a7.3 uses Ansible's copy function to transfer the specified temporary file obtained in a4 to the specified location in the container after the container starts, so that the test script generated by a6 can complete the download step.

[0054] a8. Call the ansible-playbook program, specify the playbook generated by a7, the directory where the files in a4 are located, and specify any directory as the value of the environment variable TEST_ARTIFACTS; the TEST_ARTIFACTS directory is used to save the test results output by beakerlib.

[0055] a9. Wait for ansible-playbook to finish executing and collect the beakerlib test result files from the TEST_ARTIFACTS directory.

[0056] a10. Parse the value of the results field from the YAML format text file collected by a9, which represents the result of this test, and upload it to ResultsDB along with the identity string generated by a2.

[0057] a11. Repeat steps a1-a10.

[0058] The specific process of configuring ansibleconsumer and fedmsg so that fedmsg can communicate with ansibleconsumer is as follows: (1) In the setup.py file of ansibleconsumer, set its entry_points attribute and add a section "moksha.consumer". In this section, bind the key "ansibleconsumer" to the overloaded AnsibleConsumer class in step 1. (2) Create a new file ansible_consumer.py in the configuration directory of fedmsg / etc / fedmsg.d, with the content "config=dict(ansibleconsumer=True)", which means enabling the class corresponding to the key "ansibleconsumer".

[0059] (3) After completing the above configuration, the fedmsg-hub process will load the ansibleconsumer class and call its consumer function after receiving a message. This ultimately achieves the goal of using ansibleconsumer to process fedmsg messages.

[0060] The specific customization process of the Docker image in step S6 is as follows: Based on the Fedora image, replace the yum repository with a local area network yum repository to solve the network restriction problem; Install the beakerlib, rsync, make, and beakerlib-libraries packages as the beakerlib runtime environment; Install modulemd-tools and its dependencies as the module build environment.

[0061] The present invention provides a software automation testing method based on the module compilation tool MBS. After the MBS tool issues a message indicating that the module compilation is complete, the compiled module is executed in a container with test tasks set by the developer.

[0062] Example 2:

[0063] The present invention provides a software testing system based on the module compilation tool MBS, used to implement the software testing method based on the module compilation tool MBS in Embodiment 1. The system is characterized by including ansibleconsumer module, CaseDB, ansible, a Docker image, and a Docker container for running the Docker image.

[0064] The `ansibleconsumer` module retrieves test case information from CaseDB via a web API. `ansibleconsumer` then passes the generated Ansible script and necessary test data to Ansible via a child process call. Ansible runs a Docker container from the Docker image, copies and mounts directories to pass the necessary information into the Docker container, and retrieves the test results output by beakerlib within the Docker container. `ansibleconsumer` then reads the test results from a file. This connection is also considered an internal connection within the test system.

[0065] The ansibleconsumer module obtains MBS compilation information via fedmsg; developers provide test items and bash scripts to CaseDB via the web API; and the ansibleconsumer module provides test results to ResultsDB via the web API. This connection also represents the connection between the test system and the external environment.

[0066] The Docker image is a customized Docker image. The customization process is as follows: based on the Fedora image, the yum source is replaced with a local area network yum source to solve the network limitation problem; the beakerlib, rsync, make, and beakerlib-libraries packages are installed as the beakerlib runtime environment; and modulemd-tools and its dependencies are installed as the module build environment.

[0067] For a detailed description of each part of the testing system of the present invention, please refer to Embodiment 1, and it will not be repeated here.

[0068] The third objective of this invention is achieved as follows: A computer-readable storage medium storing a computer program, characterized in that, when the computer program is executed by a processor, it implements the software testing method based on the module compilation tool MBS of Embodiment 1.

[0069] In addition, the software automated testing method and corresponding system based on the module compilation tool MBS of the present invention realizes automated testing of modules by constructing test tasks and orchestrating tasks and containers.

[0070] The abbreviations and key terms involved in this invention are explained as follows: (1) MBS: Module Build Service, a tool for modular compilation of software packages. It provides a series of interfaces for building modules, verifies the modulemd file that defines the module, prepares the compilation environment for the koji compilation system, and submits compilation tasks to koji to complete the module compilation task. (2) fedmsg: A message bus released by the Fedora Infrastructure team. MBS sends important information generated during the module compilation process to fedmsg, and other components can obtain these messages from fedmsg.

[0071] (3) fedmsg.consumers.FedmsgConsumer: A Python class provided by fedmsg that can be used as an interface to obtain messages sent by MBS.

[0072] (4) fedmsg-hub: a daemon process provided by fedmsg, which is used in this invention to continuously listen for messages sent by MBS.

[0073] (5) Ansible: An automation framework that can execute commands in a specific environment according to a pre-configured playbook. In this invention, the executable program ansible-playbook is used to execute the playbook of "creating a container - starting a test - destroying a container". The testing function of Ansible using beakerlib is implemented by the preset role standard-test-beakerlib provided by the package standard-test-roles.

[0074] (6) ResultsDB: A database that stores test results. MBS uses the records in the database to determine whether a module has passed the test and provides web APIs for adding and querying.

[0075] (7) beakerlib: A shell-level automated testing framework that can generate highly readable test reports based on test items. Its syntax differs somewhat from that of shell. This invention utilizes several of its predefined functions, such as rlJournalStart.

[0076] (8) Message: When the state of a module changes, MBS sends a JSON message to fedmsg containing component information and current state of that module. In this document, "message" or "information" generally refers specifically to such messages sent by MBS to fedmsg.

[0077] (Note: The above definitions are publicly available results from others, and their internal implementation is not part of this invention.)

[0078] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A software testing method based on a module-based compilation tool (MBS), characterized in that, Includes the following steps: Step S1: Developers save the bash shell scripts that need to be executed to CaseDB, bind them with test item names, and specify the corresponding test items for each module, saving the correspondence to CaseDB. Step S2: fedmsg-hub listens for messages on the fedmsg message bus where MBS is located and passes them to the ansibleconsumer module. The ansibleconsumer module filters the messages it receives. If the message indicates that a module has been compiled, it proceeds to the next step; otherwise, it is ignored. Step S3: The ansibleconsumer module obtains module information from the fedmsg message and searches for the corresponding test item and bash shell script in the CaseDB database. Step S4: The ansibleconsumer module converts the obtained bash shell script into a beakerlib script; Step S5: The ansibleconsumer module builds ansible playbooks for the module based on the obtained test items, and calls ansible to execute the playbooks to complete the test tasks. The process of calling the Ansible execution playbook to complete the test task includes creating a container based on a customized Docker image, executing the test task in the container, and then uploading the test results to resultsDB. In step S1, the CaseDB frontend provides web services via Python Flask, and the backend uses PostgreSQL for data storage. The CaseDB frontend provides a web API for CRUD operations via Python Flask, converting web requests into SQL statements for execution and returning results; specifically: Use Flask to create routes, and when a request for "query", "insert", or "delete" is received, call the corresponding Python function; In the corresponding Python function, retrieve the GET parameters of the request and populate them into the SQL statement template; Submit SQL statements to PostgreSQL and retrieve the results; Provide the result as a web API return value to the requester; CaseDB contains a test case table (case_table) and a mapping table (mapping_table) that maps module names to test cases. In the test case table, the test item name (case_name) and its corresponding script (case_shell) have a one-to-one relationship, while in the mapping table, the module name (module_name) and the test item name (case_name) have a many-to-many relationship. The `case_table` contains a special prefix "default_case". Before Python returns the results for the corresponding test items from the query module, it retrieves test items with this prefix and appends them to the results. Specifically, in the Python function `query`, if the query is for the `case_name` column in `mapping_table`, after submitting the SQL statement to PostgreSQL and obtaining the results, it performs another database query on `case_table` to obtain `case_name` entries with the prefix "default_case", adds them to the results of the SQL statement submitted to PostgreSQL, and provides these results as the web API return value to the requester.

2. The software testing method based on module-based compilation tool (MBS) according to claim 1, wherein, The specific steps for creating a container based on a customized Docker image, executing test tasks within the container, and then uploading the test results to resultsDB are as follows: Step S6: Ansible runs a container environment using a customized Docker image based on the Ansible script, passes the beakerlib script to the container and executes it to complete the test task, stores the test results in a specified temporary directory outside the container, and finally destroys the container. Step S7: The ansibleconsumer module collects the test results output by ansible executing ansible playbook and saves them to the specified directory; Step S8: The ansibleconsumer module uploads the test results corresponding to each test item to resultsDB through the API provided by resultsDB.

3. The software testing method based on module-based compilation tool (MBS) according to claim 1, wherein, The CaseDB is used to store module test items and their corresponding bash shell script contents.

4. The software testing method based on module-based compilation tool (MBS) according to claim 1, wherein, The AnsibleConsumer class inherits all the contents of the fedmsg.consumers.FedmsgConsumer class, and the following changes are made to the AnsibleConsumer class: The member variable topic is set as , for listening to all topics; Set the member variable config_key to "ansibleconsumer" for activation in fedmsg-hub; Add process and que members to store child processes and task queues; Overload the __init__ function, initialize multiple child processes that run the tester function in the constructor to execute test tasks, save the child processes to the child process array process, and initialize a process-safe queue que to store task information; Overload the __del__ function to wait for the child process to exit before destroying it; Override the consumer function to check the message type and module status. If the conditions are met, put the message into the task queue que.

5. The software testing method based on module-based compilation tool (MBS) according to claim 2, wherein, The specific customization process of the Docker image in step S6 is as follows: Based on the Fedora image, replace the yum repository with a local area network yum repository to solve the network restriction problem; Install the beakerlib, rsync, make, and beakerlib-libraries packages as the beakerlib runtime environment; Install modulemd-tools and its dependencies as the module build environment.

6. A software testing system based on the module compilation tool MBS, used to implement the software testing method based on the module compilation tool MBS as described in any one of claims 1-5, characterized in that, This includes the Ansible Consumer module, CaseDB, Ansible, a Docker image, and the Docker container used to run the Docker image. The ansibleconsumer module obtains test case information from CaseDB via web API. The ansibleconsumer passes the generated ansible script and the data required for testing to ansible through a subprocess call. Ansible runs a Docker container from the Docker image and passes the required information to the Docker container by copying and mounting directories, and obtains the test results output by the Docker container.

7. The module-based build tool (MBS) based software testing system according to claim 6, characterized in that, The ansibleconsumer module obtains MBS compilation information through fedmsg; developers provide test items and bash scripts to CaseDB through the web API; the ansibleconsumer module provides test results to ResultsDB through the web API.

8. The module-based build tool (MBS) based software testing system according to claim 6, wherein, The Docker image is a customized Docker image. The customization process of the Docker image is as follows: based on the Fedora image, the yum source is replaced with a local area network yum source to solve the network limitation problem; the beakerlib, rsync, make, and beakerlib-libraries packages are installed as the beakerlib runtime environment; and modulemd-tools and its dependent packages are installed as the module build environment.

9. A computer readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the software testing method based on the module compilation tool MBS as described in any one of claims 1 to 5.

Images