Multi-city e-ticket transaction testing tool

Abstract

The present invention discloses a multi-city electronic ticket transaction testing tool, comprising a request module for obtaining user information corresponding to a registered user's phone number in response to a query request; a user information determination module for confirming the user information entered into the modification box and obtaining the confirmed user information; a trip module for composing entry or exit information; a gate message assembly module for sending a user entry or exit gate message to the subway ticketing system under test; an interface recording module for monitoring the process of the interface module sending the user entry or exit gate message and generating an interface log record; and a trip query module for obtaining user trip transaction information. This tool achieves the goals of batch testing in different cities, simple operation, and low-cost testing.

Description

Technical Field

[0001] The present invention relates to the technical field of ticketing system testing, and in particular to a multi-city electronic ticket transaction testing tool and a testing method. Background Art

[0002] See attached Figure 1 The subway ticketing system is a computer system that performs transaction settlement control based on entry and exit gate records, performing ticketing logic operations, and generating travel transaction records. After updating the ticketing logic of the subway ticketing system, a series of tests are required, such as normal testing and abnormal testing. Abnormal testing includes testing business logic such as scanning the QR code to board the train when the user has no payment channel, scanning the QR code to board the train when the user does not exist, scanning the QR code to board the train when the user information and payment channel are inconsistent, and deducting fees when the user's travel time exceeds the matching limit.

[0003] At the same time, each city generally deploys a user information database and a subway ticketing system. The process of generating entry and exit gate records generally includes user information, a QR code app, a scanning terminal, and a gate. The typical operation process is: the user provides a QR code app to register with the user information database, which then receives the boarding QR code. The scanning terminal analyzes the QR code structure, and the gate opens, thus generating an entry or exit gate record.

[0004] To test the subway ticketing system, such as Figure 1 As shown, the general testing method is: the tester registers with a mobile phone, obtains a QR code, and scans the terminal to interpret the QR code. The difference is: a gate simulator is used to generate entry and exit gate records based on the QR code interpretation results. This method has the following defects:

[0005] 1. The process is complicated, requiring a complex registration process and tedious code scanning every time.

[0006] 2. Unable to perform abnormal testing.

[0007] 3. Each test requires observation through the APP's transaction records, which requires complex operations on the APP, wasting time, and only the transaction records of one APP can be viewed.

[0008] 4. Since the QR code generation algorithms of the gates in the subway systems of different cities are different, the decoding terminals and corresponding gate simulators need to be replaced in a coordinated manner. When testing the subway ticketing systems of different cities, it is necessary to construct the corresponding scanner terminals and gate simulators at a high cost. Summary of the Invention

[0009] The purpose of the present invention is to provide a multi-city electronic ticket transaction testing tool. The device utilizes existing user information data, human-computer interaction modification technology, message organization technology, and log recording technology to form a set of testing tools with high freedom, pure software simulation, and separate execution of the configuration process and the test comparison process. It can achieve the purpose of batch testing in different cities, simple operation, and low-cost testing.

[0010] Multi-city electronic ticket transaction testing tool, including:

[0011] Memory;

[0012] one or more processors; and

[0013] One or more modules, stored in the memory and configured to be executed by the one or more processors, the one or more modules comprising:

[0014] Request module: used to obtain the connection request and query request entered by the tester, the connection request including: target database, the query request including: registered user phone number; used to send the connection request to the interface module, used to send the query request to the registered user information database that has responded to the connection request through the interface module; used to obtain the user information corresponding to the registered user phone number that responded to the query request through the interface module;

[0015] Interface module: used to send connection requests to the registered user information database corresponding to the target database and the subway ticketing system to be tested;

[0016] User information confirmation module: used to obtain user information from the request module and substitute the user information into the modification box; used to confirm the user information substituted into the modification box and obtain the confirmed user information;

[0017] Trip module: used to form entry or exit information,

