BP-Source: Test scripting concepts

 

1. Introduction

In this article we'll cover basic script testing concept using the BP-Source module. We'll also show these scripts applied on couple examples and pin point some interesting ways how to use BP-Source test script feature for simulating near-real transaction flow.

As the first thing, please note that it is recommended to read our fore-coming tutorials about Basic testing concepts and Load testing for better understanding of topics covered below. Some terminology used in this article might be confusing without having knowledge of preceding guides. 

Test script feature was developed having in mind a complexity of some test scenarios and also with the aim to serve as a regression tool while challenging current switch's configuration and functionality again and again. Purpose of these scripts is to modify s single transaction from all aspects as field's value, card, currency codes and also report and validate response received in reaction on script execution. Another development focus was to provide very easy scripting language which would be easily digestible by any tester having at least the elementary knowledge of payment industry and processing logic.

2. Coding rules and syntax used

Before getting some examples we need to make a brief excursion into a technology behind. BP-Source's test scripts adhere to XML syntax, but not all rules are sacrificed in a way providing a tester with comfortable and understandable written form.

Even there are more rules mentioned in the BP-Sim user guide, I would upfront following three. The first rule states what whichever new line in a script starts with '<' sign is ignored as garbage or comments. Only one exclusion applies for '<!' which marks a comment, following the XML standard to certain point.

Another rule states that there can be only one command (or expression) per line, while there are two ways how to frame value we want to pass to the application. The first one, again, follows XML standard - framing a value with leading <tag> and trailing </tag>. But BP-Source also supports a simplified syntax, where providing a tag in a form <tag/> means that all the rest of the line is tag's value.

Third and the last rule mentioned here says that whole test script needs to be nested in between tags <TestScript> and it's trailing equivalent </TestScript>. All surrounding data will be considered as garbage, even having any otherwise understandable logic. Note that both tags needs to be on separate lines and are mandatory for test script run. Test script parser will fail on not finding those and will stop script's initial loading.

3. Script's header

Now we are getting to the scripts layout and logic behind it. BP-Source script is divided into two main parts; The Header and Steps parts. Header contains information about the script itself as its name <TSName> and transaction format <TrxFormat>. Both tags are mandatory and script parser will fail when not found. Header part can also contain some optional tags as test description <TSDesc>, starting step definition <StartingStep> and value limiting total transactions to be carried <MaxTrx>. All these fields and their acceptable values are covered in BP-Sim User guide, so their detailed description is outside of scope of this tutorial. Just note that when <StartingStep> tag not used, application will use default value of 1.

4. Script's steps

Second part of the script is so called "Steps" part. Here you define processing steps where each step stays for one transaction. As the header part, steps part also divides into it's sub parts. These are addressed as Processing directives, Message overloading and Response validators. Let's cover those in more detail.

Processing directives are telling application general information about the step as its <ID> (mandatory), <ResponseWait> (optional), <GoTo> (conditional) and <CardByPan>. Tag <ID> links steps in between and can be referenced by tags <StartingStep> and <GoTo>. <ResponseWait> tag states message time-out and <GoTo> next step to be loaded. BP-Source considers end of the script logic, when no value provided for <GoTo> or tag missing. Finally the tag <CardByPan> will state a card to be user for the script processing. Note that BP-Source will try to locate card's configuration in database first and will halt further processing when not found.

Message overloading values are usually format specific tags used for setting step's profile and its overloading values. Profile itself can be set with <Profile> tag and have to match transaction profile already configured in database. All the rest of tags are format specific and tag names described in particular section in the user guide should be used. Just for example format used for all ISO8583 based transactions tags starts with <DE_ and data element number, while any other subfield is separated with additional underscore sign '_'. Field 48.16 would be in this case referenced as <DE_48_16>. Similar logic applies for other formats.

Third part in the Steps section contains response validators and tags are formated in the same way as those for Message overloading, but each tag name have to be preceded by 'Rsp' abbreviation to signalize its section origin to BP-Source. These validators have two functions: comparable and printable. Print function can be called by question mark sign '?' and signalizes to BP-Source printing the content of the field into the output report. So having <RspDE_39/>? will result into row "DE_039    :[000]" stating that received response core value was '000' in the final report. It may also state "DE_039    :N/A - Failed", when field missing.

Second validator option is stating an expected value of the response field. In this case the BP-Source will proceed with field comparison and final result will contain Passed/Failed resolution with both values echoed. Tying up on previous example our current syntax would now say <RspDE_041/>80000001 and report would have result as "DE_041    :[80000001]|[80000001] - Passed" or something like "DE_041    :[80000001]|[ZZZZZZZZ] - Failed". Note that Pass/Failed results for each validation are base for script's final statistics where all these will be counted forming a test's overall result being Failed anytime at least one of the previous validation checks didn't succeed.

5. Reporting

