Pos transaction testing method, apparatus, device, medium, and product

Abstract

The application discloses a POS transaction test method and device, equipment, medium and product, comprising: acquiring POS transaction data under each test environment, classifying the POS transaction data under each test environment according to transaction types to obtain transaction files of N transaction types; binding the transaction files of the N transaction types with N test controls; receiving a first selection operation in the case that the N test controls are displayed on a POS transaction test interface; in response to the first selection operation, acquiring POS transaction data of a first target transaction type from a transaction file of the first target transaction type bound with a target test control; and based on the POS transaction data of the first target transaction type, initiating a hypertext transfer protocol (HTTP) request to a background system of transaction flow to execute POS transaction test. According to the application, the step of configuring and debugging a POS terminal can be omitted, and the test scene limitation and test difficulty are reduced.

Description

Technical Field

[0001] This application belongs to the field of transaction testing technology, and in particular relates to a POS transaction testing method and its apparatus, equipment, medium and product. Background Technology

[0002] With economic development, point-of-sale (POS) terminals are becoming increasingly powerful and feature-rich. When users need to pay for goods, they can make purchases by swiping their cards through the POS terminal to enjoy the fast payment experience it offers. In addition, the POS terminal needs to be tested before it is put into use.

[0003] In related technologies, the testing process of POS terminals requires professional developers to install a test program, configure information such as the POS merchant terminal key and the connected test address, and require professional testers to operate it. This traditional testing method has stringent requirements on the test network, test medium, and testers, and has high limitations in test scenarios, making the testing difficult. Summary of the Invention

[0004] This application provides a POS transaction testing method and its apparatus, device, medium, and product, which can omit the steps of configuring and debugging the POS terminal, reducing the limitations of testing scenarios and the difficulty of testing.

[0005] In a first aspect, embodiments of this application provide a POS transaction testing method, which includes: upon obtaining POS transaction data in various test environments, classifying the POS transaction data in each test environment according to transaction type to obtain N transaction files of different transaction types, wherein the transaction files are used to store POS transaction data of the corresponding transaction type; binding the N transaction files of different transaction types to N test controls; when the N test controls are displayed on the POS transaction testing interface, receiving a first selection operation on a target test control among the N test controls; in response to the first selection operation, obtaining POS transaction data of the first target transaction type from the transaction file of the first target transaction type bound to the target test control; and based on the POS transaction data of the first target transaction type, initiating an HTTP request for hypertext transfer to the backend system of the transaction flow to execute the POS transaction test.

[0006] In some possible implementations of the first aspect, the POS transaction data includes a request message. Based on the POS transaction data of the first target transaction type, an HTTP request is initiated to the back-end system of the transaction flow, including: obtaining a request message for successful transaction from the POS transaction data of the first target transaction type; parsing the request message to obtain the Internet Protocol address of the back-end system and the field content of the transaction field carried in the request message, wherein the transaction field includes at least one of order number, merchant terminal information, and amount; updating the field content of the first field in the transaction field, the first field being used to represent a unique identifier, the transaction field including the first field and the second field, the second field being a transaction field other than the first field; based on the field content of the second field and the updated field content of the first field, simulating a request message for a POS transaction request of the first target transaction type to obtain a test request message; and initiating an HTTP request carrying the test request message to the back-end system of the transaction flow based on the Internet Protocol address.

[0007] In some possible implementations of the first aspect, after obtaining transaction files for N transaction types, the method further includes: naming the transaction files for the transaction types with transaction codes used to identify the transaction types.

[0008] In some possible implementations of the first aspect, POS transaction data in each test environment is acquired at a first moment. After binding transaction files of N transaction types to N test controls, the method further includes: if the transaction type of the POS transaction data acquired within a preset time after the first moment is the same as the N transaction types, then binding the transaction files of the N transaction types to the full-scale test controls; when the full-scale test controls are displayed on the POS transaction test interface, receiving a second selection operation on the full-scale test controls; in response to the second selection operation, based on the POS transaction data of the N transaction types, initiating HTTP requests to the backend system of the transaction flow associated with each transaction type to execute the full-scale POS transaction test.

[0009] In some possible implementations of the first aspect, the POS transaction data includes request messages. After obtaining transaction files for N transaction types, the method further includes: inserting database records into the transaction files associated with the transaction types, using the transaction type as the primary key. The database records are used to record the request messages corresponding to the transaction types.

[0010] In some possible implementations of the first aspect, after binding transaction files of N transaction types with N test controls, the method further includes: scanning all transaction files based on a preset period; binding the newly added transaction file with the newly added control when a new transaction file is added; and displaying the N test controls and the newly added control on the POS transaction test interface.

