TESTING

Document Sample
TESTING Powered By Docstoc
					                                             Software Engineering




                          Software Testing


                              N.L. Hsueh




                                                             1
N.L. Hsueh, SE-Lab IECS FCU
                                         Software Engineering




        A working program remains an elusive thing of
        beauty

        Rober Dunn




                                                         2
N.L. Hsueh, SE-Lab IECS FCU
                                                     Software Engineering

                                Outline

       Basic concept
          Testability, V&V, dynamic and static testing, statistical and
           defect
       Reliability achievement
          Fault avoidance
          Fault tolerance
          Fault tolerance
       Testing Strategy
          Top-down, button-up testing
       Defect Testing
          Black-box testing
          White-box testing
       Templates


                                                                           3
N.L. Hsueh, SE-Lab IECS FCU
                                                       Software Engineering

                              Basic Concept

       Testing is the process of exercising a program with the
        specific intent of finding errors prior to delivery to end users
       Principles
          All tests should be traceable to customer requirements
          Tests should be planned long ago before testing begins
          Incremental testing
                Testing   should begin “in the small” and progress toward
                 testing “in the large”
             Exhaustive testing is not possible
             To be more effective, testing should be conducted by an
              independent third party




                                                                             4
N.L. Hsueh, SE-Lab IECS FCU
                                                             Software Engineering

                                 Testability
       Operability
           E.g., No bugs block the execution of tests
       Observability
           Distinct output is generated for each input
           Internal errors are automatically reported
           Source do is accessible
       Controllability
           Software and hardware states and variable can be controlled directly by
            the test engineering
       Decomposability
           The software system is built from independent modules
       Simplicity
           Code simplicity
       Stability
           Changes to the software are infrequent
       Understandability
           The design is well-understood
           Documentation is instantly accessible


                                                                                      5
N.L. Hsueh, SE-Lab IECS FCU
                                                        Software Engineering

                   Verification vs validation

       Verification:
             "Are we building the product right"
             The software should conform to its specification
       Validation:
             "Are we building the right product"
             The software should do what the user really requires
       Process
             Is a whole life-cycle process - V & V must be applied at
              each stage in the software process.
             Has two principal objectives
                  The discovery of defects in a system
                  The assessment of whether or not the system is usable in
                   an operational situation.

                                                                              6
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                 Dynamic and Static Testing


       Dynamic Testing
           Concerned with       exercising   and   observing    product
            behavior (testing)

       Static Testing
            Concerned with analysis of the             static   system
             representation to discover problems




                                                                      7
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                  Static and dynamic testing


                                  Static
                               verification




Requirements      High-level      Formal       Detailed
                               specification                 Program
specification      design                       design



                                                            Dynamic
  Prototype
                                                            validation




                                                                         8
N.L. Hsueh, SE-Lab IECS FCU
                                                        Software Engineering

                Statistical vs. Defect Testing

       Statistical testing
            used for reliability estimation.
            related to software reliability
       Defect testing
            Tests designed to discover system defects
            A successful defect test is one which reveals the
             presence of defects in a system.

               Defect testing and debugging are distinct processes
                  Defect testing is concerned with confirming the presence
                   of errors
                  Debugging is concerned with locating and repairing these
                   errors


                                                                              9
N.L. Hsueh, SE-Lab IECS FCU
                                                              Software Engineering

                               Testing Process


    Unit
   testing
                     Module
                     testing
                                   Sub-system
                                     testing
                                                          System
                                                          testing
                                                                      Acceptance
                                                                        testing



         Component                  Integration testing                User
           testing                                                    testing
                                                                                10
N.L. Hsueh, SE-Lab IECS FCU
                                                Software Engineering

                              Testing Stages

       Unit testing
             testing of individual components
       Module testing
             testing of collections of dependent components
       Sub-system testing
             testing collections of modules integrated into sub-
              systems
       System testing
             testing the complete system prior to delivery
       Acceptance testing
             testing by users to check that the system satisfies
              requirements
             sometimes called alpha testing

                                                                    11
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

               Test Planning and Scheduling

         Describe major phases of the testing process
         Describe tracability of tests to requirements
         Estimate overall schedule and resource allocation
         Describe relationship with other project plans
         Describe recording method for test results




                                                                    12
N.L. Hsueh, SE-Lab IECS FCU
                                                                                   Software Engineering

                  The V-model of Development



