CN114579441A - mock point detection method and device, storage medium and electronic equipment - Google Patents

Abstract

The embodiment of the disclosure relates to the technical field of computer information, in particular to a mock point detection method, a mock point detection device, a memory medium and an electronic device. The method comprises the following steps: matching a plurality of methods of a called party with an identifier rule set according to a calling relation among a plurality of methods in a code to be tested; and reserving a method matched with the identifier rule set as a mock point, wherein a virtual object created according to the mock point is used for assisting the test of the code to be tested. The technical scheme of the utility model can realize the recognition of mock point automatically to when reducing the cost of labor, improve efficiency of software testing.

Description

mock point detection method and device, storage medium and electronic equipment

Technical Field

The embodiment of the disclosure relates to the technical field of computer information, in particular to a mock point detection method, a mock point detection device, a memory medium and an electronic device.

Background

This section is intended to provide a background or context to the embodiments of the disclosure recited in the claims and the description herein is not admitted to be prior art by inclusion in this section.

Before the code of the application program (including the client and the server) and the functional module thereof is updated and online, a test is required to be performed to determine whether the code execution and execution flow of the application program and the functional module thereof are normal.

Disclosure of Invention

In some techniques, a drainage test may be performed before the code of an application and its functional modules are updated online. In the drainage test, parameters and return values of code methods of some application programs and functional modules thereof are recorded, the code methods are executed again by using the recorded parameters for playback during the test, and whether the played return values are consistent with the recorded return values or not is verified. In the case of the same parameter, the same piece of code is run, and if the playback return value and the recorded return value are inconsistent, the code is not executed in an expected manner (the drainage test is not passed), and a defect (bug) may exist. The recording parameters may be used for multiple playbacks. Therefore, the drainage test replaces the traditional complicated parameter construction and result verification of the test by recording data, and the traditional automatic compiling cost can be effectively reduced.

In the application program testing process, some method objects which are not easy to construct or obtain can be used as mock points, and virtual objects created according to the mock points can be used as substitutes of real methods in the testing process to test the application program.

In the code of an application, it can often be divided into two parts: a core approach and a non-core approach. The core method is the core logic of the method to be tested and is the main object of the drainage test of the application program. The uncore method assists the implementation of its main functions, for example, the uncore method may implement some pre-preparation work before core logic operation, saving of core logic operation results, and the like.

Complex functions of an application are realized by mutual invocation of a plurality of methods in code. In the drainage test, the called external method is generally a non-core method, and can be used as a mock point, so that a corresponding virtual object is created and used in the drainage test. In the case that the drainage test is usually an online playback test of parameters recorded on the line, however, the online users, data environments, and the like are completely different from the online users, data environments, and the like, for this reason, before the test of the core method for executing the function, it is usually necessary to perform pre-checks on some objects (such as whether the user is registered, whether the user has authority, whether the commodity exists, and the like) therein, and in order to ensure that the core logic can be executed in the drainage test, these pre-checks may also use the corresponding non-core methods as mock points, thereby creating corresponding virtual objects for use in the drainage test. After the core method is executed, the execution result is saved. In the drainage test, because the online parameters are executed in an online mode, the result data of the core method is useless dirty data for the test environment due to data difference, and in order to avoid polluting the test environment, the result data can also be used as a mock point for the storage method, so that a corresponding virtual object is created to be used in the drainage test.

In some techniques, in order to find these mock points from the code under test before conducting the drainage test, the code under test needs to be manually read to perform code analysis. Relevant testers can find and record mock points by reading the codes line by line. When the functions to be realized by the code to be detected are complex, a plurality of methods in the code are often called layer by layer in a nested manner, and some methods are hidden and are not easy to find all mock points in the code to be detected. Therefore, the mock point searching mode has higher requirement on the code reading capability of a searching person; when the functions to be realized are complex, the search time of the mock point is longer; when the code changes, the code needs to be read again manually, and there may be duplicative work.

For this reason, an improved mock point detection method and apparatus, a storage medium, and an electronic device are highly needed to automatically recognize a mock point, so as to improve the test efficiency while reducing the labor cost.

In this context, embodiments of the present invention are intended to provide a mock point detection method and apparatus, a storage medium, and an electronic device.

