White Box and Black Box Testing

  • Published on
    02-Jan-2016

  • View
    42

  • Download
    3

Embed Size (px)

DESCRIPTION

White Box and Black Box Testing. Tor Stlhane. What is White Box testing. White box testing is testing where we use the info available from the code of the component to generate tests. This info is usually used to achieve coverage in one way or another e.g. Code coverage Path coverage - PowerPoint PPT Presentation

Transcript

<ul><li><p>White Box and Black BoxTesting Tor Stlhane</p></li><li><p>What is White Box testing White box testing is testing where we use the info available from the code of the component to generate tests.This info is usually used to achieve coverage in one way or another e.g.Code coveragePath coverageDecision coverageDebugging will always be white-box testing </p></li><li><p>Coverage report. Example 1 </p></li><li><p>Coverage report. Example 2 </p></li><li><p>McCabes cyclomatic complexityMathematically, the cyclomatic complexity of a structured program is defined with reference to a directed graph containing the basic blocks of the program, with an edge between two basic blocks if control may pass from the first to the second (the control flow graph of the program). The complexity is then defined as:</p><p>v(G) = E N + 2P</p><p>v(G) = cyclomatic complexityE = the number of edges of the graphN = the number of nodes of the graphP = the number of connected components</p></li><li><p>Graph example We have eight nodes N = 8 nine edges E = 9 and we haveonly one component P = 1.</p><p>Thus, we have v(G) = 9 8 + 2 = 3. </p></li><li><p>Simple case - 1S1;IF P1 THEN S2 ELSE S3S4;</p><p>One predicate P1. v(G) = 2Two test cases can cover all codeS4S3S2S1P1</p></li><li><p>Simple case 2 S1;IF P1 THEN X := a/c ELSE S3;S4;</p><p>One predicate P1. v(G) = 2Two test cases will cover all pathsbut not all cases. What about thecase c = 0?S4S3S1a/cP1</p></li><li><p>Statement coverage 1 IF in_data &gt; 10 {out_data = 4;}ELSE {out_data = 5;}IF out_data == 8 {update_panel();}</p><p>How can we obtain full statement coverage?P1P2S2S1S3empty</p></li><li><p>Statement coverage 2 out_data = 0IF in_data &gt; 10 {out_data = 4;}update_panel();</p><p>If we set in_data to 12 we will have full statement coverage. What is the problem? </p></li><li><p>Decision coverageIF (in_data &gt; 10 OR sub_mode ==3) {out_data = 4;}ELSE {..} </p><p>P1 is really two decisions P1-1: in_data &gt; 10P1-2: sub_mode == 3We need to cover both decisions</p><p>P1P1-1P1-2S1empty empty </p></li><li><p>Using v(G)The minimum number of paths through the code is v(G).As long as the code graph is a DAG Directed Acyclic Graph the maximum number of paths is 2**|{predicates}|</p><p>Thus, we have thatV(G) &lt; number of paths &lt; 2**|{predicates}|</p></li><li><p>Problem the loopS4S2S1P1S5S3P2S1;DO IF P1 THEN S2 ELSE S3; S4OD UNTIL P2S5;</p><p>No DAG. v(G) = 3 and Max is 4 but there is an infinite number of paths.</p></li><li><p>Nested decisions S1;IF P1 THEN S2 ELSE S3; IF P2 THEN S4 ELSE S5FIS6; </p><p>v(G) = 3, while Max = 4. Three test case will cover all paths.</p></li><li><p>Using a decision table 1A decision table is a general technique used to achieve full path coverage. It will, however, in many cases, lead to over-testing. The idea is simple. Make a table of all predicates.Insert all combinations of True / False 1 / 0 for each predicateConstruct a test for each combination. </p></li><li><p>Using a decision table 2 </p><p>P1P2P3Test description or reference 000001010011100101110111</p></li><li><p>Using a decision table 3Three things to remember: The approach as it is presented here is only practical forSituations where we have binary decisions. Small chunks of code e.g. class methods and small components. It will be too laborious for large chunks of code.</p><p>Note that code that is difficult to reach difficult to construct the necessary predicates may not be needed as part of the system. </p></li><li><p>Decision table example binary The last test is not necessary </p><p>P1P2Test description orreference 00S1, S3, S5, S601S1, S3, S4, S610S1, S2, S611S1, S2, S6</p></li><li><p>Decision table example tertiary </p><p>P1P2P3Test description or reference000S1, S3, S9001S1, S4, S9002S1, S5, S9010S1, S3, S9011S1, S4, S9012S1, S5, S9100S2, S6, S8101S2, S6, S8102S2, S6, S8110S2, S7, S8111S2, S7, S8112S2, S7, S8</p></li><li><p>What about loops Loops are the great problem in white box testing. It is common practice to test the system going through each loop 0 times loop code never executed1 time loop code executed once5 times loop code executed several times20 times loop code executed many times</p></li><li><p>Loop diagram for (i; P1; i++) {S1}</p><p>The empty branch is taken when P1 is False</p></li><li><p>Error messagesSince we have access to the code we shouldIdentify all error conditionsProvoke each identified error conditionCheck if the error is treated in a satisfactory manner e.g. that the error message is clear, to the point and helpful for the intended users.</p></li><li><p>What is Black Box testingBlack box testing is also called functional testing. The main ideas are simple:Define initial component state, input and expected output for the test.Set the component in the required state.Give the defined inputObserve the output and compare to the expected output. </p></li><li><p>Info for Black Box testingThat we do not have access to the code does not mean that one test is just as good as the other one. We should consider the following info:Algorithm understandingParts of the solutions that are difficult to implement Special often seldom occurring cases. </p></li><li><p>Clues from the algorithmWe should consider two pieces of info:Difficult parts of the algorithm usedBorders between different types of solution e.g. if P1 then use S1 else use S2. Here we need to consider if the predicate isCorrect, i.e. contain the right variablesComplete, i.e. contains all necessary conditions </p></li><li><p>Black Box vs. White Box testingWe can contrast the two methods as follows:White Box testingUnderstanding the implemented code.Checking the implementation DebuggingBlack Box testingUnderstanding the algorithm used.Checking the solution functional testing</p></li><li><p>Testing real time systemsW-T. Tsai et al. have suggested a pattern based way of testing real time / embedded systems. They have introduced eight patterns. Using these they have shown through experiments that, using these eight patterns, they identified on the average 95% of all defects. We will have a look at three of the patterns.Together, these three patterns discovered 60% of all defects found </p></li><li><p>Patterns and coverage (from Tsai)</p></li><li><p>Basic scenario pattern - BSPCheck for precondition Check post-condition PreCondition == true / {Set activation time}IsTimeout == true / [report fail]PostCondition == true / [report success]</p></li><li><p>BSP example Requirement to be tested:If the alarm is disarmed using the remote controller, then the driver and passenger doors are unlocked.Precondition: the alarm is disarmed using the remote controllerPost-condition: the driver and passenger doors are unlocked</p></li><li><p>BSP testGenerate input to make preconditionFalse =&gt; nothing happensTrue =&gt; input activation timeCheck system responseTimeout = true =&gt; failsTimeout = false and post condition OK =&gt; OKTimeout false and post condition not OK =&gt; fails</p></li><li><p>Key-event service pattern - KSPCheck for key eventCheck post-condition Check precondition PreCondition == truePostCondition == true / [report success]KeyEventOccurred / [SetActivationTime]IsTimeout == true / [report fail]</p></li><li><p>KSP- example Requirement to be tested:When either of the doors are opened, if the ignition is turned on by car key, then the alarm horn beeps three times Precondition: either of the doors are openedKey-event: the ignition is turned on by car keyPost-condition: the alarm horn beeps three times </p></li><li><p>KSP test Generate key eventNot right event =&gt; waitRight event =&gt; set activation time Check preconditionNot OK =&gt; waitOK =&gt; check post conditionCheck post conditionTimeout = true =&gt; failsTimeout = false and post condition OK =&gt; OKTimeout false and post condition not OK =&gt; fails</p></li><li><p>Timed key-event service pattern - TKSPCheck for key eventCheck post-condition Check precondition PreCondition == trueIsTimeout == true / [report fail]PostCondition == true / [report success]KeyEventOccurred / [SetActivationTime]DurationExpired / [report not exercised]</p></li><li><p>TKSP example (1) Requirement to be tested:When driver and passenger doors remain unlocked, if within 0.5 seconds after the lock command is issued by remote controller or car key, then the alarm horn will beep once </p></li><li><p>TKSP example (2)Precondition: driver and passenger doors remain unlockedKey-event: lock command is issued by remote controller or car keyDuration: 0.5 seconds Post-condition: the alarm horn will beep once </p></li><li><p>TKSP test Generate key eventNot right event =&gt; wait for new event or duration expired Right event =&gt; set activation time Check preconditionNot OK =&gt; waitOK =&gt; check post conditionCheck post conditionTimeout = true =&gt; failsTimeout = false and post condition OK =&gt; OKTimeout false and post condition not OK =&gt; fails</p></li><li><p>Test automation 1 </p></li><li><p>Test automation 2 Generate stimuliGet necessary data Collect eventsCheck events </p></li><li><p>Test automation example BSP Illegal command Generate somethingNothing happens =&gt; test OK Post condition = doors unlocked =&gt; test failsLegal commandGenerate alarm disabledActivation time = TTimeout = True =&gt; test fails Timeout = false post condition = doors unlocked =&gt; test OK</p></li><li><p>Needs, models and methods 1 If we say to the developers that they need to do e.g. unit testing this is just a statement of need, it is not a statement of how the method to use. If we say that they should use white box testing, this helps a little, but there is still a lot of freedom when it comes to how. </p></li><li><p>Example white box testingWhite box testing =&gt;Static white box testing =&gt;Code inspectionCode walkthroughDynamic white box testing =&gt;Statement coveragePath coverageDecision coverage All define use coverage</p></li><li><p>Needs, models and methods 2 We can use the following structure to organize the decisions:Strategy or need =&gt; Technique =&gt; MethodThis will be applicable on all levels, e.g. acceptance test, system test, integration tests and unit tests.For unit test we can for instance use:Unit test =&gt; White box test =&gt; Path coverage</p><p>*</p></li></ul>

Recommended

View more >