Bus card business automation test method and system

Abstract

The application provides a bus card service automatic test method and system. In the method, a forwarding agent obtains a suspicious test scene requirement in a target test case sent by a test client; on a target SE device, a mobile client MC receives a first service test instruction and sends a first online service request corresponding to the first service test instruction to the forwarding agent according to the instruction; the forwarding agent controls the communication message transmission between the mobile client and a service server, and the service server stores a service suspicious state of the first online service test; the mobile client MC receives a second service test instruction sent by the test client and sends a corresponding second online service request to the service server according to the instruction; the service server re-determines the service suspicious state of the first online service test and obtains a service state determination result, and the test client obtains the service state determination result. The method can reduce the labor cost and improve the test efficiency.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to an automated testing method and system for public transport card services. Background Technology

[0002] Compared to offline outlets, "airborne" services such as mobile transportation card issuance, top-up, and ticket purchase offer greater flexibility, but they also bring new problems, one of which is "questionable business practices."

[0003] "Business Status in Doubt" is a specific term used by the "Business Server (BS)" to describe the unclear actual business status of a particular order, typically caused by poor network conditions. The BS relies on data from the "Mobile Client (MC)" to determine the business status. If the BS has completed all necessary steps for a business order but has not received any data from the MC, the order status is "Business Status in Doubt." Determining the "Business Status in Doubt" is a high-risk function because it usually involves fund transfers; incorrect determination could lead to financial losses for users or the business party. Therefore, the logic for determining the "Business Status in Doubt" requires frequent and thorough testing to ensure the function's integrity.

[0004] However, the existing automated testing methods for public transport card services are purely manual tests. Therefore, frequent and thorough testing of "questionable" states consumes a lot of manpower. In addition, the large number of business types to be tested results in a limited number of offline gates available for testing, making it difficult to achieve test coverage for all scenarios. Summary of the Invention

[0005] The purpose of this application is to provide an automated testing method and system for public transport card services, which solves the above-mentioned problems existing in the prior art, reduces labor costs, and can cover a variety of business testing scenarios.

[0006] Firstly, an automated testing method for public transport card services is provided, applicable to a system comprising a test client Appium, a forwarding proxy Proxy, a target SE device, and a service server BS. The target SE device includes an SE module and a mobile client MC. The method may include:

[0007] The proxy forwards the test case to obtain the questionable test scenario requirements from the target test cases sent by the test client Appium.

[0008] On the target SE device, the mobile client MC receives the first service test instruction for the target bus card sent by the test client Appium, and sends the first online service request corresponding to the first service test instruction to the forwarding proxy Proxy according to the instruction; the first online service request includes the target bus card number stored in the target SE device;

[0009] The forwarding proxy controls the transmission of communication messages between the mobile client MC and the business server BS based on the obtained questionable test scenario requirements and the first online business request, so that the business server BS stores the questionable status of the first online business test.

[0010] At this time, the target SE device stores the actual business execution records of the target bus card;

[0011] The mobile client MC receives the second service test instruction for the target bus card sent by the test client Appium, and sends the second online service request corresponding to the second service test instruction to the service server BS through the forwarding proxy according to the instruction; the second online service request includes the target bus card number;

[0012] If the business server (BS) detects that the target bus card number has a questionable business status, it obtains the business execution record in the target SE device; based on the business execution record of the target bus card, it re-determines the questionable business status of the first online business test, obtains the business status determination result, and sends the business status determination result to the test client Appium through the forwarding proxy, the mobile client MC, and the target SE device;

[0013] The Appium test client generates a test report based on the business status determination results.

[0014] In some optional implementations, the system also includes an offline POS machine simulation service, MockPos, which includes a backend service module MPB and a frontend service module MPF.

[0015] When test cases include offline business testing, the target SE device performs at least one offline business test of the target public transport card, including:

[0016] The test client Appium sends at least one offline business test instruction to the front-end service module MPF;

[0017] For any offline business test instruction, the front-end service module MPF obtains the target bus card number stored in the target SE device based on the offline business test instruction, and sends the target bus card number and the offline business test instruction to the back-end service module MPB;