According to an aspect of the present disclosure, there is provided a mock point detection method, including:

matching a plurality of methods of a called party with an identifier rule set according to a calling relation among a plurality of methods in a code to be tested;

and reserving a method matched with the identifier rule set as a mock point, wherein a virtual object created according to the mock point is used for assisting the test of the code to be tested.

According to an aspect of the present disclosure, there is provided a mock point detecting device including:

the matching module is used for matching the methods of the called party with the identifier rule set according to the calling relationship among the methods in the code to be tested;

and the determining module is used for reserving a method matched with the identifier rule set as a mock point, wherein a virtual object created according to the mock point is used for assisting the test of the code to be tested.

According to an aspect of the present disclosure, there is provided a storage medium having stored thereon a computer program which, when executed by a processor, is the above-described mock point detection method.

According to an aspect of the present disclosure, there is provided an electronic device including:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform any of the above-described mock point detection methods via execution of the executable instructions.

In the embodiment of the disclosure, a plurality of methods of a to-be-called party are automatically identified according to a calling relation among the methods in a code to be tested, and a mock point is automatically identified based on matching of the plurality of methods of the to-be-called party and an identifier rule set, so that the test of the code to be tested can be assisted according to a virtual object created by the mock point. Therefore, the mock point can be automatically identified without manual participation, so that the requirement on code reading capability of a tester is avoided; the complexity of the code to be tested has little influence on the recognition efficiency of the mock point, so that the recognition efficiency of the mock point is effectively improved no matter whether the code to be tested is complex or not; when the code to be tested is changed, the code does not need to be read again manually, so that the mock point can be automatically identified, the labor cost is reduced, and the testing efficiency is improved.

Drawings

The above and other objects, features and advantages of exemplary embodiments of the present disclosure will become readily apparent from the following detailed description read in conjunction with the accompanying drawings. Several embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:

fig. 1 schematically shows a flow chart of a mock point detection method according to an embodiment of the present disclosure;

FIG. 2 schematically illustrates a flow diagram for determining call relationships between methods in code to be tested, according to an embodiment of the present disclosure;

FIG. 3 is a diagram schematically illustrating call relationships between methods of code under test according to one embodiment of the present disclosure;

FIG. 4 is a schematic diagram schematically illustrating a process of executing code to be tested according to another embodiment of the present disclosure;

FIG. 5 schematically shows a schematic diagram of a testing process of the code to be tested in FIG. 4;

FIG. 6 schematically illustrates an ordering interface for purchasing a code to be tested for a commodity generation order, according to an embodiment of the present disclosure;

FIG. 7 schematically illustrates an actual order generation interface for purchasing code to be tested for a commodity generation order according to an embodiment of the present disclosure;

FIG. 8 schematically illustrates a test order generation interface for purchasing code to be tested for a commodity generation order, according to an embodiment of the present disclosure;

fig. 9 schematically shows a block diagram of a mock point detection device according to an embodiment of the present disclosure;

FIG. 10 shows a schematic diagram of a storage medium according to an embodiment of the present disclosure; and

FIG. 11 schematically illustrates a block diagram of an electronic device in accordance with the disclosed embodiments.

In the drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

Detailed Description

The principles and spirit of the present invention will be described with reference to a number of exemplary embodiments. It is understood that these embodiments are given only to enable those skilled in the art to better understand and to implement the present invention, and do not limit the scope of the present invention in any way. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

As will be appreciated by one skilled in the art, embodiments of the present disclosure may be embodied as a system, apparatus, device, method, or computer program product. Accordingly, the present disclosure may be embodied in the form of: entirely hardware, entirely software (including firmware, resident software, micro-code, etc.), or a combination of hardware and software.

According to an embodiment of the present disclosure, a mock point detection method, a mock point detection apparatus, a storage medium, and an electronic device are provided.

In this document, any number of elements in the drawings is intended to be illustrative and not restrictive, and any nomenclature is used for distinction only and not for any restrictive meaning.

The principles and spirit of the present disclosure are explained in detail below with reference to several representative embodiments of the present disclosure.

Summary of The Invention

The inventor finds that at present, in order to find the mock points from the code to be tested before the drainage test is carried out, the code to be tested needs to be manually read so as to carry out code analysis. Relevant testers can find and record mock points by reading the codes line by line.

