CN114020613A

CN114020613A - Transaction posting test processing method and device, computer equipment and storage medium

Info

Publication number: CN114020613A
Application number: CN202111264397.1A
Authority: CN
Inventors: 侯睿; 王砺磊
Original assignee: Ping An Technology Shenzhen Co Ltd
Current assignee: Ping An Technology Shenzhen Co Ltd
Priority date: 2021-10-28
Filing date: 2021-10-28
Publication date: 2022-02-08

Abstract

The invention discloses a transaction posting test processing method and device, computer equipment and a storage medium. The method comprises the following steps: acquiring original test data; adopting an authorized transaction test script to carry out an authorized transaction test on the original test data to obtain authorized transaction test data; adopting an entry test script to carry out entry test on the authorized transaction test data to obtain entry test data; performing state detection on the posting test data by adopting a state detection script to acquire a data state corresponding to the posting test data; if the data state is an unavailable state, acquiring an unavailable type corresponding to the posting test data; and determining a target processing script according to the unavailable type corresponding to the posting test data, and recovering or cleaning the posting test data by adopting the target processing script. The method can simplify the processing link of the transaction posting test, improve the efficiency of the investigation and maintenance processing, contribute to saving the storage space and contribute to ensuring the operation efficiency of the system.

Description

Transaction posting test processing method and device, computer equipment and storage medium

Technical Field

The invention relates to the technical field of automatic testing, in particular to a transaction posting test processing method and device, computer equipment and a storage medium.

Background

In the development process of a credit card system, a payment system or other financial systems, a transaction posting processing link exists, so that in the development process of the financial systems, test data related to the transaction posting needs to be generated in advance, and the transaction posting processing link in the developed system is tested by utilizing the test data, so that the developed system can ensure the realization of the transaction posting function. In the existing financial system, a system link related to transaction posting is long, so that when a problem exists in a transaction posting test processing process, a large amount of cost is consumed for problem troubleshooting, and the development progress of the financial system is seriously influenced; moreover, the result data with problems can not be used continuously, which can cause the automatic test system to redundantly store a large amount of unusable data, and the unusable data can cause the system to operate slowly and the waste of system resources is serious.

Disclosure of Invention

The embodiment of the invention provides a transaction posting test processing method, a transaction posting test processing device, computer equipment and a storage medium, and aims to solve the problems of high troubleshooting cost and resource waste caused by long system links in the conventional transaction posting test process.

A transaction posting test processing method, comprising:

acquiring original test data corresponding to the target posting identifier;

adopting an authorized transaction test script corresponding to the target posting identifier to perform an authorized transaction test on the original test data to obtain authorized transaction test data;

adopting an entry test script corresponding to the target entry mark to perform entry test on the authorized transaction test data to acquire entry test data;

performing state detection on the posting test data by adopting a state detection script corresponding to the target posting identifier to acquire a data state corresponding to the posting test data;

if the data state corresponding to the posting test data is an unavailable state, acquiring an unavailable type corresponding to the posting test data;

and determining a target processing script according to the unavailable type corresponding to the posting test data, and recovering or cleaning the posting test data by adopting the target processing script.

A transaction posting test processing apparatus comprising:

the original test data acquisition module is used for acquiring original test data corresponding to the target posting identifier;

the transaction test data acquisition module is used for performing authorized transaction test on the original test data by adopting an authorized transaction test script corresponding to the target posting identifier to acquire authorized transaction test data;

the checking-in test data acquisition module is used for performing checking-in test on the authorized transaction test data by adopting a checking-in test script corresponding to the target checking-in identification to acquire the checking-in test data;

the data state acquisition module is used for carrying out state detection on the posting test data by adopting a state detection script corresponding to the target posting identifier to acquire a data state corresponding to the posting test data;

the unavailable type obtaining module is used for obtaining an unavailable type corresponding to the posting test data if the data state corresponding to the posting test data is an unavailable state;

and the posting test data processing module is used for determining a target processing script according to the unavailable type corresponding to the posting test data and adopting the target processing script to recover or clean the posting test data.

A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the transaction posting test processing method when executing the computer program.

A computer-readable storage medium, in which a computer program is stored, which, when executed by a processor, implements the transaction posting test processing method described above.

According to the transaction posting test processing method, the transaction posting test processing device, the computer equipment and the storage medium, the authorized transaction test script and the posting test script corresponding to the target posting identification are adopted to sequentially test the original test data, and the transaction posting processing link of the target financial system is simulated, so that the formed posting test data can truly reflect the result of the original test data after being processed through the transaction posting processing link of the target financial system, and the processing link of the transaction posting test can be simplified. By adopting the state detection script corresponding to the target posting identifier, the corresponding data state can be quickly determined, so that posting test data in an unavailable state can be quickly checked, and the data checking efficiency is ensured; according to the unavailable type corresponding to the posting test data, the target processing script is adopted to carry out maintenance processing such as recovery or cleaning on the posting test data, so that the posting test data in an unavailable state can be effectively reduced, the efficiency of the troubleshooting and maintenance processing is improved, the storage space is saved, and the system operation efficiency is ensured.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive labor.

FIG. 1 is a diagram illustrating an application environment of a transaction posting test processing method according to an embodiment of the invention;

FIG. 2 is a flowchart of a transaction posting test processing method according to an embodiment of the invention;

FIG. 3 is another flow chart of a transaction posting test processing method according to an embodiment of the invention;

FIG. 4 is another flow chart of a transaction posting test processing method according to an embodiment of the invention;

FIG. 5 is another flow chart of a transaction posting test processing method according to an embodiment of the invention;

FIG. 6 is another flow chart of a transaction posting test processing method according to an embodiment of the invention;