Requir ements               System                      System                   Detailed
specification             specification                 design                    design



                                            System                 Sub-system                   Module and
             Acceptance
                                          integration              integration                   unit code
              test plan
                                           test plan                test plan                    and tess



                          Acceptance                    System                 Sub-system
   Service
                             test                   integration test         integration test




                                       Testing vs. Development
                                                                                                       13
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                    Reliability Achievement

       Fault avoidance
          Development technique are used that either minimise the
           possibility of mistakes or trap mistakes before they result
           in the introduction of system faults
       Fault detection and removal
          Verification and validation techniques that increase the
           probability of detecting and correcting errors before the
           system goes into service are used
       Fault tolerance
          Run-time techniques are used to ensure that system faults
           do not result in system errors and/or that system errors do
           not lead to system failures




                                                                         14
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                          Fault Avoidance

       Fault avoidance
          Development technique are used that either minimise the
           possibility of mistakes or trap mistakes before they result
           in the introduction of system faults

       Techniques
          Development methodology
          Configuration management
          Verification techniques
          Reviews




                                                                         15
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering

                           Fault Detection

       Fault detection and removal
          Verification and validation techniques that increase the
           probability of detecting and correcting errors before the
           system goes into service are used

       Techniques
          Debugging
                Correctness debugging
                Performance debugging
             Testing
                Component testing
                Integration testing
                System testing

                                                                       16
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                              Fault Tolerance

       Fault tolerance
          Run-time techniques are used to ensure that system faults
           do not result in system errors and/or that system errors do
           not lead to system failures
          Fault tolerance means that the system can continue in
           operation in spite of software failure
          In    critical situations, software systems must be
           fault tolerant




                                                                         17
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                     Fault Tolerance Actions

       Fault detection
          The system must detect that a fault (an incorrect system
           state) has occurred.
       Damage assessment
          The parts of the system state affected by the fault must be
           detected
       Fault recovery
          The system must restore its state to a known safe state.
       Fault repair
          The system may be modified to prevent recurrence of the
           fault.
          Many software faults are transitory, this is often
           unnecessary

                                                                         18
N.L. Hsueh, SE-Lab IECS FCU
                                                        Software Engineering

                  Fault Tolerance Techniques

       Techniques
          Atomic transactions
                Database   systems provide atomic transactions to recover
                 from failure during a sequence of actions that need to be
                 executed together or not at all
             Modular redundancy
                Assign  more than one component to perform the same
                 operation
             Defensive programming
                Programmers assume that there may be faults in the code of
                 the system and incorporate redundant code to check the
                 state after modifications to ensure that it is consistent
                Exception handling


                                                                              19
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering

                      Exception Handling

       A program exception is an error or some unexpected event
        such as a power failure

       Exception handling constructs allow for such events to be
        handled without the need for continual status checking to
        detect exceptions.

       Using normal control constructs to detect exceptions in a
        sequence of nested procedure calls needs many additional
        statements to be added to the program and adds a significant
        timing overhead




                                                                       20
N.L. Hsueh, SE-Lab IECS FCU
                                                                Software Engineering

                            Exceptions in Java
    class SensorFailureException extends Exception {
               SensorFailureException (String msg) {
                        super (msg) ;
                        Alarm.activate (msg) ;
               }
    } // SensorFailureException

    class Sensor {
              int readVal () throws SensorFailureException {
              try {
                         int theValue = DeviceIO.readInteger () ;
                         if (theValue < 0)
                                    throw new SensorFailureException ("Sensor failure") ;
                         return theValue ;
              }
              catch (deviceIOException e)
                         { throw new SensorFailureException (“ Sensor read error ”) ; }
              } // readVal
    } // Sensor

                                                                                        21