The following problems exist in the above scheme:

1) the search of the mock points depends on the code reading capability of a test classmate, and is difficult to popularize so as to improve the overall search efficiency of the mock points; 2) when the functions to be realized by the code to be detected are complex, the code is usually complex, a plurality of methods are often called layer by layer in a nested manner, some methods are hidden and are not easy to find all mock points in the code to be detected, and therefore, the time for finding the mock points is long; 3) when the code is changed, the mock point may be changed, so that the code needs to be read again manually, the incremental difference is compared, and the mock point is supplemented or removed. The code updating frequency is high, so that the mock point needs to be updated frequently, the consumption of the labor cost is high, and the code testing efficiency is reduced; 4) although the drainage test mode aims at reducing the cost of the traditional test, the complexity and the cost are actually reduced in parameter construction and return value verification, the overall cost of the drainage test is increased due to the searching mode of the manual mock point, and the test efficiency is reduced.

In view of the above, the basic idea of the present invention is: the method comprises the steps of automatically identifying a plurality of methods of a called party according to calling relations among the methods in the code to be tested, and automatically identifying a mock point based on matching of the methods of the called party and an identifier rule set so as to assist testing of the code to be tested according to a virtual object created by the mock point. Therefore, on one hand, the method can realize automatic recognition of the mock point without manual participation, so that no code reading capability requirement is required for testers; on the other hand, the complexity of the code to be tested has little influence on the recognition efficiency of the mock point, so that the recognition efficiency of the mock point is effectively improved no matter whether the code to be tested is complex or not; on the other hand, when the code to be tested is changed, the code does not need to be read again manually. From this, this disclosure can realize the discernment of mock point automatically to when reducing the cost of labor, improve efficiency of software testing.

Having described the general principles of the invention, various non-limiting embodiments of the invention are described in detail below.

Exemplary method

A mock point detection method according to an exemplary embodiment of the present disclosure is described below with reference to fig. 1.

Referring to fig. 1, the mock point detection method may include the following steps:

step S110, matching a plurality of methods of a called party with an identifier rule set according to a calling relation among a plurality of methods in a code to be tested;

and step S120, reserving a method matched with the identifier rule set as a mock point, wherein a virtual object created according to the mock point is used for assisting the test of the code to be tested.

In the mock point detection method of the embodiment of the disclosure, a plurality of methods of a to-be-called party are automatically identified according to a calling relation among the methods in a code to be tested, and a mock point is automatically identified based on matching of the plurality of methods of the to-be-called party and an identifier rule set, so that the test of the code to be tested can be assisted according to a virtual object created by the mock point. Therefore, the mock point can be automatically identified without manual participation, so that the requirement on code reading capability of a tester is avoided; the complexity of the code to be tested has little influence on the recognition efficiency of the mock point, so that the recognition efficiency of the mock point is effectively improved no matter whether the code to be tested is complex or not; when the code to be tested is changed, the code does not need to be read again manually, so that the mock point can be automatically identified, the labor cost is reduced, and the testing efficiency is improved.

According to an exemplary embodiment of the present disclosure, code to be tested is used to implement one or more business functions. The code to be tested can be an application program, a functional module of the application program, an update code of the application program and the like. The code to be tested includes a plurality of methods. A method is a collection of code statements for performing a certain behavior. In embodiments of the present disclosure, the methods in the code to be tested may also be referred to as functions.

According to an exemplary embodiment of the disclosure, the set of identifier rules comprises: the method comprises an identifier of a company to which the code to be tested belongs. Specifically, in the tested code, only the method of packaging the code by the company to which the code to be tested belongs can realize an auxiliary method to be identified as a mock point, such as verification based on business data or data storage packaging. Other methods such as a software development kit method and an open source method generally only perform operation (a core method) and do not have auxiliary functions related to services, so that the method does not need to be identified as a mock point. Therefore, whether the method is recognized as a mock point can be judged by judging whether the method is packaged by the company to which the code to be tested belongs. Because the method comprises the identifier of the company to which the code to be tested belongs if the code to be tested belongs to the company to which the code to be tested belongs is packaged by the company to which the code to be tested belongs, whether the method is packaged by the company to which the code to be tested belongs can be identified by judging whether the method comprises the identifier of the company to which the code to be tested belongs.

