Transaction data testing method and device, equipment and storage medium
Through automated summary and sorting of transaction data and generation of transaction forms for verification, the problems of deviation and errors in transaction data transmission are solved, the verification speed and accuracy are improved, and the security of funds and property is ensured.
Patent Information
- Application Number
- CN202411332915.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-24
- Publication Date
- 2024-12-17
AI Technical Summary
The transaction data may be biased during the transmission process, or there are errors in the number and amount of transactions initiated by the initiator of the transaction action, resulting in the recipient of the fund requiring regular reconciliation and testing of transaction data such as statement information to ensure that the accounts are correct and funds are Transfer safety.
By responding to the data test request, determine the user to be tested, obtain the transaction data of all their trading actions, and add it to the pre-created use case template, generate a summary transaction template, perform data assembly, form transaction files and transaction forms, and finally, The table is verified to verify the accuracy of transaction data in an automated process.
It realizes automatic summary and sorting of transaction data, saves the manual verification process, improves verification speed and accuracy, and ensures the security of funds and property and the equality of transactions.
Smart Images
Figure CN119151681A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data testing technology, and in particular to a transaction data testing method, device, equipment and storage medium. Background Art
[0002] With the continuous development of economy and the promotion of Internet, it is very convenient and quick to use online banking, credit cards and other channels for shopping, payment, repayment and refund, so more and more users are using them. However, this online transaction process involving funds and money has high security requirements.
[0003] However, transaction data may be distorted during transmission, or the initiator of the transaction may make errors in the number and amount of transactions initiated. Therefore, the recipient of funds also needs to regularly reconcile and test transaction data such as statement information to ensure that the accounts are correct and the flow of funds is safe. Summary of the invention
[0004] In view of this, the present application provides a transaction data testing method, device, equipment and storage medium, which are used to solve the problem that transaction data may be deviated during the transmission process, or the initiator of the transaction action may have errors in the number and amount of transactions initiated.
[0005] To achieve the above objectives, the proposed solution is as follows:
[0006] In a first aspect, a method for testing transaction data includes:
[0007] In response to a request instruction for performing a data test, determining each user to be tested;
[0008] For each user to be tested, obtain the transaction data of all transaction actions of the user to be tested;
[0009] Add the transaction data of all transaction actions of the user to be tested to the pre-created use case template to obtain the summary transaction template corresponding to the user to be tested;
[0010] Assembling the transaction data of each transaction action of the user to be tested from the aggregated transaction template to obtain each transaction file of the user to be tested;
[0011] generating each transaction form based on each of the transaction files;
[0012] Each of the transaction forms is verified respectively to obtain a verification result of each transaction action of the user to be tested.
[0013] Preferably, in response to the request instruction for performing data testing, determining each user to be tested includes:
[0014] In response to a request instruction for performing a data test, obtaining each pending user corresponding to the request instruction;
[0015] Extracting historical transaction records of each pending user;
[0016] Determine whether the historical transaction record of each pending user is a blank record;
[0017] Each pending user whose historical transaction record is not a blank record is used as each pending test user.
[0018] Preferably, the transaction data of all transaction actions of the user to be tested is added to a pre-created use case template to obtain a summary transaction template corresponding to the user to be tested, including:
[0019] Determine the time when each transaction action of the user to be tested is initiated;
[0020] Sorting the transaction actions of the user to be tested in the order of time;
[0021] Based on the sorting, the transaction data of each transaction action of the user to be tested is added to a pre-created use case template to obtain a summary transaction template corresponding to the user to be tested.
[0022] Preferably, the transaction data of each transaction action of the user to be tested is respectively assembled from the aggregated transaction template to obtain each transaction file of the user to be tested, including:
[0023] Determine the transaction type to which each transaction action of the user to be tested belongs;
[0024] Determine the priority of each of the transaction types, and treat each transaction type with a priority greater than a preset level as each risk type;
[0025] For each risk type, extract the transaction data of each transaction action corresponding to the risk type from the summary transaction template, and assemble the data to obtain a risk transaction list corresponding to the risk type;
[0026] Treat each transaction action corresponding to each transaction type whose priority is not greater than the preset level as each common transaction action;
[0027] Extracting transaction data of each common transaction action from the summary transaction template, and assembling the data to obtain a common transaction list;
[0028] The common transaction list and each of the risky transaction lists are used as transaction files of the user to be tested.
[0029] Preferably, the step of assembling the transaction data of each transaction action of the user to be tested from the aggregated transaction template to obtain each transaction file of the user to be tested includes:
[0030] Determine the scenario parameters corresponding to the user to be tested;
[0031] Querying a link corresponding to the scene parameter;
[0032] Determine each execution unit corresponding to each transaction action of the user to be tested on the link;
[0033] Each execution unit on the link is called to execute the corresponding transaction actions respectively, so as to assemble the transaction data of each transaction action of the user to be tested in the summary transaction template to obtain each transaction file of the user to be tested.
[0034] Preferably, generating each transaction form based on each transaction file includes:
[0035] For each of the transaction files, determining a transaction type corresponding to the transaction file;
[0036] Set the table name according to the transaction type;
[0037] Obtaining the file size of the transaction file, and setting the number of table rows and the number of table columns based on the file size;
[0038] Create a table file according to the table name, the number of table rows and the number of table columns;
[0039] All transaction data in the transaction file are transferred to the table file to obtain the transaction table of the transaction file.
[0040] In a second aspect, a transaction data testing device includes:
[0041] A module for determining users to be tested, used to determine each user to be tested in response to a request instruction for performing a data test;
[0042] The transaction data acquisition module is used to acquire the transaction data of all transaction actions of each user to be tested;
[0043] A module for obtaining a summary transaction template is used to add the transaction data of all transaction actions of the user to be tested to a pre-created use case template to obtain a summary transaction template corresponding to the user to be tested;
[0044] A data assembly module, used to assemble the transaction data of each transaction action of the user to be tested from the summary transaction template to obtain each transaction file of the user to be tested;
[0045] A transaction table generating module, used for generating each transaction table based on each of the transaction files;
[0046] The verification module is used to verify each of the transaction forms respectively to obtain the verification results of each transaction action of the user to be tested.
[0047] Preferably, the to-be-tested user determination module comprises:
[0048] A pending user acquisition module, used to respond to a request instruction for performing a data test and acquire each pending user corresponding to the request instruction;
[0049] A historical transaction record extraction module, used to extract the historical transaction records of each of the pending users;
[0050] A judgment module, used to judge whether the historical transaction record of each pending user is a blank record;
[0051] The module for finalizing the users to be tested is used to select the users to be determined whose historical transaction records are not blank records as the users to be tested.
[0052] In a third aspect, a transaction data testing device includes a memory and a processor;
[0053] The memory is used to store programs;
[0054] The processor is used to execute the program to implement the various steps of the transaction data testing method as described in the first aspect.
[0055] In a fourth aspect, a storage medium stores a computer program, which, when executed by a processor, implements the various steps of the transaction data testing method as described in the first aspect.
[0056] It can be seen from the above technical scheme that the present application determines each user to be tested in response to a request instruction for data testing; for each user to be tested, obtains the transaction data of all transaction actions of the user to be tested; adds the transaction data of all transaction actions of the user to be tested to a pre-created use case template to obtain a summary transaction template corresponding to the user to be tested; assembles the transaction data of each transaction action of the user to be tested from the summary transaction template to obtain each transaction file of the user to be tested; generates each transaction table based on each transaction file; verifies each transaction table to obtain the verification result of each transaction action of the user to be tested. This solution first determines the user to be tested and obtains the transaction data of all transaction actions initiated by the user to be tested. Then, by adding the transaction data to the use case template, the transaction data can be summarized and organized, and the added summary transaction template is used to assemble the data to realize an automated process. There is no need for the recipient of funds to manually check each transaction data corresponding to the transaction initiator one by one, which can save the verification process. The assembled transaction file is then put into a table to generate a transaction form. Compared with the transaction file, the transaction form has a neat format and clear data. Therefore, verifying the transaction form can increase the accuracy of the verification compared to directly verifying the transaction file, and can speed up the verification speed, verify the errors or problems in the transaction data, and ensure the safety of funds and property and the equality of the transaction numbers between the two parties. BRIEF DESCRIPTION OF THE DRAWINGS
[0057] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.
[0058] Figure 1 An optional flow chart of a transaction data testing method provided in an embodiment of the present application;
[0059] Figure 2 A process for establishing a use case template provided in an embodiment of the present application;
[0060] Figure 3 A process of adding transaction data to a use case template provided in an embodiment of the present application;
[0061] Figure 4 A flow chart of a data assembly device provided in an embodiment of the present application;
[0062] Figure 5 A schematic diagram of the structure of a transaction data testing device provided in an embodiment of the present application;
[0063] Figure 6 A schematic diagram of the structure of a transaction data testing device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0064] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0065] With the continuous development of economy and the promotion of Internet, it is very convenient and quick to use online banking, credit cards and other channels for shopping, payment, repayment and refund, so more and more users are using them. However, this online transaction process involving funds and money has high security requirements.
[0066] However, transaction data may be distorted during transmission, or the initiator of the transaction may make errors in the number and amount of transactions initiated. Therefore, the recipient of funds also needs to regularly reconcile and test transaction data such as statement information to ensure that the accounts are correct and the flow of funds is safe.
[0067] The embodiment of the present invention provides a method for testing transaction data. The method can be applied to various computer terminals or intelligent terminals. The execution subject can be a processor or server of the computer terminal or intelligent terminal. The method flow chart of the method is as follows: Figure 1 As shown, specifically including:
[0068] S1: In response to a request instruction for performing a data test, each user to be tested is determined.
[0069] In this application, the initiator of the transaction data test process can be a third-party test verification system between the transaction initiator and the transaction receiver (fund receiver), or the transaction receiver. The purpose is to verify the alignment between the transaction action data of the transaction initiator and the final data. The user to be tested in this application is the transaction initiator to be tested, and the fund receiver can be a bank, etc.
[0070] It is understandable that some users have higher credit ratings, or some users are newly registered users. Therefore, without considering network problems, it can be assumed that the error rate of the transaction data of these users is lower, and there is no need to verify the transaction data of these users every time, which can improve the efficiency of verification testing.
[0071] S2: For each user to be tested, obtain the transaction data of all transaction actions of the user to be tested.
[0072] After each user to be tested is determined, the transaction data of all transaction actions initiated by each user to be tested is obtained, and each transaction data is tested / verified.
[0073] S3: Add the transaction data of all transaction actions of the user to be tested to the pre-created use case template to obtain the summary transaction template corresponding to the user to be tested.
[0074] In order to make the data neat and easy to test, this application has pre-created a use case template. Adding transaction data to the use case template can not only summarize all data to prevent omissions, but also directly take the added use case template for subsequent operations, thereby achieving automation as a whole. There is no need for the transaction initiator to send transaction data to the fund recipient one by one, nor is there a need for the fund recipient to take the data one by one for manual verification, which greatly improves the testing efficiency and also improves the work efficiency of the staff.
[0075] You can create a use case template for a user, and add all the transaction data of all transaction actions of the user to the corresponding use case template; or one transaction action can correspond to one use case template.
[0076] Optionally, the use case template may be added, deleted, modified, or checked at any time, such as updating the transaction data in the use case template, or performing data cleansing before use, which is not limited in this embodiment.
[0077] The process of establishing a use case template can refer to Figure 2 ,like Figure 2 As shown in the figure, in the window for creating a use case, you can set the use case name, such as a transaction event; the name of the user to be tested (userID); type, that is, transaction type, refers to the action type of the transaction action, such as borrowing, repayment, loan, refund, installment payment, etc., and multiple selections are allowed; start date and end date, the start date is the period when the use case template is first used, and the end date is the date when the test ends. The end date is not set in the current process. When the test ends, the use case template can automatically enter the current date; user layer batching refers to the use case template acting on the data assembly process of the transaction data of the transaction action of the user to be tested, channel layer batching refers to the use case template acting on the final transaction table generation process, and can also refer to the use case template acting on the fund recipient in the process of data testing or data verification at the terminal; remarks, you can add special circumstances of the user to be tested, such as early repayment, deferred repayment, etc., to record some abnormal operations of the user to be tested; observation points refer to observation time points, such as setting some time points, and checking the use case template at these time points to ensure the normal use of the use case template.
[0078] The process of adding transaction data for each transaction action in the use case template can be as follows: Figure 3 Please refer to Figure 3 , the transaction actions added to the use case template are numbered in the order of addition, such as action 1, action 2, action 3, etc., where the transaction type to which the transaction action belongs, the time when the action was initiated, whether it is in installments, the amount, etc. are entered.
[0079] S4: assembling the transaction data of each transaction action of the user to be tested from the aggregated transaction template to obtain each transaction file of the user to be tested.
[0080] In this step, the transaction data of each transaction action of each user to be tested are respectively assembled from the summary transaction template. The transaction data of each transaction action in the summary transaction template can be assembled according to time batches, or can be assembled according to the transaction type of the transaction action. It can also be assembled according to the user's category, user priority, user risk level, etc., and this embodiment does not impose any restrictions on this.
[0081] It should be noted that the number of transaction actions and the number of transaction files are not necessarily the same. This application can generate corresponding transaction files for the transaction data of each transaction action according to specific needs, or it can aggregate the transaction data of multiple transaction actions into one transaction file.
[0082] S5: Generate each transaction table based on each of the transaction files.
[0083] The transaction file can be considered as a file in word format. In comparison, the transaction table can more intuitively and clearly indicate whether the transaction data is correct or not, and the error problem is also more prominent. Therefore, this step generates a transaction table based on the transaction file.
[0084] S6: Verify each of the transaction tables respectively to obtain verification results of each of the transaction actions of the user to be tested.
[0085] After obtaining each transaction form, the data of the fund recipient can be obtained, and the pre-created automated test script can be executed to compare the transaction form with the data of the fund recipient. Specifically, the name of the form, the content of the form, the logical relationship of the account or funds in the form can be verified to obtain the verification result. If the verification result shows a problem, the staff can trace the source based on the verification result and track down the cause of the error.
[0086] It can be seen from the above technical scheme that the present application determines each user to be tested in response to a request instruction for data testing; for each user to be tested, obtains the transaction data of all transaction actions of the user to be tested; adds the transaction data of all transaction actions of the user to be tested to a pre-created use case template to obtain a summary transaction template corresponding to the user to be tested; assembles the transaction data of each transaction action of the user to be tested from the summary transaction template to obtain each transaction file of the user to be tested; generates each transaction table based on each transaction file; verifies each transaction table to obtain the verification result of each transaction action of the user to be tested. This solution first determines the user to be tested and obtains the transaction data of all transaction actions initiated by the user to be tested. Then, by adding the transaction data to the use case template, the transaction data can be summarized and organized, and the added summary transaction template is used to assemble the data to realize an automated process. There is no need for the recipient of funds to manually check each transaction data corresponding to the transaction initiator one by one, which can save the verification process. The assembled transaction file is then put into a table to generate a transaction form. Compared with the transaction file, the transaction form has a neat format and clear data. Therefore, verifying the transaction form can increase the accuracy of the verification compared to directly verifying the transaction file, and can speed up the verification speed, verify the errors or problems in the transaction data, and ensure the safety of funds and property and the equality of the transaction numbers between the two parties.
[0087] In the method provided in the embodiment of the present invention, in response to a request instruction for performing a data test, a process of determining each user to be tested is specifically described as follows:
[0088] In response to a request instruction for performing a data test, obtaining each pending user corresponding to the request instruction;
[0089] Extracting historical transaction records of each pending user;
[0090] Determine whether the historical transaction record of each pending user is a blank record;
[0091] Each pending user whose historical transaction record is not a blank record is used as each pending test user.
[0092] Specifically, it is understandable that in order to improve the test efficiency, all users can be screened. It is not necessary to test the transaction data of all users. First, all users are treated as pending users, and then the pending users are screened, wherein the historical transaction records of each pending user are obtained, and it is determined whether the historical transaction records of each pending user are blank records, that is, it is determined whether each pending user is a new user with no transaction records, and new users or pending users with no historical transaction records are used as users to be tested.
[0093] The above scheme explains the process of determining each user to be tested in response to a request instruction for data testing in this application. The following specifically describes the process of adding the transaction data of all transaction actions of the user to be tested to a pre-created use case template in this application to obtain a summary transaction template corresponding to the user to be tested.
[0094] Determine the time when each transaction action of the user to be tested is initiated;
[0095] Sorting the transaction actions of the user to be tested in the order of time;
[0096] Based on the sorting, the transaction data of each transaction action of the user to be tested is added to a pre-created use case template to obtain a summary transaction template corresponding to the user to be tested.
[0097] Specifically, in order to ensure the orderliness of the use case template, for each user to be tested, each transaction action of the user to be tested is sorted in the order of action generation, and then the transaction data is added to the use case template in sequence according to the sorting order. This can enable early problems to be discovered and solved earlier, reducing the impact of fund account errors on the initiator and recipient of the transaction action.
[0098] The following embodiment specifically describes the process of assembling the transaction data of each transaction action of the user to be tested from the aggregated transaction template to obtain each transaction file of the user to be tested in the present application, which may include the following two assembling methods.
[0099] 1. From the perspective of transaction type.
[0100] S41: Determine the transaction type to which each transaction action of the user to be tested belongs.
[0101] S42: Determine the priority of each of the transaction types, and take each transaction type with a priority greater than a preset level as each risk type.
[0102] S43: For each risk type, extract the transaction data of each transaction action corresponding to the risk type from the summary transaction template, and assemble the data to obtain a risk transaction list corresponding to the risk type.
[0103] S44: treating each transaction action corresponding to each transaction type having a priority level not greater than the preset level as each common transaction action.
[0104] S45: extracting the transaction data of each common transaction action from the summary transaction template, and assembling the data to obtain a common transaction list.
[0105] S46: The common transaction list and each of the risky transaction lists are used as transaction files of the user to be tested.
[0106] Specifically, considering that the risk levels of different transaction actions are different, some involve the transfer and repayment of large amounts of money, etc., which require a higher safety factor, so the risk level is also relatively high. Therefore, separate processing of transaction actions with different risk levels and separate establishment of transaction files can facilitate subsequent staff to prioritize problematic and high-risk transaction data and reduce the impact of errors. Therefore, in this step, the transaction type to which each transaction action of the user to be tested belongs is first determined, and the risk level or priority of each transaction type is determined. It can be understood that the priority in this application is set in advance according to the risk level. Then, each transaction type with a higher priority, such as a priority greater than a preset level, is regarded as each risk type. In an example, the priority includes: level 1, level 2, level 3, level 4, and level 5, wherein the risk level gradually decreases from level 1, and level 3 is set as the preset level. If there are transaction types with a priority of level 1 or level 2, these transaction types are regarded as risk types.
[0107] Since the summary transaction template is already a summarized and organized template, the transaction data of each transaction action corresponding to the risk type can be directly extracted from the summary transaction template, and the data can be assembled to obtain a risk transaction list corresponding to each risk type.
[0108] 2. Starting from the link.
[0109] Determine the scenario parameters corresponding to the user to be tested;
[0110] Querying a link corresponding to the scene parameter;
[0111] Determine each execution unit corresponding to each transaction action of the user to be tested on the link;
[0112] Each execution unit on the link is called to execute the corresponding transaction actions respectively, so as to assemble the transaction data of each transaction action of the user to be tested in the summary transaction template to obtain each transaction file of the user to be tested.
[0113] In the above scheme, a device can be introduced, which includes a front-end system, a test platform, an underlying system, a task system, and a file system. The operation flow chart of the device can be as follows: Figure 4As shown, the front-end system sends the scenario ID corresponding to the system to be tested, that is, the scenario parameters, to the test platform. The test platform queries the link corresponding to the scenario parameters, executes it, and sends it to the underlying system to determine the execution units corresponding to the various transaction actions of the user to be tested on the link, calls each execution unit to execute its corresponding transaction actions, and then calls the task system to perform bill calculations in the task system to obtain the bill value. The task system assembles the bill value data and uploads it to the file system after assembly to generate a bill file, that is, a transaction file. The file system can also return the bill file to the task system.
[0114] The following embodiments describe in detail the process of generating each transaction table based on each transaction file in the present application.
[0115] For each of the transaction files, determining a transaction type corresponding to the transaction file;
[0116] Set the table name according to the transaction type;
[0117] Obtaining the file size of the transaction file, and setting the number of table rows and the number of table columns based on the file size;
[0118] Create a table file according to the table name, the number of table rows and the number of table columns;
[0119] All transaction data in the transaction file are transferred to the table file to obtain the transaction table of the transaction file.
[0120] The above scheme is the process of putting transaction files into the table. The existing technology generally requires staff to manually download transaction files, decompress the transaction files, and then import them into the table. The steps are cumbersome and time-consuming. The present scheme only needs to determine the basic information of the table, such as the table name, the number of table rows, the number of table columns, etc. to establish the table, and automatically put the transaction files into the table. It is efficient, fast, and not prone to errors.
[0121] This solution creates a use case template to realize the automated integration, aggregation, transmission, etc. of the transaction data of transaction actions, and automates the process of table entry and verification. Compared with the existing technology of manual data preparation, manual triggering of test verification, manual decompression of files, etc., the overall process steps are greatly reduced, which is more convenient and quick, saves time, and has higher verification accuracy.
[0122] and Figure 1 Corresponding to the method described above, the embodiment of the present invention also provides a testing device for transaction data, which is used to Figure 1 In the specific implementation of the method, the transaction data testing device provided in the embodiment of the present invention can be used in a computer terminal or various mobile devices, combined with Figure 5, the test device for transaction data is introduced, such as Figure 5 As shown, the device may include:
[0123] A to-be-tested user determination module 10 is used to determine each to-be-tested user in response to a request instruction for performing a data test;
[0124] The transaction data acquisition module 20 is used to acquire the transaction data of all transaction actions of each user to be tested;
[0125] The module 30 for obtaining a summary transaction template is used to add the transaction data of all transaction actions of the user to be tested to the pre-created use case template to obtain the summary transaction template corresponding to the user to be tested;
[0126] A data assembly module 40 is used to assemble the transaction data of each transaction action of the user to be tested from the summary transaction template to obtain each transaction file of the user to be tested;
[0127] A transaction table generating module 50, configured to generate each transaction table based on each of the transaction files;
[0128] The verification module 60 is used to verify each of the transaction forms respectively to obtain the verification results of each transaction action of the user to be tested.
[0129] It can be seen from the above technical scheme that the present application determines each user to be tested in response to a request instruction for data testing; for each user to be tested, obtains the transaction data of all transaction actions of the user to be tested; adds the transaction data of all transaction actions of the user to be tested to a pre-created use case template to obtain a summary transaction template corresponding to the user to be tested; assembles the transaction data of each transaction action of the user to be tested from the summary transaction template to obtain each transaction file of the user to be tested; generates each transaction table based on each transaction file; verifies each transaction table to obtain the verification result of each transaction action of the user to be tested. This solution first determines the user to be tested and obtains the transaction data of all transaction actions initiated by the user to be tested. Then, by adding the transaction data to the use case template, the transaction data can be summarized and organized, and the added summary transaction template is used to assemble the data to realize an automated process. There is no need for the recipient of funds to manually check each transaction data corresponding to the transaction initiator one by one, which can save the verification process. The assembled transaction file is then put into a table to generate a transaction form. Compared with the transaction file, the transaction form has a neat format and clear data. Therefore, verifying the transaction form can increase the accuracy of the verification compared to directly verifying the transaction file, and can speed up the verification speed, verify the errors or problems in the transaction data, and ensure the safety of funds and property and the equality of the transaction numbers between the two parties.
[0130] In one example, the to-be-tested user determination module 10 may include:
[0131] A pending user acquisition module, used to respond to a request instruction for performing a data test and acquire each pending user corresponding to the request instruction;
[0132] A historical transaction record extraction module, used to extract the historical transaction records of each of the pending users;
[0133] A judgment module, used to judge whether the historical transaction record of each pending user is a blank record;
[0134] The module for finalizing the users to be tested is used to select the users to be determined whose historical transaction records are not blank records as the users to be tested.
[0135] Furthermore, the embodiment of the present application provides a test device for transaction data. Optionally, Figure 6 The hardware structure diagram of the test equipment for transaction data is shown in FIG. Figure 6 The hardware structure of the transaction data testing device may include: at least one processor 01 , at least one communication interface 02 , at least one memory 03 and at least one communication bus 04 .
[0136] In the embodiment of the present application, the number of the processor 01 , the communication interface 02 , the memory 03 , and the communication bus 04 is at least one, and the processor 01 , the communication interface 02 , and the memory 03 communicate with each other through the communication bus 04 .
[0137] The processor 01 may be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention.
[0138] The memory 03 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), etc., such as at least one disk memory.
[0139] The memory stores a program, and the processor can call the program stored in the memory, and the program is used to execute the following transaction data testing method, including:
[0140] In response to a request instruction for performing a data test, determining each user to be tested;
[0141] For each user to be tested, obtain the transaction data of all transaction actions of the user to be tested;
[0142] Add the transaction data of all transaction actions of the user to be tested to the pre-created use case template to obtain the summary transaction template corresponding to the user to be tested;
[0143] Assembling the transaction data of each transaction action of the user to be tested from the aggregated transaction template to obtain each transaction file of the user to be tested;
[0144] generating each transaction form based on each of the transaction files;
[0145] Each of the transaction forms is verified respectively to obtain a verification result of each transaction action of the user to be tested.
[0146] Optionally, the detailed functions and extended functions of the program may refer to the description of the test method for transaction data in the method embodiment.
[0147] The embodiment of the present application further provides a storage medium, which may store a program suitable for execution by a processor, and when the program is executed, controls the device where the storage medium is located to execute the following transaction data testing method, including:
[0148] In response to a request instruction for performing a data test, determining each user to be tested;
[0149] For each user to be tested, obtain the transaction data of all transaction actions of the user to be tested;
[0150] Add the transaction data of all transaction actions of the user to be tested to the pre-created use case template to obtain the summary transaction template corresponding to the user to be tested;
[0151] Assembling the transaction data of each transaction action of the user to be tested from the aggregated transaction template to obtain each transaction file of the user to be tested;
[0152] generating each transaction form based on each of the transaction files;
[0153] Each of the transaction forms is verified respectively to obtain a verification result of each transaction action of the user to be tested.
[0154] Specifically, the storage medium may be a computer-readable storage medium, and the computer-readable storage medium may be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read-Only Memory), an EPROM, a hard disk or a ROM.
[0155] Optionally, the detailed functions and extended functions of the program may refer to the description of the test method for transaction data in the method embodiment.
[0156] In addition, the functional modules in the various embodiments of the present disclosure can be integrated together to form an independent part, or each module can exist separately, or two or more modules can be integrated to form an independent part. If the function is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for a computer device (which can be a personal computer, a live broadcast device, or a network device, etc.) to perform all or part of the steps of the methods of the various embodiments of the present disclosure.
[0157] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.
[0158] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.
[0159] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A transaction data testing method, characterized in that: include: In response to a request instruction for performing a data test, determining each user to be tested; For each user to be tested, obtain the transaction data of all transaction actions of the user to be tested; Add the transaction data of all transaction actions of the user to be tested to the pre-created use case template to obtain the summary transaction template corresponding to the user to be tested; Assembling the transaction data of each transaction action of the user to be tested from the aggregated transaction template to obtain each transaction file of the user to be tested; generating each transaction form based on each of the transaction files; Each of the transaction forms is verified respectively to obtain a verification result of each transaction action of the user to be tested.
2. The method according to claim 1, characterized in that: The step of determining each user to be tested in response to a request instruction for performing a data test comprises: In response to a request instruction for performing a data test, obtaining each pending user corresponding to the request instruction; Extracting historical transaction records of each pending user; Determine whether the historical transaction record of each pending user is a blank record; Each pending user whose historical transaction record is not a blank record is used as each pending test user.
3. The method according to claim 1, characterized in that The step of adding the transaction data of all transaction actions of the user to be tested to the pre-created use case template to obtain a summary transaction template corresponding to the user to be tested includes: Determine the time when each transaction action of the user to be tested is initiated; Sorting the transaction actions of the user to be tested in the order of time; Based on the sorting, the transaction data of each transaction action of the user to be tested is added to a pre-created use case template to obtain a summary transaction template corresponding to the user to be tested.
4. The method according to claim 1, characterized in that: The transaction data of each transaction action of the user to be tested is respectively assembled from the aggregated transaction template to obtain each transaction file of the user to be tested, including: Determine the transaction type to which each transaction action of the user to be tested belongs; Determine the priority of each of the transaction types, and treat each transaction type with a priority greater than a preset level as each risk type; For each risk type, extract the transaction data of each transaction action corresponding to the risk type from the summary transaction template, and assemble the data to obtain a risk transaction list corresponding to the risk type; Treat each transaction action corresponding to each transaction type whose priority is not greater than the preset level as each common transaction action; Extracting transaction data of each common transaction action from the summary transaction template, and assembling the data to obtain a common transaction list; The common transaction list and each of the risky transaction lists are used as transaction files of the user to be tested.
5. The method according to claim 1, characterized in that The step of assembling the transaction data of each transaction action of the user to be tested from the aggregated transaction template to obtain each transaction file of the user to be tested includes: Determine the scenario parameters corresponding to the user to be tested; Querying a link corresponding to the scene parameter; Determine each execution unit corresponding to each transaction action of the user to be tested on the link; Each execution unit on the link is called to execute the corresponding transaction actions respectively, so as to assemble the transaction data of each transaction action of the user to be tested in the summary transaction template to obtain each transaction file of the user to be tested.
6. The method according to claim 1, characterized in that The generating of each transaction form based on each transaction file includes: For each of the transaction files, determining a transaction type corresponding to the transaction file; Set the table name according to the transaction type; Obtaining the file size of the transaction file, and setting the number of table rows and the number of table columns based on the file size; Create a table file according to the table name, the number of table rows and the number of table columns; All transaction data in the transaction file are transferred to the table file to obtain the transaction table of the transaction file.
7. A transaction data testing device, characterized in that: include: A module for determining users to be tested, used to determine each user to be tested in response to a request instruction for performing a data test; The transaction data acquisition module is used to acquire the transaction data of all transaction actions of each user to be tested; A module for obtaining a summary transaction template is used to add the transaction data of all transaction actions of the user to be tested to a pre-created use case template to obtain a summary transaction template corresponding to the user to be tested; A data assembly module, used to assemble the transaction data of each transaction action of the user to be tested from the summary transaction template to obtain each transaction file of the user to be tested; A transaction table generating module, used for generating each transaction table based on each of the transaction files; The verification module is used to verify each of the transaction forms respectively to obtain the verification results of each transaction action of the user to be tested.
8. The device according to claim 7, characterized in that The to-be-tested user determination module comprises: A pending user acquisition module, used to respond to a request instruction for performing a data test and acquire each pending user corresponding to the request instruction; A historical transaction record extraction module, used to extract the historical transaction records of each of the pending users; A judgment module, used to judge whether the historical transaction record of each pending user is a blank record; The module for finalizing the users to be tested is used to select the users to be determined whose historical transaction records are not blank records as the users to be tested.
9. A transaction data testing device, characterized in that: including memory and processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the transaction data testing method as described in any one of claims 1-6.
10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, each step of the transaction data testing method according to any one of claims 1 to 6 is implemented.