Abrantix Test Environment

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

www.abrantix.com, [email protected]

Abrantix Test Environment

Product Description

Version: 1.0 / 13. April 2016

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 cash register integrations and other external interfaces. Since we support many different languages, currencies and payment protocols (ISO 8583, IFSF, ep2, etc.) testing becomes very complex and the number of test cases only ever increases.

We have focused quite early on a good quality and good quality assurance processes. Especially because the EFT environment proves to be a very heterogeneous environment consisting of different cash registers, acquirers, payment protocols, host configurations and terminals themselves. With this many different surrounding and configurations, EFT terminal testing is a really difficult task.

With this in mind we have developed an extensive testing environment that allows the complete testing of payment applications on different levels in fully automated fashion. The test environment has a rich user interface and contains several simulators and a card and PIN robot, which allows to fully automate all test cases. Test cases are stored in a repository that is shared amongst all team members. The user interface is the main point of interaction where test runs can be created, orchestrated and executed.

Test cases can be written as in XML and can be grouped into test sets. All test cases are stored in the repository and are therefore accessible by all test-team members. Therefore, every test case has to be written only once and can be used by every team member. This facilitates the creation of large test sets massively.

The test environment has a modular setup and every component can be used as a stand-alone application or it can be integrated with other components into a tailor made test environment. This makes the test environment highly flexible and it can serve all testing requirements.

A built-in reporting module allows you to print complete test report and test results

Abrantix Test Environment – Product Description

Overview 2 / 14

© 2016 Abrantix AG Version 1.0 / 13. April 2016

Table of contents

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

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

2.1 User Interface .......................................................................................................................... 5 2.2 Simulator Adapters .................................................................................................................. 5 2.3 Execution Environments .......................................................................................................... 5 2.4 Test Sets, Cases and Steps .................................................................................................... 6

2.4.1 Test Definition .................................................................................................................. 6 2.4.2 Test Set ........................................................................................................................... 6 2.4.3 Environment ..................................................................................................................... 6

2.5 Journal: Logging and Reporting .............................................................................................. 7 2.6 TMAX ....................................................................................................................................... 7 2.7 Repository ................................................................................................................................ 7 2.8 Card and PIN Robot ................................................................................................................ 8

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

3.1 Application Core .................................................................................................................... 10 3.2 Test Cases and Test Sets ..................................................................................................... 10 3.3 Data model ............................................................................................................................ 11

4 Appendix A - Screen shots ........................................................................................................ 12


Overview 3 / 14


Table of figures

Figure 1: Abrantix Test Environment Overview ....................................................................................... 4 Figure 2, TMAX Architecture ................................................................................................................... 7 Figure 3: Picture of the Card and PIN Robot........................................................................................... 9 Figure 4: Test Environment Architecture ............................................................................................... 10 Figure 5: Test environment and its adapters ......................................................................................... 12 Figure 6: Chose you test environment .................................................................................................. 12 Figure 7: TraceView of executed tests .................................................................................................. 13 Figure 8: Test steps wiht test results ..................................................................................................... 13 Figure 9: Test library with test sets ........................................................................................................ 14

Tables

Table 1: Definitions and abbreviations .................................................................................................... 3

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

IFSF International forecourt standards forum

ep2 EFTPOS 2000

ISO 8583 Standard for Financial Transaction Card Originated Messages – Interchange message specifications

PIN Personal identification number

EFT/POS Electronic Funds Transfer / Point of sale

APDU Application Protocol Data Unit

HAL hardware abstraction layer

ECR Electronic cash register

Table 1: Definitions and abbreviations


Overview 4 / 14


1 Overview

In a complete EFT test environment, you not only need a correct functioning EFT/POS terminal, you also need the proper test cards, the corresponding terminal configuration, the host environment, payment protocol and cash register version to execute your testing. This is very difficult to achieve since all surrounding environments also have release cycles, which makes testing even more difficult.

The Abrantix Test Environment contains many different components, all designed to facilitate testing activities in an EFT environment. There are multiple simulators for external systems, a PIN entry robot and other components. The modular architecture of the Test Environment allows to combine these components to your desire, to create the test environment that fits your requirements. You can also extend your test environment with additional components at a later stage to fully customize the test environment to your needs.

The Test Environment contains the following Simulator Adapters (s. 2.2):

Card simulation (Magstripe)

Cash register simulation

Petrol station simulation

Host simulation

Terminal simulation

Other simulators can be added on request.

Terminal

UI

ECR Simulator

Repository

Card Simlator

Host SimulatorTMAX

Figure 1: Abrantix Test Environment Overview


Features 5 / 14


2 Features

2.1 User Interface