[0018] Gate-pass message assembly module: used to assemble "confirmed user information" and "entry information" into a user entry gate message or assemble "confirmed user information" and "exit information" into a user exit gate message; used to send the user entry gate message or the user exit gate message to the subway ticketing system under test that responds to the connection request through the interface module;

[0019] Interface recording module: used to monitor the process of the interface module sending user entry and exit gate messages and generate interface log records for test tools;

[0020] Itinerary query module: used to send a itinerary query request to the subway ticketing system under test that responds to the connection request through the interface module. The itinerary query request includes the registered user's phone number; and is used to obtain the user's itinerary transaction information on the subway ticketing system under test that responds to the itinerary query request.

[0021] The design principle of the present invention is that the tester can compare and view the user travel transaction information and interface log records obtained by the test tool to obtain the test conclusion.

[0022] Among them, since the present invention uses an interface recording module to record the interface sending process, the gate passing information on the test tool side is formed, and the user travel transaction information on the subway ticketing system side to be tested is obtained, so comparative analysis can be performed.

[0023] The testing method described in the background of this invention typically involves testers observing user travel transaction records obtained by the app from the subway ticketing system under test. This results in limited observation of single data points, lacking test record data and the inability to generate test records, potentially leading to inaccurate testing. This invention, however, utilizes an interface logging module to generate interface logs, addressing the limitations of traditional testing methods.

[0024] In this invention, the tester can enter the target database as a connection request and the registered user's phone number as a query request to obtain user information. It should be noted that the traditional method involves registering with a QR code app, generating a QR code, and then parsing to obtain user information. This user information includes: user ID, payment account, payment method, and code issuance platform. This information is required for settlement in the subway ticketing system under test. The traditional QR code app and scanner function to parse and obtain user ID, payment account, payment method, and code issuance platform. To avoid this complex operation, the present invention directly copies a formal database of registered user information as the registered user information database. Traditional QR codes are also encoded based on the generated user ID, payment account, payment method, and code issuance platform in the registered user information database. However, the present invention directly obtains this information by directly associating it with the registered user's phone number during registration, replacing the traditional QR code app and scanner. This information is then fed into the user information determination module, which can modify or not modify this information, achieving greater testing flexibility and ultimately obtaining confirmed user information. Therefore, compared with the traditional method, the present invention can use the test tool to operate on the user information, while the traditional method is a QR code generated by the system, which cannot be intervened or requires more complicated intervention operations.

[0025] The present invention also provides a trip module for configuring entry or exit information. It is important to emphasize that each gate-passing message in this invention can only be a combination of entry or exit information and confirmed user information. This is intended to maintain gate-passing behavior as much as possible. When entry or exit information is determined, a simulated gate-passing action is triggered simultaneously. Therefore, each gate-passing message can only have entry or exit attributes. Furthermore, because the trip module is a configuration item module, it allows for a higher degree of freedom in trip configuration, such as the configuration of specific times and stops.

[0026] Among them, the function of the gate-passing message assembly module is to combine the entry information or exit information with the determined user information and generate a gate-passing message in a way that triggers the gate-passing action. Its purpose is to enable the interface that sends the message to record and monitor the message, so as to obtain the interface log record.

[0027] The subway ticketing system under test performs travel transaction settlement calculations upon receiving a gate pass message, generating travel transaction information. The present invention also includes a travel query module that matches the user's travel transaction information to the subway ticketing system under test based on the phone number. This allows the tool to obtain travel transaction information without requiring a separate access to the subway ticketing system under test. In this mode, both interface log records and user travel transaction information can be simultaneously accessed for comparative observation and rapid analysis.

[0028] It is particularly emphasized that: under the present invention, the tester can first enter the phone number multiple times to obtain user information multiple times, and enter the entry information or exit information multiple times to obtain multiple trip information. The subway ticketing system to be tested will generate multiple user trip transaction information in sequence, and the interface log record will record each process in sequence; the user can conveniently compare the data content of the two in sequence; and the operation can be performed multiple times in a concentrated manner, and the comparison can be performed once in a concentrated manner.