[0018] The backend service module MPB obtains the transaction subkey of the target bus card stored in the forwarding proxy Proxy, and after receiving the offline business test instruction, it generates an offline business test instruction by combining the business test instruction, the target bus card number and the transaction subkey, and sends the instruction to the frontend service module MPF.

[0019] The front-end service module MPF sends offline business test instructions to the SE module in the target SE device to execute offline business tests, and sends the business response to the back-end service module MPB;

[0020] After the front-end service module MPF sends the business response to the back-end service module MPB, it receives the indication information that the test business has ended from the back-end service module MPB, and sends the offline business test completion information to the test client Appium.

[0021] Secondly, an automated testing system for public transport card services is provided. The system may include: a test client Appium, a forwarding proxy Proxy, a target SE device, and a business server BS. The target SE device includes an SE module and a mobile client MC.

[0022] The forwarding proxy is used to obtain questionable test scenario requirements from the target test cases sent by the test client Appium;

[0023] On the target SE device, the mobile client MC receives the first service test instruction for the target bus card sent by the test client Appium, and sends the first online service request corresponding to the first service test instruction to the forwarding proxy Proxy according to the instruction; the first online service request includes the target bus card number stored in the target SE device;

[0024] The forwarding proxy is also used to control the transmission of communication messages between the mobile client MC and the business server BS according to the obtained questionable test scenario requirements and the first online business request, so that the business server BS stores the questionable business status of the first online business test.

[0025] The target SE device is used to store the actual business execution records of the target public transport card.

[0026] The mobile client MC is used to receive the second service test instruction for the target bus card sent by the test client Appium, and send the second online service request corresponding to the second service test instruction to the service server BS through the forwarding proxy according to the instruction; the second online service request includes the target bus card number;

[0027] The business server (BS) is used to obtain the business execution record in the target SE device if the target bus card number is detected to have a questionable business status; based on the business execution record of the target bus card, the questionable business status of the first online business test is re-determined to obtain the business status determination result, and the business status determination result is sent to the test client Appium through the forwarding proxy (Proxy), the mobile client (MC), and the target SE device.

[0028] The Appium test client is used to generate test reports based on the results of business status assessments.

[0029] Thirdly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements any of the steps of the method described in the first aspect above.

[0030] In the automated testing method for public transport card services provided in this application embodiment, the forwarding proxy obtains the questionable test scenario requirements from the target test cases sent by the test client Appium; on the target SE device, the mobile client MC receives the first service test instruction for the target public transport card sent by the test client Appium, and sends the first online service request corresponding to the first service test instruction to the forwarding proxy according to the instruction; the first online service request includes the target public transport card number stored in the target SE device; the forwarding proxy controls the transmission of communication messages between the mobile client MC and the service server BS according to the obtained questionable test scenario requirements and the first online service request, so that the service server BS stores the questionable service status of the first online service test; at this time, the target SE device... The system stores the actual business execution records of the target bus card. The mobile client (MC) receives the second business test instruction for the target bus card from the test client (Appium) and, according to the instruction, sends the second online business request corresponding to the second business test instruction to the business server (BS) through the forwarding proxy (Proxy). If the business server (BS) detects a business doubt status for the target bus card number, it retrieves the business execution records from the target SE device. Based on the business execution records of the target bus card, it re-determines the business doubt status of the first online business test, obtains the business status determination result, and sends the business status determination result to the test client (Appium) through the forwarding proxy (Proxy), the mobile client (MC), and the target SE device. The test client (Appium) generates a test report based on the business status determination result. This method can improve testing efficiency and business type test coverage while reducing labor costs, thus better ensuring product quality. Attached Figure Description

[0031] 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. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 A system architecture diagram of an automated testing method for public transport card services provided in this application embodiment;

[0033] Figure 2 This is a flowchart illustrating an automated testing method for public transport card services provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0035] The automated testing method for public transport card services provided in this application embodiment can be applied to... Figure 1 The system described may include: a test case management service (TCMS), a test client (Appium), a forwarding proxy (Proxy), a mock POS, a target SE device, and a business server (BS). The target SE device may include an SE module and a mobile client (MC). An SE (Security Element) module is a security element integrated within a device (such as a mobile phone or wristband), i.e., an independent hardware module within the device; the target SE device is a "mobile device that integrates an SE module," i.e., a mobile phone, wristband, etc.