FIG. 7 is another flow chart of a transaction posting test processing method according to an embodiment of the invention;

FIG. 8 is another flow chart of a transaction posting test processing method according to an embodiment of the invention;

FIG. 9 is a diagram illustrating an exemplary transaction posting test processing apparatus according to the present invention;

FIG. 10 is a schematic diagram of a computer device according to an embodiment of the invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The transaction posting test processing method provided by the embodiment of the invention can be applied to the application environment shown in fig. 1. Specifically, the transaction posting test processing method is applied to an automatic test system, the automatic test system comprises a client and a server shown in fig. 1, the client and the server are communicated through a network and are used for realizing the automated test of a transaction posting function in any financial system, the system processing link of the transaction posting can be reduced, the problem of slow operation and resource waste caused by a large amount of redundant unavailable data of the system can be solved, and the problem of timely and rapid checking of the posting test data with problems can be solved. The client is also called a user side, and refers to a program corresponding to the server and providing local services for the client. The client may be installed on, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server may be implemented as a stand-alone server or as a server cluster consisting of a plurality of servers.

In an embodiment, as shown in fig. 2, a transaction posting test processing method is provided, which is described by taking the server in fig. 1 as an example, and includes the following steps:

s201: acquiring original test data corresponding to the target posting identifier;

s202: adopting an authorized transaction test script corresponding to the target posting identifier to perform an authorized transaction test on the original test data to obtain authorized transaction test data;

s203: adopting an account entry test script corresponding to the target account entry identification to perform an account entry test on the authorized transaction test data and obtain the account entry test data;

s204: performing state detection on the posting test data by adopting a state detection script corresponding to the target posting identifier to acquire a data state corresponding to the posting test data;

s205: if the data state corresponding to the posting test data is an unavailable state, acquiring an unavailable type corresponding to the posting test data;

s206: and determining a target processing script according to the unavailable type corresponding to the posting test data, and recovering or cleaning the posting test data by adopting the target processing script.

The target posting identifier is an identifier for uniquely identifying a specific scene of transaction posting corresponding to the target financial system. The target financial system is the financial system targeted by the test. For example, the target financial system may be a credit card system and, accordingly, the target posting identifier is a credit card posting identifier.

Raw test data refers to pre-generated untested data.

As an example, in step S201, the server may obtain, from the scene data pool corresponding to the target posting identifier, original test data corresponding to the target posting identifier, that is, original test data related to transaction posting corresponding to the target financial system, so as to perform a transaction posting test using the original test data. Wherein the scene data pool is a collection of raw test data for storing a particular scene. For example, when the target posting identifier is a credit card posting identifier, raw test data relating to transaction posting of the credit card system is obtained from the scene data pool.

Further, the server can execute a state monitoring task, monitor all existing test data in the scene data pool to obtain a data state corresponding to each existing test data, determine the existing test data with the data state being an available state as original test data related to transaction posting, and the original test data can be understood as data which needs to be subjected to transaction posting tests subsequently. The state monitoring task is used for monitoring whether the existing test data is occupied or not. The existing test data is the test data stored in the scene data pool at the current time. The data state is a state for reflecting whether existing test data is occupied or not. Understandably, the data state of the existing test data may be any one of an occupied state and an available state, where the occupied state refers to a state where the existing test data is occupied for testing, and the available state refers to a state where the existing test data is not occupied for testing

The authorized transaction test script corresponding to the target posting identifier is a test script created in a test scenario of performing authorized transaction on the target financial system. The authorized transaction test data refers to test data which is output by an authorized transaction test script after the input original test data is tested by the authorized transaction test script.

As an example, in step S202, the server tests the original test data by using the authorized transaction test script corresponding to the target posting identifier, and determines an output result of the authorized transaction test script as the authorized transaction test data.

For example, when the target posting identifier is a credit card posting identifier, the authorization transaction test script may receive an input parameter of original test data, simulate a card swiping action of the POS machine and a background execution action of the POS machine, complete a test process corresponding to the authorization transaction, and obtain authorization transaction test data, which may be understood as data for performing subsequent tests formed after the authorization transaction of the credit card system is completed.

And the posting test script corresponding to the target posting identifier is a test script created by a test scene of posting for the target financial system. The posting test data is data formed by testing the authorized transaction test data by adopting a posting test script.

As an example, in step S203, the server uses the posting test script corresponding to the target posting identifier to test the authorized transaction test data, and determines an output result of the posting test script as the posting test data. In this example, the posting test script may receive an input parameter of authorized transaction test data output by the authorized transaction test script, simulate a credit card background to implement data synchronization, splice authorized transaction test data formed by all authorized transactions corresponding to the same account, and obtain spliced test data to implement data synchronization of all authorized transaction test data corresponding to the same account; and finally, simulating system posting operation based on the splicing test data to acquire posting test data.

For example, when the target posting identifier is a credit card posting identifier, an authorized transaction test script and a posting test script are adopted to realize the automatic test of the credit card authorized transaction stage and the credit card posting stage, starting from the authorized transaction, a transaction link in the simulation production is opened, the data transmission of the credit card transaction posting full link is opened, the corresponding posting operation is automatically completed, and the authenticity and the consistency of all test data are ensured.

In this example, each original test data stored in the scene data pool carries a unique data identifier, an authorized transaction test script is adopted to perform an authorized transaction test on the original test data, and the formed authorized transaction test data also carries the same data identifier; and adopting the posting test script to perform posting test on the authorized transaction test data, wherein the formed posting test data also carries the same data identifier. Therefore, the original test data, the authorized transaction test data and the posting test data carry the same data identification, so that the source tracing is performed based on the data identification, and the posting test data with problems can be conveniently and quickly checked in the follow-up process.

