Black Box Testing

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)


Black Box Testing. Csci 565 Chapters 5-7. Objectives. Systematic Specification-based testing Decision Table-Based Testing Cause-Effect Graphs in Functional testing Equivalence Partitioning and Boundary value Analysis Input validation and Syntax-driven Testing. Black box testing. - PowerPoint PPT Presentation

Transcript of Black Box Testing

  • BLACK BOX TESTINGCsci 565Chapters 5-7

  • ObjectivesSystematic Specification-based testingDecision Table-Based TestingCause-Effect Graphs in Functional testingEquivalence Partitioning and Boundary value AnalysisInput validation and Syntax-driven Testing

  • Black box testingBlack box testingAlso known as data-driven or input/output driven testingViews the software as a black boxAims at finding cases in which the software does not behave according to its specifications or requirementsTest data are derived from the specifications(no need for taking advantage of knowledge of code)The main criterion is exhaustive input testing!!!!

  • Decision table-based Testing (DTT)Applicable to the software requirements written using if-then statementsCan be automatically translated into codeConditions = inputsActions = outputsRules = test casesAssume the independence of inputsExampleIf cond1 AND cond2 OR cond3 then Action1

  • Sample of Decision tableA decision table consists of a number of columns (rules) that comprise all test situationsAction ai will take place if c1 and c2 are trueExample: the triangle problemC1: a, b,c form a triangleC2: a=bC3: a= cC4: b= cA1: Not a triangleA2:scaleneA3: IsoscelesA4:equilateralA5: impossible

  • r1r2rnC1110c2110C3-11C4-10A1100A2001A3000A4011A500

  • Test cases from Decision Tables

    Test Case IDabcExpected outputDT1412Not a TriangleDT2288828882888EquilateralDT3?|)ImpossibleDT4


  • Example: Simple editorA simple text editor should provide the following featuresCopyPasteBoldfaceUnderline

  • In general, for n conditions, we need 2n rules


  • Decision tables as a basis for test case designThe use of decision-table model to design test cases is applicableThe spec is given by table or is easily converted to oneThe order in which the conditions are evaluated does not affect the interpretation of rules or the resulting actionThe order in which the rules are evaluated does not affect the resulting actionOnce a rule has been satisfied and an action is selected, no other rule need be examinedIf multiple actions result from the satisfaction of a rule, the order in which the actions take place is not importantInconsistency problem and nondeterministic tableWhen two rules with same conditions elevated to two different actions then the whole decisions tables is nondeterministic because it is difficult to decide which rule should be applied

  • The implications of rulesThe above conditions have the following implicationsRules are complete (i.e., every combination of decision table values including default combinations are inherent in the decision table)The rules are consistent (i.e., there is not two actions for the same combinations of conditions)

  • Cause-effect graphs in black box testingCaptures the relationships between specific combinations of inputs (causes) and outputs (effects)Deals with specific cases Avoids combinatorial explosionExplore combinations of possible inputsCauses/effects represented as nodes of a cause effect graphThe graph also includes a number of intermediate nodes linking causes and effects

  • Drawing Cause-Effect GraphsABIf A then B (identity)ACIf (A=true and B=true)then CB

  • Drawing Cause-Effect GraphsACIf (A or B) then CBACIf (not(A AND B)) then CB

  • Drawing Cause-Effect GraphsACIf (not (A OR B))then CBABIf (not A) then B

  • Constraint Symbolsabat most, one of a and b can be 1 (i.e., a and b cannot be 1 at the same time)abExactly one of A and B can be 1abat least one of a, or b must be 1 (i.e., a and b cannot be 0 at the same time)OIE

  • Example: ATMFor a simple ATM banking transaction systemCauses (inputs)C1: command is creditC2: command is debitC3: account number is validC4: transaction amount is validEffects (outputs)E1: print invalid commandE2: print invalid account numberE3: print debit amount not validE4: debit accountE5: credit account

  • C1C4C3C2andandandandE3E2E1E5E4or

  • Description of processing nodes used in a Cause-effect graph()

    Type of processing nodedescriptionANDEffect occurs if all input are true (1)OREffect occurs if both or one input is trueXOCEffect occurs if one of input is trueNegationEffect occurs if input are false (0)

  • ATM Cause-effect decision tableDont Care condition


  • C/E: Print Message problemThe "Print message" is a software that read two characters and, depending of their values, messages must be printed.

    The first character must be an "A" or a "B". The second character must be a digit. If the first character is an "A" or "B" and the second character is a digit, the file must be updated. If the first character is incorrect (not an "A" or "B"), the message X must be printed. If the second character is incorrect (not a digit), the message Y must be printed.

  • Step 1: Identify Causes and EffectCauses: 1 - first character is "A" 2 - first character is "B" 3 - second character is a digit

    Effects: 70 - the file is updated 71 - message X is print 72 - message Y is print

  • Step 2: Draw the Graph

  • Step 2: Improved GraphExclusive Or (i.e., 1 and 2 cannot be true at same time)

  • Step 3: Convert the Graph into Decision table


  • Steps to create cause-effect graphStudy the functional requirements and divide the requirements into workable piecesIdentify causes and effects in the specificationsCauses: distinct input conditionsEffects: an output condition or a system transformations.Assign unique number to each cause and effectUse the semantic content of the spec and transform it into a Boolean graphAnnotate the graph with constrains describing combinations of causes and/or effectsConvert the graph into a limited-entry decision tableUse each column as a test case

  • Black-box testing

  • Equivalence partitioningBlack box testing that involves identifying a small set of input values that produces as many different output conditions as possibleInput data and output results often fall into different classes where all members of a class are relatedEach of these classes is an equivalence partition where the program behaves in an equivalent way for each class memberTest cases design involvesIdentifying all partitions satisfying the input values for a productIdentifying all partitions satisfying the expected outputs for a productSelecting one member value from each partition to maximize complete coverage

  • Equivalence partitioning

  • Guidelines for equivalence classesIf an input condition specifies range, one valid and two invalid equivalence classes are neededIf an input condition requires a specific value, then one valid and two invalid equivalence classes are neededIf an input condition specifies a member of a set one valid and one invalid equivalence class are neededIf an input condition is Boolean, one valid and one invalid class are needed

  • Example: ATMConsider data maintained for ATMUser should be able to access the bank using PC and modem (dialing)User needs to provide eight-digit passwordNeed to follow a set of typed commands representing various transactions

  • Data format for phone(xxx-xxx-xxxx)Software acceptsArea code: blank or three-digitPrefix: three-digit number not beginning with 0 or 1Suffix: four digits numberPassword: eight digit alphanumeric valueCommand: {check, deposit, bill pay, transfer etc.}

  • Input conditions for ATMInput conditionsArea code: Boolean: (the area code may or may not be present)Range: values defined between 200-999Specific value: no value > 905Prefix: range : specific value >200Suffix: Value: four-digit lengthPassword: Boolean: password may or may not be presentvalue : eight char-stringCommand: set containing commands noted previously

  • Boundary Value Analysis (BVA)Complements equivalence partitioningFocuses is on the boundaries of the inputIf input condition specifies a range bounded by a certain values, say, a and b, then test cases should include The value for a The value for bThe values just above aThe values just below a The values just above bThe values just below bThe nominal value If an input condition specifies any number of values, test cases should be exercise the minimum and maximum numbers, the values just above and just below the minimum and maximum values

  • Example 2: Equivalence Partitioning (EP)

  • EP: Process Identify valid partitionsIdentify invalid partitionsIdentify output partitions

  • Input: Valid partitionsThe valid partitions can be0
  • Input: Invalid partitionsThe most obvious partitions areExam mark > 75Exam mark < 0Coursework mark > 25Coursework nark
  • Exam mark and course work (c/w) mark

  • Less obvious invalid input EPInvalid INPUT EP should include

  • Partitions for the OUTPUTSEP for valid OUTPUTS should include


  • The EP and boundariesThe EP and boundaries for total mark

  • Unspecified OutputsThree unspecified Outputs errors can be identified Output = E (errors below zero)Output = A+ (errors exceeding 100)Output = null (errors corresponding to blanks)

  • Total PEsInput partitions for examsInput partitions for course worksOutput partitions for special casesInput partitions for invalid dataOutput partitions for valid data

  • Test Cases corresponding to PE exam mark (INPUT)

  • Test Case 4-6 (coursework)

  • test case