Software testing method, device, equipment, system and medium

Abstract

The invention discloses a software testing method, device, equipment, system and medium, and the method comprises the steps that testing equipment receives a target testing request, the target testing request is sent by requesting equipment to run an automatic testing program to call a communication interface, and the automatic testing program is a program written by using a first programming language; the target test request is used for requesting to test a plurality of to-be-tested functions contained in the target software package, the plurality of to-be-tested functions are functions written by using a second programming language, and the first programming language is different from the second programming language; analyzing the target test request to obtain test data required by operation of the to-be-tested function, and calling the test data by using the to-be-tested function to obtain a test result of the to-be-tested function; and returning a test result of the to-be-tested function to the request equipment. According to the scheme, cross-programming language software automatic testing is achieved.

Description

Technical Field

[0001] The present application relates to the field of software processing, and in particular to a software testing method, device, equipment, system and medium. Background Art

[0002] Software testing automation refers to the conversion of human-driven testing behaviors into machine execution, which is of great significance to software development and maintenance. It can effectively improve testing efficiency and speed and reduce testing costs.

[0003] In some cases, the automated test program and the software being tested are written in different programming languages. For example, the automated test program is written in Python, while the software package used to execute in an embedded device is written in C or C++. How to implement test automation when cross-programming languages ​​is required becomes an urgent problem to be solved. Summary of the invention

[0004] The present application at least provides a software testing method, apparatus, device, system and medium.

[0005] The present application provides a software testing method, including: a testing device receives a target test request, the target test request is sent by requesting the device to run an automated test program to call a communication interface, the automated test program is a program written in a first programming language; the target test request is used to request testing of a number of to-be-tested functions included in a target software package, the number of to-be-tested functions are functions written in a second programming language, and the first programming language and the second programming language are different; the target test request is parsed to obtain test data required for running the to-be-tested function, the test data is called using the to-be-tested function to obtain a test result of the to-be-tested function; and the test result of the to-be-tested function is returned to the requesting device.

[0006] Therefore, the test device and the requesting device communicate through the communication interface. The test device receives the target test request sent by the requesting device, and can parse out the test data required for the operation of the function to be tested. Based on this, the function to be tested is called, the test results are obtained and returned to the requesting device, thereby realizing software automation testing across programming languages.

[0007] Among them, parsing the target test request to obtain the test data required for the operation of the function to be tested, using the function to be tested to call the test data, and obtaining the test result of the function to be tested includes: parsing the target test request to obtain the test parameter values ​​corresponding to the input parameters of the function to be tested; using the function to be tested to call the test parameter values ​​to obtain the execution result; based on the execution result, generating the test result of the function to be tested.

[0008] Therefore, by parsing the target test request, the input parameters can be obtained, so that the test of the function to be tested can be implemented and the test results can be obtained.

[0009] Among them, the target test request includes a uniform resource identifier and a request body; parsing the target test request to obtain test parameter values ​​corresponding to the input parameters of the function to be tested includes: parsing the uniform resource identifier to determine a number of functions to be tested; for each function to be tested, parsing the request body based on the input parameters corresponding to the function to be tested to obtain test parameter values ​​corresponding to the input parameters.

[0010] Therefore, the uniform resource identifier in the target test request is used to determine the function to be tested, and the request body in the target test request is used to determine the test parameter values ​​of the input parameters of the function to be tested. By parsing the target test request, the test object can be determined and the test parameter values ​​can be obtained to meet the conditions for calling the function to be tested, thereby realizing the test of the function to be tested.

[0011] Among them, the execution result includes the return value and the parameter values ​​corresponding to the output parameters of the function to be tested; based on the execution result, generating the test result of the function to be tested includes: using the return value and the parameter values ​​corresponding to the output parameters to generate the test result in json format.

[0012] Therefore, the test result is generated using the return value and parameter value in the execution result, so that the test result can reflect the performance of the function to be tested.

[0013] The test result of the function to be tested also includes the calling time; the method also includes: counting the calling time of the function to be tested to obtain the test result.

[0014] Therefore, the call time consumption of the function to be tested is counted to obtain the test result, so that the test result can accurately characterize the performance of the function to be tested from multiple aspects.

[0015] Among them, the first programming language is Python.

[0016] Therefore, cross-language automated software testing between Python programs and programs in other programming languages ​​can be achieved.

[0017] The second programming language is C or C++.

[0018] Therefore, cross-language automated software testing between C or C++ programs and programs in other programming languages ​​can be achieved.

[0019] Among them, the communication interface is an interface based on the Hypertext Transfer Protocol.

[0020] Therefore, the hypertext transfer protocol is used to realize communication between two devices, and cross-device automated software testing is realized. In addition, multiple programming languages ​​can call the communication interface of the hypertext transfer protocol, and cross-language automated software testing can be realized.

[0021] Among them, the target test request is parsed to obtain the test data required for the operation of the function to be tested, the test data is called by the function to be tested, and the step of obtaining the test result of the function to be tested is implemented by using the protocol processing function. Before receiving the target test request, the method also includes: parsing the header file of the target software package to obtain the parsing result, the parsing result includes a number of testable functions, the number of testable functions include at least part of all the functions in the target software package, and the number of functions to be tested are one or more of the number of testable functions; generating a protocol processing function based on the number of testable functions, and the protocol processing function is used to call each function separately to obtain the corresponding test result.