[0011] Among the possible implementations of the first aspect, the method also includes: displaying N test controls on the POS transaction test interface of the browser.

[0012] Secondly, embodiments of this application provide a POS transaction testing device, which includes: a classification module, used to classify POS transaction data in various test environments according to transaction type to obtain N transaction files of different transaction types, wherein the transaction files are used to store POS transaction data of the corresponding transaction type; a binding module, used to bind the N transaction files of different transaction types to N test controls; a user input module, used to receive a first selection operation on a target test control among the N test controls when the POS transaction testing interface displays the N test controls; an acquisition module, used to acquire POS transaction data of a first target transaction type from the transaction file of the first target transaction type bound to the target test control in response to the first selection operation; and a transaction testing module, used to initiate an HTTP request for hypertext transmission to the back-end system of the transaction flow based on the POS transaction data of the first target transaction type to execute the POS transaction test.

[0013] In some possible implementations of the second aspect, the POS transaction data includes a request message, and the transaction testing module includes: an acquisition unit, used to acquire a successful transaction request message from the POS transaction data of the first target transaction type; a parsing unit, used to parse the request message to obtain the Internet Protocol address of the backend system and the field content of the transaction field carried in the request message, wherein the transaction field includes at least one of order number, merchant terminal information, and amount; an update unit, used to update the field content of the first field in the transaction field, the first field being used to represent a unique identifier, the transaction field including the first field and the second field, the second field being a transaction field other than the first field; a message generation unit, used to simulate a POS transaction request message of the first target transaction type based on the field content of the second field and the updated field content of the first field, to obtain a test request message; and a request unit, used to initiate an HTTP request carrying the test request message to the backend system of the transaction flow based on the Internet Protocol address.

[0014] In some possible implementations of the second aspect, after obtaining transaction files for N transaction types, the apparatus further includes: a naming module for naming the transaction files of the transaction types with transaction codes used to identify the transaction types.

[0015] In some possible implementations of the second aspect, POS transaction data in each test environment is acquired at a first moment. The device further includes: a binding module, which is further used to bind the transaction files of N transaction types to N test controls, and if the transaction type of the POS transaction data acquired within a preset time after the first moment is the same as the N transaction types, then bind the transaction files of the N transaction types to the full-scale test controls; a user input module, which is further used to receive a second selection operation on the full-scale test controls when the full-scale test controls are displayed on the POS transaction test interface; and a transaction test module, which is further used to respond to the second selection operation and, based on the POS transaction data of the N transaction types, initiate HTTP requests to the backend system of the transaction flow associated with each transaction type to execute the full-scale POS transaction test.

[0016] In some possible implementations of the second aspect, the POS transaction data includes request messages, and the apparatus further includes: an insertion module, used to insert database records into the transaction files associated with the transaction types after obtaining transaction files of N transaction types, with the transaction type as the primary key, the database records being used to record the request messages corresponding to the transaction types.

[0017] In some possible implementations of the second aspect, the device further includes: a scanning module for scanning all transaction files based on a preset period after binding transaction files of N transaction types with N test controls; a binding module for binding newly added transaction files with newly added controls when new transaction files are added; and a display module for displaying the N test controls and the newly added controls on the POS transaction test interface.

[0018] In some possible implementations of the second aspect, the apparatus further includes a display module for displaying N test controls on a POS transaction test interface of a browser.

[0019] Thirdly, embodiments of this application provide an electronic device, the device comprising: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the steps of the POS transaction testing method as shown in any embodiment of the first aspect.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the POS transaction testing method as shown in any embodiment of the first aspect.

[0021] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the steps of the POS transaction testing method as shown in any embodiment of the first aspect.

[0022] The POS transaction testing method, apparatus, device, medium, and product of this application, upon obtaining POS transaction data under various test environments, classifies the POS transaction data according to transaction type to obtain N transaction files for each transaction type. These transaction files store POS transaction data for the corresponding transaction type. By binding the N transaction files to N test controls, N test controls can be displayed on the POS transaction testing interface. Testers can initiate POS transaction tests for the corresponding transaction type by clicking on the test controls. Specifically, the electronic device can receive a first selection operation from the tester on a target test control among the N test controls. In response to the first selection operation, it can obtain POS transaction data of the first target transaction type from the transaction file of the first target transaction type bound to the target test control, and based on the POS transaction data of the first target transaction type, initiate a hypertext transfer HTTP request to the backend system of the transaction flow to execute the POS transaction test. Thus, the testing process of this application does not rely on the POS terminal, therefore eliminating the need for POS terminal configuration and debugging. The testing process is unaffected by the test network and test medium; only the operation of the test controls is required to execute the POS transaction test, lowering the professional threshold for testers and reducing the limitations and difficulty of the testing scenario. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a POS transaction testing method provided in an embodiment of this application;