According to an exemplary embodiment of the disclosure, the identifier rule set comprises that no data bearer class identifier is included in the method. The data bearing method is used for realizing the conversion from the service data to the object, and has no complex logic, so that a virtual object does not need to be constructed as a mock point. The data bearer class method will have a data bearer class identifier in the code of its method so that it can be determined whether the method needs to be identified as a mock point depending on whether or not the data bearer class identifier is included in the method. Their data carrying class identifiers may differ according to different code languages. For example, the java is used, the data bearer class identifier includes one or more of a data transmission object, metadata, an entity, enumeration, a result, a constant, a message, an information package, and a parameter. The identifier of the data transfer object is dto; the identifier of the metadata is meta; the identifier of the entity is entity; the enumerated identifier is enum; the identifier of the result is result; the identifier of the constant is constant; the message identifier is a message, the information encapsulation identifier is info, and the parameter identifier is param.

According to an exemplary embodiment of the disclosure, the set of identifier rules comprises: a common behavior governing identifier is not included in the method. Since the common behavior control method is a general overall method, the common behavior control method performs uniform processing on different data/objects, and therefore a virtual object does not need to be constructed as a mock point. The collective behavior management method may include one or more of an exception handling method, a link tracing method, and a logging method. The code of the exception handling method is used to perform uniform handling of error conditions. The code of the link tracing method is used to query the information of all methods on the service chain. The log recording method is used for recording relevant information when each method is executed.

The common behavior control method may have a common behavior control identifier in the code of its method, so that it may be determined whether the method needs to be recognized as a mock point according to whether the common behavior control identifier is included in the method. Their collective behavior governing identifiers may differ according to different code languages. Taking java as an example, the joint behavior management identifier includes one or more of exception handling, link tracing, and logging. Wherein the identifier of Exception handling is Exception; the identifier of the link tracing is Trace, and the identifier of the Log record is Log.

According to an exemplary embodiment of the disclosure, the set of identifier rules comprises: the constructor identifier is not included in the method. Considering that the constructor does not have the function of data verification, the virtual object does not need to be constructed as a mock point. Constructors will have common behavior governing identifiers in the code of their methods, so that it can be determined whether the method needs to be identified as a mock point, depending on whether the constructor identifier is included in the method. Taking java as an example, the constructor identifier may be initialization (int), for example, and the disclosure is not limited thereto.

According to an exemplary embodiment of the disclosure, the identifier rule set may include a combination of one or more of the above rules. In a further embodiment, the matching execution order of the rules may be set as desired.

According to an exemplary embodiment of the disclosure, the identifier used for matching in the identifier rule set may be associated with a language of the code to be tested. Therefore, for codes to be tested in different languages, a plurality of methods of the called party can be matched with the identifier rules of the language related to the codes to be tested in the identifier rule set, so that the identification accuracy of the mock point is ensured.

According to an exemplary embodiment of the present disclosure, step S110 in fig. 1 is performed in response to the submission of the code to be tested. Thus, automatic triggering of mock point identification can be achieved. Further, the mock point identification step can be executed asynchronously with the flow-directed test of the code to be tested to ensure the normal execution of the flow-directed test of the code to be tested.

According to an exemplary embodiment of the present disclosure, the execution of step S110 may include steps in the flowchart illustrated in fig. 2. Fig. 2 shows the following steps together:

step S101: and acquiring the calling relation among a plurality of methods in the code to be tested.

According to an exemplary embodiment of the present disclosure, methods may be identified by including a method name, an entry definition, a return parameter definition, etc. of a method to be called into the code of the method of the caller. Therefore, the calling relation among the methods is obtained by identifying and analyzing the code to be tested. According to an exemplary embodiment of the disclosure, a code semantic analysis algorithm may be adopted to obtain a calling relationship between a plurality of methods in the code to be tested. And performing semantic analysis on the code to be tested through a code semantic analysis algorithm, so as to obtain the calling relation among a plurality of methods in the code to be tested based on the result of the semantic analysis.

