CN117271301A - Test method, test device, electronic equipment and medium - Google Patents

Abstract

The embodiment of the disclosure discloses a testing method, a testing device, electronic equipment and a medium. One embodiment of the method comprises the following steps: acquiring a domain-specific language file of test input data, wherein the domain-specific language file comprises elements for indicating parameters required by a method to be tested, interface simulation data on which the method to be tested depends and expected data of a test result; analyzing the field specific language file to generate an input data object, an interface simulation value object and an expected value object of the test input data; testing the method to be tested based on the input data object and the interface analog value object, and generating an output result of the method to be tested; and generating a test result of the method to be tested according to the matching of the output result and the expected value object. The embodiment realizes centralized management of the test data, can provide a simple, efficient and low-cost operation data driving test scheme, and further improves the unit test efficiency.

Description

Test method, test device, electronic equipment and medium

Technical Field

Embodiments of the present disclosure relate to the field of computer technology, and in particular, to a testing method, apparatus, electronic device, and medium.

Background

With the development of computer technology, unit testing is an important guarantee of code correctness in software system development, particularly in mature and complex business software systems. And the data driving unit test is a simple and efficient unit test method.

Existing data-driven cell testing often uses data sources provided by Junit, testNG to directly obtain data through encoding, or to read from Excel, databases. The former requires specialized developers to write test code, while the latter is difficult to express complex data and structures. Meanwhile, in a complex service system, the code of the unit test often needs to depend on external interface data, and the existing technical scheme can only simulate and pile the interface data in the test case code, so that the interface data to be simulated or piled can not be directly defined in the test data. Therefore, the problems of high implementation difficulty, high cost and the like exist in at least one aspect of test data writing, test code writing, interface-dependent simulation and the like.

Disclosure of Invention

The embodiment of the disclosure provides a testing method, a testing device, electronic equipment and a medium.

In a first aspect, embodiments of the present disclosure provide a test method comprising: acquiring a domain-specific language (DSL) file of test input data, wherein the domain-specific language file comprises elements for indicating parameters required by a method to be tested, interface simulation data on which the method to be tested depends and expected data of a test result; analyzing the field specific language file to generate an input data object, an interface simulation value object and an expected value object of the test input data; testing the method to be tested based on the input data object and the interface analog value object, and generating an output result of the method to be tested; and generating a test result of the method to be tested according to the matching of the output result and the expected value object.

In some embodiments, the above elements include at least one of the following forms: and (3) statically defining constants, presetting the running result of the code block, and presetting data values output by the function according to the context environment parameters.

In some embodiments, parsing the domain-specific language file to generate an input data object, an interface simulation value object, and an expected value object of the test input data includes: based on a preset analysis tool, analyzing the data defined in the field specific language file line by line, and analyzing the elements used for indicating the parameters required by the method to be tested, the interface simulation data on which the method to be tested depends and the expected data of the test result into the corresponding input data object, interface simulation value object and expected value object of the test input data respectively.

In some embodiments, the testing the method to be tested based on the input data object and the interface analog value object to generate an output result of the method to be tested includes: searching a method to be tested in a preset method set according to the field specific language file; creating an instance object of a class to which the method to be tested belongs through reflection; and in response to determining that the input data object has the input parameters required by the method to be tested, calling the method to be tested through reflection, and generating an output result of the method to be tested.

In some embodiments, the testing the method to be tested based on the input data object and the interface analog value object to generate an output result of the method to be tested includes: responding to a method to be tested to call a target interface component method, and determining whether an interface analog value object matched with the target interface component method exists in the interface analog value object; in response to determining that the interface exists, calling an interface method corresponding to the matched interface simulation value object to generate simulation interface data, wherein the interface proxy object belongs to a proxy class generated by means of JAVA dynamic proxy; and generating an output result of the method to be tested according to the analog interface data and the method to be tested.

In some embodiments, the data type in the interface analog value object is a function; and calling the interface proxy object corresponding to the matched interface simulation value object to generate simulation interface data, wherein the simulation interface data comprises: and running the function of the matched interface simulation value object, and determining the value generated by the function as simulation interface data.