[0029] At the same time, the present invention realizes the connection between the tool and the registered user information database and the subway ticketing system to be tested through the provided target database, providing support for subsequent data interaction without the need for additional connection actions.

[0030] Preferably, the confirmed user information is the first user information or the second user information;

[0031] The first user information is: the user information in the modification box that is retained without modification;

[0032] The second user information is: user information generated after performing a modification operation on the user information in the modification box.

[0033] Preferably, the modification operation includes at least one of replacement and default.

[0034] Preferably, the user information includes: user ID, payment account, payment method, and code issuing platform.

[0035] Preferably, the user information entered into the modification box includes: the user ID corresponding to the registered user's phone number, the payment account, the payment method, and the code issuing platform;

[0036] When testing the QR code scan without a payment channel, perform a default operation on the payment account in the modification box to obtain the second user information, which includes: user ID, payment method, and code issuing platform;

[0037] When testing the situation where no user exists to scan the QR code for a ride, perform a default operation on the user ID in the modification box to obtain the second user information, which includes: user ID, payment method, and code issuing platform;

[0038] When conducting a QR code scan test where the user information and payment channel are inconsistent, replace the user ID or payment channel in the modification box to obtain the second user information. The second user information includes: "replaced user ID, payment account, payment method, code issuing platform" or "user ID, replaced payment account, payment method, code issuing platform".

[0039] Preferably, the registered user information database corresponding to the target database and the subway ticketing system to be tested belong to the same system in the same city.

[0040] Preferably, the registered user information database is a copy library of the running user information database, the subway ticketing system to be tested contains the ticketing logic to be tested, and the user travel transaction information is: the response result of the ticketing transaction logic operation of the subway ticketing system to be tested on the user's entry and exit gate messages according to the ticketing logic to be tested.

[0041] Preferably, the itinerary module includes: a itinerary selection module and a itinerary determination module.

[0042] Itinerary selection module: used to enter the station and scan the time;

[0043] Trip confirmation module: after selecting the entry confirmation button, the typed station will be determined as the entry station, the typed scanning time will be determined as the entry scanning time, and an entry order number will be randomly generated. The determined entry station, entry scanning time, and entry order number constitute the entry information; after selecting the exit confirmation button, the typed station will be determined as the exit station, the typed scanning time will be determined as the exit scanning time, and an exit order number will be randomly generated. The determined exit station, exit scanning time, and exit order number constitute the exit information.

[0044] Preferably, the scan code time entered is the default system time or the custom timeout time entered when performing a user timeout trip matching and fee deduction scan code ride test.

[0045] Preferably, the user entry and gate information includes: user ID, payment account, payment method, code issuing platform, entry station, entry code scanning time, entry order number, and entry gate device ID;

[0046] The user exit gate message includes: user ID, payment account, payment method, code issuing platform, exit station, exit code scanning time, exit order number, exit gate device ID;

[0047] The user's travel transaction information includes: entry station, entry time, entry order number, exit station, exit time, exit order number, mileage fee, deduction amount, payment account number, and transaction status;

[0048] The interface log record includes: gate passing information and gate passing results, and the gate passing information includes a user entry gate passing message or a user exit gate passing message in the form of a message body.

[0049] The beneficial effects of the present invention are: the device utilizes existing user information data, human-computer interaction modification technology, message organization technology, and log recording technology to form a set of test bases with high freedom, pure software simulation, and separate execution of the configuration process and the test comparison process, which can achieve the purpose of testing in different cities, batch testing, simple operation, and low-cost testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 A schematic diagram of the structural deployment of existing testing methods.

[0051] Figure 2 It is a schematic diagram of the structural deployment of the present invention.

[0052] Figure 3 The data flow diagram of the test tool.

