Ross Systems International Ltd. home up ABOUT US SERVICES PRODUCTS CONTACT US NEWS

Passionate About Tandem

  Ross Systems International Limited

                    Tandem/HP NonStopTM Development & Test Solutions



Server Oriented Architecture is an amazingly flexible way of incorporating new services
into an IT system, enabling applications using it to become the best and most cost effective
of their type. There is however a downside to this evolutionary approach to IT systems and this is that there is a need for the fully automated testing of systems using SOA because
it is no longer practicable to spend 2 to 3 weeks testing an application which is to be implemented tomorrow.

The test scenarios for these applications should have the following properties:

  1. Each individual test must be repeated a large number of times.
  2. The test data should be variable and within statistically set bounds.
  3. The timings of transactions should be variable
  4. The scenarios to be done should depend on previous test results.
  5. The order in which the scenarios are done should be variable.
  6. The test system should be able to perform functional, performance and regression tests.
  7. The tests should be quick and simple to set up and alter
  8. It must be possible to pull into the test data and components from elsewhere
  9. It must be possible to capture data from existing systems for test replay

In short there is a requirement to alter the  test pace, content and sequence depending on a fixed schedule, results already received and random events in real time.

This implies a test language which can:

  1. Repeat tests, conditionally
  2. Branch through tests
  3. Set the interval at which individual test are done
  4. Alter test sets and individual tests in response to outside influences, for instance:
    a)    Tests already done
    b)    Responses received
    c)    Data base contents
    d)    Results from other server processes
    e)    Results from devices, e.g. security boxes
  5. Send messages without expecting replies, to handle very large messages
  6. Be automatically generated from running systems

All of this leads us to a system which has a:

  1. Fixed Part, and
  2. A Variable Part

The fixed component is easy to define:

  1. Repetition: do, while, until, loop
  2. Branching: if, then, else, endif
  3. Interval: pause
  4. Test Data: [ "Here is a record" ]
  5. Send data with and without replies: writeread, read
  6. Automatic generation: Use a spy process capture

The variable component is more difficult. Here is what to do:

  1. Records can can contain variable data this implies, will want to do:
    a)    Repetition
    b)    Branching
    c)    Inclusion of data from user hooks, i.e.
          <User Data> will go of to a user routine and collect the user data
    This has some interesting consequences:
    (i)     There will be a piece of stub code which can generate this data, and
    (ii)    This module can also receive the replies from transaction to modify any
            subsequent user data.
  2. The repetition, branching and interval determination must also be able to generate variable results, this again implies entry to the user hooks:
    a)    Repetition <do>, <while>, <until>, <loop>
    b)    Branching <if>, <then>, <else>, <endif>
    c)    Interval <pause>, <speed>
    This results in the user determining the exact meaning of these statements:
    (i)    <do 10> means of course do 10 times but it is also possible to write:
           <do anything> where the number of repeats is determined by the hook
    (ii)   <while not stable> could mean anything, here is the content dependant
           capability coming out
    (iii)  <if>... ther is no definition here, it just depends on the user
    (iv)   <pause 1000> means pause 1000 ticks, but it can be modified by the user
  3. The user is also informed of the end of a record ] or ]; so he can determine if a reply is required
  4. This has the result that there is a global linguistic component:    < text >
    This means enter a user hook, whether or not it is part of the language
    so you can make your own hooks:
    <set nnn> Presumably sets something a variable with a value perhaps?
    <abort>    Crashes all following hooks for a quick exit, maybe?
    <natural language - if this test has been going on too long stop it otherwise>
    <ask Steve what to do if he is available otherwise iterrogate \brains...> <pira>
    Hit the native english interpreter and keep on running until the <pira> hook is
    reached, n.b. <pira> is once again an user hook.

This division of the language into two parts enables:

  1. The quick generation of user hooks written in C in the user library USERLIB.C / USERLIB.H, which because of their primitive nature are very simple to generate, and are also re-useable. There is a small library of user hooks in existence which is constantly growing.
  2. The easy generation of top level scripts, which are enables by the User Hooks to perform very sophisticated testing for little effort, for example:
    <SET COUNT> 
    <PAUSE 50>
    <DO 1000>
    <IF RAND 4>
    <IF RAND 4>
    ["Hi 1 IN 4 - " <COUNT> " PLUS 1 = " <COUNT> ];
    <IF RAND 3>
    ["Hi 2 IN 4 - " <COUNT> " PLUS 1 = " <COUNT> ];
    <IF RAND 2>
    ["Hi 3 IN 4 - " <COUNT> " PLUS 1 = " <COUNT> ];
    <IF RAND 1>
    ["Hi 4 IN 4 - " <COUNT> " PLUS 1 = " <COUNT> ];
    <PAUSE 2000>
    ["Finish, total count = " <COUNT> ];

    Loops 50 times decrementing the delay between transactions from 50 ticks to 10 and performing a 1 of the four transactions in an equally distributed random manner, the transaction  themselves containing the counter value, which is being incremented, two times. A banal example I know, but one which shows quite how powerful the PIRA language is.
Contact: Tel: +44(0)1206-392923             Copyright 2006 Ross Systems International Ltd.