N.L. Hsueh, SE-Lab IECS FCU
class FreezerController {
Sensor tempSensor = new Sensor () ;
Dial tempDial = new Dial () ;
float freezerTemp = tempSensor.readVal () ;
final float dangerTemp = (float) -18.0 ;
final long coolingTime = (long) 200000.0 ;
public void run ( ) throws InterrupedException {
  try {
        Pump.switchIt (Pump.on) ;
        do { if (freezerTemp > tempDial.setting ())
                        if (Pump.status == Pump.off)
                        {      Pump.switchIt (Pump.on) ;
                               Thread.sleep (coolingTime) ;
                        } else
                        if (Pump.status == Pump.on)
                               Pump.switchIt (Pump.off) ;
                if (freezerTemp > dangerTemp)
                        throw new FreezerTooHotException () ;
                freezerTemp = tempSensor.readVal () ;
        } while (true) ;
  } // try block
  catch (FreezerTooHotException f)
  {     Alarm.activate ( ) ; }
  catch (InterruptedException e)
  {     System.out.println (“Thread exception”) ;
        throw new InterruptedException ( ) ;                    Freezer controller (Java)
  }
  } //run
} // FreezerController
                                                  Software Engineering

                              Fault Detection

       Languages such as Java and Ada have a strict type system
        that allows many errors to be trapped at compile-time

       However, some classes of error can only be discovered at
        run-time

       Fault detection involves detecting an erroneous system state
        and throwing an exception to manage the detected fault




                                                                       23
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                              Fault Detection

       Preventative fault detection
          The fault detection mechanism is initiated before the state
           change is committed.
          If an erroneous state is detected, the change is not made


       Retrospective fault detection
          The fault detection mechanism is initiated after the system
           state has been changed.
          Used when a incorrect sequence of correct actions leads
           to an erroneous state to when preventative fault detection
           involves too much overhead




                                                                         24
N.L. Hsueh, SE-Lab IECS FCU
                                                      Software Engineering



         class PositiveEvenInteger {
                 int val=0;
                 positiveEvenInteger (int n) throws NumericException {
                          if (n<0 | n%2==1)
                             throw new NumericException();
                          else
                             val = n;
                 }
                 public void assign (int n) throws NumericException {
                          if (n<0 | n%2==1)
                             throw new NumericException();
                          else
                             val = n;
                 }
         }

                       Preventative fault detection
                                                                         25
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                      Damage Assessment

       Analyse system state to judge the extent of corruption caused
        by a system failure

       Must assess what parts of the state space have been affected
        by the failure

       Generally based on ‘validity functions’ which can be applied
        to the state elements to assess if their value is within an
        allowed range




                                                                        26
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering
                     Damage Assessment -
                         Techniques

       Checksums are used for damage assessment in data
        transmission

       Redundant pointers can be used to check the integrity of data
        structures

       Watch dog timers can check for non-terminating processes
          If no response after a certain time, a problem is assumed




                                                                        27
N.L. Hsueh, SE-Lab IECS FCU
class RobustArray {
// Checks that all the objects in an array of objects
// conform to some defined constraint
boolean [] checkState ;                                         checkState will
CheckableObject [] theRobustArray ;                                store the
                                                                 damage level
RobustArray (CheckableObject [] theArray)
{
     checkState = new boolean [theArray.length] ;
     theRobustArray = theArray ;
}
public void assessDamage () throws ArrayDamagedException
{
     boolean hasBeenDamaged = false ;

     for (int i= 0; i <this.theRobustArray.length ; i ++)
     {
               if (! theRobustArray [i].check ())
                       {
                            checkState [i] = true ;
                            hasBeenDamaged = true ;
                       }
               else
                       checkState [i] = false ;
     }
     if (hasBeenDamaged)
               throw new ArrayDamagedException () ;
}                                                           Java class with damage
}                                                                 assessment
                                                     Software Engineering

                              Fault Recovery

       Forward recovery
          Apply repairs to a corrupted system state


       Backward recovery
          Restore the system state to a known safe state


       Forward recovery is usually application specific - domain
        knowledge is required to compute possible state corrections
          You know why faults happen and how to correct them


       Backward error recovery is simpler
          Details of a safe state are maintained and this replaces the
           corrupted system state

                                                                          29
N.L. Hsueh, SE-Lab IECS FCU
                                                      Software Engineering

                      Backward Recovery

       Transactions are a frequently used method of backward
        recovery.
           Changes are not applied until computation is complete
           If an error occurs, the system is left in the state preceding
            the transaction

       Periodic checkpoints allow system to 'roll-back‘ to a correct
        state




                                                                            30