Understandably, the authorized transaction test script and the posting test script corresponding to the target posting identifier are adopted to test the original test data in sequence, a transaction posting processing link of the target financial system is simulated, so that the posting test data can truly reflect the result of the original test data after being processed by the transaction posting processing link of the target financial system, the transaction posting processing link can be simplified, and the transaction posting test process only needs to be processed by the authorized transaction test script and the posting test script, and the posting test data with problems can be conveniently and quickly checked, so that the development progress of the target financial system is ensured.

Wherein the state detection script is a script for detecting whether the test data is available. As an example, the state detection script corresponding to the target posting identifier refers to a script set according to the test data corresponding to the target posting identifier and all unavailable situations. For example, when the target financial system is tested for a credit card system transaction posting scenario, a status detection script for detecting whether the test data is available or not may be set according to the situation that all credit cards are unavailable, so that the data status of the posted test data is quickly determined by using the status detection script.

The data state corresponding to the posting test data comprises an available state and an unavailable state. The available state here refers to a state in which the posting test data can be continuously called for software testing. The unavailable state is a state in which the posting test data cannot be called on to conduct a software test.

As an example, in step S204, the server may perform status detection on the posting test data by using a status detection script corresponding to the target posting identifier to determine whether the posting test data is still called to perform a software test, so as to obtain a data status corresponding to the posting test data, where the data status may be an available status or an unavailable status.

In this example, the state detection script is a detection script configured in advance according to at least one unavailable evaluation condition, and when the state detection script is used for performing state detection on the posting test data, the posting test data is specifically compared with the at least one unavailable evaluation condition; if the posting test data does not meet all the unavailable evaluation conditions, the data state corresponding to the posting test data is an available state; and if the posting test data meets any unavailable evaluation condition, the data state corresponding to the posting test data is an unavailable state.

For example, in a scenario where the target financial system is a credit card system test, if a certain credit card is in an unavailable state when not being paid for in time, a state detection script can be configured according to an evaluation condition corresponding to the untimely payment of the credit card, so that when the state detection script detects the check-in test data, whether the check-in test data meets the unavailable evaluation condition corresponding to the untimely payment of the credit card is evaluated; if the test data is in accordance with the test data, the data state corresponding to the posting test data is an unavailable state; and if not, the data state corresponding to the posting test data is an available state.

The unavailable type is a type used for reflecting whether the posting test data in the unavailable state can be recovered to the available state, and comprises a recoverable type and an unrecoverable type. In this example, the recoverable type is a type in which the posting test data can be recovered from an unavailable state to an available state. For example, an authorized transaction test and an accounting test are performed on original test data of a credit card system, and the formed accounting test data is mainly that when an account is unavailable due to untimely payment, the unavailable type of the accounting test data is a recoverable type. Accordingly, the unrecoverable type is a type in which the posting test data cannot be restored from an unavailable state to an available state. For example, an authorization transaction test and an accounting test are performed on original test data of a credit card system, and the formed accounting test data is mainly that when an account is unavailable due to the fact that the service life of a credit card reaches the longest life or the card is cancelled, the unavailable type of the accounting test data is an unrecoverable type.

As an example, in step S205, when determining that the data status corresponding to a certain posting test data is in an unavailable status, the server needs to classify the posting test data in the unavailable status to determine an unavailable type corresponding to the posting test data, so as to perform different data processing on the posting test data according to the unavailable type, so as to prevent the system from storing a large amount of redundant and unavailable posting test data.

In this example, when the data state corresponding to the posting test data is the unavailable state, it is described that the posting test data satisfies an unavailable evaluation condition configured in advance by the state detection script, and the corresponding unavailable type can be quickly determined according to the unavailable evaluation condition. For example, an information table of correspondence between the unavailable evaluation condition and the unavailable type thereof may be configured in advance, and the unavailable type thereof may be determined quickly based on the unavailable evaluation condition table that is satisfied by the posting test data.

Wherein the target processing script is a configuration processing script matching the unavailable type. The configuration processing script is a script for realizing processing operations such as recovery or cleaning of test data.

As an example, in step S206, the server stores configuration processing scripts corresponding to all unavailable types in advance, and after determining an unavailable type corresponding to a certain posting test data, the configuration processing script corresponding to the unavailable type may be determined as a target processing script, and the target processing script is executed to perform recovery or cleaning processing on the posting test data. In this example, the posting test data whose unavailable type is the recoverable type is subjected to recovery processing so as to be converted into an available state; the method has the advantages that the posting test data with the unavailable type as the unrecoverable type are cleaned, the posting test data in the unavailable state in the system can be reduced, and the problem that the posting test data in the unavailable state is redundant, so that the system runs slowly and the storage and calculation resources of the system are wasted is avoided.

In the transaction posting test processing method provided by the embodiment of the invention, the authorized transaction test script and the posting test script corresponding to the target posting identifier are adopted to sequentially test the original test data, and the transaction posting processing link of the target financial system is simulated, so that the formed posting test data can truly reflect the result of the original test data after being processed by the transaction posting processing link of the target financial system, and the processing link of the transaction posting test can be simplified. By adopting the state detection script corresponding to the target posting identifier, the corresponding data state can be quickly determined, so that posting test data in an unavailable state can be quickly checked, and the data checking efficiency is ensured; according to the unavailable type corresponding to the posting test data, the target processing script is adopted to carry out maintenance processing such as recovery or cleaning on the posting test data, so that the posting test data in an unavailable state can be effectively reduced, the efficiency of the troubleshooting and maintenance processing is improved, the storage space is saved, and the system operation efficiency is ensured.