[0025] Figure 2 This is a flowchart illustrating a POS transaction testing method provided in another embodiment of this application;

[0026] Figure 3 This is a flowchart illustrating a POS transaction testing method provided in another embodiment of this application;

[0027] Figure 4 This is a flowchart illustrating a POS transaction testing method provided in another embodiment of this application;

[0028] Figure 5 This is a schematic diagram of the structure of a POS transaction testing device provided in an embodiment of this application;

[0029] Figure 6 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0031] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0032] With economic development, point-of-sale (POS) terminals are becoming increasingly powerful and feature-rich. When users need to pay for goods, they can make purchases by swiping their cards through the POS terminal to enjoy the fast payment experience it offers. In addition, the POS terminal needs to be tested before it is put into use.

[0033] In related technologies, the testing of POS terminals requires professional developers to install a test program, configure the POS merchant terminal key, the test address, and other information, and professional testers to operate it. When problems arise such as the POS terminal failing to connect to the test network, incorrect POS machine information configuration, or testers lacking experience with POS machines and unfamiliar with POS terminal operation, a significant amount of time is needed to troubleshoot the problem or for professional personnel to guide the testing. Otherwise, testing cannot be carried out. It is evident that traditional testing methods place stringent requirements on the test network, test media, and testers, resulting in limited testing scenarios and significant testing difficulty.

[0034] To address the problems in related technologies, this application provides a POS transaction testing method. After obtaining POS transaction data from various test environments, the POS transaction data is categorized according to transaction type, resulting in N transaction files for each transaction type. These transaction files store the corresponding POS transaction data. By binding the N transaction files to N test controls, N test controls can be displayed on the POS transaction testing interface. Testers can initiate POS transaction tests for the corresponding transaction type by clicking on the test controls. Specifically, the electronic device can receive a first selection operation from the tester on a target test control among the N test controls. In response to the first selection operation, it can obtain the POS transaction data of the first target transaction type from the transaction file bound to the target test control, and based on the POS transaction data of the first target transaction type, initiate a Hypertext Transfer HTTP request to the backend system of the transaction flow to execute the POS transaction test. Thus, the testing process of this application does not rely on the POS terminal, therefore eliminating the need for POS terminal configuration and debugging. The testing process is unaffected by the test network and test medium; only the operation of the test controls is required to execute the POS transaction test, lowering the professional threshold for testers and reducing the limitations and difficulty of the testing scenario.

[0035] The POS transaction testing method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0036] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0037] Figure 1 This is a flowchart illustrating a POS transaction testing method provided in an embodiment of this application. The executing entity of this POS transaction testing method can be an electronic device. It should be noted that the aforementioned executing entity does not constitute a limitation on this application.

[0038] The aforementioned electronic devices can be devices with communication functions such as mobile phones, tablets, and all-in-one machines, or devices simulated by virtual machines or simulators. Of course, they can also include devices with storage and computing functions such as cloud servers or server clusters.

[0039] like Figure 1 As shown, the POS transaction testing method provided in this application embodiment may include steps 110-150.

[0040] Step 110: After obtaining POS transaction data from various test environments, classify the POS transaction data from each test environment according to the transaction type to obtain N transaction files for each transaction type. The transaction files are used to store POS transaction data for the corresponding transaction type.

[0041] Step 120: Bind the transaction files of N transaction types to N test controls;

[0042] Step 130: When N test controls are displayed on the POS transaction test interface, receive the first selection operation of the target test control among the N test controls;

[0043] Step 140: In response to the first selection operation, obtain POS transaction data of the first target transaction type from the transaction file of the first target transaction type bound to the target test control;

[0044] Step 150: Based on the POS transaction data of the first target transaction type, initiate an HTTP request to the backend system of the transaction flow to execute the POS transaction test.

