• Loading
    • Categories of Testing

      Broad Categories of Testing


      Ø Testing the software by performing a manual inspection, review or walkthrough is termed as Static Testing
      • Inspection: It is a technique in which the work product is examined for its compliance to specific standards and also checked against a history of common errors.
      •Review: It is a technique in which the work product is discussed upon by a group of two or more persons and reexamined or revaluated for possible corrections.
      •Walkthrough: It is a technique mostly done on the code developed, where the code is traced manually to monitor the state of the program variables as a way of analyzing the logic.

      Ø Testing the software by Dynamically executing the application is termed as Dynamic Testing.
      •Functional Testing : Functional Testing checks whether all the business functionalities are working fine as per the requirement from the customer.
      •Non-Functional Test: Testing that concentrates on the performance of the system like the response time, speed of execution, usability, availability etc.


      Dynamic Testing Techniques


      1. White Box Testing

      Tests at micro level of the programs that test each and every implemented functional task, ensuring that all code options are exercised. Requires knowledge of the internal code.

      2. Black Box Testing

      Testing that focuses solely on the outputs generated in response to selected inputs and execution conditions. Requirements are the only test basis and knowledge of the internal code is not required.


      Dynamic Testing Techniques



      Black Box Technique : Equivalence Partitioning

      § Partitioning the input domain of a program into a finite number of classes
      sets], to identify a minimal set of well selected test cases to represent these
      classes.

      § There are two types of input equivalence classes, valid and invalid.
      §
      § Equivalence class testing can significantly reduce the number of test cases
      that must be created and executed



      Guidelines for equivalence classes

      •If an input condition specifies range, one valid and two invalid equivalence classes are needed
      •If a condition requires a specific value, then one valid and two invalid equivalence classes are needed
      •If an input condition specifies a member of a set, one valid and one invalid equivalence class are needed
      •If an input condition is Boolean, one valid and one invalid class are needed

      Illustration for EP


      EP may be best explained with an example of a function which has the pass parameter "month" of a date. The valid range for the month is 1 to 12, standing for January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.

      .... -2 -1 0 1 ...................12 13 14 15 .....
      --------------------|-------------------|---------------------
      Invalid partition I Valid partition Invalid partition II


      Black Box Technique : Boundary Value Analysis
      § A selection technique in which test data are chosen to lie along "boundaries“ of the input domain [or output range] classes, data structures, procedure parameters, etc.§
      § Choices often include maximum, minimum, and trivial values

      Focus on the boundaries of the input

      If input condition specifies a range bounded by a certain values, say, a and b, then test cases should include
      •The values for a and b
      •The values just above and just below a and b
      If an input condition specifies any number of values, test cases should be
      §the minimum and maximum numbers,
      §the values just above and just below the minimum and maximum values

      Boundary value analysis:

      Behaviour at the edge of each equivalence partition is more likely to be incorrect, so boundaries are an area where testing is likely to yield defects. The maximum and minimum values of a partition are its boundary values. Tests can be designed to cover both valid and invalid boundary values. When designing test cases, a value on each boundary is chosen.

      Boundary value analysis can be applied at all test levels. It is relatively easy to apply and its defect finding capability is high; detailed specifications are helpful. This technique is often considered an extension of equivalence partitioning and can be used on input by humans as well as, for example, on timing or table boundaries. Boundary values may also be used for test data selection.

      Illustration for BVA

      If the same example of a function which has the pass parameter
      "month" of a date
      Valid Class is 1<= month <=12
      Invalid Class 1 is month <1
      Invalid Class 2 is month >12

      When compared to EP, which says select any test case within a
      range and any on either side of it , in BVA the emphasis is on the
      ‘edges’
      1 and 12 for the ‘edges’ of the Valid class

      7( a middle value ) for the Valid Class

      0 and 13 for the Invalid class

      Experience has shown that when a test case on or just to one side
      of a boundary of an equivalence class is selected, the probability of
      detecting a fault increases.


      White Box Technique: Statement Coverage


      § Testing to satisfy the criterion that each statement in a program to be executed at least once during program testing. Coverage is 100 percentage when a set of test cases causes every program statement to be executed at least once.

      § The chief disadvantage of statement coverage is that it is insensitive to some control structures.
      Example
      1 int select ( int a[], int n, int x)
      2 {
      3 int i = 0;
      4 while ( i < n && a[i] < x )
      5 {
      6 if (a[i] < 0)
      7 a[i] = - a[i];
      8 i++;
      9 }
      10 return 1;
      11 }
      One test case n=1, a[0]=-7, x=9 covers everything ,
      Flow 1 - > 2 - > 3 - > 4 - > 5 - > 6 - > 7 - > 8 - > 9 - > 10 - > 11


      White Box Technique: Branch or Decision Coverage
      § A test coverage criteria which requires that for each decision point or each possible branch be executed at least once
      Example
      1 int select ( int a[], int n, int x)
      2 {
      3 int i = 0;
      4 while ( i < n && a[i] < x )
      5 {
      6 if (a[i] < 0)
      7 a[i] = - a[i];
      8 i++;
      9 }
      10 return 1;
      11 }
      Test Data
      Branch coverage i n x a[i] Branch Outcome
      while ( i < n && a[i] < x ) 0 1 9 -7 True
      0 1 7 9 False


      Flow A : 1 - > 2 - > 3 - > 4 - > 5 - > 6 - > 7 - > 8 - > 9 - > 10 - > 11
      Flow B : 1 - > 2 - > 3 - > 4 - > 10 - > 11


      White Box Technique: Multiple Condition Coverage

      § A test coverage criteria which requires enough test cases such that all possible combinations of condition outcomes in each decision, and all points of entry, are invoked at least once.

      § A large number of test cases may be required for full multiple condition coverage
      Example
      1 int select ( int a[], int n, int x)
      2 {
      3 int i = 0;
      4 while ( i < n && a[i] < x )
      5 {
      6 if (a[i] < 0)
      7 a[i] = - a[i];
      8 i++;
      9 }
      10 return 1;
      11 }
      Test Data
      Multiple Condition Coverage i n a[i] x Outcome
      while ( i < n && a[i] < x ) 0 4 -10 10 True
      0 4 10 10 False
      0 -4 -10 10 False
      0 -4 10 10 False
      if ( a[i] < 0 ) - - -10 - True
      - - 10 - False


      Flow A : 1 - > 2 - > 3 - > 4 - > 5 - > 6 - > 7 - > 8 - > 9 - > 10 - > 11
      Flow B : 1 - > 2 - > 3 - > 4 - > 10 - > 11
      Flow C : 1 - > 2 - > 3 - > 4 - > 5 - > 6 - > 9 - > 10 - > 11


      White Box Technique: Loop Coverage

      § A test coverage criteria which checks whether loop body executed zero times, exactly once or more than once
      Example
      main ( )
      {
      int i, n, a[10],x;
      printf (“Enter the values”);
      scanf (“%d %d %d %d”, &i, &n, &a[i], &x);
      while ( i < n && a[i] < x )
      {
      if (a[i] < 0)
      a[i] = - a[i];
      i++;
      }
      printf (“%d” , a[i] );
      }
      Test Data
      Loop Coverage i n x a[i] loop called
      while ( i < n && a[i] < x ) 0 4 5 10 0 times
      3 4 5 -10 1 time
      1 4 5 -10 3 times


      White Box Technique: Call Coverage

      § A test coverage criteria which checks whether function called zero times, exactly once or more than once
      § Since probability of failure is more in function calls, each function call is executed
      Example
      main ( )
      {
      int a, b, i ;
      printf (“Enter the value of a, b, i”);
      scanf (“ %d %d %d “, &a ,&b, &i);
      if ( i < 10 )
      {
      sample ( a, b);
      i = i + 1;
      }
      }
      sample ( int x , int y )
      {
      If ( x > 10 )
      x = x + y ; break ;
      if ( y > 10 )
      y = y + x ; break ;
      }
      Test Data
      Call Coverage a b i function called
      sample ( int x, int y ) 2 4 10 0 times
      2 4 9 1 time
      2 4 7 3 times


      White Box Technique: Path Coverage
      § Testing to satisfy coverage criteria that each logical path through the program be tested. Often paths through the program are grouped into a finite set of classes. One path from each class is then tested

      § General coverage requires executing all paths, number of paths may be infinite if there are loops
      Example


      Linear Independent Paths
      Path 1 -> p1 – d1 – d2 – p4
      Path 2 -> p1 – d1 – p2 – p4
      Path 3 -> p1 – d1 – d2 – p3 – p4

      Sample Program
      1 sample ( int x , int y )
      {
      2 If ( x > 10 )
      3 x = x + y ; break ;
      4 if ( y > 10 )
      5 y = y + x ; break ;
      }
      6 printf (“%d %d”, x , y);



      Levels of Testing
      There are broadly four levels of Testing done in any Testing Project
      q Unit Testing
      q Integration Testing
      q System Testing
      q Acceptance Testing

      The first 2 levels concentrate mainly on the “Functional aspects”. During System Testing level, the functionality of the application is tested first, and then the non-functional aspects mainly the “Performance” of the application can be tested.
      Acceptance Testing is the last level of testing in the SDLC
      Apart from the ‘Performance’ there are other non-functional aspects that can be tested in the application as per the requirements



      Unit Testing
      §To test a unit of code (program or set of programs) using Unit Test Specifications, after coding is completed. Involves the basic testing of a piece of code, the size of which is often undefined in practice, although it is usually a function or a subroutine

      • Example
      – Testing of a cobol program in the reservation system that calculates the price for the ticket requested based on the inputs supplied to the program from the calling cobol program.


      Integration Testing
      § The process of testing interfaces and data flows between the programs within a sub system,and between the sub-systems within a system.
      § Integration testing means that the tester must look for bugs in the relationship and the interfaces between pairs of components and groups of components under test.
      • Example
      – Check whether the calling program in previous example passes the right information relating to starting station and destination, date of journey, discounts to be applied and class requested

      System Testing
      § It is a test, executed by the developer or independent test team in a laboratory environment that should demonstrate that the developed system or subsystems meet the requirements set in the functional and quality specifications.
      § The process of proving that the system meets its stated design specifications (design
      documents) w.r.t criteria such as recoverability, maintainability and security.

      • Example
      – Comprehensive black box testing of railway reservation system with transactions initiated and validations performed on databases and reports generated after the completion of the transactions.


      Acceptance Testing
      § It is a test, executed by the user(s) and system manager(s) in an environment
      simulating the operational environment to the greatest possible extent, that should demonstrate that the developed system meets the functional and quality requirements.


      Non-Functional & Other types of Testing
      §Performance testing
      § Volume testing
      § Load testing
      § Limit testing
      § Stress testing
      § Disaster Testing
      § Recovery testing
      § Security testing
      § Reliability testing
      § Installation Testing
      § Usability Testing
      § Accessibility Testing
      § Regression testing



    Disclaimer: Users of techforum4u.com are responsible for ensuring that any material they post (article, blog posts, images or other mulitimedia content) does not violate or infringe upon the copyright, patent, trademark, or any personal or proprietary rights of any third party, and is posted with the permission of the owner of such rights.Anyone who violates these rules may have their access privileges removed without warning.