Previous Next Methods Allocation  
4.5 Elementary Method "Black Box Test Case Design" (BBTD)  

  4.5 Elementarmethode "Black-box-Testfallentwurf" (BBTE)

Contents  
  • 1 Identification/Definition of the Method
  • 2 Brief Characteristic of the Method
  • 3 Limits of the Methods Application
  • 4 Specification of the Methods Allocation
  • 5 Interfaces
  • 6 Further Literature
  • 7 Functional Tool Requirements
  • Links to the V-Model Mailinglist
  • 1 Identification/Definition of the Method

    /Myers, 1991/ chap. 2, p. 7; chap. 4, pp. 44-55

    2 Brief Characteristic of the Method

    Objective and Purpose

    The purpose of the Black Box Test Case Design (BBTD) is to discover circumstances under which the assessed object will not react and behave according to the requirements or respectively the specifications.

    Operational Sequence

    The test cases in a black box test case design are deviated from the requirements or respectively the specifications. The object to be assessed is considered as a black box, i. e. the assessor is not interested in the internal structure and the behavior of the object to be assessed.

    It can be differentiated between the following black box test case designs:

    1. Generation of Equivalence Classes

      Objective and Purpose

      It is the objective of the generation of equivalence classes to achieve an optional probability to detect errors with a minimum number of test cases.

      Operational Sequence

      The principle of the generation of equivalence classes is to group all input data of a program into a finite number of equivalence classes so it can be assumed that with any representative of a class it is possible to detect the same errors as with any other representative of this class.

      The definition of test cases via equivalence classes is realized by means of the following steps:

      When defining equivalence classes, two groups of equivalence classes have to be differentiated:

      For valid equivalence classes, the valid input data are selected; in case of invalid equivalence classes erroneous input data are selected. If the specification is available, the definition of equivalence classes is predominantly a heuristic process.

    2. Marginal Value Analysis

      Objective and Purpose

      It is the objective of the marginal value analysis to define test cases that can be used to discover errors connected with the handling of range margins.

      Operational Sequence

      The principle of the marginal value analysis is to consider the range margins in connection with the definition of test cases. This analysis is based on the equivalence classes defined by means of the generation of equivalence classes. Contrary to the generation of equivalence classes, not any one representative of the class is selected as test case but only the representatives at the class margins. Therefore, the marginal value analysis represents an addition to the test case design according to the generation of equivalence classes.

    3. Intuitive Test Case Definition

      Objective and Purpose

      It is the objective of the intuitive test case definition to improve systematically detected test cases qualitatively, and also to detect supplementary test cases.

      Operational Sequence

      Basis for this methodical approach is the intuitive ability and experience of human beings to select test cases according to expected errors. A regulated procedure does not exist. Apart from the analysis of the requirements and the systematically defined test cases (if realized) it is most practical to generate a list of possible errors and error-prone situations. In this connection it is possible to make use of the experience with repeatedly occurred standard errors. Based on these identified errors and critical situations the additional test cases will then be defined.

    4. Function Coverage

      Objective and Purpose

      It is the purpose of the function coverage to identify test cases that can be used to proof that the corresponding function is available and can be executed as well. In this connection the test case concentrates on the normal behavior and the exceptional behavior of the object to be assessed.

      Operational Sequence

      Based on the defined requirements, the functions to be tested must be identified. Then the test cases for the identified functions can be defined.

      Recommendation

      With the help of a test case matrix it is possible to check if functions are covered by several test cases. In order to improve the efficiency of the tests, redundant test cases ought to be deleted.

    3 Limits of the Methods Application

    By applying the method BBTD, it is not possible to detect functions that-though realized in the object to be assessed-are not required.

    4 Specification of the Methods Allocation

    No. Activity Description
    4.1 QA2.3
    Definition of Test Cases
    By applying the method BBTD, test cases for the following objects to be assessed will be defined: Normally, the test cases for the information for the user, diagnosis, and operator manuals are deduced from the function coverage. With the test cases, deviations of the listed operating information from the actually realized system are to be detected.

    For components, modules, and databases the subproduct Assessment Specification.Test Case Description is only covered by the additional application of method WBTD - White Box Test Case Design. For SWCI, DP Segments, and the System the subproduct Assessment Specification.Test Case Description is only completely covered by the additional application of method FMEA - Failure Mode Effect Analysis (in case the reliability requirements are high). For the operating information, the subproduct will be completely covered.

    5 Interfaces

    - not applicable -

    6 Literature

    /Deutsch, 1982/ Software Verification and Validation
    /Myers, 1991/ Methodisches Testen von Programmen
    /Sneed, 1988/ Software-Qualitätssicherung
    /Wallmüller, 1990/ Software-Qualitätssicherung

    7 Functional Tool Requirements

    SQA14 - Generation of Test Cases

    Links to the V-Model Mailinglist

    Mail 0653 - QS-Plan: Fragen zu Festlegung der Kritikalität, Vererbung, Infizierung und zughörigen Dokumenten (653)

    Previous Next This page online  •  GDPA Online  •  Last Updated 06.Mar.2003 by C. Freericks