[0022] Therefore, by parsing the header file, a protocol processing function is generated for the testable functions obtained by the analysis, which can call each testable function separately to obtain the corresponding test results. The corresponding protocol processing function can be automatically generated for several testable functions, which greatly reduces the workload of R&D personnel and improves work efficiency.

[0023] Among them, the parsing results include the input parameters and output parameters corresponding to each testable function, and the parameter types corresponding to the input parameters and output parameters. The protocol processing function includes an input parameter assignment module and a test result generation module for each testable function; generating a protocol processing function based on a number of testable functions includes: for each testable function, according to the parameter type of the input parameter, generating an input parameter assignment module for assigning values ​​to the input parameter; according to the parameter type of the output parameter, generating a test result generation module for obtaining the test result based on the output parameter.

[0024] Therefore, for each testable function, an input parameter assignment module for assigning values ​​to input parameters and a test result generation module for obtaining test results based on output parameters are generated respectively, so as to be called in subsequent testing processes to meet the testing needs of the testable function.

[0025] Among them, the protocol processing function is executed in response to a test request, and the test request includes a request body; according to the parameter type of the input parameter, an input parameter assignment module for assigning a value to the input parameter is generated, including: in response to the parameter type of the input parameter being a basic type, a first program code is generated, the first program code is used to obtain the value corresponding to the input parameter from the request body, and the value corresponding to the input parameter is assigned to the input parameter; in response to the parameter type of the input parameter being a non-basic type, at least one level of sub-parameters contained in the input parameter is traversed, and for the sub-parameter whose parameter type is the basic type, a second program code is generated, the second program code is used to obtain the value corresponding to the sub-parameter from the request body, and the value corresponding to the sub-parameter is assigned to the sub-parameter.

[0026] Therefore, according to the parameter type of the input parameter, the corresponding code is generated, so that the input parameter assignment module can be called to correctly assign values ​​to the input parameters of the testable function to meet the testing requirements.

[0027] Among them, according to the parameter type of the output parameter, a test result generation module for obtaining a test result based on the output parameter includes: in response to the parameter type of the output parameter being a basic type, generating a third program code, the third program code is used to generate a test result based on the value of the output parameter; in response to the parameter type of the output parameter being a non-basic type, traversing at least one level of sub-parameters contained in the output parameter, and generating a fourth program code for the sub-parameter whose parameter type is the basic type, the fourth program code is used to generate a test result based on the value corresponding to the sub-parameter.

[0028] Therefore, according to the parameter type of the output parameter, the corresponding code is generated, so that the test result generation module can be called to generate the corresponding test result for the testable parameter to meet the test requirements.

[0029] Before receiving the target test request, the method further includes: parsing the header file of the target software package to obtain the parsing result, the parsing result includes a number of testable functions and a number of parameter types used by the testable functions; the number of testable functions include at least part of all the functions in the target software package, and the number of functions to be tested are one or more of the testable functions; generating a message body of the target format file based on the number of parameter types, generating a remote procedure call block of the target format file based on the number of testable functions; generating a test description document about the number of testable functions based on the target format file, the target format file including the message body and the remote procedure call block.

[0030] Therefore, the header file of the target software package is parsed, and the parsed functions and parameter types are used to generate corresponding test description documents. The format of the test description document is more suitable for testers to view, so that testers can understand the target software package.

[0031] The present application provides a software testing device, including a receiving module, a testing module and a returning module. The receiving module is used to receive a target test request, the target test request is sent by requesting a device to run an automated testing program to call a communication interface, the automated testing program is a program written in a first programming language; the target test request is used to request testing of a number of to-be-tested functions included in a target software package, the number of to-be-tested functions are functions written in a second programming language, the first programming language and the second programming language are different; the testing module is used to parse the target test request to obtain test data required for running the to-be-tested function, and use the to-be-tested function to call the test data to obtain a test result of the to-be-tested function; the returning module is used to return the test result of the to-be-tested function to the requesting device.

[0032] The present application provides an electronic device, including a memory and a processor, wherein the processor is used to execute program instructions stored in the memory to implement any of the above-mentioned software testing methods.

[0033] The present application provides a software testing system, including a requesting device and a testing device, wherein the requesting device is used to run an automated testing program to call a communication interface, send a target test request to the testing device, and request to test a number of to-be-tested functions contained in a target software package, wherein the automated testing program is a program written in a first programming language, and the number of to-be-tested functions are functions written in a second programming language, and the first programming language and the second programming language are different; the testing device is used to receive the target test request sent by the requesting device, parse the target test request to obtain test data required for running the to-be-tested function, use the to-be-tested function to call the test data, obtain a test result of the to-be-tested function, and return the test result of the to-be-tested function to the requesting device.

[0034] The present application provides a computer-readable storage medium on which program instructions are stored. When the program instructions are executed by a processor, any of the above-mentioned software testing methods is implemented.

[0035] In the above scheme, the test device and the requesting device communicate through a communication interface. The test device receives the target test request sent by the requesting device, and can parse out the test data required for the operation of the function to be tested. Based on this, the function to be tested is called, the test results are obtained and returned to the requesting device, thereby realizing software automation testing across programming languages.

[0036] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application.

[0038] Figure 1 It is a flowchart of an embodiment of the software testing method of the present application;

