Method and apparatus for automatically identifying test scenarios and automatically verifying results

Abstract

The present invention provides a method and device for automatically identifying test scenarios and automatically verifying results. The method includes: analyzing and extracting the incoming database message and service data to obtain the extracted message data; matching the extracted message data with the mapping relationship between the preset service rules and the expected test results to obtain a matching result; determining whether it is necessary to verify the expected test results according to the matching result; if so, verifying the actual execution result and the expected test result to generate a test progress report. Through the automated statistics of the test case coverage rate, this application avoids the situation of manually and randomly or incorrectly matching test cases. It improves the accuracy of the test case coverage rate statistics, can more truly and accurately reflect the test progress, and estimate the test risks; moreover, it also automatically analyzes and matches through the service database and the rule base, and automatically matches the coverage of the test cases, further reducing the management communication cost.

Description

Technical Field

[0001] This application belongs to the field of testing technology. Specifically, it relates to a method and device for automatically identifying test scenarios and automatically verifying results. Background Art

[0002] With the current work requirements of building quality in development and the in-depth transfer of testing, more testing work needs to be transferred to developers for execution. Among them, the execution of test cases is an important testing task transferred to developers. Since developers lack testing experience, there are situations where test cases are not executed properly. Currently, there is a lack of effective means for monitoring the testing quality of transferred scenario cases. The progress of case execution is mainly feedback by developers manually confirming and checking cases, and there are situations where developers have subjective understanding errors or wrongly match cases in order to catch up with the testing progress, resulting in false testing progress or missed tests, and it is impossible to accurately evaluate the testing effect and ensure the project testing quality.

[0003] For test cases transferred to developers for execution, currently, the testing progress of the project is mainly monitored by developers manually confirming and checking cases. This method has the following problems:

[0004] 1. Since developers lack testing experience, they may not understand test cases properly, or in order to catch up with the project testing progress, there are situations of randomly matching or wrongly matching test cases. As a result, it is inaccurate to evaluate the project testing progress based on the test case coverage rate.

[0005] 2. The testing progress depends on developers or testers checking cases for statistics and feedback. Often, the test manager or project manager needs to repeatedly urge and communicate with the test executors to check cases in a timely manner, which further increases the testing management cost.

[0006] 3. The execution of test cases also includes the verification of results after case execution. In fact, the verification of test case execution results often requires test executors to have stronger business understanding ability. When developers or external testers execute cases, due to lack of understanding or no logical verification, defects are not found, resulting in poor quality of the project's online version and an increase in production problems. Summary of the Invention

[0007] This application provides a method and device for automatically identifying test scenarios and automatically verifying results to at least solve the problems existing in manually executing test cases and checking cases to monitor the testing progress of the project.

[0008] According to the first aspect of this application, a method for automatically identifying test scenarios and automatically verifying results is provided, including:

[0009] Analyze and extract the incoming database message and business data to obtain the extracted message data;

[0010] Match the extracted message data with the mapping relationships of preset business rules and expected test results to obtain a matching result;

[0011] Determine whether it is necessary to check the expected test results according to the matching result;

[0012] If so, check the actual execution result against the expected test result to generate a test progress report.

[0013] In one embodiment, the test scenario automatic recognition and result automatic checking method further includes:

[0014] Construct the mapping relationships of business rules and expected test results according to the existing business rules and scenario test cases;

[0015] In one embodiment, constructing the mapping relationships of business rules and expected test results according to the existing business rules and scenario test cases includes:

[0016] Sort out the business rules for the application scenario or system to be tested;

[0017] Obtain the transaction result checking rules and expected test results of each scenario test case;

[0018] Construct the mapping relationships of business rules and expected test results according to the scenario test cases and expected test results.

[0019] In one embodiment, analyzing and extracting the stored message and business data to obtain the extracted message data includes:

[0020] Obtain the message from the message database through SQL query language;

[0021] Parse the message to obtain the attribute values of the message and save them.

[0022] In one embodiment, determining whether it is necessary to check the expected test results according to the matching result includes:

[0023] If there is message data that matches the business rules of a certain case, the case has been covered, and the matching business data is output;

