Embedded operating system test method, device, equipment, medium and product

Abstract

The invention provides an embedded operating system testing method, device and equipment, a medium and a product, and is applied to the field of operating system testing. A first device is provided with a server side of an embedded operating system and an automatic testing system, a second device is provided with a client side of the automatic testing system, and on one side of the first device, a testing request message sent by the second device is received, the test request message comprises a main command code for indicating a test module, a sub-command code for indicating a test item and a test parameter related to the test item, the test module corresponds to a functional module of the embedded operating system, and the test item corresponds to a sub-function supported by the functional module; analyzing the test request message to obtain an analysis result; according to the analysis result, testing the sub-function to obtain a test result; generating a test response message according to the test result; and sending the test response message to the second equipment. Therefore, automatic testing of the embedded operating system is realized, and the testing efficiency of the embedded operating system is improved.

Description

Technical Field

[0001] The present application relates to the field of operating system testing, and in particular to an embedded operating system testing method, device, equipment, medium and product. Background Art

[0002] In the development process of embedded operating systems, embedded operating system testing is a key link to ensure the normal functions and performance of the embedded operating system.

[0003] In the related art, developers conduct unit testing on embedded operating systems during the development phase, including manual testing and / or partially automated testing; or, during the product function testing phase, conduct side verification to check whether the system functions used by the software product are normal.

[0004] However, the testing efficiency of the embedded operating system in the above method is low. Summary of the invention

[0005] In view of this, the embodiments of the present application are dedicated to providing an embedded operating system testing method, apparatus, device, medium and product to solve the problem of low testing efficiency of the embedded operating system.

[0006] According to a first aspect of an embodiment of the present application, there is provided an embedded operating system testing method, which is applied to a first device, wherein the first device is deployed with an embedded operating system and a server of an automated testing system, and a second device is deployed with a client of the automated testing system, wherein the embedded operating system testing method comprises: receiving a test request message sent by the second device, wherein the test request message comprises a main command code indicating a test module, a sub-command code indicating a test item in the test module, and a test parameter related to the test item, wherein the test module corresponds to a functional module of the embedded operating system, and the test item corresponds to a sub-function supported by the functional module; parsing the test request message to obtain a parsing result, wherein the parsing result comprises the main command code, the sub-command code, and the test parameter; testing the sub-function according to the parsing result to obtain a test result; generating a test response message according to the test result; and sending the test response message to the second device.

[0007] In some embodiments, testing the sub-function according to the analysis result to obtain a test result includes: obtaining a main command code mapping relationship; in the main command code mapping relationship, determining the test module according to the main command code; obtaining a sub-command code mapping relationship of the test module; in the sub-command code mapping relationship, determining the test item according to the sub-command code; testing the sub-function according to the test item and the test parameters to obtain the test result.

[0008] In some embodiments, the test item is a test function of the sub-function, and the test function is obtained by encapsulating an API related to the sub-function and a test operation of the sub-function, and testing the sub-function according to the test item and the test parameters to obtain the test result includes: inputting the test parameters into the test item, testing the sub-function by executing the test item, and obtaining the test result.

[0009] In some embodiments, the test request message also includes a test type; if the test type is an interface test, the test request message includes a group of module test information, and the module test information includes the main command code, the sub-command code and the test parameters; or, if the test type is a module combination service test, the test request message includes multiple groups of module test information, and each group of module test information in the multiple groups of module test information includes the main command code, the sub-command code and the test parameters, respectively, and different module test information in the multiple groups of module test information includes different main commands.

[0010] In some embodiments, the test result includes whether the sub-function is tested successfully, the test error type of the sub-function and a result description statement of the sub-function; the test response message includes the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag and the result description statement, the first flag indicates whether the sub-function is tested successfully, and the second flag indicates the test error type of the sub-function; generating a test response message according to the test result includes: determining the flag value of the first flag according to whether the sub-function is tested successfully; determining the flag value of the second flag according to the test error type of the sub-function; generating the test response message according to the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag and the result description statement.

[0011] In some embodiments, before parsing the test request message and obtaining the parsing result, the embedded operating system testing method also includes: adding a test task corresponding to the test request message in a task queue of a thread pool, and the thread pool is used for automated testing of the embedded operating system; obtaining the test task in the task queue through an idle thread in the thread pool, and the task acquisition method of the thread pool includes parallel acquisition and / or serial acquisition.

[0012] According to a second aspect of an embodiment of the present application, an embedded operating system testing device is provided, which is applied to a first device, wherein the first device is deployed with an embedded operating system and a server of an automated testing system, and the second device is deployed with a client of the automated testing system, and the embedded operating system testing device comprises: a receiving unit, for receiving a test request message sent by the second device, wherein the test request message comprises a main command code indicating a test module, a sub-command code indicating a test item in the test module, and a test parameter related to the test item, wherein the test module corresponds to a functional module of the embedded operating system, and the test item corresponds to a sub-function supported by the functional module; a parsing unit, for parsing the test request message to obtain a parsing result, wherein the parsing result comprises the main command code, the sub-command code, and the test parameter; a testing unit, for testing the sub-function according to the parsing result to obtain a test result; a message generating unit, for generating a test response message according to the test result; and a sending unit, for sending the test response message to the second device.

[0013] According to the third aspect of the embodiments of the present application, an electronic device is provided, comprising a memory and a processor; the memory is connected to the processor and is used to store programs; the processor is used to implement the embedded operating system testing method as described in the first aspect or any embodiment of the first aspect by running the program in the memory.

[0014] According to a fourth aspect of an embodiment of the present application, a storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the embedded operating system testing method as described in the first aspect or any embodiment of the first aspect is implemented.

[0015] According to a fifth aspect of the embodiments of the present application, a computer program product is provided, which includes a computer program. When the computer program is executed by a processor, it implements the embedded operating system testing method as described in the first aspect or any embodiment of the first aspect.

[0016] It can be seen from the above technical scheme that the embodiments of the present application provide an embedded operating system testing method, apparatus, equipment, medium and product, which implements automated testing of the embedded operating system and improves the testing efficiency of the embedded operating system by deploying a second device that is a client of the automated testing system and interacting with a first device that is a server of the embedded operating system and the automated testing system, and testing the sub-functions of the functional modules in the embedded operating system on the first device. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0018] Figure 1 A schematic diagram of an implementation environment involved in an embodiment of the present application;

[0019] Figure 2 The following is a flow chart of an embedded operating system testing method provided in accordance with an embodiment of the present application. Figure 1 ;

[0020] Figure 3 The following is a flow chart of an embedded operating system testing method provided in accordance with an embodiment of the present application. Figure 2 ;