[0036] Test Case Management Service (TCMS): Deployed on the test server, its main function is to manage test cases.

[0037] The forwarding proxy, located between the mobile client (MC) and the business server (BS), can acquire communication packets between the two and extract valid information by parsing the packets. Additionally, the proxy can control the traffic between the mobile client (MC) and the business server (BS) according to test case requirements, thereby simulating test scenarios. This module functions similarly to Fiddler.

[0038] Mock Pos (hereinafter referred to as "MP"): Its main function is to simulate various offline transactions. It includes a front-end service module (hereinafter referred to as "MPF") and a back-end service module MPB. "MPF" is responsible for communicating with the mobile device security module SE, and "MPB" is responsible for simulating various offline devices.

[0039] The Appium test client is primarily responsible for parsing and executing test cases.

[0040] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0041] Figure 2 This is a flowchart illustrating an automated testing method for public transport card services provided in an embodiment of this application. Figure 2 As shown, the method may include:

[0042] Step S210: The forwarding proxy obtains the questionable test scenario requirements in the target test case sent by the test client Appium.

[0043] Specifically, the test client Appium sends test scenario requirements to the forwarding proxy Proxy;

[0044] The forwarding proxy parses the requirements of the test scenario;

[0045] If the test scenario requirement is determined to be a questionable test scenario requirement, then the forwarding proxy obtains the questionable test scenario requirement;

[0046] If the test scenario requirement is parsed as a normal test scenario requirement, then the forwarding proxy obtains the normal test scenario requirement.

[0047] Step S220: On the target SE device, the mobile client MC receives the first service test instruction of the target bus card sent by the test client Appium, and sends the first online service request corresponding to the first service test instruction to the forwarding proxy Proxy according to the instruction.

[0048] The first online service request may include the target public transport card number stored in the target SE device. The first online service test may include online card activation test and online recharge test.

[0049] Step S230: The forwarding proxy controls the transmission of communication messages between the mobile client MC and the business server BS based on the obtained questionable test scenario requirements and the first online business request, so that the business server BS stores the questionable status of the first online business test.

[0050] During the test preparation phase, the card transaction key is extracted. The forwarding proxy forwards the communication messages that establish a communication connection between the mobile client MC and the business server BS, and parses the communication messages to obtain the transaction sub-key. Subsequently, based on the transaction sub-key, the forwarding proxy can parse the communication messages between the mobile client MC and the business server BS.

[0051] It should be noted that the keys (including transaction sub-keys) required for different public transport card services are all obtained during the public transport card activation process. The extraction of transaction keys actually occurs before the start of the test, that is, during the test preparation phase. For virtual card recharge transactions, successful virtual card activation is a necessary prerequisite. In reality, the card's transaction sub-key is written into the card during the virtual card activation process. Therefore, as long as we can intercept the communication messages between "BS" and "MC" during the activation process and successfully parse the messages, we can extract the transaction sub-key for this virtual card.

[0052] In practice, if the questionable test scenario requires a network interruption during the business request process, the forwarding proxy will refuse to send the first online business request to the business server (BS) based on the obtained questionable test scenario requirements, so that the business server (BS) stores the questionable status of the first online business test.

[0053] If the questionable test scenario requires a network interruption during the business response process, the forwarding proxy will send the first online business request to the business server (BS) based on the obtained questionable test scenario requirements, and after receiving the first online business response from the business server (BS), will refuse to send the first online business response to the mobile client (MC).

[0054] Alternatively, if the questionable test scenario requires instruction tampering during the business request process, the forwarding proxy will illegally tamper with the first online business request sent to the business server (BS) based on the obtained questionable test scenario requirements. When the business server (BS) detects that the request content in the tampered first online business request is illegal, it will determine the business status of the first online business test as a questionable business status.

[0055] If the questionable test scenario requires instruction tampering during the business response process, the forwarding proxy sends the first online business request to the business server (BS) based on the obtained questionable test scenario requirements, and illegally tampers with the first online business response received from the business server (BS); then sends the tampered first online business response to the mobile client (MC).

[0056] The mobile client MC and the target SE device jointly detect the tampered first online service response. When it detects that the response content in the tampered first online service request is invalid, it rejects the response result of the service server BS and there are no subsequent requests. At this time, the first online service is in a suspicious state on the service server BS side.