[0053] Figure 4 Schematic diagram of the human-computer interaction interface of the testing tool.

[0054] Figure 5 This is a schematic diagram of obtaining user information after information query.

[0055] Figure 6 This is a diagram of the content recorded in the interface log.

[0056] Figure 7 A diagram showing the simultaneous display of interface log records and user travel transaction information. DETAILED DESCRIPTION

[0057] The present invention will be further described in detail below with reference to the embodiments and the accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0058] Example 1

[0059] See attached Figure 2-Figure 7 , multi-city electronic ticket transaction testing tool, including,

[0060] Memory;

[0061] one or more processors; and

[0062] One or more modules, stored in the memory and configured to be executed by the one or more processors, the one or more modules comprising:

[0063] Request module: used to obtain the connection request and query request entered by the tester, the connection request including: target database, the query request including: registered user phone number; used to send the connection request to the interface module, used to send the query request to the registered user information database that has responded to the connection request through the interface module; used to obtain the user information corresponding to the registered user phone number that responded to the query request through the interface module;

[0064] Interface module: used to send connection requests to the registered user information database corresponding to the target database and the subway ticketing system to be tested;

[0065] User information confirmation module: used to obtain user information from the request module and substitute the user information into the modification box; used to confirm the user information substituted into the modification box and obtain the confirmed user information;

[0066] Trip module: used to form entry or exit information,

[0067] Gate-pass message assembly module: used to assemble "confirmed user information" and "entry information" into a user entry gate message or assemble "confirmed user information" and "exit information" into a user exit gate message; used to send the user entry gate message or the user exit gate message to the subway ticketing system under test that responds to the connection request through the interface module;

[0068] Interface recording module: used to monitor the process of the interface module sending user entry and exit gate messages and generate interface log records;

[0069] Itinerary query module: used to send a itinerary query request to the subway ticketing system under test that responds to the connection request through the interface module. The itinerary query request includes the registered user's phone number; and is used to obtain the user's itinerary transaction information that responds to the itinerary query request.

[0070] The design principle of the present invention is that the tester can compare and view the user travel transaction information and interface log records obtained by the test tool to obtain the test conclusion.

[0071] In this invention, the tester can enter the target database as a connection request and the registered user's phone number as a query request to obtain user information. It should be noted that the traditional method involves registering with a QR code app, generating a QR code, and then parsing to obtain user information. This user information includes: user ID, payment account, payment method, and code issuance platform. This information is required for settlement in the subway ticketing system under test. The traditional QR code app and scanner function to parse and obtain user ID, payment account, payment method, and code issuance platform. To avoid this complex operation, the present invention directly copies a formal database of registered user information as the registered user information database. Traditional QR codes are also encoded based on the generated user ID, payment account, payment method, and code issuance platform in the registered user information database. However, the present invention directly obtains this information by directly associating it with the registered user's phone number during registration, replacing the traditional QR code app and scanner. This information is then fed into the user information determination module, which can modify or not modify this information, achieving greater testing flexibility and ultimately obtaining confirmed user information. Therefore, compared with the traditional method, the present invention can use the test tool to operate on the user information, while the traditional method is a QR code generated by the system, which cannot be intervened or requires more complicated intervention operations.

[0072] The present invention also provides a trip module for configuring entry or exit information. It is important to emphasize that each gate-passing message in this invention can only be a combination of entry or exit information and confirmed user information. This is intended to maintain gate-passing behavior as much as possible. When entry or exit information is determined, a simulated gate-passing action is triggered simultaneously. Therefore, each gate-passing message can only have entry or exit attributes. Furthermore, because the trip module is a configuration item module, it allows for a higher degree of freedom in trip configuration, such as the configuration of specific times and stops.

[0073] Among them, the function of the gate-passing message assembly module is to combine the entry information or exit information with the determined user information and generate a gate-passing message in a way that triggers the gate-passing action. Its purpose is to enable the interface that sends the message to record and monitor the message, so as to obtain the interface log record.