[0021] Figure 4 The following is a flow chart of an embedded operating system testing method provided in accordance with an embodiment of the present application. Figure 3 ;

[0022] Figure 5 A system architecture diagram of the automated testing system provided in this embodiment;

[0023] Figure 6 A schematic diagram of the structure of an embedded operating system testing device provided according to an embodiment of the present application;

[0024] Figure 7 It is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0026] An embedded operating system is an operating system located on an embedded device. The application areas of embedded operating systems are very wide. For example, some home entertainment devices, vehicle-mounted devices, and industrial control devices are deployed with embedded operating systems. For embedded operating systems, especially those running on devices in resource-constrained environments (such as microcontrollers, single-board computers, or other dedicated hardware platforms), it is necessary to conduct efficient embedded operating system testing.

[0027] In the related art, there are two ways to test embedded operating systems: the first way is that the developers of the embedded operating system perform manual or partially automated unit testing on the embedded operating system during the development phase; the second way is to verify whether some functions of the embedded operating system can meet the needs of the current product during the product function testing phase.

[0028] For example, in the first method, the developer performs the following operations: 1. Manually write test cases and / or test scripts according to the interface functions of the embedded operating system; 2. Manually execute test cases on the target device used for the test, or automatically execute a small number of test cases on the target device through test scripts; 3. Determine whether the interface return value of the embedded operating system or the peripheral action is accurate to obtain the test results; 4. Manually record the test results and write a test report.

[0029] For example, in the second method, the tester of the product function performs the following operations: 1. Writes test cases for the product functions; 2. Manually executes the test cases one by one on the product tool (referring to the user operation tool released together with the product and used in conjunction with the product, such as client tools, configuration tools, web interface tools, configuration tools, etc.) or the target hardware platform (referring to the device that actually runs the embedded operating system) according to the operating steps of the test cases; 3. Manually fills in the test results of each test case; 4. Manually writes a test report and conducts test quality analysis.

[0030] Based on the above process, it can be seen that the above two methods have the following disadvantages:

[0031] Disadvantages 1. Low efficiency, high maintenance cost and unstable test accuracy: (1) Manual testing relies entirely on manual operation. Each test requires re-executing the test cases according to the test steps. In cross-testing, new testers need to understand the test cases again, which leads to low efficiency and high maintenance cost. In addition, due to the differences in experience and skills of testers, the accuracy of test results is unstable. (2) In partially automated testing, only part of the test operations are automated by writing scripts, which still requires a lot of manual participation. It has the same disadvantages as manual testing. In addition, the test scenarios and test case parameters in the test scripts are fixed. Every time a test case is added or modified, the script needs to be rewritten, which leads to a large maintenance workload.

[0032] Disadvantage 2: Poor consistency of test results and limited coverage of test cases: (1) In manual testing, test cases are not solidified in the form of test codes. The test results depend on the tester's understanding of the test case operation steps. Different testers have different understandings, resulting in poor consistency and repeatability of test results. In addition, the test pressure of manual testing is not high enough and the scenarios are not complete, which may miss some system problems. (2) In partial automation testing, some positive functions of some interfaces of the embedded operating system are partially automated. Each time a pre-written test script is executed, it can usually only handle simple test cases. Complex scenarios are still handled manually by testers. If all test scenarios are to be covered, the script writing workload is huge. (3) In product function testing, on the one hand, the product function does not cover all the functions of the operating system. On the other hand, the product function testing focuses on the demand indicators of product users, not the actual functional indicators of the operating system. Therefore, for embedded operating systems, the test coverage of product function testing is not comprehensive and fails to reflect the functional indicators and capabilities of the embedded operating system itself.

[0033] It can be seen that due to many factors such as differences in the levels of testers, limited testing tools, limited resources, lack of standardization (such as unified testing standards, unified testing processes, test case writing specifications, test script writing specifications), the main problems of embedded operating systems are low testing efficiency, low testing quality, and limited coverage.

[0034] To solve the above problems, the embodiment of the present application provides an embedded operating system testing method, device, equipment, chip, medium and product, which are applied to the field of operating system testing. In the embedded operating system testing method: the automated testing of the embedded operating system is realized by an automated testing system, the server of the automated testing system is deployed on the first device where the embedded operating system is located, and the client of the automated testing system is deployed on the second device; the first device can receive the test request message of the second device, and perform automated testing on the functional modules in the embedded operating system according to the command code and test parameters contained in the test request message to obtain the test results; then, the first device sends a test response message to the second device according to the test results. Thus, the manual intervention of the test process is significantly reduced, and the test efficiency and test quality of the embedded operating system are improved; the first device analyzes and understands the test request message before executing the test operation, which improves the consistency and repeatability of the test results; compared with manual testing, the test pressure of automated testing is sufficient and can cover more scenarios, which improves the coverage of embedded operating system testing; compared with product testing, this application focuses on the operating system itself, which can reflect the functional indicators and capabilities of the embedded operating system itself.

[0035] Exemplary Implementation Environment

[0036] Please refer to Figure 1 , Figure 1 1 is a schematic diagram of an implementation environment according to an embodiment of the present application. The implementation environment involved in the present application includes a first device 100, a second device 110, a switch 120 ( Figure 1 Take two switches as an example) and a user terminal 130. Among them, the server and embedded operating system of the automated test system are deployed on the first device 100, and the client of the automated test system is deployed on the second device 110. The first device 100, the second device 110 and the user terminal 130 can establish a network connection and perform network data interaction through the switch 120, and the second device 110 and the user terminal 130 can also perform network data interaction through other methods (such as mobile communication networks).

[0037] In the implementation environment, first, the user terminal 130 can access the client of the automated testing system on the second device 110, and through interactive operations on the client, trigger the second device 110 to send a test request message to the first device 100; after the first device 100 receives the test request message, it parses the test request message by running the server of the automated testing system, and tests the embedded operating system based on the parsing result to obtain the test result; then, the first device 100 can send a test response message to the second device 110 according to the test result; after receiving the test response message, the second device 110 can feed back the test result to the user terminal 130 according to the test response message.

[0038] Among them, the first device 100 and the second device 110 can be a server or a terminal; in the implementation environment, multiple first devices 100 may be included to realize automated testing of multiple embedded operating systems; in the implementation environment, multiple user terminals 130 may be included to realize automated testing of embedded operating systems by multiple testers to improve testing efficiency.

[0039] Exemplary Methods

[0040] See also Figure 2 In an exemplary embodiment, a method for testing an embedded operating system is provided, and the method for testing an embedded operating system comprises the following steps:

[0041] S201, the first device receives a test request message sent by the second device, the test request message includes a main command code indicating a test module, a sub-command code indicating a test item in the test module, and test parameters related to the test item, the test module corresponds to a functional module of the embedded operating system, and the test item corresponds to a sub-function supported by the functional module.

[0042] Among them, an embedded operating system and a server of an automated test system are deployed on the first device, that is, the software program of the embedded operating system and the server program of the automated test system are installed on the first device, and the server program of the automated test system is used for automated testing of the embedded operating system. A client of the automated test system is deployed on the second device, that is, a client program of the automated test system is deployed on the second device. Communication between the server of the automated test system and the client of the automated test system can be realized through communication between the first device and the second device.

[0043] In the process of designing the automated test system, a custom private protocol is designed for the automated test system, and the first device and the second device can communicate based on the custom private protocol. In the defined private protocol, the test request message includes the following fields: a main command code field, a sub-command code field, and a test parameter field, the field value of the main command code field is the main command code, the field value of the sub-command code field is the sub-command code, and the field value of the test parameter field is the test parameter.

[0044] Among them, the test module belongs to the program module in the server of the automated test system, and the test item is the subroutine module in the test module. In the server of the automated test system, multiple test modules are included, and the multiple test modules respectively include one or more test items. In the design process of the server of the automated test system, multiple test modules and test items corresponding to the multiple test modules can be designed according to the multiple functional modules included in the embedded operating system and the sub-functions supported by the multiple functional modules, and the corresponding main command code is designed for the test module, and the corresponding sub-command code is designed for the test item.

[0045] Among them, a main command code indicates a test module, and a sub-command code indicates a test item.

[0046] In this embodiment, the first device receives a test request message sent by the second device. In the test request message, the main command code indicates a test module, and the sub-command code indicates a test item of the test module, so as to request to test a sub-function supported by a functional module in the embedded operating system, the functional module corresponds to the test module indicated by the main command code, and the sub-function corresponds to the test item indicated by the sub-command code.

[0047] In one example, the test request message includes a main command code, a sub-command code corresponding to the main command code, and a test parameter corresponding to the sub-command code, so as to request to test a sub-function supported by a functional module in the embedded operating system.

[0048] In another example, the test request message includes a main command code, multiple sub-command codes corresponding to the main command code, and test parameters corresponding to the multiple sub-command codes, so as to request testing of multiple sub-functions supported by a functional module in the embedded operating system.

[0049] In another example, the test request message includes multiple main command codes, one or more sub-command codes corresponding to the multiple main command codes, and test parameters corresponding to each sub-command code, so as to request testing of sub-functions supported by multiple functional modules in the embedded operating system.

[0050] S202, the first device parses the test request message to obtain a parsing result, where the parsing result includes a main command code, a sub-command code, and a test parameter.

[0051] In this embodiment, the first device can parse the test request message based on a customized private protocol between the first device and the second device to obtain a parsing result, wherein the parsing result includes the parsing result of the field value of each field in the test request message, namely, the main command code, sub-command code and test parameters.

[0052] In one example, the parsing result includes a main command code, a sub-command code corresponding to the main command code, and a test parameter corresponding to the sub-command code.

[0053] In another example, the parsing result includes a main command code, a plurality of sub-command codes corresponding to the main command code, and test parameters corresponding to the plurality of sub-command codes.

[0054] In another example, the analysis result includes a plurality of main command codes, one or more sub-command codes corresponding to the plurality of main command codes, and a test parameter corresponding to each sub-command code.

[0055] S203: The first device tests the sub-function according to the analysis result to obtain a test result.

[0056] In this embodiment, the first device can determine the test module indicated by the main command code in the parsing result among multiple test modules included in the automated testing system, and determine the test item indicated by the sub-command code in the parsing result among the test items corresponding to the test module, and test the sub-function corresponding to the test item based on the test item and the test parameters related to the test item in the parsing result to obtain a test result.

[0057] S204: The first device generates a test response message according to the test result.

[0058] Among them, in the customized private protocol, the test response message includes the following fields: a main command code field, a sub-command code field and a test result field.

[0059] In this embodiment, the first device can determine the main command code as the field value of the main command code field, determine the sub-command code as the field value of the sub-command code field, convert the test result into a test result parameter, determine the test result parameter as the field value of the test result field, and obtain a test response message.

[0060] In one example, the test response message includes a main command code, a sub-command code corresponding to the main command code, and a test result parameter corresponding to the sub-command code to indicate a test result of a sub-function supported by a functional module in the embedded operating system.

[0061] In another example, the test response message includes a main command code, multiple sub-command codes corresponding to the main command code, and test result parameters corresponding to the multiple sub-command codes to indicate the test results of multiple sub-functions supported by a functional module in the embedded operating system.

[0062] In another example, the test response message includes multiple main command codes, one or more sub-command codes corresponding to the multiple main command codes, and test result parameters corresponding to each sub-command code to indicate the test results of sub-functions supported by multiple functional modules in the embedded operating system.

[0063] S205: The first device sends a test response message to the second device.

[0064] In this embodiment, after generating the test response message, the first device sends the test response message to the second device to inform the second device of the test result of the embedded test system.

[0065] In the embodiment of the present application, based on the functional modules of the embedded operating system and the sub-functions supported by the functional modules, the test modules of the automated testing system and the test items contained in the test modules are designed. The first device parses the test request message of the second device to obtain the corresponding command code and test parameters, determines the test items involved in the test according to the command code, and tests the sub-functions supported by the functional modules in the embedded operating system based on the test items and test parameters. Thus, on the one hand, end-to-end automated testing of the embedded operating system is achieved, and the test efficiency and test quality are improved; on the other hand, the coverage of the automated testing of the embedded operating system is improved through the test modules corresponding to the functional modules of the embedded operating system and the test items corresponding to the sub-functions supported by the functional modules.

[0066] Below, other feasible exemplary implementations are provided for some of the contents in the above embodiments.

[0067] In some embodiments, S203 may include: obtaining a main command code mapping relationship; in the main command code mapping relationship, determining a test module according to the main command code; obtaining a sub-command code mapping relationship of the test module; in the sub-command code mapping relationship, determining a test item according to the sub-command code; testing the sub-function according to the test item and the test parameter to obtain a test result.

[0068] Among them, the main command code mapping relationship may include the mapping relationship (or correspondence relationship) between all test modules in the server of the automated test system and multiple main command codes. In the main command code mapping relationship, the test module corresponds to the main command code one by one, that is, the main command code corresponding to the test module is unique.

