Software Testing - Cheatsheet

  05BC1502 - Software Testing

UNIT 1         UNIT 2

------------------------------------------------------------------------------------------------------------------

UNIT : 2

------------------------------------------------------------------------------------------------------------------

Dynamic Testing           Static techniques

------------------------------------------------------------------------------------------------------------------

Black-Box Testing Techniques / functional testing

------------------------------------------------------------------------------------------------------------------

- This technique considers only the functional requirements of the software or module.

-----------------------------------------------------------------------------------

Boundary Value Analysis (BVA):

- A Black-Box testing technique used to check the errors at the boundaries of an input domain.

1.1 Boundary Value Checking :

- Test cases are designed by holding one variable at its extreme value and other variables at their nominal values in the input domain.

(a) Minimum value (Min) 

(b) Value just above the minimum value (Min+ ) 

(c) Maximum value (Max) 

(d) Value just below the maximum value (Max−)

1.2 Robustness Testing Method :

- The idea of BVC can be extended such that boundary values are exceeded as: 

(6n + 1) (6*2 + 1) 

A value just greater than the Maximum value (Max+) 

A value just less than Minimum value (Min−)

1.3 Worst-case testing method :

- We can again extend the concept of BVC by assuming more than one variable on the boundary

-----------------------------------------------------------------------------------

Equivalence Class Testing

-Equivalence partitioning is a method for deriving test cases wherein classes of input conditions called equivalence classes

-It means only one test case in the equivalence class will be sufficient to find errors

For designing test cases has the following goals :

1) Completeness :we strive to touch the completeness of testing domain

2) Non-redundancy : When the test cases are executed having inputs from the same class, then there is redundancy in executing the test cases.

One needs to perform two steps:

STEP-1 : IDENTIFICATION OF EQUIVALENT CLASSES

Different equivalence classes are formed by grouping inputs for which the behavior pattern of the module is similar

I) Valid equivalence classes

II) Invalid equivalence classes

STEP-2 : IDENTIFYING TEST CASES:
Assign a unique identification number to each equivalence class

-----------------------------------------------------------------------------------

State Table Based Testing

1. FINITE STATE MACHINE (FSM)

-An FSM is a behavioral model whose outcome depends upon both previous and current inputs.

2. STATE TRANSITION DIAGRAMS OR STATE GRAPH
    1. New State: When a task is newly created. 

    2. Ready: When the task is waiting in the ready queue for its turn. 

    3. Running: When instructions of the task are being executed by CPU. 

    4. Waiting: When the task is waiting for an I/O event or reception of a signal. 

    5. Terminated: The task has finished execution.

3 STATE TABLE

-state graphs are converted into tabular form for convenience sake, which are known as state tables.

-State tables also specify states, inputs, transitions, and outputs.

4. STATE TABLE BASED TESTING

    I. Identify the states

    II. Prepare state transition diagram after understanding transitions between states

    III.  Convert the state graph into the state table as discussed earlier

    IV. Analyze the state table for its completeness

    V. Create the corresponding test cases from the state table

        Test case ID 
        Test Source 
        Current State
        Event
        Output
        Next State

-----------------------------------------------------------------------------------

Decision Table Based Testing

Boundary value analysis and equivalence class partitioning methods do not consider combinations of input conditions.

4.1 FORMATION OF DECISION TABLE

4.2 TEST CASE DESIGN USING DECISION TABLE

- Interpret condition stubs as the inputs for the test case.

- Interpret action stubs as the expected output for the test case.

- Rule, which is the combination of input conditions, becomes the test case itself.

- If there are k rules over n binary conditions, there are at least k test cases and at the most 2^n test cases.

4.3 EXPANDING THE IMMATERIAL CASES IN DECISION TABLE:

- Immaterial cases (I) have been shown in the decision table which are don’tcare conditions.

-----------------------------------------------------------------------------------

CAUSE EFFECT BASED TESTING

- Division of specification

- Identification of causes and effects

- Transformation of specification into a cause-effect graph

- Conversion into decision table

- Deriving test cases

BASIC NOTATIONS FOR CAUSE-EFFECT GRAPH

1) Identity(According to the identity function, if x is 1, y is 1; else y is 0.)

UPDATING.....................................