Detailed Description
Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding, and are to be considered merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
It should be noted that the method provided by the embodiment of the invention is suitable for the automatic test of all java languages in the software industry, and aims to automatically test products or interfaces at regular intervals, and other types of unit tests can be realized according to specific language extension.
Automated testing is the implementation of simulated manual testing, which refers to the process of automatically executing software testing in the form of code or script, and therefore, the generation of corresponding code and script is necessary.
It should be noted that the code and script herein means that the automated test may be generated by a script language or may be generated by a code. Both are substantially identical, although the principle and manner of operation are different, the problem addressed is the same.
The terms related to the present invention are explained as follows:
Byte code: an intermediate process of translating source code into computer-recognizable binary data can be understood. Because the Java code developed by the developer is simply a combination of words and formats, but the computer must also translate these words for recognition because the computer recognizes only the binary code 0/1. In addition, the bytecode is an essential process in the java language running, and regardless of the environment, any program for executing java language development must execute the process.
Byte code enhancement: after the Java byte code is generated, the Java byte code is modified to enhance the function, and the mode is equivalent to modifying the binary file of the application program, mainly aiming at reducing redundant codes, improving the performance and the like.
FREEMARKER: a template engine, a generic tool that generates output text based on templates and data to be changed.
Floor data: is the data that is persisted, and such data is typically placed on a hard disk or other persisted storage, such as: pictures, system logs, data displayed on pages, data stored in relational databases, etc., floor data must have a fixed carrier that does not disappear instantaneously.
Referring to fig. 1, a main flowchart of an automatic test code generating method provided by an embodiment of the present invention is shown, including the following steps:
S101: determining an interface corresponding to the test instruction in the target application, and collecting test data of the interface in the test process based on a probe corresponding to the target application;
S102: and in the testing process of the interface, generating an automatic testing code corresponding to the interface according to the template and the testing data corresponding to the target application.
In the above embodiment, for step S101, during testing, the probe Agent for developing the bytecode enhancement may be deployed into the testing environment along with the application:
1) Test environment: whether an online environment or a test environment, any code developed in Java language must rely on Java virtual machine implementation, JVM (Java VirtualMachine).
2) Application: the testing of the application is mainly also the testing of the application interface, such as the television, and the functional correctness of the application can only be tested through channel switching, volume and the like, and the channel switching, the volume and the like are aimed at the television interface; but the invention does not contemplate implementations within the television such as visualization, signal streaming, etc.
3) Probe Agent: mainly for applications, it has to be started with the application. When an application is started, the start-up parameters of jvm are modified, so that the start-up of the probe can be loaded, as only jvm configuration is modified, and submitted code is not developed, so that it is common to all java applications.
The Agent aims to collect data of the application in the calling/testing process, and the process is necessary, otherwise, automatic testing codes cannot be automatically generated, and certainly, data of non-interface calling can also be collected, for example, the actual user name abcdef and the password 123456 in a login function, and the login function is not an interface.
For example, user a sends the information "hello" to user B, but in its background there is much hidden information, such as the sending address, encryption and decryption information, etc., which are not visible to all users. However, for late writing of automated test code, information that cannot be seen on these pages may be required, and if the computer cannot automatically acquire the automated test code, the automated test code cannot be automatically generated, so that the Agent needs to be relied on to acquire the data.
The Agent acquires the information and makes interception modification to the code of the call interface based on the information. For example, interception may be done before loading class (name of bytecode file) at the time of remote invocation by RPC (Remote Procedure Call Protocol ), modification of bytecode of interface, and replacement of original bytecode file. And, obtaining information such as request path parameters of remote call (for example, after the user clicks the login button, a login request is generated and connected to the background server, where the request includes a user name and a password input by the user), and information such as call result parameters after the call is completed, and finally writing the collected information into a database or sending an asynchronous MQ queue message, which is specifically described with reference to fig. 2.
It should be noted that, unlike code modification in the ordinary sense, the use of the byte code enhancement technique only simulates modification of the code, for example, copying a copy, modifying the code in the copy, and actually the code of the application under test is not modified.
In addition, the probes used may be universal, for example, 1-probe 1, 2-probe 1, or may be provided specifically, for example, 1-probe 1, 2-probe 2.
For step S102, in the process of functional testing, the development Collector dynamically generates automated test codes according to the collected test data and the corresponding templates (e.g., FREEMARKER) to reduce the development cost of the automated test scripts.
Note that the Collector is not included in the agent, and the agent is present for collecting the request information of the developer interface code. After the information is collected, the data needs to be processed according to a Collector, which can be regarded as a data processing center. With particular reference to fig. 3-5.
Taking a login function as an example, when the login encryption mode is out of date and needs to be replaced, the automatic test code can be directly operated without manual test. For the automatic test code generated in the function test process, the meaning of the automatic test code is realized without waiting for the next item/interface change, for example, the user name and the password in the login function are all data scenes, the password of the user name 123 in the manual test is 12, and then 1234 and other combinations can be executed by using the automatic test, so that the aim of the automatic test auxiliary function test is fully reflected.
According to the method provided by the embodiment, the byte code enhancement technology is adopted to acquire the test data in real time, data support is provided for automatically generating the automatic code while testing the function, and when the function test is finished, the automatic code is also automatically finished, so that the code writing cost is reduced.
Referring to fig. 2, a flowchart of an alternative automated test code generation method according to an embodiment of the invention is shown, comprising the steps of:
S201: determining an interface corresponding to the test instruction in the target application, and adding a predetermined code into the test code of the interface based on the probe corresponding to the target application;
S202: running the test code after the interface is changed, and acquiring the input parameters, the output parameters and the parameter types of the interface in the test process based on a preset reflection mode;
s203: and in the testing process of the interface, generating an automatic testing code corresponding to the interface according to the template and the testing data corresponding to the target application.
In the above embodiment, step S203 may refer to the description of step S102 shown in fig. 1, and will not be described herein.
In the above embodiment, for step S201, the probe Agent implemented by the java bytecode enhancement technology intervenes the code initiating the RPC (i.e. the interception and modification of the bytecode), so as to automatically process the tag information, and thus, without modifying the code by a developer, the probe Agent can intercept before loading the class file, thereby implementing the modification of the bytecode.
The following description is needed:
1) RPC-originated code
The test of the application by the tester usually adopts a black box test mode, namely, the tested application is understood as a black box, and the performance of the whole black box is tested only through an interface reserved outside the box, such as a television-external button-tuning key. For the tested application, where the RPC call is initiated, it is the interface that is left outside (the description of the present invention refers only to the external interface of the application, and does not consider the internal interface of the application).
2) Agents modify the code that initiates the PRC:
The byte code enhancement technology can modify any code in java language in principle, but for the test process, the purpose of testing can be realized by modifying only the interface code initiating RPC call, and code modification is not needed in other places where no call occurs. The RPC call is a protocol java code, and to use this protocol, there must be code to implement this block.
In addition, the modification of the interface code is analog modification and is realized in the memory, only a part of codes are added, and other processes such as deletion and the like are not performed, so that the source code is not modified. And this modification is necessary because the applications are all directed to output information.
For step S202, for this added portion of code, this is equivalent to marking the added code with a label, which can be understood as a label.
After marking the code, the source code of the application interface may automatically run the portion of the added code at run-time. The code can help a tester acquire a part of information which cannot be acquired before, such as information of an incoming call and an incoming call type, a call address mode and the like, an outgoing call and an outgoing call type and the like, which are remotely called by the RPC.
Taking shopping cart function test as an example;
1) The user purchases a commodity on the shopping interface, clicks to add the shopping cart, and the shopping cart interface displays that the commodity is stored:
2) For a computer: responding to the operation of clicking the commodity to join the shopping cart by the user, triggering the corresponding interface address to transmit the commodity information of the commodity to the background server as the joining parameter; after receiving the entry, the background server transmits successful information of adding the commodity to the shopping cart to the interface through a series of business processes, and the user can see that the commodity is added to the shopping cart at the interface through the interface address.
3) To automate this process, there must be access to, for example, merchandise information. The automation code automatically triggers the interface address to be sent to the background server through the maintained entry. The background server processes the commodity according to the process that the user joins the commodity to the shopping cart manually, and returns the commodity to the automatic test code, and the automatic test code judges whether joining is successful or not according to the return of the server.
For a similar process, all test cases/test patterns are written as code, so that automated test code can replace manual testing no matter how the background server is modified. Alternatively, it is understood that automated test code simulates the process of manual testing and saves this process for subsequent reuse.
Further, for the acquisition of the data described above, reflection techniques may be relied upon. The reflection technology can be regarded as a function of the java itself to perform self-checking when the application is running, and is mainly used for acquiring the parameter type. Automated testing is mainly to test whether the source code is correct, so the type of source code parameters should be known.
For example, two parameters in the test login function, namely a user name (character type), a password (integer), must be entered when a correct login scenario case is to be sent in an automated test.
According to the method provided by the embodiment, the byte code enhancement technology is adopted, the test data for generating the automatic test code is automatically acquired, a tester does not need to modify the application source code, the test scene collection method parameters are directly involved, and the method solves the problems that in the prior art, when the automatic test code is written, the function test is completed and the data is completely acquired.
Referring to FIG. 3, another alternative automated test code generation method flow diagram according to an embodiment of the invention is shown, comprising the steps of:
S301: determining an interface corresponding to the test instruction in the target application, and collecting test data of the interface in the test process based on a probe corresponding to the target application;
S302: receiving a data deleting instruction, extracting test data corresponding to the data deleting instruction, and executing deleting operation on the extracted test data;
s303: and in the testing process of the interface, generating an automatic testing code corresponding to the interface according to the template and the testing data corresponding to the target application.
In the above embodiment, the step S301 may refer to the description of the step S101 shown in fig. 1, and also refer to the descriptions of the steps S201 and S202 shown in fig. 2, which are not repeated here.
In the above embodiment, for step S302, for the newly added interface, it means an interface in a system or application that has never been tested by the tester, all history information is absent, and the tester needs to start the functional test first.
Also taking shopping cart function test as an example, a tester needs to add some commodities to the shopping cart according to a test method. For example, 10 items of different attributes are prepared, with entities (e.g., clothing), with virtual items (e.g., phone card recharge, etc.), when all 10 items are successfully added to the shopping cart, i.e., indicating that the shopping cart is functioning properly.
According to the Agent, the generated process of calling the interface or the remote is completely stored and warehoused. Also, as an example, after adding a commodity to the shopping cart, whether the addition is successful is determined by querying whether the commodity is stored in the shopping cart, and when all the commodities are added, the test is finished. Through the scheme, the processes of adding the commodity to the shopping cart for 10 times can be recorded, and the required data are reserved. When the automated test code is generated, 10 manual processes of the tester can be simulated by using the test data of the 10 commodities.
For data warehouse entry, a tester can consume the MQ queue message sent by the Agent to show the whole testing process, for example, the functional test generates 20 testing cases for the interface, and then the page shows the testing cases.
It should be noted that:
1) Presentation for test case
Also, in the above example, the functional test is a process of finding an application problem, for example, a problem of the program itself or an operation error of a tester (for example, the application point X but the application point Y) but the background Agent cannot distinguish whether the program itself or an artificial cause when collecting information such as an operation record and operation data of the tester, so that the test data needs to be completely displayed, so that the tester can exclude some invalid cases unrelated to the test, and the cost and time consumption of generating invalid automatic test codes later can be reduced.
In addition, for the presentation of the test data, other forms, such as Excel forms, besides the web page presentation mode, for example, can be adopted, and the invention is mainly presented in the web page mode.
2) Screening for test cases
In practical application testing, errors/repeated cases are usually generated due to factors such as testing environment, and thus the number of cases obtained may be large, for example 20+.
The screening for effective cases is performed manually by the tester. The tester knows which are valid tests and which are invalid tests by himself in the test process, and the meaning of the test is that the tester is also in the test meaning.
The tester can mark the effective test case on the page, and can generate corresponding automatic test codes according to templates (e.g. freemaker, etc.) on the interface according to the marked test case, for example, 20 automatic test codes case are generated according to 20 test cases, and the automatic test codes case are stored for subsequent regression test.
The test case is a generic term for test cases. Taking the login function as an example, at least two test cases-correct user name and password, and incorrect user name and password are required.
The illustrated approach may be applicable to conventional HTTP interfaces, web services, JSF (Java ServerFaces) protocol interfaces, MQ message queue interfaces, database operations, and the like.
For step S303, the automated test code generation process is specifically described with reference to step S102 shown in fig. 1, except that the test data at this time is the screened test data.
According to the method provided by the embodiment, for the display of the test data, a tester can screen the effective data, reject the error or invalid test cases and mark the effective data, so that the availability and reusability of the subsequent automatic test codes are improved.
Referring to FIG. 4, a flowchart of yet another alternative automated test code generation method according to an embodiment of the invention is shown, comprising the steps of:
S401: determining an interface corresponding to the test instruction in the target application, and collecting test data of the interface in the test process based on a probe corresponding to the target application;
S402: based on a preset matching rule, when a matching interface corresponding to the interface exists, taking an automatic test code corresponding to the matching interface as an automatic test code corresponding to the interface; wherein the matching interface does not include the interface;
S402': and when the matching interface corresponding to the interface does not exist, generating an automatic test code corresponding to the interface according to the template and the test data corresponding to the target application.
In the above embodiment, the step S401 may refer to the description of the step S101 shown in fig. 1, and also refer to the descriptions of the steps S201 and S202 shown in fig. 2, which are not repeated here.
In the above embodiment, for step S402, after the Agent is used to collect the test data, an automated test code may be generated for regression testing based on collector, but this is provided that the test data must be generated through functional testing.
But based on interface similarity, corresponding automated test codes can be multiplexed, so that the functional test process can be skipped to a certain extent, and the automated test can be directly entered:
For similar interfaces, for example, interface a has a login function, and interface B also has a login function. For testers, the functions of the two interfaces are required to be completely tested, on the basis, the interfaces can be analyzed for matching similarity, if the interfaces are similar, the stored historical data are directly utilized, and the automatic test codes of related scenes are intelligently generated so as to directly cross the functional test flow, directly perform automatic test, improve the test efficiency and save the test time.
Further, interfaces are generally referred to as content for automated testing, and interfaces are supported by test data/parameters, etc. For matching of the same interface, a form of modifying only part of the code can be used to directly generate:
for example, interface a tests complete and automated test code is generated, then when testing interface B, the difference between the two interfaces is directly modified, perhaps only the address is different externally, and internally implemented algorithm (e.g., encryption algorithm, etc.) tests are not of interest, so that the call address of modifiable a is directly applied to automated test of interface B.
Further, it may be similar to the code, and for the interface A, B, the illustrated method may be a user name and a password, but the background may use a different encryption method or a verification method, and for such similar functions, some parameters, such as address path information, may be replaced.
The matching rules involved in judging whether the interfaces are similar can be as follows:
matching rule 1: the description information of the interface is matched in the form of keywords, and a fuzzy search mode is mainly adopted. For example, interface A-login, user name, password, interface B-login, user name, password;
Matching rule 2: matching through the parameter types and the number of the interfaces:
Taking the login function as an example for illustration, the interface a has two parameters-user name and password, and the other interface C has three parameters-user name, password and expiration date. If the interface to be matched also has three parameters, an automatic test code of the interface C is necessarily selected;
similarly, for a parameter type, for example, the parameter type of the user name in the interface a is a character string type, the type of the user name in the interface C is an integer type, and if the user name of the interface to be matched is also a character string type, the automation test code of the interface a is selected.
Matching rule 3: the floor data (i.e., persistence data) through the interface determines, for example, that the same database table is accessed.
Matching rule 4: the service types and functions of the interfaces are matched, for example, the interface A and the interface B with the same login function are used. The service type of the interface can be preset, and is also judged on line or customized by a tester.
It should be noted that, the matching rules include, but are not limited to, the above rules, and the number may be increased at any time. For the matching rule, one of the matching rules can be selected for matching, and 2 or even more matching rules can be selected, and the matching rules are specifically selected according to actual needs. When the number of the selected matching rules is large, the matching can be performed in a step-by-step screening mode, and the interface matching accuracy is improved.
For the determination of the matching interface, it is not determined by a matching rule, and therefore, the process also needs to rely on the information of the parameter type, number, etc. of the test data in step S402.
Also taking the login function as an example, if the matching key word can match both interfaces, then fine calibration is performed through other rules. However, when the number of the finally determined matching interfaces is large, for example, two, one may be randomly selected as the matching interface.
In addition, the matching accuracy gradually improves with the accumulation of the use time. In the initial stage, the number of test data and automatic codes is small, and the matching probability is probably zero; however, as the use time increases, the number of automation codes increases gradually, so that the probability of meeting the corresponding matching rule is also increased. Theoretically, the automatic generation of automatic test codes can be omitted when the data amount in the database is accumulated to a certain extent, because all business scenes are covered in the database, and although the method is an ideal state, the more information amount in the database is, the more accurate the opportunity of meeting the matching rule is.
For intelligent matching, the cost of automatic code writing is low, other similar interface functions are directly used for automatic testing, and a functional testing part is skipped, so that the efficiency of the whole testing process is greatly improved.
For step S402', when no matching interface is present, automated test code may still be generated based on the test data and templates in the manner shown in fig. 1.
According to the method provided by the embodiment, for similar requests or business logics, the required automatic test codes are directly generated according to the historical automatic test codes in a rule matching mode, multiplexing of the automatic test codes is achieved, the purpose of intelligently skipping functional test steps and directly executing the automatic test cases is achieved, and a foundation is provided for subsequent artificial intelligence.
Referring to FIG. 5, a flowchart of yet another alternative automated test code generation method according to an embodiment of the invention is shown, comprising the steps of:
S501: determining an interface corresponding to the test instruction in the target application, and collecting test data of the interface in the test process based on a probe corresponding to the target application;
S502: in the testing process of the interface, generating an automatic testing code corresponding to the interface according to a template and testing data corresponding to the target application;
S503: receiving a change instruction of the automatic test code, and changing the test data based on the change data in the change instruction;
S504: and regenerating an automatic test code corresponding to the interface based on the changed test data and the template.
In the above embodiment, the step S501 may refer to the description of the step S101 shown in fig. 1, and also refer to the descriptions of the steps S201 and S202 shown in fig. 2, and the step S502 may refer to the description of the step S102 shown in fig. 1, which is not repeated here.
In the above embodiment, for steps S503 and S504, the test data may be stored in the database in real time, so that the search for the whole test process in the later stage is convenient.
If the application under test is functionally changed and the content of the change is large, the previously generated automated test code also needs to be changed. For the automatic test codes with changing requirements, the test data can be directly modified, the automatic test codes can be regenerated, and maintenance of the original automatic test codes is reduced.
For example, the old television has no remote controller, the test is completed based on the television button, the remote controller is changed now, the corresponding automatic test code is transferred to the remote controller, but the functions of the television button and the buttons on the remote controller are the same, for example, channel changing/volume adjusting and the like, namely, regeneration/modification of the automatic test code can be realized by modifying only a part of data, and the method is quick and convenient.
The method provided by the embodiment is convenient for the later dynamic maintenance and updating of the automatic test code for the storage of the test data, greatly reduces the maintenance cost of the automatic test code and reduces the debugging and maintenance time of the code.
The method provided by the embodiment of the invention can greatly improve the coverage rate of the automatic test code, assist the function test efficiency and ensure the test quality based on the thought that the automatic test code is automatically generated while the function is tested; based on the intelligent matching thought, an automatic test code can be intelligently generated; and for the preservation of test data, the subsequent updating and debugging of the automatic test code are facilitated, and the maintenance cost is reduced.
Referring to fig. 6, a schematic diagram of main modules of an automated test code generating apparatus 600 according to an embodiment of the present invention is shown, including:
the data acquisition module 601 is configured to determine an interface corresponding to a test instruction in a target application, and acquire test data of the interface in a test process based on a probe corresponding to the target application;
the code generating module 602 is configured to generate an automated test code corresponding to the interface according to the template and the test data corresponding to the target application during the test of the interface.
In the implementation device, the probe is generated based on a byte code enhancement mode;
A data acquisition module 601, configured to: based on the probe, adding a predetermined code to the test code of the interface; and running the test code after the interface is changed, and acquiring the input parameters, the output parameters and the parameter types of the interface in the test process based on a preset reflection mode.
In the embodiment of the present invention, the data acquisition module 601 is configured to: and receiving a data deleting instruction, extracting test data corresponding to the data deleting instruction, and executing deleting operation on the extracted test data.
In the implementation device of the present invention, the code generation module 602 is further configured to:
Based on a preset matching rule, when a matching interface corresponding to the interface exists, taking an automatic test code corresponding to the matching interface as an automatic test code corresponding to the interface; wherein the matching interface does not include an interface; or (b)
And when the matching interface corresponding to the interface does not exist, generating an automatic test code corresponding to the interface according to the template and the test data.
In the implementation device of the present invention, the code generation module 602 is configured to:
Acquiring description information of an interface, extracting keywords conforming to a preset keyword extraction rule from the description information, and determining the interface corresponding to the keywords as a matching interface; and/or
Acquiring the parameter types and the parameter numbers of the interfaces, and determining the interfaces corresponding to the parameter types and/or the parameter numbers as matching interfaces; and/or
Acquiring landing data of an interface, and taking the interface which is in the same database table as the landing data as a matching interface; and/or
And determining the service type of the interface, and taking the interface which is the same as the service type as a matching interface.
The implementation device of the present invention further includes a code changing module 603 (not shown in the figure) for: receiving a change instruction of the automatic test code, and changing the test data based on the change data in the change instruction; and regenerating an automatic test code corresponding to the interface based on the changed test data and the template.
In addition, the specific implementation of the automated test code generating device according to the embodiment of the present invention is described in detail in the automated test code generating method described above, and thus the description thereof will not be repeated here.
The device provided by the embodiment of the invention automatically generates the thought of the automatic test code based on the simultaneous function test, can greatly improve the coverage rate of the automatic test code, can assist the function test efficiency and ensures the test quality; based on the intelligent matching thought, an automatic test code can be intelligently generated; and for the preservation of test data, the subsequent updating and debugging of the automatic test code are facilitated, and the maintenance cost is reduced.
FIG. 7 illustrates an exemplary system architecture 700 to which an automated test code generation method or apparatus of embodiments of the invention may be applied.
As shown in fig. 7, a system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705 (by way of example only). The network 704 is the medium used to provide communication links between the terminal devices 701, 702, 703 and the server 705. The network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
A user may interact with the server 705 via the network 704 using the terminal devices 701, 702, 703 to receive or send messages or the like. Various communication client applications such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only) may be installed on the terminal devices 701, 702, 703.
The terminal devices 701, 702, 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.
The server 705 may be a server providing various services, such as a background management server (by way of example only) providing support for shopping-type websites browsed by users using the terminal devices 701, 702, 703. The background management server may analyze and process the received data such as the product information query request, and feedback the processing result (e.g., the target push information, the product information—only an example) to the terminal device.
It should be noted that, the method for generating an automated test code according to the embodiment of the present invention is generally executed by the server 705, and accordingly, the automated test code generating device is generally disposed in the server 705.
It should be understood that the number of terminal devices, networks and servers in fig. 7 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 8, there is illustrated a schematic diagram of a computer system 800 suitable for use in implementing an embodiment of the present invention. The terminal device shown in fig. 8 is only an example, and should not impose any limitation on the functions and the scope of use of the embodiment of the present invention.
As shown in fig. 8, the computer system 800 includes a Central Processing Unit (CPU) 801 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to the bus 804.
The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, mouse, etc.; an output portion 807 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 808 including a hard disk or the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. The drive 810 is also connected to the I/O interface 805 as needed. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as needed so that a computer program read out therefrom is mounted into the storage section 808 as needed.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure 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 flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication section 809, and/or installed from the removable media 811. The above-described functions defined in the system of the present invention are performed when the computer program is executed by a Central Processing Unit (CPU) 801.
The computer readable medium shown in the present invention 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 the context of this document, 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. In the present invention, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the 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: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
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 invention. 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 or flowchart illustration, and combinations of blocks in the block diagrams 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 modules involved in the embodiments of the present invention may be implemented in software or in hardware. The described modules may also be provided in a processor, for example, as: a processor comprises a data acquisition module, a code generation module and an acquisition module. Where the names of the modules do not constitute a limitation on the module itself in some cases, for example, the code generation module may also be described as an "automated test code generation module".
As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to include:
determining an interface corresponding to a test instruction in a target application, and collecting test data of the interface in a test process based on a probe corresponding to the target application;
And in the process of testing the interface, generating corresponding automatic test codes according to the templates corresponding to the target application and the test data.
According to the technical scheme of the embodiment of the invention, the idea of automatically generating the automatic test code based on the function test can greatly improve the coverage rate of the automatic test code, assist the function test efficiency and ensure the test quality; based on the intelligent matching thought, an automatic test code can be intelligently generated; and for the preservation of test data, the subsequent updating and debugging of the automatic test code are facilitated, and the maintenance cost is reduced.
The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.