Automatic testing method and device, equipment and storage medium
Through automated testing methods, COBOL monomers are tested using test case parameter scripts, which solves the problem of low automation testing efficiency in the existing technology, realizes an efficient and automated testing process, and improves product quality.
Patent Information
- Application Number
- CN202411584286.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-07
- Publication Date
- 2025-02-14
AI Technical Summary
The prior art is less efficient when performing automated testing of COBOL monomers, and requires manual scripting, resulting in complexity and inefficiency.
It provides an automated testing method, which obtains the program identification and target test case of the program to be tested by responding to the execution instructions of the target test task, and tests the program to be tested based on the test case parameter script to obtain test results. Test case parameter scripts include program identification, test input data and test premise data, without manual scripting.
On the basis of ensuring the quality of the test, it effectively improves the efficiency of the test work, simplifies the test process, reduces manual intervention, and thus helps improve product quality.
Smart Images
Figure CN119441053A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the financial field, and in particular to an automated testing method, device, equipment and storage medium. Background Art
[0002] COBOL is a high-level, process-oriented programming language that is primarily used for data processing, such as in the development of financial systems. COBOL monoliths refer to monolithic applications written in COBOL.
[0003] Currently, COBOL monomers are usually tested automatically by manually writing scripts, which results in low efficiency. Therefore, an effective solution for automated testing of COBOL monomers is urgently needed. Summary of the invention
[0004] The embodiments of the present application provide an automated testing method, apparatus, device and storage medium, which are used to provide an effective solution for automated testing of COBOL monomers.
[0005] In a first aspect, the present application provides an automated testing method for COBOL unit testing, the automated testing method comprising:
[0006] In response to an execution instruction for a target test task, obtaining a program identifier of a program to be tested corresponding to the target test task;
[0007] Obtaining a target test case corresponding to the program to be tested, the target test case including test input data, test expected output data and test premise data;
[0008] The program to be tested is tested based on the test case parameter script corresponding to the target test case to obtain the test result. The test case parameter script is generated according to the target test case, and the test case parameter script includes a program identifier, test input data and test premise data.
[0009] In one possible implementation, a program to be tested is tested based on a test case parameter script corresponding to a target test case to obtain a test result, including: parsing the test case parameter script to obtain a program identifier, test input data, and test premise data of the program to be tested; calling the program to be tested according to the program identifier, and inputting the test input data and test premise data into the program to be tested, testing the program to be tested, and obtaining a test result.
[0010] In a possible implementation, the target test case may further include a target intermediate data structured query language SQL, which is used to execute the target intermediate data SQL when testing the program to be tested to obtain query results of associated data tables in the program to be tested.
[0011] In a possible implementation, the data type of the test premise data includes at least one of a premise test case, an SQL premise data script, and a simulation program.
[0012] In one possible implementation, before responding to an execution instruction for a target test task, the automated testing method further includes: in response to an import operation for an input file corresponding to the test input data, obtaining test input data; in response to an import operation for a format file corresponding to output data of the program to be tested, obtaining a target format corresponding to the output data.
[0013] In a possible implementation, after obtaining the test results, the automated testing method further includes: comparing the test results with the expected test output data, and determining whether the test results are correct based on the comparison results; if the test results are correct, generating a record sheet; if the test results are incorrect, generating a problem sheet.
[0014] In a possible implementation, the automated testing method further includes at least one of the following: in response to a configuration operation for a target test plan, generating a target test plan according to a preset test plan template; in response to a configuration operation for a target test task, obtaining a target test task, the target test task corresponding to a program to be tested and a target test case; in response to a configuration operation and / or an import operation on a target test case, obtaining a target test case; based on the test results, generating a test report; and based on the test results, counting code coverage.
[0015] In a second aspect, the present application provides an automated testing device for COBOL unit testing, the automated testing device comprising:
[0016] A first acquisition module, configured to acquire a program identifier of a program to be tested corresponding to a target test task in response to an execution instruction for the target test task;
[0017] The second acquisition module is used to acquire a target test case corresponding to the program to be tested, where the target test case includes test input data, test expected output data and test premise data;
[0018] The test module is used to test the program to be tested based on the test case parameter script corresponding to the target test case to obtain the test result. The test case parameter script is generated according to the target test case, and the test case parameter script includes program identification, test input data and test premise data.
[0019] In one possible implementation, the test module is specifically used to: parse the test case parameter script to obtain the program identifier, test input data and test premise data of the program to be tested; call the program to be tested according to the program identifier, and input the test input data and test premise data into the program to be tested, test the program to be tested, and obtain test results.
[0020] In a possible implementation, the target test case may further include a target intermediate data structured query language SQL, which is used to execute the target intermediate data SQL when testing the program to be tested to obtain query results of associated data tables in the program to be tested.
[0021] In a possible implementation, the data type of the test premise data includes at least one of a premise test case, an SQL premise data script, and a simulation program.
[0022] In a possible implementation, the first acquisition module is also used to: acquire test input data in response to an import operation of an input file corresponding to the test input data before an execution instruction for a target test task; and acquire a target format corresponding to the output data in response to an import operation of a format file corresponding to the output data of the program to be tested.
[0023] In one possible implementation, the test module is also used to: after obtaining the test results, compare the test results with the expected test output data, and determine whether the test results are correct based on the comparison results; if the test results are correct, generate a record sheet; if the test results are incorrect, generate a problem sheet.
[0024] In a possible embodiment, the automated testing device also includes a processing module, which is used for at least one of the following: generating a target test plan according to a preset test plan template in response to a configuration operation for a target test plan; obtaining a target test task in response to a configuration operation for a target test task, the target test task corresponding to a program to be tested and a target test case; obtaining a target test case in response to a configuration operation and / or an import operation on a target test case; generating a test report based on the test results; and calculating code coverage based on the test results.
[0025] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;
[0026] Memory stores computer-executable instructions;
[0027] The processor executes the computer-executable instructions stored in the memory to implement the above first aspect and / or various possible implementations of the first aspect.
[0028] In a fourth aspect, the present application provides a computer-readable storage medium, in which computer program instructions are stored. When the computer program instructions are executed, the above first aspect and / or various possible implementation methods of the first aspect are implemented.
[0029] In a fifth aspect, the present application provides a computer program product, including a computer program, which implements the above first aspect and / or various possible implementation methods of the first aspect when the computer program is executed.
[0030] The automated testing method, apparatus, device and storage medium provided by the present application obtain the program identifier of the program to be tested corresponding to the target test task by responding to the execution instruction for the target test task; obtain the target test case corresponding to the program to be tested, the target test case includes test input data, test expected output data and test premise data; test the program to be tested based on the test case parameter script corresponding to the target test case to obtain the test result. Among them, the test case parameter script is generated according to the target test case, and the test case parameter script includes the program identifier of the program to be tested, test input data and test premise data, without the need to manually write scripts, that is, there is no need to learn complex rule processes and no need to learn to write scripts. Therefore, when performing automated testing on COBOL monomers, the present application can effectively improve the test work efficiency on the basis of ensuring the test quality, thereby helping to improve product quality. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0032] Figure 1 A schematic diagram of an application scenario provided for an embodiment of the present application;
[0033] Figure 2 Schematic diagram of the process of the automated testing method provided in the embodiment of the present application Figure 1 ;
[0034] Figure 3 A schematic diagram of a configuration interface for a test task provided in an embodiment of the present application;
[0035] Figure 4 A schematic diagram of a configuration interface for a test case provided in an embodiment of the present application;
[0036] Figure 5 Schematic diagram of the process of the automated testing method provided in the embodiment of the present application Figure 2 ;
[0037] Figure 6 A schematic diagram of the structure of an automated testing device provided in one embodiment of the present application;
[0038] Figure 7 A schematic diagram of an automated testing system provided in one embodiment of the present application;
[0039] Figure 8 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application.
[0040] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION
[0041] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.
[0042] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards, and provide corresponding operation entrances for users to choose to authorize or refuse.
[0043] First, the terms involved in this application are explained:
[0044] Common Transaction Format (CTF), used to define all input variables of the program;
[0045] Standard Input Area (SIA), which is used to define the input data format data structure for each transaction;
[0046] Output format definition file (TFORM) is used to define the data structure of the output data format of the transaction.
[0047] COBOL is a process-oriented high-level programming language mainly used for data processing, such as in the development of financial systems.
[0048] COBOL Monolith refers to a monolithic application written in COBOL language.
[0049] Automated Unit Test System (AUTS) is a system or framework for automated unit testing, which is used to perform automated testing on COBOL monomers.
[0050] At present, when testing COBOL monomers, they are usually automated by manually writing scripts, which leads to low efficiency. Considering the large number of tasks in each batch and the increasing requirements for product quality, an effective solution for automated testing of COBOL monomers is urgently needed.
[0051] Based on the above problems, the present application provides an automated testing method, apparatus, device and storage medium. When executing a target test task, based on the target test case corresponding to the program to be tested associated with the target test task, a test case parameter script corresponding to the target test case is automatically generated, so that the program to be tested is tested based on the test case parameter script to obtain a test result. Among them, the test case parameter script includes the program identifier, test input data and test premise data of the program to be tested, without the need to learn cumbersome rule processes and without the need to learn to write scripts, which can effectively improve the efficiency of testing work and thus help improve product quality.
[0052] It should be noted that the automated testing method, device, equipment and storage medium of the present application can be used in the financial field, and can also be used in any field other than the financial field. The application field of the automated testing method, device, equipment and storage medium of the present application is not limited.
[0053] In the following, the application scenarios of the solutions provided in this application are first illustrated.
[0054] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of the present application. Figure 1 As shown, in this application scenario, the developer configures the target test task for the target COBOL monomer through the client 101, and accordingly, the server 102 obtains the target test task. The server 102 executes the target test task through the automated testing method provided by the present application, thereby realizing automated testing of the program to be tested (target COBOL monomer) corresponding to the target test task.
[0055] It should be noted that Figure 1 This is only a schematic diagram of an application scenario provided by the embodiment of the present application. Figure 1 does not limit the equipment included in Figure 1 The positional relationship between the devices is limited.
[0056] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.
[0057] Figure 2 Schematic diagram of the process of the automated testing method provided in the embodiment of the present application Figure 1 , used for COBOL unit testing. The method of the embodiment of the present application can be applied to an electronic device, which can be a server or a server cluster. Figure 2 As shown, the method of the embodiment of the present application includes:
[0058] S201 . In response to an execution instruction for a target test task, obtain a program identifier of a program to be tested corresponding to the target test task.
[0059] In the embodiment of the present application, the execution instruction for the target test task can be input by the user to the electronic device executing the embodiment of the present method, or the electronic device executing the embodiment of the present method is triggered according to the configured execution date of the target test task. Different test tasks can be pre-configured so that the target test task can be selected for execution, and one or more target test tasks can be executed at the same time to realize batch automated testing.
[0060] Optionally, in response to a configuration operation for a target test task, the target test task is acquired, and the target test task corresponds to a program to be tested and a target test case.
[0061] For example, Figure 3 A schematic diagram of a configuration interface for a test task provided in an embodiment of the present application is shown in FIG. Figure 3 As shown, you can configure the task number of the target test task and the execution date of automatic execution. You can select the program to be tested (such as program 1) and the target test case (such as test case 1) corresponding to the program to be tested by checking the boxes. Among them, it supports full selection, query and partial test case selection by program. After configuring the target test task (that is, creating a new target test task), you can query the target test task, modify the target test task, or delete the target test task, etc.
[0062] In this step, when an execution instruction for a target test task is received, a program identifier of a program to be tested corresponding to the target test task is obtained, where the program to be tested is a COBOL monomer to be tested.
[0063] S202: Obtain a target test case corresponding to the program to be tested, where the target test case includes test input data, test expected output data, and test premise data.
[0064] In this step, after obtaining the program to be tested corresponding to the target test task, the target test case corresponding to the program to be tested can be obtained. It can be understood that the target test task is associated with the target test case (including the joint selection of test premise data, test expected output data, etc.), and the target test cases under the target test task can be combined to define the execution sequence of the target test cases, thereby forming a test component relationship for system assembly testing. Among them, the test input data and test premise data corresponding to the target test case are used as the input of the program to be tested, and the test expected output data corresponding to the target test case is used to compare with the output of the program to be tested (i.e., to compare the test results) to determine whether the test results are correct.
[0065] Optionally, the input data format and the output data format may be preconfigured.
[0066] Exemplarily, taking bank transactions as an example, the transaction format can be configured to prepare for the formatting of the test case parameter script. For example, CTF files, standard input format (SIF) files / standard output format (SOF) files, TFORM COPYBOOK (a file for defining data structures and fields in COBOL programs), etc. can be imported into the electronic device that executes the embodiment of the present method, and the input data format and output data format of the transaction are automatically parsed and generated. In addition, the electronic device that executes the embodiment of the present method can also be imported through detailed design, and the transaction format customization is automatically parsed and generated, wherein the detailed design is, for example, a detailed design of a customized EXECL (a tool for organizing and processing data) version. Optionally, the SIA file of the transaction product can also be imported to dynamically generate an input interface when creating a test case, which can be used to obtain the test input data of the test case. Optionally, the TFORM file of the transaction product can also be imported so that after executing the test case, the output data can be displayed in TFORM format instead of returning data without format.
[0067] For the target test case, optionally, in response to a configuration operation and / or an import operation on the target test case, the target test case is obtained.
[0068] Exemplarily, if a test case has been written according to a test case template, the test case can be imported into the AUTS system. After importing the test case, the CTF and TFORM information of each test case can be maintained. Alternatively, the test case can be directly created in the AUTS system, wherein the test case includes a target test case, so that the target test case can be obtained. After the test case is created, the test case can be queried, modified or deleted. Optionally, redundant test cases can be deleted based on an intelligent duplication discrimination function (such as whether the test input data of the test case is the same), and redundant test cases can be deleted in batches.
[0069] Optionally, the target test case may also include a target intermediate data structured query language (Structured Query Language, SQL), which is used to execute the target intermediate data SQL when testing the program to be tested to obtain query results of associated data tables in the program to be tested.
[0070] Exemplarily, for the associated data table in the program to be tested, a target intermediate data SQL can be set, and after executing the target intermediate data SQL, the query result of the associated data table in the program to be tested can be obtained. For example, if the target intermediate data SQL is a select statement of intermediate data, after executing the statement, the query result of the associated data table to be queried can be obtained, without the need to perform the query through PL / SQL (a procedural programming language).
[0071] Optionally, the data type of the test premise data includes at least one of a premise test case, an SQL premise data script, and a simulation program.
[0072] For example, Figure 4 A schematic diagram of a configuration interface for a test case provided in an embodiment of the present application is shown in FIG. Figure 4 As shown, the data type of the test premise data of the test case (i.e. Figure 4 The premise data types in the example include at least one of premise test cases, SQL premise data scripts, and simulation programs. The test premise data may be data obtained by executing premise test cases (i.e., executing premise test cases before executing current test cases), or data obtained by executing SQL premise data scripts (i.e., SQL premise data scripts based on data table SQL, providing dynamic SQL premise data script customization), or data obtained by executing simulation programs. The SQL premise data scripts may also be exported for subsequent writing of SQL premise data scripts. Figure 4 Other information of the test case can be filled in or imported according to the actual test case.
[0073] In addition, you can also repeatedly execute test cases by setting up SQL for the underlying data; if the SQL premise data script contains an insert statement for the test premise data, you can lay the data before executing the test case. If the insert data already exists, update all the information of the data. In this way, you can repeatedly execute the test case without modifying the original data status and other information.
[0074] Optionally, the data items in the test input data, test premise data and test expected output data of the test case can be replaced in batches; further, automatic replacement of specific data items according to customized strategies is provided, for example, non-repeating serial numbers, dates, and data items obtained through premise data (such as automatically compiled business numbers), etc., after replacement, a new test case is formed without changing the original test case content. After the data items in the test case are replaced, the test premise data and test expected output data are automatically adapted to the replacement. The execution time and execution order of the test case can be configured, so that it can be automatically executed in a certain conditional order (such as executing business transactions first and query transactions later) or the execution order can be freely selected, supporting multi-test task parallel mode. After the interface format of the program to be tested is changed, the test case data is expanded (including the expansion of test expected output data, test premise data, etc.), for example, a data item is added to the input interface of the program to be tested, and the associated test expected output data, etc. are all changed. Batch changes (such as by program, transaction) are supported, and test case debugging is required after the change. After the interface format of the program to be tested is changed, the test case distribution is automatically checked. For example, the case distribution can be checked according to the changed transaction data value table (used to record each transaction-related data), and the test cases of the uncovered test input data combinations are supplemented.
[0075] S203, testing the program to be tested based on the test case parameter script corresponding to the target test case to obtain a test result, wherein the test case parameter script is generated according to the target test case, and the test case parameter script includes a program identifier of the program to be tested, test input data, and test premise data.
[0076] In this step, after obtaining the target test case corresponding to the program to be tested, the program to be tested can be tested based on the test case parameter script corresponding to the target test case to obtain the test result. Among them, the test case parameter script is generated according to the target test case. Exemplarily, taking bank transactions as an example, referring to the example of step S202, after automatically parsing and generating the input data format and output data format of the transaction, the test case script EXECL template (which can be filled in manually and supplemented with data) can be exported according to the transaction. If there is a sub-transaction data value table (after activation), a template with data is generated; if there is no sub-transaction data value table, an empty template is generated. The sub-transaction data value table can be generated according to the detailed design (customized EXECL version). According to the sub-transaction data value table, a random test case script is generated, that is, a test case parameter script is generated. For example, various test input data can be enumerated according to the test input data, and various test input data can be arranged and combined to generate a test case parameter script. Optionally, the test case parameter script can be imported into the test case library system (AUTS system) for unified management.
[0077] Optionally, the test case parameter script generates data as a test case for the test premise data, supports the test case parameter script as the premise data script, and needs to add the associated test case number and execution order and other contents in the test case parameter script.
[0078] In this step, illustratively, based on the test case parameter script corresponding to the target test case, an online test simulation tool can be used in the form of an external JAVA (an object-oriented programming language) system, and the background program to be tested can be called in a configured transaction format through an external call interface (ECI) call (CALL) to test the program to be tested and obtain the test result. After obtaining the test result, the test result can be compared with the test expected output data of the target test case, and whether the test result is correct can be determined based on the comparison result. If the test result is correct, a record sheet is generated; if the test result is incorrect, a problem sheet is generated. Optionally, a case sheet, a record sheet and a problem sheet can also be exported. Optionally, the target test case, the test prerequisite data of the target test case and the test result and other information can also be recorded to generate a case sheet. Optionally, a single test case debugging function can also be provided, and the test case execution result needs to be predetermined in advance.
[0079] The automated testing method provided in the embodiment of the present application obtains the program identifier of the program to be tested corresponding to the target test task by responding to the execution instruction for the target test task; obtains the target test case corresponding to the program to be tested, the target test case includes test input data, test expected output data and test premise data; tests the program to be tested based on the test case parameter script corresponding to the target test case to obtain the test result. Among them, the test case parameter script is generated according to the target test case, and the test case parameter script includes the program identifier of the program to be tested, test input data and test premise data, without the need to manually write scripts, that is, there is no need to learn complex rule processes and no need to learn to write scripts. Therefore, when performing automated testing on COBOL monomers, the embodiment of the present application can effectively improve the test work efficiency on the basis of ensuring the test quality, thereby helping to improve product quality.
[0080] Figure 5 Schematic diagram of the process of the automated testing method provided in the embodiment of the present application Figure 2 Based on the above embodiments, the present application further describes the automated testing method. Figure 5 As shown, the method of the embodiment of the present application may include:
[0081] S501 . In response to an import operation on an input file corresponding to test input data, obtain test input data.
[0082] Exemplarily, taking bank transactions as an example, referring to the example of step S202, the SIA file of the transaction product can be imported, so that the test input data can be obtained to dynamically generate the input interface when creating the test case.
[0083] S502: In response to an import operation of a format file corresponding to output data of the program to be tested, a target format corresponding to the output data is obtained.
[0084] For example, taking bank transactions as an example, referring to the example of step S202, the TFORM file of the transaction product can be imported, so that the target format corresponding to the output data can be obtained, so that after executing the test case, the output data can be displayed in the TFORM format instead of returning the data without format. It can be understood that the maintenance of SIA files and TFORM files in AUTS system management only needs to be maintained when a new program is added.
[0085] It should be noted that the embodiment of the present application does not limit the order in which steps S501 and S502 are executed.
[0086] S503: In response to an execution instruction for a target test task, obtain a program identifier of a program to be tested corresponding to the target test task.
[0087] The detailed description of this step can be found in Figure 2 The relevant description of S201 in the illustrated embodiment will not be repeated here.
[0088] S504: Obtain a target test case corresponding to the program to be tested, where the target test case includes test input data, test expected output data, and test premise data.
[0089] The detailed description of this step can be found in Figure 2 The relevant description of S202 in the illustrated embodiment will not be repeated here.
[0090] In the embodiment of the present application, Figure 2 The step S203 may further include the following two steps S505 and S506:
[0091] S505. Parse the test case parameter script corresponding to the target test case to obtain the program identifier, test input data and test premise data of the program to be tested. The test case parameter script is generated according to the target test case, and the test case parameter script includes the program identifier, test input data and test premise data of the program to be tested.
[0092] Exemplarily, the test case parameter script includes the program identifier, test input data and test premise data of the program to be tested. Therefore, the test case parameter script can be parsed to obtain the program identifier, test input data and test premise data of the program to be tested.
[0093] S506 , calling the program to be tested according to the program identifier, and inputting the test input data and the test premise data into the program to be tested, testing the program to be tested, and obtaining the test result.
[0094] In this step, after obtaining the program identifier, test input data and test premise data of the program to be tested, the program to be tested can be called according to the program identifier, and the test input data and test premise data can be input into the program to be tested, and the program to be tested is tested to obtain the test results.
[0095] S507: Compare the test result with the test expected output data, and determine whether the test result is correct based on the comparison result.
[0096] Exemplarily, after obtaining the test results, the return code and return information contained in the test results can be filled in according to the downloaded template, the filled return code and return information can be uploaded through the script, the return code and return information can be compared with the expected test output data, and whether the test results are correct can be determined based on the comparison results. Among them, the key data items (for example, for maintenance and transformation tasks, the changed data items are mainly checked), and the check data items can be checked through SQL scripts. In addition, the external interface verification results, such as account balances, can also be obtained. If the test result is correct, execute step S508; if the test result is incorrect, execute step S509.
[0097] S508. If the test result is correct, a record sheet is generated.
[0098] In this step, if the test result is correct, a record sheet is generated.
[0099] S509: If the test result is incorrect, a problem ticket is generated.
[0100] In this step, if the test result is incorrect, a problem ticket is generated. Optionally, a single test case debugging function can also be provided, and the test case execution result needs to be predetermined in advance.
[0101] In addition, you can also record information such as target test cases, test prerequisite data and test results to generate case sheets. You can also export case sheets, record sheets and problem sheets of test execution results and import them into the test library corresponding to the product in EXECL file format.
[0102] The automated testing method provided by the embodiment of the present application obtains test input data in response to an import operation of an input file corresponding to the test input data, and obtains a target format corresponding to the output data in response to an import operation of a format file corresponding to the output data of the program to be tested; obtains a program identifier of the program to be tested corresponding to the target test task in response to an execution instruction for a target test task; obtains a target test case corresponding to the program to be tested, the target test case including test input data, test expected output data and test premise data; parses a test case parameter script corresponding to the target test case to obtain a program identifier, test input data and test premise data of the program to be tested; calls the program to be tested according to the program identifier, and inputs the test input data and the test premise data into the program to be tested, tests the program to be tested, and obtains a test result. Among them, the test case parameter script is generated according to the target test case, and the test case parameter script includes the program identifier of the program to be tested, the test input data and the test premise data, so that automated testing can be performed by only importing the input file corresponding to the test input data and the format file corresponding to the output data of the program to be tested, without the need to manually write scripts, that is, there is no need to learn complex rule processes and no need to learn to write scripts. Therefore, when performing automated testing on COBOL monomers, the embodiments of the present application can effectively improve the test work efficiency while ensuring the test quality, thereby helping to improve product quality.
[0103] Based on the above embodiments, optionally, the automated testing method provided in the embodiments of the present application may also include at least one of the following: generating a target test plan according to a preset test plan template in response to a configuration operation for the target test plan; generating a test report based on the test results; and calculating code coverage based on the test results.
[0104] Exemplarily, in response to the configuration operation for the target test plan, the target test plan can be generated through a predefined test plan template (i.e., a preset test plan template), and the program completion list can be exported. Among them, the preset test plan template is, for example, a template customized according to the product. A test report template can be generated by statistics of case sheets, record sheets, problem sheets, etc., and combined with the relevant content in the preset test plan template (such as a template customized according to the product), and then a test report can be generated based on the test report template. After the test report is generated, the test report can be exported. Code coverage can be counted based on the test results, wherein production version control needs to be noted; specifically, the program to be tested can be analyzed, and signals such as logs can be automatically added to the branch of the program to be tested, automatically compiled, updated, and effective, and the execution order of the program to be tested can be recorded during the execution process to evaluate the code coverage; the branch definition of the program to be tested can be customized, and a flexible customization strategy can be adopted; for the test task of the original function change, the code coverage check is mainly for the modified code (adding the program comment part before modifying the code) and the program branch where it is located, and the evaluation result is only for the changed part.
[0105] Based on the above embodiment, optionally, the transaction log may be automatically extracted.
[0106] For example, through the transaction log, test cases and test result comparisons (test return information part) and other contents are automatically extracted; the data in the transaction log is bleached, and sensitive data is replaced or cleared; the transaction log import function of each business system is supported, and after import, it is converted into the transaction log temporary data table of the AUTS system.
[0107] On the basis of the above-mentioned embodiment, optionally, for the external system test stub (backend function), a class interface simulation can be returned to support customized processing of specified return codes and return information of the test case; the interface can be read through a message queue (MQ), for example; and one-way external system simulation can also be performed.
[0108] In summary, the technical solution provided by this application has at least the following advantages:
[0109] (1) Ease of use: There is no need to learn complicated rule processes or script writing. You only need to import input files (such as SIA files) and output files (such as TFORM files) to create test cases for testing. During the testing process, you can accumulate test cases to form a test case library.
[0110] (2) Practicality: It can realize batch automated testing, automatically compare test results, and export case sheets, record sheets, problem sheets, and test reports to improve test efficiency and quality.
[0111] (3) Adaptability: Through configuration, simple maintenance parameters can meet changes in the environment and data.
[0112] For developers, each file can be customized based on the automated testing method and environmental information provided in the embodiments of the present application.
[0113] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.
[0114] Figure 6 This is a schematic diagram of the structure of an automated testing device provided in an embodiment of the present application, which is used for COBOL unit testing. Figure 6 As shown, the automated testing device 600 of the embodiment of the present application includes: a first acquisition module 601, a second acquisition module 602 and a testing module 603. Among them:
[0115] The first acquisition module 601 is used to acquire the program identifier of the to-be-tested program corresponding to the target test task in response to the execution instruction for the target test task.
[0116] The second acquisition module 602 is used to acquire a target test case corresponding to the program to be tested, where the target test case includes test input data, test expected output data and test premise data.
[0117] The test module 603 is used to test the program to be tested based on the test case parameter script corresponding to the target test case to obtain the test result. The test case parameter script is generated according to the target test case, and the test case parameter script includes a program identifier, test input data and test premise data.
[0118] In some embodiments, the test module 603 can be specifically used to: parse the test case parameter script to obtain the program identifier, test input data and test premise data of the program to be tested; call the program to be tested according to the program identifier, and input the test input data and test premise data into the program to be tested, test the program to be tested, and obtain test results.
[0119] Optionally, the target test case may further include target intermediate data SQL, which is used to execute the target intermediate data SQL when testing the program to be tested to obtain query results of associated data tables in the program to be tested.
[0120] In some embodiments, the data type of the test premise data includes at least one of a premise test case, an SQL premise data script, and a simulation program.
[0121] Optionally, the first acquisition module 601 can also be used to: acquire test input data in response to an import operation of an input file corresponding to the test input data before an execution instruction for a target test task; acquire a target format corresponding to the output data in response to an import operation of a format file corresponding to the output data of the program to be tested.
[0122] Optionally, the test module 603 can also be used to: after obtaining the test results, compare the test results with the expected test output data, and determine whether the test results are correct based on the comparison results; if the test results are correct, generate a record sheet; if the test results are incorrect, generate a problem sheet.
[0123] Optionally, the automated testing device 600 may further include a processing module (not shown in the figure), which is used for at least one of the following: in response to a configuration operation for a target test plan, generating a target test plan according to a preset test plan template; in response to a configuration operation for a target test task, obtaining a target test task, the target test task corresponding to a program to be tested and a target test case; in response to a configuration operation and / or an import operation on a target test case, obtaining a target test case; based on the test results, generating a test report; based on the test results, counting code coverage.
[0124] The automated testing device of the embodiment of the present application can be used to execute the technical solution of any of the above-mentioned method embodiments, and its implementation principle and technical effect are similar, which will not be repeated here.
[0125] Figure 7 Schematic diagram of an automated testing system provided in one embodiment of the present application, which may also be understood as an AUTS system. Figure 7 As shown, the automated testing system 700 of the embodiment of the present application may include: a system management module 701, a case management module 702 and an automated testing module 703. Among them:
[0126] System management module 701 is used to perform user login and identify products through users; perform product maintenance to maintain products and their names; perform user maintenance to maintain the correspondence between products and users; perform task order maintenance to maintain task order information; perform SIA file maintenance to import the SIA file of the product and dynamically generate an input interface when creating a test case; perform TFORM file maintenance to import the TFORM file of the product and display the output data in TFORM format after executing the test case instead of returning the data in an unformatted manner.
[0127] The case management module 702 is used to import test cases. Test cases can be created by importing test cases or by directly creating test cases. The test cases are maintained and executed. All test cases for the program are created based on the program. After executing the test cases, a record sheet or a problem sheet is generated based on the execution results. The underlying data SQL can be set to repeatedly execute the test cases. The intermediate data SQL can be set. After executing the intermediate data SQL, the query results of the associated data table can be directly displayed. The test cases can be added, deleted, modified and queried, as well as the query of the associated record sheet / case sheet can be provided. Case sheets, record sheets, problem sheets and test reports can be exported.
[0128] The automated testing module 703 is used to configure the parameter values of whether to compare or participate in the comparison of each data item of the test input data, the test expected output data, the base data and the intermediate data based on the program dimension; to maintain and execute the test tasks. When creating a test task, you can select (for example, by checking the box) the test case to be executed corresponding to the test task, and you can set the execution date. When the execution date arrives, the test task is automatically scheduled for execution, and the test results are compared according to the configured rules; it provides the addition, deletion, modification and query of test tasks, and provides the repeated execution of test tasks; it can query the test results and export case sheets, record sheets, problem sheets and test reports; it can maintain public data, such as maintaining fixed parameter values or SQL statements, to achieve data replacement for batch execution.
[0129] The automated testing system of the embodiment of the present application can be used to execute the technical solution of any of the above-mentioned method embodiments, and its implementation principle and technical effect are similar and will not be repeated here.
[0130] Figure 8 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present application. Figure 8 As shown, the electronic device 800 may include: at least one processor 801 and a memory 802 .
[0131] The memory 802 is used to store programs. Specifically, the programs may include program codes, and the program codes include computer-executable instructions.
[0132] The memory 802 may include a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.
[0133] The processor 801 is used to execute the computer-executable instructions stored in the memory 802 to implement the automated testing method described in the aforementioned method embodiment. Among them, the processor 801 may be a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application. Specifically, when implementing the automated testing method described in the aforementioned method embodiment, the electronic device may be, for example, an electronic device with processing functions such as a server.
[0134] Optionally, the electronic device 800 may further include a communication interface 803. In a specific implementation, if the communication interface 803, the memory 802 and the processor 801 are implemented independently, the communication interface 803, the memory 802 and the processor 801 may be interconnected through a bus and communicate with each other. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc., but it does not mean that there is only one bus or one type of bus.
[0135] Optionally, in a specific implementation, if the communication interface 803, the memory 802 and the processor 801 are integrated on a chip, the communication interface 803, the memory 802 and the processor 801 can communicate through an internal interface.
[0136] The electronic device is used to execute the automated testing method in any of the aforementioned method embodiments, and its implementation principle and technical effects are similar and will not be repeated here.
[0137] The present application also provides a computer-readable storage medium, in which computer program instructions are stored. When a processor executes the computer program instructions, the above-mentioned automated testing method is implemented.
[0138] The present application also provides a computer program product, including a computer program, which implements the above-mentioned automated testing method when executed by a processor.
[0139] The computer-readable storage medium mentioned above can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.
[0140] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in a dedicated integrated circuit. Of course, the processor and the readable storage medium can also exist as discrete components in an automated test device.
[0141] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.
[0142] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0143] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0144] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory, a random access memory (RAM), a disk or an optical disk.
[0145] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.
[0146] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application, are not limited to the precise structures described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present application is limited only by the appended claims.
Claims
1. An automated testing method, characterized in that: For COBOL unit testing, the automated testing method includes: In response to an execution instruction for a target test task, obtaining a program identifier of a program to be tested corresponding to the target test task; Obtaining a target test case corresponding to the program to be tested, wherein the target test case includes test input data, test expected output data, and test premise data; The program to be tested is tested based on a test case parameter script corresponding to the target test case to obtain a test result, wherein the test case parameter script is generated according to the target test case and includes the program identifier, the test input data and the test premise data.
2. The automated testing method according to claim 1, characterized in that: The step of testing the program to be tested based on the test case parameter script corresponding to the target test case to obtain the test result includes: Parsing the test case parameter script to obtain the program identifier of the program to be tested, the test input data and the test premise data; The program to be tested is called according to the program identifier, and the test input data and the test premise data are input into the program to be tested, and the program to be tested is tested to obtain a test result.
3. The automated testing method according to claim 1, characterized in that: The target test case may also include a target intermediate data structured query language SQL, which is used to execute the target intermediate data SQL when testing the program to be tested to obtain query results of the associated data table in the program to be tested.
4. The automated testing method according to claim 1, characterized in that: The data type of the test premise data includes at least one of a premise test case, an SQL premise data script, and a simulation program.
5. The automated testing method according to any one of claims 1 to 4, characterized in that: Before responding to the execution instruction for the target test task, the method further includes: In response to an import operation on an input file corresponding to the test input data, acquiring the test input data; In response to an import operation of a format file corresponding to output data of the program to be tested, a target format corresponding to the output data is acquired.
6. The automated testing method according to any one of claims 1 to 4, characterized in that: After obtaining the test results, the method further includes: Comparing the test result with the test expected output data, and determining whether the test result is correct based on the comparison result; If the test result is correct, a record sheet is generated; If the test result is incorrect, a problem ticket is generated.
7. The automated testing method according to any one of claims 1 to 4, characterized in that: Also includes at least one of the following: In response to a configuration operation for a target test plan, generating the target test plan according to a preset test plan template; In response to a configuration operation for the target test task, the target test task is acquired, where the target test task corresponds to the program to be tested and the target test case; In response to a configuration operation and / or an import operation on the target test case, acquiring the target test case; Based on the test results, generate a test report; Based on the test results, code coverage is calculated.
8. An automated testing device, characterized in that: For COBOL unit testing, the automated testing device comprises: A first acquisition module, configured to acquire a program identifier of a program to be tested corresponding to a target test task in response to an execution instruction for the target test task; A second acquisition module is used to acquire a target test case corresponding to the program to be tested, wherein the target test case includes test input data, test expected output data and test premise data; A test module is used to test the program to be tested based on a test case parameter script corresponding to the target test case to obtain a test result. The test case parameter script is generated based on the target test case, and the test case parameter script includes the program identifier, the test input data and the test premise data.
9. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the automated testing method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the automated testing method according to any one of claims 1 to 7 when executed.