[0024] Further check the expected test results.

[0025] In one embodiment, determining whether it is necessary to check the expected test results according to the matching result further includes:

[0026] If there is no message data that matches the business rules of a certain case, the case has not been covered, and the check of the expected test results is not performed.

[0027] In one embodiment, determining whether it is necessary to check the expected test results according to the matching result further includes:

[0028] If there is a partial match of the message data with the business rules of a certain case, do not check the expected test results for all the message data;

[0029] Output the partially matched business data and then check the expected test results.

[0030] According to another aspect of the present application, there is also provided a device for automatically identifying test scenarios and automatically checking results, including:

[0031] An extraction unit for analyzing and extracting the stored message and business data to obtain the extracted message data;

[0032] A matching unit for matching the extracted message data with the mapping relationship between the preset business rules and the expected test results to obtain a matching result;

[0033] A checking unit for determining whether it is necessary to check the expected test results according to the matching result;

[0034] A test progress report generation unit for, if so, checking the actual execution result against the expected test result and generating a test progress report.

[0035] In one embodiment, the device for automatically identifying test scenarios and automatically checking results further includes:

[0036] A mapping relationship construction unit for constructing the mapping relationship between the business rules and the expected test results according to the existing business rules and scenario test cases;

[0037] In one embodiment, the mapping relationship construction unit includes:

[0038] A business rule sorting module for sorting out the business rules for the application scenario or system to be tested;

[0039] An expected test result acquisition module for acquiring the transaction result checking rules and the expected test results of each scenario test case;

[0040] A construction module for constructing the mapping relationship between the business rules and the expected test results according to the scenario test cases and the expected test results.

[0041] In one embodiment, the extraction unit includes:

[0042] A query and acquisition module for obtaining the message from the message database through SQL query language;

[0043] An attribute value saving module for parsing the message to obtain the attribute value of the message and saving it.

[0044] In one embodiment, the verification unit includes:

[0045] A first module, configured to output the matching service data if there is message data that matches the service rule of a certain case, indicating that the case has been covered.

[0046] A verification module, configured to further verify the expected test result.

[0047] In one embodiment, the verification unit further includes:

[0048] A second module, configured to not perform the verification of the expected test result if there is no message data that matches the service rule of a certain case, indicating that the case has not been covered.

[0049] In one embodiment, the verification unit further includes:

[0050] A third module, configured to not perform the verification of the expected test result for all the message data if there is message data that partially matches the service rule of a certain case.

[0051] A screening and verification module, configured to output the partially matching service data and then perform the verification of the expected test result. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings without creative efforts based on these drawings.

[0053] Figure 1 A method for automatically identifying a test scenario and automatically verifying the result provided by this application.

[0054] Figure 2 Constructing a mapping relationship between service rules and expected test results for this application.

[0055] Figure 3 Analyzing and extracting the stored messages and service data for this application to obtain the extracted message data.

[0056] Figure 4 Determining whether to verify the expected test result according to the matching result.

[0057] Figure 5 Determining whether to verify the expected test result according to the matching result in another embodiment.

[0058] Figure 6 Reference for defining service rules in the cross-institutional message interaction service scenario.

[0059] Figure 7 For the matching relationship between cases and business rules.

[0060] Figure 8 For the matching relationship between cases and the verification rules of expected results.

[0061] Figure 9 It is a device for automatically identifying test scenarios and automatically verifying results.

[0062] Figure 10 It is a structural block diagram of the mapping relationship construction unit.

[0063] Figure 11 It is a structural block diagram of the extraction unit.

[0064] Figure 12 It is a structural block diagram of the verification unit.

[0065] Figure 13 It is a structural block diagram of the verification unit in another embodiment.

[0066] Figure 14 This is a specific implementation manner of an electronic device in the embodiments of the present application. Specific implementation manner

[0067] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without making creative efforts belong to the scope of protection of the present invention.

[0068] To solve the problems existing in the background technology, the present application provides a method for automatically identifying test scenarios and automatically verifying results, as Figure 1 shown, including:

[0069] S101: Analyze and extract the incoming library message and business data to obtain the extracted message data.

[0070] S102: Match the extracted message data with the mapping relationship between the preset business rules and the expected test results to obtain a matching result.

[0071] S103: Determine whether it is necessary to verify the expected test results according to the matching result.

[0072] S104: If so, verify the actual execution result and the expected test result, and generate a test progress report.

[0073] In one embodiment, the method for automatically identifying test scenarios and automatically verifying results further includes:

[0074] Construct the mapping relationship between business rules and expected test results according to existing business rules and scenario test cases;

[0075] In one embodiment, construct the mapping relationship between business rules and expected test results according to existing business rules and scenario test cases, as Figure 2 shown, including:

[0076] S201: Sort out business rules for the application scenario or system to be tested.

[0077] S202: Obtain the transaction result verification rules and expected test results of each scenario test case.

[0078] S203: Construct the mapping relationship between business rules and expected test results according to the scenario test case and the expected test result.

[0079] In one embodiment, analyze and extract the stored message and business data to obtain the extracted message data, as Figure 3 shown, including:

[0080] S401: Obtain the message from the message database through the SQL query language.

[0081] S402: Parse the message to obtain the attribute values of the message and save them.

[0082] In one embodiment, determine whether it is necessary to check the expected test results according to the matching result, as Figure 4 shown, including:

[0083] S501: If there is message data matching the business rule of a certain case, the case has been covered, and output the matching business data.

[0084] S502: Further check the expected test results.

[0085] In one embodiment, determine whether it is necessary to check the expected test results according to the matching result, and also include:

[0086] If there is no message data matching the business rule of a certain case, the case is not covered, and do not check the expected test results.

[0087] In one embodiment, determine whether it is necessary to check the expected test results according to the matching result, as Figure 5 shown, and also include:

[0088] S601: If there is partial message data matching the business rule of a certain case, do not check the expected test results for all the message data.

[0089] S602: Output the partially matched service data and then check it against the expected test results.

[0090] In a specific embodiment, sort out the service matching rules for the tested application scenarios or systems. For example, for service scenarios such as cross-institutional transfer and remittance, consumption, etc., which involve message interaction, the service matching rules are defined as follows:

[0091] The extraction of message service rules includes the original message type, sending / receiving flag, receipt message type, receipt message status, associated message type, associated message sending / receiving flag, etc. Among them, the matching dictionary items for the original message type are: 201, 221, 225, 227, 251, 255, 281, 801, 262, 211, etc.; the matching dictionary items for the sending / receiving flag are: sending, receiving; the matching dictionary items for the receipt message type are: 202, 222, 226, 228, 253, 902, 911, 909, 900, 212, 282, 263; the matching dictionary items for the receipt message status are: PR00, PR01, PR03, PR04; the matching dictionary items for the associated message type are: 201, 221, 225, 227, 251, 255, 281, 801, 262, 211; the matching dictionary items for the associated message sending / receiving flag are: sending, receiving; The reference for the service rule definition of the cross-institutional message interaction service scenario is as Figure 6 shown.

[0092] Sort out the transaction result checking rules for each application scenario, and define the transaction result checking rules for service scenarios such as cross-institutional transfer and consumption in step one.

[0093] The checking of transaction results includes: checking of product service tables, checking of message registration tables, and checking of accounting processing.

[0094] The checking of each service table is represented in JSON format, mainly including the names of the corresponding checked tables and the checking rules for the key fields in the tables.

[0095] For example, for the transfer service, the checking rules for each database table are sorted out as follows: Among them, the ones marked with "#" represent variables, which need to match the parsed message data to verify the correctness of the transaction results.

[0096] The checking rules for the transfer product service table TRANSFERLOG are defined as follows:

[0097] {"TRANSFERLOG":{"PARTID":"#PARTID#","DRCRFLAG":"#Debit / Credit Flag#","AMOUNT":"#Message Amount#","STATUS":"#Status#","ACCSTATUS":"#Accounting Status#","ACCDATE":"#Accounting Date#","DRBANKCODE":"#Payer's Financial Institution#","CRBANKCODE":"#Payee's Financial Institution#","DRACCID":"#Payer's Account#","CRACCID":"#Payee's Account#"}}