[0074] The subway ticketing system under test performs travel transaction settlement calculations upon receiving a gate pass message, generating travel transaction information. The present invention also includes a travel query module that matches the user's travel transaction information to the subway ticketing system under test based on the phone number. This allows the tool to obtain travel transaction information without requiring a separate access to the subway ticketing system under test. In this mode, both interface log records and user travel transaction information can be simultaneously accessed for comparative observation and rapid analysis.

[0075] It is particularly emphasized that: under the present invention, the tester can first enter the phone number multiple times to obtain user information multiple times, and enter the entry information or exit information multiple times to obtain multiple trip information. The subway ticketing system to be tested will generate multiple user trip transaction information in sequence, and the interface log record will record each process in sequence; the user can conveniently compare the data content of the two in sequence; and the operation can be performed multiple times in a concentrated manner, and the comparison can be performed once in a concentrated manner.

[0076] At the same time, the present invention realizes the connection between the tool and the registered user information database and the subway ticketing system to be tested through the provided target database, providing support for subsequent data interaction without the need for additional connection actions.

[0077] Preferably, the confirmed user information is the first user information or the second user information;

[0078] The first user information is: the user information in the modification box that is retained without modification;

[0079] The second user information is: user information generated after performing a modification operation on the user information in the modification box.

[0080] Preferably, the modification operation includes at least one of replacement and default.

[0081] Preferably, the user information includes: user ID, payment account, payment method, and code issuing platform.

[0082] Preferably, the user information entered into the modification box includes: the user ID corresponding to the registered user's phone number, the payment account, the payment method, and the code issuing platform;

[0083] When testing the QR code scan without a payment channel, perform a default operation on the payment account in the modification box to obtain the second user information, which includes: user ID, payment method, and code issuing platform;

[0084] When testing the situation where no user exists to scan the QR code for a ride, perform a default operation on the user ID in the modification box to obtain the second user information, which includes: user ID, payment method, and code issuing platform;

[0085] When conducting a QR code scan test where the user information and payment channel are inconsistent, replace the user ID or payment channel in the modification box to obtain the second user information. The second user information includes: "replaced user ID, payment account, payment method, code issuing platform" or "user ID, replaced payment account, payment method, code issuing platform".

[0086] Preferably, the registered user information database corresponding to the target database and the subway ticketing system to be tested belong to the same system in the same city.

[0087] Preferably, the registered user information database is a copy library of the running user information database, the subway ticketing system to be tested contains the ticketing logic to be tested, and the user travel transaction information is: the response result of the ticketing transaction logic operation of the subway ticketing system to be tested on the user's entry and exit gate messages according to the ticketing logic to be tested.

[0088] Preferably, the itinerary module includes: a itinerary selection module and a itinerary determination module.

[0089] Itinerary selection module: used to enter the station and scan the time;

[0090] Trip confirmation module: after selecting the entry confirmation button, the typed station will be determined as the entry station, the typed scanning time will be determined as the entry scanning time, and an entry order number will be randomly generated. The determined entry station, entry scanning time, and entry order number constitute the entry information; after selecting the exit confirmation button, the typed station will be determined as the exit station, the typed scanning time will be determined as the exit scanning time, and an exit order number will be randomly generated. The determined exit station, exit scanning time, and exit order number constitute the exit information.

[0091] Preferably, the scan code time entered is the default system time or the custom timeout time entered when performing a user timeout trip matching and fee deduction scan code ride test.

[0092] Preferably, the user entry and gate information includes: user ID, payment account, payment method, code issuing platform, entry station, entry code scanning time, and entry order number;

[0093] The user exit gate message includes: user ID, payment account, payment method, code issuing platform, exit station, exit code scanning time, and exit order number;

[0094] The user's travel transaction information includes: entry station, entry time, entry order number, exit station, exit time, exit order number, mileage fee, deduction amount, payment account number, and transaction status;