In a second aspect, embodiments of the present disclosure provide a test apparatus comprising: the device comprises an acquisition unit, a test input unit and a test result acquisition unit, wherein the acquisition unit is configured to acquire a domain-specific language file of test input data, and the domain-specific language file comprises elements for indicating parameters required by a method to be tested, interface simulation data on which the method to be tested depends and test result expected data; the analysis unit is configured to analyze the field specific language file and generate an input data object, an interface simulation value object and an expected value object of the test input data; the testing unit is configured to test the method to be tested based on the input data object and the interface analog value object, and generate an output result of the method to be tested; and the generating unit is configured to generate a test result of the method to be tested according to the matching of the output result and the expected value object.

In some embodiments, the above elements include at least one of the following forms: and (3) statically defining constants, presetting the running result of the code block, and presetting data values output by the function according to the context environment parameters.

In some embodiments, the parsing unit is further configured to: based on a preset analysis tool, analyzing the data defined in the field specific language file line by line, and analyzing the elements used for indicating the parameters required by the method to be tested, the interface simulation data on which the method to be tested depends and the expected data of the test result into the corresponding input data object, interface simulation value object and expected value object of the test input data respectively.

In some embodiments, the test unit is further configured to: searching a method to be tested in a preset method set according to the field specific language file; creating an instance object of a class to which the method to be tested belongs through reflection; and in response to determining that the input data object has the input parameters required by the method to be tested, calling the method to be tested through reflection, and generating an output result of the method to be tested.

In some embodiments, the test unit is further configured to: responding to a method to be tested to call a target interface component method, and determining whether an interface analog value object matched with the target interface component method exists in the interface analog value object; in response to determining that the interface exists, calling an interface method corresponding to the matched interface simulation value object to generate simulation interface data, wherein the interface proxy object belongs to a proxy class generated by means of JAVA dynamic proxy; and generating an output result of the method to be tested according to the analog interface data and the method to be tested.

In some embodiments, the data type in the interface analog value object is a function; and the test unit is further configured to: and running the function of the matched interface simulation value object, and determining the value generated by the function as simulation interface data.

In a third aspect, embodiments of the present disclosure provide an electronic device comprising: one or more processors; a storage device having one or more programs stored thereon; the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method as described in any of the implementations of the first aspect.

In a fourth aspect, embodiments of the present disclosure provide a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a method as described in any of the implementations of the first aspect.

According to the testing method, the testing device, the electronic equipment and the testing medium, the acquired field specific language file of the testing input data is analyzed to generate the input data object, the interface simulation value object and the expected value object of the corresponding testing input data; and generating an output result of the method to be tested based on the input data object and the interface analog value object, and further generating a test result of the method to be tested through matching the output result with the expected value object. The method has the advantages that the contents such as parameters, interface simulation data, expected data and the like are written into the test data file instead of the code of the test case in the form of the field specific language file, so that the understanding and using difficulty is reduced, the development efficiency is improved, the dependent external interface data can be automatically identified and simulated during operation, and the code writing of interface simulation is avoided; therefore, centralized management of test data is realized, a simple, efficient and low-cost operation data driving test scheme can be provided, and further, the unit test efficiency is improved.

Drawings

Other features, objects and advantages of the present disclosure will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the following drawings:

FIG. 1 is an exemplary system architecture diagram in which an embodiment of the present disclosure may be applied;

FIG. 2a is a flow chart of one embodiment of a test method according to the present disclosure;

FIG. 2b is a schematic diagram of a test data structure according to one embodiment of the test method of the present disclosure;

FIG. 3 is a schematic diagram of one application scenario of a test method according to an embodiment of the present disclosure;

FIG. 4 is a flow chart of yet another embodiment of a test method according to the present disclosure;

FIG. 5 is a schematic diagram of the structure of one embodiment of a test device according to the present disclosure;

fig. 6 is a schematic structural diagram of an electronic device suitable for use in implementing embodiments of the present disclosure.

Detailed Description

The present disclosure is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings.

It should be noted that, without conflict, the embodiments of the present disclosure and features of the embodiments may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

Fig. 1 illustrates an exemplary architecture 100 in which the test methods or test apparatuses of the present disclosure may be applied.

As shown in fig. 1, a system architecture 100 may include terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The terminal devices 101, 102, 103 interact with the server 105 via the network 104 to receive or send messages or the like. Various communication client applications, such as a web browser application, a search class application, an instant messaging tool, a mailbox client, a unit test class application, etc., may be installed on the terminal devices 101, 102, 103.