[0057] Over-the-air services are completed through network communication between the service server (BS) and the mobile client (MC). A single service may involve several to a dozen network communications. "Questionable recharge" occurs when, during the transaction, the last network communication between the service server (BS) and the mobile terminal (target SE device and mobile client MC) fails. At this point, the service server (BS) has already issued the recharge command ("recharge command issuance response"). Once this command is executed by the target SE device, the recharge process is complete. Normally, after the service server (BS) issues the recharge command, the mobile client (MC) receives the command and successfully executes it on the target SE device, then sends a request message to the service server (BS) informing it that the recharge was successful ("recharge success confirmation request"). However, in abnormal situations, the service server (BS) does not receive the "recharge success confirmation request" from the mobile client (MC). In this case, the service server (BS) can only consider this situation as "questionable recharge." A proxy can easily construct such scenarios, leveraging its positional advantage on the network to construct the following scenarios:

[0058] (1) Mobile recharge successful, but the recharge on the business server (BS) is questionable:

[0059] a) The proxy intercepts the mobile client's "recharge success confirmation request," simulating a real-world scenario where a network error occurs when sending the "recharge success confirmation request." In this case, the mobile client's MC has successfully recharged and sent the request to the business server (BS), but the request fails to reach the BS, causing the BS's transaction status to be "questionable." The proxy prevents this request from reaching the BS by intercepting the mobile client's MC request.

[0060] b) The proxy tampers with the mobile client's (MC) "recharge success confirmation request," simulating a scenario where the "recharge success confirmation request" is invalid in a real-world environment. In this case, the mobile client's MC has successfully recharged and sent the request to the business server (BS). However, the content of this request is invalid and fails the BS's verification, causing the BS to disapprove of the request's legitimacy and thus resulting in the BS's transaction status being "questionable." The proxy simulates this scenario by tampering with the mobile client's MC's "recharge success confirmation request," causing the BS to receive an invalid request. This type of scenario exists in reality, but its frequency is lower than in (a).

[0061] (2) Mobile client MC recharge failed, and the business server BS recharge is questionable:

[0062] a) The proxy intercepts the "recharge command response" from the business server (BS), simulating a real-world scenario where the "recharge command response" fails to reach the mobile client (MC) due to network issues. In this case, the business server (BS) has already sent the recharge command, but the mobile client (MC) has not received a response from the business server (BS), meaning it hasn't received the recharge command and therefore cannot execute, resulting in a failed recharge. The proxy prevents the recharge command from reaching the mobile client (MC) by intercepting the business server (BS) response.

[0063] b) The proxy tampers with the "recharge command response" on the business server (BS), simulating a scenario where the "recharge command response" is invalid in a real-world environment. In this case, the BS has already sent the recharge command, but the command itself is invalid, causing the mobile verification to fail, thus rejecting the transaction and the recharge actually failing.

[0064] Step S240: The target SE device stores the actual business execution record of the target bus card. The mobile client MC receives the second business test instruction of the target bus card sent by the test client Appium, and sends the second online business request corresponding to the second business test instruction to the business server BS through the forwarding proxy Proxy according to the instruction.

[0065] The second online service request may include the target bus card number; the second online service request includes online recharge service testing and query service testing.

[0066] In some embodiments, prior to the second online service request, when the test case includes offline service testing, the target SE device performs at least one offline service test based on the acquired transaction subkey and the target transit card, which may include:

[0067] The test client Appium sends at least one offline business test instruction to the front-end service module MPF;

[0068] For any offline business test instruction, the front-end service module MPF obtains the target bus card number stored in the target SE device based on the offline business test instruction, and sends the target bus card number and the offline business test instruction to the back-end service module MPB;

[0069] The backend service module MPB obtains the transaction subkey of the target bus card stored in the forwarding proxy Proxy, and after receiving the offline business test instruction corresponding to the offline business test instruction, sends the offline business test instruction to the frontend service module MPF;

[0070] The front-end service module MPF sends offline business test instructions to the SE module in the target SE device to execute offline business tests, and sends the business response to the back-end service module MPB;