In an embodiment, as shown in fig. 3, the step S201 of acquiring original test data corresponding to the target posting identifier includes:

s301: acquiring a data preparation instruction, wherein the data preparation instruction comprises a target posting identifier and a target data volume;

s302: determining the existing test data with the data state being the available state in a scene data pool corresponding to the target posting identifier as available test data, and counting the available data volume corresponding to the available test data;

s303: if the available data volume is larger than or equal to the target data volume, determining available test data corresponding to the target data volume from the scene data pool as original test data corresponding to the target posting identifier;

s304: and if the available data volume is smaller than the target data volume, determining the newly added data volume according to the target data volume and the available data volume, generating newly added test data corresponding to the newly added data, and determining the original test data corresponding to the target posting identifier according to the available test data and the newly added test data.

The data preparation instruction is an instruction for triggering preparation of original test data. The target data amount refers to the amount of original test data that needs to be prepared for the present test.

As an example, in step S301, the server may receive a data preparation instruction triggered by the user through the client, where the data preparation instruction includes a target posting identifier and a target data volume, the target posting identifier is used to uniquely identify a target financial system to which the posting of the transaction is directed, and the target data volume is used to determine a data volume of original test data required for posting the transaction.

The existing test data refers to data which are stored in a scene data pool corresponding to the target posting identifier before the current time of the system and are used for testing. Available test data refers to existing test data that was stored prior to the current time of the system with the data state in the available state.

As an example, in step S302, the server may monitor a data state corresponding to each existing test data in the scene data corresponding to the target posting identifier, and the monitoring process is the same as the monitoring of the data state corresponding to the posting test data in step S204, which is not repeated here to avoid repetition. Then, the server may determine existing test data in the scene data pool corresponding to the target posting identifier, the data state of which is an available state, as available test data. And finally, the server counts the number of all available test data in the scene data pool corresponding to the target posting identifier, and determines the available data amount corresponding to the available test data so as to determine whether additional new test data needs to be generated according to the comparison result of the available data amount and the target data amount.

As an example, in step S303, when the available data amount is greater than or equal to the target data amount, the server directly determines the available test data corresponding to the target data amount as the original test data related to credit card posting, and can quickly acquire the original test data corresponding to the target data amount to guarantee feasibility of the posting test operation, and does not need to wait for execution of generation time for generating the original test data, which is helpful for guaranteeing processing efficiency of the posting test operation.

As an example, in step S304, when the available data amount is smaller than the target data amount, the server may determine a difference between the target data amount and the available data amount as a new data amount, may generate new test data corresponding to the new data amount by using a pre-generated data generation task or a data generation script, and determine the available test data corresponding to the available data amount and the new test data corresponding to the new data amount as original test data related to credit card entry.

In an embodiment, as shown in fig. 4, after the step S402, that is, after the new test data matching the new data amount is generated, the transaction posting test processing method further includes:

s401: obtaining a host batch date corresponding to the newly added test data, and comparing the host batch date with the current date of the system;

s402: and if the host batch date is not consistent with the current date of the system, updating the host batch date corresponding to the newly added test data to the current date of the system.

The host batch date is the date of generation of the data recorded in the newly added test data. The current date of the system refers to the current date the system is operating.

As an example, after executing the data generation task and generating the target test data matching the amount of the newly added data, the server needs to compare the host batch date corresponding to each newly added test data with the current system date to determine whether the host batch date is consistent with the current system date. And when the host batch date is inconsistent with the current system date, the server needs to update the host batch date corresponding to the newly added test data to the current system date so as to realize synchronization of the host batch date of the newly added test data and the current system date, thereby avoiding the problem of failure to enter accounts due to inconsistency of the host batch date and the current system date and ensuring the reliability of the transaction entry test of the newly added test data.

In an embodiment, as shown in fig. 5, the step S304 of generating new test data corresponding to the new data processing includes:

s501: acquiring a data generation task corresponding to a target posting identifier, wherein the data generation task comprises at least one target action and a scene parameter value corresponding to a posting configuration parameter;

s502: and executing the number making action script corresponding to at least one target action according to the scene parameter value corresponding to the posting configuration parameter, and generating new test data matched with the new data volume.

As an example, in step S401, the server may obtain a data generation task corresponding to the target posting identifier, where the data generation task includes at least one target action and a scene parameter value corresponding to the posting configuration parameter. For example, the server may control the client to display a task configuration interface corresponding to the target posting identifier, and the user may determine at least one target action among a plurality of standard actions provided by the task configuration interface, and when the target actions include at least two, the order of the actions needs to be determined; and displaying a parameter configuration interface corresponding to the target action, and inputting a scene parameter value corresponding to the posting configuration parameter in the parameter configuration interface to obtain a data generation task corresponding to the target posting identifier, so that the data generation task comprises at least one target action and the scene parameter value corresponding to the posting configuration parameter. The standard action refers to an action included in a system to be tested corresponding to the target financial system.

For example, where the target financial system is a scenario suitable for credit card system testing, its posting configuration parameters may need to be categorized as follows: the method comprises the steps of classifying and sorting the posting requirements, supporting the construction of test data corresponding to a plurality of standard actions corresponding to all card organization channel transactions (UnionPay multi-channel, self-channel, EC, VISA, JCB, MASTER), test data corresponding to a plurality of standard actions corresponding to all types of forward and reverse transactions (consumption, cash-taking, forward-flushing, withdrawal, return and the like), constructing test data corresponding to a plurality of standard actions corresponding to each period data (not started, returned for 1 period, returned for the like), constructing various scene data such as posted data, non-posted data and the like, and supporting various scene data combinations such as reserve fund + staged + self-channel non-posted data and the like.