The terminal devices 101, 102, 103 may be hardware or software. When the terminal devices 101, 102, 103 are hardware, they may be various electronic devices having a display screen and supporting man-machine interaction, including but not limited to smartphones, tablet computers, laptop and desktop computers, and the like. When the terminal devices 101, 102, 103 are software, they can be installed in the above-listed electronic devices. Which may be implemented as multiple software or software modules (e.g., software or software modules for providing distributed services) or as a single software or software module. The present invention is not particularly limited herein.

The server 105 may be a server providing various services, such as a background server providing support for unit test class applications on the terminal devices 101, 102, 103. The background server may perform corresponding processing on the obtained domain-specific language file of the test input data (for example, generate a test result of the method to be tested corresponding to the domain-specific language file), and may also feed back the generated processing result (such as the test result) to the terminal device.

The domain-specific language file of the test input data may be directly stored in the local area of the server 105, and the server 105 may directly extract and process the domain-specific language file of the test input data stored in the local area, and in this case, the terminal devices 101, 102, 103 and the network 104 may not be present.

The server may be hardware or software. When the server is hardware, the server may be implemented as a distributed server cluster formed by a plurality of servers, or may be implemented as a single server. When the server is software, it may be implemented as a plurality of software or software modules (e.g., software or software modules for providing distributed services), or as a single software or software module. The present invention is not particularly limited herein.

It should be noted that the testing method provided by the embodiments of the present disclosure is generally performed by the server 105, and accordingly, the testing device is generally disposed in the server 105. Alternatively, the test method provided in the embodiment of the present application may be performed by the terminal devices 101, 102, 103 under the condition that the computing capability is satisfied, and accordingly, the test apparatus may be provided in the terminal devices 101, 102, 103.

It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

With continued reference to fig. 2a, a flow 200 of one embodiment of a test method according to the present disclosure is shown. The test method comprises the following steps:

step 201, a domain specific language file of test input data is obtained.

In this embodiment, the execution subject of the test method (such as the server 105 shown in fig. 1) may acquire the domain-specific language file of the test input data through a wired connection manner or a wireless connection manner. The domain-specific language file may include elements for indicating parameters required by a method to be tested, interface simulation data on which the method to be tested depends, and test result expected data.

Specifically, the execution subject may acquire a domain-specific language file of the test input data stored locally in advance, or may acquire a domain-specific language file of the test input data from an electronic device (for example, a database server) connected to the execution subject in communication.

In this embodiment, the domain-specific language file of the test input data generally has a correspondence relationship with the method to be tested. As an example, the correspondence relationship between the file name of the domain-specific language file of the above-described test input data and the method name of the method to be tested may be saved in advance. As yet another example, a method name (e.g., methodA) of a method to be tested may be used as a part of a file name (e.g., full path class name) of a domain-specific language file of the above-described test input data.

In this embodiment, the above-described elements for indicating the parameters required for the method to be tested, the interface analog data on which the method to be tested depends, and the test result expected data may take various forms. As an example, referring to fig. 2b, the test input data described above may be a test data structure defined based on a Groovy DSL. The whole structure is an array, and the elements of each array can comprise three parts: an element for indicating parameters required for the method to be tested (e.g., set as a Given part), an element for indicating interface analog data on which the above-described method to be tested depends (e.g., set as a Mock part), and an element for indicating desired data of a test result (e.g., set as an aspect part).

In this embodiment, as an example, among the above-mentioned elements for indicating parameters required by the method to be tested, the input of the corresponding parameter a may be "method input parameter 1", the input of the parameter B may be "method input parameter 2", and the input of the parameter C may be the current object of the collection iteration, i.e. 0-4. That is, the results of the above parameters give 5 sets of input data, respectively:

[ method input parameter 1, method input parameter 2,0];

[ method input parameter 1, method input parameter 2,1];

[ method input parameter 1, method input parameter 2,2];

[ method input parameter 1, method input parameters 2,3];

[ method input parameter 1, method input parameters 2,4].

As an example, the "method input parameter 1" may be used to indicate the first input variable of the method to be tested, that is, the first parameter required by the method to be tested. The "method input parameter 2" may be used to indicate a second input variable of the method to be tested, i.e. a second parameter required for the method to be tested.

