Automated portable device testing method and system

Abstract

Automated portable device testing methods and systems are described. One method includes receiving, by a reader controller, a configuration file including configuration data, and providing, by the reader controller, a configuration command associated with the configuration data to an access application on an access device. The method also includes configuring the access application on the access device for an interaction context based on the configuration command, and initiating the interaction context between the access device and a testing tool. The method also includes receiving, by the access device, interaction data from the testing tool, and processing, by the access device, the interaction data, thereby generating testing output data. The method also includes providing, by the access device, the testing output data to the reader controller, and sending, by the reader controller, the testing output data to the testing tool.

Description

[0001] Cross-referencing related applications

[0002] This application is a non-provisional application of U.S. Provisional Application No. 63 / 032,947, filed June 1, 2020, and claims priority to the provisional application, which is incorporated herein by reference. Background Technology

[0003] Traditional access devices, such as tag readers, ticket readers, and point-of-sale devices, are specifically manufactured for their intended purpose. These access devices are built and then extensively tested before being deployed to providers who use them.

[0004] In recent years, many transaction providers have been developing access device solutions that can be integrated into commercially available mobile devices. For example, some tag readers, ticket readers, and mobile point-of-sale (mPOS) solutions include applications that can be deployed on smartphones that support Near Field Communication (NFC). Such solutions allow mobile devices to be used as access devices.

[0005] However, one drawback of using an application on a mobile device to turn it into an access device is that the application requires extensive testing before it can be used. Compared to traditional access device readers and software, application software has a rapid release cycle and a shorter lifespan. This is problematic because traditional access devices may need to go through and pass more than 1500 test cases before they are certified. In traditional access device testing, a probe is used to lightly touch the access device under test whenever a test case is run on the device. Therefore, traditional testing methods can be very time-consuming and cumbersome.

[0006] The embodiments of the present invention address these and other problems individually and collectively. Summary of the Invention

[0007] One embodiment includes a method comprising: configuring an access application on an access device for an interaction scenario based on the configuration command received from a reader controller; performing the interaction scenario between the access device and a testing tool; receiving interaction data from the testing tool by the access device; processing the interaction data by the access device to generate test output data; and providing the test output data to the reader controller by the access device, the reader controller sending the test output data to the testing tool. The test output data is compared with expected test output data to determine whether the access device is capable of performing the interaction scenario.

[0008] Another embodiment of the present invention includes an access device comprising: a processor; and a non-transient computer-readable medium including code executable by the processor to cause the processor to perform operations including: configuring an access application on the access device for an interaction scenario based on the configuration command received from a reader controller; performing the interaction scenario between the access device and a testing tool by the access device; receiving interaction data from the testing tool; processing the interaction data to generate test output data; and providing the test output data to the reader controller, which sends the test output data to the testing tool. The test output data is compared with expected test output data to determine whether the access device is capable of performing the interaction scenario.

[0009] Another embodiment includes a method comprising: receiving a test plan by a test tool; storing the test plan by the test tool; determining a configuration file including configuration data from the test plan by the test tool; providing the configuration file including the configuration data to a reader controller by the test tool, the reader controller providing configuration commands associated with the configuration data to an access application on an access device to configure the access application for an interaction scenario between the access device and the test tool; performing the interaction scenario between the access device and the test tool; and receiving test output data from the access device. The test output data is compared with expected test output data to determine whether the access device is capable of performing the interaction scenario.

[0010] Another embodiment of the present invention includes a testing tool comprising: a processor; and a computer-readable medium coupled to the processor. The computer-readable medium includes code executable by the processor to perform operations including: receiving a test plan by the testing tool; storing the test plan by the testing tool; determining a configuration file including configuration data from the test plan by the testing tool; providing the configuration file including the configuration data to a reader controller by the testing tool, the reader controller providing configuration commands associated with the configuration data to an access application on an access device to configure the access application for an interaction scenario between the access device and the testing tool; performing the interaction scenario between the access device and the testing tool; and receiving test output data from the access device. The test output data is compared with expected test output data to determine whether the access device is capable of performing the interaction scenario.

[0011] Another embodiment includes a method comprising: receiving a configuration file including configuration data by a reader controller; providing a configuration command associated with the configuration data to an access application on an access device by the reader controller, the access device configuring the access application on the access device for an interactive scenario based on the configuration command; initiating the interactive scenario between the access device and a testing tool, the access device receiving interactive data from the testing tool, processing the interactive data, and generating test output data; receiving the test output data from the access device; and sending the test output data to the testing tool by the reader controller. The test output data is compared with expected test output data to determine whether the access device is capable of performing the interactive scenario.

[0012] For more detailed information on embodiments of the present invention, please refer to the detailed description and accompanying drawings. Attached Figure Description

[0013] Figure 1 A block diagram of a system according to an embodiment is shown.

[0014] Figure 2 A block diagram and sequential flow of the system according to an embodiment are shown.

[0015] Figure 3 A swimlane diagram of a test protocol according to an embodiment is shown.

[0016] Figure 4 The test execution message flow according to an embodiment is illustrated.

[0017] Figure 5 The batch test execution message flow according to an embodiment is illustrated.

[0018] Figure 6 A message flow for multiple initiations of transaction messages according to an embodiment is illustrated.