[0039] Figure 2 is a flowchart of another embodiment of step S120 of the present application;

[0040] Figure 3 This is a flowchart of another embodiment of step S120 of the present application;

[0041] Figure 4 It is a flowchart of another embodiment of the software testing method of the present application;

[0042] Figure 5 It is a flowchart of another embodiment of the software testing method of the present application;

[0043] Figure 6 It is a schematic diagram of an embodiment of a function configuration file in the present application;

[0044] Figure 7 is a schematic diagram of an embodiment of a type definition file in the present application;

[0045] Figure 8 is a schematic diagram of an embodiment of a code block automatically generated in this application;

[0046] Fig. 9 It is a schematic diagram of the framework of an embodiment of a software testing device in the present application;

[0047] Fig.10 It is a schematic diagram of the framework of an embodiment of an electronic device in the present application;

[0048] Fig.11 It is a schematic diagram of the framework of an embodiment of a software testing system in the present application;

[0049] Fig.12 It is a schematic diagram of a framework of an embodiment of a computer-readable storage medium in the present application. DETAILED DESCRIPTION

[0050] The scheme of the embodiment of the present application is described in detail below in conjunction with the drawings of the specification.

[0051] In the following description, for the purpose of explanation rather than limitation, specific details such as specific subsystem structures, interfaces, and technologies are provided to facilitate a thorough understanding of the present application.

[0052] The term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there may be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the objects associated before and after are in an "or" relationship. In addition, "many" in this article means two or more than two. In addition, the term "at least one" in this article means any combination of at least two of any one or more of a plurality of, for example, including at least one of A, B, and C, can mean including any one or more elements selected from the set consisting of A, B, and C.

[0053] See also Figure 1 , Figure 1 It is a flowchart of an embodiment of the software testing method of the present application. It should be noted that the process of software testing in the present application involves a test device and a request device, the test object is a function included in a target software package (Software Development Kit, SDK), the request device is used to run the automated test program used by the tester, and the test device is used to run the target software package.

[0054] The following is an example of steps performed by a test device. Specifically, the method may include:

[0055] Step S110: receiving a target test request.

[0056] The target test request is sent to request the device to run an automated test program to call the communication interface. The target test request is used to request to test several to-be-tested functions contained in the target software package.

[0057] The automated test program requested to be run by the device is a program written in a first programming language, while the function in the target software package is written in a second programming language, and the first programming language and the second programming language are different.

[0058] Step S120: Parse the target test request to obtain the test data required for the function to be tested to run, use the function to be tested to call the test data, and obtain the test result of the function to be tested.

[0059] The target test request includes the test data required for the function to be tested to run, and the test device can parse the target test request. After obtaining the test data, the test device can use the function to be tested to call the test data and obtain the test result of the function to be tested.

[0060] It can be understood that the target test request can be used to request testing of one or more functions to be tested.

[0061] If the target test request is used to request testing of multiple functions to be tested, the multiple functions to be tested are independent of each other. The target test request can parse the test data required by each function to be tested, and use each function to be tested to call the corresponding test data to obtain the test results of each function to be tested. The test results of all functions to be tested are returned to the requesting device.

[0062] Step S130: Return the test result of the function to be tested to the requesting device.

[0063] It is understandable that after obtaining the test result of the function to be tested, the testing device can return the obtained test result to the requesting device, thereby completing the automated test of the function to be tested in the target software package.

[0064] It is understandable that before the test device executes the steps of the above software testing method, the requesting device first runs the automated testing program to call the communication interface and send a target test request to the test device, with the purpose of requesting to test the function to be tested in the target software package. And the requesting device can obtain the test result of the function to be tested returned by the test device, thereby realizing automated testing of the target software package.

[0065] In the above scheme, the test device and the requesting device communicate through the communication interface. The test device receives the target test request sent by the requesting device, and can parse out the test data required for the running of the function to be tested. Based on this, the function to be tested is run, and the test results are obtained and returned to the requesting device, thereby realizing automated testing of the target software package using the automated test program run by the requesting device, overcoming the problem of cross-programming languages.

[0066] The automated test program and the test object use different programming languages. In some cases, the test equipment used to run the test object is not convenient for running the automated test program. Therefore, a requesting device is used to run the automated test program, while the test equipment runs the test object. The two devices communicate using a communication interface to achieve cross-device software testing.

[0067] The automated testing program can call the communication interface to send a test request. The test request sent by the requesting device can be received and parsed by the testing device to obtain the test data required for the test object to run. The testing device can then run the test object, complete the test, obtain the results and return them to the requesting device, thus realizing automated software testing across programming languages.

[0068] Furthermore, the programming language commonly used by testers is different from the programming language used by the test object. The above method can realize automated software testing across programming languages, reduce the learning and maintenance costs of testers, and improve testing efficiency.

[0069] See also Figure 2 , Figure 2 1 is a flow chart of another embodiment of step S120 of the present application. Specifically, this step may include:

[0070] Step S221: Parse the target test request to obtain test parameter values ​​corresponding to the input parameters of the function to be tested.

[0071] The test data required for the function to be tested to run includes the test parameter values ​​corresponding to the input parameters of the function to be tested, which are the actual parameters corresponding to the input parameters. The target test request includes but is not limited to a uniform resource identifier (URL) and a request body.

