A payment timeout warning test method and its system

Abstract

The present invention provides a method for testing payment timeout warnings. The method includes the following steps: Step S1, locally create an order management database, create a temporary order table and a historical timeout order table, and set the attributes of the historical timeout order table, including order number, timeout times, and payment callback values of each component; clear the data in the temporary order table before each test task is executed; Step S2, set a test task, deploy the test task on the continuous integration tool jenkins, set the build frequency to a preset time, continuously integrate and build the test task, and monitor the online order payment status; Step S3, after the test task is completed, push the test warning message, and the operator can accurately locate the abnormal link causing the payment timeout according to the abnormal component callback value in the push message; the automated monitoring is more intelligent, reducing unnecessary troubleshooting processes.

Description

Technical Field

[0001] The present invention relates to the field of computer communication technology, and particularly to a payment timeout warning test method and system thereof. Background Art

[0002] The order payment of a product involves the product itself, multiple payment-related components, and a third-party payment platform. These parties are independent of each other but interdependent. When a payment timeout occurs, the user has completed the payment operation on the third-party payment platform and the amount has been deducted, but the front-end order of the product is still in the pending payment state, seriously damaging the interests of the user. The product side cannot know the problem in a timely manner, and the process of troubleshooting is complicated.

[0003] When a payment timeout occurs in the prior art, manual testing has the following disadvantages:

[0004] (1) It is impossible to quickly locate the abnormal link. It is necessary for multiple payment-related component parties and the product side development involved to perform abnormality troubleshooting on each link in each payment process, wasting a lot of time and manpower.

[0005] (2) The problem response is slow. The problem cannot be known in a timely manner. It is always necessary to wait for external feedback before starting troubleshooting, damaging the interests of the user.

[0006] (3) The troubleshooting process is the same every time, and the same troubleshooting steps are repeatedly executed manually, with low efficiency and waste of time. Summary of the Invention

[0007] To overcome the above problems, the object of the present invention is to provide a payment timeout warning test method, which can automatically and preliminarily troubleshoot the order timeout problem, lock the abnormal components, and avoid the time and manpower investment of multiple component personnel for troubleshooting.

[0008] The present invention is implemented by the following scheme: A payment timeout warning test method, the method includes the following steps:

[0009] Step S1: Create an order management database locally, create a temporary order table and a historical timeout order table, set the attributes of the historical timeout order table as order number, timeout times, and payment callback values of each component; clear the data in the temporary order table before each test task is executed;

[0010] Step S2: Set a test task, deploy the test task on the continuous integration tool jenkins, set the build frequency to a preset time, continuously integrate and build the test task, and monitor the online order payment status;

[0011] Step S3: After the test task is completed, push the test warning message, and the operator can accurately locate the abnormal link causing the payment timeout according to the abnormal component callback value in the push message.

[0012] Further, the test task is as follows: Obtain the orders that have been paid and whose payment status is pending payment in the third-party payment platform of the online database to the local database, store them in the temporary order table, read the original overdue orders and the information of newly added overdue orders in the temporary order table from the local historical overdue order table, increment the order overdue count by 1, filter the orders with an overdue count greater than 1, and successively verify the payment callback values of the third-party payment platform and each component to determine the payment exception link.

[0013] Further, the test task is further specifically as follows: Write a script in Python + MySQL language to obtain the order table of the MySQL database of the third-party payment platform from the online, obtain the order records with normal payment callback and pending payment status in the third-party payment platform through the query conditions, and write them into the local temporary order table;

[0014] Judge according to the order number in the local historical overdue order table. If the order obtained this time is already in the historical overdue order table, update the corresponding order information in the local historical overdue order table and increment the overdue count by 1; if the order obtained this time is not in the historical overdue order table, add the corresponding order information to the historical overdue order table and increment the overdue count by 1;

[0015] Filter out the orders with an overdue count greater than 1 from the historical overdue order table, where the overdue time is greater than the preset time.