According to an exemplary embodiment of the present disclosure, the code semantic analysis algorithm may be, for example, constructing an Abstract Syntax Tree (AST), and an Abstract representation may be formed for the method call relation of the code to be tested through the Abstract Syntax Tree, which may represent the Syntax structure of the code to be tested in a Tree form. Specifically, the call syntax may be different between the methods for different code languages, and thus, different code semantic analysis modes may be provided for different code languages. For example, for java, the Code under test may be semantically parsed in conjunction with a Byte Code Engineering Library (BCEL), thereby generating an abstract syntax tree based on the parsed semantic content.

In connection with fig. 3, fig. 3 shows an abstract syntax tree for the methods of application a. The code to be tested of the application program A comprises a method of a calling party and a method of a called party. Referring to FIG. 3, method A1 in the test code of application A calls method A2, method B1, method C1, and method A3; method A2 invoked method C2, method A4; method A3 invoked method D1; method A4 calls method E1. The method of the calling party comprises a method A1, a method A2, a method A3 and a method A4; the methods of the callee include method A2, method B1, method C1, method A3, method C2, method A4, method D1, and method E1. The method of the calling party, including method a1, method a2, method A3 and method a4, are all methods of application a, and the method B1, method C1, method C2, method D1 and method E1 of the method of the called party are all external methods to be called.

Step S102: a plurality of methods of a callee are obtained.

Step S103: a plurality of methods of a caller are obtained.

Step S104: and removing the methods of the calling party from the methods of the called party.

According to the analysis of various codes to be tested, the method plays an auxiliary role in realizing the core function of the codes to be tested, and is often a method of external services to be called so as to assist in data query, data storage and the like. Therefore, the mock point required to create a virtual object is high in the method of the external service to be called. Therefore, the method of the external service to be called can be obtained by removing the methods of the calling party from the methods of the called party through the acquisition of the calling relationship. Continuing with the example of FIG. 3, the method of the caller (method A1, method A2, method A3, and method A4) is culled from the methods of the callee (method A2, method B1, method C1, method A3, method C2, method A4, method D1, and method E1) to obtain the external methods (method B1, method C1, method C2, method D1, and method E1) to be called. Through the abstract syntax tree obtained by semantic analysis of the code to be tested, the method of the called party to be matched can be screened to obtain the external method of the called party, and the number of methods matched by a subsequent identifier rule set is reduced, so that the mock point identification efficiency is improved.

Further, since the external methods are typically embedded in the code to be tested in the form of an interface, jar (java language file compression format), etc., the present disclosure may also look through the integrated development environment tool among the callees 'methods to identify the callees' external methods.

Referring now to FIG. 4, FIG. 4 schematically illustrates a diagram of an execution process of code to be tested according to another embodiment of the present disclosure.

In the execution process of the code to be tested, S11 is first executed: and a method for inquiring user information. The method of inquiring user information may be an external method, and the member center 1 provides a user information inquiry interface by which user information is inquired by calling. The query of the user information is an auxiliary method and can be used as a non-core method of the code to be tested.

Then, execution of S12: a user information processing method and a parameter verification method. The user information processing method and the parameter checking method do not need to call an external method, and execute the core logic of the code to be tested, so the method can be used as the core method of the code to be tested.

Then, execution of S13: a method for inquiring commodity information. The method for inquiring the commodity information can be an external method, a commodity information inquiry interface is provided by the commodity center 2, and the commodity information is inquired by calling the interface. The query of the commodity information is an auxiliary method and can be used as a non-core method of the code to be tested.

Then, execution of S14: a price calculation method. The price calculation method does not need to call an external method, and executes the core logic of the code to be tested, so the price calculation method can be used as the core method of the code to be tested.

Then, execution of S15: and generating an order method. The order generation method may be an external method, and the order center 3 provides an order generation interface, and generates an order by calling the interface. The order is generated as an auxiliary method which can be used as a non-core method of the code to be tested.

Then, execution S16: and (4) deducting inventory. The inventory deduction method may be an external method, and the inventory data change interface is provided by the commodity center 3, and the inventory deduction is performed in the commodity center 3 by calling the interface. The inventory deduction method is an auxiliary method and can be used as a non-core method of the code to be tested.