In this example, when receiving at least two target actions selected by a user, a server needs to obtain a configuration sequence of the at least two target actions autonomously determined by the user, perform action verification on the configuration sequence of the at least two target actions, and obtain an action verification result; if the action verification result is that the verification is passed, determining that the at least two target actions are determined to be successful; and if the action verification result is that the verification fails, prompting action configuration error information so that a user can modify the action configuration error information.

In this example, the server performs action verification on the configuration sequence of the at least two target actions, and is specifically configured to verify whether the configuration sequence of the at least two target actions conforms to the business logic of the target financial system. For example, when the target financial system is a scene suitable for testing a credit card system, according to the service logic of the target financial system, the credit card transactions need to sequentially pass through standard actions such as card issuing, card binding registration, activation and control, if the sequence of the four standard actions selected by the user meets the requirements, the user is determined to meet the service logic, and an action verification result that the verification passes is obtained; if the sequence of the four standard actions selected by the user for card issuing, card binding registration, activation and regulation does not meet the requirement, the user is determined not to meet the service logic, and an action verification result that the verification fails is obtained.

As an example, in step S402, the server executes the data generating task, specifically, according to the scene parameter value corresponding to the posting configuration parameter, executes the number-making action script corresponding to at least one target action, and generates new test data matching with the new data amount, so as to obtain the new test data meeting the test requirement. In this example, the server may use a scene parameter value of the posting configuration parameter as a script input parameter of the number-of-manufacture action script corresponding to the at least one target action, sequentially execute the number-of-manufacture action script corresponding to the at least one target action according to a dependency relationship between the at least one target action, determine an output result of the last executed number-of-manufacture action script as new test data, and finally generate new test data matched with the new data amount, so that the new test data may be applied to a transaction payment function corresponding to the target financial system for software testing. The manufactured action script is a script configured in advance for generating test data corresponding to a certain action.

In an embodiment, as shown in fig. 6, before the step S201, before acquiring the original test data corresponding to the target posting identifier, the transaction posting test processing method further includes:

s601: acquiring a script generation instruction, wherein the script generation instruction comprises a target posting identifier and a target action;

s602: acquiring a target scene action tree corresponding to the target posting identifier, wherein the target scene action tree is a tree structure formed by sequencing all standard actions corresponding to the target posting identifier according to the service logic of the target posting identifier;

s603: determining whether the target action has a dependent action according to the target position of the target action in the target scene action tree;

s604: if the target action has the dependent action, determining a parameter to be configured corresponding to the target action based on an action output parameter corresponding to the dependent action and an action input parameter corresponding to the target action;

s605: if the target action does not have a dependent action, determining a parameter to be configured corresponding to the target action based on an action input parameter corresponding to the target action;

s606: and generating a number making action script corresponding to the target action according to the data generation rule corresponding to the target action and the parameter to be configured.

The script generation command is a command for triggering generation of a model operation script.

As an example, in step S601, the server may receive a script generation instruction triggered by a user, where the script generation instruction carries a target posting identifier and a target action, so as to generate an artificial number action script corresponding to the target action in the target financial system.

The target scene action tree is a tree structure formed by sequencing all standard actions corresponding to the target posting identifier according to the service logic of the target posting identifier.

As an example, in step S602, the server stores in advance candidate scene action trees corresponding to different candidate scene identifiers, where each candidate scene action tree is a tree structure formed by sorting all standard actions in the candidate application scene based on the service logic corresponding to the candidate application scene corresponding to the candidate scene identifier. And the server determines the scene action tree to be selected matched with the target posting identifier as the target scene action tree according to the target posting identifier carried in the script generating instruction after receiving the script generating instruction.

Where a dependent action refers to an action that must be performed before the target action is performed.

As an example, in step S603, the server may query the target scene action tree according to the target action, determine a target position of the target action in the target scene action tree, and determine whether there is another standard action between the target position and the root node; if other standard actions exist between the target position and the root node, determining that a dependent action exists; and if no other standard action exists between the target position and the root node, determining that no dependent action exists. Understandably, the target action is one of all standard actions in the target scene action tree, and one of all standard actions from the root node to the target position can be determined as the closest target action in the target scene action tree according to the target position of the target action in the target scene action tree.

The action output parameter of the dependent action refers to a parameter which is output after the execution of the dependent action and is used for calling the target action. The action input parameters corresponding to the target action refer to parameters which need to be input in the execution process of the target action. The parameter to be configured corresponding to the target action is a parameter required to be configured for executing the number making action script corresponding to the target action.

As an example, in step S604, when there is a dependent action in the target action, the server needs to determine the action output parameter corresponding to the dependent action and the action input parameter corresponding to the target action together as the parameter to be configured corresponding to the target action, that is, in the process of executing the number of each target action, the action output parameter corresponding to the dependent action and the action input parameter corresponding to the target action need to be configured in advance, so as to ensure that the parameter to be configured of the number-of-actions script can be configured independently, and the independence of the execution of the number-of-actions script can be ensured without depending on the execution of the dependent action.

As an example, in step S605, when the target action does not have a dependent action, the server only needs to determine the action input parameter corresponding to the target action as the parameter to be configured corresponding to the target action.

The data generation rule is a preset rule for meeting the target action generation requirement. For example, in the target action of issuing a credit card, the required data generation rule is required to form a corresponding credit card number according to the credit card number generation rule.

As an example, in step S606, the server may obtain a manufactured action script corresponding to the target action, which is formed by encoding according to the data generation rule corresponding to the target action and the parameter to be configured, and the manufactured action script may be executed on the server to generate original test data matching the target action.

