Black-box Testing Black-box Testing Categories Types of Black box testing  Equivalence class...

Click here to load reader

download Black-box Testing Black-box Testing Categories Types of Black box testing  Equivalence class Partitioning Equivalence class Partitioning  Boundary Value

of 26

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Black-box Testing Black-box Testing Categories Types of Black box testing  Equivalence class...

  • Black-box TestingBlack-box Testing CategoriesTypes of Black box testingEquivalence class PartitioningBoundary Value AnalysisCause and Effect Decision Table Advantages of Black Box Testing Disadvantages of Black Box Testing

  • Complements white-box testing by uncovering different classes of errorsFocuses on the functional requirements and the information domain of the softwareUsed during the later stages of testing after white box testing has been performedThe tester identifies a set of input conditions that will fully exercise all functional requirements for a programThe test cases satisfy the following:Reduce, by a count greater than one, the number of additional test cases that must be designed to achieve reasonable testingTell us something about the presence or absence of classes of errors, rather than an error associated only with the specific task at hand


  • Incorrect or missing functionsInterface errorsErrors in data structures or external data base accessBehavior or performance errorsInitialization and termination errorsBACK

  • Equivalence class partitioningBoundary value analysisDecision Table based testingCause Effect GraphBACK

  • A black-box testing method that divides the input domain of a program into classes of data from which test cases are derivedAn ideal test case single-handedly uncovers a complete class of errors, thereby reducing the total number of test cases that must be developedTest case design is based on an evaluation of equivalence classes for an input conditionAn equivalence class represents a set of valid or invalid states for input conditions

  • From each equivalence class, test cases are selected so that the largest number of attributes of an equivalence class are exercise at onceInput values to a program are partitioned into equivalence classes. Partitioning is done such that:program behaves in similar ways to every input value belonging to an equivalence class.

  • If the input data to the program is specified by a range of values:e.g. numbers between 1 to 5000. one valid and two invalid equivalence classes are defined. 15000

  • There are three equivalence classes: the set of negative integers, set of integers in the range of 1 and 5000, integers larger than 5000. 15000BACK

  • A greater number of errors occur at the boundaries of the input domain rather than in the "center"Boundary value analysis is a test case design method that complements equivalence partitioningIt selects test cases at the edges of a classIt derives test cases from both the input domain and output domain

  • Some typical programming errors occur: at boundaries of equivalence classes might be purely due to psychological factors. Programmers often fail to see:special processing required at the boundaries of equivalence classes. Programmers may improperly use < instead of
  • For a function that computes the square root of an integer in the range of 1 and 5000:test cases must include the values: {0,1,5000,5001}.15000BACK

  • Testing would be a lot easier:if we could automatically generate test cases from requirements.Work done at IBM:Can requirements specifications be systematically used to design functional test cases?

  • Examine the requirements:restate them as logical relation between inputs and outputs.The result is a Boolean graph representing the relationships called a cause-effect graph. Convert the graph to a decision table:each column of the decision table corresponds to a test case for functional testing

  • Study the functional requirements.Mark and number all causes and effects.Numbered causes and effects:become nodes of the graph. Draw causes on the LHSDraw effects on the RHSDraw logical relationship between causes and effects as edges in the graph.Extra nodes can be added to simplify the graph

  • ABIf A then BACIf (A and B)then CB

  • ACIf (A or B) then CBACIf (not(A and B)) then CB~

  • ACIf (not (A or B))then CBABIf (not A) then B~~BACK

  • Two dimensional mapping of condition against actions to be performedConditions evaluate to BooleanAction corresponds to expected activityThey can be derived from Cause Effect graph tooMap cause as conditionMap effect as action

  • Cause 1Cause 2Cause 3Cause 4Cause 5Effect 1Effect 2Effect 3Test 1Test 2Test 3Test 4Test 5IIIIIIISIXSSSSSPPSISAAAAAPPPAAAAAXXXXXXI

  • Put a row in the decision table for each cause or effect:in the example, there are five rows for causes and three for effects.The columns of the decision table correspond to test cases.Define the columns by examining each effect:list each combination of causes that can lead to that effect.We can determine the number of columns of the decision tableby examining the lines flowing into the effect nodes of the graph.

  • Theoretically we could have generated 25=32 test cases.Using cause effect graphing technique reduces that number to 5.

  • Not practical for systems which:include timing aspectsfeedback from processes is used for some other processes.BACK

  • more effective on larger units of code than glass box testingtester needs no knowledge of implementation, including specific programming languagestester and programmer are independent of each othertests are done from a user's point of viewwill help to expose any ambiguities or inconsistencies in the specificationstest cases can be designed as soon as the specifications are complete


  • only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly foreverwithout clear and concise specifications, test cases are hard to designthere may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already triedmay leave many program paths untestedcannot be directed toward specific segments of code which may be very complex (and therefore more error prone)most testing related research has been directed toward glass box testing