In conjunction with fig. 6 and 7, fig. 6 schematically illustrates an ordering interface for purchasing codes to be tested for a commodity generation order, according to an embodiment of the present disclosure; FIG. 7 schematically illustrates an actual order generation interface for purchasing codes to be tested for a commodity generation order according to an embodiment of the present disclosure. In the reflow testing process, the method is equivalent to simulating the execution process when the user actually uses the code to be tested, but the reflow testing environment is different from the actual environment of the user.

In actual use, the user selects the order button on the order interface 310 shown in fig. 6, and orders the displayed product. The code for generating an order for purchasing a commodity completes the process of generating an order (see fig. 4) and provides the user with an actual order generation interface 320 as shown in fig. 7. According to the steps shown in fig. 4 and the information required to be displayed in the order generation interface 320, the interface of the member center 1 is first called to acquire user information in step S11 shown in fig. 4. The user information processing method and the parameter verification method of step S12 are then performed using the acquired user information without interaction with any external device. Then, step S13 is executed to call the goods information query interface provided by the goods center 2, query the goods information, and display it on the order generating interface 320. The price calculation method is performed at step S14 and the calculated price is displayed on the order generation interface 320 without interaction with any external device. The order generation interface provided by the order center 3 is called to generate an order in step S15, and relevant order information is displayed on the order generation interface 320. Finally, step S16 is executed to call the inventory data modification interface provided by the commodity center 3, modify the inventory and update the inventory in the ordering interface 310. Thus, when the user actually places an order, step S11, step S13, step S15, and step S16 call the interface execution of the member center 1, the product center 2, and the order center 3, respectively. In the testing environment, the testing device executing the code to be tested is not connected with the member center 1, the commodity center 2 and the order center 3, so that information cannot be acquired by calling interfaces of the member center 1, the commodity center 2 and the order center 3, and in order to ensure normal execution of the test, the methods need to be used as mock points to virtualize the methods, so that in the process of test execution, when the methods are executed, data which should be returned by the member center 1, the commodity center 2, the order center 3 and the like originally are directly returned by the virtualized method.

Further, the mock point of the above example can be identified in such a way that, based on the code to be tested, a plurality of methods of the called party can be obtained through analysis of the calling relationship of each method. Since the local method has a method definition, and the external method directly calls the local method without the method definition, the local method and the external method can be obtained through code semantic analysis. For example, the method definition has a name of public void method, and if a public void modifier exists in the method, the method is a local method. Other methods may be considered external methods.

Thus, a plurality of methods (a query user information method, a query product information method, a generate order method, and a deduct stock method) of the callee for matching with the identifier rule set can be obtained. And respectively matching the user information inquiring method, the commodity information inquiring method, the order generating method and the inventory deduction method with the identifier rule set. Taking the method for inquiring user information as an example, according to the scanning and identification of the code, the code can be determined to include the identifier of the company to which the code to be tested belongs, no data bearing class identifier, no common behavior control identifier and no constructor identifier, so that the method for inquiring user information is automatically identified as a mock point. Similarly, for the method of inquiring commodity information, the method of generating an order and the method of deducting inventory, the method is also automatically identified as a mock point according to the scanning matching in the above manner.

Referring now to fig. 5, fig. 5 schematically illustrates a schematic diagram of the testing process of the code under test of fig. 4.

Before testing the code to be tested, a virtual object can be constructed according to the method of each identified mock point. For example, virtual user information is constructed for a method mock point 1 for inquiring user information; virtual commodity information is constructed aiming at a commodity information inquiry method mock point 2; constructing a virtual order aiming at an order generation method mock point 3; and constructing a virtual deduction result aiming at a deduction inventory method mock point 4. Thus, when performing the test, S21 may be executed first: querying a user information method to obtain virtual user information; execution of S22: a user information processing method and a parameter checking method; execution of S23: inquiring a commodity information method to obtain commodity user information; execution of S24: a price calculation method; execution of S25: generating an order method to obtain a virtual order; execution S26: a deduction inventory method is performed to obtain a virtual deduction result.

Referring now to FIG. 8, FIG. 8 schematically illustrates a test order generation interface for purchasing code to be tested for a commodity generation order, according to an embodiment of the present disclosure.

In the testing process, when the order placing button is selected on the order placing interface 310 shown in fig. 6 automatically based on the test case, the displayed commodity is placed. The code for purchasing the product generation order needs to complete the process of generating the order (see fig. 5) during the testing process, and provides the user with a test order generation interface 330 as shown in fig. 8. According to fig. 5 and 8, during the testing process, the execution of the code to be tested is not connected with the member center 1, the commodity center 2 and the order center 3. Thus, step S11, step S13, step S15, and step S16 are recognized as mock points based on the above mock point recognition method, and are virtualized as corresponding step S21, step S23, step S25, and step S26. When the step S21 is performed, the step S21 directly constructs virtual user information and returns without calling an interface of the member center 1; when the step S23 is performed, the step S23 directly constructs virtual commodity information and returns without calling an interface of the commodity center 2; when step S25 is executed, step S25 directly constructs virtual order information and returns it without calling an interface of the order center 3; when step S26 is executed, step S26 directly constructs a virtual deduction result and returns without calling the interface of the commodity center 2. Therefore, the normal execution of the test process of the code to be tested is ensured.

The above is merely an illustration of one specific implementation of the present disclosure, which is not to be taken as a limitation thereof.

Exemplary devices

Having introduced the mock point detection method of the exemplary embodiment of the present disclosure, the mock point detection device of the exemplary embodiment of the present disclosure is described next with reference to fig. 9.

Referring to fig. 9, the mock point detection device 200 of the exemplary embodiment of the present disclosure may include: a matching module 210 and a determination module 220. Wherein the content of the first and second substances,

the matching module 210 is configured to match the multiple methods of the called party with the identifier rule set according to the calling relationship among the multiple methods in the code to be tested;

the determining module 220 is configured to reserve a method matching the identifier rule set as a mock point, where a virtual object created according to the mock point is used to assist in testing the code to be tested.

According to an exemplary embodiment of the present disclosure, the matching module includes: the first acquisition module is used for acquiring the calling relation among a plurality of methods in the code to be tested; the second acquisition module is used for acquiring a plurality of methods of the called party; the third acquisition module is used for acquiring a plurality of methods of the calling party; and the screening module is used for removing the methods of the caller from the methods of the callee.

According to an exemplary embodiment of the present disclosure, the first obtaining module includes: and the code semantic analysis module is used for acquiring the calling relation among the methods in the code to be tested by adopting a code semantic analysis algorithm.

According to an exemplary embodiment of the disclosure, the set of identifier rules comprises: the method comprises an identifier of a company to which the code to be tested belongs.

According to an exemplary embodiment of the disclosure, the set of identifier rules comprises: the method does not include a data bearing class identifier, and the data bearing class identifier includes one or more of a data transmission object, metadata, an entity, an enumeration, a result, a constant, a message, an information package, and a parameter.

According to an exemplary embodiment of the disclosure, the set of identifier rules comprises: common behavior governance identifiers are not included in the method, and include one or more of exception handling, link tracing, and logging.

According to an exemplary embodiment of the disclosure, the set of identifier rules comprises: the constructor identifier is not included in the method.

According to an exemplary embodiment of the disclosure, the identifier in the set of identifier rules is associated with a language of the code to be tested, the determining comprises: and the association matching module is used for matching the methods of the called party with the identifier rules of the language associated with the code to be tested in the identifier rule set.

According to an exemplary embodiment of the disclosure, the step performed by the matching module is due to the submitted execution of the code to be tested.

Since each functional module of the mock point detection device in the embodiment of the present disclosure is the same as that in the embodiment of the foregoing mock point detection method, it is not described herein again.

Exemplary storage Medium

Having described the mock point detection method, apparatus, and system according to the exemplary embodiments of the present disclosure, a storage medium according to the exemplary embodiments of the present disclosure will be described with reference to fig. 10.

Referring to fig. 10, a program product 1000 for implementing the above method according to an embodiment of the present disclosure is described, which may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a device, such as a personal computer. However, the program product of the present disclosure is not limited thereto, and in this document, a 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.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, 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.

A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a 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 readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user computing device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).

Exemplary electronic device

Having described the storage medium of the exemplary embodiment of the present disclosure, next, an electronic device of the exemplary embodiment of the present disclosure will be described with reference to fig. 10.

The electronic device 800 shown in fig. 11 is only an example and should not bring any limitation to the function and the scope of use of the embodiments of the present disclosure.