[0045] The POS transaction testing method of this application, upon obtaining POS transaction data from various test environments, categorizes the POS transaction data according to transaction type to obtain N transaction files for each transaction type. These transaction files store the POS transaction data for the corresponding transaction type. By binding the N transaction files to N test controls, N test controls can be displayed on the POS transaction testing interface. Testers can initiate POS transaction tests for the corresponding transaction type by clicking on the test controls. Specifically, the electronic device can receive a first selection operation from the tester on a target test control among the N test controls. In response to the first selection operation, it can obtain POS transaction data for the first target transaction type from the transaction file bound to the target test control, and based on the POS transaction data for the first target transaction type, initiate an HTTP request to the backend system of the transaction flow to execute the POS transaction test. Thus, the testing process of this application does not rely on the POS terminal, therefore eliminating the need for POS terminal configuration and debugging. The testing process is unaffected by the test network and test medium; only the operation of the test controls is required to execute the POS transaction test, lowering the professional threshold for testers and reducing the limitations and difficulty of the testing scenario.

[0046] The specific implementation of the above steps will be described in detail below with reference to specific embodiments.

[0047] In step 110, after obtaining POS transaction data from various test environments, the POS transaction data from each test environment is classified according to transaction type to obtain transaction files of N transaction types.

[0048] In step 110, the transaction type is any transaction type involved in the POS terminal, which may include, but is not limited to: check-in, check-out, pre-authorization transactions, payment, scanned transactions, scanned transactions, voucher redemption transactions, and cancellation transactions.

[0049] Among these, check-in is the first operation that cashiers must perform after the POS terminal is powered on. It involves uploading the terminal number and merchant number to the UnionPay or acquiring bank's host computer via an online connection. The host computer then sends the relevant information back to the POS terminal in the form of a transaction response. Transactions can only begin after the POS terminal has completed check-in. Check-out is the operation that operators must perform at the end of the day after business hours and POS transaction settlement. After check-out, check-in must be performed again before new transactions can be processed. Some POS software is set to automatically check out after a settlement transaction is executed. Scanned transactions, main... Both scan-to-pay and voucher-verification transactions are consumer transactions, referring to transactions where cardholders use their cards to pay for shopping, dining, or other consumption at designated merchants. Cancellation transactions refer to transactions where, after a successful transaction on the same day, the cardholder or cashier discovers an error in the transaction amount or other circumstances (such as the cardholder requesting cancellation), and the original transaction needs to be cancelled before the POS terminal settlement on the same day. Pre-authorization transactions are mostly used for credit cards, and some debit cards may also support this type of transaction. Currently, this type of transaction is only available to hotels and hospitals, and prior application for activation must be submitted to UnionPay and the acquiring bank, and the issuing bank's backend support is required.

[0050] In some embodiments of this application, after obtaining transaction files for N transaction types, step 110 further includes naming the transaction files of the transaction types with transaction codes used to identify the transaction types.

[0051] The transaction file can contain request messages in formats such as XML, 8583, and JSON.

[0052] In some embodiments of this application, POS transaction data may include request messages. After obtaining transaction files of N transaction types in step 110, the method may further include: inserting database records into the transaction files associated with the transaction types, using the transaction type as the primary key. The database records are used to record the request messages corresponding to the transaction types.

[0053] Step 120 involves binding the transaction files of N transaction types to N test controls.

[0054] In step 120, each test control is used to identify the corresponding transaction type, which can trigger the POS transaction test of the corresponding transaction type. After binding the transaction files of N transaction types with N test controls, the electronic device can display N test controls on the POS transaction test interface.

[0055] For example, an electronic device can bind transaction data from a primary scan transaction to a test control labeled "Primary Scan Test." Thus, when testers want to test whether the primary scan function of the POS terminal is working properly, they can manually operate the "Primary Scan Test" test control to trigger the electronic device to simulate a primary scan transaction on the POS terminal and perform a primary scan transaction test.

[0056] In some embodiments, the electronic device can display N test controls on the POS transaction test interface of the browser. In this way, after logging into the browser, the tester can complete the test of the POS transaction by operating on the browser page. The test steps are simple and easy to operate.

[0057] In some embodiments of this application, in order to expand the scope of POS transaction testing, Figure 2 This is a flowchart illustrating a POS transaction testing method provided in another embodiment of this application.

[0058] like Figure 2 As shown, after step 120, the method may further include steps 210-230.

[0059] Step 210: Scan all transaction files based on a preset period;

[0060] Step 220: When a new transaction file is added, bind the new transaction file to the new control;

[0061] Step 230: Display N test controls and newly added controls on the POS transaction test interface.

[0062] The newly added transaction files correspond to the newly added transaction types, and the newly added controls are used to trigger POS transaction tests for the new transaction types. The preset period can be set according to specific needs, such as scanning once every 10 minutes or other values; this application does not impose specific limitations on this.

[0063] In step 130, when N test controls are displayed on the POS transaction test interface, the first selection operation of the target test control among the N test controls is received.

