SOFTWARE TESTING

Subject Code: SEE6B/ SAZ6C / SEU6G

Unit 3:  Data Flow Testing Strategies - Domain Testing:  Domains and Paths – Domains and Interface Testing.

INTRODUCTION: Transaction

Ø  A transaction is a unit of work seen from a system user's point of view.

Ø  A transaction consists of a sequence of operations, some of which are performed by a system, persons or devices that are outside of the system.

Ø  Transaction begins with Birth-that is they are created as a result of some external act.

Ø  At the conclusion of the transaction's processing, the transaction is no longer in the system.

Ø  Example of a transaction: A transaction for an online information retrieval system might consist of the following steps or tasks:

o   Accept input (tentative birth)

o   Validate input (birth)

o   Transmit acknowledgement to requester

o   Do input processing

o   Search file

o   Request directions from user

o   Accept input

o   Validate input

o   Process request

o   Update file

o   Transmit output

o   Record transaction in log and clean up (death)

TRANSACTION FLOW GRAPHS:

Ø  Transaction flows are introduced as a representation of a system's processing.

Ø  The methods that were applied to control flow graphs are then used for functional testing.

Ø  Transaction flows and transaction flow testing are to the independent system tester what control flows are path testing is to the programmer.

Ø  The transaction flow graph is to create a behavioral model of the program that leads to functional testing.

Ø  The transaction flowgraph is a model of the structure of the system's behavior (functionality).

Ø  An example of a Transaction Flow is as follows:

Ø  The user sees this scenario as a single transaction.

Ø  From the system’s point of view the transaction consists of many steps.

Ø  Best example is an Automatic Teller Machine (ATM)

Subject Code: SEE6B/ SAZ6C / SEU6G

Unit 3:  Data Flow Testing Strategies - Domain Testing:  Domains and Paths – Domains and Interface Testing.

DATA FLOW TESTING:

Ø  Data flow testing is the name given to a family of test strategies based on selecting paths through the program's control flow in order to explore sequences of events related to the status of data objects.

Ø  For example, pick enough paths to assure that every data object has been initialized prior to use or that all defined objects have been used for something.

Data Flow graphs

            The flow graph is a graph consisting of nodes and directed links. (i.e., links with arrows on them).

Data Object State and Usage:

Ø  Data Objects can be created, killed and used.

Ø  They can be used in two distinct ways: (1) In a Calculation (2) As a part of a Control Flow Predicate.

o   The following symbols denote these possibilities:

ü  Defined: d - defined, created, initialized, etc

ü  Killed or undefined: k - killed, undefined, released, removed, etc

ü  Usage: u - used for something

c - used in Calculations,

p - used in a predicate (e.g., if-the-else, do while, case)

    1. Defined (d):

Ø  An object is defined explicitly when it appears in a data declaration.

Ø  Or implicitly when it appears on the left hand side of the assignment.

Ø  It is also to be used to mean that a file has been opened.

Ø  A dynamically allocated object has been allocated.

Ø  Something is pushed on to the stack.

Ø  A record written.

    2. Killed or Undefined (k):

Ø  An object is killed on undefined when it is released or otherwise made unavailable.

Ø  Release of dynamically allocated objects back to the availability pool.

Ø  Return of records.

Ø  The old top of the stack after it is popped.

Ø  An assignment statement can kill and redefine immediately. For example, if A had been previously defined and we do a new assignment such as A : = 17, we have killed A's previous value and redefined A

    3. Usage (u): used for something.

Ø  A variable is used for computation (c) when it appears on the right hand side of an assignment statement, as a pointer, as part of a pointer calculation; a file record is read or written, and so on.

Ø  It is used in a Predicate (p) when it appears directly in a predicate.

Ø  The p used in control variable of loop, in an expression used to evaluate the control flow of a case statement, as pointer to an object.

DATA FLOW ANOMALIES:

Ø  An anomaly is denoted by a two-character sequence of actions.

Ø  For example, ku means that the object is killed and then used,

Ø  Whereas dd means that the object is defined twice without an intervening usage.

Ø  What is an anomaly is depend on the application.

Ø  There are nine possible two-letter combinations for d, k and u. some are bugs, some are suspicious, and some are okay.

      dd :- probably harmless but suspicious. Why define the object twice without an intervening usage?

      dk :- probably a bug. Why define the object without using it?

      du :- the normal case. The object is defined and then used.

      kd :- normal situation. An object is killed and then redefined.

      kk :- harmless but probably buggy. Did you want to be sure it was really killed?

      ku :- a bug. The object does not exist.

      ud :- usually not a bug because the language permits reassignment at almost any time.

      uk :- normal situation.

      uu :- normal situation.

STRATEGIES OF DATA FLOW TESTING:

1.      General:

Ø  Data Flow Strategy testing are structural strategies.

Ø  While path testing strategies focus on execution of every statement and branch atleast, data flow strategies focus on transformation of data objects.

Ø  In order to facilitate this in Data flow testing.