In the transaction posting test processing method provided by this embodiment, whether a dependent action exists or not may be determined according to a target position of a target action in a target scene action tree, and then a parameter to be configured corresponding to the target action is determined in different manners, and then a number making action script corresponding to the target action is generated based on a data generation rule and the parameter to be configured, so that the independence of the number making action script may be ensured, so that all the number making action scripts may run independently, and a combined number making of at least one target action may be implemented, so that the obtained original test data more easily meet the user requirements.

In an embodiment, as shown in fig. 7, in step S206, determining a target processing script according to an unavailable type corresponding to the posted test data, and performing recovery or cleaning processing on the posted test data by using the target processing script, includes:

s701: if the unavailable type corresponding to the posting test data is a recoverable type, determining a data recovery script corresponding to the target posting identifier as a target processing script, and recovering the posting test data by adopting the data recovery script to obtain recovered test data;

s702: and if the unavailable type corresponding to the posting test data is the unrecoverable type, determining the data cleaning script as a target processing script, and cleaning the posting test data by adopting the data cleaning script.

The data recovery script is a script for recovering the posting test data from the unavailable state to the available state. In this example, each target posting identifier configures a data recovery script corresponding to a plurality of unavailability reasons, where the unavailability reasons match with the unavailability evaluation conditions in the status detection script.

As an example, in step S701, when determining that the unavailable type corresponding to the posting test data is the recoverable type, the server may recover the posting test data by using a data recovery script corresponding to the unavailable reason according to the unavailable reason corresponding to the posting test data, so as to obtain recovered test data. For example, if the unavailable reason of a certain entry test data is that payment is not timely made, a data recovery script corresponding to the untimely payment can be adopted to automatically repay the entry test data, so that the entry test data in the unavailable state is updated to the recovery test data in the available state, the redundancy of the entry test data in the unavailable state is avoided, the waste of system resources is caused, and the system operation efficiency is favorably ensured. The recovery test data is data generated when the posting test data is recovered by adopting a data recovery script.

The data cleaning script is used for cleaning the posting test data.

As an example, in step S702, when determining that the unavailable type corresponding to the posting test data is the recoverable type, the server indicates that the posting test data is completely unavailable, and if the posting test data is stored in the scene data pool or other databases for a long time, a large amount of posting test data in a redundant unavailable state may exist in the test environment, which may cause waste of system resources.

Understandably, the server can realize the data state of the check-in test data through the full link, intelligently analyze the unavailable reason of the check-in test data, and restore the reverse operation to the available state, thereby ensuring the availability of the recovered test data. For example, when the target financial system is a credit card scenario, the servers can be uniformly scheduled by the detection and repair method (interface or SQL) of the system configuration data on the full link of the credit card. For example: the card service system provides control code detection and release interfaces corresponding to the cards, the accounts and the clients, the server detects the control codes in real time and cannot appear in a normal scene when control exists, and meanwhile, the control codes are periodically released so that unavailable posting test data can be recovered to available recovery test data. For another example, the core accounting system provides an account available amount checking and repayment interface, the server checks the account available amount in real time, and if the account is insufficient, the account available amount will not appear in the consumption scene, and meanwhile, the repayment operation is executed periodically, and the data recovery can be used for recovering the unavailable posting test data to the available recovery test data.

In an embodiment, as shown in fig. 8, in step S701, that is, determining a data recovery script corresponding to the target posting identifier as a target processing script, and performing recovery processing on the posting test data by using the data recovery script to obtain recovered test data, the method includes:

s801: if the unavailable type corresponding to the check-in test data is a arrearage type, adopting an arrearage reason detection script to detect the check-in test data and determine the current arrearage reason;

s802: if the current debt reason is transaction debt, recovering the check-in test data by adopting a transaction repayment processing script to obtain recovery test data;

s803: and if the current debt reason is non-transaction debt, adopting an account entry and repayment processing script to recover the account entry test data and obtain recovery test data.

The arrears type refers to a type in which the posting test data is not available due to arrears. The arrears reason detection script is a script for realizing the arrears reason detection.

As an example, in step S801, when determining that the unavailable type corresponding to the posting test data is a recoverable type, the server may be the arrears type, or may be a non-arrears type other than the arrears type, for example, when the account is logged off or the age expires. When the unavailable type corresponding to the check-in test data is the arrearage type, the server can adopt a preset arrearage reason detection script to detect the check-in test data, and can acquire the current arrearage reason corresponding to the check-in test data. For example, the arrears reason detection script can be configured according to the specific situation of meeting the transaction arrears condition, and when the arrears reason detection script is adopted to detect the check-in test data, if the check-in test data meets the transaction arrears condition, the current arrears reason is determined as transaction arrears; correspondingly, if the posting test data does not meet the transaction arrears condition, the current arrears are determined to be non-transaction arrears.

The transaction repayment processing script is a processing script used for realizing authorized transaction repayment, namely a processing script which is configured in advance and used for realizing authorized transaction repayment on the account entry test data, and new test data is formed through two links of authorized transaction and account entry test.

As an example, in step S802, when determining that the current debt reason corresponding to a certain posting test data is transaction debt, and if the current debt reason is not timely repayment, the server may adopt a pre-configured transaction repayment processing script to perform recovery processing on the posting test data to simulate a transaction repayment operation corresponding to the target financial system, so as to obtain recovery test data, so that the newly formed recovery test data does not have the problem of not timely repayment, and update the posting test data in an unavailable state to the recovery test data in an available state, so as to avoid redundancy of the posting test data in the unavailable state, which causes waste of system resources, and help to ensure system operation efficiency.

