Docstoc

Black Box Testing - PDF

Document Sample
Black Box Testing - PDF Powered By Docstoc
					                    Black Box Testing

                                By:
                          Bayu hendradjaya




Black Box Testing - Bayu Hendradjaya         5-Nov-98 1
          Functional/black Box Testing
• Check the conformity of the tested CSU against
  established behavior and detect errors generated by fault
     Software fault is a software part which is not according
     to its definition provided in the development document




Black Box Testing - Bayu Hendradjaya                5-Nov-98 2
          Functional/black Box Testing
• Should consider only a CSU from the standpoint of its

     Input data, output data
   Knowledge of its internal structured should not be

   It is very often impossible to test all the input data
   It is hence necessary to select a subset of possible input




Black Box Testing - Bayu Hendradjaya                   5-Nov-98 3
                    Black Box Testing
•   Equivalence class partitioning
•   Sample testing
•   Limit testing
•   Robustness testing
•   Behavior testing
•   Requirement testing
•   Testing through ‘cause effect relationship’




Black Box Testing - Bayu Hendradjaya              5-Nov-98 4
         Expected Result Determination
• Expected result can not be determined by executing a CSU

   It is determined prior to test execution, at test design phase
   The cost of analyzing and predicting the expected behavior
   for each test case of each CSU is likely too high

         • Something which makes it possible to predict the
           expected result from executing a test applying to a
           subprogram of a given CSU, with specific input data
           It may be a program, a set of values, etc



Black Box Testing - Bayu Hendradjaya                    5-Nov-98 5
                               Oracle