[0016] Further, the successive verification of the payment callback values of the third-party payment platform and each component to determine the payment exception link is specifically as follows: Verify according to the component call logic sequence in the payment process: After creating an order, the order status is default to the pending payment status. After the user completes the payment operation, the third-party payment platform transmits the payment callback result to the payment center component, the payment center component transmits the payment callback value to the wallet component, the wallet component transmits the payment callback value to the product server, and the product server queries the order and updates the order status; then the payment center component queries the order and views the TradeStatus field returned by the interface. When TradeStatus = TRADE_SUCCESS, it means that the third-party payment platform callback is normal; the wallet component queries the order and views the order status code field returned by the interface. If code = 80010000, it indicates that the payment is successful, which means that the payment callback returned by the payment center component is normal; the server queries the order and views the order status status field returned by the interface. When status = 1, it indicates that the payment is successful, which means that the payment callback value returned by the wallet component is normal; in this way, the source abnormal component or the third-party payment platform that causes the payment timeout is judged.

[0017] The present invention also provides a payment timeout warning test system, which includes: a test preparation module, a test execution module, and a test result collection module;

[0018] The test preparation module is used to create an order management database locally, create a temporary order table and a historical timeout order table, set the attribute order numbers, timeout times, and payment callback values of each component in the historical timeout order table; clear the data in the temporary order table before each test task execution;

[0019] The test execution module sets a test task, deploys the test task on the continuous integration tool jenkins, sets the build frequency to a preset time, continuously integrates and builds the test task, and monitors the online order payment status;

[0020] The test result collection module is used to push the warning messages of the test after the test task is completed. The operator can accurately locate the abnormal link causing the payment timeout according to the abnormal component callback value in the pushed message.

[0021] Further, the test task is: obtain the orders that have been paid and whose payment status is pending payment in the online database of the third-party payment platform to the local database, store them in the temporary order table, read the original timeout orders and newly added timeout order information in the temporary order table from the local historical timeout order table, increment the order timeout times by 1, filter out the orders with timeout times greater than 1, and sequentially verify the payment callback values of the third-party payment platform and each component to determine the payment abnormal link.

[0022] Further, the test task further specifically includes: writing a script in Python + MySQL language to obtain the order table of the MySQL database of the third-party payment platform online, obtaining the order records with normal payment callbacks and pending payment status in the third-party payment platform through query conditions, and writing them into the local temporary order table;

[0023] Judge according to the order numbers in the local historical timeout order table. If the order obtained this time is already in the historical timeout order table, update the corresponding order information in the local historical timeout order table and increment the timeout times by 1; if the order obtained this time is not in the historical timeout order table, add the corresponding order information to the historical timeout order table and increment the timeout times by 1;

[0024] Filter out the orders with timeout times greater than 1 from the historical timeout order table, where the timeout time is greater than the preset time.

[0025] Further, the payment callback values of the third-party payment platform and each component are sequentially verified to determine the payment exception link, specifically as follows: Verification is performed according to the component call logic sequence in the payment process: After creating an order, the order status is default to the pending payment status. After the user completes the payment operation, the third-party payment platform transfers the payment callback result to the payment center component, the payment center component transfers the payment callback value to the wallet component, the wallet component transfers the payment callback value to the product server, and the product server queries the order and updates the order status; then the payment center component queries the order and checks the TradeStatus field returned by the interface. When TradeStatus = TRADE_SUCCESS, it indicates that the callback from the third-party payment platform is normal; the wallet component queries the order and checks the order status code field returned by the interface. If code = 80010000, it means the payment is successful, indicating that the payment callback value returned by the payment center component is normal; the server queries the order and checks the order status status field. When status = 1, it means the payment is successful, indicating that the payment callback value returned by the wallet component is normal; thus, the source abnormal component or the third-party payment platform causing the payment timeout is judged.

[0026] The beneficial effects of the present invention are as follows: 1. This testing method can automatically and preliminarily troubleshoot the order timeout problem, lock the abnormal component, and avoid the time and labor input of multiple component personnel for troubleshooting. 2. Automatically monitoring the payment timeout can discover problems in the first time, respond to problems in a timely manner, reduce user losses, and maintain the credibility of the system. 3. The automatic monitoring is more intelligent, simplifies the repetitive manual troubleshooting process method, and saves time. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 is a schematic flow chart of the method of the present invention.

[0028] Figure 2 is a schematic flow chart of an embodiment of the present invention.

[0029] Figure 3 is a specific schematic flow chart of the test task in an embodiment of the present invention.

[0030] Figure 4 is a schematic block diagram of the system of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] The present invention will be further described below with reference to the accompanying drawings.

[0032] Please refer to Figure 1 as shown, a payment timeout warning test method of the present invention, the method includes the following steps:

[0033] Step S1: Create an order management database locally, create a temporary order table and a historical timeout order table, and set the attributes of the historical timeout order table, including order number, timeout count, and payment callback values for each component. Clear the data in the temporary order table before each test task execution.

[0034] Step S2: Set up a test task, deploy the test task on the continuous integration tool Jenkins, set the build frequency to a preset time, continuously integrate and build the test task, and monitor the online order payment status.

[0035] After the test task is completed, push the test alert message, and the operator can accurately locate the abnormal link that causes payment timeout based on the abnormal component callback value in the push message.

[0036] As Figure 2 shown, it is a flowchart of an embodiment of the present invention. A payment timeout alert test method of the present invention, preparation before testing:

[0037] 1. Create a MySQL database for order management locally (i.e., on the client side), create a temporary order table to store the timeout orders pulled from the online (server-side online) environment database of the project during this test execution, create a historical timeout order table to store the details of historical timeout orders. The attributes of the historical timeout order table include order number, timeout count, and payment callback values returned by the third-party payment platform. The components include: payment center component and wallet component, payment center component callback value, and wallet component payment callback value.

[0038] 2. Clear the data in the local temporary order table before each test task execution.

[0039] As Figure 3 shown, test execution:

[0040] 1. Deploy the test task on the continuous integration tool Jenkins, set the build frequency to a preset time, which is 2 - 3 minutes, continuously integrate and build the test task, and monitor the online order payment status.

[0041] 2. Write a script in Python + MySQL language to obtain the order table of the third-party payment platform's MySQL database from the online, and obtain the order records with normal payment callbacks from the third-party payment platform and a payment status of pending payment through query conditions, and write them into the local temporary order table.

[0042] 3. Determine according to the order number in the local historical timeout order table. If the order obtained this time is already in the local historical timeout order table, update the corresponding order information in the local historical timeout order table and increment the timeout count by 1; if the order obtained this time is not in the local historical timeout order table, add the corresponding order information to the local historical timeout order table and increment the timeout count by 1.

[0043] 4. Filter out the orders in the local historical timeout order table with a timeout count greater than 1, that is: the timeout time is greater than 2 minutes.

[0044] 5. According to the component call logic sequence in the payment process: after creating an order, the order status is defaulted to the pending payment status, and the front end shows waiting for payment. After the user completes the payment operation, the third-party payment platform passes the payment callback result to the payment center component, the payment center component passes the payment callback value to the wallet component, the wallet component passes the payment callback value to the product server, and the server queries the order and updates the order status. Therefore, the payment center component queries the order and checks the TradeStatus field returned by the interface. When TradeStatus = TRADE_SUCCESS, it means that the third-party payment platform callback is normal; the wallet component queries the order and checks the order status code field returned by the interface. If code = 80010000, it indicates successful payment, which means that the payment callback returned by the payment center component is normal; the server queries the order and checks the order status status field. When status = 1, it indicates successful payment, which means that the payment callback value returned by the wallet component is normal. Based on this, judge whether the component causing the payment timeout is the source abnormal component or the third-party payment platform.

[0045] 6. Notify the corresponding component responsible person through a communication tool (such as WeChat, QQ, email) message alarm. The message content includes the order number, the name of the abnormal component, and the payment callback value of the abnormal component.

[0046] Test result collection:

[0047] After completing the alarm message push, the specific timeout order number, the name of the abnormal component, and the payment callback value of the abnormal component can be obtained in a timely manner. According to the payment callback value of the abnormal component in the push message, more accurately locate the abnormal link that causes the payment timeout, and use this as a starting point to further deeply troubleshoot bugs and reduce unnecessary troubleshooting processes.

[0048] The described test task further specifically includes: writing a script in Python + MySQL language to obtain the order table of the MySQL database of the third-party payment platform from the online, and obtaining the order records with normal payment callbacks from the third-party payment platform and a payment status of pending payment through query conditions, and writing them into the local temporary order table;

[0049] Determine according to the order number in the local historical timeout order table. If the order obtained this time is already in the historical timeout order table, update the corresponding order information in the local historical timeout order table and increment the timeout count by 1. If the order obtained this time is not in the historical timeout order table, add the corresponding order information to the historical timeout order table and increment the timeout count by 1.

[0050] Filter out the orders with a timeout count greater than 1 from the historical timeout order table, where the timeout time is greater than the preset time.

[0051] As Figure 4 shown, the present invention also provides a payment timeout warning test system, which includes: a test preparation module, an execution test module, and a test result collection module;

[0052] The test preparation module is used to create an order management database locally, create a temporary order table and a historical timeout order table, set the attributes of the historical timeout order table, including order number, timeout count, and payment callback values of each component. Clear the data in the temporary order table before each test task execution;

[0053] The execution test module sets a test task, deploys the test task on the continuous integration tool jenkins, sets the build frequency to a preset time, continuously integrates and builds the test task, and monitors the online order payment status. The test task is: obtain the orders that have been paid and have a payment status of pending payment in the third-party payment platform of the online database to the local database and store them in the temporary order table. The local historical timeout order table reads the original timeout orders and newly added timeout order information in the temporary order table, increments the order timeout count by 1, filters out the orders with a timeout count greater than 1, and sequentially verifies the payment callback values of the third-party payment platform and each component to determine the payment exception link.

[0054] The test result collection module is used to push the test warning messages after the test task is completed. The operator can accurately locate the abnormal link causing the payment timeout according to the abnormal component callback value in the pushed message.

[0055] The test task further specifically includes: writing a script in Python+MySQL language to obtain the order table of the MySQL database of the third-party payment platform online, obtaining the order records with normal payment callbacks in the third-party payment platform and a payment status of pending payment through query conditions, and writing them into the local temporary order table;

[0056] Judge according to the order number in the local historical timeout order table. If the order obtained this time already exists in the historical timeout order table, update the corresponding order information in the local historical timeout order table and increment the timeout count by 1. If the order obtained this time does not exist in the historical timeout order table, add the corresponding order information to the historical timeout order table and increment the timeout count by 1.

[0057] Filter out the orders with a timeout count greater than 1 from the historical timeout order table, where the timeout time is greater than the preset time.

[0058] Verify the payment callback values of the third-party payment platform and each component in sequence to determine the payment exception link. Specifically: Verify according to the component call logic sequence in the payment process. After creating an order, the order status is defaulted to the pending payment status. After the user completes the payment operation, the third-party payment platform transmits the payment callback result to the payment center component. The payment center component transmits the payment callback value to the wallet component. The wallet component transmits the payment callback value to the product server. The product server queries the order and updates the order status. Then the payment center component queries the order and checks the TradeStatus field returned by the interface. When TradeStatus = TRADE_SUCCESS, it indicates that the third-party payment platform callback is normal. The wallet component queries the order and checks the order status code field returned by the interface. If code = 80010000, it means the payment is successful, indicating that the payment callback returned by the payment center component is normal. The server queries the order and checks the order status status field returned by the interface. When status = 1, it means the payment is successful, indicating that the payment callback value returned by the wallet component is normal. Thus, the source abnormal component or the third-party payment platform that causes the payment timeout can be judged.

[0059] The above are only the preferred embodiments of the present invention. All equivalent changes and modifications made according to the scope of the patent application of the present invention shall fall within the scope of the present invention.

Claims

1. A payment timeout alarm testing method, characterized by: The method comprises the following steps: Step S1: Create an order management database locally, create a temporary order table and a historical timeout order table, set the attributes of the historical timeout order table, order number, timeout count, and payment callback value of each component; clear the temporary order table data before executing each test task; Step S2: Set a test task, deploy the test task on the continuous integration tool Jenkins, set the build frequency to a preset time, continuously integrate and build the test task, and monitor the online order payment status; Step S3: After the test task is completed, the test alarm message is pushed. The operator accurately locates the abnormal link that causes the payment timeout based on the abnormal component callback value in the pushed message; The test task further specifically includes: using Python+MySQL language to write a script to obtain the order table of the MySQL database of the third-party payment platform from online, and using query conditions to obtain order records with normal payment callbacks and payment status of pending payment on the third-party payment platform, and write them into the local temporary order table; According to the order number in the local historical timed-out order table, if the order obtained this time is already in the historical timed-out order table, the corresponding order information in the local historical timed-out order table is updated, and the timeout count is accumulated by 1; if the order obtained this time is not in the historical timed-out order table, the corresponding order information is added to the historical timed-out order table, and the timeout count is accumulated by 1; and orders with a timeout count greater than 1 are screened out from the historical timed-out order table, where the timeout period is greater than the preset time; Verify the payment callback values of the third-party payment platform and each component in turn to determine the payment abnormality link. Specifically, verify according to the logical order of component calls in the payment process: After creating an order, the order status defaults to pending payment. After the user completes the payment operation, the third-party payment platform passes the payment callback result to the payment center component, the payment center component passes the payment callback value to the wallet component, and the wallet component passes the payment callback value to the product server. The product server queries the order and the order status is updated. The payment center component queries the order and checks the TradeStatus field returned by the interface. When TradeStatus = TRADE_SUCCESS, it indicates that the third-party payment platform callback is normal. The wallet component queries the order and checks the order status code field returned by the interface. If code = 80010000, it indicates that the payment is successful, which indicates that the payment callback returned by the payment center component is normal. The server queries the order and checks the order status status field returned by the interface. When status = 1, it indicates that the payment is successful, which indicates that the payment callback value returned by the wallet component is normal. Based on this, determine the source abnormal component or third-party payment platform that caused the payment timeout.