The account entry and payment processing script is used for realizing account entry and payment. The method is characterized in that the method is used for realizing the entry and payment of the entry test data, and a new test data processing script is formed only through the test of the entry link.

As an example, in step S803, when it is determined that the current arrears corresponding to a certain posting test data are not timely paid due to non-transaction arrears, such as a rest fee and a foreign currency, the server may adopt a pre-configured posting and paying processing script to perform recovery processing on the posting test data to simulate a posting and paying operation corresponding to the target financial system to obtain recovery test data, so that the newly formed recovery test data does not have the problem of not timely paying, and the posting test data in the unavailable state is updated to the recovery test data in the available state, so as to avoid redundancy of the posting test data in the unavailable state, which leads to waste of system resources, and help to ensure system operation efficiency.

It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

In an embodiment, a transaction posting test processing device is provided, and the transaction posting test processing device corresponds to the transaction posting test processing methods in the embodiments one to one. As shown in fig. 9, the transaction posting test processing apparatus includes an original test data acquisition module 901, a transaction test data acquisition module 902, a posting test data acquisition module 903, a data state acquisition module 904, an unavailable type acquisition module 905, and a posting test data processing module 906. The functional modules are explained in detail as follows:

an original test data obtaining module 901, configured to obtain original test data corresponding to the target posting identifier;

a transaction test data obtaining module 902, configured to perform an authorized transaction test on the original test data by using an authorized transaction test script corresponding to the target posting identifier, and obtain authorized transaction test data;

an entry test data acquisition module 903, configured to perform an entry test on the authorized transaction test data by using an entry test script corresponding to the target entry identifier, and acquire entry test data;

a data state obtaining module 904, configured to perform state detection on the posting test data by using a state detection script corresponding to the target posting identifier, and obtain a data state corresponding to the posting test data;

an unavailable type obtaining module 905, configured to obtain an unavailable type corresponding to the posting test data if the data state corresponding to the posting test data is an unavailable state;

and the posting test data processing module 906 is configured to determine a target processing script according to the unavailable type corresponding to the posting test data, and recover or clean the posting test data by using the target processing script.

In one embodiment, the raw test data acquisition module 901 includes:

the data preparation instruction acquisition unit is used for acquiring a data preparation instruction, and the data preparation instruction comprises a target posting identifier and a target data volume;

the available data volume counting unit is used for determining the existing test data with the data state being the available state in the scene data pool corresponding to the target posting identifier as available test data and counting the available data volume corresponding to the available test data;

the first original data determining unit is used for determining available test data corresponding to the target data volume from the scene data pool as original test data corresponding to the target posting identifier if the available data volume is larger than or equal to the target data volume;

and the second original data determining unit is used for determining the newly added data volume according to the target data volume and the available data volume if the available data volume is smaller than the target data volume, generating newly added test data corresponding to the newly added data, and determining original test data corresponding to the target posting identifier according to the available test data and the newly added test data.

In one embodiment, the transaction posting test processing apparatus further includes:

the date comparison unit is used for acquiring the host batch date corresponding to the newly added test data and comparing the host batch date with the current date of the system;

and the date updating unit is used for updating the host batch date corresponding to the newly added test data to the current date of the system if the host batch date is inconsistent with the current date of the system.

In one implementation, the second raw data determining unit includes:

the data generation task acquisition subunit is used for acquiring a data generation task corresponding to the target posting identifier, wherein the data generation task comprises at least one target action and a scene parameter value corresponding to the posting configuration parameter;

and the number making action script execution subunit is used for executing the number making action script corresponding to at least one target action according to the scene parameter value corresponding to the posting configuration parameter, and generating new test data matched with the new data volume.

the script generation instruction unit is used for acquiring a script generation instruction, and the script generation instruction comprises a target posting identifier and a target action;

the scene action tree obtaining unit is used for obtaining a target scene action tree corresponding to the target posting identifier, and the target scene action tree is a tree structure formed by sequencing all standard actions corresponding to the target posting identifier according to the business logic of the target posting identifier;

the dependency action judging unit is used for determining whether the dependency action exists in the target action according to the target position of the target action in the target scene action tree;

the first configuration parameter determining unit is used for determining a to-be-configured parameter corresponding to the target action based on an action output parameter corresponding to the dependent action and an action input parameter corresponding to the target action if the target action has the dependent action;

the second configuration parameter determining unit is used for determining a parameter to be configured corresponding to the target action based on the action input parameter corresponding to the target action if the target action does not have a dependent action;

and the number making action script generating unit is used for generating the number making action script corresponding to the target action according to the data generating rule corresponding to the target action and the parameter to be configured.

In one embodiment, the posting test data processing module 906 includes:

the test data recovery processing unit is used for determining a data recovery script corresponding to the target posting identifier as a target processing script if the unavailable type corresponding to the posting test data is a recoverable type, and recovering the posting test data by adopting the data recovery script to acquire recovered test data;

and the test data cleaning processing unit is used for determining the data cleaning script as a target processing script if the unavailable type corresponding to the posting test data is the unrecoverable type, and cleaning the posting test data by adopting the data cleaning script.

In one embodiment, a test data recovery processing unit includes:

the debt reason determining subunit is used for detecting the check-in test data by adopting a debt reason detection script and determining the current debt reason if the unavailable type corresponding to the check-in test data is a debt type;

the first data recovery processing subunit is used for recovering the check-in test data by adopting a transaction repayment processing script if the current debt reason is transaction debt, and acquiring recovery test data;

and the second data recovery processing subunit is used for adopting the account entry and repayment processing script to recover the account entry test data and acquire the recovery test data if the current debt reason is non-transaction debt.