[0072] In some embodiments, the requesting device calls a communication interface to send a target test request, wherein the interface called by the requesting device is an interface based on Hypertext Transfer Protocol (HTTP). The target test request is an HTTP request.

[0073] In some embodiments, parsing the target test request to obtain test parameter values ​​corresponding to the input parameters of the function to be tested may include: parsing a uniform resource identifier to determine several functions to be tested, and for each function to be tested, parsing the request body based on the input parameters corresponding to the function to be tested to obtain test parameter values ​​corresponding to the input parameters.

[0074] It should be noted that the parsing of the target test request may include two parts. First, all functions to be tested need to be parsed, that is, all functions to be tested, and the number of functions to be tested may be one or more. Then, the test parameter value is parsed for each function to be tested. The test device stores the header file of the target software package, and the header file defines the input parameters of each function in the target software package. On this basis, the test parameter value corresponding to the input parameter of the function to be tested can be parsed.

[0075] Step S222: Using the function to be tested to call the test parameter value, obtain the execution result.

[0076] During the running of the function to be tested, the test parameter value is called as the actual parameter corresponding to the input parameter. The execution result is the result obtained after the execution of the function to be tested is completed. In some implementation scenarios, the execution result may include a return value, and in some implementation scenarios, the execution result may include a return value and a parameter value corresponding to the output parameter.

[0077] Step S223: Generate a test result of the function to be tested based on the execution result.

[0078] The test result is returned to the requesting device.

[0079] In some embodiments, the test result is in a preset format, and generating the test result may be converting the execution result into the preset format.

[0080] In some embodiments, the execution result includes a return value and parameter values ​​corresponding to output parameters of the function to be tested, and the return value and the parameter values ​​corresponding to the output parameters are used to generate a test result for returning to the requesting device.

[0081] In some embodiments, the execution result includes a return value and parameter values ​​corresponding to an output parameter of the function to be tested, and the return value and the parameter values ​​corresponding to the output parameter are used to generate a test result in a preset format, wherein the preset format is a json format.

[0082] In some embodiments, the test result may be generated together with the execution result and other data related to the execution of the function to be tested.

[0083] In some embodiments, step S120 is implemented by a protocol processing function, and the protocol processing function calls the function to be tested during its operation, wherein the test parameter value is used as the data for calling the function to be tested, thereby obtaining a test result.

[0084] In one implementation scenario, during the process of calling the function to be tested, the calling time of the function to be tested can also be counted. The calling time and the execution result can be used to generate the corresponding test result. Specifically, the time information can be obtained before and after the call, and the time information before and after the call can be compared to determine the calling time of the function to be tested.

[0085] In a specific application scenario, the function A to be tested is called to obtain the return value and the parameter values ​​corresponding to the output parameters, and the calling time of the function A to be tested is counted to obtain the calling time. The return value, the parameter values ​​corresponding to the output parameters, and the calling time are organized into json format data as the test result of the function A to be tested.

[0086] See also Figure 3 , Figure 3 It is a flowchart of another embodiment of step S120 of the present application.

[0087] In this embodiment, step S120 is implemented by a protocol processing function. Specifically, the protocol processing function is used to determine the functions to be tested based on the uniform resource identifier, including the to-be-tested function A and the to-be-tested function B.

[0088] The following uses the function A to be tested as an example. After determining the function to be tested, the protocol processing function parses the request body according to the input parameters required by the function A to be tested to obtain the test parameter values ​​required by the function A to be tested. The time before calling the function A to be tested is obtained, the function A to be tested is called, and the time after calling the function A to be tested is obtained. The latter time is subtracted from the former time to obtain the interface time. Finally, the execution result of the function A to be tested and the interface time are organized into json data as the test result of the function A to be tested. The same is true for the function B to be tested.

[0089] In some embodiments, before the protocol processing function is executed, the test device will first parse the received target test request to obtain the uniform resource identifier and request body contained therein.

[0090] In some embodiments, the test device pre-builds an environment for communication interface processing, specifically, pre-builds an environment for HTTP API (Application Programming Interface) processing.

[0091] See also Figure 4 , Figure 4 It is a flowchart of another embodiment of the software testing method of the present application.

[0092] In this embodiment, the test device runs the main function to implement the software testing method. Specifically, after the HTTP service is initialized and the HTTP service is started, it is determined whether the HTTP message sent by the requesting device, that is, the target test request, is received. If the target test request is received, the target test request is parsed to obtain a uniform resource identifier and a request body. Then the protocol processing function is called, and the test result obtained by the protocol processing function is returned to the requesting device, and then the HTTP message is waited. If it is determined that the HTTP message sent by the requesting device is not received, the HTTP message is waited.

[0093] In some embodiments, the automated testing program is written in Python, and the functions in the target software package are written in C or C++.

[0094] In a specific application scenario, the automated test program is written in Python. The embedded field focuses on performance and usually uses C or C++. When unit testing the software package interface in an embedded device, there is a cross-language problem. It is not convenient for embedded devices to run Python programs directly. Therefore, the requesting device runs the automated test program, and the embedded device runs the target software package, using a communication interface to interact in the middle. The embedded device parses the request sent by the requesting device and obtains the test data required for the function to be tested, so that the function to be tested can be tested. This completes the cross-programming language test.

[0095] Among them, the communication interface can be HTTP API.

[0096] In a specific application scenario, the requesting device may be a PC (Personal Computer) or a server.