In this embodiment, as an example, of the elements for indicating interface analog data on which the method to be tested depends, "$mockservice" shown in the example may be used to indicate a reference to the interface component name, "$mockservice.

In the present embodiment, as an example, among the above-described elements for indicating the expected data of the test result, "$fact" shown in the sample may be used to indicate a reference to the return value of the above-described test method to be tested, and "$fact. Field 1> >" expected value 1' "may be used to indicate that the value of" field 1 "in the object among the expected values of the method to be tested is" expected value 1". Similarly, "$fact. Field 2> > 'expected value 2'" may be used to indicate that the value of "field 2" in the object is "expected value 2" in the expected values of the method to be tested.

It should be noted that, in practice, the above-mentioned domain-specific language file may be defined in a Groovy script, so as to be able to be finally parsed into a runtime data object.

In some alternative implementations of the present embodiment, the elements described above may include at least one of the following forms: and (3) statically defining constants, presetting the running result of the code block, and presetting data values output by the function according to the context environment parameters.

In these implementations, the above elements may include at least one of the following forms: a statically defined constant (e.g., a number "1" or a string constant "abc"), a running result of a code block (e.g., a result of running a predefined code block as a data value), a data value output by a preset function according to a context parameter (e.g., a data value dynamically calculated by a preset function object when the preset function object is running, according to a parameter input of the context, is invoked).

It should be noted that any element of the above element for indicating the parameters required by the method to be tested, the element for indicating the interface analog data on which the method to be tested depends, and the element for indicating the expected data of the test result may take any form of the above statically defined constants, the running result of the preset code block, and the data value output by the preset function according to the context environment parameters, which is not limited herein.

As an example, in fig. 2b, the above-mentioned elements for indicating parameters required for the method to be tested, elements for indicating interface simulation data on which the above-mentioned method to be tested depends, and elements for indicating expected data of test results take the form of data values output by the above-mentioned running results of the preset code blocks, statically defined constants, and preset functions according to the context environment parameters, respectively.

Based on the above-mentioned alternative implementation manner, the definition mode of the test data in the domain-specific language file of the test input data provided by the present solution has high flexibility, and can support multiple types including basic data types, code blocks and function objects (including closure functions).

Step 202, analyzing the domain-specific language file to generate an input data object, an interface simulation value object and an expected value object of the test input data.

In this embodiment, the execution body may parse the domain-specific language file in various manners to generate an input data object, an interface simulation value object, and an expected value object of the test input data.

In this embodiment, the execution body may parse the domain-specific language file of the test input data obtained in the step 201 according to a preset language parsing rule, so as to convert the data defined in the domain-specific language file into corresponding objects, that is, generate an input data object, an interface analog value object, and an expected value object of the test input data.

In some optional implementations of this embodiment, the execution body may interpret, line by line, data defined in the domain-specific language file based on a preset parsing tool, and parse the elements for indicating parameters required by the method to be tested, interface analog data on which the method to be tested depends, and test result expected data into corresponding input data objects, interface analog value objects, and expected value objects of the test input data, respectively.

In these implementations, the preset parsing tool may include, but is not limited to, at least one of the following: groovy profile tool extensions, AST (Abstract Syntax Tree ) conversion tools. By way of example, when the domain-specific language file is simpler, the execution body may parse using its own Groovy profile tool extension. As yet another example, when the domain-specific language file is complex, the execution subject may analyze using the AST conversion tool.

Based on the optional implementation manner, the technical scheme can analyze the domain-specific language file in various different manners so as to convert the domain-specific language file into a corresponding object, thereby providing a technical foundation for subsequent automatic testing.

And step 203, testing the method to be tested based on the input data object and the interface analog value object, and generating an output result of the method to be tested.

In this embodiment, based on the input data object and the interface analog value object generated in the step 202, the execution body may test the method to be tested in various manners, so as to generate an output result of the method to be tested.

In this embodiment, as an example, the execution body may further use the data corresponding to the input data object and the interface analog value object as the input parameter of the method to be tested, operate the method to be tested, and use the obtained operation result as the output result of the method to be tested.