N.L. Hsueh, SE-Lab IECS FCU
class SafeSort {
static void sort ( int [] intarray, int order ) throws SortError
{
      int [] copy = new int [intarray.length];

     // copy the input array

      for (int i = 0; i < intarray.length ; i++)
             copy [i] = intarray [i] ;
                                                                    Periodic Checking
      try {
             Sort.bubblesort (intarray, intarray.length, order) ;
             if (order == Sort.ascending)
                   for (int i = 0; i <= intarray.length-2 ; i++)
                           if (intarray [i] > intarray [i+1])
                               throw new SortError () ;
             else
                   for (int i = 0; i <= intarray.length-2 ; i++)
                           if (intarray [i+1] > intarray [i])
                               throw new SortError () ;
      } // try block
      catch (SortError e )
      {
             for (int i = 0; i < intarray.length ; i++)
                   intarray [i] = copy [i] ;
             throw new SortError ("Array not sorted") ;
      } //catch
} // sort
} // SafeSort
                                                    Software Engineering

                          Testing Strategy

       Testing strategies are ways of approaching the testing
        process
       Different strategies may be applied at different stages of the
        testing process
       Strategies covered
             Top-down testing: starting with the most abstract
             Bottom-up testing: starting with the fundamental
              component
             Thread testing
             Stress testing: how well the system can cope with
              overload situations
       Whenever testing strategy is adopted, it is always sensible
        to adopt an incremental approach to subsystem and system
        testing

                                                                         32
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                        Top-Down Testing

                        Testing
      Level 1                           Level 1                         . ..
                       sequence



                        Level 2   Level 2     Le vel 2       Level 2

Le vel 2
 stubs


                  Le vel 3
                   stubs




                                                                       33
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering

                               Conti.

       Start with the high-levels of a system and work your way
        downwards
       Testing strategy which is used in conjunction with top-down
        development finds architectural errors
            It demonstrates the feasibility of the system to
             management
            Validation can begin early in the testing process

       May be difficult to develop program stubs
           Consider a function which relies on the conversion of
            an array of objects into a linked list, this stub is not
            easy to do



                                                                       34
N.L. Hsueh, SE-Lab IECS FCU
                                                      Software Engineering

                          Bottom-up testing


   Test
  drivers
                                                                     Testing
        Level N       Level N   Le vel N    Level N       Level N
                                                                    sequence




   Test
  drivers
              Level N–1         Level N–1        Level N–1




                                                                       35
N.L. Hsueh, SE-Lab IECS FCU
                                                     Software Engineering

                        Bottom-Up Testing

         Necessary for critical infrastructure components
         Start with the lower levels of the system and work upward
         Needs test drivers to be implemented
         Does not find major design problems until late in the process
         Appropriate for object-oriented systems




                                                                          36
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering

                              Stress Testing

       Exercises the system beyond its maximum design load until
        the system fails
       Stressing the system often causes defects to come to light
       Systems should not fail catastrophically
       Particularly relevant to distributed systems which can exhibit
        severe degradation as a network becomes overloaded




                                                                    37
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering

                              Defect Testing

       The objective of defect testing is to discover defects in
        programs
       A successful defect test is a test which causes a program to
        behave in an anomalous way
       Tests show the presence not the absence of defects

       Test data
            Inputs which have been devised to test the system
       Test cases
            Inputs to test the system and the predicted outputs
             from these inputs if the system operates according to
             its specification



                                                                       38
N.L. Hsueh, SE-Lab IECS FCU
                                                                     Software Engineering

                    The Defect Testing Process




                Test                   Test                     Test                        Test
                cases                  data                    results                     reports


  Design test           Prepare test          Run program                Compare results
    cases                  data               with test data              to test cases




                                                                                                     39
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                    Defect Testing Approaches

            Testing                                De velopment
             team                                      team




          Functional           Interface             Structural
            testing             testing               testing

Black-box testing                          White-box testing



                              Sub-system              Unit and
            System
                                                      module

                                                                   40
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

               Functional (black-box) testing

       Approach to testing where the program is considered as a
        „black-box‟

       The program test cases are based on the system
        specification

       Test planning can begin early in the software process




                              input       output




                                                                   41
N.L. Hsueh, SE-Lab IECS FCU
                                                 Software Engineering

                            Black-box testing

                                                Inputs causing
                                                anomalous
                 Input test data        I       behaviour
                                        e




                               System




                                                Outputs which reveal
                                                the presence of
               Output test results      Oe      defects


                                                                       42
