Test case generation and verification method and device, equipment, storage medium and program product
By analyzing and assembling the data in the transaction log and service transaction data, generating test cases for the underlying service, solving the problem of low accuracy of artificial design test cases and improving the reliability of system verification.
Patent Information
- Application Number
- CN202411873474.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-18
- Publication Date
- 2025-03-28
AI Technical Summary
In the prior art, the accuracy of artificially designed test cases is low, resulting in a decrease in reliability of system verification results.
By obtaining the test case format corresponding to the underlying service and parsing it, identifying and extracting the data required for request messages, reply messages and expected results, assembling the required data from transaction log files and service transaction data to generate test cases.
Improve the accuracy of test cases, enhance the reliability of system verification results, and enable test cases to better simulate the real business operation environment.
Smart Images

Figure CN119718948A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of financial technology or other related fields, and in particular to a test case generation and verification method, device, equipment, storage medium and program product. Background Art
[0002] With the continuous development of Internet technology and the financial field, the functions of trading systems are becoming more and more complex, and the update scope is becoming wider and wider. It is necessary to verify the updated trading system to ensure the normal use of the trading system.
[0003] Currently, verification of an updated trading system is generally carried out by R&D personnel manually designing test cases based on the logical path of the trading system's operation, and using the manually designed test cases to verify the updated trading system.
[0004] However, in a real business operation environment, various unpredictable situations often occur, which makes the accuracy of artificially designed test cases low, thereby reducing the reliability of system verification results. Summary of the invention
[0005] The present application provides a test case generation and verification method, apparatus, equipment, storage medium and program product to solve the technical problem that the accuracy of the designed test cases is low, thereby reducing the reliability of the system verification results.
[0006] In a first aspect, the present application provides a test case generation method, the method is applied to a target transaction system verification platform, the target transaction system verification platform is used to verify a target transaction system, the target transaction system includes multiple underlying services, the method includes: obtaining a test case format corresponding to the underlying service and parsing it to obtain an address and identifier of data required by the test case format; the test case includes a request message, a response message, and an expected result;
[0007] According to the request message format and the address of the data required for the reply message format, a transaction log file is obtained in the production log backup server, and according to the corresponding identifier, an optical character recognition strategy is used to respectively identify and extract the request message format and the data required for the reply message format in the transaction log file;
[0008] Acquire service transaction data in a preset storage medium according to the addresses of the data required for the request message format, the response message format, and the expected result format, and acquire the data required for the request message format, the response message format, and the expected result format respectively from the service transaction data according to the corresponding identifiers;
[0009] The data required for the request message format, the response message format and the expected result format are respectively assembled, and the request message, the response message and the expected result are generated based on the assembly results to generate the test case corresponding to the underlying service.
[0010] In a second aspect, the present application provides a test case verification method, the method being applied to a target trading system, the target trading system including a plurality of underlying services, the method comprising: receiving a preset playback strategy sent by a verification platform of the target trading system, and a request message and a response message corresponding to the underlying service;
[0011] According to the playback target, playback order, and playback times indicated by the preset playback strategy, the request message is used to run the underlying service, and an actual response message of the underlying service is verified based on the response message;
[0012] The verification result and the operation data of the underlying service are obtained to obtain a playback result, and the playback result is sent to the target transaction system verification platform.
[0013] In a third aspect, the present application provides a test case generation device, including: a processing module, used to obtain the test case format corresponding to the underlying service and parse it to obtain the address and identifier of the data required by the test case format; the test case includes a request message, a response message and an expected result; according to the request message format and the address of the data required by the response message format, a transaction log file is obtained in a production log backup server, and according to the corresponding identifier, an optical character recognition strategy is used to respectively identify and extract the request message format and the data required by the response message format in the transaction log file; according to the address of the data required by the request message format, the response message format and the expected result format, service transaction data is obtained in a preset storage medium, and according to the corresponding identifier, the data required by the request message format, the response message format and the expected result format are respectively obtained in the service transaction data; the data required by the request message format, the response message format and the expected result format are respectively assembled;
[0014] A generation module is used to generate a request message, a response message and an expected result based on the assembly result to generate a test case corresponding to the underlying service.
[0015] In a fourth aspect, the present application provides a test case verification device, comprising: a transceiver module, configured to receive a preset playback strategy sent by a target transaction system verification platform, and a request message and a response message corresponding to an underlying service;
[0016] A processing module, configured to run the underlying service using the request message according to the playback target, playback order, and playback number indicated by the preset playback strategy;
[0017] A verification module, used to verify the actual response message of the underlying service based on the response message;
[0018] The processing module is further used to obtain the verification result and the operation data of the underlying service to obtain the playback result;
[0019] The transceiver module is also used to send the playback result to the target transaction system verification platform.
[0020] In a fifth aspect, the present application provides an electronic device, comprising: a processor, a memory and a transceiver communicatively connected to the processor;
[0021] The memory stores computer-executable instructions; the transceiver is used to send and receive data;
[0022] The processor executes the computer-executable instructions stored in the memory to implement the method according to the first aspect and the second aspect.
[0023] In a sixth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the methods described in the first and second aspects.
[0024] In a seventh aspect, the present application provides a computer program product, including a computer program, which implements the methods described in the first and second aspects when executed by a processor.
[0025] The test case generation and verification method, apparatus, device, storage medium and program product provided in the present application are applied to a target transaction system verification platform, wherein the target transaction system verification platform is used to verify a target transaction system, wherein the target transaction system includes multiple underlying services, and the method includes: obtaining a test case format corresponding to the underlying service and parsing it to obtain the address and identifier of the data required for the test case format; the test case includes a request message, a response message and an expected result; according to the request message format and the address of the data required for the response message format, a transaction log file is obtained in a production log backup server, and according to the corresponding identifier, An optical character recognition strategy is used to respectively identify and extract the request message format and the data required for the response message format in the transaction log file; service transaction data is obtained in a preset storage medium according to the addresses of the data required for the request message format, the response message format and the expected result format, and according to corresponding identifiers, the data required for the request message format, the response message format and the expected result format are respectively obtained in the service transaction data; the data required for the request message format, the response message format and the expected result format are respectively assembled, and a request message, a response message and an expected result are generated based on the assembly results, so as to generate a test case corresponding to the underlying service. Since the test case is formed based on the request message, the response message and the expected result, the address and identifier of the data required for the test case format can be obtained by obtaining the test case format corresponding to the underlying service and parsing it, that is, the address and identifier of the data required for the request message format, the address and identifier of the data required for the response message, and the address and identifier of the data required for the expected result. By obtaining the transaction log file in the production log backup server according to the request message format and the address of the data required for the response message format, the request message format can be further identified and extracted in the transaction log file according to the corresponding identifier using an optical character recognition strategy. And the data required for the response message format. Similarly, by obtaining the service transaction data in the preset storage medium according to the addresses of the data required for the request message format, the response message format and the expected result format, the data required for the request message format, the response message format and the expected result format can be obtained in the service transaction data according to the corresponding identifiers, thereby by respectively assembling the data required for the request message format, the response message format and the expected result format, the request message, the response message and the expected result can be generated based on the assembly results, thereby generating test cases corresponding to the underlying services, improving the accuracy of the test cases, and then improving the reliability of the system verification results. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] 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.
[0027] Figure 1An application scenario diagram of a test case generation method provided by an embodiment of the present application;
[0028] Figure 2 A flowchart of a test case generation method provided in one embodiment of the present application;
[0029] Figure 3 A flowchart of a test case verification method provided in an embodiment of the present application;
[0030] Figure 4 A signaling interaction diagram of a test case generation and verification method provided in an embodiment of the present application;
[0031] Figure 5 A schematic diagram of the structure of a test case generation device provided in one embodiment of the present application;
[0032] Figure 6 A schematic diagram of the structure of a test case verification device provided in one embodiment of the present application;
[0033] Figure 7 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application.
[0034] 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
[0035] 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.
[0036] 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, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse.
[0037] It should be noted that the test case generation and verification method, apparatus, equipment, storage medium and program product provided in the present application can be used in the field of financial technology or other related fields, and can also be used in any field other than the field of financial technology or other related fields. The application field of the test case generation and verification method, apparatus, equipment, storage medium and program product in the present application is not limited.
[0038] At present, when verifying the updated trading system, the R&D personnel usually determine the logical path of each service when executing according to the services included in the trading system, and manually design test cases applicable to each service according to the above logical path, such as request messages and response messages applicable to each service, and then use the designed test cases to verify the updated trading system. However, in the real business operation environment, various unpredictable situations often occur, which makes the accuracy of the manually designed test cases low, thereby reducing the reliability of the system verification results.
[0039] Therefore, when facing the technical problems in the prior art, instead of designing test cases manually, test cases are pre-set, i.e., the formats of request messages, response messages, and expected results, and then, according to the instructions of the formats of request messages, response messages, and expected results, the specific data required for request messages, response messages, and expected results are extracted from the transaction log files and service transaction data generated during the operation of the transaction system, thereby forming a test case for verifying the updated transaction system. Then, when there is a need to verify the updated transaction system, the pre-set test case format, i.e., the request message format, the response message format, and the expected result format, is obtained, and then, according to the data position indicated by each format, the data required for each format is obtained from the transaction log files and service transaction data, and the obtained data is respectively assembled into request messages, response messages, and expected results, i.e., test cases for verifying the updated transaction system, so that the generated test cases can simulate the real business operation environment to a large extent, improve the accuracy of the test cases, and thus improve the reliability of the system verification results.
[0040] Figure 1 An application scenario diagram of a test case generation method provided by an embodiment of the present application, such as Figure 1As shown, the system corresponding to the test case generation method in the embodiment of the present application includes: a target transaction system verification platform 1, a production log backup server 2, and a preset storage medium 3. Among them, the target transaction system verification platform 1 is a device for executing the test case generation method. The production log backup server 2 is a server for storing log files generated during the operation of the transaction system. The preset storage medium 3 is a storage medium for storing service transaction data generated during the operation of the transaction system, for example, it can be a data lake. Among them, the target transaction system verification platform 1 is respectively communicated with the production log backup server 2 and the preset storage medium 3. First, the target transaction system verification platform 1 responds to the instruction to generate a test case triggered by the corresponding client, obtains the test case format corresponding to the underlying service included in the target transaction system and parses it, and obtains the address and identifier of the data required for the test case format, that is, the address and identifier of the data required for the request message format, the response message format, and the expected result format. Then, according to the request message format and the address of the data required for the reply message format, the transaction log file is obtained in the production log backup server 2, and according to the corresponding identifier, the optical character recognition strategy is used to respectively identify and extract the request message format and the data required for the reply message format in the transaction log file. Further, according to the address of the data required for the request message format, the reply message format and the expected result format, the service transaction data is obtained in the preset storage medium 3, and according to the corresponding identifier, the data required for the request message format, the reply message format and the expected result format are respectively obtained in the service transaction data. Finally, the data required for the request message format, the reply message format and the expected result format are respectively assembled, and the request message, the reply message and the expected result are generated based on the assembly result, so as to generate the test case corresponding to the underlying service. Among them, the number of underlying services included in the target transaction system is multiple, and the test case format corresponding to the underlying service can be pre-stored in the preset storage medium 3, or can be stored in other databases. This embodiment does not limit this. In order to clearly illustrate the acquisition process of the test case format corresponding to the underlying service, this embodiment takes the preset storage medium 3 as an example for description.
[0041] The test case generation and verification method, device, equipment, storage medium and program product provided in this application are intended to solve the above technical problems in the prior art.
[0042] 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.
[0043] Figure 2 A flowchart of a test case generation method provided in an embodiment of the present application is shown in FIG. Figure 2 As shown, the execution subject of this embodiment is a test case generation device. The test case generation device is located in an electronic device, such as a server corresponding to a target trading system verification platform, the target trading system verification platform is used to verify the target trading system, and the target trading system includes multiple underlying services. The test case generation method provided in this embodiment includes the following steps:
[0044] S201, obtain the test case format corresponding to the underlying service and parse it to obtain the address and identifier of the data required by the test case format. The test case includes a request message, a response message and an expected result.
[0045] The target transaction system verification platform is any electronic device for verifying the operation of the system, such as a server, and is specifically used to verify the target transaction system. The target transaction system is an updated transaction system. The transaction system is a system with transaction functions, and can specifically provide customers with various transaction-related services, such as financial services, transfer services, etc. This embodiment does not limit the specific use of the transaction service.
[0046] Among them, the underlying service is the smallest service unit that the trading system can provide.
[0047] For example, if the services included in the trading system include financial management services, and the financial management services also include query services for a certain financial product, and the query service does not include other sub-services, then the query service is one of the smallest service units that the trading system can provide, that is, the underlying service.
[0048] It is understandable that the target trading system includes more than one service, and the included service further includes more than one sub-service, so the target trading system includes multiple underlying services. Verification of the target trading system is essentially verification of the underlying services included in the target trading service.
[0049] The test case format is the format that the pre-set prediction case should have, and the test case includes a request message, a response message, and an expected result. Furthermore, the request message is a message corresponding to the relevant instructions initiated to the underlying service, the response message is a message that the underlying service should feedback under the instruction of the above request message, and the expected result is the result of the underlying service responding to the above request message under normal circumstances.
[0050] In this embodiment, the R&D personnel can configure the corresponding test case formats, i.e., the formats of request messages, response messages, and expected results, for each underlying service included in the target transaction service in advance, and configure the address and corresponding identifier of the required data in each format based on the data required to form the request message, response message, and expected result. Then, in response to obtaining the test case formats corresponding to the underlying services included in the target transaction service, the request message format, response message format, and expected result format are obtained according to the identity identifiers of the request message, response message, and expected result, such as the number, name, etc., and each format is parsed to obtain the address and identifier of the data required for the request message format, the address and identifier of the data required for the response message format, and the address and identifier of the data required for the expected result format.
[0051] Exemplarily, if the data required by the request message format is a specific name, and the specific name is stored in A, then based on the above specific name, the address "A" and the field where the name is located can be configured in the format. This example is only an example and should not constitute any limitation to this application.
[0052] It is understandable that the above analysis results can be provided in the form of key-value pairs, that is, a list of key-Values. This embodiment does not limit the specific form of the analysis results.
[0053] S202, according to the request message format and the address of the data required for the response message format, obtain the transaction log file in the production log backup server, and according to the corresponding identifier, use the optical character recognition strategy to respectively identify and extract the request message format and the data required for the response message format in the transaction log file.
[0054] Among them, the optical character recognition strategy is a strategy that can recognize information media in various formats, such as images, files and other information media.
[0055] It can be understood that the transaction log file is a log file generated by the transaction system during operation, which may specifically include the messages involved in the operation process. Therefore, the main data required for the request message format and the response message format are all located in the transaction log file. Based on this, in response to obtaining the request message format and the address and identifier of the data required for the response message format, first obtain the transaction log file in the server according to the request message format and the address of the data required for the response message format, that is, the production log backup server. Then, an optical character recognition strategy is used to scan and identify the transaction log file, and the request message format and the identifier of the data required for the response message format are determined, so that based on the recognition result and the determination result, the fields where the request message format and the data required for the response message format are located are extracted from the transaction log file.
[0056] Optionally, after extracting the request message format and the data required for the response message format in the production log backup server, the required data can be stored in a storage medium that temporarily stores data, such as a memory, to facilitate acquisition in a short time and save storage resources.
[0057] S203, according to the address of the data required for the request message format, the response message format and the expected result format, obtain the service transaction data in the preset storage medium, and according to the corresponding identifier, obtain the data required for the request message format, the response message format and the expected result format in the service transaction data respectively.
[0058] It is understandable that the service transaction data is the transaction data generated by the transaction system during operation, and specifically may include the status data of the transaction system when executing the transaction. Therefore, the data required for the expected result message is located in the service transaction data, and part of the data required for the request message format and the response message format, such as the transaction party information, is also located in the service transaction data. Based on this, in response to obtaining the address and identifier of the data required for the request message format, the response message format, and the expected result format, the service transaction data is first obtained in the preset storage medium according to the address of the data required for each format, that is, the preset storage medium. Then, the identifier of the data required for the request message format, the response message format, and the expected result format is determined, and based on the determination result, the fields where the data required for the request message format, the response message format, and the expected result format are located are extracted from the service transaction data.
[0059] Optionally, after obtaining the required data for the request message format, response message format and expected result format in the service transaction data, the required data may also be stored in a storage medium for temporary data storage, such as a memory, to facilitate acquisition in a short time and save storage resources.
[0060] S204, assembling the data required for the request message format, the response message format and the expected result format respectively, and generating the request message, the response message and the expected result based on the assembly results, so as to generate the test case corresponding to the underlying service.
[0061] In this embodiment, the required data of the request message format, response message format and expected result format are obtained, and the required data corresponding to each format is assembled according to the specific requirements of each format, and based on the request message format, response message format and expected result format that have been assembled corresponding to the required data, the request message, response message and expected result are generated, thereby generating test cases corresponding to each underlying service included in the target transaction system.
[0062] The test case generation method provided in this embodiment forms a test case based on a request message, a response message, and an expected result. Therefore, by acquiring the test case format corresponding to the underlying service and parsing it, the address and identifier of the data required for the test case format can be obtained, that is, the address and identifier of the data required for the request message format, the address and identifier of the data required for the response message, and the address and identifier of the data required for the expected result. By acquiring the transaction log file in the production log backup server according to the request message format and the address of the data required for the response message format, the optical character recognition strategy can be further used to identify and extract the transaction log files in the transaction log file according to the corresponding identifiers. Take the request message format and the data required for the response message format. Similarly, by obtaining the service transaction data in the preset storage medium according to the addresses of the data required for the request message format, the response message format and the expected result format, the required data for the request message format, the response message format and the expected result format can be obtained in the service transaction data according to the corresponding identifiers. Then, by respectively assembling the data required for the request message format, the response message format and the expected result format, the request message, the response message and the expected result can be generated based on the assembly results, thereby generating test cases corresponding to the underlying services, improving the accuracy of the test cases, and further improving the reliability of the system verification results.
[0063] As an optional embodiment, based on the above embodiment, this embodiment further includes the following steps before obtaining the test case format corresponding to the underlying service and parsing it:
[0064] Step a1: receiving a configuration request sent by a control interface, wherein the configuration request includes a plurality of preset underlying service identifiers and a mapping relationship between each preset underlying service identifier and a corresponding test case format.
[0065] The configuration request is a request for instructing the target transaction system verification platform to configure a test case corresponding to an underlying service, specifically including a plurality of preset underlying service identifiers and a mapping relationship between each preset underlying service identifier and a corresponding test case format.
[0066] The preset underlying service identifier is an identifier that represents the identity of the preset underlying service, such as the name and number of the preset underlying service. The specific form of the preset underlying service identifier is not limited in this embodiment. The preset underlying service is various preset underlying services.
[0067] It is understandable that the premise of obtaining the test case format corresponding to the underlying service is that the test case format corresponding to the underlying service has been currently configured.
[0068] Based on this, the R&D personnel can set the corresponding test case format for each preset underlying service through the control interface of the target transaction system verification platform, and build a mapping relationship between each preset underlying service identifier and its corresponding test case format, so as to trigger the confirmation button where the configuration request is located in the above control interface based on the construction result. Correspondingly, the target transaction system verification platform receives the configuration request sent by the control interface based on the operation of the R&D personnel.
[0069] Step a2: configure the test case format corresponding to each preset underlying service according to the mapping relationship.
[0070] In this embodiment, in response to receiving a configuration request sent by the control interface, multiple preset underlying service identifiers and the mapping relationship between each preset underlying service identifier and the corresponding test case format are obtained in the request, and the test case format corresponding to each preset underlying service is automatically configured according to the above mapping relationship.
[0071] The test case generation method provided in this embodiment, since the premise of obtaining the test case format corresponding to the underlying service is that the test case format corresponding to the underlying service has been configured, the configuration request including multiple preset underlying service identifiers and the mapping relationship between each preset underlying service identifier and the corresponding test case format sent by the receiving control interface can configure the test case format corresponding to each preset underlying service according to the mapping relationship. Thus, the test case format corresponding to the underlying service is pre-configured, so that the test case format of the underlying service can be successfully obtained later, thereby improving the success rate of the subsequent execution process.
[0072] As an optional embodiment, in this embodiment Figure 2 On the basis of the corresponding embodiment, before obtaining the transaction log file in the production log backup server and obtaining the service transaction data in the preset storage medium, the following steps are also included:
[0073] Step b1, obtaining an initial transaction log file based on the production log backup server, and obtaining initial service transaction data based on a preset storage medium.
[0074] The initial transaction log file is an unprocessed original transaction log file, and the initial service transaction data is an unprocessed original service transaction data.
[0075] It is understandable that the initial transaction log file is stored in the production log backup server in real time when the transaction system is running, and the initial service transaction data is stored in the preset storage medium in real time when the transaction system is running, and there may be exceptions in the operation of the transaction system. Therefore, some data in the initial transaction log file and the initial service transaction data may be abnormal, and these abnormal data need to be processed for application in the generation of test cases.
[0076] Based on this, before obtaining the transaction log file and the service transaction data, the initial transaction log file is first obtained based on the production log backup server, and the initial service transaction data is obtained based on the preset storage medium.
[0077] Step b2: verify the legitimacy of the contents of the initial transaction log file and the initial service transaction data.
[0078] Among them, the legality verification is to verify the logical rationality and range of certain data. The logical rationality verification is to verify the basic information of the data, such as data type, dictionary value, length, and whether the data is repeated or wrong, etc. The range verification is to verify the data indicating specific values to ensure that these data do not exceed the normal value range.
[0079] Specifically, the contents of the initial transaction log file and the initial service transaction data are verified for logical rationality and range in turn to determine whether the basic data information included in the above contents is correct and compliant, and whether the data indicating specific numerical values is within a pre-set normal value range.
[0080] Step b3, desensitize the initial transaction log file and initial service transaction data when the verification is passed, and obtain and repair the illegal content when the verification fails, and desensitize it after repair to obtain the transaction log file and service transaction data.
[0081] Among them, desensitization processing is processing performed on sensitive information, such as replacing sensitive information with randomly generated information, or using an encryption algorithm to convert the field where the sensitive information is located into ciphertext. This embodiment does not limit the specific desensitization processing method used.
[0082] In this embodiment, if the above judgment result is yes, it is determined that the verification is passed, and the sensitive fields in the initial transaction log file and the initial service transaction data, such as the specific amount, are desensitized. If the above judgment result is no, it is determined that the verification is not passed, and the illegal content is obtained and repaired, and the sensitive fields in the repaired initial transaction log file and the initial service transaction data are desensitized to obtain the transaction log file and the service transaction data.
[0083] When repairing illegal content, specifically: for content with logical rationality errors, adjustments can be made according to pre-set basic information specifications, and / or duplicate data and erroneous data can be deleted. For content with range errors, data indicating specific values can be adjusted according to pre-set range requirements.
[0084] Step b4, storing the transaction log file in the production log backup server, and storing the service transaction data in a preset storage medium.
[0085] In this embodiment, after the transaction log file and the service transaction data are obtained, the transaction log file is stored in the production log backup server according to the original storage path, and the service transaction data is stored in the preset storage medium.
[0086] The test case generation method provided in the present embodiment stores unprocessed initial transaction log files and initial service transaction data in the production log backup server and the preset storage medium by default. Therefore, by obtaining the initial transaction log file based on the production log backup server and the initial service transaction data based on the preset storage medium, the legality of the contents of the initial transaction log file and the initial service transaction data can be verified. When the verification passes, the initial transaction log file and the initial service transaction data can be desensitized. When the verification fails, the illegal content is obtained and repaired, and desensitized after the repair, so as to obtain the transaction log file and service transaction data of the test case suitable for the underlying service. By storing the transaction log file in the production log backup server and the service transaction data in the preset storage medium, it is ensured that the transaction log file and the service transaction data obtained subsequently can be read correctly, thereby improving the success rate of obtaining the required data in each format subsequently.
[0087] As an optional embodiment, this embodiment, based on any of the above embodiments, further includes the following steps:
[0088] Step c1, in response to a failure in the assembly process, determining whether the data in which the failure occurred is constant data.
[0089] Among them, constant data refers to data whose value does not change during the operation of the service, such as the name of the transaction party, contact information, etc.
[0090] It is understandable that failures may occur during the assembly process. For example, if the data required by the request message requires information of five fields, but the information acquisition of these five fields fails during assembly, in this case, in order to ensure smooth assembly, it is necessary to further determine whether the data in which the failure occurs is constant data.
[0091] Based on this, in response to a failure in the assembly process of the request message, the response message, and the expected result, the data in which the failure occurred is obtained and the category to which the data belongs is determined, and it is determined whether the data is constant data based on the above category.
[0092] Exemplarily, if the data where the failure occurs is "12345" and the category of the data is the transaction party number, it can be determined that the data is constant data.
[0093] Step c2: if yes, replace the faulty data with the preset default value. If no, delete the faulty data.
[0094] The preset default values are preset default values for different categories of constant data.
[0095] In this embodiment, if the data that fails is constant data, it means that the data that fails is fixed under normal circumstances, and assigning a default value that conforms to its original specification can ensure that the underlying service can operate normally, then the preset default value corresponding to the constant data is obtained, and the preset default value is used to replace the data that fails. If the data that fails is not constant data, it means that the data that fails may depend on the status of the service, user input or other dynamic factors, and replacing it with a default value may cause logical errors or inconsistencies, then the data that fails is deleted.
[0096] In the test case generation method provided by this embodiment, since a failure may occur during the assembly process, when it is determined that a failure occurs during the assembly process, by judging whether the data where the failure occurs is constant data, the data where the failure occurs can be replaced with a preset default value when it is determined to be constant data, and the data where the failure occurs can be directly deleted when it is determined not to be constant data. This avoids the failure of test case generation due to assembly failure, and improves the success rate and efficiency of test case generation.
[0097] As an optional embodiment, based on any of the above embodiments, after generating a request message, a response message and an expected result based on the assembly result to generate a test case corresponding to the underlying service, this embodiment further includes the following steps:
[0098] Step d1, sending the preset playback strategy, and the request message and response message corresponding to the underlying service to the target trading system, so that the target trading system runs the underlying service according to the playback target, playback sequence and playback times indicated by the preset playback strategy.
[0099] The preset revisit strategy is a strategy that needs to be followed when the target transaction system is replayed, which may specifically include a replay target, a replay order, and a replay count.
[0100] The playback target is the underlying service that needs to be played back. The playback order is the specific playback order when playing back the underlying service that needs to be played back. The playback count is the number of times the underlying service that needs to be played back needs to be played back.
[0101] In this embodiment, the developer can set the preset playback strategy through the control interface in advance, and configure the playback environment, including but not limited to configuring the network environment, configuring the initialization database and user information, etc., and then trigger the playback instruction based on the request message and response message corresponding to the underlying service. Based on this, the target trading system verification platform sends the preset playback strategy, as well as the request message and response message corresponding to the underlying service to the target trading system based on the triggering of the above instructions.
[0102] Optionally, before sending the preset playback strategy and the request and response messages corresponding to the underlying services to the target transaction system, the request and response messages corresponding to the underlying services to be sent can be cleaned according to the specific needs of the R&D personnel to retain the content with testing significance and save computing resources.
[0103] Step d2, receiving the playback result returned by the target transaction system, and determining whether the playback result is the same as the expected result corresponding to the underlying service.
[0104] The playback result is a result of the target transaction system playing back the request message and the response message corresponding to the underlying service.
[0105] In this embodiment, after the target trading system runs the underlying service using corresponding request messages and response messages according to the playback target, playback order, and playback times indicated by the preset playback strategy, in response to receiving the playback result returned by the target trading system, the playback result is compared with the expected result corresponding to the underlying service to determine whether the two are the same.
[0106] Step d3, obtaining a preset report template, and embedding the judgment result and the test case corresponding to the underlying service into the corresponding position of the preset report template to obtain a target report.
[0107] Among them, the preset report template is a pre-made report template.
[0108] The judgment result is a result of judging whether the playback result is the same as the expected result corresponding to the underlying service, which may specifically include the same or different.
[0109] The target report is a report reflecting the verification results of the target trading system.
[0110] In this embodiment, the R&D personnel can prepare a preset report template in advance and specify the location of the modules included in the report. Then, after obtaining the judgment result, the preset report template is obtained, and the judgment result and the test case corresponding to the underlying service, that is, the request message, response message and expected result are embedded in the corresponding position of the preset report template to obtain the target report.
[0111] Step d4, displaying the target report on the control interface.
[0112] In this embodiment, after the target report is obtained, the target report is displayed on the control interface so that the R&D personnel can adjust the target trading system according to the specific content in the target report.
[0113] The test case generation method provided in this embodiment, since the preset playback strategy is pre-set, by sending the preset playback strategy, and the request message and response message corresponding to the underlying service to the target transaction system, the target transaction system can run the underlying service according to the playback target, playback order and playback number indicated by the preset playback strategy, and by receiving the playback result returned by the target transaction system, it can be judged whether the playback result is the same as the expected result corresponding to the underlying service, so that by obtaining the preset report template, the judgment result and the test case corresponding to the underlying service can be embedded in the position corresponding to the preset report template to obtain the target report, and the target report is displayed on the control interface. In this way, the test case obtained based on the real environment is used for verification, which improves the accuracy of verification, and enables R&D personnel to smoothly obtain the verification results and improve the user experience.
[0114] Figure 3 A flowchart of a test case verification method provided in an embodiment of the present application is shown in FIG. Figure 3 As shown, the execution subject of this embodiment is a test case verification device. The test case verification device is located in an electronic device, such as a server corresponding to a target trading system. The target trading system includes multiple underlying services. The test case verification provided by this embodiment includes the following steps:
[0115] S301, receiving a preset playback strategy sent by a target transaction system verification platform, as well as a request message and a response message corresponding to an underlying service.
[0116] In this embodiment, the target transaction system responds to the sending operation of the target transaction system verification platform, receives the preset playback strategy sent by the target transaction system verification platform, and the request message and response message corresponding to the underlying service.
[0117] S302: According to the playback target, playback order, and playback times indicated by the preset playback strategy, the request message is used to run the underlying service, and the actual response message of the underlying service is verified based on the response message.
[0118] The actual response message is a response message actually generated after the underlying service of the target transaction system runs according to the content of the request message.
[0119] In this embodiment, the playback target, playback order, and playback times indicated by the preset playback strategy are obtained, and the underlying service indicated by the playback target is run according to the playback order and playback times. Specifically, the request message corresponding to the underlying service is used as input, and the underlying service responds to the input and generates a corresponding actual response message. Further, it is verified whether the generated actual response message is consistent with the response message corresponding to the underlying service to obtain a verification result.
[0120] S303, obtaining the verification result and the operation data of the underlying service to obtain the playback result, and sending the playback result to the target transaction system verification platform.
[0121] The operation data is the operation data generated when the underlying service responds to the request message, which may include the processing result of the request message, the runtime service status data, etc.
[0122] In this embodiment, after obtaining the above-mentioned verification results, the operation data of the underlying service is obtained based on the corresponding database, and a playback result is formed based on the verification result and the operation data, and a sending instruction is triggered based on the playback result, so that the playback result is sent to the target transaction system verification platform.
[0123] Among them, when forming the playback result, the specific content of the playback result can be set according to specific needs. For example, based on the result of successful or failed processing of the request message, the playback result containing the "success" or "failure" field can be output, or the playback result can be output for the specified content in the verification result and the operation data. This embodiment does not limit the specific content of the playback result.
[0124] It is understandable that the playback result will eventually be compared with the expected result, and therefore the specific content of the playback result needs to correspond to the content of the expected result.
[0125] In the test case verification method provided in this embodiment, since the target transaction system verification platform sends the preset playback strategy and the request message and response message corresponding to the underlying service to the target transaction system, the target transaction system receives the preset playback strategy and the request message and response message corresponding to the underlying service, and runs the underlying service using the request message according to the playback target, playback sequence and playback times indicated by the preset playback strategy, and can verify the actual response message of the underlying service based on the response message, and can further obtain the verification result and the operation data of the underlying service, that is, the playback result, so as to send the playback result to the target transaction system verification platform. In this way, playback is performed based on the test case obtained according to the real environment, and the accuracy of the playback result is improved.
[0126] Figure 4A signaling interaction diagram of a test case generation and verification method provided in an embodiment of the present application, such as Figure 4 As shown, this embodiment exemplarily shows the complete process of the test case generation and verification method.
[0127] S401. The target transaction system verification platform receives a configuration request sent by a control interface, where the configuration request includes a plurality of preset underlying service identifiers and a mapping relationship between each preset underlying service identifier and a corresponding test case format.
[0128] S402: The target transaction system verification platform configures the test case format corresponding to each preset underlying service according to the mapping relationship.
[0129] S403, the target transaction system verification platform obtains and parses the test case format corresponding to the underlying service to obtain the address and identifier of the data required by the test case format. The test case includes a request message, a response message, and an expected result.
[0130] S404: The target transaction system verification platform obtains an initial transaction log file based on the production log backup server, and obtains initial service transaction data based on a preset storage medium.
[0131] S405. The target transaction system verification platform verifies the legitimacy of the contents of the initial transaction log file and the initial service transaction data, and determines whether the verification is passed. If so, execute S406 and continue to execute S408. If not, execute S407 and continue to execute S408.
[0132] S406: The target transaction system verification platform performs desensitization processing on the initial transaction log file and the initial service transaction data to obtain the transaction log file and the service transaction data.
[0133] S407. The target transaction system verification platform obtains and repairs the illegal content, and performs desensitization processing after the repair to obtain transaction log files and service transaction data.
[0134] S408. The target transaction system verification platform stores the transaction log file in the production log backup server, and stores the service transaction data in a preset storage medium.
[0135] S409: The target transaction system verification platform obtains the transaction log file from the production log backup server according to the request message format and the address of the data required by the response message format.
[0136] S410. The target transaction system verification platform uses an optical character recognition strategy to identify and extract the request message format and the data required for the response message format from the transaction log file according to the corresponding identifier.
[0137] S411. The target transaction system verification platform obtains service transaction data in a preset storage medium according to the address of the data required by the request message format, the response message format and the expected result format.
[0138] S412. The target transaction system verification platform obtains the data required for the request message format, the response message format and the expected result format in the service transaction data according to the corresponding identifier.
[0139] S413. The target transaction system verification platform assembles the data required for the request message format, the response message format and the expected result format respectively.
[0140] S414. In response to a failure in the assembly process, the target transaction system verification platform determines whether the failed data is constant data. If so, execute S415 and continue to execute S417. If not, execute S416 and continue to execute S417.
[0141] S415. The target trading system verification platform uses preset default values to replace the failed data.
[0142] S416: The target transaction system verification platform deletes the failed data.
[0143] S417. The target transaction system verification platform generates a request message, a response message, and an expected result based on the assembly result to generate a test case corresponding to the underlying service.
[0144] S418. The target trading system verification platform sends the preset playback strategy, as well as the request message and response message corresponding to the underlying service to the target trading system.
[0145] S419: The target transaction system receives the preset playback strategy, as well as the request message and response message corresponding to the underlying service.
[0146] S420. The target transaction system runs the underlying service using the request message according to the playback target, playback order, and playback times indicated by the preset playback strategy, and verifies the actual response message of the underlying service based on the response message.
[0147] S421. The target trading system obtains the verification result and the operation data of the underlying service to obtain the playback result, and sends the playback result to the target trading system verification platform.
[0148] S422: The target transaction system verification platform receives the playback result and determines whether the playback result is the same as the expected result corresponding to the underlying service.
[0149] S423. The target transaction system verification platform obtains a preset report template, and embeds the judgment result and the test case corresponding to the underlying service into the position corresponding to the preset report template to obtain a target report.
[0150] S424. The target transaction system verification platform displays the target report on the control interface.
[0151] Figure 5 A schematic diagram of the structure of a test case generation device provided in an embodiment of the present application is shown in FIG. Figure 5 As shown, the test case generating device provided in this embodiment is located in an electronic device, such as a server corresponding to a target transaction system verification platform. The test case generating device 50 provided in this embodiment includes: a processing module 51 and a generating module 52.
[0152] Among them, the processing module 51 is used to obtain the test case format corresponding to the underlying service and parse it to obtain the address and identifier of the data required for the test case format; the test case includes a request message, a response message and an expected result; according to the request message format and the address of the data required for the response message format, the transaction log file is obtained in the production log backup server, and according to the corresponding identifier, the optical character recognition strategy is used to respectively identify and extract the request message format and the data required for the response message format in the transaction log file; according to the address of the data required for the request message format, the response message format and the expected result format, the service transaction data is obtained in a preset storage medium, and according to the corresponding identifier, the data required for the request message format, the response message format and the expected result format are respectively obtained in the service transaction data; the data required for the request message format, the response message format and the expected result format are respectively assembled; the generation module 52 is used to generate the request message, the response message and the expected result based on the assembly result to generate the test case corresponding to the underlying service.
[0153] The test case generation device provided in this embodiment can be executed Figure 2 The specific implementation principles and technical effects of the method embodiments shown are similar and will not be repeated here.
[0154] Optionally, the test case generating device 50 provided in this embodiment further includes: a transceiver module.
[0155] Among them, the transceiver module is used to receive the configuration request sent by the control interface before the processing module 51 obtains and parses the test case format corresponding to the underlying service, and the configuration request includes multiple preset underlying service identifiers and the mapping relationship between each preset underlying service identifier and the corresponding test case format; the processing module 51 is also used to configure the test case format corresponding to each preset underlying service according to the mapping relationship.
[0156] Optionally, the processing module 51 is also used to obtain a transaction log file in a production log backup server, and, before obtaining the service transaction data in a preset storage medium, obtain an initial transaction log file based on the production log backup server, and obtain initial service transaction data based on the preset storage medium; perform legitimacy verification on the contents of the initial transaction log file and the initial service transaction data; perform desensitization processing on the initial transaction log file and the initial service transaction data when the verification passes, and obtain and repair illegal content when the verification fails, and perform desensitization processing after repair to obtain a transaction log file and service transaction data; store the transaction log file in the production log backup server, and store the service transaction data in the preset storage medium.
[0157] Optionally, the processing module 51 is also used to respond to a failure in the assembly process and determine whether the failed data is constant data; if so, replace the failed data with a preset default value; if not, delete the failed data.
[0158] Optionally, the transceiver module is also used to generate a request message, a response message and an expected result based on the assembly result of the generation module 52 to generate a test case corresponding to the underlying service, and then send the preset playback strategy, as well as the request message and response message corresponding to the underlying service to the target transaction system, so that the target transaction system runs the underlying service according to the playback target, playback order and playback number indicated by the preset playback strategy; the transceiver module is also used to receive the playback result returned by the target transaction system, and the processing module 51 is also used to determine whether the playback result is the same as the expected result corresponding to the underlying service; obtain a preset report template, and embed the judgment result and the test case corresponding to the underlying service into the position corresponding to the preset report template to obtain the target report; and display the target report on the control interface.
[0159] The test case generation device provided in this embodiment can execute any of the above method embodiments. The specific implementation principles and technical effects are similar and will not be repeated here.
[0160] Figure 6 A schematic diagram of the structure of a test case verification device provided in an embodiment of the present application is shown in FIG. Figure 6 As shown, the test case verification device provided in this embodiment is located in an electronic device, such as a server corresponding to a target transaction system. Then, the test case verification device 60 provided in this embodiment includes: a transceiver module 61 , a processing module 62 , and a verification module 63 .
[0161] Among them, the transceiver module 61 is used to receive the preset playback strategy sent by the target trading system verification platform, as well as the request message and response message corresponding to the underlying service; the processing module 62 is used to run the underlying service using the request message according to the playback target, playback order and playback number indicated by the preset playback strategy; the verification module 63 is used to verify the actual response message of the underlying service based on the response message; the processing module 62 is also used to obtain the verification result and the operation data of the underlying service to obtain the playback result; the transceiver module 61 is also used to send the playback result to the target trading system verification platform.
[0162] The test case verification device provided in this embodiment can be executed Figure 3 The specific implementation principles and technical effects of the method embodiments shown are similar and will not be repeated here.
[0163] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the electronic device 70 provided in this embodiment includes: a processor 71, a memory 72 communicatively connected to the processor, and a transceiver 73.
[0164] The transceiver 73 is used to send and receive data; the memory 72 stores computer-executable instructions; and the processor 71 executes the computer-executable instructions stored in the memory to implement the test case generation and verification method provided by any of the above embodiments. The relevant description can be understood by referring to the relevant descriptions and effects corresponding to the steps in the accompanying drawings, and no further details are given here.
[0165] The program may include program codes, and the program codes include computer-executable instructions. The memory 72 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.
[0166] In this embodiment, the memory 72 and the processor 71 are connected via a bus. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.
[0167] The embodiment of the present application also provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, they are used to implement the test case generation and verification method provided in any of the above embodiments. For example, the computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.
[0168] An embodiment of the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the test case generation and verification method provided in any one of the above embodiments.
[0169] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.
[0170] It should be further noted that, although the various steps in the flowchart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.
[0171] It should be understood that the above-mentioned device embodiments are only illustrative, and the device of the present application can also be implemented in other ways. For example, the division of units / modules in the above-mentioned embodiments is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.
[0172] In addition, unless otherwise specified, each functional unit / module in each embodiment of the present application may be integrated into one unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The above-mentioned integrated unit / module may be implemented in the form of hardware or in the form of a software program module.
[0173] If the integrated unit / module is implemented in the form of hardware, the hardware may be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes but is not limited to transistors, memristors, etc. Unless otherwise specified, the processor may be any appropriate hardware processor, such as a CPU, a GPU, an FPGA, a DSP, an ASIC, etc. Unless otherwise specified, the storage unit may be any appropriate magnetic storage medium or magneto-optical storage medium, such as a resistive random access memory (RRAM), a dynamic random access memory (DRAM), a static random access memory (SRAM), an enhanced dynamic random access memory (EDRAM), a high-bandwidth memory (HBM), a hybrid memory cube (HMC), etc.
[0174] If the integrated unit / module is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a memory, including a number of instructions to enable a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned memory includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.
[0175] In the above embodiments, the description of each embodiment has its own emphasis. For the part not described in detail in a certain embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0176] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.
[0177] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.
Claims
1. A test case generation method, characterized in that: The method is applied to a target trading system verification platform, the target trading system verification platform is used to verify a target trading system, the target trading system includes a plurality of underlying services, and the method includes: Obtaining and parsing the test case format corresponding to the underlying service to obtain the address and identifier of the data required by the test case format; the test case includes a request message, a response message, and an expected result; According to the request message format and the address of the data required for the reply message format, a transaction log file is obtained in the production log backup server, and according to the corresponding identifier, an optical character recognition strategy is used to respectively identify and extract the request message format and the data required for the reply message format in the transaction log file; Acquire service transaction data in a preset storage medium according to the addresses of the data required for the request message format, the response message format, and the expected result format, and acquire the data required for the request message format, the response message format, and the expected result format respectively from the service transaction data according to the corresponding identifiers; The data required for the request message format, the response message format and the expected result format are respectively assembled, and the request message, the response message and the expected result are generated based on the assembly results to generate the test case corresponding to the underlying service.
2. The method according to claim 1, characterized in that Before obtaining and parsing the test case format corresponding to the underlying service, the method further includes: Receive a configuration request sent by the control interface, wherein the configuration request includes a plurality of preset underlying service identifiers and a mapping relationship between each preset underlying service identifier and a corresponding test case format; According to the mapping relationship, configure the test case format corresponding to each preset underlying service.
3. The method according to claim 1, characterized in that Before obtaining the transaction log file in the production log backup server and obtaining the service transaction data in the preset storage medium, the method further includes: Acquiring an initial transaction log file based on the production log backup server, and acquiring initial service transaction data based on the preset storage medium; Performing legality verification on the contents of the initial transaction log file and the initial service transaction data; When the verification is passed, the initial transaction log file and the initial service transaction data are desensitized, and when the verification is not passed, illegal content is obtained and repaired, and desensitized after repair to obtain the transaction log file and service transaction data; The transaction log file is stored in the production log backup server, and the service transaction data is stored in the preset storage medium.
4. The method according to any one of claims 1 to 3, characterized in that: Also includes: In response to a failure in the assembly process, determining whether the data in which the failure occurred is constant data; If so, the faulty data is replaced by a preset default value; If not, the failed data is deleted.
5. The method according to any one of claims 1 to 3, characterized in that: After generating a request message, a response message and an expected result based on the assembly result to generate a test case corresponding to the underlying service, the method further includes: Sending a preset playback strategy, and a request message and a response message corresponding to the underlying service to a target trading system, so that the target trading system runs the underlying service according to the playback target, playback sequence, and playback times indicated by the preset playback strategy; Receiving the playback result returned by the target transaction system, and determining whether the playback result is the same as the expected result corresponding to the underlying service; Obtain a preset report template, and embed the judgment result and the test case corresponding to the underlying service into the position corresponding to the preset report template to obtain a target report; The target report is displayed on a control interface.
6. A test case verification method, characterized in that: The method is applied to a target transaction system, the target transaction system includes a plurality of underlying services, and the method includes: Receive the preset playback strategy sent by the target trading system verification platform, as well as the request message and response message corresponding to the underlying service; According to the playback target, playback order, and playback times indicated by the preset playback strategy, the request message is used to run the underlying service, and an actual response message of the underlying service is verified based on the response message; The verification result and the operation data of the underlying service are obtained to obtain a playback result, and the playback result is sent to the target transaction system verification platform.
7. A test case generating device, characterized in that: include: A processing module, used to obtain and parse the test case format corresponding to the underlying service to obtain the address and identifier of the data required by the test case format; the test case includes a request message, a response message and an expected result; According to the request message format and the address of the data required for the reply message format, a transaction log file is obtained in the production log backup server, and according to the corresponding identifier, an optical character recognition strategy is used to respectively identify and extract the request message format and the data required for the reply message format in the transaction log file; according to the address of the data required for the request message format, the reply message format and the expected result format, service transaction data is obtained in a preset storage medium, and according to the corresponding identifier, the data required for the request message format, the reply message format and the expected result format are respectively obtained in the service transaction data; Assemble the data required for the request message format, the response message format and the expected result format respectively; A generation module is used to generate a request message, a response message and an expected result based on the assembly result to generate a test case corresponding to the underlying service.
8. A test case verification device, characterized in that: include: The transceiver module is used to receive the preset playback strategy sent by the target transaction system verification platform, as well as the request message and response message corresponding to the underlying service; A processing module, configured to run the underlying service using the request message according to the playback target, playback order, and playback number indicated by the preset playback strategy; A verification module, used to verify the actual response message of the underlying service based on the response message; The processing module is further used to obtain the verification result and the operation data of the underlying service to obtain the playback result; The transceiver module is also used to send the playback result to the target transaction system verification platform.
9. An electronic device, characterized in that: include: A processor, a memory and a transceiver communicatively connected to the processor; The memory stores computer-executable instructions; the transceiver is used to send and receive data; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 6.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 6 when executed by a processor.
11. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 6 when being executed by a processor.