In some optional implementations of this embodiment, the executing body may test the method to be tested based on the input data object and the interface analog value object according to the following steps, and generate an output result of the method to be tested:

first, searching a method to be tested in a preset method set according to a domain-specific language file.

In these implementations, the executing body may search for the method to be tested in the preset method set according to the domain-specific language file in various ways. The method in the preset method set may have a corresponding relationship with at least one domain-specific language file for testing input data. As an example, the execution subject may find a corresponding class in the class path, that is, a class to which the method to be tested belongs, according to a class name and a method name included in a file name of the domain-specific language file of the test data.

Second, an instance object of the class to which the method to be tested belongs is created by reflection.

In these implementations, the execution body may create, by reflection, an instance object of a class to which the method under test belongs

And thirdly, in response to determining that input parameters required by the method to be tested exist in the input data object, calling the method to be tested through reflection, and generating an output result of the method to be tested.

In these implementations, in response to determining that the input parameters required by the method to be tested exist in the input data object, the execution body may call the method to be tested through reflection, thereby generating an output result of the method to be tested.

Based on the optional implementation manner, the scheme provides a method for running the unit test class, and the method test result is obtained by utilizing the data object.

And 204, generating a test result of the method to be tested according to the matching of the output result and the expected value object.

In this embodiment, the execution body may generate the test result of the method to be tested in various manners according to the matching between the output result generated in step 203 and the expected value object generated in step 202. As an example, in response to determining that the output result matches the expected value object (e.g., the same or an error value is less than a preset threshold), the execution body may generate a test result that characterizes the test that the method under test passed. As yet another example, in response to determining that the output result does not match the expected value object (e.g., the error value is greater than a preset threshold), the execution body may generate a test result that characterizes the method under test as failing the test.

With continued reference to fig. 3, fig. 3 is a schematic illustration of an application scenario of a test method according to an embodiment of the present disclosure. In the application scenario of fig. 3, a user 301 sends DSL files 303 of test input data to a server 304 using a terminal device 302. The server 304 parses the DSL file 303 of test input data as described above to generate an input data object 305, an interface analog value object 306, and an expected value object 307 (e.g., characterizing an expected value of "3"). Based on the input data object 305 and the interface object 306, the method to be tested (e.g., methodA) is tested, generating an output result 308 (e.g., "3"). Based on the matching of the output result 308 and the expected value object 307, a test result 309 (e.g., "test pass") of the method to be tested is generated. Optionally, the server 304 may also send the test result 309 to the terminal device 302.

Currently, one of the existing technologies is to use the data source provided by the Junit and TestNG to directly obtain the data through coding or read from Excel and database, which makes it difficult to write more complex test codes in a simpler manner. Moreover, the existing method for simulating and piling interface data in test case codes cannot directly define the interface data to be simulated or piled in the test data, so that great difficulty exists in the realization of the interface simulation. According to the method provided by the embodiment, the acquired field specific language file of the test input data is analyzed to generate the input data object, the interface simulation value object and the expected value object of the corresponding test input data; and generating an output result of the method to be tested based on the input data object and the interface analog value object, and further generating a test result of the method to be tested through matching the output result with the expected value object. The method has the advantages that the contents such as parameters, interface simulation data, expected data and the like are written into the test data file instead of the code of the test case in the form of the field specific language file, so that the understanding and using difficulty is reduced, the development efficiency is improved, the dependent external interface data can be automatically identified and simulated during operation, and the code writing of interface simulation is avoided; therefore, centralized management of test data is realized, a simple, efficient and low-cost operation data driving test scheme can be provided, and further, the unit test efficiency is improved.

With further reference to fig. 4, a flow 400 of yet another embodiment of a test method is shown. The flow 400 of the test method includes the steps of:

step 401, obtaining a domain-specific language file of the test input data.

Step 402, parse the domain-specific language file, generate an input data object, an interface simulation value object, and an expected value object of the test input data.

Step 403, in response to the method to be tested calling the target interface component method, determining whether there is an interface analog value object matching the target interface component method in the interface analog value object.

In this embodiment, in response to a method to be tested calling a target interface component method, an execution subject of the test method (e.g., the server 105 shown in fig. 1) may determine whether there is an interface analog value object matching the target interface component method among the interface analog value objects generated in step 402 described above in various ways. The interface analog value object matched with the target interface component method may include an interface analog value object having a preset correspondence relationship, for example, a predefined interface analog value object.