A graphical user interface allows you to select test cases and group them into test runs. You can also execute and start test runs, generate reports, view the log output and check test results.

Refer to chapter 4 Appendix A - Screen shots to get a visual impression of the Test Environments UI.

2.2 Simulator Adapters

Card simulator (Magstripe)

The card simulator allows to simulate magnetic stripe (magstripe) cards. This card data will be automatically feed into the terminal or transaction.

Cash register simulator

The cash register simulator allows to simulate a cash register application. This is used to start a transaction on the terminal. The cash register simulator allows you to initiate terminal functions like payment, reversal, credit, tip, end of day processing, receipt printing, trigger initialization and terminal configuration. The functionality of the simulator is usually depending of the functionality of the terminal and its payment protocol.

Petrol station simulator

The petrol station simulator allows you to simulate the pump behavior on a petrol station. It starts a preauthorization for a certain amount, waits a random time and captures a random amount below the preauthorization amount. This simulates the fueling process. It also handles all functionality around a petrol ECR system. It is basically a cash register simulator with the special petrol use case (fueling).

Host simulator

The host simulator simulates the acquirer host. It implements the full functionality of the payment protocol (ep2, ISO8583, IFSF, etc.). The behavior of the host simulation can be controlled by the test definition. For example you can define, that the host answers with “pin wrong” on certain conditions.

Terminal simulator

The terminal simulator simulates the full functionality of a payment terminal. It implements all features of the given payment protocol.

All simulators allow to load reference configurations that determine their behavior, so you can adjust the Test Environment to your needs.

2.3 Execution Environments

The Test Environment allows you to configure several test execution environments. These environments can be configured to your requirements depending on what you want to test. They also allow you to use the Test Environment for application development, quality assurance and certification. A test execution environment consists of the relevant components for the test run:

EFT/POS terminal with the loaded software version (test target)

Host, acquiring system (simulation or real system)

Cards (simulation or physical cards)

Cash register (simulation or real cash register (ECR))


Features 6 / 14


In the beginning of the development cycle you typically use simulators for all components. These

simulators can successively be replaced with real systems for quality assurance. For certification you

usually use only a cash register simulation, all other parts will be real systems.

2.4 Test Sets, Cases and Steps

Tests are divided and split into sets, according to the categories. Every Test set contains certain number of tests and tries to cover the field of testing properly. At the end, every test is divided into steps. Steps can be fully or semi-automated, they may however require human interaction.

There are many test sets already available, which cover the EMV, EP2/IFSF (terminal and host side) field, as well as basic terminal tasks like software download, terminal setup, etc...

The following elements exist:

2.4.1 Test Definition

This very important entity, represented by an XML file describes the steps necessary to perform a certain test procedure. Each step has an instruction and a number of associated questions, which may answer pass or fail.

A test definition can readily be transformed into a HTML screen or a PDF document.

For simplicity, the test definition can also accommodate results of test execution, namely the status attribute that captures the outcome of individual steps as well as the test itself.

Consequently, a test report is generated, enriched by the result attributes.

test-definition Element

plan Element

The plan is an ordered collection of test steps.

step Element

Describes a single test step; for simplicity element are provided to also capture the results of test execution.

automation Element

Automation elements describe adapter related commands associated with a test step. Each automation element is targeted to a particular adapter.

question Element

Question elements may be present to request confirmation from the user or automation adapters.

2.4.2 Test Set

A test set is a container for test definitions, possibly enriched by results. The set can act as a test plan, specifying a particular list and order of tests. It can also be used to capture the current status of a test run. A test plan is simply a test run with all result elements removed.

test-set Element

test-container Element

link Element

2.4.3 Environment

The environment definition describes a set of processes, services and associated adapters. Additionally it may define variables that can be referenced by test definitions.

environment Element


Features 7 / 14


The environment element describes a particular configuration of test targets, which may be simulators or deliverables, processes or services. Parametrization is done through use of variables and macro-substitution.

process Element

adapter Element

The adapter element defines an external object which is implemented as a DLL or that runs in a separate process.

2.5 Journal: Logging and Reporting

All interactions of the components can be recorded and logged. The simulators provide the

corresponding data sources. Every test run will be logged and saved so that it can be used for later

analysis and reporting. The logging is very extensive. It includes all data that is submitted by the

interfaces (APDU, Network, HAL, etc.) as well as information derived from the application level like the

decoding of cryptograms and coded data elements, error- and warning messages.

During the test run a test protocol will be displayed so the user always knows which tests already have

passed. The test protocol will be saved in XML format and can be converted into HTML or PDF

Reports through the User Interface (s. 2.1).

2.6 TMAX