[0069] Among all the test modules, each test module may correspond to its own sub-command code mapping relationship (or correspondence relationship). The sub-command code mapping relationship of the test module may include the mapping relationship between all test items in the test module and multiple sub-command codes, and the test items correspond to the sub-command codes one by one, that is, the sub-command code corresponding to the test item is unique.

[0070] In this embodiment, the first device can obtain the main command mapping relationship from the local data, and search the main command code mapping relationship for the test module corresponding to the main command code in the parsing result (i.e., the main command code in the test request message); then, obtain the sub-command code mapping relationship of the test module from the local data, and search the sub-command code mapping relationship for the test item corresponding to the sub-command code in the parsing result. Thus, based on the mapping relationship between the main command code and the test module, and the mapping relationship between the sub-command code and the test item, the accuracy of determining the test module and the test item based on the parsing result is improved.

[0071] In one example, the main command code mapping relationship exists in the form of a main command code mapping table, and the sub-command code mapping relationship exists in the form of a sub-command code mapping table. The first device stores the main command code mapping table and the sub-command code mapping table corresponding to the test module. The first device can use the main command code in the parsing result as a query keyword to search for the test module in the main command code mapping table, and can use the sub-command code in the parsing result as a query keyword to search for the test item in the sub-command code mapping table of the test module. Thus, the accuracy of searching the test module and the test item is improved through the data table.

[0072] In some embodiments, the test item is a test function of a sub-function, and the test function is obtained by encapsulating an application programming interface (API) related to the sub-function and a test operation of the sub-function. S203 may include: inputting test parameters into the test item, testing the sub-function by executing the test item, and obtaining a test result.

[0073] In an embedded operating system, a functional module may provide one or more APIs. The APIs provided by the functional module are related to the sub-functions supported by the functional module. An application or a third-party device may use the sub-functions supported by the functional module by calling the APIs provided by the functional module.

[0074] In this embodiment, the API provided by the function module of the embedded operating system may not necessarily be used in the sub-function test of the function module. For example, a certain function module provides 8 APIs, and the test of one of the sub-functions supported by the function module requires 3 of them, and the test of another sub-function supported by the function module requires 2 of them. Therefore, in the development process of the automated test platform, according to the test requirements of the embedded operating system, the function modules in the embedded operating system, the sub-functions supported by the function modules, and the API provided by the function modules, the APIs related to the sub-functions supported by the function modules and the test operations of the sub-functions supported by the function modules can be encapsulated to obtain the test function of the sub-function, that is, to obtain the test item corresponding to the sub-function. During the test process, after the first device parses the test request message and obtains the parsing result, it determines the test item indicated by the sub-command code in the parsing result, inputs the test parameters in the parsing result into the test item (i.e., inputs the test function), and tests the sub-function corresponding to the test item by executing the test item to obtain the test result.

[0075] It can be seen that in the above embodiments: on the one hand, the test items can be directly called to test the sub-functions during the automated testing process, thereby improving the testing efficiency of the embedded operating system; on the other hand, the test operations are fixed in the form of test items, thereby achieving consistency and standardization of the embedded operating system testing process and improving the testing quality of the embedded operating system.

[0076] In some embodiments, the test request message also includes a test type; if the test type is an interface test, the test request message includes a set of module test information, and the module test information includes a main command code, a sub-command code, and a test parameter; or, if the test type is a module combination service test, the test request message includes multiple sets of module test information, and each set of module test information in the multiple sets of module test information includes a main command code, a sub-command code, and a test parameter, respectively, and different module test information in the multiple sets of module test information includes different main commands. Thus, in the automated testing of the embedded operating system, not only interface testing can be implemented, but also module combination service testing can be implemented, which improves the diversity of the test function.

[0077] The test request message also includes a type field, and the field value of the type field indicates the test type. For example, if the field value of the type field is a, the test type is an interface test, and if the field value of the test type is b, the test type is a module combination service test.

[0078] Among them, in a test request message, the test type is interface test or module combination service test. Interface test can be understood as testing the sub-functions supported by a single functional module; module combination service test can be understood as testing the sub-functions supported by multiple functional modules, and the sub-functions supported by the multiple functional modules involve the same service.

[0079] In one example, a test request message includes a test type and a set of module test information, the test type is an interface test, and a set of module test information includes a main command code, a sub-command code and test parameters to test the sub-functions supported by a functional module in an embedded operating system.

[0080] In another example, the test request message includes a test type and multiple groups of module test information, the test type is a module combination service test, and each group of module test information includes a main command code, a sub-command code and test parameters to test the sub-functions supported by multiple functional modules in the embedded operating system.

[0081] In some embodiments, in the test request message, the test parameters may include at least one of the following: input parameters of an API related to a sub-function, test execution times, or test execution time. Thus, different input parameters, test execution times, and / or test execution times may be indicated for automated testing, thereby improving the comprehensiveness of embedded operating system testing.