In this embodiment, as an example, in response to a method to be tested calling a target interface component method, the execution body may first query, in a runtime context, an interface component name (e.g., mockService) and a method name (e.g., someMethod) corresponding to the target interface component method (e.g., having the same name or a preset correspondence), and determine, according to a query result, whether an interface analog value object matching the target interface component method exists in the generated interface analog value objects.

Step 404, in response to determining that the interface exists, calling an interface method corresponding to the matched interface simulation value object, and generating simulation interface data.

In this embodiment, in response to determining that there is an interface, the execution body may call an interface method corresponding to the matched interface analog value object through various methods to generate analog interface data. The interface proxy object may belong to a proxy class generated by means of JAVA dynamic proxy. As an example, the execution body may first generate a simulated interface proxy object according to the matched interface simulation value object, and then call an interface method corresponding to the matched interface simulation value object, thereby generating simulated interface data.

In some optional implementations of this embodiment, the data types in the interface analog value object may be functions.

Based on the optional implementation manner, the execution body may further execute a function of the matched interface analog value object, and determine a value generated by the function as the analog interface data.

Based on the optional implementation manner, the method can call the function to obtain the result in the running process, so that dynamic calculation of the simulation value can be supported.

Step 405, generating an output result of the method to be tested according to the analog interface data and the method to be tested.

In this embodiment, according to the analog interface data and the method to be tested, the execution body may generate the output result of the method to be tested in various manners. As an example, the execution body may operate the method to be tested using the analog interface data as an input parameter of the method to be tested, and determine the obtained operation result as an output result of the method to be tested.

And step 406, generating a test result of the method to be tested according to the matching of the output result and the expected value object.

The steps 401, 402, and 406 are identical to the steps 201, 202, 204 and their optional implementation manners in the foregoing embodiments, and the descriptions of the steps 201, 202, 204 and their optional implementation manners also apply to the steps 401, 402, and 406, which are not repeated herein.

As can be seen from fig. 4, the flow 400 of the test method in this embodiment shows the steps of calling the interface method corresponding to the interface analog value object matched with the target interface component method, generating analog interface data, and generating an output result of the method to be tested according to the analog interface data and the method to be tested. Therefore, the scheme described in the embodiment can realize that when the method of the interface component is called, the method of the proxy class is essentially called, and the interface simulation value object defined in the test script file is calculated and returned, so that the proxy class of the corresponding interface is generated by using a dynamic proxy mode to replace the original real interface component.

With further reference to fig. 5, as an implementation of the method shown in the above figures, the present disclosure provides an embodiment of a testing apparatus, which corresponds to the method embodiment shown in fig. 2 or fig. 4, and which is particularly applicable in various electronic devices.

As shown in fig. 5, the test apparatus 500 provided in this embodiment includes an acquisition unit 501, an analysis unit 502, a test unit 503, and a generation unit 504. The acquiring unit 501 is configured to acquire a domain-specific language file of the test input data, where the domain-specific language file includes elements for indicating parameters required by a method to be tested, interface simulation data on which the method to be tested depends, and expected data of a test result; the parsing unit 502 is configured to parse the domain-specific language file, and generate an input data object, an interface simulation value object and an expected value object of the test input data; a test unit 503 configured to test the method to be tested based on the input data object and the interface analog value object, and generate an output result of the method to be tested; and a generating unit 504 configured to generate a test result of the method to be tested according to the matching of the output result and the expected value object.

In this embodiment, in the test apparatus 500: the specific processes of the obtaining unit 501, the analyzing unit 502, the testing unit 503 and the generating unit 504 and the technical effects thereof may refer to the descriptions related to the steps 201, 202, 203 and 204 in the corresponding embodiment of fig. 2, and are not repeated herein.

In some alternative implementations of the present embodiment, the elements described above may include at least one of the following forms: and (3) statically defining constants, presetting the running result of the code block, and presetting data values output by the function according to the context environment parameters.

In some optional implementations of this embodiment, the parsing unit 502 may be further configured to: based on a preset analysis tool, analyzing the data defined in the field specific language file line by line, and analyzing the elements used for indicating the parameters required by the method to be tested, the interface simulation data on which the method to be tested depends and the expected data of the test result into the corresponding input data object, interface simulation value object and expected value object of the test input data respectively.