[0095] The interface log record includes: gate passing information and gate passing results, and the gate passing information includes a user entry gate passing message or a user exit gate passing message in the form of a message body.

[0096] See attached Figure 4 The information query button is an operation performed after the tester enters the mobile phone number and selects the city. The mobile phone number corresponds to the query request for querying user information, and selecting a city means selecting a target database and generating a corresponding connection request.

[0097] Among them, user information is brought into the modification boxes of user ID, payment account, payment method, and code issuance platform, and all this information can be modified.

[0098] Among them, the modification boxes such as site selection and scan time correspond to site input and scan time input, which represent the itinerary selection module.

[0099] Among them, the entry button and exit button correspond to the trip determination module. After the button is triggered, the trip determination module, the gate message assembly module, and the interface recording module are all activated, thereby generating a gate message and an interface log record.

[0100] Therefore, for testers, during normal testing, they only need to enter the phone number and select the city, then enter the station, scan the code time, and click the entry or exit button. The operation is very simple. At the same time, when clicking the entry or exit button, the interface log can be directly displayed, and the content sent by the interface can be directly and dynamically displayed. At the same time, for testers, they can click the itinerary query button to trigger the itinerary query module and obtain the user's itinerary transaction information, which can also be dynamically displayed on the tool side.

[0101] The interface log records a message body style content, which can be continuously recorded and dynamically refreshed, and is very beneficial to the test observation of the present invention.

[0102] The present invention can be summarized into six major actions: user data call, travel data input, gate pass message triggering, gate pass message recording, travel transaction data call, and data comparison. However, for the tester of the present invention, there are no complicated operations, and data switching between different cities can be achieved. There is no hardware support, and the hardware cost is low. The comparison can synchronously and dynamically display two sets of data. User data can be modified, especially single-item modification operations on a certain basis. It does not require custom input for all items, reducing the input workload. That is, during abnormal testing, the basic user information is selected, and then individual items are modified based on the user information, avoiding the complex operation of multiple inputs by the tester.

[0103] The independent simulation of inbound or outbound communication of the present invention is more in line with the independence of inbound and outbound messages, so as to realize operation test of the system under test.

[0104] The multi-city electronic ticket transaction testing tool of the present invention integrates the APP, terminal scanning, and gate simulation program into one. It can directly query user information from the database through the user's mobile phone information, or manually fill in the user information and then send the itinerary with one click. Finally, the local sent data and the itinerary data in the database are compared and verified. At the same time, more abnormal scenarios can be tested.

[0105] It will be understood that the above embodiments are merely exemplary embodiments for illustrating the principles of the present invention, and the present invention is not limited thereto. Persons skilled in the art will readily appreciate that various modifications and improvements can be made without departing from the spirit and substance of the present invention, and such modifications and improvements are considered within the scope of protection of the present invention.

Claims

1. Multi-city electronic ticket transaction testing tool, characterized by: include, Memory; one or more processors; and One or more modules, stored in the memory and configured to be executed by the one or more processors, the one or more modules comprising: Request module: used to obtain the connection request and query request entered by the tester, the connection request including: target database, the query request including: registered user phone number; used to send the connection request to the interface module, used to send the query request to the registered user information database that has responded to the connection request through the interface module; used to obtain the user information corresponding to the registered user phone number that responded to the query request through the interface module; Interface module: used to send connection requests to the registered user information database corresponding to the target database and the subway ticketing system to be tested; User information confirmation module: used to obtain user information from the request module and substitute the user information into the modification box; used to confirm the user information substituted into the modification box and obtain the confirmed user information; Trip module: used to compose entry information or exit information; Gate-pass message assembly module: used to assemble "confirmed user information" and "entry information" into a user entry gate-pass message, or assemble "confirmed user information" and "exit information" into a user exit gate-pass message; used to send the user entry gate-pass message or the user exit gate-pass message to the subway ticketing system under test that responds to the connection request through the interface module; Interface recording module: used to monitor the process of the interface module sending user entry and exit gate messages and generate interface log records on the test tool side; Itinerary query module: used to send a itinerary query request to the subway ticketing system under test that responds to the connection request through the interface module. The itinerary query request includes the registered user's phone number; and is used to obtain the user's itinerary transaction information on the subway ticketing system under test that responds to the itinerary query request.