As shown in fig. 11, the electronic device 800 is embodied in the form of a general purpose computing device. The components of the electronic device 800 may include, but are not limited to: the at least one processing unit 810, the at least one memory unit 820, a bus 830 connecting different system components (including the memory unit 820 and the processing unit 810), and a display unit 840.

Wherein the storage unit stores program code that is executable by the processing unit 810 to cause the processing unit 810 to perform steps according to various exemplary embodiments of the present invention as described in the above section "exemplary methods" of the present specification. For example, the processing unit 810 may perform the steps as shown in fig. 1.

The memory unit 820 may include volatile memory units such as a random access memory unit (RAM)8201 and/or a cache memory unit 8202, and may further include a read only memory unit (ROM) 8203.

The storage unit 820 may also include a program/utility 8204 having a set (at least one) of program modules 8205, such program modules 8205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

Bus 830 may include a data bus, an address bus, and a control bus.

The electronic device 800 may also communicate with one or more external devices 900 (e.g., keyboard, pointing device, bluetooth device, etc.), which may be through an input/output (I/O) interface 850. The electronic device 800 further comprises a display unit 840 connected to the input/output (I/O) interface 850 for displaying. Also, the electronic device 800 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via the network adapter 860. As shown, the network adapter 860 communicates with the other modules of the electronic device 800 via the bus 830. It should be appreciated that although not shown, other hardware and/or software modules may be used in conjunction with the electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

It should be noted that although in the above detailed description several modules or sub-modules of the mock point detection device are mentioned, such a division is merely exemplary and not mandatory. Indeed, the features and functionality of two or more of the units/modules described above may be embodied in one unit/module, in accordance with embodiments of the present disclosure. Conversely, the features and functions of one unit/module described above may be further divided into embodiments by a plurality of units/modules.

Further, while the operations of the disclosed methods are depicted in the drawings in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.

While the spirit and principles of the invention have been described with reference to several particular embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, nor is the division of aspects, which is for convenience only as the features in such aspects may not be combined to benefit. The invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims (10)

1. A mock point detection method is characterized by comprising the following steps:

matching a plurality of methods of a called party with an identifier rule set according to a calling relation among a plurality of methods in a code to be tested;

and reserving a method matched with the identifier rule set as a mock point, wherein a virtual object created according to the mock point is used for assisting the test of the code to be tested.

2. The mock point detection method according to claim 1, wherein said matching identifiers of the called methods with the identifier rule set according to the calling relationship between the methods in the code to be tested comprises:

obtaining a calling relation among a plurality of methods in a code to be tested;

acquiring a plurality of methods of a called party;

acquiring a plurality of methods of a calling party;

and removing the methods of the calling party from the methods of the called party.

3. The mock point detection method according to claim 2, wherein said obtaining a calling relationship between a plurality of methods in a code to be tested comprises:

and acquiring the calling relation among a plurality of methods in the code to be tested by adopting a code semantic analysis algorithm.

4. The mock point detection method according to claim 1, wherein said set of identifier rules comprises:

the method comprises an identifier of a company to which the code to be tested belongs.

5. The mock point detection method according to claim 1, wherein said set of identifier rules comprises:

the method does not include a data bearing class identifier, and the data bearing class identifier includes one or more of a data transmission object, metadata, an entity, an enumeration, a result, a constant, a message, an information package, and a parameter.

6. The mock point detection method according to claim 1, wherein said set of identifier rules comprises:

common behavior governance identifiers are not included in the method, and include one or more of exception handling, link tracing, and logging.

7. The mock point detection method according to claim 1, wherein said set of identifier rules comprises:

the constructor identifier is not included in the method.

8. A mock point detection device, comprising:

the matching module is used for matching the methods of the called party with the identifier rule set according to the calling relation among the methods in the code to be tested;

and the determining module is used for reserving a method matched with the identifier rule set as a mock point, wherein a virtual object created according to the mock point is used for assisting the test of the code to be tested.

9. A storage medium having a computer program stored thereon, the computer program when executed by a processor implementing:

the mock point detection method according to any one of claims 1 to 9.

10. An electronic device, comprising:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform, via execution of the executable instructions:

the mock point detection method according to any one of claims 1 to 9.

Images