[0098] The check rules for the transfer message registration form CREDSENDLOG are defined as follows:

[0099] {"CREDSENDLOG":{"PARTID":"#PARTID#","MSGID":"#Message Identification Number#","MSGTYPE":"#Message Type#","MSGAMT":"#Message Amount#","STATUS":"#Status#","BANKCODE":"#Initiating Party's Financial Institution#","OBNKCODE":"#Receiving Party's Financial Institution#","DRACCID":"#Payer's Account#","CRACCID":"#Payee's Account#","ACCDATE":"#Accounting Date#","RETMSGID":"#Receipt Message Identification Number#","RETMSGTYPE":"#Receipt Message Type#","BUSSSTS":"#Business Status#"}}

[0100] The check rules for the accounting processing table ACCOUNTDETAIL are defined as follows:

[0101] {"ACCOUNTDETAIL":{"PARTID":"#PARTID#","ACCID":"#Accounting Account#","AMOUNT":"#Message Amount#","CBACCOUNT":"#Counterparty Account#","STATUS":"#Status#","TRANSDATE":"#Accounting Date#","RPFLAG":"#Debit / Credit Flag#","TRADETYPE":"#Transaction Type#"}}

[0102] For the transfer and remittance business, send a 201 message and receive a successful 202 receipt.

[0103] Parsing the XML message data matches the verification rules of the above product business table TRANSFERLOG. Among them, the variables marked with "#" are matched and converted with the actually parsed message data. For the above 2021 remittance XML message sent by our bank and the successful receipt of 202, the specific matching conversion is as follows:

[0104] Calculate PARTID according to the message date 2021-11-24. PARTID represents the day of the year. January 1, 2021 is the 1st day, and November 24, 2021 is the 328th day, that is, PARTID = 328,

[0105] The payment and receipt flag DRCRFLAG = 44 (payment),

[0106] The message amount AMOUNT = 100,

[0107] The transaction status STATUS = 55 (transaction successful),

[0108] The accounting status ACCSTATUS = 66 (accounting successful),

[0109] The accounting date ACCDATE = 2021-11-24,

[0110] The financial institution of the payer DRBANKCODE = CCCC1011211020012,

[0111] The financial institution of the payee CRBANKCODE = DDDD1140301005293,

[0112] The payer's account DRACCID = 9222022021****2871,

[0113] The payee's account CRACCID = 02000031017****3452

[0114] The result after replacing the verification rules of the product business table TRANSFERLOG is as follows. The conversion of other verification tables is similar:

[0115] {"TRANSFERLOG":{"PARTID":"328","DRCRFLAG":"44","AMOUNT":"100","STATUS":"55","ACCSTATUS":"66","ACCDATE":"2021-11-24","DRBANKCODE":"CCCC1011211020012","CRBANKCODE":"DDDD1140301005293","DRACCID":"9222022021****2871","CRACCID":"02000031017****3452"}}

[0116] Build the correspondence between the scenario test cases and the business matching rules and the expected result checking rules, that is, regularize the test cases to prepare for subsequent automatic matching and checking:

[0117] For example, for the transfer and remittance business scenario number 101, the matching relationship between cases 101 and 107 and the business rules is as Figure 7 shown, and the matching relationship between cases 101 and 107 of the transfer and remittance business scenario number 101 and the expected result checking rules is as Figure 8 shown. For the transfer and remittance business, send a 201 message and receive a successful 202 receipt. After parsing the message, make variable substitutions for the checking rules according to the specific values of the message, and then match and check with the business data obtained from the database, and output the checking results and the message data.