N.L. Hsueh, SE-Lab IECS FCU
                                                          Software Engineering

                   Equivalence Partitioning

       Input equivalence partitions are sets of data where the set
        members should all be processed in an equivalent way by
        the program

       The partitioning is identified by a tester using experience to
        predict which classes of input value are likely to detect
        errors

       Partition system input into „equivalence sets‟
             Output partitions (<10, 10-20, >20)
                  Design input values to output values located in partition 1,
                   2, and 3, respectively




                                                                                  43
N.L. Hsueh, SE-Lab IECS FCU
                                     Software Engineering

              An Example – Swimming Center




                                                     44
N.L. Hsueh, SE-Lab IECS FCU
                                       Software Engineering

                              Conti.




                                                       45
N.L. Hsueh, SE-Lab IECS FCU
                                                          Software Engineering

                       An Example - Search


        procedure Search (Key : ELEM ; T: ELEM_ARRAY;
            Found : in out BOOLEAN; L: in out ELEM_INDEX) ;

        Pre-condition
                -- the array has at least one element
                T’FIRST <= T’LAST
        Post-condition
                -- the element is found and is referenced by L
                ( Found and T (L) = Key)
        or
                -- the element is not in the array
                ( not Found and
                not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))


  In black-box testing, testing is based on specification
                                                                          46
N.L. Hsueh, SE-Lab IECS FCU
                                                                       Software Engineering

                                            Conti.
                                   Equivalence class boundaries



                  Elements < Mid                            Elements > Mid



                                           Mid-point


    Variable    Valid EC             Representing value           Invalid EC   Representing value
                               valid value      boundary value
   array(A)    odd          {1,2,3}           {1}
               even         {3,5,6,9}         null, {2,3}
                                              last value, first
                                              value, middle
   key(K)      in array     depends on A      value
               not in array depends on A      depends on A

                                    Equivalence Partition
                                                                                                47
N.L. Hsueh, SE-Lab IECS FCU
                                                          Software Engineering

                                         Conti.


                     Type                         Input           Result
    A-class n/b         K-class   n/b     A          K    L          Found
    1         n         1         n       {1,2,3}    2    1            TRUE
    1         n         1         b       {1,2,3}    1    0            TRUE
    1         b         1         b       {1}        1    0            TRUE
    1         b         2         b       {1}        2    -            FALSE
    2         n         2         n       {3,5,6,9} 4     -            FALSE
    2         b         1         n       null       9    no such data
    2         n         1         b       {3,5,6,9} 9     3            TRUE
    n/b: nomal or boundary



                                        Test Cases
                                                                               48
N.L. Hsueh, SE-Lab IECS FCU
                                          Software Engineering




        Bugs lurk in corners and congregate at
        boundaries

        Boris Beizer




                                                          49
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                         Structural Testing

         Sometime called white-box testing
         Derivation of test cases according to program structure
         Objective is to exercise all program statements
         Knowledge of the program is used to identify additional test
          cases
              By examining the code of the search routine, we can
               see that binary searching involves splitting the search
               space into three parts
              Each of these parts makes up an equivalence partition
              Test cases where the key lies at the boundaries of
               each of these partitions should be chosen to exercise
               the code



                                                                         50
N.L. Hsueh, SE-Lab IECS FCU
                                                                   Software Engineering
           void Binary_search (elem key, elem* T, int size,
                                              boolean &found, int &L)
           {
                      int bott, top, mid ;
                      bott = 0 ; top = size -1 ;
                      L = ( top + bott ) / 2 ;
                      if (T[L] == key)
                                  found = true ;
                      else
                                  found = false ;
                      while (bott <=top && !found)
                      {
                                  mid = top + bott / 2 ;
                                  if ( T [mid] == key )
                                  {
                                              found = true;
                                              L = mid ;
                                  }
                                  else if (T [mid] < key )
                                              bott = mid + 1 ;
                                  else
                                              top = mid-1 ;
                      } // while
           } //binary_search
                                                                                   51
N.L. Hsueh, SE-Lab IECS FCU
                                                          Software Engineering

                              Path Coverage

       Path testing
          To exercise every independent execution path through the
           component
          If every independent path is executed then all statements
           in the program must have been executed at least once
                All conditional statements are tested for both true and false
                 cases
       Flow graph
          Describes the program control flow
          Is constructed by replacing program control statements by
           equivalent diagrams
          If there are no „goto‟ statements in a program, it is a
           straightforward mapping from a program to a flow graph
          Used as a basis         for computing the cyclomatic
           complexity

                                                                                 52
