Black Box Testing

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)


Black Box Testing. Csci 565 Spring 2009. Objectives. Decision Table-Based Testing Cause-Effect Graphs in Functional testing Equivalence Partitioning and Boundary value Analysis State transition testing (revisited) Input validation and Syntax-driven Testing. - PowerPoint PPT Presentation

Transcript of Black Box Testing

  • Csci 565Spring 2009Black Box Testing

  • ObjectivesDecision Table-Based TestingCause-Effect Graphs in Functional testingEquivalence Partitioning and Boundary value AnalysisState transition testing (revisited)Input validation and Syntax-driven Testing

  • Decision table-based Testing (DTT)Applicable to the software requirements written using if-then statementsCan be automatically translated into codeAssume the independence of inputsExampleIf c1 AND c2 OR c3 then A1

  • Sample of Decision tableA decision table is consists of a number of columns (rules) that comprise all test situationsAction ai will take place if c1 and c2 are true


  • 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 important

  • 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 are 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 and B)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 SymbolsabE: at most, one of a and b can be 1abO: Exactly one of A and B can be invokedabI: at least one of a or b must be 1 O

  • Example: ATMFor a simple ATM banking transaction systemCauses (inputs)C1: Command is creditC2: command is debitC3: account number is validC4: transaction amount is validEffectsE1: 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 trueXOREffect occurs if one of input is trueNegationEffect occurs if input are false (0)

  • ATM Cause-effect decision tableDont Care condition


  • More ExampleConsider the following NL specifications:The boiler should be shut down if any of the following conditions occurs:If the water level in a boiler is below the 20000lb markThe water level is above the 120000 lb, orThe boiler is operating in degraded mode and the steam meter failsBeing in degraded mode means :If either water pump or a pump monitors fails

  • Example 3: Translate NL into workable pieces (atomic specifications)Atomic sentences areC1. the water level in boiler is below the 20000 lb (F/T)C2. the water level is above the 120000 lb mark (F/T)C3. A water pump has failed (F/T)C4. A pump monitor has failed (F/T)C5. Steam meter has failed/TE. Shut the boiler down

  • Steps to create cause-effect graphStudy the functional requirements and divide the requirements into workable piecesE.g. of workable piece, in eCom, can be verifying a single item placed in shopping cartIdentify 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

  • Possible research topics based on CEGComparison of CEG ,FSM-based test sets, and randomly generated test cases (functional)For effectiveness in terms of cost and fault detection capabilitiesFor fault detection capabilitiesFor number of test cases generated (cost)For automatic generation of actual test cases

  • Black-box testing

  • Equivalence partitioningInput 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 should be chosen from each partition (or class)

  • Equivalence partitioning

  • Guidelines for equivalence classesIf an input condition specifies range, one valid and two invalid equivalence classes are neededIf a 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 modemUser should provide six-digit passwordNeed to follow a set of typed commands

  • Data formatSoftware acceptsArea code: blank or three-digitPrefix: three-digit number not beginning with 0 or 1Suffix: four digits numberPassword: six digit alphanumeric valueCommand: {check, deposit, bill pay, transfer etc.}

  • Input conditions for ATMInput conditions: phone numberArea 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 length)Password: Boolean: password may or may not be presentValid-value: six 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 values for a and b The values just above and just below a and b 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

  • Valid partitionsThe valid partitions can be0
  • Invalid partitionsThe most obvious partitions areExam mark > 75Exam mark < 0Coursework mark > 25Coursework mark
  • Exam mark and c/w mark

  • Less obvious invalid input EPinvalid INPUT EP should include

  • Partitions for the OUTPUTSEP for valid OUTPUTS should include

  • The EP & Boundary valuesThe EP and boundaries for total mark

  • Unspecified OutputsThree unspecfied Outputs can be identified (very subjective)Output = EOutput = A+Output = null

  • Total PE

  • Test Cases corresponding to PE exam mark (INPUT) ( test cases 1, 2,3 )

  • Test Case 4-6 (coursework)

  • test case for Invalid inputs (7 to 10)

  • Test cases for invalid outputs:11 to 13 test case

  • Test cases for invalid outputs:2

  • Test cases for invalid outputs:3

  • Minimal Test cases:1

  • Minimal Test cases:2

  • Syntax-Driven testing (SDT)Applicable to Specification validation written by a certain grammar (BNF)Test generationGenerate test cases such that each production rule is tested at least once

  • Example: BNF of simple Arithmetic expressionsExample ::= + | - | ::= * | / | ::= | ()::= a|b||z

  • More on SDTThe set of test cases for SDT should include expressions that exercise the ALL production rulesExamples:a+b * c + + * + * + * + * (w+v) + z

  • Strings errorsEven small specification may result in many stringsStrings errors can be classified asSyntax errorDelimiter errorsField-value errors