1 / 15

Dynamic Testing

Dynamic Testing. White Box Testing Techniques. White box testing(1). Source code is known and used for test design While executing the test cases, the internal processing of test object (source code), as well as output is analyzed (PoO is inside test object)

aladdin-blackburn
Download Presentation

Dynamic Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dynamic Testing White Box Testing Techniques

  2. White box testing(1) • Source code is known and used for test design • While executing the test cases, the internal processing of test object (source code), as well as output is analyzed (PoO is inside test object) • PoC can be located inside the test object • Also known as code-based or structural testing techniques • Can be applied at component and integration testing

  3. White Box Testing Techniques(2) Poc and/or PoO “inside” the test object Test input data PoC Test Output data Test object PoO

  4. White box testing(3) • The generic idea is to execute every path of the code at least once • Flow-oriented test cases are identified • Program logic is analyzed and executed • Expected results should be determined using requirements or specification, not source code

  5. White box testing(4) • The basic test case design techniques are: • Statement coverage • Branch coverage

  6. Statement Coverage(1) • A set of paths - that every node lies on at least one path • Focuses on each statement • Steps taken • Translate source code to CFG • Determine the paths • Determine the test cases

  7. Statement Coverage(2) Path: a,b,f,g,h,d,e a b Choose test case that fulfills the path f k c i g h d e

  8. Statement Coverage(3) • Test completion criteria • Statement coverage = (number of executed statement/total number of statement) * 100% • Value of the technique • Unreachable code can be detected • Statement for empty ELSE is irrelevant

  9. Branch Coverage(1) • A set of paths - that every edge lies on at least one path • Focus on edges • Consider the execution of decisions • Result of decision determines which statement is executed next • Testing should make sure every decision is executed with both TRUE and FALSE outcomes • In IF-statement • All possible CASE or SWITCH statement • Loops (execute loop body, bypass loop body, return to beginning of loop)

  10. Branch Coverage(2) • Paths: • a,b,c,d • a,b,f,g,i,g,h,d,e • a,k,e • In addition to statement • coverage can result in complete • coverage. a b f k c i g Choose test cases that fulfill the paths h d e

  11. Branch Coverage(3) • Test completion criteria • branch coverage = (number of executed branch/total number of branches) * 100% • Value of the technique • Requires more test cases than statement coverage • Can detect missing statements in empty branches • 100% branch coverage guarantees 100% statement coverage

  12. Linearly independent path • The execution of set of linearly independent paths • An independent path must move along at least one edge that has not been traversed before the path is defined • Steps taken • Draw a corresponding CFG • Calculate cyclomatic complexity • Determine a basis set of linearly independent paths • Prepare test cases that will force execution of each path in the basis set.

  13. Test of conditions(1) • If a decision is based on several conditions connected by logical operators, then the complexity of the condition should be considered in the test • Branch condition testing • The goal is that each atomic (partial) condition in the test shall adopt the values of TRUE and FALSE • An atomic part of a condition is a condition that has no logical operator, but at the most includes relational symbols

  14. Test of conditions(2) Branch condition testing (example) • Supposed a composed condition is: x > 3 OR y < 5 • Consists of two atomic partial conditions (x > 3; y < 5) • Goal: every atomic part is evaluated once for each of the logical values • The test data x=6 and y=8 result in logical value TRUE for first atomic part and FALSE for the second atomic part; the logical value for complete condition is TRUE • The test data x=2 and y=3 result in logical value FALSE for first atomic part and TRUE for the second atomic part; the logical value for complete condition is TRUE

  15. Test of conditions(3) • Branch condition combination testing (multiple-condition coverage) • Requires that all TRUE-FALSE combinations of the atomic partial conditions be exercised at least once • All variations should be built, if possible • Example from previous slide • Four possible combinations of test cases x=6(T), y=3(F), x>3 OR y<5 (T) x=6(T), y=8(F), x>3 OR y<5 (T) x=2(F), y=3(T), x>3 OR y<5 (T) x=2(F), y=8(F), x>3 OR y<5 (F)

More Related