Browse Prior Art Database

Method to Create a Concurrency Execution Including Alternative Paths Modulated as Desired in Terms of Success and Error

IP.com Disclosure Number: IPCOM000246808D
Publication Date: 2016-Jul-01
Document File: 3 page(s) / 60K

Publishing Venue

The IP.com Prior Art Database

Abstract

Here is proposed is a method to generate software tests which represent a real customer workload. The method proposes single tests exploiting real data and also alternative execution paths. At run time, the workload will no more be composed from happy path executions simulating uniform user behaviors but also error, validation, alternative paths which will be part of it and therefore the system under analysis will be observed in more real conditions.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 01 of 3

Method to Create a Concurrency Execution Including Alternative Paths Modulated as Desired in Terms of Success and Error

    Concurrent software tests are usually executed on software applications through tools based on record / playback paradigm. Typically the user interaction flow is recorded then customized to run at the same time with multiple users, using data provided through a data pool. In this way, concurrency users workload is realized to stress the application and observe how the application reacts from resource usage and User Interface (UI) response time point of view.

    The problem with this approach is that the application can assume different behaviors, follow different paths depending from the data involved. Obviously if during the playback phase the data selected triggers a different behavior from the recorded one, the test will fail trying to go through a path that is not valid. This means that customer data can be difficulty used to realize a test workload, since those data will be the result of the interaction of different users acting at the some time in a different way with a multitude of different data. So what usually happens is that, to realize customer situation, data are cleaned up, or made uniform, of the same type, or the test recorded must be strongly edited to include alternative path evaluating the response received in specific requests when a given data is used. All this can only occur through an alternative recording and then manual merging or sniffing the single additional requests and then reproducing them in the main test. The drawback is that the process is really slow and error prone.

So here is disclosed a method to make easier to realize a customer typical workload with real data in test environment so to replicate exactly customer product usage.

    The recording phase can become something no more happening like a single instance. The record itself is a set having multiple instances that can come from multiple recordings done from the same user with different data or better from sniffing the behavior of multiple users at the same time. The best option is the recording module becoming something embedded into the product and sniffing the product user behavior in specific time window enabling a proxy through which all the requests go through. The sniffing phase produces recording sessions. These recording sessions are then uploaded in a collector managed by central workbench.

The key point is the analysis of the recording sessions just uploaded.

    If they have been created from a single user or even from multiple users having the same test to realize they are already divided in different sets: the users know at starting time which test they are recording and therefore, even if following different paths, the association with the set can already be done at the beginning (selected from the user).

    If the recording sessions are instead coming from sniffing customer product user behaviors, they preliminary nee...