In some optional implementations of this embodiment, the test unit 503 may be further configured to: searching a method to be tested in a preset method set according to the field specific language file; creating an instance object of a class to which the method to be tested belongs through reflection; and in response to determining that the input data object has the input parameters required by the method to be tested, calling the method to be tested through reflection, and generating an output result of the method to be tested.

In some optional implementations of this embodiment, the test unit 503 may be further configured to: responding to a method to be tested to call a target interface component method, and determining whether an interface analog value object matched with the target interface component method exists in the interface analog value object; in response to determining that the interface exists, calling an interface method corresponding to the matched interface simulation value object to generate simulation interface data, wherein the interface proxy object belongs to a proxy class generated by means of JAVA dynamic proxy; and generating an output result of the method to be tested according to the analog interface data and the method to be tested.

In some optional implementations of this embodiment, the data types in the interface analog value object may be functions; and the test unit 503 may be further configured to: and running the function of the matched interface simulation value object, and determining the value generated by the function as simulation interface data.

In the device provided in the above embodiment of the present disclosure, the parsing unit 502 parses the domain-specific language file of the test input data acquired by the acquiring unit 501, to generate an input data object, an interface analog value object, and an expected value object of the corresponding test input data; and the test unit 503 generates an output result of the method to be tested based on the input data object and the interface analog value object, and further generates a test result of the method to be tested by matching the output result with the expected value object through the generation unit 504. The method has the advantages that the contents such as parameters, interface simulation data, expected data and the like are written into the test data file instead of the code of the test case in the form of the field specific language file, so that the understanding and using difficulty is reduced, the development efficiency is improved, the dependent external interface data can be automatically identified and simulated during operation, and the code writing of interface simulation is avoided; therefore, centralized management of test data is realized, a simple, efficient and low-cost operation data driving test scheme can be provided, and further, the unit test efficiency is improved.

Referring now to fig. 6, a schematic diagram of an electronic device (e.g., server in fig. 1) 600 suitable for use in implementing embodiments of the present application is shown. The terminal device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. The server illustrated in fig. 6 is merely an example, and should not be construed as limiting the functionality and scope of use of the embodiments herein.

As shown in fig. 6, the electronic device 600 may include a processing means (e.g., a central processing unit, a graphics processor, etc.) 601, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 602 or a program loaded from a storage means 608 into a Random Access Memory (RAM) 603. In the RAM603, various programs and data required for the operation of the electronic apparatus 600 are also stored. The processing device 601, the ROM 602, and the RAM603 are connected to each other through a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

In general, the following devices may be connected to the I/O interface 605: input devices 606 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 607 including, for example, a liquid crystal display (LCD, liquid Crystal Display), a speaker, a vibrator, and the like; storage 608 including, for example, magnetic tape, hard disk, etc.; and a communication device 609. The communication means 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. While fig. 6 shows an electronic device 600 having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead. Each block shown in fig. 6 may represent one device or a plurality of devices as needed.

In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via communication means 609, or from storage means 608, or from ROM 602. The above-described functions defined in the methods of the embodiments of the present application are performed when the computer program is executed by the processing means 601.

It should be noted that, the computer readable medium according to the embodiments of the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In an embodiment of the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. Whereas in embodiments of the present disclosure, the computer-readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (Radio Frequency), and the like, or any suitable combination thereof.

The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: acquiring a domain-specific language file of test input data, wherein the domain-specific language file comprises elements for indicating parameters required by a method to be tested, interface simulation data on which the method to be tested depends and expected data of a test result; analyzing the field specific language file to generate an input data object, an interface simulation value object and an expected value object of the test input data; testing the method to be tested based on the input data object and the interface analog value object, and generating an output result of the method to be tested; and generating a test result of the method to be tested according to the matching of the output result and the expected value object.

Computer program code for carrying out operations of embodiments of the present disclosure may be written in one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C", python, or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments described in the present disclosure may be implemented by means of software, or may be implemented by means of hardware. The described units may also be provided in a processor, for example, described as: a processor includes an acquisition unit, an analysis unit, a test unit, and a generation unit. The names of these units do not constitute a limitation on the unit itself in some cases, and for example, the acquisition unit may also be described as "a unit that acquires a domain-specific language file of test input data, where the domain-specific language file includes elements for indicating parameters required for a method to be tested, interface simulation data on which the method to be tested depends, and test result desired data".