[0064] In step 130, the POS transaction test interface is a front-end test interface developed for testers. Through the operation of test controls on this interface, automated testing can be carried out. This method saves significant manpower and time resources, preventing delays caused by network issues or testers' lack of knowledge about operating the POS machine, thus ensuring smooth functional testing. Furthermore, the menu-driven button testing interface greatly reduces testers' reliance on the POS machine, improving development and testing efficiency.

[0065] The target test control is the test control selected by the tester. The first selection operation can be the user's click operation, long press operation, or other operation to select the target test control among N test controls.

[0066] In step 140, in response to the first selection operation, POS transaction data of the first target transaction type is obtained from the transaction file of the first target transaction type bound to the target test control.

[0067] In step 140, the electronic device can obtain POS transaction data of the first target transaction type from the transaction file of the first target transaction type.

[0068] The POS transaction data includes data on successful transactions, not data on failed transactions.

[0069] In step 150, based on the POS transaction data of the first target transaction type, an HTTP request for hypertext transmission is initiated to the back-end system of the transaction flow to execute the POS transaction test.

[0070] In step 150, by sending an HTTP request to the backend system of the transaction flow associated with the first target transaction type, a POS transaction request of the first target transaction type initiated on a traditional POS terminal can be simulated. Based on the response message returned by the backend system, it can be determined whether the transaction test is successful, for example, by identifying the status field or response code carried in the response message.

[0071] It should be noted that the back-end systems associated with different transaction types can be the same or different. For example, the transaction types "scanning transaction" and "being scanned transaction" can be associated with the same back-end system. The transaction types "check-in" and "check-out" can be associated with the same back-end system. However, the transaction types "scanning transaction" and "check-in" can be associated with different back-end systems.

[0072] In some embodiments of this application, POS transaction data includes request messages. Figure 3 This is a flowchart illustrating a POS transaction testing method provided in another embodiment of this application.

[0073] like Figure 3 As shown, step 150 may include Figure 3 Steps 310-350 are shown.

[0074] Step 310: Obtain the transaction success request message from the POS transaction data of the first target transaction type;

[0075] Step 320: Parse the request message to obtain the Internet Protocol address of the backend system and the field content of the transaction field carried in the request message;

[0076] Step 330: Update the field content of the first field in the transaction field. The first field is used to represent a unique identifier. The transaction field includes the first field and the second field. The second field is the transaction field other than the first field.

[0077] Step 340: Based on the content of the second field and the updated content of the first field, simulate the request message of the POS transaction request of the first target transaction type to obtain the test request message;

[0078] Step 350: Based on the Internet Protocol address, initiate an HTTP request carrying a test request message to the backend system of the transaction flow.

[0079] Specifically, the transaction field is a field carried in the request message that is related to the first target transaction type. The transaction field may include at least one of the following: order number, merchant terminal information, and amount.

[0080] For example, when the first target transaction type is at least one of payment, scanned, scanned by the customer, voucher redemption, return, or cancellation transaction, since all of the above transaction types involve order number, terminal information, and transaction amount, the transaction field of the request message in the POS transaction data of the first target transaction type can include order number, merchant terminal information, and amount.

[0081] The first field is used to represent a unique identifier. For example, among the three transaction fields of order number, merchant terminal information, and amount, the order number is unique and non-repeating, thus it can represent a unique identifier. Therefore, the order number can be the first field, and the merchant terminal information and amount, excluding the first field, are the second fields. Based on this, since a duplicate order number will cause an error and prevent the transaction test from completing, the order number in the request message can be updated. For example, a new order number can be randomly generated, or some digits of the order number in the request message can be replaced to generate a new order number. Then, combining the updated order number with the merchant terminal information and amount, a new request message can be simulated, which is the test request message.

[0082] In this application, the test request message is used to simulate the request message sent by the POS terminal when initiating a transaction request of the first target transaction type to the back-end system, that is, the request message of the POS transaction request of the first target transaction type. Therefore, by initiating an HTTP request carrying the test request message to the back-end system, the electronic device can simulate the POS terminal initiating a transaction request of the first target transaction type to the back-end system and execute the POS transaction test corresponding to the first target transaction type.

[0083] In this embodiment, by parsing the IP address of the backend system and the content of the transaction fields from the request message, the request message sent by the POS terminal when initiating a transaction request of the first target transaction type to the backend system can be simulated to obtain the test request message. Then, by sending an HTTP request carrying the test request message to the backend system, the transaction process between the POS terminal and the backend system can be simulated. Thus, POS transaction testing can be completed without relying on a POS terminal. Testers do not need to learn POS machine expertise to conduct testing, greatly reducing labor costs. Furthermore, it does not depend on POS machines or test media, enabling rapid automated testing, ensuring thorough and complete software development testing, and significantly reducing software bugs before deployment.