[0097] In a specific application scenario, the C program written by the software developer runs on the device side, and the Python program written by the software tester runs on the PC or server side. The HTTP API is used for interaction in the middle. The device side needs to parse the protocol content and complete the corresponding software package interface call, and finally return the call result to the PC or server side.

[0098] In a specific application scenario, the protocol processing function is mainly responsible for determining which function name of the target software package is included in the uniform resource identifier, parsing the request body according to the input parameters required by the corresponding function to obtain the function input parameters, calling the function to obtain the function's return value and output parameter information, counting the function's previous and subsequent call times to obtain the interface time consumption, and then organizing these into json format results, returning them to the main function, and finally returning them to the protocol request end.

[0099] See also Figure 5 , Figure 5 1 is a flow chart of another embodiment of the software testing method of the present application. Specifically, in the software testing method provided by the present application, a protocol processing function is used. Before receiving the target test request, the software testing method provided by the present application may also include a code automatic generation step of the protocol processing function. Specifically, the following steps may be included:

[0100] Step S510: Parse the header file of the target software package to obtain a parsing result.

[0101] The parsing result includes a number of testable functions, which include at least part of all functions of the target software package. The number of to-be-tested functions as the test object are one or more of the number of testable functions.

[0102] In an implementation scenario, the header file can be parsed using ANTLR technology to obtain a parsing result. The parsing result includes a function configuration file (function.json), and the function configuration file includes a function declaration block of each testable function, wherein the function declaration block defines the input parameters and output parameters of each testable function, and the parameter types of the input parameters and the output parameters.

[0103] In some embodiments, the parsing result also includes a type definition file (types.json), and the type definition file includes a declaration of a parameter type of a non-basic type.

[0104] Step S520: Generate a protocol processing function based on a number of testable functions.

[0105] The protocol processing function is used to call each testable function in the target software package to obtain corresponding test results. It should be noted that the program automatically generates the code of the protocol processing function, so that the protocol processing function can be used to realize automated testing in the subsequent actual testing process.

[0106] When the interface parameters of the target software package are complex, the workload of writing protocol processing functions is very large. And if the testable functions and parameters change, the protocol processing functions also need to be adapted, and the maintenance workload is also very large. Using the program to automatically generate corresponding protocol processing functions for testable functions and apply them in the testing process can effectively reduce the workload of developers, greatly reduce the additional maintenance costs of software developers, and make development more efficient.

[0107] Furthermore, the protocol processing function is used to execute in response to a test request sent by a requesting device. The protocol processing function can call each to-be-tested function in response to the test request to obtain a corresponding test result.

[0108] In some embodiments, the parsing result also includes input parameters and output parameters corresponding to each testable function, and the protocol processing function includes but is not limited to an input parameter assignment module and a test result generation module for each testable function. Among them, the input parameter assignment module is used to assign values ​​to the input parameters of the testable function, and the test result generation module is used to generate a test result corresponding to the testable function based on the output parameters of the testable function. The process of generating the protocol processing function includes generating an input parameter assignment module and a test result generation module for each testable function respectively.

[0109] In some embodiments, the protocol processing function includes other modules in addition to the parameter assignment module and the test result generation module, such as a function definition module, a time acquisition module, etc. The generation of the protocol processing function also includes the generation of other modules. In this embodiment, the specific generation steps of other modules are simplified. For example, some modules can be generated by each testable function, and some modules can be obtained by obtaining preset codes.

[0110] In some embodiments, the parsing result includes input parameters corresponding to each testable function and parameter types corresponding to the input parameters. For each testable function, an input parameter assignment module is related to its input parameters, and the input parameter assignment module is generated based on the parameter types of its input parameters.

[0111] In some embodiments, the parsing results include output parameters corresponding to each testable function and parameter types corresponding to the output parameters. For each testable function, a test result generation module is related to its output parameters, and a test result generation module is generated based on the parameter types of its output parameters.

[0112] In one implementation scenario, the test request sent by the requesting device includes a request body. According to the parameter type of the input parameter, generating an input parameter assignment module for assigning a value to the input parameter includes: in response to the parameter type of the input parameter being a basic type, generating a first program code, the first program code is used to obtain a value corresponding to the input parameter from the request body, and assign the value corresponding to the input parameter to the input parameter; in response to the parameter type of the input parameter being a non-basic type, traversing at least one level of sub-parameters contained in the input parameter, and generating a second program code for a sub-parameter whose parameter type is a basic type, the second program code is used to obtain a value corresponding to the sub-parameter from the request body, and assign the value corresponding to the sub-parameter to the sub-parameter.

[0113] In one implementation scenario, according to the parameter type of the output parameter, a test result generation module for obtaining a test result based on the output parameter includes: in response to the parameter type of the output parameter being a base type, generating a third program code, the third program code being used to generate a test result based on the value of the output parameter; in response to the parameter type of the output parameter being a non-base type, traversing at least one level of sub-parameters contained in the output parameter, and generating a fourth program code for the sub-parameters whose parameter type is the base type, the fourth program code being used to generate a test result based on the value corresponding to the sub-parameter.

[0114] Among them, basic types and non-basic types are pre-defined. For example, string, floating point, and integer are used as basic types, and parameter types other than basic types are non-basic types. Non-basic type parameters contain at least one level of sub-parameters. For example, non-basic type parameter A is composed of several basic type sub-parameters a and several non-basic type sub-parameters B, wherein non-basic type sub-parameter B is composed of several basic type sub-parameters c, then parameter A has two levels of sub-parameters.

[0115] It should be noted that the function configuration file contains the function declaration block of each testable function. Each function declaration block of the testable function is processed in turn to obtain a complete protocol processing function, which can implement the call of each testable function to obtain the corresponding test result.

[0116] In some embodiments, the protocol processing function also includes a function execution module, which generates a function execution program code, and the function execution program code is used to call the corresponding testable function based on the assigned input parameters to obtain the execution result of the testable function. In some embodiments, the execution result of the testable function includes a return value, and in some embodiments, the execution result of the testable function includes the return value and the value corresponding to the output parameter.

[0117] In a specific application scenario, a function declaration block of a testable function is obtained from a function configuration file, and the input parameters and output parameters of the testable function and the corresponding parameter types are determined based on the function declaration block. The input parameter is used as the current parameter, and it is determined whether the parameter type of the current parameter is a basic type or a non-basic type. In response to the parameter type of the current parameter being the basic type, a program code is generated to assign a value to the current parameter using the corresponding value in the request body. In response to the parameter type of the current parameter being the non-basic type, a declaration of the current parameter type is obtained from a type definition file, a sub-parameter of the current parameter is determined, the sub-parameter of the current parameter is used again as the current parameter, and the steps of determining whether the parameter type of the current parameter is the basic type or the non-basic type and subsequent steps are re-executed.

[0118] Generate program code for assigning values ​​to input parameters or parameters of basic types in input parameters and their subparameters.

[0119] The output parameter is used as the current parameter, and the parameter type of the current parameter is determined to be a basic type or a non-basic type. In response to the parameter type of the current parameter being the basic type, a program code is generated to generate a test result based on a value corresponding to the current parameter. In response to the parameter type of the current parameter being the non-basic type, a declaration of the current parameter type is obtained from a type definition file, a sub-parameter of the current parameter is determined, the sub-parameter of the current parameter is used again as the current parameter, and the steps of determining whether the parameter type of the current parameter is the basic type or the non-basic type and subsequent steps are re-executed.

[0120] Generate program code for generating test results for output parameters or basic type parameters in output parameters and their subparameters.

[0121] Once the above processing is completed for each testable function, the generation of the input parameter assignment module and the test result generation module is completed.

[0122] In a specific application scenario, the automatic generation process is the process of traversing the function configuration file (function.json). Specifically, it includes: parsing the header file of the target software package to obtain the function configuration file (function.json) and the type definition file (types.json). Take out the elements of the function configuration file (function.json), that is, the function declaration block, obtain the input parameters required by the testable function, determine whether the input parameter type is a basic type, if it is a basic type, generate program code for assigning values ​​to the elements in the request body, if the input parameter type is not a basic type, find its declaration from the type definition file (types.json), traverse its subtypes in depth first, and if the basic type is traversed, generate program code for assigning values ​​to the elements in the request body. After the traversal is completed, the assignment of the input parameters is completed.

[0123] Generates program code that implements testable functions.

[0124] Determine whether the parameter type is a basic type. If it is a basic type, generate program code that assigns the obtained output parameter to the json variable. If the output parameter type is not a basic type, find its declaration from the type definition file (types.json), traverse its subtypes depth-first, and if the traversal reaches the basic type, generate program code that assigns the obtained output parameter to the json variable.

[0125] Determine whether there are any elements in the function configuration file (funct i on.json). If so, return to execute the extraction of elements and subsequent steps.

[0126] In a specific application scenario, the step of automatically generating code may be performed in combination with a preset template, for example, filling the template with parameter names included in the testable function to form a complete code.

[0127] In some embodiments, the automatic generation of the protocol processing function may be performed by a test device or other device.

[0128] In a specific application scenario, after the code generation of the protocol processing function is completed, an executable file is formed using the code of the protocol processing function and loaded into a test device, so that the subsequent test device can call the protocol processing function.

[0129] See also Figure 6 , Figure 6 It is a schematic diagram of an embodiment of a function configuration file in the present application.

[0130] Figure 6 An example of a function configuration file (function.json) obtained by parsing the header file is given in.

[0131] See also Figure 7 , Figure 7 It is a schematic diagram of an embodiment of a type definition file in this application.

[0132] Figure 7 An example of a type definition file (types.json) obtained by parsing a header file is given in .

[0133] See also Figure 8 , Figure 8 It is a schematic diagram of an embodiment of a code block automatically generated in this application.

[0134] The code blocks provided in this embodiment are only examples. Taking the code blocks corresponding to a testable function in the target software package as an example, the protocol processing function includes the code blocks corresponding to each testable function, which can realize calling each testable function separately to obtain the corresponding test results.

[0135] In some embodiments, before receiving the target test request, the method may further include: parsing the header file of the target software package to obtain a parsing result. The parsing result includes a number of testable functions and a number of parameter types used by the testable functions, wherein the testable functions include part or all of all functions of the target software package, and the number of functions to be tested are one or more of the testable functions. A message body of a target format file is generated based on the number of parameter types, and a remote procedure call block of the target format file is generated based on the number of testable functions. The target format file includes a message body and a remote procedure call block, and a test description document about the testable functions is generated based on the target format file.

[0136] In one implementation scenario, the target format file is a proto file.

