Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
Abrantix Test Environment – Product Description
Overview 3 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
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
Abrantix Test Environment – Product Description
Overview 4 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
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
Abrantix Test Environment – Product Description
Features 5 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
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))
Abrantix Test Environment – Product Description
Features 6 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
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
Abrantix Test Environment – Product Description
Features 7 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
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
Abrantix Test Environment – Product Description
Features 8 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
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)
Abrantix Test Environment – Product Description
Features 9 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
Figure 3: Picture of the Card and PIN Robot
Abrantix Test Environment – Product Description
Architecture 10 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
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.
Abrantix Test Environment – Product Description
Architecture 11 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
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.
Abrantix Test Environment – Product Description
Appendix A - Screen shots 12 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
4 Appendix A - Screen shots
Figure 5: Test environment and its adapters
Figure 6: Chose you test environment
Abrantix Test Environment – Product Description
Appendix A - Screen shots 13 / 14
© 2016 Abrantix AG Version 1.0 / 13. April 2016
Figure 7: TraceView of executed tests
Figure 8: Test steps wiht test results