[0019] Figure 7 A message flow for multiple terminations of transaction messages according to an embodiment is shown.

[0020] Figure 8 A mobile device with components that can be present in an access device or a testing tool is shown. Detailed Implementation

[0021] Before discussing the embodiments of the present invention, it may be helpful to discuss certain terms.

[0022] "Portable device" can include devices that are easily transportable. For example, a portable device used by a user can interact with an access device to perform interactions. Examples of portable devices include payment devices, membership devices, access cards, identification devices, etc.

[0023] "Mobile device" can include a device that can be carried by a user. Examples of mobile devices can include smartphones, tablet computers, etc. In some embodiments, a mobile device can include an interactive application and kernel. In some embodiments, a mobile device can be a mobile access device. A mobile access device can be used by a resource provider or a person working for a resource provider to verify that a user using a portable device has the right to access resources (e.g., location, goods, services, data, etc.) provided by a resource provider (e.g., transportation operators, venue operators, merchants, etc.).

[0024] "Test computer" can include a computer capable of performing tests. A test computer can include a processor and a computer-readable medium including a reader controller.

[0025] A "testing tool" can be used to interact with another entity (e.g., an access device) to perform tests. In some cases, a testing tool may include an NFC emulator, allowing the testing tool to mimic devices such as contactless cards or contactless phones.

[0026] "Interaction" can include reciprocal effects or influences. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices.

[0027] "Interaction data" can include data related to an interaction. In some embodiments, interaction data can be transaction data. Transaction data can include multiple data elements having data values ​​associated with a transaction. In some embodiments, interaction data can include identifiers, credentials, amounts, dates, times, etc.

[0028] An "interaction context" can include an interaction plan. An example of an interaction context can be a test case. An interaction can be, for example, one or more communications (interactive input and output messages) that can occur between an access device and a test tool. The setup and sequence of these communications can constitute an interaction context.

[0029] A test plan can include multiple interaction scenarios or test cases. A test plan can contain many test cases, which can be used to test whether a specific access application on the access device is functioning correctly.

[0030] "Interactive input message" can be a communication received during an interaction. For example, a message sent by a mobile device can be an interactive input message received from a portable device. An example of an interactive input message can include an Application Protocol Data Unit (APDU) command.

[0031] An "interactive output message" can be a communication sent during an interaction in response to an interactive input message. An example of an interactive output message can include an APDU response sent by a portable device in response to receiving an APDU command.

[0032] "Test interaction" can be an investigational interaction. In some embodiments, test interactions can be performed to determine information about how the interactive system works. For example, different test interactions can be designed to determine whether the interaction will be handled correctly when initiated by different types of portable devices. Test interactions may involve sending certain types of information to the mobile device during an interactive communication session to test how the information is processed. Some test interactions can be designed to check for errors in the interaction processing. For example, some test interactions can check the response from the mobile device when the test computer provides incorrect information about the interaction. Upon receiving incorrect information, a properly functioning mobile device will provide a predicted response (e.g., an error message).

[0033] An "interaction report" can include information about one or more previous interactions. The interaction report may contain a description of how messages in the interaction were handled. For example, the interaction report may include information sent and received, and whether the interaction was successful. The interaction report may also include notes about problems, missing information, delays, or other issues that occurred during the interaction.

[0034] "Reader controller" can be a device and / or software that can, for example, provide control over at least some measurements of the access device during testing.

[0035] A “processor” can include means for performing a task. In some embodiments, a processor can include any suitable one or more data computing means. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user- and / or system-generated requests. A CPU can be a microprocessor such as AMD’s Athlon, Duron, and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processors; Intel’s Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0036] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory may include non-transient computer-readable media whose storage contains instructions executable by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0037] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one example, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0038] An "access device" can be any suitable device for providing access to an external computer system. Access devices can take any suitable form. Some examples of access devices include point-of-sale (POS) devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, etc. Access devices can send or receive data to or from mobile devices using any suitable contact or contactless operating mode, or be associated with mobile devices. In some embodiments where the access device may include a POS terminal, any suitable POS terminal can be used, and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a mobile device.

[0039] Figure 1 A schematic diagram of the system according to an embodiment is shown. Figure 1 The roles of three entities in test automation are illustrated: test tool 120, reader controller 130, and access device 140. Access device 140 can be a device that authorizes access to resources, such as a building sign access reader, ticket reader, or point-of-sale terminal.

[0040] Test tool 120 can communicate with reader controller 130 to deliver transaction configurations and receive transaction results. Test tool 120 may also include a card emulator 125 (e.g., a card probe, software or a physical card emulating card functionality) for executing each test case. Test tool 120 may also include a test computer with a display having a user interface (UI), which can provide tester 110 with the ability to communicate with or control test tool 120. The user interface may display test steps and instructions for performing tests, prompts for confirming test status, events and visual inspections, and test conclusions. Test tool 120 can also verify Application Protocol Data Units (APDUs) and transaction results.