For the specific definition of the transaction posting test processing device, reference may be made to the above definition of the transaction posting test processing method, which is not described herein again. The modules in the transaction posting test processing device can be wholly or partially implemented by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as shown in fig. 10. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing data adopted or stored in the process of executing the transaction posting test processing method. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a transaction posting test processing method.

In an embodiment, a computer device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the transaction posting test processing method in the foregoing embodiments is implemented, for example, S201 to S206 shown in fig. 2, or shown in fig. 3 to 8, which is not described herein again to avoid repetition. Alternatively, the processor implements the functions of each module/unit in the transaction posting test processing apparatus in this embodiment when executing the computer program, for example, the functions of the original test data obtaining module 901, the transaction test data obtaining module 902, the posting test data obtaining module 903, the data state obtaining module 904, the unavailable type obtaining module 905, and the posting test data processing module 906 shown in fig. 9, and in order to avoid repetition, details are not described here again.

In an embodiment, a computer-readable storage medium is provided, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the transaction posting test processing method in the foregoing embodiments is implemented, for example, S201 to S206 shown in fig. 2, or shown in fig. 3 to fig. 8, which is not described herein again to avoid repetition. Alternatively, when being executed by the processor, the computer program implements the functions of the modules/units in the transaction posting test processing apparatus, for example, the functions of the original test data obtaining module 901, the transaction test data obtaining module 902, the posting test data obtaining module 903, the data state obtaining module 904, the unavailable type obtaining module 905, and the posting test data processing module 906 shown in fig. 9, and in order to avoid repetition, the descriptions thereof are omitted here.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present invention, and not for limiting the same; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present invention, and are intended to be included within the scope of the present invention.

Claims

1. A transaction posting test processing method is characterized by comprising the following steps:

acquiring original test data corresponding to the target posting identifier;

2. The transaction posting test processing method of claim 1, wherein the obtaining of the original test data corresponding to the target posting identifier comprises:

acquiring a data preparation instruction, wherein the data preparation instruction comprises a target posting identifier and a target data volume;

determining existing test data with a data state being an available state in a scene data pool corresponding to the target posting identifier as available test data, and counting the available data volume corresponding to the available test data;

if the available data volume is larger than or equal to the target data volume, determining available test data corresponding to the target data volume from the scene data pool as original test data corresponding to the target posting identifier;

and if the available data volume is smaller than the target data volume, determining a newly added data volume according to the target data volume and the available data volume, generating newly added test data corresponding to the newly added data, and determining original test data corresponding to the target posting identifier according to the available test data and the newly added test data.

3. The transaction posting test processing method according to claim 2, wherein after the generating of the additional test data that matches the amount of the additional data, the transaction posting test processing method further includes:

obtaining a host batch date corresponding to the newly added test data, and comparing the host batch date with the current date of the system;

and if the host batch date is not consistent with the current date of the system, updating the host batch date corresponding to the newly added test data to the current date of the system.

4. The transaction posting test processing method of claim 3, wherein the generating of the additional test data corresponding to the additional data processing comprises:

acquiring a data generation task corresponding to the target posting identifier, wherein the data generation task comprises at least one target action and a scene parameter value corresponding to a posting configuration parameter;

and executing at least one manufacture number action script corresponding to the target action according to the scene parameter value corresponding to the posting configuration parameter, and generating newly added test data matched with the newly added data volume.

5. The transaction posting test processing method of claim 4, wherein prior to obtaining the raw test data corresponding to the target posting identity, the transaction posting test processing method further comprises:

acquiring a script generation instruction, wherein the script generation instruction comprises a target posting identifier and a target action;

acquiring a target scene action tree corresponding to the target posting identifier, wherein the target scene action tree is a tree structure formed by sequencing all standard actions corresponding to the target posting identifier according to the business logic of the target posting identifier;

determining whether the target action has a dependent action according to the target position of the target action in the target scene action tree;

if the target action has a dependent action, determining a parameter to be configured corresponding to the target action based on an action output parameter corresponding to the dependent action and an action input parameter corresponding to the target action;

if the target action does not have a dependent action, determining a parameter to be configured corresponding to the target action based on an action input parameter corresponding to the target action;

and generating a number making action script corresponding to the target action according to the data generation rule corresponding to the target action and the parameter to be configured.

6. The transaction posting test processing method of claim 1, wherein the determining a target processing script according to the unavailable type corresponding to the posting test data, and performing recovery or cleaning processing on the posting test data by using the target processing script comprises:

if the unavailable type corresponding to the posting test data is a recoverable type, determining a data recovery script corresponding to the target posting identifier as a target processing script, and recovering the posting test data by adopting the data recovery script to obtain recovered test data;

and if the unavailable type corresponding to the posting test data is the unrecoverable type, determining a data cleaning script as a target processing script, and cleaning the posting test data by adopting the data cleaning script.

7. The transaction posting test processing method of claim 6, wherein the determining a data recovery script corresponding to the target posting identifier as a target processing script, and performing recovery processing on the posting test data by using the data recovery script to obtain recovery test data comprises:

if the unavailable type corresponding to the posting test data is a arrearage type, detecting the posting test data by adopting an arrearage reason detection script to determine the current arrearage reason;

if the current debt reason is transaction debt, recovering the posting test data by adopting a transaction repayment processing script to obtain recovery test data;

and if the current debt reason is non-transaction debt, adopting an account entry and repayment processing script to recover the account entry test data and obtain recovery test data.

8. A transaction posting test processing apparatus, characterized by comprising:

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor when executing the computer program implements a transaction posting test processing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, in which a computer program is stored, which, when being executed by a processor, implements a transaction posting test processing method according to any one of claims 1 to 7.