2. The multi-city electronic ticket transaction testing tool according to claim 1, characterized in that: The confirmed user information is the first user information or the second user information; The first user information is: the user information in the modification box that is retained without modification; The second user information is: user information generated after performing a modification operation on the user information in the modification box.

3. The multi-city electronic ticket transaction testing tool according to claim 2, characterized in that: The modification operation includes at least one of replacement and default.

4. The multi-city electronic ticket transaction testing tool according to claim 2, characterized in that: The user information includes: user ID, payment account, payment method, and code issuance platform.

5. The multi-city electronic ticket transaction testing tool according to claim 2, characterized in that: The user information entered into the edit box includes: the user ID corresponding to the registered user's phone number, payment account, payment method, and code issuance platform; When testing the QR code scan without a payment channel, perform a default operation on the payment account in the modification box to obtain the second user information, which includes: user ID, payment method, and code issuing platform; When testing the situation where no user exists to scan the QR code for a ride, perform a default operation on the user ID in the modification box to obtain the second user information, which includes: user ID, payment method, and code issuing platform; When conducting a QR code scan test with inconsistent user information and payment channels, replace the user ID or payment channel in the modification box to obtain the second user information. The second user information includes: "replaced user ID, payment account, payment method, code issuing platform" or "user ID, replaced payment account, payment method, code issuing platform".

6. The multi-city electronic ticket transaction testing tool according to any one of claims 1 to 5, characterized in that: The registered user information database corresponding to the target database and the subway ticketing system to be tested belong to the same system in the same city.

7. The multi-city electronic ticket transaction testing tool according to any one of claims 1 to 5, characterized in that: The registered user information database is a copy of the running user information database. The subway ticketing system to be tested contains the ticketing logic to be tested. The user travel transaction information is: the response result of the ticketing transaction logic operation of the subway ticketing system to the user's entry and exit gate messages based on the ticketing logic to be tested.

8. The multi-city electronic ticket transaction testing tool according to any one of claims 1 to 5, characterized in that: The itinerary module includes: a itinerary selection module and a itinerary determination module. Itinerary selection module: used to enter the station and scan the time; Trip confirmation module: after selecting the entry confirmation button, the typed station will be determined as the entry station, the typed scanning time will be determined as the entry scanning time, and an entry order number will be randomly generated. The determined entry station, entry scanning time, and entry order number constitute the entry information; after selecting the exit confirmation button, the typed station will be determined as the exit station, the typed scanning time will be determined as the exit scanning time, and an exit order number will be randomly generated. The determined exit station, exit scanning time, and exit order number constitute the exit information.

9. The multi-city electronic ticket transaction testing tool according to claim 8, characterized in that: The scan code time entered is the default system time or the custom timeout time entered when performing a user timeout trip matching and fee deduction scan code ride test.

10. The multi-city electronic ticket transaction testing tool according to any one of claims 1 to 5, characterized in that: The user entry and gate information includes: user ID, payment account, payment method, code issuing platform, entry station, entry code scanning time, entry order number, and entry gate equipment ID; The user exit gate message includes: user ID, payment account, payment method, code issuing platform, exit station, exit code scanning time, exit order number, exit gate device ID; The user's travel transaction information includes: entry station, entry time, entry order number, exit station, exit time, exit order number, mileage fee, deduction amount, payment account number, and transaction status; The interface log record includes: gate passing information and gate passing results, and the gate passing information includes a user entry gate passing message or a user exit gate passing message in the form of a message body.

Images