[0041] The reader controller 130 can communicate with the test tool 120 to receive transaction configuration data and pass it to the access device 140. The transaction configuration data may include data that causes the access device 140 to operate under predetermined conditions. For example, if the access device 140 is a point-of-sale terminal, the transaction configuration data may include data that causes the access device 140 to simulate a twenty-dollar payment transaction, such as when a merchant enters twenty dollars into the access device 140 and waits to receive the account from a portable device. In another instance, if the access device 140 is a ticket reader, the configuration data may configure the access device 140 to interact with a specific type of ticket format at a certain time of day.

[0042] After the card emulation device 125 provides any requested data (e.g., account number, user ID, etc.) to the access device 140, the reader controller 130 can also retrieve data representing the transaction result from the access device 140. The reader controller 130 can then subsequently submit this information to the testing tool 120. The transaction result can be correct or incorrect, and the transaction result can be evaluated by the testing tool 120. For example, in the case of a payment transaction, a correct transaction result could be a generation or authorization request message from the access device 140 or some other type of message.

[0043] Figure 2 Another block diagram of a system according to another embodiment is shown. Figure 2 A tester 110 is shown, which can be a person or a machine. The system may include a test tool 120, a reader controller 130, and an access device 140. (The above is in contrast to...) Figure 1 These components are described. The system also includes a test portal 150, a test computer 135 with a reader controller 130, an interactive server 160, and test result files 170.

[0044] In some embodiments, the test tool 120 may be a mobile device, such as a smartphone. The test tool 120 may include a test application 122. The test tool 120 may have an NFC card emulation device 125, which may include hardware and / or software suitable for allowing the test tool 120 to emulate an NFC card. It should be noted that although NFC is discussed as an example, other short-range wireless communication mechanisms such as Wi-Fi, Bluetooth, IR, etc., or even contact-based communication mechanisms may be used in embodiments.

[0045] The reader controller 130 can be hosted on the test computer 135. The test computer can be a personal computer, such as a laptop or desktop computer, which can communicate with the interactive server 160 and the access device 140.

[0046] In some embodiments, access device 140 may be a mobile device, such as a smartphone. Access device 140 may include access application 142. Access application may be a building or event access application, a mobile point-of-sale application, etc. Access application 142 in access device 140 may communicate with interaction server 160. Access device 140 may also include NFC reader 145, which provides the ability to read data from a portable device using NFC.

[0047] Test portal 150 provides test plans and certification for the access application 142 to be tested. In some embodiments, test portal 150 may include test plan 152, report check 154, and test plan and report viewer 156. Test plan 152 may be one of many test plans, each having test cases (test scenarios) for testing the access device and the access application. Test plans may be stored in a test plan component within test portal 150. Report check component 154 may receive test results from access device 140 or access application 142. Test results may be in test result file 170. Report check component 154 may also evaluate test results and may approve or disapprove access device 140 or access application 142. Test plan and report viewer 156 may provide tester 110 with visualization of test plan 152 and test result file 170.

[0048] In some embodiments, test portal 150 may be manifested by a remote server computer running a website, which is used or accessed by a tester 110 using a user device (not shown). Test portal 150 may communicate with test application 122 on test tool 120 via a communication network.

[0049] Suitable communication networks can be any one and / or a combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), an Operational Mission as a Node on the Internet (OMNI), a secure custom connection, a wide area network (WAN), or a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.). Messages between computers, networks, and devices can be transmitted using secure communication protocols such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); Secure Sockets Layer (SSL), etc.

[0050] Access device 140 and testing tool 120 can be smartphones, tablets, or similar commercially available devices. For example, the access device can be a first mobile phone, and the testing tool 120 can be a second mobile phone. They can be located in the same location and can be close to each other during testing (e.g., within 1 inch or in contact with each other). Since access device 140 and testing tool 120 can be commercially available devices such as smartphones, embodiments of the invention can be implemented by resource providers who wish to install access application 142 on access device 140 and authenticate said access application.

[0051] Tester 110, who operates the user device, test computer 135, test portal 150, and test server 160, may be located at the location of access device 140 and test tool 120. In other embodiments, one or more of these entities may be remotely located relative to each other and / or access device 140 and test tool 120.

[0052] Continue to refer to Figure 2 This can describe a method for testing the access application 142 on the access device 140.

[0053] In step 1, tester 110 or another entity may launch test application 122. Test application 122 may check for the latest version of test plan 152 and download the latest version of test plan from test portal 150 to test tool 120. Tester 110 or another entity may operate test tool 120 and use it to contact test portal 150 to obtain test plan 152.

[0054] In step 2, tester 110 can initiate tests in test application 122. Tests can be performed in batches, with multiple test cases, or as a single test case. Test application 122 on test tool 120 can push a first configuration file to reader controller 130, the first configuration file containing first configuration data for a first interaction scenario of the test cases.

[0055] In step 3, the reader controller 130 may receive first configuration data from the first configuration file and send a first configuration command to the access application 142 to configure the access application 142. In some embodiments, the first configuration command may be sent via the interactive server 160. For example, the first configuration command may configure the access application 142 for a $20 transaction. In this case, the access application 142 may receive data indicating that a $20 transaction is beginning, and then may perform steps to process the $20 transaction. In some cases, configuring the access application 142 may include inputting certain values ​​(e.g., transaction amount) into certain data fields in the access application 142, opening or closing certain routines in the access application 142, modifying or updating code in the access application 142 to cause the access device 140 to operate in a particular manner, etc.

[0056] In step 4, the reader controller 130 can initiate a first interaction scenario for the test case. When initiating the first interaction scenario, the reader controller 130 can set the NFC receiver to a "closed" state by sending a first signal to the NFC receiver of the access device 140, and then set it to an "open" state by sending a second signal to the NFC receiver to simulate a touch. In some embodiments, the sent signal can turn the access device 140 on or off by toggling a small block that controls the open or closed state of the access device 140. In this way, a single touch interaction can be simulated even if the access device 140 and the test tool 120 remain in continuous contact or maintain a constant interval (e.g., half an inch) across multiple tests. In other words, multiple touches (e.g., more than 100 or more than 1000 touches) can be simulated by turning the NFC reader module 145 on and off even if the access device 140 and the test tool 120 do not move. This eliminates the need for humans or machines to manually move the test tool 120 for each test performed, thereby improving testing speed and reducing the probability of any errors (e.g., mechanical failures) associated with the mechanical movement of the test tool 120.

[0057] In step 5, after using the test case APDU flow of access application 142, test application 122 may begin card emulation using NFC card emulation device 125 to perform a first interaction scenario. In some embodiments, test application 122 may begin card emulation in response to receiving a message from reader controller 130. For example, the message may be a read record command in which credentials such as a user ID or account are requested from test tool 120, which simulates a portable device, such as a payment card or access token. After test tool 120 receives the message requesting interaction data, access device 140 may subsequently receive interaction data (e.g., simulated PAN, dCVV) from test tool 120.

[0058] In step 6, the access application 142 can process the interaction data of the first interaction scenario and create first test output data. For example, the first test output data could be a transaction confirmation for a $20 transaction, or it could be data related to the generation of an authorization request message for a $20 transaction. The access application 142 can then provide the first test output data to the reader controller 130. In some embodiments, the first test output data can be sent via the interaction server 160.

[0059] In step 7, the reader controller 130 may return the first test output data to the test application 122. The test application 122 (or any other downstream device) may then compare the first test output data with the first expected output data to determine whether the access device 140 and / or the access application 142 are capable of performing the first interactive scenario. For example, the expected test output may be in the form of an authorization request message formatted with the account from the test tool 120 and the requested amount of twenty dollars in the authorization request message. The test application 122 may compare the received authorization request message format with the expected authorization request message format to determine whether the access application 142 is functioning as expected.

[0060] Then, test application 122 can repeat steps 2-7 for all test cases in the test plan or selected by tester 110. For example, to initiate a second test, test application 122 can send a second profile with second configuration data to reader controller 130. Reader controller 130 can then send a second configuration command to access application 142 to configure the access application for a second interaction scenario. For example, the second configuration could be a $100 transaction. Reader controller 130 can then initiate a second interaction scenario by turning the NFC receiver of access device 140 on and off to simulate a second touch or physical interaction between access device 140 and test tool 120. Access application 142 then processes the second interaction scenario and generates second test output data, which can be sent to reader controller 130 and then to test application 122. Test application 122 can then compare the second test output data with the second expected output data as described above.

[0061] It should be noted that steps 2-7 can be repeated as needed for any number of test plans or test scenarios.

[0062] In step 8, the test application 122 generates a test result file 170 after completing one or more tests selected by the tester 110. The test result file 170 may include test output data (e.g., first test output data, second test output data, etc.) and expected output data (e.g., first expected output data, second expected output data, etc.).

[0063] In step 9, tester 110 uploads test result file 170 from test tool 120 to test portal 150 for visualization. Tester 110 can view test result file 170, see passed and / or failed tests, and review test plan 152 for debugging.

[0064] In step 10, tester 110 uploads test result file 170 to report check 154 of test portal 150 to check whether the test has been run. Test portal 150 can verify test result file 170 and confirm that application 142 has successfully completed the test. If so, test portal 150 can authorize application 142 for public use and distribution.

[0065] Before conducting the test, tester 110 can complete the setup process. Tester 110 can install the target access application 142 on access device 140, the reader controller 130 on test computer 135, and the test application 122 on test tool 120. Test application 122 can be downloaded from a remote application store storing many applications. Tester 110 configures test application 122 to connect to reader controller 130 via HTTP connection or some other means. Tester 110 can then place access device 140 and test tool 120 within range (e.g., back to back) to allow NFC communication between them. Tester 110 can then connect test computer 135 and access device 140 (e.g., via USB) to allow reader controller 130 and access application 142 to communicate.

[0066] In some embodiments, the test plans and test cases used by the reader controller can be generated autonomously. This can be done by the test portal 150. In such embodiments, a requirement model and artificial intelligence (AI) can be used to generate machine-readable test plans in, for example, XML or JSON format. Human-readable test plans can then be generated from the machine-readable test plans. The model and AI are used to generate test cases from the machine-readable test plans, and the test cases contain test data, test procedures, and expected outputs. Machine-readable test cases can then be generated, for example, in XML or JSON. The test plans and test cases can then be hosted by the test portal 150 on a cloud server.

[0067] Figure 3 A swimlane diagram illustrates the test process that can occur between the test tool 120, the reader controller 130, and the access device 140. These components are... Figure 1 and 2 As shown, and the steps can be compared with those above. Figure 1 and 2 The combination of steps described.

[0068] In step 1 of the test preparation, the reader controller 130 can test the connection with the test tool 120 by sending an "ECHO" request HTTP message. The request behavior of the "ECHO" request HTTP is TRACE / HTTP / 1.1, and the request header is "Message: ECHO, Hosted: [IP address]: [port], Connection: Keep Alive".

[0069] In step 2, the testing tool 120 can respond with an "ECHO" HTTP response message. The "ECHO" response message has the status behavior "http / 1.1 [status code reason phrase]", the response header is "Connection: Keep Alive, Content Type: Text / Plaintext", and the response message body can include the content of the ECHO request header. The status code can be one of the following: 200 Normal (Success, ACK), 400 Error Request Format (Incorrect Request Syntax), 408 Request Timeout (Server Busy, Retry Later), or Other (Failure).

[0070] After confirming that a connection has been established, the reader controller 130 can initiate a test execution process. The test execution process can be iterated repeatedly (e.g., 1500 times).

[0071] In step 1 of the test execution, the reader controller 130 may send a request to the test tool 120 to start a transaction. The request may be an "STXN" request HTTP message with a request action of GET / HTTP / 1.1 and a request header of "Message: STXN Hosting: [IP address]: [port] Connection: Keep Alive".

[0072] In step 2, the testing tool 120 can send the transaction configuration in an "STXN" response HTTP message to the reader controller 130, with the status behavior HTTP / 1.1 [status code reason phrase], the request header "Connection: Keep Alive, Content Type: Text / Plaintext", and the XML data containing the configuration data. The status code can be one of the following: 200 OK (Success, ACK), 204 No Content (No More Tests), 400 Bad Request Format (Incorrect Request Syntax), 408 Request Timeout (Server Busy, Retry Later), 409 Conflict (Multiple Updates), or others (Server Error).

[0073] In step 3, the reader controller 130 may send a configuration command to the access device 140 to configure the device for the transaction.

[0074] In step 4, access device 140 can execute a test (or test scenario). During test execution, access device 140 can interact with test tool 120 (e.g., by reading a simulation card on test tool 120).

[0075] In step 5, the access device 140 can process the transaction and generate the transaction result as test output data. Then, the access device 140 can send the test output data to the reader controller 130.

[0076] In step 6, the reader controller 130 can submit the transaction result to the test tool 120 by sending an "ETXN" request HTTP message. The "ETXN" request HTTP message has the request behavior of POST / HTTP / 1.1, the request header is "Message: ETXN, Hosting: [IP address]: [port], Connection: Keep-alive, Content type: Text / Plaintext", and the XML data includes the test output data.

[0077] In step 7, the testing tool 120 can confirm the transaction result by sending an "ETXN" response HTTP message, the status behavior of which is HTTP / 1.1 [status code reason phrase]. The status code can be one of the following: 200 OK (success, ACK), 400 Error Request Format (malformed request syntax), 408 Request Timeout (server busy, try again later), 409 Conflict (multiple updates), etc.

[0078] Figure 4 and Figure 5 The diagram illustrates message exchange between a client (e.g., a reader controller) and a server (e.g., a testing tool) during test execution. Before the test process begins, the server may prepare a list of test_IDs to be run. This list of test_IDs can depend on the tester's preferred run type. The tester can choose to run and execute individual test cases one by one (running one by one) or run and execute a batch of test cases (batch run). In other embodiments, the tester may select a subset of test cases from the batch. Figure 4-5 as well as Figure 6-7 The steps shown can be compared with those above. Figure 1-2 The combination of steps described.

[0079] The test_ID can be adjusted to a minimum of three states for the test cycle. One state is "Start"—the start state, where the test_ID has never been sent or never completed. Another state is "Sent," where the server receives the transaction start message and the test_ID has been sent to the client. The third state is "Completed," where the server receives the transaction end message for the test_ID and responds with a 200 (normal) status code. When the server has completed the list of test_IDs (e.g., no more test cases to run), it can respond to the transaction start message with a 204 status code.

[0080] Figure 4 The message flow for a single test case run is shown. In step 402, the user can identify the individual test ID to be run.

[0081] In step 404, the client may send an STXN request message to the server.

[0082] In step 406, the server can reply with the test_ID in an STXN response with status code 200 and mark the test_ID as sent.

[0083] In step 408, the client may send an ETXN request message to the server.

[0084] In step 410, the server can respond with an ETXN response with status code 200 and mark the test_ID as completed.

[0085] In step 412, the client may send another STXN request message to the server.

[0086] In step 414, the server may send an ETXN response message with status code 204, indicating that no more test cases are pending execution.

[0087] Figure 5 The message flow for batch execution of multiple test cases is illustrated. In step 502, the server can prepare a list of test_IDs to be run.

[0088] In step 504, the client may send an STXN request message to the server.

[0089] In step 506, the server may reply with the next test_ID in an STXN response with status code 200 and mark the test_ID as sent.

[0090] In step 508, the client may send an ETXN request message to the server.

[0091] In step 510, the server can respond with an ETXN response with status code 200 and mark the current test_ID as completed.

[0092] Then, steps 504-510 can be repeated multiple times until all test cases have been executed.

[0093] In step 512, the client may send another STXN request message to the server.

[0094] In step 514, if there is no test_ID marked as "completed", the server can send an ETXN response message with status code 204, indicating that there are no more test cases to run.

[0095] In some embodiments, the testing tool has an option for users to enable a Stop-On-Error function. This function allows the testing tool to "pause" the testing process when the access device test fails. This allows users to resume the testing process after investigating the cause of the failure. When the testing process is paused, the testing tool can store the test case information so that the process can continue to the next test case upon resumption.

[0096] When the error-stop function is enabled and the conclusion of the last test case is a failure, the server can respond with a 204 status code. A 204 status code can cause the client application to stop or pause the testing process. When the client application resumes the testing process, the server responds with the next test_ID having a status of == "Started". If the test conclusion is not yet available (e.g., for test cases requiring additional visual inspection), the server can respond with a "Server Busy" 408 return code.

[0097] In some embodiments, the client may send multiple transaction start messages before receiving the transaction end message. Figure 6 The message flow is shown when multiple transaction start messages are sent.

[0098] In step 602, the server can prepare a list of test_IDs to be run.

[0099] In step 604, the client may send an STXN message to the server.

[0100] In step 606, the server can reply with the next test_ID and mark the test_ID as sent.

[0101] In step 608, the client may send another STXN message to the server.

[0102] In step 610, the server can retrieve the last test_ID with a status of "sent" and reply with the same response message as in step 606.

[0103] In other embodiments, multiple ETXN messages can be received without interfering with the STXN message. In this case, the server can check if the test_ID is the same as the last test_ID (where the last message is an ETXN message). If the test_ID is the same, the server can overwrite the transaction result based on the new ETXN message and invoke the testing tool to re-verify the test.

[0104] In step 702, the server can prepare a list of test_IDs to be run.

[0105] In step 704, the client may send an STXN message to the server.

[0106] In step 706, the server can reply with the next test_ID and mark the test_ID as sent.

[0107] In step 708, the client may send an ETXN message to the server.

[0108] In step 710, the server can respond with an ETXN response with status code 200 and mark the current test_ID as completed.

[0109] In step 712, the client may send another ETXN message to the server.

[0110] In step 714, the server can overwrite the result of the last ETXN message with the result of the new ETXN message. The server can also re-perform the associated test verifications.

[0111] In some embodiments, the client may send an ETXN message whose test_ID does not match the test_ID of the last received STXN message. Upon receiving these ETXN messages, the server may respond with a 400 status code indicating an error request format.

[0112] Figure 8 A mobile communication device 800 according to an embodiment is shown. The mobile communication device 800 may include device hardware 804 coupled to a system memory 802, which may include a computer-readable medium 802.

[0113] Device hardware 804 may include a processor 806, a short-range antenna 814, a long-range antenna 816, an input element 810, a user interface 808, and an output element 812 (the output element may be part of the user interface 808). Examples of input elements may include a microphone, keyboard, touchscreen, sensors, etc. Examples of output elements may include a speaker, display screen, and haptic device. Processor 806 may be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers) and is used to control the operation of mobile communication device 800. Processor 806 may execute various programs in response to program code or computer-readable code stored in system memory 802, and may maintain multiple concurrently executing programs or processes.

[0114] The long-range antenna 816 may include one or more RF transceivers and / or connectors that can be used by the mobile communication device 800 to communicate with other devices and / or connect to external networks. The user interface 808 may include any combination of input and output elements to allow a user to interact with the mobile communication device 800 and invoke the functions of the mobile communication device. The short-range antenna 814 may be configured to communicate with external entities via short-range communication media (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long-range antenna 816 may be configured to communicate over the air with remote base stations and remote cellular or data networks.

[0115] System memory 802 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transient storage media or combinations thereof. System memory 802 may store computer code executable by processor 806 to perform any of the functions described herein. For example, system memory 802 may include a computer-readable medium comprising code executable by processor 806 to implement the methods described herein for test tools and / or access devices.

[0116] The system memory 802 may also store the kernel 802A, application programs 802B, virtual devices such as virtual cards 802C, credentials / tokens 802D, and the operating system 802E.

[0117] Kernel 802A can be a contactless kernel. Kernel 802A can be within or outside of application 802B. The kernel can provide the basic functionality of application 802B. For example, kernel 802A can provide code for generating certain responses or performing operations in response to messages received by kernel 802A.

[0118] Application 802B may be an access application in the case of an access device, or a test application in the case of a mobile device 800 being a test tool. The access application may be a contactless application that allows the mobile device 800 to behave as an access device similar to a contactless portable device capable of receiving and processing data from, for example, a contactless card (e.g., a contactless payment card). The access device may be a POS terminal, a transmission terminal, a data access terminal, etc. If the mobile communication device 800 is an access device, application 802B may include code for reading and processing data from the portable device, generating an authorization request message based on the data received from the portable device, transmitting the authorization request message to an authorization entity computer, and receiving and processing an authorization response message from the authorization entity computer.

[0119] When the mobile device 800 is used as a testing tool, the virtual card 802C may include code for simulating the functionality of a contactless card in the software. The virtual card 802C and processor 806 may behave similarly to the previously described physical reprogrammable card or probe. The virtual card 802C and processor 806 may receive messages from the test computer according to a network-based protocol and then convert the messages into an APDU message format compatible with NFC data transmission.

[0120] When the mobile device 800 is in the form of a test tool, the system memory 802 may also store credentials and / or tokens 802D. Credentials may also include information identifying the mobile communication device 800 and / or its user. Examples of credentials may include a public key associated with the mobile communication device 800 and / or its user, a digital signature (e.g., the public key of the mobile communication device 800 signed by a key of an authentication system), payment credentials, biometric data (e.g., a biometric sample or template), etc.

[0121] The embodiments of the present invention offer several advantages. As described above, the embodiments of the present invention can allow for the rapid testing of hundreds or even thousands of test scenarios for an access application to be deployed to an access device. This can be done without any movement of the access device or the testing tool used to test the access device. Furthermore, the test application can be downloaded to the testing tool, thereby allowing the testing tool to communicate with a test portal having various test plans with test scenarios and a reader controller that controls the access device under test. Thus, the embodiments allow, for example, a resource provider from a vendor to simply download the test application to a mobile phone and also download the access application to another mobile phone. Both phones can be used to verify the operation of the access application.

[0122] Another embodiment includes a method comprising: receiving a configuration file including configuration data by a reader controller; providing a configuration command associated with the configuration data to an access application on an access device by the reader controller, the access device configuring the access application on the access device for an interactive scenario based on the configuration command; initiating the interactive scenario between the access device and a testing tool, the access device receiving interactive data from the testing tool, processing the interactive data, and generating test output data; receiving the test output data from the access device; and sending the test output data to the testing tool by the reader controller, the testing tool comparing the test output data with expected output data to determine whether the access device is capable of performing the interactive scenario.

[0123] Another embodiment may include the method described above, wherein the configuration file is a first configuration file, the configuration data is first configuration data, the configuration command is a first configuration command, the interaction scenario is a first interaction scenario, the test output data is first test output data, and the expected output data is first expected output data, wherein the method further includes: the test tool determining a second configuration file including second configuration data from the test plan; the test tool providing the second configuration file including the second configuration data to a reader controller, the reader controller providing a second configuration command associated with the second configuration data to the access application on the access device to configure the access application for a second interaction scenario between the access device and the test tool; performing the second interaction scenario between the access device and the test tool; receiving second test output data from the access device; and comparing the second test output data with the second expected output data to determine whether the access device is capable of performing the second interaction scenario.

[0124] Another embodiment includes a method according to the above method, wherein the second configuration file is automatically sent in response to receiving the first test output data.

[0125] Any software component or function described in this application may be implemented as software code executable by a processor using, for example, conventional or object-oriented techniques and any suitable computer language (e.g., Java, C++, or Perl). The software code may be stored as a series of instructions or commands on a computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device, and may exist on or within different computing devices within a system or network.

[0126] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of this disclosure. Therefore, the scope of the invention may be determined not with reference to the above description, but rather with reference to the pending claims and their full scope or equivalents.

[0127] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0128] Unless explicitly indicated otherwise, the use of “one” or “the” is intended to mean “one or more”.

[0129] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. This does not constitute an admission that they are prior art.

Claims

1. A method comprising: Download the access application to the access device, the access device including a processor, a computer-readable medium, and a reader device; After the reader controller on the test computer, which is separate from the access device, transmits the start transaction request to the test tool via the Internet, and after the test tool sends the start transaction response to the reader controller via the Internet, the access application in the access device receives the first configuration command from the reader controller. The access device configures the access application in the access device based on the first configuration command received from the reader controller for use in a first interaction scenario; The reader device in the access device receives a first signal from the reader controller, the first signal being used to open the reader device in the access device to initiate the first interactive scenario; The first interaction scenario is initiated by the access device between the access device and the testing tool, wherein the testing tool includes a testing application; The access device receives first interactive data from the test tool, wherein the first interactive data includes first transaction data, and the first transaction data includes data values ​​associated with one or more first transactions; The access device processes the first interactive data, thereby generating the first test output data; The access device provides the first test output data to the reader controller, wherein the reader controller sends the first test output data to the test tool via the Internet, wherein the first test output data is compared with the first expected output data to determine whether the access device is capable of performing the first interaction scenario; The reader device in the access device receives a second signal from the reader controller, the second signal being used to disable the reader device in the access device; The access application in the access device receives a second configuration command from the reader controller; The access device configures the access application in the access device based on the second configuration command received from the reader controller for use in the second interaction scenario; The reader device in the access device receives a third signal from the reader controller, the third signal being used to open the reader device in the access device to initiate the second interaction scenario; The second interaction scenario is initiated by the access device between the access device and the testing tool; The access device receives second interactive data from the testing tool; The access device processes the second interactive data, thereby generating second test output data; as well as The access device provides the second test output data to the reader controller, which then transmits the second test output data to the testing tool via the Internet. The second test output data is compared with second expected output data to determine whether the access device is capable of performing the second interaction scenario. The access device and the test tool remain stationary and within one inch of each other during at least one hundred test scenarios, including the first and second interaction scenarios, and are close to each other and remotely positioned relative to the test computer including the reader controller. The reader device mentioned above is an NFC reader device.