[0118] Extract and analyze the incoming warehouse message / business data. The message data analysis and extraction function module queries the message data in the message database, parses it, and matches it with the business rules. It uses SQL to query the message database for data in XML or JSON format, and then parses the XML or JSON format message. For example, it uses DOM4J to parse the XML message, obtains the attribute values under the XML message nodes and saves them in a collection, and uses Gson to parse the JSON format message, obtains the message information attribute values and saves them in a collection. For the above transfer and remittance business, it sends a 201 message and receives a 202 successful receipt. After parsing the XML message, it saves the attribute values of the original message and the receipt message, such as SndDtTm, Sender, Receiver, MsgId, TrxAmt, MsgTp, DbAccNo, CdAccNo, RspsnSts, etc., and then checks and matches them with the business rules and expected results. By matching the original message type MsgTp = 201, the receipt message type MsgTp = 202, and the sender Sender = CCCC1011211020012 (this bank) to determine the sending and receiving message flag = sending message, and the receipt message status RspsnSts = PR00, which matches case 101, then the case is covered. The matching conversion of the transaction result check rule is similar, that is, it is matched and converted according to the attribute values saved by message parsing.

[0119] Match the extracted message data with the case rules:

[0120] 1) If there is message data that matches the business rules of a certain case, then the case is covered, output the matching business data, and further check the expected results

[0121] 2) If there is no message data that matches the business rules of a certain case, then this case is not covered and there is no need to check the expected results

[0122] 3) If there is message data that partially matches the business rules of a certain case, for example: case 107 above involves two operation steps. If only the first operation step is matched and the second operation step is not matched, then the case has not reached the final state, so this case is not covered and there is no need to check the expected results. At the same time, output the partially matching business data for subsequent checking

[0123] For the cases that have been covered and executed in step five, perform the automatic check function for the expected results. The specific steps can be seen in the second subsection of the third paragraph:

[0124] 1) If there are no records found in the query database table, then the check of the case execution result fails, and output the query statement for subsequent analysis and checking

[0125] 2) If database records are queried, the corresponding fields in the database table are verified according to the expected result verification rules. If there is a complete match, the verification passes.

[0126] 3) If database records are queried, the corresponding fields in the database table are verified according to the expected result verification rules. If some of the fields fail to pass the verification, the expected result verification fails, and a result prompt for the failed fields is output for subsequent analysis and verification.

[0127] Through the matching and verification in Step 5 and Step 6, the execution status of each case already has corresponding output results. The coverage of cases is summarized daily, including: the number of executed cases, the number of cases that passed the execution, etc. The case coverage rate is statistically calculated, and a test progress report is automatically generated.

[0128] Through the automated statistics of the test case coverage rate in this application, the situation of manually and randomly mismatching or mis-matching test cases is avoided. The accuracy of the test case coverage rate statistics is improved, and the test progress can be more realistically and accurately reflected, and the test risk can be estimated. Moreover, through the automatic analysis and matching of the business database and the rule library, the coverage of test cases is automatically matched, and it is not necessary for the test manager or project management personnel to repeatedly urge and communicate with the test executors to manually check the cases in a timely manner, further reducing the management communication cost. For the automatically matched covered test cases, by matching the expected result verification rules, the transaction execution results are automatically verified, avoiding the problems such as undetected defect problems caused by the test executors' insufficient understanding or failure to verify the transaction results, and poor quality of the version going online. Through the automatic verification of the transaction execution results, the assertions for the cases that fail to pass the verification are saved and output, which is more convenient for developers and testers to analyze and locate problems. Finally, by automatically monitoring the execution status of cases daily and saving the monitored results, the entire test process of the project can be understood more clearly, and it is also possible to better monitor and discover that the executed cases that have passed are affected by incorrect modifications made by developers, and better protect the test quality of the project.

[0129] Based on the same inventive concept, the embodiment of the present application also provides a test scenario automatic recognition and result automatic verification device, which can be used to implement the method described in the above embodiment, as described in the following embodiment. Since the principle of the test scenario automatic recognition and result automatic verification device for solving problems is similar to that of the test scenario automatic recognition and result automatic verification method, the implementation of the test scenario automatic recognition and result automatic verification device can refer to the implementation of the test scenario automatic recognition and result automatic verification method, and the repeated parts will not be described again. As used hereinafter, the term "unit" or "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the systems described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0130] According to another aspect of the present application, there is also provided a device for automatically identifying test scenarios and automatically verifying results, as Figure 9 shown, including:

[0131] An extraction unit 1001, configured to analyze and extract the dropped database message and service data to obtain the extracted message data;

[0132] A matching unit 1002, configured to match the extracted message data with the mapping relationship between the preset service rules and the expected test results to obtain a matching result;

[0133] A verification unit 1003, configured to determine whether it is necessary to verify the expected test results according to the matching result;

[0134] A test progress report generation unit 1004, configured to, if so, verify the actual execution result and the expected test result, and generate a test progress report.

[0135] In one embodiment, the device for automatically identifying test scenarios and automatically verifying results further includes:

[0136] A mapping relationship construction unit, configured to construct a mapping relationship between service rules and expected test results according to the existing service rules and scenario test cases;

[0137] In one embodiment, as Figure 10 shown, the mapping relationship construction unit includes:

[0138] A service rule sorting module 1101, configured to sort service rules for the application scenario or system to be tested;

[0139] An expected test result acquisition module 1102, configured to acquire the transaction result verification rules and expected test results of each scenario test case;

[0140] A construction module 1103, configured to construct a mapping relationship between service rules and expected test results according to the scenario test cases and the expected test results.

[0141] In one embodiment, as Figure 11 shown, the extraction unit 1001 includes:

[0142] A query and acquisition module 1201, configured to acquire messages from the message database through SQL query language;

[0143] An attribute value saving module 1202, configured to parse the message to obtain the attribute value of the message and save it.

[0144] In one embodiment, as Figure 12 shown, the verification unit 1003 includes:

[0145] The first module 1301 is used to output the matching service data if there is message data that matches the service rule of a certain case, indicating that the case has been covered.

[0146] The verification module 1302 is used to further verify the expected test results.

[0147] In one embodiment, the verification unit 1003 further includes:

[0148] The second module is used to not verify the expected test results if there is no message data that matches the service rule of a certain case, indicating that the case has not been covered.

[0149] In one embodiment, as Figure 13 shown, the verification unit 1003 further includes:

[0150] The third module 1401 is used to not verify the expected test results for all the message data if there is message data that partially matches the service rule of a certain case;

[0151] The screening and verification module 1402 is used to output the partially matching service data and then verify the expected test results.

[0152] The embodiments of the present application also provide a specific implementation manner of an electronic device that can implement all the steps in the method in the above embodiments. Refer to Figure 14 and the electronic device specifically includes the following:

[0153] A processor 1501, a memory 1502, a communication interface 1503, a bus 1504, and a non-volatile memory 1505;

[0154] Among them, the processor 1501, the memory 1502, and the communication interface 1503 communicate with each other through the bus 1504;

[0155] The processor 1501 is used to call computer programs in the memory 1502 and the non-volatile memory 1505. When the processor executes the computer programs, all the steps in the method in the above embodiments are implemented. For example, when the processor executes the computer programs, the following steps are implemented:

[0156] S101: Analyze and extract the incoming database messages and service data to obtain the extracted message data.

[0157] S102: Match the extracted message data with the mapping relationship between the preset service rules and the expected test results to obtain a matching result.

[0158] S103: Determine whether it is necessary to verify the expected test result according to the matching result.

[0159] S104: If so, verify the actual execution result and the expected test result, and generate a test progress report.

[0160] An embodiment of the present application further provides a computer-readable storage medium capable of implementing all steps in the method in the above embodiment. A computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, all steps in the method in the above embodiment are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0161] S101: Analyze and extract the incoming library message and service data to obtain the extracted message data.

[0162] S102: Match the extracted message data with the mapping relationship between the preset service rules and the expected test results to obtain a matching result.

[0163] S103: Determine whether it is necessary to verify the expected test result according to the matching result.

[0164] S104: If so, verify the actual execution result and the expected test result, and generate a test progress report.