[0084] In some embodiments of this application, the electronic device can also obtain the IP address of the back-end system for transaction flow from the gateway, which is the address to which the transaction is sent.

[0085] In related technologies, when an urgent basic case regression testing task arises, if test information is configured through a traditional POS machine and individual case regression testing is started, testers will face significant pressure due to various unforeseen circumstances, resulting in high labor costs and slow testing progress.

[0086] In some embodiments of this application, in order to address the aforementioned problem of slow progress in basic case regression testing, Figure 4 This is a flowchart illustrating a POS transaction testing method provided in another embodiment of this application.

[0087] like Figure 4 As shown, after step 120, the method may further include steps 410-430.

[0088] Step 410: If the transaction type of the POS transaction data obtained within a preset time after the first moment is the same as N transaction types, then bind the transaction files of N transaction types to the full test control.

[0089] Step 420: When the full test control is displayed on the POS transaction test interface, receive the second selection operation for the full test control;

[0090] Step 430: In response to the second selection operation, based on the POS transaction data of N transaction types, initiate HTTP requests to the backend system of the transaction flow associated with each transaction type to perform a full POS transaction test.

[0091] In this process, POS transaction data from each test environment is acquired in real time. The preset duration can be set according to specific needs, such as 30 minutes, 1 hour or other values. This application does not make any specific restrictions on this.

[0092] In this embodiment, testers can trigger POS transaction execution for all transaction types with a single click, enabling full regression testing of basic test cases, greatly reducing time costs, accelerating testing progress, ensuring thorough testing, and reducing software launch bugs.

[0093] It should be noted that the POS transaction testing method provided in this application can be executed by an electronic device or a control module in a POS transaction testing system. This application uses a POS transaction testing device to execute the POS transaction testing method as an example to illustrate the POS transaction testing device provided in this application. The POS transaction testing device will be described in detail below.

[0094] Figure 5 This is a schematic diagram of the structure of a POS transaction testing device provided in an embodiment of this application. Figure 5 As shown, the POS transaction testing device 500 may include: a classification module 510, a binding module 520, a user input module 530, an acquisition module 540, and a transaction testing module 550.

[0095] The system includes the following modules: a classification module 510, which categorizes POS transaction data from various test environments according to transaction type to obtain N transaction files for each transaction type, where the transaction files store POS transaction data for the corresponding transaction type; a binding module 520, which binds the N transaction files to N test controls; a user input module 530, which receives a first selection operation on a target test control when the N test controls are displayed on the POS transaction test interface; an acquisition module 540, which, in response to the first selection operation, acquires POS transaction data of the first target transaction type from the transaction file of the first target transaction type bound to the target test control; and a transaction test module 550, which initiates an HTTP request to the backend system of the transaction flow based on the POS transaction data of the first target transaction type to execute the POS transaction test.

[0096] In some embodiments of this application, the POS transaction data includes a request message. The transaction testing module 550 includes: an acquisition unit, used to acquire a successful transaction request message from the POS transaction data of a first target transaction type; a parsing unit, used to parse the request message to obtain the Internet Protocol address of the backend system and the field content of the transaction field carried in the request message, wherein the transaction field includes at least one of order number, merchant terminal information, and amount; an update unit, used to update the field content of the first field in the transaction field, the first field being used to represent a unique identifier, the transaction field including the first field and the second field, the second field being a transaction field other than the first field; a message generation unit, used to simulate a POS transaction request message of the first target transaction type based on the field content of the second field and the updated field content of the first field to obtain a test request message; and a request unit, used to initiate an HTTP request carrying the test request message to the backend system of the transaction flow based on the Internet Protocol address.

[0097] In some embodiments of this application, after obtaining transaction files of N transaction types, the apparatus further includes: a naming module, used to name the transaction files of the transaction types with transaction codes used to identify the transaction types.

[0098] In some embodiments of this application, POS transaction data in various test environments are acquired at a first moment. The device further includes: a binding module 520, which is further configured to bind the transaction files of N transaction types to N test controls after binding transaction files of N transaction types to N test controls, and if the transaction type of the POS transaction data acquired within a preset time after the first moment is the same as the N transaction types, then bind the transaction files of the N transaction types to the full-scale test controls; a user input module 530, which is further configured to receive a second selection operation on the full-scale test controls when the full-scale test controls are displayed on the POS transaction test interface; and a transaction test module 550, which is further configured to respond to the second selection operation and, based on the POS transaction data of the N transaction types, initiate HTTP requests to the backend system of the transaction flow associated with each transaction type to perform a full-scale POS transaction test.