2. A payment timeout alarm testing method according to claim 1, characterized in that: The test task is to obtain the paid orders in the third-party payment platform of the online database and the payment status is pending payment to the local database, and store them in the temporary order table. The local historical timed-out order table reads the original timed-out order and the newly added timed-out order information in the temporary order table, adds 1 to the order timeout number, filters out orders with a timeout number greater than 1, verifies the payment callback values of the third-party payment platform and each component in turn, and determines the payment abnormality link.

3. A payment timeout alarm testing system, characterized by: The system includes: a test preparation module, a test execution module, and a test result collection module; The test preparation module is used to create an order management database locally, create a temporary order table and a historical timeout order table, set the attributes of the historical timeout order table, order number, timeout count, and payment callback value of each component; clear the temporary order table data before each test task is executed; The execution test module sets a test task, deploys the test task on the continuous integration tool Jenkins, sets the build frequency to a preset time, continuously integrates and builds the test task, and monitors the online order payment status; The test result collection module is used to push the test alarm message after the test task is completed. The operator can accurately locate the abnormal link that causes the payment timeout based on the abnormal component callback value in the pushed message; The test task further specifically includes: using Python+MySQL language to write a script to obtain the order table of the MySQL database of the third-party payment platform from online, and using query conditions to obtain order records with normal payment callbacks and payment status of pending payment on the third-party payment platform, and write them into the local temporary order table; According to the order number in the local historical timed-out order table, if the order obtained this time is already in the historical timed-out order table, the corresponding order information in the local historical timed-out order table is updated, and the timeout count is accumulated by 1; if the order obtained this time is not in the historical timed-out order table, the corresponding order information is added to the historical timed-out order table, and the timeout count is accumulated by 1; and orders with a timeout count greater than 1 are screened out from the historical timed-out order table, where the timeout period is greater than the preset time; Verify the payment callback values of the third-party payment platform and each component in turn to determine the payment abnormality link. Specifically, verify according to the logical order of component calls in the payment process: After creating an order, the order status defaults to pending payment. After the user completes the payment operation, the third-party payment platform passes the payment callback result to the payment center component, the payment center component passes the payment callback value to the wallet component, and the wallet component passes the payment callback value to the product server. The product server queries the order and the order status is updated. The payment center component queries the order and checks the TradeStatus field returned by the interface. When TradeStatus = TRADE_SUCCESS, it indicates that the third-party payment platform callback is normal. The wallet component queries the order and checks the order status code field returned by the interface. If code = 80010000, it indicates that the payment is successful, which indicates that the payment callback returned by the payment center component is normal. The server queries the order and checks the order status status field returned by the interface. When status = 1, it indicates that the payment is successful, which indicates that the payment callback value returned by the wallet component is normal. Based on this, determine the source abnormal component or third-party payment platform that caused the payment timeout.

4. A payment timeout alarm testing system according to claim 3, characterized in that: The test task is to obtain the paid orders in the third-party payment platform of the online database and the payment status is pending payment to the local database, and store them in the temporary order table. The local historical timed-out order table reads the original timed-out order and the newly added timed-out order information in the temporary order table, adds 1 to the order timeout number, filters out orders with a timeout number greater than 1, verifies the payment callback values of the third-party payment platform and each component in turn, and determines the payment abnormality link.

Images