N.L. Hsueh, SE-Lab IECS FCU
                                                Software Engineering

                       Program flow graphs

       The number of independent path in a program can be
        discovered by computing the cyclomatic complexity
        (McCabe 1976)
            Complexity = Number of edges - Number of nodes +1




                 if-then-else   loop-while   case-of



                                                                 53
N.L. Hsueh, SE-Lab IECS FCU
                                                                            Software Engineering
                                      1


                                           (while Bott < = Top loop)
                                      2


             (if not Found then...)
                                      3

                                                          (If T (mid) = Key then...)
                      4                         5


                                      6                          7
                                                                          (if T (mid) < Key then...)


                                                      8                    9


                                                                 10


                                      12       11




                                      13
                                                                                                       54
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                   Cyclomatic complexity

       The number of tests to test all control statements equals the
        cyclomatic complexity
       Cyclomatic complexity equals number of conditions in a
        program
       Independent paths
            1, 2, 12, 13
            1, 2, 3, 4, 12, 13
            1, 2, 3, 5, 6, 11, 2, 12, 13
            1, 2, 3, 5, 7, 8, 10, 11, 2, 12, 13
            1, 2, 3, 5, 7, 9, 10, 11, 2, 12, 13
            A dynamic program analyzer may be used to check
             that paths have been executed



                                                                        55
N.L. Hsueh, SE-Lab IECS FCU
                                                           Software Engineering

              White-Box Testing – An Example

       Imperial Taxi Service (ITS)
          Minimal fare: $2
                <= 1000 yards and waiting time <= 3 min
          For every additional 250 yards: $25cents
          For every additional 2 min waiting: $20cents
          One suitcase: no charge; each additional suitcase: $1
          Night supplement: 25%, for 21:00-06:00
       Please prepare the program graph flow
       Please prepare a list of paths to achieve full coverage




                                                                           56
N.L. Hsueh, SE-Lab IECS FCU
                                                       Software Engineering



                          A number of industry studies have indicated
                          that the higher V(G), the higher the probability
                          or errors.

            modules




                                          V(G) = Cyclomatic complexity

                        modules in this range are
                        more error prone




                                                                             57
N.L. Hsueh, SE-Lab IECS FCU
                                                 Software Engineering

                          Interface Testing

       Takes place when modules or sub-systems are integrated to
        create larger systems
       Objectives are to detect faults due to interface errors or
        invalid assumptions about interfaces
       Particularly important for object-oriented development as
        objects are defined by their interfaces




                              A        B



                                  C

                                                                     58
N.L. Hsueh, SE-Lab IECS FCU
                                               Software Engineering
                          Interfaces
                            Types

       Parameter interfaces
           Data passed from one procedure to another
       Shared memory interfaces
           Block of memory is shared between procedures
       Procedural interfaces
           Sub-system encapsulates a set of procedures to be
            called by other sub-systems
       Message passing interfaces
           Sub-systems request services from other sub-systems




                                                                  59
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering

                          Interface Errors

       Interface misuse
             A calling component calls another component and
              makes an error in its use of its interface e.g.
              parameters in the wrong order
       Interface misunderstanding
             A calling component embeds assumptions about the
              behaviour of the called component which are incorrect
       Timing errors
             The called and the calling component operate at
              different speeds and out-of-date information is
              accessed




                                                                      60
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering

                 Interface Testing Guidelines

       Design tests so that parameters to a called procedure are at
        the extreme ends of their ranges
       Always test pointer parameters with null pointers
       Use stress testing in message passing systems
            Design tests which generate many more messages
             than are likely to occur in practice
       In shared memory systems, vary the order in which
        components are activated




                                                                       61
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering
                       Software Test Plan -
                            Template

       Scope
            What are to be tested?
       Testing environment
            Testing site
            Required hw/sw configuration
            Participating organization
            Preparation and training requirement of the test team
       The testing details (for each test)
            Test identification, test class, test level, test case,
             recording procedure
       Testing schedule
            Link to project development schedule
            Preparation  testing  error correction  regression
             testing

                                                                       62
N.L. Hsueh, SE-Lab IECS FCU

				
About if any file u wil find copyright contact me it will be remove in 3 to 4 buisnees days. add me on sanjaydudeja007@gmail.com or visit http://www.ohotech.com/