[0071] After the front-end service module MPF sends the business response to the back-end service module MPB, it receives the indication information that the test business has ended from the back-end service module MPB, and sends the offline business test completion information to the test client Appium.

[0072] Step S250: If the business server (BS) detects that the target bus card number has a questionable business status, it obtains the business execution record in the target SE device and re-determines the questionable business status of the first online business test based on the business execution record of the target bus card to obtain the business status determination result.

[0073] In practice, if the first online business test is a recharge business test, the business server (BS) can determine whether the first online business test corresponding to the business doubt status is successful based on the time of the business doubt status determination and the consumption amount corresponding to the time of the business execution record. If a transaction record matching the transaction time, transaction amount and transaction acceptor is found in the business execution record of the target SE device, then the test status of the first online business test is determined to be successful.

[0074] Step S260: The business server (BS) sends the business status determination result to the test client (Appium) through the forwarding proxy (Proxy), the mobile client (MC), and the target SE device.

[0075] The business execution records may include the operation records of the target bus card and their corresponding operation times, such as recharge operations, card opening operations, query operations and their corresponding operation times, as well as transaction records and their corresponding operation times, such as online transactions of the target bus card (mobile device transactions, such as using an app to recharge the bus card), offline transactions (such as swiping the bus card, swiping the subway card, recharging at bus stops, etc.) and their corresponding operation times.

[0076] Step S270: The test client Appium generates a test report based on the business status determination result.

[0077] In the automated testing method for public transport card services provided in this application embodiment, the forwarding proxy obtains the questionable test scenario requirements in the target test case sent by the test client Appium; the target SE device receives the first service test instruction for the target public transport card sent by the test client Appium, and sends the first online service request corresponding to the first service test instruction to the forwarding proxy according to the instruction; the first online service request includes the target public transport card number stored in the target SE device; the forwarding proxy controls the transmission of communication messages between the mobile client MC and the service server BS according to the obtained questionable test scenario requirements and the first online service request, so that the service server BS stores the questionable service status of the first online service test;

[0078] The target SE device receives a second service test instruction for the target bus card sent by the test client Appium, and sends the second online service request corresponding to the second service test instruction to the service server BS through the forwarding proxy. If the service server BS detects a service doubt status for the target bus card number, it obtains the service execution record from the target SE device. Based on the service execution record of the target bus card, it re-determines the service doubt status of the first online service test, obtains the service status determination result, and sends the service status determination result to the test client Appium through the forwarding proxy, the mobile client MC, and the target SE device. The test client Appium generates a test report based on the service status determination result. This method can improve testing efficiency and service type test coverage while reducing labor costs, thus better ensuring product quality.

[0079] Regarding the functionality of proxy:

[0080] Regarding the question of how to parse the card activation message, the normal card activation process consists of the following steps:

[0081] (1) The service server (BS) sends a command to the target security device (SE) to select the corresponding card security domain, and the target SE responds normally. Each security domain has a corresponding key, and the service server (BS) and the target SE are consistent.

[0082] (2) The service server (BS) and the target SE device perform bidirectional authentication using the security domain key from step (1), and the handshake is successful. At this time, the service server (BS) and the target SE device jointly possess a random key, which is used for subsequent message encryption and decryption. The generation of the random key incorporates random numbers from both the service server (BS) and the target SE device, and the random numbers are transmitted in plaintext.

[0083] (3) The business server (BS) issues a card writing command. When all card writing commands are executed, the card production process ends. All card writing commands are encrypted using the random key from step (2). Therefore, the target SE device decrypts the card writing command using the random key to obtain the plaintext card writing command and executes it. The card writing command covers all information on the target SE device, including the card number, card validity period, and of course, various transaction keys.

[0084] Obtaining the card transaction key is one of the functions of the Proxy. As a node between the "BS" and "MC" on the network, it can easily obtain all messages in the card opening process. However, as mentioned above, the messages are encrypted. To obtain the card-related key, it is necessary to obtain the random key in step (2). The acquisition of the random key requires two conditions to be met simultaneously: first, the security domain key in step 1; and second, the random key generation algorithm in step (2).