• Various categories of oracles may be applicable for

       Expected result is obtained by executing subprogram
         • It only applies if the execution is followed up and
           checked (for analyzing intermediate values and internal

           Ability to prove that the result obtained are valid
           Must be used with caution
    – An application may be derived from a previous already
      tested application
    – Executing an equivalent CSU to be tested


Black Box Testing - Bayu Hendradjaya                        5-Nov-98 6
             Equivalence Class Testing
• To limit the number of test on a CSU, the number of items
  of input data to be tested can be reduced
  Identification the subset of values having the same impact

   These values are generally identified as regards input data
   conditions or conditions external to the item to be tested
   such as the property of an output data item




Black Box Testing - Bayu Hendradjaya                 5-Nov-98 7
             Equivalence Class Testing
• The subset of values that is defined, are known as
  ‘equivalence classes’
     An input data in an equivalence class is a set of values
     such that a test for any value of the class is equivalent
     to the tests for all the values of the class
     If a value cause an error, any other value in the class

   A distinction is made between valid equivalence classes
   which represent valid input values and invalid equivalence
   classes which represent invalid input values



Black Box Testing - Bayu Hendradjaya                 5-Nov-98 8
                         Examples (1)
• Requirements of the subprogram to be tested (initial&final

       The subprogram takes an integer input in the range

     The output of the subprogram is the sign of the input
     value (the value 0 is considered positive)
   Two valid equivalence class
    – The input range [-100,0] which contains the subset of integer, will
      produce negative sign as an output
      The input range [0,100] will produce positive sign
• Two invalid equivalence class
    – The integers strictly less than -100
      The integers strictly more than -100
Black Box Testing - Bayu Hendradjaya                          5-Nov-98 9
        Rules in Equivalence of Classes
• If a condition concerning the input data specifies a range of
  values (e/g: the counter can take values 1 to 999), define a
  valid equiv. Class [1,999] and two invalid equivalence
  class (counter < 1, and counter > 99).
  If a condition concerning the input data specifies the
  number of values (a thing can contain 1 to 6 name), define
  a valid equivalence class and two invalid equivalence
  classes (no name and more than 6 names)
  If a condition concerning the input data specifies a set of
  values and the CSU tested processes each value differently
  (e/g: BUS, TAXI, TRUCK, TRAIN), define a valid
  equivalence class for each value and an invalid
  equivalence class (e/g MOTORCYCLE).
Black Box Testing - Bayu Hendradjaya                 5-Nov-98 10
 Rules in Equivalence of Classes (Cont.)
• If an input condition is expressed by a sentence containing
  ‘must be’ (e/g the first character must be a letter), define a
  valid equivalence class ( a letter) and an invalid
  equivalence class ( not a letter)
  If there are reasons to believe that the CSU to be tested
  doesn’t process the elements of an equivalence class in the
  same way, decompose the equivalence class into smaller
  equivalence classes (based on a logical subprogram
  approach, at the algorithm level).
      If this is not the case, this should be taken into account
      in defining the equivalence classes


Black Box Testing - Bayu Hendradjaya                  5-Nov-98 11
 Rules in Equivalence of Classes (Cont.)
• If a sub program of the CSU to be tested has several
  inputs, the equivalence class or test case definition process
  may or may not take into account of combinatory

       To test a subprogram which, has two independent input
       (A and B), two valid equivalence classes (A1, A2, B1
       and B2) are defined for each input
       The subprogram can be tested either by:
         • Two test cases (the first case defines an input value of
           A1, and input value B1, and the second value A2 and B2)
           and considering that these tests are sufficient
           Or by four test cases (A1 and B1, A1 and B2, A2 and B1,
           A2 and B2) if this is considered necessary.
Black Box Testing - Bayu Hendradjaya                    5-Nov-98 12
 Rules in Equivalence of Classes (Cont.)
• To test a subprogram which has two independent inputs, an
  invalid equivalence class, is defined for each input
  Write a test case for each invalid equivalence class
     E/g: a requirement specifies to enter a car type, and the
     number of the car”
     In the test case in which the input data are two incorrect
     values ‘XYZ’, 0 the program will probably not check
     the number of items (0), and will stop on with the
     message ‘XYZ’ is not a type of car
  To test a subprogram which has several dependent input,
  the equivalence classes to be defined must take into
  account of input combinations
Black Box Testing - Bayu Hendradjaya                 5-Nov-98 13
                         Examples (2)
• Requirements
   – Given three values, represent the length of side of
     triangle, determine if it is equilateral, isosceles and

   Three valid equivalence class
    – 3 equal values positive
    – 3 positive values and 2 which are equal and the sum of two is
      greater than the third value
      3 positive values and the sum of two values is greater than the third

• Two invalid equivalence classes
    – 2 positive values and a negative/zero
      3 positive values such that the sum of two is equal/less
Black Box Testing - Bayu Hendradjaya                             5-Nov-98 14
                         Examples (3)
• How about this instruction in the requirement to calculate



   And what if it is implemented with:




Black Box Testing - Bayu Hendradjaya                5-Nov-98 15
                       Sample Testing
• Sample testing involves selecting a number of values from
  an equivalence class of input data
  Integrate the values into test cases
  These values may be chosen at constant or variable




Black Box Testing - Bayu Hendradjaya              5-Nov-98 16
                         Limit Testing
• Test cases that processing limit values (or singular points)
  Limit values are deduced from equivalence classes by
  taking values which are equal to or nearly equal to the
  delimiting values
  Limit test also involves the output data equivalence class



       In the triangle example, the limit test will try to detect
       inequality check (a+b >= c and not a + b > c)




Black Box Testing - Bayu Hendradjaya                    5-Nov-98 17
                 Rules in Limit Testing
• If a condition concerning the input data specifies range,
  write test cases for the delimiter of the range and test cases
  for invalid values near the delimiter
      If the range is [-1.0, +1.0], write the test case for the
      values -1.0, 1.0, -1.001,1.001
  If a condition concerning the input data specifies a number
  of values, write test for the minimum and maximum
  number of values.
      An input file can contain 1 to 255 records, write test
      case for 0, 1, 255 and 256, or test the empty record and
      full records cases.


Black Box Testing - Bayu Hendradjaya                  5-Nov-98 18
                   Robustness Testing
• Data are chosen outside the range defined by the

   The purpose of this test is to prove that no catastrophic
   event can be produced by the introduction of an abnormal




Black Box Testing - Bayu Hendradjaya                 5-Nov-98 19
                     Behavior Testing
• A behavior tests is a test for which the result obtained
  cannot be evaluated after a single execution of a CSU
  program, but can be evaluated only after a set of linked
  calls to subprogram (several calls to a given subprogram, a
  call to several different subprogram)




Black Box Testing - Bayu Hendradjaya               5-Nov-98 20
                  Requirement Testing
• The requirement associated with the software
  (input/output/function/performance) are identified during
  the software specification and design activities.
  Requirement testing involves producing a test case for
  each requirement relating to CSU
  To facilitate the implementing of such tests, each
  requirement may be traced to final test case trough the
  traceability matrix




Black Box Testing - Bayu Hendradjaya               5-Nov-98 21
      Cause-effect Relationship Testing
• This technique supplements equivalence testing by
  providing ways of determining and selecting combinations

   It involves representing the input state (cause) and output
   states (effect) deduced from functional requirements
   associated with the CSU in the form of a graph represented
   by logical relationship (decision table), to avoid of having
   defined too many test cases




Black Box Testing - Bayu Hendradjaya                 5-Nov-98 22
      Steps in Cause-effect Relationship

• Break down the requirements into subset within which it
  will possible to work
  Define cause and effect based on the requirement
  Analyze the requirements to make a logical relationship
  Highlight the graph, the impossibilities of combinations of
  cause/effect due to constraint from the requirements
  Convert the graph into a decision table
     Column --> test case
     Row --> cause/effect
  Convert the columns of the decision table into test cases


Black Box Testing - Bayu Hendradjaya                5-Nov-98 23
                  Performance Testing
• Performance testing evaluates the csu’s ability to operate
  correctly with regard to the requirement concerning, for

      data flow, memory size, execution time, etc
   To meet under certain workload or configuration
   conditions, provided, however, that these requirements can
   be reflected at the level of the CSU
   These requirements are defined during specification or
   design activities
   Performance testing may also be used to measure and
   explore the performance limits of a CSU


Black Box Testing - Bayu Hendradjaya                5-Nov-98 24
                    Endurance Testing
• Endurance Testing involves repeating a given test case a
  certain number of times in order to evaluate a CSU’s
  ability to meet requirements.

       the regularity in the accuraccy of certain mathematics
       operations (floating point, rounding off, etc)
       management of system resources (incorrect release of

      input/outputs (within the framework of the validating of
      an input/output layer)
   These requirements are defined during specification or
   design activities
Black Box Testing - Bayu Hendradjaya                 5-Nov-98 25

				
DOCUMENT INFO
Shared By:
Categories:
Tags: Black, Testing
Stats:
views:165
posted:3/9/2010
language:English
pages:25
Description: Black Box Testing