[0137] In a specific application scenario, the parsing result may include a function configuration file (functi on.json) and a type definition file (types.json). The function configuration file defines several testable functions, and the type definition file defines several parameter types used by several testable functions. Take out the elements in the type definition file (types.json), and organize the types into the message body (message) in the proto file until the type definition file (types.json) does not contain the elements. Take out the elements in the function configuration file (functi on.json), and organize the functions into the message body remote procedure call (rpc, Remote Procedure Call Protocol) block in the proto file until the function configuration file (functi on.json) does not contain the elements. Generate a test description document based on the proto file.

[0138] The test description document is a document in a specific format generated using the target format file.

[0139] In a specific application scenario, the protoc tool is used to generate protobuf into a swagger test description document.

[0140] It is understandable that the test description document is automatically generated by the program, and the test description document is provided to testers for advance review. The format of the test description document is more convenient for testers to read and understand the test object. Testers do not need to conduct additional learning for test objects in other programming languages, so that testers can easily understand the testable functions and the corresponding protocol processing functions, so as to determine the appropriate test parameter values ​​and enhance the collaboration between R&D personnel and testers.

[0141] It should be noted that the automatic generation of the test description document can be performed by the test equipment or other equipment.

[0142] See also Fig. 9 , Fig. 9 It is a schematic diagram of the framework of an embodiment of a software testing device in the present application.

[0143] In this embodiment, the software testing device 90 includes a receiving module 91, a testing module 92 and a returning module 93. The receiving module 91 is used to receive a target test request, which is sent by requesting a device to run an automated testing program to call a communication interface, and the automated testing program is a program written in a first programming language; the target test request is used to request testing of a number of functions to be tested contained in a target software package, and the number of functions to be tested are functions written in a second programming language, and the first programming language and the second programming language are different; the testing module 92 is used to parse the target test request to obtain the test data required for the operation of the function to be tested, and use the function to be tested to call the test data to obtain the test result of the function to be tested; the returning module 93 is used to return the test result of the function to be tested to the requesting device.

[0144] See also Fig.10 , Fig.10 It is a schematic diagram of the framework of an embodiment of an electronic device in the present application.

[0145] In this embodiment, the electronic device 100 includes a memory 101 and a processor 102, and the processor 102 is used to execute program instructions stored in the memory 101 to implement any of the above software testing methods. In a specific implementation scenario, the electronic device 100 may include but is not limited to: computer equipment, power equipment, microcomputers, desktop computers, servers, and in addition, the electronic device 100 may also include mobile devices such as laptops and tablet computers, which are not limited here.

[0146] Specifically, the processor 102 is used to control itself and the memory 101 to implement any of the above-mentioned software testing methods. The processor 102 can also be called a CPU (Central Processing Unit). The processor 102 may be an integrated circuit chip with signal processing capabilities. The processor 102 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. In addition, the processor 102 can be implemented by an integrated circuit chip.

[0147] See also Fig.11 , Fig.11 It is a schematic diagram of the framework of an embodiment of a software testing system in the present application.

[0148] In this embodiment, the software testing system 110 includes a requesting device 111 and a testing device 112 .

[0149] The requesting device 111 is used to run an automated testing program to call a communication interface, and to send a target testing request to the testing device 112, requesting to test a number of functions to be tested contained in a target software package, wherein the automated testing program is a program written in a first programming language, and the number of functions to be tested are functions written in a second programming language, and the first programming language and the second programming language are different; the testing device 112 is used to receive the target testing request sent by the requesting device 111, parse the target testing request to obtain the test data required for the function to be tested to run, use the function to be tested to call the test data, obtain the test result of the function to be tested, and return the test result of the function to be tested to the requesting device 111.

[0150] The specific execution steps of the test device 112 may refer to the steps in the aforementioned software testing method embodiment, which will not be described in detail here.

[0151] See also Fig.12 , Fig.12 It is a schematic diagram of a framework of an embodiment of a computer-readable storage medium in the present application.

[0152] The computer-readable storage medium 120 provided in this embodiment stores program instructions 121 that can be executed by a processor. When the program instructions 121 are executed by the processor, they are used to implement any of the above-mentioned software testing methods.

[0153] The above description of various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced to each other, and for the sake of brevity, they will not be repeated herein.

[0154] In the several embodiments provided in the present application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation described above is only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation, such as units or components can be combined or integrated into another subsystem, 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 through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0155] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform all or part of the steps of each implementation method of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.

Claims

1. A software testing method, characterized in that: The method comprises: The test device receives a target test request, wherein the target test request is sent by requesting the device to run an automated test program to call a communication interface, wherein the automated test program is a program written in a first programming language; the target test request is used to request testing of a plurality of to-be-tested functions included in a target software package, wherein the plurality of to-be-tested functions are functions written in a second programming language, and the first programming language and the second programming language are different; Parsing the target test request to obtain test data required for the function to be tested to run, and using the function to be tested to call the test data to obtain a test result of the function to be tested; The test result of the function to be tested is returned to the requesting device.

2. The method according to claim 1, characterized in that: The step of parsing the target test request to obtain test data required for the function to be tested to run, and using the function to be tested to call the test data to obtain a test result of the function to be tested includes: Parsing the target test request to obtain test parameter values ​​corresponding to the input parameters of the function to be tested; Using the function to be tested to call the test parameter value, obtaining an execution result; Based on the execution result, a test result of the function to be tested is generated.