[0099] In some embodiments of this application, the POS transaction data includes request messages, and the apparatus further includes: an insertion module, used to insert database records into the transaction files associated with the transaction types after obtaining transaction files of N transaction types, with the transaction type as the primary key, and the database records are used to record the request messages corresponding to the transaction types.

[0100] In some embodiments of this application, the apparatus further includes: a scanning module, used to scan all transaction files based on a preset period after binding transaction files of N transaction types with N test controls; a binding module, used to bind the newly added transaction file with the newly added control when a new transaction file is added; and a display module, used to display the N test controls and the newly added control on the POS transaction test interface.

[0101] In some embodiments of this application, the apparatus further includes a display module for displaying N test controls on a POS transaction test interface of a browser.

[0102] The POS transaction testing device of this application, upon acquiring POS transaction data from various test environments, categorizes the POS transaction data according to transaction type, resulting in N transaction files for each transaction type. These transaction files store POS transaction data for the corresponding transaction type. By binding the N transaction files to N test controls, N test controls can be displayed on the POS transaction testing interface. Testers can initiate POS transaction tests for the corresponding transaction type by clicking on the test controls. Specifically, the electronic device can receive a first selection operation from the tester on a target test control among the N test controls. In response to the first selection operation, it can obtain POS transaction data for the first target transaction type from the transaction file bound to the target test control, and based on the POS transaction data of the first target transaction type, initiate an HTTP request to the backend system of the transaction flow to execute the POS transaction test. Thus, the testing process of this application does not rely on the POS terminal, therefore eliminating the need for POS terminal configuration and debugging. The testing process is unaffected by the test network and test medium; only the operation of the test controls is required to execute the POS transaction test, lowering the professional threshold for testers and reducing the limitations and difficulty of the testing scenario.

[0103] The POS transaction testing device in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0104] The POS transaction testing device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0105] Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0106] like Figure 5 As shown, the electronic device 500 in this embodiment may include a processor 501 and a memory 502 storing computer program instructions.

[0107] Specifically, the processor 501 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0108] Memory 502 may include mass storage for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 502 may include removable or non-removable (or fixed) media. Where appropriate, memory 502 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 502 is non-volatile solid-state memory. Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, a memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform operations described with reference to the methods according to embodiments of this application.

[0109] The processor 501 reads and executes computer program instructions stored in the memory 502 to implement any of the POS transaction testing methods in the above embodiments.

[0110] In one example, electronic device 500 may also include communication interface 503 and bus 510. For example, Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 510 and complete communication with each other.

[0111] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0112] Bus 510 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0113] The electronic device provided in this application embodiment is capable of achieving Figure 1-3 The various processes implemented in the method embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0114] Based on the POS transaction testing methods in the above embodiments, this application provides a POS transaction testing system, which includes the electronic equipment described in the above embodiments. For details regarding the electronic equipment, please refer to the relevant descriptions in the above embodiments; they will not be repeated here.

[0115] Furthermore, in conjunction with the POS transaction testing methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement the steps of any of the POS transaction testing methods in the above embodiments.

[0116] Based on the POS transaction testing method in the above embodiments, this application can provide a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, the electronic device performs the steps of the POS transaction testing method as shown in any embodiment of the first aspect.