Now when we have scripting logic covered, lets focus at test script results in a few words. Each test script will produce a test script report, being lodged in BP-Sim under navigator tag "Test reports" having its name preceded by date-time stamp in a format YYYYMMDD_hhmmss_<TSName>. Content of the report has a header with generic information about the test, step's processing details and a trailer with brief test statistics and overall result.

Just as a hit to the topic covered in paragraphs above, using this logic can be used for further processing and running a command '$ find -name "*.log" -exec grep Failed {} +' in <BP installation folder>/reports will result into a very handy log over all test results lodged there and their details as per below:

./20120821_211657_Apacs30 script 1.log:Date                        :[9802]|[1208] - Failed
./20120821_211657_Apacs30 script 1.log:Message Number              :[0]|[0003] - Failed
./20120821_211657_Apacs30 script 1.log:Response Code               :[91]|[00] - Failed
./20120821_211657_Apacs30 script 1.log:Test overall result:    Failed
./20120916_014701_Iso8583 R93 script 2.log:DE_035    :N/A - Failed
./20120916_014701_Iso8583 R93 script 2.log:DE_049    :[978]|[826] - Failed
./20120916_014701_Iso8583 R93 script 2.log:Test overall result:    Failed

6. Elementary example

Let's show all above on some examples and unleash the BP-Source scripting power. The first example is elementary and just overviews scripting options already covered by this tutorial. Let's have a simple ISO8583 transaction and overload it's currency value.

<TestScript>
<!--File header -->
<TSName/>Iso8583 R87 - currency overload script
<TSDesc/>This script will send a transaction in GBP
<TrxFormat/>Iso8583-1987
<StartingStep/>1
 
<!-- Step 1 -->
<Step>
<ID/>1
<Profile/>Authorisation request
<DE_49/>826
<!-- Response validation -->
<RspDE_39/>00 
</Step>
 
</TestScript>

The script above takes the "Authorisation request" profile from "Iso8583-1987" format and overloads its currency field with value of a British Pound - 826. All the other fields and message structure is given based on current BP-Source configuration which will determine values for STAN, card, terminal, MAC etc.. This script will also test the response code field DE39 on value '00' - approved. Test report for this script will read like below:

Script's name:         Iso8583 R87 - currency overload script
Script's description:     This script will send a transaction in GBP
Transaction format:     Iso8583-1987
Report created:     2012/11/08 03:10:48
*********************************************************
[2012-11-08 03:10:48.951891]
Step Id:        1
DE_039    :[00]|[00] - Passed
---------------------------------------------------------
---------------------------------------------------------
Test finished:         2012/11/08 03:10:48
Nr. of tests failed:    0
Nr. of tests passed:    0
*********************************************************
Test overall result:    Passed

7. Introducing <GoTo> tag

Extending the same script with another step we'll get a scenario for testing several currencies. Notice usage of the tag <GoTo> directing BP-Source to follow up with step 2, when step 1 is done.

<TestScript>
<!--File header -->
<TSName/>Iso8583 R87 - currency overload script 2
<TSDesc/>This script will send a transaction in GBP and second in EUR
<TrxFormat/>Iso8583-1987
<StartingStep/>1
 
<!-- Step 1 -->
<Step>
<ID/>1
<Profile/>Authorisation request
<DE_49/>826
<RspDE_39/>00
<GoTo/>2
</Step>

<!-- Step 2 -->
<Step>
<ID/>2
<Profile/>Authorisation request
<DE_49/>978
 <RspDE_39/>00
</Step>
 
</TestScript>


As a last thing we will provide you with couple practical hints from our clients. Using the <GoTo/> tag in the last step of your test script and referring the first step again you can also create infinite loop script. With all information covered above you should be also able writing several scripts having your systems typical transaction logic covered (balance inquiry, payment, payment reversal, terminal logon) and assigning them to several terminals at one time. Running the BP-Source in a Test Script mode will now generate very rich transaction feed, which may simulate a real production traffic and is much more suitable for system benchmarking than simple authorization feed.

8. Summary

We did reach the end of this tutorial. At this stage you should be able to understand basic concept of BP-Source's scripting feature as well having a good background for writting a new one. There are almost unlimited options given by this feature and please note that our team is always ready to assist you with your development.

BP-Tools

BP-Tools is a set of freeware applications for EFT testing, benchmarking and transaction service development.

See more...

Download...

Download Flyer...

BP-Sim

The Babylon Payments Simulator (BP-Sim) is a family of highly efficient regression and stress testing tools, designed for deployment in development and pre-production environments. BP-Sim allows users to perform an extensive range of tests across the chain of payment services.

See more...

Download Flyer...

BP-Processing

The Babylon Payments Processing Suite(BP-Processing) is a suite of EFTlab's products for realtime payment transaction processing and authorisation.

See more...