[0082] For example, the test request message is represented as: {test type: 0; module test information: {main command code: 1; sub-command code: 1000; requested memory size: 256; test execution times: 1000; .........}

[0083] Among them, the test type is 0, that is, the field value of the type field is 0, indicating that the test type is an interface test; the main command code is 1, and the corresponding test module is the memory management module; the sub-command code is 1000, and the corresponding test item is a memory application interface test; the applied memory size and the number of test executions are test parameters, and the applied memory size is, for example, 256 bits.

[0084] For another example, the test request message is represented as: {test type: 1; module test information: {main command code: 2; ...}, {main command code: 3; ...}}.

[0085] Among them, the test type is 1, indicating that the test type is a module combination service test; in the first group of module test information, the main command code is 2, and the corresponding test module is the system clock module; in the second group of module test information, the main command code is 3, and the corresponding test module is the network communication module.

[0086] In some embodiments, the test result includes whether the sub-function is tested successfully, the test error type of the sub-function, and the result description statement of the sub-function; the test response message includes the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag, and the result description statement, the first flag indicates whether the sub-function is tested successfully, and the second flag indicates the test error type of the sub-function. S204 may include: the first device determines the flag value of the first flag according to whether the sub-function is tested successfully; determines the flag value of the second flag according to the test error type of the sub-function; the first device generates a test response message according to the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag, and the result description statement. Thus, the second device can accurately obtain the test result of the sub-function based on the test response message.

[0087] In this embodiment, the first device determines the flag value of the first flag according to whether the sub-function in the test result is tested successfully. For example, if the sub-function is tested successfully, the flag value of the first flag is determined to be 0, otherwise the flag value of the first flag is determined to be 1. Whether the sub-function is tested successfully refers to whether the test operation of the sub-function is executed successfully, such as whether the memory application operation is executed successfully; different test error types may correspond to different flag values ​​of the second flag. The first device may search for the flag value corresponding to the test error type of the sub-function in the test result in the mapping relationship between the test error type and the flag value of the second flag, and determine that the flag value of the second flag is the flag value corresponding to the test error type of the sub-function. The first device writes the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag and the result description statement into the corresponding fields contained in the test response message to obtain the test response message.

[0088] Specifically, the first device can write the main command code into the main command field, write the sub-command code into the sub-command field contained in the test response message, write the flag value of the first flag into the first flag field corresponding to the first flag, write the flag value of the second flag into the second flag field corresponding to the second flag, and write the result description statement into the data field to obtain a test response message containing these fields.

[0089] For example, the test response message is represented as: {main command code: 1; sub-command code: 1000; execution result of the test operation (ie, the first flag, indicating whether the sub-function test is successful): 1; test error code (ie, the second flag, indicating the error type): 1000; result description statement: memory application failed}.

[0090] Among them, the main command code is 1, and the corresponding test module is the memory management module; the sub-command code is 1000, and the corresponding test item is the memory application interface test; the execution result of the test operation is 1, indicating that the test failed. If the execution result of the test operation is 0, it means that the test is successful; the test error code is 1000, and the test error code is 0 if the test is successful.

[0091] It should be noted that the content in the test request message and the test response message can be flexibly expanded based on the above embodiments according to actual scenarios and actual needs, that is, the customized private protocol between the first device and the second device can be flexibly expanded, which is not described one by one with examples here.

[0092] In one example, the customized private protocol between the first device and the second device may be designed based on the transmission control protocol (TCP).

[0093] See also Figure 3 In another exemplary embodiment, a method for testing an embedded operating system is provided, the method comprising the following steps:

[0094] S301, the first device receives a test request message sent by the second device, the test request message includes a main command code indicating a test module, a sub-command code indicating a test item in the test module, and test parameters related to the test item, the test module corresponds to a functional module of the embedded operating system, and the test item corresponds to a sub-function supported by the functional module.

[0095] The implementation principle and technical effects of S301 may refer to the aforementioned embodiments and will not be described in detail.

[0096] S302, the first device adds a test task corresponding to the test request message in a task queue of a thread pool, where the thread pool is used for automated testing of an embedded operating system.

[0097] Understandably, the thread pool is specifically used for automated testing of embedded operating systems, so as to improve testing efficiency by setting a dedicated thread pool for automated testing of embedded operating systems. A task queue of the thread pool may include multiple test tasks, and one test task corresponds to one test request message.

[0098] In this embodiment, after the first device receives the test request message sent by the second device, it adds the test task corresponding to the test request message to the task queue of the thread pool, and waits for the idle thread in the thread pool to execute the test task according to the task order in the task queue.

[0099] In one example, the first device can simultaneously receive multiple test request messages, which can come from the same or different second devices; the first device can add the test tasks corresponding to the multiple test request messages to the task queue of the thread pool. Thus, batch testing of the functions of the embedded operating system is achieved, and the testing efficiency of the embedded operating system is improved.

[0100] S303, the first device obtains the test task in the task queue through the idle thread in the thread pool, and the task acquisition method of the thread pool includes parallel acquisition and / or serial acquisition.

[0101] In this embodiment, the first device obtains the test task from the task queue through the idle thread in the thread pool, and performs subsequent operations on the test request message corresponding to the obtained test task. Among them, the idle thread obtains multiple test tasks from the task queue in parallel, and executes the multiple test tasks in parallel, so as to realize the batch execution of the functional test of the embedded operating system and improve the test efficiency; or, the idle thread obtains the next test task to be executed from the task queue in series, and executes the test tasks in series.

[0102] S304, the first device parses the test request message to obtain a parsing result, where the parsing result includes a main command code, a sub-command code and a test parameter.

[0103] S305: The first device tests the sub-function according to the analysis result to obtain a test result.

[0104] S306: The first device generates a test response message according to the test result.

[0105] S307: The first device sends a test response message to the second device.

[0106] The implementation principles and technical effects of S304 to S307 may refer to the aforementioned embodiments and will not be described in detail.

[0107] In the embodiment of the present application, after receiving the test request message, the first device adds the test task corresponding to the test request message to the task queue corresponding to the thread pool dedicated to the automated test system, and the idle thread in the thread pool obtains the test task from the task queue and performs subsequent operations on the task request message corresponding to the test task. Thus, by adopting a dedicated thread pool, the task queue of the thread pool supports both serial and parallel modes, thereby improving the flexibility and efficiency of embedded operating system testing.

[0108] In some embodiments, upon detecting that the server of the automated testing system is started, the first device may create a test service thread, receive a test request message sent by the second device through the test service thread, and / or send a test response message to the second device through the test service thread.

[0109] In this embodiment, after the server of the automated testing system is started, the test service thread is a resident thread during the running time of the server, and is specifically responsible for receiving test request messages and / or sending test response messages. Thus, by sending and receiving messages through a dedicated thread, the communication efficiency between the first device and the second device is improved, and the testing efficiency of the embedded operating system is improved.

[0110] Optionally, after the first device creates the test service thread, it switches the state of the test service thread to a blocked waiting state by selecting I / O multiplexing to wait for a test request message, thereby monitoring the test request message and receiving the test request message in a timely manner.

[0111] See also Figure 4 In another exemplary embodiment, a method for testing an embedded operating system is provided, the method comprising the following steps:

[0112] S401, the second device obtains a test case.

[0113] The test case may include the function to be tested of the embedded operating system, test parameters related to the function to be tested, and expected test results.

[0114] In this embodiment, the user can request access to the client of the automated testing system on the second device through the user terminal; the second device can send the client's page to the user terminal in response to the request of the user terminal; the user terminal displays the client's page, obtains the test case entered by the user on the client's page, and sends the test case to the second device.

[0115] S402: The second device generates a test request message according to the test case.

[0116] In this embodiment, the second device can determine the function module to be tested in the embedded operating system and the sub-function to be tested in the function module according to the function to be tested; then, the test module corresponding to the function module to be tested can be determined in the test module included in the automated test system, and the test item corresponding to the sub-function to be tested can be determined in the test item included in the test module; then, the main command code indicating the test module and the sub-command code corresponding to the test item can be determined. A test request message is generated according to the main command code, the sub-command code and the test parameters.

[0117] The test request message can refer to the above embodiment and will not be described in detail. The test request message can be generated according to the main command code, sub-command code and test parameters by writing the main command code, sub-command code and test parameters into the fields included in the test request message.

[0118] In one example, the second device can obtain a main command code mapping relationship, in which the main command code corresponding to the test module is determined; and can obtain a sub-command code mapping relationship of the test module, in which the sub-command code mapping relationship is determined to correspond to the test item.

[0119] S403: The second device sends a test request message to the first device.

[0120] S404, the first device parses the test request message to obtain a parsing result, where the parsing result includes a main command code, a sub-command code and a test parameter.

[0121] S405: The first device tests the sub-function according to the analysis result to obtain a test result.

[0122] S406: The first device generates a test response message according to the test result.

[0123] S407: The first device sends a test response message to the second device.

[0124] The implementation principles and technical effects of S403 to S407 may refer to the aforementioned embodiments and will not be described in detail.

[0125] In one example, before the second device sends a test request message to the first device, the second device can connect to and log in to the server of the automated testing system on the first device through the Internet Protocol Address (IP address) of the first device and the port number of the first device.

[0126] In one example, after sending the test request message, the second device blocks and waits for the test response message to monitor the test response message and receive the test response message in time.

[0127] S408: The second device outputs the test result according to the test response message.

[0128] In this embodiment, the second device parses the test response message to obtain the test result, and can output the test result to the user terminal. After receiving the test result, the user terminal visualizes the test result, thereby intuitively showing the test result of the embedded operating system to the user.

[0129] In one example, the test result includes whether the sub-function is tested successfully, the test error type of the sub-function and the result description statement of the sub-function; the test response message includes the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag and the result description statement, the first flag indicates whether the sub-function is tested successfully, and the second flag indicates the test error type of the sub-function. S408 may include: the second device parses the test response message to obtain a parsing result, the parsing result includes the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag and the result description statement; determines the sub-function according to the main command code and the sub-command code in the parsing result; determines the test result according to the flag value of the first flag, the flag value of the second flag and the result description statement in the parsing result and determines that the test result is obtained by testing the sub-function.

[0130] Among them, the process of determining the sub-function according to the main command code and the sub-command code can be determined based on the correspondence between the main command code and the test module, the correspondence between the test module and the functional module, the correspondence between the sub-command code and the test item, and the correspondence between the test item and the sub-function, which will not be described one by one here.

[0131] Among them, the test result is determined according to the flag value of the first flag, the flag value of the second flag and the result description statement in the parsing result, and whether the sub-function is tested successfully and the test error type of the sub-function are determined through the meaning of the flag value of the first flag and the meaning of the flag value of the second flag specified in the custom private protocol, and finally a test result including whether the function is tested successfully, the test error type of the sub-function and the result description statement of the sub-function is obtained.

[0132] In another example, after receiving the test response message, the second device parses the test response message to obtain a parsing result, and can judge the parsing result according to the assertion rule to obtain a test result, and the test result indicates whether the sub-function is tested successfully and the result description statement of the sub-function. Thus, in the automated testing of the embedded operating system, a personalized assertion rule can be designed for the message structure of the test response message to improve the accuracy and efficiency of determining the test result based on the test response message.

[0133] In this example, the parsing result of the test response message includes the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag, and the result description statement. It can be determined whether the flag value of the first flag and / or the flag value of the second flag in the parsing result satisfies the assertion rule to determine whether the sub-function is tested successfully, and obtain the result description statement of the sub-function from the parsing result; the test result is obtained based on whether the sub-function is tested successfully and the result description statement of the sub-function.

[0134] Optionally, the assertion rule is that the flag value of the first flag is the first numerical value and the flag value of the second flag is the second numerical value. If the flag value of the first flag and the flag value of the second flag both meet the assertion rule, it is determined that the sub-function test succeeds, otherwise it is determined that the sub-function test fails. Wherein, the flag value of the first flag is the first numerical value and the flag value of the second flag is the second numerical value, indicating that the sub-function test succeeds.

[0135] Optionally, the assertion rule is that the first flag value is a first numerical value or the flag value of the second flag is a second numerical value. If the flag value of the first flag or the flag value of the second flag meets the assertion rule, it is determined that the sub-function test succeeds, otherwise it is determined that the sub-function test fails. Wherein, the flag value of the first flag is the first numerical value or the flag value of the second flag is the second numerical value, indicating that the sub-function test succeeds.

[0136] In the embodiment of the present application, the second device can send a test request message to the first device according to the input test case; the first device performs automated testing of the embedded operating system based on the test request message, and after obtaining the test result, sends a test response message to the second device; the second device outputs the test result according to the test response message. Thus, through the message interaction between the first device and the second device, the end-to-end automated testing of the embedded operating system is realized, the test efficiency and test quality of the embedded operating system are improved, and the user experience of the test user is improved.

[0137] In one example, before deploying the server of the automated test system on the first device, a configuration file of the embedded operating system on the first device can be obtained, and the configuration file indicates the functional modules allowed to be tested in the embedded operating system and the sub-functions supported by the functional modules (the sub-functions allowed to be tested); the server of the automated test system can be deployed according to the configuration file, so that the deployed server can support the testing of the sub-functions of the functional modules allowed to be tested in the embedded operating system. Thus, the server of the automated test system can be compatible with different embedded operating systems, and the hardware platform supported by the server of the automated test system and the embedded operating system can be seamlessly switched.

[0138] See also Figure 5 , Figure 5 This is a system architecture diagram of the automated testing system provided in this embodiment. The automated testing system includes a user operation layer, an application logic layer, a use case scheduling layer, and a platform compatibility layer.

[0139] The user operation layer corresponds to the client of the automated testing system, which can be used for test case management, test result display, and visual management (such as visualizing test results).

[0140] The application logic layer, use case scheduling layer and platform compatibility layer correspond to the server side of the automated test system. The application logic layer can be used to parse the test request message from the user operation layer, generate the test response message according to the test result from the use case scheduling layer, etc.; the use case scheduling layer can be used to schedule the corresponding test items according to the parsing result of the test request message, obtain the test result, and return the test result to the application logic layer; the platform compatibility layer is used to be compatible with different embedded operating systems.

[0141] Exemplary Devices

[0142] Correspondingly, an embodiment of the present application also provides an embedded operating system testing device.

[0143] See also Figure 6 In an exemplary embodiment, an embedded operating system testing device 600 is provided, and the embedded operating system testing device includes: a receiving unit 601, a parsing unit 602, a testing unit 603, a message generating unit 604 and a sending unit 605, wherein:

[0144] The receiving unit 601 is used to receive a test request message sent by the second device. The test request message includes a main command code indicating a test module, a sub-command code indicating a test item in the test module, and test parameters related to the test item. The test module corresponds to a functional module of the embedded operating system, and the test item corresponds to a sub-function supported by the functional module.

[0145] The parsing unit 602 is used to parse the test request message to obtain a parsing result, which includes a main command code, a sub-command code and a test parameter.

[0146] The testing unit 603 is used to test the sub-function according to the analysis result to obtain the test result.

[0147] The message generating unit 604 is used to generate a test response message according to the test result.

[0148] The sending unit 605 is configured to send a test response message to the second device.

[0149] In some embodiments, the test unit 603 is specifically used to: obtain the main command code mapping relationship; in the main command code mapping relationship, determine the test module according to the main command code; obtain the sub-command code mapping relationship of the test module; in the sub-command code mapping relationship, determine the test item according to the sub-command code; test the sub-function according to the test item and the test parameter to obtain the test result.

[0150] In some embodiments, the test item is a test function of a sub-function, and the test function is obtained by encapsulating the API related to the sub-function and the test operation of the sub-function. The test unit 603 is specifically used to: input the test parameters into the test item, test the sub-function by executing the test item, and obtain the test result.

[0151] In some embodiments, the test request message also includes a test type; if the test type is an interface test, the test request message includes a set of module test information, and the module test information includes a main command code, a sub-command code, and test parameters; or, if the test type is a module combination service test, the test request message includes multiple sets of module test information, and each set of module test information in the multiple sets of module test information includes a main command code, a sub-command code, and test parameters, and different module test information in the multiple sets of module test information includes different main commands.

[0152] In some embodiments, the test result includes whether the sub-function is tested successfully, the test error type of the sub-function and the result description statement of the sub-function; the test response message includes a main command code, a sub-command code, a flag value of a first flag, a flag value of a second flag and a result description statement, the first flag indicates whether the sub-function is tested successfully, and the second flag indicates the test error type of the sub-function; the message generation unit 604 is specifically used to: determine the flag value of the first flag according to whether the sub-function is tested successfully; determine the flag value of the second flag according to the test error type of the sub-function; generate a test response message according to the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag and the result description statement.

[0153] In some embodiments, before parsing the test request message and obtaining the parsing result, the embedded operating system testing device also includes a task scheduling unit (not shown in the figure), which is used to: add a test task corresponding to the test request message in the task queue of the thread pool, and the thread pool is used for automated testing of the embedded operating system; obtain the test task in the task queue through the idle thread in the thread pool, and the task acquisition method of the thread pool includes parallel acquisition and / or serial acquisition.

[0154] The embedded operating system testing device provided in this embodiment belongs to the same application concept as the embedded operating system testing method provided in the above embodiment of this application, and can execute the embedded operating system testing method provided in any of the above embodiments of this application, and has the corresponding functional modules and beneficial effects of the execution method. For the technical details not described in detail in this embodiment, please refer to the specific processing content of the embedded operating system testing method provided in the above embodiment of this application, which will not be repeated here.

[0155] The functions implemented by the above receiving unit 601, parsing unit 602, testing unit 603, message generating unit 604 and sending unit 605 can be implemented by the same or different processors respectively, and the embodiments of the present application are not limited thereto.

[0156] It should be understood that the receiving unit 601, parsing unit 602, testing unit 603, message generating unit 604 and sending unit 605 in the above embedded operating system test device can be implemented in the form of a processor calling software. For example, the device includes a processor, the processor is connected to a memory, and instructions are stored in the memory. The processor calls the instructions stored in the memory to implement any of the above methods or realize the functions of each unit of the device, wherein the processor can be a general processor, such as a CPU or a microprocessor, etc., and the memory can be a memory in the device or a memory outside the device. Alternatively, the unit in the device can be implemented in the form of a hardware circuit, and the functions of some or all of the units can be realized by designing the hardware circuit. The hardware circuit can be understood as one or more processors; for example, in one implementation, the hardware circuit is an ASIC, and the functions of some or all of the above units are realized by designing the logical relationship of the components in the circuit; for another example, in another implementation, the hardware circuit can be implemented by PLD. Taking FPGA as an example, it can include a large number of logic gate circuits, and the connection relationship between the logic gate circuits is configured through the configuration file, so as to realize the functions of some or all of the above units. All units of the above device may be implemented entirely in the form of a processor calling software, or entirely in the form of a hardware circuit, or partially in the form of a processor calling software and the rest in the form of a hardware circuit.

[0157] In an embodiment of the present application, a processor is a circuit with the ability to process signals. In one implementation, the processor may be a circuit with the ability to read and run instructions, such as a CPU, a microprocessor, a GPU, or a DSP; in another implementation, the processor may implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, DPU, etc.

[0158] It can be seen that each unit in the above device can be one or more processors (or processing circuits) configured to implement the above method, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0159] In addition, all or part of the units in the above device can be integrated together, or can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a SOC. The SOC may include at least one processor for implementing any of the above methods or implementing the functions of each unit of the device. The type of the at least one processor may be different, for example, including a CPU and an FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.