[0085] In the test environment, the first condition is met because the security domain key is actually public for development, debugging, and testing purposes. Regarding the second condition, the random key algorithm can almost be considered public as well, since most transit card companies (the issuers of public transport cards) choose the algorithm described in the "specification" as their random key generation algorithm. Furthermore, even if the transit card company uses a custom algorithm, its direct partners—the developers who directly interface with the company as the server-side—must know the random key generation algorithm. Therefore, the second condition is also met. Thus, the transit card company's direct partners can decrypt the card activation message within the proxy and further obtain various card transaction keys. After obtaining the card transaction keys, they can assemble the corresponding transaction messages and cards according to the "transaction specification" (the publicly available instruction assembly rules and algorithms) to conduct transactions. In other words, they possess the ability to simulate various offline terminals and cards for transactions.

[0086] The key can be easily obtained by capturing packets, which may seem to pose a security risk, but in actual use the risk is controllable:

[0087] 1. High cost of packet interception in production environment: Because the production environment uses the HTTPS protocol and the app is configured to enable packet interception, the cost of packet interception in the production environment is very high. In contrast, the test environment uses the HTTP protocol, and setting up a proxy is not difficult.

[0088] 2. Difficulty in message parsing: The card activation messages in the test environment can be parsed because the protection key used during the activation process is relatively public and only set up for project debugging and testing. The situation in the production environment is completely different. Production environment keys are stored in a hardware encryption machine, making them extremely difficult to obtain. Furthermore, production environment card activation messages are encrypted using the production environment key. Without the production environment key, the messages cannot be decrypted, let alone further parsed. Therefore, parsing card data in the production environment is very difficult.

[0089] 3. Controllable Risk: Even if an attacker successfully intercepts and parses the message, the number of cards affected is extremely limited. Because each card has a unique key, the breach of one or a few cards will not significantly impact overall security.

[0090] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the automated testing methods for public transport card services described in the above embodiments.

[0091] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the automated testing methods for public transport card services described in the above embodiments.

[0092] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1A device that provides the functions specified in one or more boxes.

[0094] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0095] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0096] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

[0097] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims in this application and their equivalents, then this application also intends to include these modifications and variations.

Claims

1. An automated testing method for public transport card services, characterized in that, Applied to a system comprising a test client Appium, a forwarding proxy Proxy, a target SE device, and a service server BS, wherein the target SE device includes an SE module and a mobile client MC, the method includes: The proxy forwards the test case to obtain the questionable test scenario requirements from the target test cases sent by the test client Appium. On the target SE device, the mobile client MC receives the first service test instruction for the target bus card sent by the test client Appium, and sends the first online service request corresponding to the first service test instruction to the forwarding proxy Proxy according to the instruction; the first online service request includes the target bus card number stored in the target SE device; The forwarding proxy controls the transmission of communication messages between the mobile client MC and the business server BS based on the obtained questionable test scenario requirements and the first online business request, so that the business server BS stores the questionable status of the first online business test corresponding to the first online business request. At this time, the target SE device stores the actual business execution records of the target bus card; The mobile client MC receives the second service test instruction for the target bus card sent by the test client Appium, and sends the second online service request corresponding to the second service test instruction to the service server BS through the forwarding proxy according to the instruction; the second online service request includes the target bus card number; If the business server (BS) detects that the target bus card number has a questionable business status, it obtains the business execution record in the target SE device; based on the business execution record of the target bus card, it re-determines the questionable business status of the first online business test, obtains the business status determination result, and sends the business status determination result to the test client Appium through the forwarding proxy, the mobile client MC, and the target SE device; The Appium test client generates a test report based on the business status determination results.

2. The method as described in claim 1, characterized in that, The forwarding proxy, based on the obtained questionable test scenario requirements and the first online business request, controls the transmission of communication messages between the mobile client (MC) and the business server (BS), so that the business server (BS) stores the questionable business status of the first online business test, including: If the questionable test scenario requires a network interruption during the business request process, the forwarding proxy will refuse to send the first online business request to the business server (BS) based on the obtained questionable test scenario requirements, so that the business server (BS) stores the questionable status of the first online business test. If the questionable test scenario requires a network interruption during the business response process, the forwarding proxy sends the first online business request to the business server (BS) based on the obtained questionable test scenario requirements, and refuses to send the first online business response to the mobile client (MC) after receiving the first online business response from the business server (BS).