The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above technical features, but encompasses other technical features formed by any combination of the above technical features or their equivalents without departing from the spirit of the invention. Such as the above-described features, are mutually substituted with (but not limited to) the features having similar functions disclosed in the embodiments of the present disclosure.

Claims (10)

1. A method of testing, comprising:

acquiring a domain-specific language file of test input data, wherein the domain-specific language file comprises elements for indicating parameters required by a method to be tested, interface simulation data on which the method to be tested depends and expected data of a test result;

analyzing the field specific language file to generate an input data object, an interface simulation value object and an expected value object of the test input data;

testing the method to be tested based on the input data object and the interface analog value object, and generating an output result of the method to be tested;

And generating a test result of the method to be tested according to the matching of the output result and the expected value object.

2. The method of claim 1, wherein the element comprises at least one of the following forms: and (3) statically defining constants, presetting the running result of the code block, and presetting data values output by the function according to the context environment parameters.

3. The method of claim 1, wherein the parsing the domain-specific language file to generate an input data object, an interface simulation value object, and an expected value object of the test input data comprises:

and based on a preset analysis tool, interpreting the data defined in the domain-specific language file row by row, and respectively analyzing the elements for indicating the parameters required by the method to be tested, the interface simulation data on which the method to be tested depends and the expected data of the test result into corresponding input data objects, interface simulation value objects and expected value objects of the test input data.

4. A method according to any of claims 1-3, wherein said testing said method to be tested based on said input data object and said interface analog value object, generating an output result of said method to be tested, comprises:

Searching the method to be tested in a preset method set according to the domain-specific language file;

creating an instance object of the class to which the method to be tested belongs through reflection;

and in response to determining that the input data object has the input parameters required by the method to be tested, calling the method to be tested through reflection, and generating an output result of the method to be tested.

5. A method according to any one of claims 1-3, wherein said testing a method to be tested corresponding to said domain-specific language file based on said input data object and said interface analog value object, generating an output result of said method to be tested, comprises:

responding to the method to be tested to call a target interface component method, and determining whether an interface analog value object matched with the target interface component method exists in the interface analog value object;

in response to determining existence, calling an interface method corresponding to the matched interface simulation value object to generate simulation interface data, wherein the interface proxy object belongs to a proxy class generated by means of JAVA dynamic proxy;

and generating an output result of the method to be tested according to the analog interface data and the method to be tested.

6. The method of claim 5, wherein the type of data in the interface analog value object is a function; and

and calling an interface proxy object corresponding to the matched interface simulation value object to generate simulation interface data, wherein the simulation interface data comprises the following steps:

and running the function of the matched interface simulation value object, and determining the value generated by the function as the simulation interface data.

7. A test apparatus comprising:

the device comprises an acquisition unit, a test input unit and a test result acquisition unit, wherein the acquisition unit is configured to acquire a domain-specific language file of test input data, and the domain-specific language file comprises elements for indicating parameters required by a method to be tested, interface simulation data on which the method to be tested depends and test result expected data;

the analysis unit is configured to analyze the domain-specific language file and generate an input data object, an interface simulation value object and an expected value object of the test input data;

the testing unit is configured to test the method to be tested based on the input data object and the interface simulation value object, and generate an output result of the method to be tested;

and the generating unit is configured to generate a test result of the method to be tested according to the matching of the output result and the expected value object.

8. The apparatus of claim 7, wherein the test unit is further configured to:

responding to the method to be tested to call a target interface component method, and determining whether an interface analog value object matched with the target interface component method exists in the interface analog value object;

in response to determining existence, calling an interface method corresponding to the matched interface simulation value object to generate simulation interface data, wherein the interface proxy object belongs to a proxy class generated by means of JAVA dynamic proxy;

and generating an output result of the method to be tested according to the analog interface data and the method to be tested.

9. An electronic device, comprising:

one or more processors;

a storage device having one or more programs stored thereon;

when executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-6.

10. A computer readable medium having stored thereon a computer program, wherein the program when executed by a processor implements the method of any of claims 1-6.