[0160] Exemplary Electronic Devices

[0161] Another embodiment of the present application further provides an electronic device, in particular, the electronic device may be a vehicle-mounted device, and further, the electronic device is a vehicle-mounted voice device. Figure 7 As shown, the electronic device includes: a memory 700 and a processor 710; wherein the memory 700 is connected to the processor 710 and is used to store programs; the processor 710 is used to implement the embedded operating system testing method disclosed in any of the above embodiments by running the program stored in the memory 700.

[0162] Specifically, the electronic device may further include: a bus, a communication interface 720 , an input device 730 and an output device 740 .

[0163] The processor 710, the memory 700, the communication interface 720, the input device 730 and the output device 740 are connected to each other via a bus.

[0164] A bus may include a pathway that transfers information between components of a computer system.

[0165] The processor 710 may be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0166] The processor 710 may include a main processor, and may also include a baseband chip, a modem, and the like.

[0167] The memory 700 stores a program for executing the technical solution of the present application, and may also store an operating system and other key services. Specifically, the program may include a program code, and the program code includes a computer operation instruction. More specifically, the memory 700 may include a read-only memory (ROM), other types of static storage devices that can store static information and instructions, a random access memory (RAM), other types of dynamic storage devices that can store information and instructions, a disk storage, a flash, and the like.