3. The method as described in claim 1, characterized in that, The method further includes: If the questionable test scenario requires instruction tampering during the business request process, the forwarding proxy will illegally tamper with the first online business request sent to the business server (BS) based on the obtained questionable test scenario requirements. When the business server (BS) detects that the request content in the tampered first online business request is illegal, it will determine the business status of the first online business test as a questionable business status. If the questionable test scenario requires instruction tampering during the business response process, the forwarding proxy sends the first online business request to the business server (BS) based on the obtained questionable test scenario requirements, and illegally tampers with the first online business response received from the business server (BS); then sends the tampered first online business response to the mobile client (MC). The mobile client MC and the target SE device jointly detect the tampered first online service response. When it detects that the response content in the tampered first online service request is invalid, it rejects the response result of the service server BS and there are no subsequent requests. At this time, the first online service is in a suspicious state on the service server BS side.

4. The method as described in claim 1, characterized in that, Before instructing the mobile client MC to send the first online service request corresponding to the first service test instruction to the forwarding proxy Proxy, the method further includes: The forwarding proxy forwards the communication messages used to establish a communication connection between the mobile client (MC) and the business server (BS), and parses the communication messages to obtain the transaction sub-key; the transaction sub-key is obtained in the public transport card activation process. When the test case includes offline business testing, the target SE device performs offline business testing based on obtaining the transaction subkey and the target bus card.

5. The method as described in claim 4, characterized in that, The system also includes an offline POS machine simulation service, MockPos, which includes a backend service module MPB and a frontend service module MPF. When test cases include offline business testing, the target SE device performs at least one offline business test of the target public transport card, including: The test client Appium sends at least one offline business test instruction to the front-end service module MPF; For any offline business test instruction, the front-end service module MPF obtains the target bus card number stored in the target SE device based on the offline business test instruction, and sends the target bus card number and the offline business test instruction to the back-end service module MPB; The backend service module MPB obtains the transaction subkey of the target bus card stored in the forwarding proxy Proxy, and after receiving the offline business test instruction, it generates an offline business test instruction by combining the business test instruction, the target bus card number and the transaction subkey, and sends the instruction to the frontend service module MPF. The front-end service module MPF sends offline business test instructions to the SE module in the target SE device to execute offline business tests, and sends the business response to the back-end service module MPB; After the front-end service module MPF sends the business response to the back-end service module MPB, it receives the indication information that the test business has ended from the back-end service module MPB, and sends the offline business test completion information to the test client Appium.

6. The method as described in claim 1, characterized in that, The first online business test includes online card issuance business test and online recharge business test; the second online business test includes online recharge business test and query business test.

7. The method as described in claim 1, characterized in that, The business execution records include transaction records and operation records of the target public transport card.

8. An automated testing system for public transport card services, characterized in that, The system includes: a test client Appium, a forwarding proxy Proxy, a target SE device, and a business server BS. The target SE device includes an SE module and a mobile client MC. The forwarding proxy is used to obtain questionable test scenario requirements from the target test cases sent by the test client Appium; On the target SE device, the mobile client MC receives the first service test instruction for the target bus card sent by the test client Appium, and sends the first online service request corresponding to the first service test instruction to the forwarding proxy Proxy according to the instruction; the first online service request includes the target bus card number stored in the target SE device; The forwarding proxy is also used to control the transmission of communication messages between the mobile client MC and the business server BS according to the obtained questionable test scenario requirements and the first online business request, so that the business server BS stores the questionable business status of the first online business test corresponding to the first online business request. The target SE device is used to store the actual business execution records of the target public transport card. The mobile client MC is used to receive the second service test instruction for the target bus card sent by the test client Appium, and send the second online service request corresponding to the second service test instruction to the service server BS through the forwarding proxy according to the instruction; the second online service request includes the target bus card number; The business server (BS) is used to obtain the business execution record in the target SE device if the target bus card number is detected to have a questionable business status; based on the business execution record of the target bus card, the questionable business status of the first online business test is re-determined to obtain the business status determination result, and the business status determination result is sent to the test client Appium through the forwarding proxy (Proxy), the mobile client (MC), and the target SE device. The Appium test client is used to generate test reports based on the results of business status assessments.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-7.

Images