CN116737465A - Test method for checking account and processing errors of bank payment system - Google Patents
Test method for checking account and processing errors of bank payment system Download PDFInfo
- Publication number
- CN116737465A CN116737465A CN202311018631.1A CN202311018631A CN116737465A CN 116737465 A CN116737465 A CN 116737465A CN 202311018631 A CN202311018631 A CN 202311018631A CN 116737465 A CN116737465 A CN 116737465A
- Authority
- CN
- China
- Prior art keywords
- error
- baffle
- account
- checking
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012545 processing Methods 0.000 title claims abstract description 73
- 238000010998 test method Methods 0.000 title abstract description 6
- 238000012360 testing method Methods 0.000 claims abstract description 80
- 238000013515 script Methods 0.000 claims abstract description 44
- 238000000034 method Methods 0.000 claims abstract description 33
- 230000007246 mechanism Effects 0.000 claims abstract description 25
- 238000011161 development Methods 0.000 claims abstract description 19
- 238000004806 packaging method and process Methods 0.000 claims abstract description 5
- 230000005540 biological transmission Effects 0.000 claims description 25
- 230000000903 blocking effect Effects 0.000 claims description 22
- 238000004088 simulation Methods 0.000 claims description 12
- 230000007547 defect Effects 0.000 claims description 10
- 238000012937 correction Methods 0.000 claims description 4
- 230000004888 barrier function Effects 0.000 claims description 3
- 230000001502 supplementing effect Effects 0.000 claims description 3
- 238000012795 verification Methods 0.000 description 20
- 238000011084 recovery Methods 0.000 description 11
- 230000008569 process Effects 0.000 description 10
- 238000004891 communication Methods 0.000 description 5
- 238000011010 flushing procedure Methods 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000004075 alteration Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000013524 data verification Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000004080 punching Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/03—Credit; Loans; Processing thereof
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- General Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Quality & Reliability (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention discloses a test method for checking account and processing errors of a bank payment system, and belongs to the technical field of bank data processing. The method comprises the following steps: the method comprises the steps of pre-packaging a script of configurable operation of error scenes aiming at the error scenes contained in different types of business of a bank payment system; configuring an error scene by using the packaged script; and carrying out the tests of daytime error processing and daily final check-up of various businesses of the bank payment system under the configured error scene. The method realizes the automatic operation of checking account and error processing test of the bank payment system, simplifies the test flow, reduces the investment time of personnel, and improves the sending and testing quality of development content, thereby improving the test efficiency of error processing and checking account checking mechanism and reducing the test cost.
Description
Technical Field
The invention relates to the technical field of bank data processing, in particular to a test method for checking account and processing errors of a bank payment system.
Background
For the business of the cross-line payment type in the banking system, error processing and relevant verification of the checking mechanism are required.
At present, bank payment systems generally verify error handling and reconciliation verification mechanisms by adopting the following methods: according to the overtime condition between the payment system and the associated system, the developer writes a daytime error processing mode according to the interface layer, and the intermodulation processing of the interface layer is completed normally; when checking account for the end of day, the data comparison is completed only according to the account checking files given by three parties (other rows, payment and cores), if errors are corresponding under the condition of inconsistency, the subsequent account compensation or the normal call between the interfaces can be realized, and the sending and testing conditions considered by the developer are reached. When a tester is logged in, a timeout scene appears between the payment system and the associated system, whether the transaction fund flow is completed is taken as a starting point, whether a daytime error processing mechanism is reasonable or not and whether a daily final account checking result and a daily final error processing mode are reasonable or not are considered. The developer and the tester stand at different angles, so that the test of the function is often faced with the condition of testing and developing at the same time. After a round of testing is completed, a function that has been verified earlier often occurs, resulting in new problems due to the code altered by the later modification defect. To ensure quality, only the test runs can be increased continuously.
The verification method has the following problems: (1) The requirement on personnel business quality is high and personnel are required to participate in the whole process. The test personnel and the developer need to be simultaneously input when the test starts, and the related verification is completed by mutual cooperation; (2) For data checked out at the end of the day, many repeated works often occur due to the need to re-pre-embed the data because the data is invalidated, for example: after checking, a certain key field in the online transaction is found, the key field is input into the database but not actually input, so that the expected result is not met by the daily end result, the related verification is required to be carried out on the re-embedded data after the problem is repaired, and the verification is required to be carried out again after the verification is completed; (3) The development is generally lower to the quality of carrying and testing of error handling and checking mechanism functional module, mainly because the condition that overtime appears between this part payment system and each system of association involves the scene more, developer's angle is different with the testers angle of seeing the problem again, leads to even the development is submitted the test after accomplishing from the survey, and the problem still is comparatively more. The content of the overtime situation between the part of payment system and the related systems is very important to banks, although the scene of production is very few, and belongs to the bottom protection mechanism of the bank cross-bank payment business, so that the functions which are rarely used in production can occur, and a great deal of time and personnel are required to be invested for relevant test work. In the test work of any bank payment system, the test task of the overtime condition between the part of payment system and each related system is a pain point and difficulty of testers and developers.
Disclosure of Invention
In order to solve the problems in the prior art, the invention provides the following technical scheme.
The invention provides a test method for checking account and processing errors of a bank payment system, which comprises the following steps:
the method comprises the steps of pre-packaging a script of configurable operation of error scenes aiming at the error scenes contained in different types of business of a bank payment system;
configuring an error scene by using the packaged script;
and carrying out the tests of daytime error processing and daily final check-up of various businesses of the bank payment system under the configured error scene.
Preferably, the testing of daytime error processing and daily final check-out of various services of the bank payment system under the configured error scene comprises the following steps:
in the development self-test stage, executing service under error scene and outputting registration data; checking whether the result of the daytime error processing or the daily terminal account checking is consistent with the expected value according to the registered data, if not, correcting a daytime error processing or daily terminal account checking mechanism, re-checking after correction until the result of the daytime error processing or daily terminal account checking is consistent with the expected value, and entering a test stage;
in the test stage, executing service under error scene and outputting registration data; and checking whether the result of daytime error processing or daily final checking check is consistent with the expectation according to the registration data, if not, submitting the defect to a corresponding developer, and returning to a development self-test stage until the result of daytime error processing or daily final checking in the test stage is consistent with the expectation.
Preferably, whether the result of the day end reconciliation check is consistent with the expectation comprises: whether the corresponding business state after the end-of-day account checking is updated corresponds to whether the data transferred to the suspicious state or the end-of-day error is correct, whether the end-of-day error is consistent with the expected state, and/or whether the account supplementing processing mechanism is consistent with the expected state.
Preferably, said verifying whether the result of the daytime error handling or the end-of-day accounting verification is consistent with the expectation based on the check-in data comprises: and checking various errors according to the result of the daytime error processing or the daytime end account checking according to the service type.
Preferably, the script includes a script to add a barrier, a script to simulate data transmission, a script to register data information output, and a script for environment restoration.
Preferably, the service includes: the account-going credit type business, the account-coming credit type business, the account-going debit type business and the third party account-coming type transaction.
Preferably, for the forward credit type service, configuring the error scene with the encapsulated script includes:
adding a baffle which requests that the core system overtime application message is not sent to the core system, or adding a baffle which blocks the receiving core system from returning the receipt message, or adding a baffle which requests that the people bank center preposed system, or adding a baffle which blocks the receiving people bank center from returning the receipt message;
using message to simulate data transmission, and executing data registration once when transmitting one data; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
Preferably, for the account-and-credit type service, configuring the error scene with the encapsulated script includes:
adding a baffle for blocking message information sent by other rows, or adding a baffle for requesting that the message of the core system is failed to be sent, or adding a baffle for blocking receipt of the receipt message of the core system;
the development self-test stage uses message to simulate data transmission, and the test stage uses simulation or contacts other participation lines to simulate data transmission; performing data registration once every time one data is transmitted; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
Preferably, configuring the error scene with the encapsulated script for the debit-to-account class service includes:
adding a baffle for failing to send the message of the people banking center, or adding a baffle for preventing other receipt messages from being received in the bank, or adding a baffle for requesting the overtime application message of the core system not to be sent to the core system, or adding a baffle for blocking the receiving core system from returning the receipt message;
using message to simulate data transmission, and executing data registration once when transmitting one data; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
Preferably, configuring the error scene with the encapsulated script for the account debit class service includes:
adding a baffle for blocking message information sent by other rows, or adding a baffle for overtime of sending other rows, or adding a baffle for failing to send the message of the request core system overtime, or adding a baffle for blocking receipt messages returned by the payment system by the receiving core system;
the development self-test stage uses message to simulate data transmission, and the test stage uses simulation or contacts other participation lines to simulate data transmission; performing data registration once every time one data is transmitted; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
The beneficial effects of the invention are as follows: (1) The automatic operation of the bank payment system in the process of error processing and verification of the checking mechanism is realized, the subsequent testing flow is simplified, the input time of advanced/expert personnel is reduced, the sending and testing quality of development content is improved, the testing efficiency of the error processing and checking mechanism is improved, and the input cost of the part of work is reduced; (2) Aiming at the technical problem of how to realize the efficient completion of the test of the account checking and error processing mechanism of the bank payment system, the bank payment system provided by the invention realizes the configurable operation of baffle addition, data transmission and baffle withdrawal by using the script, completes the configuration of error scenes of various businesses, simplifies the pre-buried flow of error scene data, reduces the personnel proportion (no longer needing to be matched with the simultaneous investment of test personnel) which needs to be simultaneously input, simultaneously improves the quality of the transmitted and tested content by guiding the developer to efficiently complete the self-test of the unit so as to realize the test task of the error processing and account checking mechanism.
Drawings
FIG. 1 is a flow chart of a method for testing account checking and error handling of a bank payment system according to the present invention;
FIG. 2 is a schematic diagram of a payment system account statement service flow and baffle add nodes;
FIG. 3 is a schematic diagram of a payment system accounting credit type business process and baffle add nodes;
FIG. 4 is a schematic diagram of a payment system debit-to-account business process and a baffle add node;
fig. 5 is a schematic diagram of a payment system account-taking and debit-type business process and a baffle-adding node.
Detailed Description
In order to better understand the above technical solutions, the following detailed description will be given with reference to the accompanying drawings and specific embodiments.
As shown in fig. 1, an embodiment of the present invention provides a method for testing account checking and error handling of a bank payment system, including: s101, pre-packaging a script of configurable operation of an error scene aiming at the error scene contained in different types of business of a bank payment system; s102, configuring an error scene by using the packaged script; s103, performing tests of daytime error processing and daily end account checking of various businesses of the bank payment system under the configured error scene, wherein the tests comprise the following steps: in the development self-test stage, executing service under error scene and outputting registration data; checking whether the result of the daytime error processing or the daily terminal account checking is consistent with the expected value according to the registered data, if not, correcting a daytime error processing or daily terminal account checking mechanism, re-checking after correction until the result of the daytime error processing or daily terminal account checking is consistent with the expected value, and entering a test stage; in the test stage, executing service under error scene and outputting registration data; and checking whether the result of daytime error processing or daily final checking check is consistent with the expectation according to the registration data, if not, submitting the defect to a corresponding developer, and returning to a development self-test stage until the result of daytime error processing or daily final checking in the test stage is consistent with the expectation.
Wherein whether the result of the day end reconciliation check is consistent with the expectation comprises: whether the corresponding business state after the end-of-day account checking is updated corresponds to whether the data transferred to the suspicious state or the end-of-day error is correct, whether the end-of-day error is consistent with the expected state, and/or whether the account supplementing processing mechanism is consistent with the expected state.
Further, the verifying whether the result of the daytime error handling or the end-of-day accounting verification is consistent with the expectation based on the check-in data includes: and checking various errors according to the result of the daytime error processing or the daytime end account checking according to the service type.
The scripts comprise a baffle adding script, a data sending simulating script, a data information output registering script and an environment restoring script.
In the embodiment of the invention, the service comprises the following steps: the account-going credit type business, the account-coming credit type business, the account-going debit type business and the third party account-coming type transaction.
For the forward credit business, the error scene is configured by using the packaged script, which comprises the following steps: adding a baffle which requests that the core system overtime application message is not sent to the core system, or adding a baffle which blocks the receiving core system from returning the receipt message, or adding a baffle which requests that the people bank center preposed system, or adding a baffle which blocks the receiving people bank center from returning the receipt message; using message to simulate data transmission, and executing data registration once when transmitting one data; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
The core system is the most basic system mainly based on loan deposit business of the bank and is mainly used for completing the individual account accounting processing of customer accounts and internal accounts, and meanwhile, the core system is also an accounting processing system and is used for processing the clearing accounting of the bank subjects.
The environment recovery refers to that a baffle which is added before and used for blocking communication between the systems is withdrawn, so that interaction between the systems is recovered to be normal, and the condition that communication between the systems is not smooth due to human intervention does not exist.
For the account-taking credit type service, configuring an error scene by using the packaged script comprises the following steps: adding a baffle for blocking message information sent by other rows, or adding a baffle for requesting that the message of the core system is failed to be sent, or adding a baffle for blocking receipt of the receipt message of the core system; the development self-test stage uses message to simulate data transmission, and the test stage uses simulation or contacts other participation lines to simulate data transmission; performing data registration once every time one data is transmitted; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
The other participating banks comprise other banks or financial institutions except the current bank, and can realize fund exchange with the current bank through payment platforms such as a people bank size system, a super-network system, an internet connection system, a banking system, a city banking system, an agricultural credit banking system and the like.
For the account going debit class business, configuring the error scene by using the packaged script comprises the following steps: adding a baffle for failing to send the message of the people banking center, or adding a baffle for preventing other receipt messages from being received in the bank, or adding a baffle for requesting the overtime application message of the core system not to be sent to the core system, or adding a baffle for blocking the receiving core system from returning the receipt message; using message to simulate data transmission, and executing data registration once when transmitting one data; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
For the account debit class service, configuring an error scene by using the packaged script comprises the following steps: adding a baffle for blocking message information sent by other rows, or adding a baffle for overtime of sending other rows, or adding a baffle for failing to send the message of the request core system overtime, or adding a baffle for blocking receipt messages returned by the payment system by the receiving core system;
the development self-test stage uses message to simulate data transmission, and the test stage uses simulation or contacts other participation lines to simulate data transmission; performing data registration once every time one data is transmitted; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
Aiming at third party account-entering transaction (such as internet connection and instant transfer, the third party forwards the transaction to the current line), according to the multiplexing account-entering debit type scene when the line is used as a scene of a payer, the multiplexing account-entering credit type transaction scene is used as the scene of the payment, the simulation is carried out, only the corresponding message influenced by a baffle plate required by replacement is needed, the positions of the baffle plates are added in the transaction scene, the required baffle plate scenes are integrated to a configuration interface respectively, and the follow-up operators only need simple configuration work;
the data required to be output in the above scene includes: business scene, platform running water, other working dates, account numbers and family names of payers, and data information related to the account numbers and family names of payee and the system platform date are collected, and integral file output can be realized.
In the embodiment of the invention, the baffle plate is a logic code for blocking the scene of errors in the system caused by communication between the systems, and the baffle plate can be used for blocking information passing between the systems. In the actual use process, the baffle plate can be realized in the following way: the communication between the systems uses a stack queue mode, and the error scene of intermodulation timeout between the systems is realized by temporarily adjusting the information in the stack queue to be only in and out and deleting the information in the queue before the normal state is recovered; the baffle may also be implemented as follows: when communication between systems has no concept of stack team, the IP address of a message receiver can be changed, so that the message is abnormally sent or received, and an error scene of intermodulation timeout between systems is realized.
The invention provides a specific embodiment of a test method for checking account and processing errors of a bank payment system, which can be implemented according to the following steps: step S10, packaging a baffle plate, analog data transmission, registration data information and a scene recovery script which are required to be added in the test process into a payment system error scene configuration platform for configurable operation according to the characteristics of the system and the scene of the service, changing different configuration rules according to the test scene, thereby completing configuration of the added baffle plate, analog transmission data transmission, cancellation of the baffle plate and output of a registered transaction data information table, facilitating subsequent processing, wherein advanced or expert-level development and whole-course participation of testers are required; step S20, a developer performs data preparation by using the step S10 in the daytime error data verification process, two pens are needed to be pre-embedded in one scene, one pen is used for daytime error processing, and the other pen is used for checking a daily end account checking result in the step S30; after corresponding daytime error data appear, writing corresponding scripts to automatically judge whether system error processing meets expectations or inquires, or is positive, or is supplementary, if scene error processing is inconsistent with expectations, interface early warning reminding is carried out, corresponding developers carry out problem positioning after receiving early warning, the steps are repeated again after defect resolution, relevant verification is carried out by submitting testers after expected results are met, and the part can replace primary and middle level developers to participate, so that advanced and expert personnel can carry out guiding work; step S30, aiming at the data to be checked for the final daily account of S20, a developer compiles a script completion system to automatically judge whether the final daily account checking result meets the expectations, including whether business state update and account checking states (or account checking, or doubt, or account checking errors entering the final daily account) meet the expectations, checking according to preset scenes, if inconsistent conditions exist, carrying out early warning reminding, carrying out problem positioning after receiving early warning by the corresponding developer, re-executing the steps for re-verification after defect solving, submitting a tester for relevant verification after meeting the expected results, wherein the part can replace the participation of primary and intermediate level developers, and the advanced and expert staff carry out guiding work; step S40, the testers begin to intervene in the step S10 to finish data embedding, at least two pieces of data are embedded in each error scene, one piece is used for daytime error processing verification, the other piece is used for daily final account checking, daytime error processing is performed according to an output data table after the data embedding is finished, whether a daytime error processing mechanism meets expectations or not is verified, the part can replace primary and middle level testers to participate, and advanced and expert staff conduct guiding work; in step S50, the tester starts checking and checking the checking data of the end of the intervention day, checks the checking result of the checking data by using the data output in S40, checks the checking result (or checking, or in doubt) of the data which has completed the error processing in the day, checks one by one whether the checking result meets the expectations for the checking state (or checking, or in doubt, or uneven checking entering into the end of the day error) of the data which has not undergone the error processing in the day, and whether the end of the day error processing mechanism meets the expectations, and the part can replace the participation of the initial and intermediate level testers, and the expert staff can conduct guiding work.
Further, for step S10, the following method may be implemented: step S11: for the credit business (business of the active payment type), the business flow is shown in fig. 2, after the payment system receives the payment type instruction, the core system is requested to complete the operation of deducting the balance of the account of the payer, after the core system receives the definite successful receipt, the payment system requests other rows to complete the credit and the payment, after the off-line (other rows) payment system receives the request of the credit business, if the successful receipt is returned, the credit and the credit business is successful, and the transaction is ended; if the failed receipt is returned, the payment system needs to continuously request the core system to complete the clearing, funds are returned to the customer account, after the core system receives the clear successful receipt, the credit to account business fails, and the transaction is ended. Different baffles may be added according to different scenes as desired. For example, a baffle may be added at the position with the number 2 or 17 in fig. 2, where the request core system timeout request message is not sent to the core system. A baffle may be added at the location of sequence number 6 or 20 to block the receiving core system from returning receipt messages. Baffles requesting other rows may be added at the position of sequence number 8: 1) The front-end system of the pedestrian center is requested to add a baffle to realize the scene of failure in sending other rows, and 2) the baffle for blocking the receipt of the return receipt message of the pedestrian center is added to realize the scene that the pedestrian transaction is in the middle state in the final state row. After the baffle is set, waiting for 1-5 minutes, configuring an interface test tool to simulate an upstream channel to initiate an account-sending message, carrying out data registration at the position of the serial number 21 every time 1 stroke is sent, then repeatedly simulating the initiated message, and executing environment recovery at the position of the serial number 22 after the preset stroke number is reached, wherein after the environment recovery, an interface is successfully reminded of recovery, and an operator is informed of the fact that the environment has recovered normally. The baffle scenes are integrated into the configuration interface respectively, and subsequent operators only need simple configuration work to realize the wanted error scene, so that the operation flow is simplified and quick deployment is realized.
And, step S12: for the account-receiving credit business (passive payment business), the business flow is shown in fig. 3, other rows send the credit business to the current row, after the in-row payment system receives the account-receiving credit business, the core system is requested to complete accounting processing, account-receiving processing is carried out on the client account or account-receiving failure, after the core system definitely succeeds in receipt, the credit account-receiving transaction succeeds, and the business is ended. Different baffles are added according to different error scenes. For example, a baffle is added at the position with the number of 2 in fig. 3 to block the message information sent by other rows, so as to complete the scene that the person has the current row or not (the scene that the other rows have the current row or not). The baffle of the request core is added at the position with the sequence number of 6: 1) Adding a baffle when requesting the core causes the request message to fail to send the core (the core does not receive the accounting request of the payment system), and 2) adding a baffle for blocking the receipt of the receipt message of the core system (the scene that the payment system does not receive the actual result of the core is realized). After the baffle plate is set, waiting for 1-5 minutes, configuring and using an interface test tool to simulate other lines to send account information (the part only uses message simulation in a self-test stage of development, all accounts coming from a test stage of a tester need to contact other lines to help send transactions or use a simulation system to simulate accounts), carrying out data registration once at the position of a serial number 12 every time 1 line is sent, carrying out data statistics to a preset number, triggering scene recovery at the position of the serial number 13 by the system, and carrying out successful interface recovery reminding after environment recovery, so as to inform operators that the environment is recovered to be normal. The baffle scenes are integrated into the configuration interface respectively, and subsequent operators only need simple configuration work to realize the wanted error scene, so that the operation flow is simplified and quick deployment is realized.
And, step S13: for the charge and debit type business (business of active collection type), the business flow is as shown in fig. 4: the payment system receives the account-going debit instruction, sends an account-going debit type service request message to other rows (outside the rows), judges whether a payment condition is met according to the request, returns a payment receipt if the payment condition is met, and sends the payment receipt to the core system to complete the account-going operation of the collection account; if the payment condition is not met, returning a refusal receipt, and after the payment system receives the refusal receipt, failing to charge the debit business, and ending the transaction. Different baffles are added according to different error scenes. For example, a baffle may be added to interact with other rows at the position of number 3 in fig. 4: 1) When a pedestrian center is sent, a baffle is added to cause message sending failure (a scene of existence or non-existence of a pedestrian in a line is realized), and 2) the baffle is added to prevent receipt of other line receipt messages (a scene of ending of other lines in line processing is realized). Adding a baffle of the request core system at the position with the sequence number of 11: 1) Requesting that the core system timeout application message is not sent to the baffle of the core system; 2) A baffle for blocking receipt messages returned by the receiving core system is added. After the baffle plate is set, waiting for 1-5 minutes, configuring an interface test tool to simulate an upstream channel to initiate an account-sending message, carrying out data registration at the position of the serial number 17 every time 1 stroke is sent, repeatedly simulating the initiated message, and after the number reaches the preset number, executing environment recovery at the position of the serial number 18, and carrying out successful reminding on the interface after the environment is recovered to be normal, so as to inform an operator that the environment is recovered to be normal. The baffle scenes are integrated into the configuration interface respectively, and subsequent operators only need simple configuration work to realize the wanted error scene, so that the operation flow is simplified and quick deployment is realized;
and, step S14: for the account debit type service (passive payment type service), the service flow is as shown in fig. 5: the other lines (outside the line) send a debit service request, after the payment system receives the debit service, the core system is requested to carry out payment account deduction operation, the core system returns to the deduction success, the payment system returns to the payment receipt, otherwise, returns to the rejection receipt, if the debit receipt of the payment system receives the successful receipt of the other lines, the debit service is ended, and the transaction is ended; if the debit receipt of the payment system receives other failed receipts, the debit receipt service state is updated to fail, if the original debit service is the payment receipt, the payment system needs to update the debit receipt state to fail after the core system finishes the flushing, the flow of the debit service receipt is ended, and the flow is repeated after waiting for the receipt again. Different baffles are added according to different error scenes. For example, a baffle is added at the position with the number of 2 in fig. 5 to block message information sent by other rows, so as to complete the scene that the person has the current row or not (and the scene that the transaction of other rows is successfully forwarded but not received in the row); and adding a baffle plate for sending other lines of messages overtime, failing to actually send or not receiving other lines of receipt after the successful actual sending at the position with the sequence number of 12. The barrier of the request core is added at the position with the sequence number of 6 or 24: the request core overtime payment sent application message is not sent to the baffle of the core system; and adding a baffle for blocking the receipt message returned by the core system by the payment system at the position with the serial number of 9 or 20. After the baffle plate is set, waiting for 1-5 minutes, configuring and using an interface test tool to simulate other line-initiated account-sending messages (the messages are only used in development and self-time measurement), carrying out data registration at the position of the serial number 17 every time 1 stroke is sent, then repeatedly simulating message initiation, after the preset number is reached, executing environment recovery at the position of the serial number 18, and carrying out successful reminding of recovery on the interface after the environment is recovered to be normal, and notifying an operator that the environment is recovered to be normal. The baffle scenes are integrated into the configuration interface respectively, and subsequent operators only need simple configuration work to realize the wanted error scene, so that the operation flow is simplified and quick deployment is realized;
and, step S15: aiming at third party account-entering transaction (such as internet connection and instant transfer, the third party forwards the transaction to the current line), according to the in-line multiplexing account-entering debit type scene as a payer scene, the in-line multiplexing account-entering credit type transaction scene simulation is carried out as a cash-receiving multiplexing account-entering credit type transaction scene, only the corresponding message influenced by the baffle plate required for replacement is needed, the positions of the baffle plates added in the transaction scene are the same, the required baffle plate scenes are integrated to the configuration interface respectively, and the follow-up operators only need simple configuration work.
The data output in the above steps include: business scene, platform running water, other working dates, payer account number and family name, payee account number and family name, and system platform date related data, and can realize integral file output.
In steps S11-S15, corresponding baffles are added at different positions according to different scenes aiming at error scenes possibly occurring in various services so as to achieve error scenes preset by the corresponding services, and data embedding and data registering work is completed.
Further, for step S20, the following method may be implemented: step S21: the developer starts to execute the step S10, all data can be simulated by the configured script, and the registered data of the corresponding error scene is output. Step S22: aiming at the flow information of the outputted registration data, according to the scene and the flow number as the judging basis, the corresponding writing SQL statement judges whether the daytime error processing result of the corresponding flow is consistent with the expected one, if the conditions of the inconsistency are met, a reminding mechanism needs to be set, after the reminding is received, a developer checks whether the daytime error processing mechanism has a problem or not, and the judgment and the verification are carried out again after the error correction adjustment until the verification result is consistent with the expected one. Step S23: for the business of checking ending, respectively performing coverage verification according to each error scene according to the business of the account going credit class, the account going debit class, the account coming credit class and the account coming debit class: querying (the expected result is met by querying the core, or updating the local state by the state of the pedestrian center); flushing account (flushing and correcting process is carried out for the situation of multi-deduction of customer account in line, and the correctness of business processing is checked); ledger (for the case of less-in-line customer ledgers, funds are replenished to customers through this day-to-day error handling mechanism); ignoring (setting the pen error as invalid without continuing processing); adjustment fails (for business with failed pedestrian center sent in line, customers are rushed to trade, and adjustment failure billing processing is carried out after manual verification). The polling coverage is carried out for the service type and the possible error handling mechanism, and the system can normally handle and then can provide the test personnel with the test stage.
Further, for step S30, the following method may be implemented: step S31: the developer starts to execute the step S10, all data can be simulated through the configured script, and the registration data of the corresponding error scene is output; step S32: and verifying after the pre-buried data is subjected to daily final reconciliation, writing a corresponding script according to the output serial number and the scene, and judging whether the daily final reconciliation result is consistent with the expected result and whether the business state update is correct. If the judgment result is inconsistent with the expectation, registering inconsistent flow information and scenes and outputting the flow information and the scenes, and verifying by a developer at the same time, so that the final daily account checking result is consistent with the expectation; step S33: aiming at the business of ending the account checking at the day end, the day end error processing mechanism respectively performs coverage verification on corresponding scenes: flushing account (flushing and correcting process is carried out for the situation of multi-deduction of customer account in line, and the correctness of business processing is checked); ledger (for the case of less-in-line customer ledgers, funds are replenished to customers through this day-to-day error handling mechanism); ignoring (setting the pen error as invalid without continuing processing). And carrying out full coverage verification according to the types of errors which can occur in the account going credit, the account coming credit, the account going debit and the account coming debit respectively, and submitting the expected result to corresponding testers to enter a testing stage.
Further, for step S40, the following method may be implemented: step S41: the testers start to perform scene configuration and pre-buried data according to the step S10, at the moment, data preparation can be performed in a message simulation mode aiming at account-going transactions in the script, the account-going scenes in the script need to be simulated by the testers or are connected with other participation lines for simulation transmission, and an output flow information table is obtained after the data pre-buried is completed; step S42: and the testers check the corresponding running information and account transaction details according to the output running water, check the corresponding running water information and account transaction details according to the corresponding scene and running water number, then perform the daytime error processing, check whether the system implementation is consistent with the case expectation or not, if not, submit the defect to the corresponding developer to locate the problem and solve the defect, and finally realize that the error processing is consistent with the expectation.
Further, for step S50, the following method may be performed: after the data which is not processed by errors in the daytime and the like are checked by manpower according to the output scene and serial numbers after the data which is not processed by errors in the daytime and the like are checked by using the step S10, whether the checking result is consistent with expectations, whether the corresponding business state after the checking is completed is updated correspondingly, whether the data which is transferred to suspicious state or is in the daytime and the like is correct, whether the processing mechanisms such as punching and checking the errors in the daytime and the like are consistent with expectations or not are checked, if no situation exists, the defects are submitted to corresponding developers to locate the problems and solve the defects, and finally the consistency of the errors in the daily and the expectations is realized.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the invention. It will be apparent to those skilled in the art that various modifications and variations can be made to the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.
Claims (9)
1. The method for testing account checking and error processing of the bank payment system is characterized by comprising the following steps of:
the method comprises the steps of pre-packaging a script of configurable operation of error scenes aiming at the error scenes contained in different types of business of a bank payment system;
configuring an error scene by using the packaged script;
and carrying out the tests of daytime error processing and daily final checking of various businesses of the bank payment system under the configured error scene, wherein the tests comprise the following steps:
in the development self-test stage, executing service under error scene and outputting registration data; checking whether the result of the daytime error processing or the daily terminal account checking is consistent with the expected value according to the registered data, if not, correcting a daytime error processing or daily terminal account checking mechanism, re-checking after correction until the result of the daytime error processing or daily terminal account checking is consistent with the expected value, and entering a test stage;
in the test stage, executing service under error scene and outputting registration data; and checking whether the result of daytime error processing or daily final checking check is consistent with the expectation according to the registration data, if not, submitting the defect to a corresponding developer, and returning to a development self-test stage until the result of daytime error processing or daily final checking in the test stage is consistent with the expectation.
2. The method for testing the reconciliation of the bank payment system and the error handling of claim 1, wherein the step of determining whether the result of the final daily reconciliation is consistent with the expected result comprises: after the daily terminal checking, whether the corresponding business state is updated correspondingly, whether the data transferred to the suspicious or daily terminal error is correct, whether the daily terminal error is consistent with the expected date, and/or whether the account supplementing processing mechanism is consistent with the expected date.
3. The method for testing the reconciliation of the payment system and the error handling of the bank as defined in claim 1, wherein the checking whether the result of the daytime error handling or the end-of-day reconciliation is consistent with the expected result based on the check-in data comprises:
and checking various errors according to the result of the daytime error processing or the daytime end account checking according to the service type.
4. The method for testing the reconciliation check and error handling of a bank payment system of claim 1, wherein the scripts include a script for adding a barrier, a script for simulating data transmission, a script for registering data information output, and a script for environment restoration.
5. The method for testing the reconciliation check and the error handling of a bank payment system of claim 4, wherein the business comprises: the account-going credit type business, the account-coming credit type business, the account-going debit type business and the third party account-coming type transaction.
6. The method for testing the reconciliation of the payment system and the error handling of the bank as defined in claim 5, wherein the configuring the error scenario with the encapsulated script for the reconciliation credit type service comprises:
adding a baffle which requests that the core system overtime application message is not sent to the core system, or adding a baffle which blocks the receiving core system from returning the receipt message, or adding a baffle which requests that the people bank center preposed system, or adding a baffle which blocks the receiving people bank center from returning the receipt message;
using message to simulate data transmission, and executing data registration once when transmitting one data; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
7. The method for testing the reconciliation of the payment system and the error handling of the bank as defined in claim 5, wherein configuring the error scenario with the encapsulated script for the account-and-credit-like service comprises:
adding a baffle for blocking message information sent by other rows, or adding a baffle for requesting that the message of the core system is failed to be sent, or adding a baffle for blocking receipt of the receipt message of the core system;
the development self-test stage uses message to simulate data transmission, and the test stage uses simulation or contacts other participation lines to simulate data transmission; performing data registration once every time one data is transmitted; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
8. The method for testing the reconciliation of the payment system and the error handling of the bank of claim 5, wherein configuring the error scenario with the encapsulated script for the reconciliation and debit type service comprises:
adding a baffle for failing to send the message of the people banking center, or adding a baffle for preventing other receipt messages from being received in the bank, or adding a baffle for requesting the overtime application message of the core system not to be sent to the core system, or adding a baffle for blocking the receiving core system from returning the receipt message;
using message to simulate data transmission, and executing data registration once when transmitting one data; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
9. The method for testing the check-up and error handling of a bank payment system according to claim 5, wherein configuring the error scene with the encapsulated script for the account debit type service comprises:
adding a baffle for blocking message information sent by other rows, or adding a baffle for overtime of sending other rows, or adding a baffle for failing to send the message of the request core system overtime, or adding a baffle for blocking receipt messages returned by the payment system by the receiving core system;
the development self-test stage uses message to simulate data transmission, and the test stage uses simulation or contacts other participation lines to simulate data transmission; performing data registration once every time one data is transmitted; and recovering the environment after the repeated operation reaches the preset number of sending strokes.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311018631.1A CN116737465B (en) | 2023-08-11 | 2023-08-11 | Test method for checking account and processing errors of bank payment system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311018631.1A CN116737465B (en) | 2023-08-11 | 2023-08-11 | Test method for checking account and processing errors of bank payment system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116737465A true CN116737465A (en) | 2023-09-12 |
| CN116737465B CN116737465B (en) | 2024-04-02 |
Family
ID=87917228
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311018631.1A Active CN116737465B (en) | 2023-08-11 | 2023-08-11 | Test method for checking account and processing errors of bank payment system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116737465B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117435630A (en) * | 2023-12-21 | 2024-01-23 | 杭银消费金融股份有限公司 | Rule preposition-based data verification method and system |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4774664A (en) * | 1985-07-01 | 1988-09-27 | Chrysler First Information Technologies Inc. | Financial data processing system and method |
| US8204824B2 (en) * | 2003-07-29 | 2012-06-19 | Mtrex, Inc. | System and method of account reconciliation for electronic transactions |
| US20180025435A1 (en) * | 2016-07-22 | 2018-01-25 | Nec Europe Ltd. | Method for secure ledger distribution and computer system using secure distributed ledger technology |
| CN113032176A (en) * | 2021-03-23 | 2021-06-25 | 中国邮政储蓄银行股份有限公司 | Distributed transaction double-compensation method and device based on daily account checking |
| CN114385749A (en) * | 2021-12-02 | 2022-04-22 | 天翼电子商务有限公司 | Accounting processing apparatus based on communication account fund safety |
-
2023
- 2023-08-11 CN CN202311018631.1A patent/CN116737465B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4774664A (en) * | 1985-07-01 | 1988-09-27 | Chrysler First Information Technologies Inc. | Financial data processing system and method |
| US8204824B2 (en) * | 2003-07-29 | 2012-06-19 | Mtrex, Inc. | System and method of account reconciliation for electronic transactions |
| US20180025435A1 (en) * | 2016-07-22 | 2018-01-25 | Nec Europe Ltd. | Method for secure ledger distribution and computer system using secure distributed ledger technology |
| CN113032176A (en) * | 2021-03-23 | 2021-06-25 | 中国邮政储蓄银行股份有限公司 | Distributed transaction double-compensation method and device based on daily account checking |
| CN114385749A (en) * | 2021-12-02 | 2022-04-22 | 天翼电子商务有限公司 | Accounting processing apparatus based on communication account fund safety |
Non-Patent Citations (3)
| Title |
|---|
| 刘志清: "变更管理系统的研究和实现", 中国优秀硕士学位论文全文数据库信息科技辑（月刊）, no. 07, pages 138 - 88 * |
| 朱胡勇，等: "浅析基于国产硬件的中小银行开发平台的性能", 网络空间安全, pages 88 - 93 * |
| 王皓月: "某商业银行快捷支付平台的设计与实现", 中国优秀硕士学位论文全文数据库信息科技辑（月刊）, no. 02, pages 138 - 508 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117435630A (en) * | 2023-12-21 | 2024-01-23 | 杭银消费金融股份有限公司 | Rule preposition-based data verification method and system |
| CN117435630B (en) * | 2023-12-21 | 2024-03-29 | 杭银消费金融股份有限公司 | Rule preposition-based data verification method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116737465B (en) | 2024-04-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN116737465B (en) | Test method for checking account and processing errors of bank payment system | |
| US20210319013A1 (en) | Computer methods and computer systems for automatic data analysis, reconcilliation and repair | |
| CN106327317A (en) | Data verification method and device used for computer system | |
| CN106649500A (en) | Data verification method and system | |
| CN109359964A (en) | The real-time account checking method of multi-party payment channel | |
| CN110837470B (en) | Bank card network transaction testing method and device | |
| CN114971609A (en) | Reconciliation system and method for direct connection account | |
| CN108009916B (en) | Transaction dynamic adjustment-based universal payment accounting method and system | |
| CN111459800B (en) | Method, device, equipment and medium for verifying availability of service system | |
| CN108762895A (en) | Handle the method and device of distributed transaction | |
| CN112686658A (en) | Method, device, electronic equipment and storage medium for settling out payment fund | |
| CN112200670A (en) | Event-driven intelligent contract platform design | |
| CN111160885B (en) | Accounting processing method and device | |
| CN113724070A (en) | Information processing method, information processing apparatus, electronic device, and medium | |
| CN114219621A (en) | Method and system for processing peer storage business | |
| Financial Big Data Reconciliation Method | ||
| CN112419052A (en) | Transaction testing method and device, electronic equipment and readable storage medium | |
| CN111538664A (en) | System and method for testing payment marking application | |
| CN113222561A (en) | Account checking method and device, storage medium and electronic equipment | |
| CN111582851B (en) | Platform money printing method and device based on big data, electronic equipment and storage medium | |
| CN113724082B (en) | Accounting processing method, device, equipment and storage medium | |
| CN111768293B (en) | Transaction information processing method, device, equipment and storage medium | |
| CN116843458A (en) | Digital currency transaction management method, system, medium and equipment | |
| CN114936164A (en) | Automatic abnormity testing method, device, equipment and medium for distributed transaction | |
| CN115456635A (en) | Data processing method, device, equipment and medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |