abrantix test environment · languages, currencies and payment protocols (iso 8583, ifsf, ep2,...

Copyright © Abrantix AG 2018 Förrlibuckstrasse 66, CH - 8005 Zürich, +41 43 433 70 30

www.abrantix.com, [email protected]

Abrantix Test Environment

Product Description

Version: 2.2 / Dec 14 2018

For many years, Abrantix has been developing a large number of payment applications for EFT/POS terminals. These applications have to be tested and certified according to international requirements and standards such as EMV L2/L3 and PCI. In addition, the requirements of local payment protocols or acquirers like ADV/TIP must be met. With every software release we need to run regression tests with several ECR integrations and other external interfaces. Since we support many different languages, currencies and payment protocols (ISO 8583, IFSF, ep2, etc.) testing is very complex and the number of tests only ever increases.

Quite early on we have started to focus on high quality software and therefore good quality assurance processes. This is especially important in our industry because the EFT environment proves to be very heterogeneous, consisting of different cash registers, acquirers, payment protocols, host configurations and terminals etc.

With this in mind we have developed an extensive testing framework that allows the complete testing of payment applications on different levels in fully automated fashion. The Abrantix Test Environment software is the centrepiece of this framework. The Test Environment is used to execute manual and automated tests and orchestrates all necessary components that together build the test setup. It provides a graphical user interface which is the main point of interaction where test runs can be created, orchestrated and executed.

Tests are written in XML and can be grouped into test sets. All tests are stored in a repository and can therefore be made accessible to all test-team members. Every test only has to be written once and can be used by every team member. This massively simplifies the creation of large test sets.

The Test Environment is a modular and therefore flexible software application that also provides extension points for proprietary functionality.

A built-in reporting module is used to generate complete test reports and results in PDF format.

Abrantix Test Environment – Product Description

Overview 2 / 17

© 2018 Abrantix AG Version 2.2 / Dec 14 2018

Table of contents

1 Overview ........................................................................................................................................ 4

2 Features ......................................................................................................................................... 5

2.1 Test Sets, Definitions and Runs .............................................................................................. 5 2.2 Test Run Results ..................................................................................................................... 5 2.3 Environment Definitions ........................................................................................................... 5 2.4 Test Libraries ........................................................................................................................... 5 2.5 GUI .......................................................................................................................................... 6 2.6 Manual and Automated Testing............................................................................................... 6 2.7 Variables .................................................................................................................................. 6 2.8 Adapters .................................................................................................................................. 6

2.8.1 Available Abrantix Adapters ............................................................................................ 7

2.9 Log Data .................................................................................................................................. 8 2.10 Test Reports ............................................................................................................................ 8 2.11 Hardware Extensions .............................................................................................................. 8

2.11.1 Abrantix EFT/POS Terminal Testing Robot .................................................................... 8 2.11.2 Abrantix Card Multiplexer ................................................................................................ 8 2.11.3 Abrantix Magstripe Probe ................................................................................................ 9

3 Architecture ................................................................................................................................. 10

3.1 Data Model ............................................................................................................................ 10

3.1.1 Test Definition and Steps .............................................................................................. 10 3.1.2 Test Set ......................................................................................................................... 10 3.1.3 Test Run ........................................................................................................................ 11

3.2 Adapters and Controllers ....................................................................................................... 11

3.2.1 Public API ...................................................................................................................... 12 3.2.2 Adapter and Controller Example ................................................................................... 12

3.3 Terminal State Validation During Test ................................................................................... 13

4 Hardware and Software Requirements ..................................................................................... 14

5 Appendix A - Screen shots ........................................................................................................ 15


Overview 3 / 17


Table of figures

Figure 1: Regular EFT/POS Terminal Testing Setup .............................................................................. 4 Figure 2: Example Setup with Adapters .................................................................................................. 4 Figure 3: Adapters and Instructions ........................................................................................................ 7 Figure 4: Abrantix EFT/POS Terminal Testing Robot ............................................................................. 8 Figure 5: Abrantix Card Multiplexer (contact) - Housing of final product might differ from housing shown in image ........................................................................................................................................ 9 Figure 6: Abrantix Magstripe Probe ......................................................................................................... 9 Figure 7: Architecture Overview ............................................................................................................ 10 Figure 8: Adapters and Controllers ....................................................................................................... 11 Figure 9: Adapter and Controller Example ............................................................................................ 12 Figure 10: Test environment and adapters ........................................................................................... 15 Figure 11: Chose test environment ....................................................................................................... 15 Figure 12: Trace view of executed test ................................................................................................. 16 Figure 13: Test steps wiht test results ................................................................................................... 16 Figure 14: Test library with test sets ...................................................................................................... 17

Tables

Table 1: Definitions and abbreviations .................................................................................................... 3 Table 2: References ................................................................................................................................ 3 Table 3: Available Abrantix Adapters ...................................................................................................... 7

Definitions and Abbreviations

Term Definition EMV Europay International, MasterCard und VISA

PCI Payment Card Industry Data Security Standard

ADV/M-TIP Acquirer Device Validation / MasterCard Terminal Integration Process

MUX Multiplexer

PIN Personal identification number

EFT/POS Electronic Funds Transfer / Point of sale

ECR Electronic cash register

Table 1: Definitions and abbreviations

References

Ref. Description Version / Date

[xmlref] Abrantix Test Environment - Xml Data Model Reference 0.1 / 2018-12-13

Table 2: References


Overview 4 / 17


1 Overview

A complete EFT/POS terminal test setup not only requires the terminal itself, it also requires the correct test cards, the corresponding terminal configuration, the host environment and the correct payment protocol and cash register versions. Figure 1 shows the simplified version of a standard test setup.

Figure 1: Regular EFT/POS Terminal Testing Setup

Setting up such an environment is very difficult, not to mention a setup that allows test automation. The fact that each of the surrounding environments has its own release cycle further complicates testing. With the adoption of app-store like ecosystems around terminals this complexity will only ever increase.

The Abrantix Test Environment is a purpose-built EFT/POS terminal testing software that facilitates the use of such complex test setups. This is made possible by a flexible and extensible design that allows plugging in so called adapters for each component of the test setup.

Figure 2 shows an example of the test setup shown above, integrated with the Abrantix Test Environment for automated testing.

Figure 2: Example Setup with Adapters

As shown, the Test Environment allows for an arbitrary number of adapters and simulators that can be combined in different ways, so that nearly any setup can be achieved. Adapters can also be added at a later point in time, to extend a current setup. The adapter API is public and adapters can be written by our clients.


Features 5 / 17


2 Features

2.1 Test Sets, Definitions and Runs

The Test Environment is built around the following three main entities:

• Test Set A freely definable list of Test Definitions.

• Test Definition An actual test case. A test of a certain use case or functionality, consisting of a number of Steps. A Test Definition can be part of one or more Test Sets.

• Step An individual instruction or action that forms part of a Test Definition.

• Test Run Contains a number of executed Test Definitions and their result.

Test Sets, Test Definitions and Test Runs are represented by Xml files and reside in a local folder structure (s. 2.4 Test Libraries). Test Definitions can be written using a regular text editor or any other XML editor.

The GUI (s. 2.5) visualizes these entities.

More details on the data model can be found in chapter 3.1 Data Model.

2.2 Test Run Results

When executing a Test Set or Test Definition, the Test Environment will create a Test Run.

An execution status is stored for every Test Definition, down to the Step level. This status information can assume the following values:

• Inconclusive The Test Definition or Step has not yet been executed

• Successful The Test Definition or Step has been executed successfully

• Failed The Test Definition or Step has failed

2.3 Environment Definitions

To enable test automation, the Test Environment can be extended with so-called controllers and adapters. These are binaries that are loaded by the Test Environment and used during test execution (s. 2.8 Adapters).

To make use of such controllers and adapters, the Test Environment requires information about where the corresponding binaries reside and more.

This information is also stored as well-defined Xml files.

2.4 Test Libraries

The Test Environment supports the notion of Test Libraries. A Test Library is a folder on the file system that contains Test Sets and Test Definitions (s. 2.1 Test Sets, Definitions and Runs) and Environment Definitions (s. 2.3).

All Environment Definitions and Test Set of a Test Library must reside in the root folder of the Test Library. Other than that, the Test Library can have an arbitrary folder structure. Test Sets can be linked with any Test Definition in the structure by using the source attribute (s. 3.1.2 Test Set).


Features 6 / 17


When starting the Test Environment, a valid library must be chosen, so that the corresponding tests can be loaded.

Other kinds of libraries, such as an online repository or the integration with other test storage systems are in planning or currently being developed. Please contact your Abrantix representative for more information.

2.5 GUI

A graphical user interface visualizes Test Sets and Test Definitions and allows to group those into Test Runs. These can then be executed from the GUI and the current test status is visualized for the user. Automated tests will be executed without the need of a user present. Manual tests have to be performed step-by-step by the user (s. 2.6 Manual and Automated Testing).

After execution, a report can be generated (s. 0 Table 3: Available Abrantix Adapters

Log Data) and log output is visible in the GUI.

Refer to Appendix A - Screen shots (s. 5) for some screen shots.

2.6 Manual and Automated Testing

Test Environment supports manual and automated tests. Each test Step can either contain an instruction to be executed manually, or an automation instruction that can be executed automatically (s. 2.8 Adapters). A Test Definition can contain a mix of such Test Steps and therefore semi-automated Test Definitions are also possible.

2.7 Variables

Parametrization of test execution is done through variables, which can be referenced using the $(...) syntax from within the test Steps.

Variable values can be provided by the following contexts:

1. User settings

2. Environment Definitions (s. 2.3)

3. Test Definitions (s. 2.1 Test Sets, Definitions and Runs)

Variable resolution takes place during test execution, so that variables can be used to transfer information from one test Step to another. Test Environment will look for a variable value by traversing the numbered list above, starting at the highest number.

The GUI may ask the user for the value of a variable if it is not set during the time of execution.

2.8 Adapters

Test Environment can be extended with adapters to enable automated testing. A number of adapters already exist and can be used off-the-shelve (s. 2.8.1 Available Abrantix Adapters).

Each adapter implements the same .NET interface provided by Test Environment (s. 3.2 Adapters and Controllers). This enables the Test Environment to call the adapters during test execution. Test Steps (s. 2.1 Test Sets, Definitions and Runs) can contain one or more automation instruction, each targeted at a certain adapter. Once Test Environment reaches a test Step with an automation instruction, it will forward the instruction to the particular adapter.

Each adapter can freely define its own set of instructions. Test Environment will treat each instruction as a string and forward it unaltered to the adapter.

Figure 3 illustrates this concept with a simple example. There is a test with a number of Steps, each containing an automation instruction (shown in color). When executing this test, Test Environment will forward each instruction to the corresponding adapter (shown in same color as the instruction). The corresponding adapter will then execute this instruction. For example, in Step 2 the Robot Adapter is


Features 7 / 17


instructed to enter a PIN. This adapter will therefore send the corresponding command to the Abrantix EFT/POS Terminal Testing Robot.

After executing an instruction, the adapter will notify Test Environment about the outcome.

Figure 3: Adapters and Instructions

2.8.1 Available Abrantix Adapters

Adapter Description

Abrantix Pin Entry Machine Adapter

This adapter integrates the Test Environment with the Abrantix EFT/POS Terminal Testing Robot (s. 2.11 Hardware Extensions).

Using this adapter makes it possible to create test Steps that can press buttons on a terminal or insert/eject chip cards.

Abrantix Card Multiplexer Adapter

This adapter integrates the Test Environment with the Abrantix Card Multiplexer (s. 2.11 Hardware Extensions).

Using this adapter makes it possible to select different chip cards for each test.

Abrantix Magstripe Probe Adapter

This adapter integrates the Test Environment with the Abrantix EFT/POS Terminal Testing Robot (s. 2.11 Hardware Extensions).

Using this adapter makes it possible to simulate a magstripe swipe at the card reader with any track data.

Abrantix MDB Converter Adapter

This adapter integrates the Test Environment with the Abrantix MDB Converter (s. 2.11 Hardware Extensions).

Using this adapter makes it possible to simulate a vending machine.

UL Card Simulator Adapter

This adapter integrates the Test Environment with the UL Brand Test Tool.

Using this adapter makes it possible to select a certain card on the UL probe.

Table 3: Available Abrantix Adapters


Features 8 / 17


2.9 Log Data

Test Environment provides to option to display and store log data for each test Step in a Test Run. This log data can be displayed in the GUI in near real-time for each Step.

Log data is only available if the corresponding adapter (s. 2.8 Adapters) provides log data. The level of log data detail is also dependent on the adapter implementation.

2.10 Test Reports

A PDF report can be generated for each Test Run. The report will indicate the status of each Test

Definitions and Step within the Test Run.

The status can assume the following values:

• Inconclusive The Test Definition or Step has not yet been executed

• Successful The Test Definition or Step has been executed successfully

• Failed The Test Definition or Step has failed

2.11 Hardware Extensions

2.11.1 Abrantix EFT/POS Terminal Testing Robot

The Abrantix EFT/POS Terminal Testing Robot was purpose built to automat EFT/POS terminal testing. It can press the buttons of a terminal or a terminal screen and insert or eject chip cards. It also provides a mounting bracket for contactless probes to test contactless use cases.

The robot is fully integrated with the Test Environment through the corresponding adapter (s. 2.8.1 Available Abrantix Adapters). However, it can also be used without Test Environment through one of its interfaces. Please ask your Abrantix representative for more information.

Figure 4: Abrantix EFT/POS Terminal Testing Robot

2.11.2 Abrantix Card Multiplexer

The Abrantix Card Multiplexer was purpose built to automat EFT/POS terminal testing. It provides a chip card probe and a number of chip card slots that can hold actual EMV chip cards. The card multiplexer can be instructed as to which card slot shall be routed to the probe, therefore enabling the


Features 9 / 17


use of multiple chip cards on a single probe. This enables running tests without having to change the test card in the Abrantix EFT/POS Terminal Testing Robot (s. 2.11.1).

The card multiplexer is fully integrated with the Test Environment through the corresponding adapter (s. 2.8.1 Available Abrantix Adapters). However, it can also be used without Test Environment through one of its interfaces. Please ask your Abrantix representative for more information.

A contactless version of the card multiplexer is planned.

Figure 5: Abrantix Card Multiplexer (contact) - Housing of final product might differ from housing shown in image

2.11.3 Abrantix Magstripe Probe

The Abrantix Magstripe Probe was purpose built to automat EFT/POS terminal testing. It provides a simple interface that allows to swipe any track data through a magstripe card reader. However, the probe does not need to be moved for the swipe action, swiping will be emulated by moving the magnetic field on the stripe.

The magstripe probe is fully integrated with the Test Environment through the corresponding adapter (s. 2.8.1 Available Abrantix Adapters). However, it can also be used without Test Environment through one of its interfaces. Please ask your Abrantix representative for more information.

Figure 6: Abrantix Magstripe Probe


Architecture 10 / 17


3 Architecture

The Test Environment consists of multiple components. Figure 7 provides a high-level overview of the main components.

Figure 7: Architecture Overview

• The GUI (s. 2.5) visualizes Test Definitions and provides the ability to perform tests interactively.

• The Core is the main component and contains the business logic for the interpretation and execution of test definitions and test Steps.

• The Test Libraries (s. 2.4) are used to store Test Definitions and other necessary files. The test libraries are not part of the application as such, but need to be present with the correct structure and content for the Test Environment to work (s. 3.1 Data Model).

• Numerous Adapters (s. 2.8) can be used to enable test automation.

Test Environment is based on the .NET Framework and written in C# (s. 4 Hardware and Software Requirements).

3.1 Data Model

The following provides a high-level description of the main entities in the Xml data model as used in the Test Libraries (s. 2.4). The actual Xml data model is defined in a supplied Xml schema and a reference thereof can be found in [xmlref].

3.1.1 Test Definition and Steps

A Test Definition is represented by a well-defined Xml file and is identified by a unique, freely definable ID. It contains the necessary test Steps to perform a certain test procedure.

Each test Step consists of an instruction and either an automation action or a number of associated questions, which may answer pass or fail (for manual testing) (s. 2.6 Manual and Automated Testing).

3.1.2 Test Set

A Test Set is represented by a well-defined Xml file and is identified by a freely definable title.

Each Test Set consists of one or more sources, which refer to file system folders that contain Test Definitions (s. 2.4 Test Libraries).




Test Definitions from those sources are associated with a Test Set by defining so-called links. Each link contains the ID of the corresponding Test Definition.

3.1.3 Test Run

When choosing to execute a Test Set or Test Definition, Test Environment will create a Test Run. Like Test Sets and Test Definitions, a Test Run is also represented by one single Xml file.

This Xml file contains all Test Definitions that were executed, enriched with a status for each Test Definition and for each test Step (s. 2.10 Test Reports).

3.2 Adapters and Controllers

To enable the use of Adapters(s. 2.8), Test Environment uses Environment Definitions (s. 2.3). Each environment definition contains the necessary information to create and use an adapter.

To enable more granular control and handling of automation, Test Environment not only knows the adapter entity, it also uses the so-called controller entity.

Figure 8 illustrates these entities:

Figure 8: Adapters and Controllers

• Controller The controller can be used to create and control additional items used during testing. This could for example be a host simulator (s. 3.2.2 Adapter and Controller Example). Each environment definition can contain one or more controllers. When activating an environment, Test Environment will instruct the controllers to initialize and activate the items they control.

• Adapter An adapter provides the functionality required to execute test Steps for a certain automation target (e.g. an ECT simulator). Interaction with an adapter takes place at the beginning and the end of a test, and during test Step execution. Adapters are not directly associated with an environment definition. They form part of a controller. Each controller can have one or more adapters.

Adapters and controllers are represented by a specific Public API (s. 3.2.1).

It shall be noted that each environment runs in its own application domain.




3.2.1 Public API

Test Environment provides two public .NET interfaces that must be implemented to create controllers and adapters:

• IAutomationController Must be implemented to create a controller. Has methods such as Initialize, Activate, Deactivate.

• IAutomationAdapter Must be implemented to create an adapter. Has methods such as Execute, BeforeExecute, AfterExecute.

3.2.2 Adapter and Controller Example

Figure 9 shall illustrate an exemplary case in which the test setup requires an acquiring host simulator which is called by the terminal to authorize transactions. For some tests, it is required that the host simulator returns a certain authorization error.

This is achieved by defining an environment which contains the acquiring host simulator controller and an acquiring host simulator adapter.

When the controller is activated, it will start the actual acquiring host simulator. After this point in time, the simulator can be reached by the terminal for authorizations. The controller controls the lifetime of the host simulator and is responsible for the startup and shutdown of the simulator.

In addition to providing the authorization interface to the terminal, the host simulator also provides another API that allows setting a condition that will provoke a certain error for the next transaction. This API is used by the adapter. For the above-mentioned test, as one of the first test steps, the adapter will call the host simulator on this API and set the expected error condition.

When the test progresses to the actual authorization call by the terminal, the host simulator will return the expected error and the test can validate if the terminal behaved correctly.

Figure 9: Adapter and Controller Example




3.3 Terminal State Validation During Test

Much like manual tests, automated tests also need to observe and validate the terminal state during test execution. Like manual tests, automated tests are also built around an action / validation pattern:

1. Start transaction

2. Validate if terminal shows the amount and asks for a card

3. Enter card

4. Validate PIN entry screen is shown

5. Enter PIN

6. Validate terminal accepted the PIN

7. …

Therefore, there needs to be a way to define test Steps that can be used for this state validation. This is done by creating an adapter (s. 3.2 Adapters and Controllers) for this state validation. Such adapters are proprietary to the terminal application software.

Some terminal applications implement a rich ECR interface that provides all necessary data required for this state validation. In this case it would be advisable to write an ECR simulator and a corresponding adapter that can be used within Test Environment.

Other terminal applications provide log data that can be used for state validation. This data could be provided on the serial port of the terminal, over syslog or some other connection or format. In this case it would be advisable to write an adapter that accesses this log data to validate the terminal state.

There are many different ways to achieve this state validation and the flexibility of Test Environment should allow a solution for most scenarios. It shall however be noted that a minimum of data is required from the terminal to allow state validation so that automated testing can be implemented.


Hardware and Software Requirements 14 / 17


4 Hardware and Software Requirements

Test Environment is a Microsoft Windows application and is based on the Microsoft .NET Framework (version 4.7.2 or higher required).

The standard system requirements of .NET 4.7.2 apply (s. .NET Framework system requirements).

https://dotnet.microsoft.com/

https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirements


Appendix A - Screen shots 15 / 17


5 Appendix A - Screen shots

Figure 10: Test environment and adapters

Figure 11: Chose test environment




Figure 12: Trace view of executed test

Figure 13: Test steps wiht test results




Figure 14: Test library with test sets

abrantix test environment · languages, currencies and payment protocols (iso 8583, ifsf, ep2,...

Documents