Please enable JavaScript.

Coggle requires JavaScript to display documents.

TESTING THE PROGRAM (COMPONENT TESTING (Test Environment (Driver (“Main…

- - - - objective
        
        To demonstrate that software functions are operational, input is properly accepted and output is correctly produced without taking into account of knowledge of the internal structure of the program
        
        Functional testing attempts to find errors in the following categories
        
        Incorrect or missing functions
        
        Interface errors
        
        Errors in data structures or external database access
        
        Performance errors
        
        Initialization and termination errors
      - Method
        
        Equivalence partitioning
        
        To reduce the number of input data to be tested
        
        Sampling
        
        Similar approach to equivalence partitioning method but it is more complete
        
        In each class, a certain number of values are selected
        
        Boundary value analysis
        
        A variant and refinement of the equivalence partitioning
        
        Lead to the selection of test cases that exercise boundary values of equivalence classes
        
        Can derive test cases from the output domain as well
        
        Test cases are derived to ensure the robustness of the subprogram
        
        Remember to take the max integer, the min real number plus or minus the precision of the computer
        
        Robustness
        
        To prove that no catastrophic event can be produced by the introduction of an abnormal input data item
        
        As from the equivalence classes
        
        The values are taken at the outer bounds of the equivalence classes
        
        Examples:
        
        Hit the ESC key
        
        Insert the different types of data
        
        Use the values outside the limit
        
        Cause-effect graphing
        
        Explore combinations of inputs circumstances
    - - Objective
        
        To examine the internal structure of the CSU
        
        Logical Paths through the software are tested by providing test
        cases that exercise specific sets of condition and/or loops
        
        Using white box testing method, the s/w engineer can derive the test cases that:
        
        Guarantee that all independent paths within module have been exercise at this once
        
        Exercise all logical decisions on their true and false sides
        
        Execute all loops at their boundaries and within their operational bounds
        
        Exercise the internal data structures to assure their validity
      - Methods
        
        Control/flow graph
        
        The logic structure of software modules can be represented using the control/flow graph
        
        Instruction block (IB)
        
        An IB is a set of sequential instructions in which the execution of the first leads to the executions of the next.
        
        The IB test consist of executing at least once all the IB (or a certain percentage decided on beforehand)
        
        Decision-to-decision path (DDP)
        
        A decision-to-decision or branch begins at the start of the program or at a decision note (instruction that can lead to branching) and ends at the end of the program or the next decision node
        
        DDP encompasses IB testing The decision-to-decision path test consists in executing at least once the decision-to-decision paths (or a certain percentage decided on beforehand)
  - - - “Main program” that accepts the test case data, passes such data to the module to be tested, and then prints the relevant results
    - - Serves to replace modules that are subordinate to the module to be tested. A stub or “dummy subprogram” uses the subordinate modules interface, may do minimal data manipulation, prints the verification of entry and then returns to the caller