[0117] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0118] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0119] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0120] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable multiple data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable multiple data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0121] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A POS transaction testing method, characterized in that, The method includes: Having obtained POS transaction data from various test environments, the POS transaction data from each test environment is classified according to transaction type to obtain N transaction files for each transaction type. The transaction files are used to store POS transaction data for the corresponding transaction type. The method further includes binding transaction files of the N transaction types to N test controls; acquiring POS transaction data in each test environment at a first moment; and after binding the transaction files of the N transaction types to the N test controls, the method also includes: if the transaction type of the POS transaction data acquired within a preset time after the first moment is the same as the N transaction types, then binding the transaction files of the N transaction types to the full-scale test controls; when the full-scale test controls are displayed on the POS transaction test interface, receiving a second selection operation on the full-scale test controls; in response to the second selection operation, based on the POS transaction data of the N transaction types, initiating HTTP requests to the backend system of the transaction flow associated with each transaction type to execute the full-scale POS transaction test; wherein the backend systems of the transaction flows associated with different transaction types may be the same or different. When the N test controls are displayed on the POS transaction test interface, a first selection operation is received for the target test control among the N test controls; In response to the first selection operation, POS transaction data of the first target transaction type is obtained from the transaction file of the first target transaction type bound to the target test control; Based on the POS transaction data of the first target transaction type, an HTTP request for hypertext transmission is initiated to the back-end system of the transaction flow to simulate the POS terminal sending a transaction request of the first target transaction type to the back-end system, and POS transaction test is performed; The POS transaction data includes a request message. The step of initiating an HTTP request to the backend system of the transaction flow based on the POS transaction data of the first target transaction type includes: obtaining a transaction success request message from the POS transaction data of the first target transaction type; parsing the request message to obtain the Internet Protocol address of the backend system and the field content of the transaction field carried in the request message, wherein the transaction field includes at least one of order number, merchant terminal information, and amount; updating the field content of the first field in the transaction field, the first field being used to represent a unique identifier, the transaction field including a first field and a second field, the second field being a transaction field other than the first field; simulating a POS transaction request message of the first target transaction type based on the field content of the second field and the updated field content of the first field to obtain a test request message; and initiating an HTTP request carrying the test request message to the backend system of the transaction flow based on the Internet Protocol address.

2. The method according to claim 1, characterized in that, After obtaining transaction files for N transaction types, the method further includes: Name the transaction file of the transaction type with the transaction code used to identify the transaction type.

3. The method according to claim 1, characterized in that, The POS transaction data includes request messages. After obtaining transaction files for N transaction types, the method further includes: Using the transaction type as the primary key, a database record is inserted into the transaction file associated with the transaction type. The database record is used to record the request message corresponding to the transaction type.

4. The method according to claim 1, characterized in that, After binding the transaction files of the N transaction types to the N test controls, the method further includes: Scan all transaction files based on a preset cycle; When a new transaction file is added, the new transaction file will be bound to the new control. The POS transaction test interface displays the N test controls and the newly added control.

5. The method according to claim 1, characterized in that, The method further includes: The N test controls are displayed on the POS transaction test interface of the browser.

6. A POS transaction testing device, characterized in that, The device includes: The classification module is used to classify the POS transaction data in each test environment according to the transaction type, and obtain N transaction files of each transaction type, wherein the transaction files are used to store the POS transaction data of the corresponding transaction type. A binding module is used to bind transaction files of the N transaction types to N test controls. POS transaction data in each test environment is acquired at a first moment. After binding the transaction files of the N transaction types to the N test controls, if the transaction type of the POS transaction data acquired within a preset time after the first moment is the same as the N transaction types, then the transaction files of the N transaction types are bound to the full-scale test controls. When the full-scale test controls are displayed on the POS transaction test interface, a second selection operation on the full-scale test controls is received. In response to the second selection operation, based on the POS transaction data of the N transaction types, an HTTP request is initiated to the backend system of the transaction flow associated with each transaction type to execute a full-scale POS transaction test. The backend systems associated with the transaction flows of different transaction types may be the same or different. The user input module is used to receive a first selection operation of the target test control among the N test controls when the N test controls are displayed on the POS transaction test interface; The acquisition module is configured to, in response to the first selection operation, acquire POS transaction data of the first target transaction type from a transaction file of the first target transaction type bound to the target test control; The transaction testing module is used to initiate an HTTP request to the backend system of the transaction flow based on POS transaction data of the first target transaction type, to simulate the POS terminal sending a transaction request of the first target transaction type to the backend system and perform POS transaction testing. The POS transaction data includes a request message. Initiating an HTTP request to the backend system of the transaction flow based on the POS transaction data of the first target transaction type includes: obtaining a transaction success request message from the POS transaction data of the first target transaction type; parsing the request message to obtain the interconnection information of the backend system carried in the request message. The system retrieves the field content of the Internet Protocol address and the transaction field, wherein the transaction field includes at least one of order number, merchant terminal information, and amount; updates the field content of the first field in the transaction field, the first field being used to represent a unique identifier, the transaction field including a first field and a second field, the second field being a transaction field other than the first field; based on the field content of the second field and the updated field content of the first field, simulates a POS transaction request message for the first target transaction type to obtain a test request message; and initiates an HTTP request carrying the test request message to the backend system of the transaction flow based on the Internet Protocol address.

7. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the POS transaction testing method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the steps of the POS transaction testing method as described in any one of claims 1-5.

9. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the steps of the POS transaction testing method as described in any one of claims 1-5.

Images