[0168] The input device 730 may include a device for receiving data and information input by a user, such as a keyboard, a mouse, a camera, a scanner, a light pen, a voice input device, a touch screen, a pedometer, or a gravity sensor.

[0169] Output device 740 may include devices that allow information to be output to a user, such as a display screen, printer, speaker, etc.

[0170] The communication interface 720 may include any transceiver or the like to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0171] The processor 710 executes the program stored in the memory 700 and calls other devices, and can be used to implement each step of any embedded operating system testing method provided in the above embodiments of the present application.

[0172] An embodiment of the present application also proposes a chip, which includes a processor and a data interface. The processor reads and runs a program stored in a memory through the data interface to execute the embedded operating system testing method introduced in any of the above embodiments. The specific processing process and its beneficial effects can be found in the introduction to the embodiment of the above embedded operating system testing method.

[0173] Exemplary computer program products and storage media

[0174] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the embedded operating system testing method according to various embodiments of the present application described in any of the above embodiments of this specification.

[0175] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0176] In addition, an embodiment of the present application may also be a storage medium on which a computer program is stored, and the computer program is executed by a processor to execute the steps of the embedded operating system testing method according to various embodiments of the present application described in any of the above embodiments of this specification.

[0177] For the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0178] It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other. For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0179] The steps in the methods of each embodiment of the present application can be adjusted in order, combined and deleted according to actual needs, and the technical features recorded in each embodiment can be replaced or combined.