To make best use of the test framework we have developed a component that can be integrated into the existing EFT/POS terminal. It is designed to automate steps in the terminal and collect trace data, which can be parsed in the test environment.

TMAX is a terminal framework interface, which enables the functionality of the device in the context of development and quality assurance process. The interface is very simple and application specific, based on TCP/IP and XML. It is currently used to support the following tasks:

Terminal automation of the EMV certification process.

A basic ECR interface

Test of automation process

Trace interface

The interface can be accessed through raw socket connection or HTTP requests. Each message is represented by a well formed XML document, encoded in UTF-8.

Test Environment Application Core

SIM A

SIM C

SIM B

TMAX

Terminal Application

TMAX

Automation Interface

Trace Interface

Figure 2, TMAX Architecture

2.7 Repository

The common repository, based on a Microsoft SQL database, serves as a distribution point for all the testing process related items. The repository supports the development and distribution of test definitions, their packaging and publication as test sets. The repository can also be used as primary


Features 8 / 14


storage of test definitions, but we recommend to use a conventional source control system for this purpose.

2.8 Card and PIN Robot

We especially developed a robot that allows to insert, swipe or wave cards and enter the PIN automatically. The robot can be fully integrated into to the Test Environment. The robot can be fully remote controlled through an interface. Therefore the robot can also be used without the Test Environment, if you want to write your own drivers for the robot.

Technical description of the robot:

Smoothieboard (CNC controller board)

Open source, HW and Software

Fully adjustable

Connectivity over LAN or Serial

G code compatibility

Fast, reliable, there is a big community

Pin Entry Machine

Made out of strong but light aluminum

Suitable for any type of terminal

Testing of contact and contactless as well as keyboard manipulation

Possible further extensions and enhancements (use of multiple cards, contact and contactless)


Features 9 / 14


Figure 3: Picture of the Card and PIN Robot


Architecture 10 / 14


3 Architecture

The Test Environment consists of several components.

XML

Application Core

Terminal

User Interface

SIM A

Repo

SIM C

SIM B

File StoreSQL

Figure 4: Test Environment Architecture

The Application Core (s. 3.1) is the main component and contains the business logic for the interpretation and execution of test definitions and test cases.

The User Interface provides the ability to perform tests interactively.

The Repository is used to store test and environment definitions and execution results.

Numerous Simulators form the basis for a specific test setup.

XML Files hold the configuration of the system and test sets and cases.

The software is based on the .NET Framework and written in C#.

3.1 Application Core

The Application Core combined with the simulators form the core of the test environment. The Application Core can either run as a service or it can be embedded into an existing application. Operated in service mode, the Application Core can handle several user session if this is supported by the simulators.

After starting the system with an appropriate configuration and simulators, the system will represent a server with all the supported payment interfaces. In idle mode the systems behaves like a regular host environment. By starting a test case you can send the simulator instruction on how to behave, to provoke a certain behavior. After the test execution the system will go back to its idle mode.

3.2 Test Cases and Test Sets

The Test Environment works on XML based test definitions. Each test definition contains a title, the execution conditions and several test steps. Each test step contains instructions for the test execution as well as instructions for the involved simulators.

Test cases can be created with a regular text editor or any other XML editor. The supplied XML schema facilitates the creation of the test cases.


Architecture 11 / 14


Instruction for the simulators are embedded into the test definitions. Every simulator offers its own XML control language based on the functions offered. An XML schema is also provided for each simulator.

In the definition of the simulation steps you can define if simulation is optional. This allows you to use the same test definition with or without simulation.

The test definition are usually stored in a source control system such as Microsoft TFS or GIT. The XML sources can either be executed directly from the file system (development) or loaded into the repository to give access of the test definition to other test team members.

3.3 Data model

The data model of the Test Environment includes the following main entities:

The Environment Definition contains information on simulators and network services which are used in the context of the environment. This includes, for example, the ports on which simulators listen.

Test Cases contain a number of Test Steps that form one single test definition

A Test Set combines multiple test cases in a hierarchical structure (several folders possible) together.

A Test Session represents a single test run and contains a number of tests sets that belong to this test run.

The Test Result of a test session includes the executed test cases, the test result and its log data.

The data structure is designed so that each test case can be addressed through an URL. Any folder structure, even sub folders are allowed.


Appendix A - Screen shots 12 / 14


4 Appendix A - Screen shots

Figure 5: Test environment and its adapters

Figure 6: Chose you test environment




Figure 7: TraceView of executed tests

Figure 8: Test steps wiht test results




Figure 9: Test library with test sets

Abrantix Test Environment

Documents

Transcript of Abrantix Test Environment