Ø  We label Data flow links with weights that represent the state of Data objects by using d (defined); k ( killed); u ( used ) – either for c ( calculation ) or p (used in a predicate).

Ø  Data Flow Testing Strategies are based on selecting test path segments (also called sub paths) that satisfy some characteristic of data flows for all data objects.

Ø  For example, all sub paths that contain a d (or u, k, du, dk).

Ø  For example, if you are interested in understanding the state of Data objects when d (defined) action takes place then we need to select sub-paths that contain a d.

2.      Terminology:

We will assume for the moment that all paths are achievable.

ü  A Definition –clear path segment: If a variable is defined on the first link and not redefined and killed on any subsequent link of a path segments then that path segments is termed as a clear path segment.

o   In Figure 3.10, we have complicated situation. The following path segments are definition-clear: (1,3,4), (1,3,5), (5,6,7,4), (7,8,9,6,7), (7,8,9,10), (7,8,10), (7,8,10,11).

o   Subpath (1,3,4,5) is not definition-clear because the variables defined on (1,3) and again on (4,5).

ü  A loop - free path segment: If in a path segments every node is visited at most once, then that path segment is termed as loop – free path segment

o   Path (4,5,6,7,8,10) in Figure 3.10 is loop free, but path (10,11,4,5,6,7,8,10,11,12) is not because nodes 10 and 11 are each visited twice.

ü  A Simple path segment: In a path segment at most one node is visited twice then it is a Simple path segment.

o   In Figure 3.10 path (7,4,5,6,7) is a simple path segment.

o   A simple path segment is either loop-free or if there is a loop, only one node is involved.

ü  A du path: (defined used) In a path segment if the variable is defined earlier and the last link has a computational use of that variable then that path is termed as a du path, then the path is simple and definition-clear;

3.      Test Strategies

ü  Data flow test strategies focus on impact of definition and computational use of variable.

ü  It may also consider only segment of path to check the state of the data objects in that path segments.

ü  In order to carry out data flow testing following are test strategies with varying strength:

All- du- path (ADUP) strategy:

ü  This is the strongest data flow testing strategy.

ü  This strategy requires that every du path that is possible from every definition of every variable and also every use of that definition shall be exercised under some test.

ü  The definition on link (1,3) we must exercise paths that include subpaths (1,3,4) and (1,3,5)

ü  The definition on link (4, 5) is covered by any path that includes (5, 6) such as subpath (1,3,4,5,6,….)

ü  The all-du-paths strategy for this variable requires that we exercise all loop-free entry/exit paths and at least one path that includes the loop cased by (11, 4).

ü  The all-du-paths strategy is a strong criterion, but it does not take as many tests as it might seem at first because any one test simultaneously satisfies the criterion for several definitions and uses of several different variables.

All-uses (AU) strategy:

ü  Our ambitions by stepping down from all paths (P∞) to branch coverage (P2).

ü  The test set include at least one path segment from every definition to every use that can be reached by that definition this is called all-uses (AU) strategy.

ü  This strategy is that at least one definition-clear path from every definition of every variable to every use of that definition be exercised under some test.

ü  In Figure 3.11, ADUP requires that we include subpaths (3,4,5) and (3,5) in some test because subsequent uses on link (5,6) can be reached by either alternatives.

All-p-Uses/Some-c-Uses (APU+C) and All-c-Uses/Some-p-Uses (ACU+P) strategy:

ü  These are weaker test criteria.

ü  The all-p-uses/ some-c-uses(APU+C) strategy is defined as follows: for every variable and every definition to every predicate use; if there are definitions of the variable that are not covered by the above prescription, then add computational-use test cases as required to cover every definition.

ü  The all-c-uses/some-p-uses(ACU+P) strategy reverses the bias: first ensure coverage by computational-use cases and if any definition is not covered by the previously selected paths, add such predicate-use cases as are needed to assure that every definition is included in some test.

All -Definitions (AD) strategy:

ü  The all-definitions (AD) strategy requires every definition of every variable be covered by at least one use of that variable and that use can be either computational use or predicate use.

All-Predicate-Uses (APU), All –Computational Uses (ACU) strategy:

ü  The all-predicate-uses (APU) strategy is derived from the APU+C strategy by dropping the requirement that we include a c-use for the variable if there’re are no p-uses for the variable if there are no p-uses for the variable following definition.

ü  The all-computational-use (ACU) strategy is derived from ACU+P by dropping the requirement that we include a p-use if there are no c-use instances following a definition.

ORDERING THE STRATEGIES:

ü  Figure 3.12 compares path-flow and data-flow testing strategies. The arrows denote that the strategy at the arrow's tail is stronger than the strategy at the arrow's head.

ü  The right-hand side of this graph, along the path from "all paths" to "all statements" is the more interesting hierarchy for practical applications.

ü  Note that although ACU+P is stronger than ACU, both are incomparable to the predicate-biased strategies. Note also that "all definitions" is not comparable to ACU or APU.