[0165] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and the key point of each embodiment is to illustrate the differences from other embodiments. In particular, for the hardware + program type of embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments. Although the method operation steps as described in the embodiments of this specification are provided, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way among the execution orders of numerous steps and does not represent the only execution order. When actually implemented in a device or terminal product, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel (for example, in an environment of parallel processors or multi-threaded processing, or even in a distributed data processing environment). The term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, product or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such a process, method, product or device. Without further limitation, there is no exclusion of additional identical or equivalent elements in the process, method, product or device including the said elements. For the convenience of description, when describing the above device, it is divided into various modules according to functions for separate description. Of course, when implementing the embodiments of this specification, the functions of each module can be realized in the same or multiple software and / or hardware, or the modules implementing the same function can be realized by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, 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 displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces, and the indirect coupling or communication connection of the device or unit can be in electrical, mechanical or other forms. The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate for implementing in the process Figure 1 one or more flows and / or blocks Figure 1Apparatus for the functions specified in one or more boxes. Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code. Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For the relevant parts, reference can be made to the partial description of the method embodiment. In the description of this specification, the description of reference terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the embodiments of this specification. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples. The above is only the embodiments of the embodiments of this specification and is not used to limit the embodiments of this specification. For those skilled in the art, the embodiments of this specification can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiments of this specification shall be included in the scope of the claims of the embodiments of this specification.

Claims

1. A method for automatically identifying test scenarios and automatically verifying results, characterized in that, include: Define transaction result verification rules in advance for cross-institution transfer and consumption business scenarios; The transaction result verification rules include: product business table verification, message registration table verification and account processing verification; Sort out business rules for the application scenarios or systems to be tested; Obtain transaction result verification rules and expected test results for each scenario test case; Constructing a mapping relationship between business rules and expected test results based on the scenario test case and the expected test results; Analyze and extract the stored messages and business data to obtain the extracted message data; Matching the extracted message data with a mapping relationship between preset business rules and expected test results to obtain a matching result, wherein the preset business rules include the transaction result verification rules; Determine whether to check the expected test results based on the matching results; If so, compare the actual execution results with the expected test results and generate a test progress report.

2. The method for automatic identification of test scenarios and automatic verification of test results according to claim 1, characterized in that: The step of analyzing and extracting the stored messages and business data to obtain the extracted message data includes: Obtain messages from the message database using SQL query language; Parse the message to obtain the attribute value of the message and save it.

3. The method for automatically identifying a test scenario and automatically checking results according to claim 2, characterized in that Determining whether to check the expected test result based on the matching result includes: If there is message data that matches the business rules of a case, the case is covered and the matching business data is output; Further checks are performed on the expected test results.

4. The method for automatically identifying a test scenario and automatically verifying a result according to claim 2, wherein The determining whether to check the expected test result according to the matching result further includes: If no message data matches the business rules of a case, the case is not covered and the expected test results are not checked.

5. The method for automatically identifying a test scenario and automatically verifying a result according to claim 2, wherein The determining whether to check the expected test result according to the matching result further includes: If some message data partially matches the business rules of a case, the expected test results will not be checked against all message data; After outputting the partially matched business data, the expected test results are checked.

6. An automatic test scenario recognition and result automatic verification device, characterized in that, include: The business rule sorting module is used to predefine transaction result verification rules for cross-institution transfer and consumption business scenarios; The transaction result verification rules include: product business table verification, message registration table verification and account processing verification; The mapping relationship construction unit includes: a business rule combing module for combing business rules for the application scenario or system to be tested; an expected test result acquisition module for obtaining transaction result verification rules and expected test results for each scenario test case; and a construction module for constructing a mapping relationship between business rules and expected test results based on the scenario test case and expected test results. An extraction unit, configured to analyze and extract the stored messages and business data to obtain extracted message data; a matching unit, configured to match the extracted message data with a mapping relationship between preset business rules and expected test results to obtain a matching result, wherein the preset business rules include the transaction result verification rules; A checking unit, configured to determine whether the expected test result needs to be checked based on the matching result; The test progress report generating unit is used to, if yes, check the actual execution result with the expected test result and generate a test progress report.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, it implements the steps of the method for automatically identifying test scenarios and automatically verifying results according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for automatically identifying test scenarios and automatically verifying results according to any one of claims 1 to 5.

Images