3. The method according to claim 2, characterized in that The target test request includes a uniform resource identifier and a request body; the parsing of the target test request to obtain a test parameter value corresponding to the input parameter of the function to be tested includes: Parsing the uniform resource identifier to determine the plurality of functions to be tested; For each of the functions to be tested, the request body is parsed based on the input parameters corresponding to the function to be tested to obtain the test parameter values ​​corresponding to the input parameters; and / or, The execution result includes a return value and a parameter value corresponding to an output parameter of the function to be tested; and generating a test result of the function to be tested based on the execution result includes: The test result in json format is generated using the return value and the parameter values ​​corresponding to the output parameters.

4. The method according to any one of claims 1 to 3, characterized in that The test result of the function to be tested also includes the calling time consumption; the method also includes: The calling time of the function to be tested is counted to obtain the test result.

5. The method according to any one of claims 1 to 4, characterized in that The step of parsing the target test request to obtain the test data required for the function to be tested to run, using the function to be tested to call the test data, and obtaining the test result of the function to be tested is implemented by using a protocol processing function. Before receiving the target test request, the method further includes: Parsing the header file of the target software package to obtain a parsing result, wherein the parsing result includes a plurality of testable functions, the plurality of testable functions include at least a portion of all functions in the target software package, and the plurality of functions to be tested are one or more of the plurality of testable functions; A protocol processing function is generated based on the plurality of testable functions, and the protocol processing function is used to respectively utilize each of the testable functions to obtain corresponding test results.

6. The method according to claim 5, characterized in that The parsing result includes the input parameters and output parameters corresponding to each of the testable functions, and the parameter types corresponding to the input parameters and output parameters; the protocol processing function includes an input parameter assignment module and a test result generation module for each of the testable functions; The generating of the protocol processing function based on the plurality of testable functions comprises: For each of the testable functions, generating an input parameter assignment module for assigning a value to the input parameter according to the parameter type of the input parameter; According to the parameter type of the output parameter, a test result generation module is generated for obtaining a test result based on the output parameter.

7. The method according to claim 6, characterized in that The protocol processing function is executed in response to a test request, wherein the test request includes a request body; and the generating, according to the parameter type of the input parameter, an input parameter assignment module for assigning a value to the input parameter includes: In response to the parameter type of the input parameter being a basic type, generating a first program code, the first program code being used to obtain a value corresponding to the input parameter from the request body, and assigning the value corresponding to the input parameter to the input parameter; In response to the parameter type of the input parameter being a non-basic type, traversing at least one level of sub-parameters contained in the input parameter, and generating a second program code for the sub-parameter whose parameter type is a basic type, wherein the second program code is used to obtain a value corresponding to the sub-parameter from the request body, and assign the value corresponding to the sub-parameter to the sub-parameter; and / or, The generating, according to the parameter type of the output parameter, a test result generating module for obtaining a test result based on the output parameter comprises: In response to the parameter type of the output parameter being a base type, generating a third program code, the third program code being used to generate a test result based on a value of the output parameter; In response to the parameter type of the output parameter being a non-basic type, traverse at least one level of sub-parameters contained in the output parameter, and generate a fourth program code for the sub-parameter whose parameter type is a basic type, wherein the fourth program code is used to generate a test result based on the value of the sub-parameter.

8. The method according to any one of claims 1 to 7, characterized in that Before receiving the target test request, the method further includes: Parsing the header file of the target software package to obtain parsing results, wherein the parsing results include a number of testable functions and a number of parameter types used by the testable functions, the testable functions include at least part of all functions in the target software package, and the number of functions to be tested are one or more of the testable functions; Generate a message body of a target format file based on the several parameter types, and generate a remote procedure call block of the target format file based on the several testable functions; A test description document about the plurality of testable functions is generated based on the target format file, wherein the target format file includes the message body and the remote procedure call block.

9. A software testing device, characterized in that: The device comprises: A receiving module, configured to receive a target test request, wherein the target test request is sent by requesting a device to run an automated test program to call a communication interface, wherein the automated test program is a program written in a first programming language; the target test request is used to request testing of a plurality of to-be-tested functions included in a target software package, wherein the plurality of to-be-tested functions are functions written in a second programming language, and the first programming language and the second programming language are different; A test module, used to parse the target test request to obtain the test data required for the function to be tested to run, and use the function to be tested to call the test data to obtain the test result of the function to be tested; The return module is used to return the test result of the function to be tested to the requesting device.

10. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory stores program instructions, and when the program instructions are executed by the processor, the method according to any one of claims 1 to 8 is implemented.

11. A software testing system, characterized in that: The system comprises: A requesting device, used to run an automated test program to call a communication interface, send a target test request to a test device, and request to test a plurality of to-be-tested functions contained in a target software package, wherein the automated test program is a program written in a first programming language, and the plurality of to-be-tested functions are functions written in a second programming language, and the first programming language and the second programming language are different; A test device is used to receive a target test request sent by the requesting device, parse the target test request to obtain the test data required for the function to be tested to run, use the function to be tested to call the test data, obtain the test result of the function to be tested, and return the test result of the function to be tested to the requesting device.

12. A computer-readable storage medium having program instructions stored thereon, characterized in that: When the program instructions are executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images