2. The method according to claim 1, wherein the access device is a first mobile phone and the testing tool is a second mobile phone.

3. The method of claim 1, wherein the first interaction scenario is part of a test plan that includes multiple interaction scenarios.

4. The method according to claim 1, wherein the testing tool includes an NFC card emulation device, the NFC card emulation device being used to mimic the operation of an access card.

5. The method of claim 1, wherein the first interaction scenario includes transmitting multiple application protocol data unit messages between the access device and the testing tool.

6. The method of claim 1, wherein the first interaction scenario exists in a test plan received by the reader controller via a test application on the test tool.

7. The method of claim 1, further comprising: Without moving the testing tool and the access device, at least one thousand test scenarios are performed using the testing tool and the access device.

8. The method of claim 1, wherein before being configured for the first interaction scenario, the reader controller sends an ECHO request to the test tool and receives an ECHO response from the test tool.

9. An access device, comprising: processor; A reader device coupled to the processor; as well as A non-transient computer-readable medium coupled to the processor, the non-transient computer-readable medium including code executable by the processor to cause the processor to perform operations, said operations including: Download and access the application; After the reader controller on the test computer, which is separate from the access device, transmits the start transaction request to the test tool via the Internet, and after the test tool sends the start transaction response to the reader controller via the Internet, the access application receives the first configuration command from the reader controller. Configure the access application in the access device for a first interaction scenario based on the first configuration command received from the reader controller; The reader device in the access device receives a first signal from the reader controller, the first signal being used to open the reader device in the access device to initiate the first interactive scenario; The first interaction scenario is initiated by the access device between the access device and the testing tool, wherein the testing tool includes a testing application; Receive first interaction data from the test tool, wherein the first interaction data includes first transaction data, and the first transaction data includes data values ​​associated with one or more first transactions; Process the first interactive data to generate the first test output data; The first test output data is provided to the reader controller, which then sends the first test output data to the test tool via the Internet. The test tool compares the first test output data with the first expected output data to determine whether the access device can perform the first interaction scenario. The reader device in the access device receives a second signal from the reader controller, the second signal being used to disable the reader device in the access device; The access application in the access device receives a second configuration command from the reader controller; The access application in the access device is configured based on the second configuration command received from the reader controller for use in the second interaction scenario; The reader device in the access device receives a third signal from the reader controller, the third signal being used to open the reader device in the access device to initiate the second interaction scenario; Initiate the second interaction scenario between the access device and the testing tool; Receive second interactive data from the testing tool; Process the second interactive data, thereby generating second test output data; and The access device provides the second test output data to the reader controller, which then transmits the second test output data to the testing tool via the Internet. The second test output data is compared with second expected output data to determine whether the access device is capable of performing the second interaction scenario. The access device and the test tool remain stationary and within one inch of each other during at least one hundred test scenarios, including the first and second interaction scenarios, and are close to each other and remotely positioned relative to the test computer including the reader controller. The reader device mentioned above is an NFC reader device.

10. The access device according to claim 9, wherein the access device is a mobile phone.

11. A method comprising: The test plan is received by the testing tool; The test plan is stored by the test tool; The testing tool determines a configuration file that includes configuration data from the test plan; After the reader controller on the test computer transmits the start transaction request to the test tool via the Internet, and after the test tool sends the start transaction response to the reader controller via the Internet, the test tool provides the configuration file including the configuration data to the reader controller via the Internet. The reader controller provides a first configuration command associated with the first configuration data to an access application in an access device separate from the test computer to configure the access application for a first interaction scenario between the access device and the test tool. The first interaction scenario is initiated by the testing tool between the access device and the testing tool; The testing tool provides first interactive data to the access device, wherein the first interactive data includes first transaction data, and the first transaction data includes first data values ​​associated with one or more first transactions; The testing tool receives first test output data from the reader controller via the Internet, wherein the first test output data is compared with first expected output data to determine whether the access device is capable of performing the first interaction scenario; The test tool provides a second configuration file to the reader controller via the Internet. The second configuration file is used to configure the access application in the access device for a second interaction scenario. The reader controller provides a second configuration command to the access application in the access device. The testing tool provides the access device with second interaction data for the second interaction scenario; as well as The testing tool receives second test output data from the reader controller via the Internet, wherein the second test output data is compared with second expected output data to determine whether the access device is capable of performing the second interaction scenario. The access device and the test tool remain stationary and within one inch of each other during at least one hundred test scenarios, including the first interaction scenario and the second interaction scenario, and the access device and the test tool are close to each other and remotely positioned relative to the test computer including the reader controller. The access device includes a reader device, a processor coupled to the reader device, and a computer-readable medium coupled to the processor. The reader controller sends a first signal to the reader device to close it upon completion of the first interaction scenario and sends a second signal to the reader device to open it and begin the second interaction scenario. The reader device mentioned above is an NFC reader device.

12. The method of claim 11, wherein the testing tool is a mobile phone.

13. The method of claim 11, wherein the testing tool includes a testing application, wherein the testing application communicates with a testing portal to receive the test plan and with the reader controller.

Images