[0180] The modules and sub-modules in the devices and terminals of the various embodiments of the present application can be combined, divided and deleted according to actual needs.

[0181] In the several embodiments provided in the present application, it should be understood that the disclosed terminals, devices and methods can be implemented in other ways. For example, the terminal embodiments described above are only schematic, for example, the division of modules or submodules is only a logical function division, and there may be other division methods in actual implementation, for example, multiple submodules or modules can be combined or integrated into another module, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules, which can be electrical, mechanical or other forms.

[0182] The modules or submodules described as separate components may or may not be physically separated, and the components of the modules or submodules may or may not be physical modules or submodules, that is, they may be located in one place, or they may be distributed on multiple network modules or submodules. Some or all of the modules or submodules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0183] In addition, each functional module or submodule in each embodiment of the present application may be integrated into one processing module, or each module or submodule may exist physically separately, or two or more modules or submodules may be integrated into one module. The above-mentioned integrated modules or submodules may be implemented in the form of hardware or in the form of software functional modules or submodules.

[0184] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0185] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly by hardware, software units executed by a processor, or a combination of the two. The software units may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0186] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0187] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for testing an embedded operating system, characterized in that: Applied to a first device, the first device is deployed with an embedded operating system and a server of an automated testing system, and the second device is deployed with a client of the automated testing system, the embedded operating system testing method includes: receiving a test request message sent by the second device, wherein the test request message includes a main command code indicating a test module, a sub-command code indicating a test item in the test module, and a test parameter related to the test item, wherein the test module corresponds to a functional module of the embedded operating system, and the test item corresponds to a sub-function supported by the functional module; Parsing the test request message to obtain a parsing result, wherein the parsing result includes the main command code, the sub-command code and the test parameter; According to the analysis result, the sub-function is tested to obtain a test result; Generate a test response message according to the test result; Send the test response message to the second device.

2. The embedded operating system testing method according to claim 1, characterized in that: The step of testing the sub-function according to the analysis result to obtain the test result includes: Get the main command code mapping relationship; In the main command code mapping relationship, the test module is determined according to the main command code; Obtaining a sub-command code mapping relationship of the test module; In the sub-command code mapping relationship, determining the test item according to the sub-command code; The sub-function is tested according to the test item and the test parameter to obtain the test result.

3. The embedded operating system testing method according to claim 2, characterized in that: The test item is a test function of the sub-function, and the test function is obtained by encapsulating an application programming interface API related to the sub-function and a test operation of the sub-function. The sub-function is tested according to the test item and the test parameter to obtain the test result, including: The test parameter is input into the test item, and the sub-function is tested by executing the test item to obtain the test result.

4. The embedded operating system testing method according to any one of claims 1 to 3, characterized in that: The test request message also includes a test type; The test type is an interface test, the test request message includes a set of module test information, and the module test information includes the main command code, the sub-command code and the test parameters; Alternatively, the test type is a module combination service test, the test request message includes multiple groups of module test information, each group of module test information in the multiple groups of module test information respectively includes the main command code, the sub-command code and the test parameters, and different module test information in the multiple groups of module test information includes different main commands.

5. The embedded operating system testing method according to any one of claims 1 to 3, characterized in that: The test result includes whether the sub-function is tested successfully, the test error type of the sub-function and the result description statement of the sub-function; The test response message includes the main command code, the sub-command code, a flag value of a first flag, a flag value of a second flag, and the result description statement, wherein the first flag indicates whether the sub-function is tested successfully, and the second flag indicates a test error type of the sub-function; Generating a test response message according to the test result includes: Determining a flag value of the first flag according to whether the sub-function is tested successfully; Determining a flag value of the second flag according to a test error type of the sub-function; The test response message is generated according to the main command code, the sub-command code, the flag value of the first flag, the flag value of the second flag and the result description statement.

6. The embedded operating system testing method according to any one of claims 1 to 3, characterized in that: Before parsing the test request message to obtain the parsing result, the embedded operating system testing method further includes: Adding a test task corresponding to the test request message in a task queue of a thread pool, wherein the thread pool is used for automated testing of the embedded operating system; The test tasks in the task queue are acquired through the idle threads in the thread pool, and the task acquisition mode of the thread pool includes parallel acquisition and / or serial acquisition.

7. An embedded operating system testing device, characterized in that: Applied to a first device, the first device is deployed with an embedded operating system and a server of an automated testing system, the second device is deployed with a client of the automated testing system, and the embedded operating system testing device comprises: a receiving unit, configured to receive a test request message sent by the second device, wherein the test request message includes a main command code indicating a test module, a sub-command code indicating a test item in the test module, and a test parameter related to the test item, wherein the test module corresponds to a functional module of the embedded operating system, and the test item corresponds to a sub-function supported by the functional module; A parsing unit, configured to parse the test request message to obtain a parsing result, wherein the parsing result includes the main command code, the sub-command code and the test parameter; A testing unit, used to test the sub-function according to the analysis result to obtain a test result; A message generating unit, used to generate a test response message according to the test result; A sending unit, configured to send the test response message to the second device.

8. An electronic device, characterized in that: including memory and processor; The memory is connected to the processor and is used to store programs; The processor is used to implement the embedded operating system testing method according to any one of claims 1 to 6 by running the program in the memory.

9. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by the processor, the embedded operating system testing method according to any one of claims 1 to 6 is implemented.

10. A computer program product, characterized in that The invention comprises a computer program, which, when executed by a processor, implements the embedded operating system testing method according to any one of claims 1 to 6.

Images