Software Testing Techniques


Published on

Learn about Software Testing Techniques

Published in: Technology
  • it is really a nice effort about software testing techniques. Well done Bill

    Its all about SQA
    Are you sure you want to  Yes  No
    Your message goes here
  • Bill, Very nice presentation. You cover a lot of grounds in very few slides. Naturally, it is not possible to cover every important test design techniques in 18 slides. One topic in particular that has been proven to double tester productivity is combinationatorial testing (including pairwise, n-wise, and orthogonal array-based techniques). This approach has consistently been proven to be extremely effective but even most Fortune 100 companies do not use it regularly. To find out more about this approach (which is complementary to each of the techniques you describe), please see: ----- 1) Slides from a presentation I gave last week to a local group of testers: ----- 2) An article I co-authored that cites 10 projects that measured what happened to tester productivity when they implemented this approach. Productivity increased by 2.4X): ----- 3) Additional articles about combinatorial testing: ----- 4) A tool my company has created to generate efficient sets of test cases. Specifically, users identify ’what’ they want to test for, hit a button, and our Hexawise test case generator will tell you what to test in what combination in each test case in order to achieve maximum coverage in the fewest possible number of tests:


    - Justin
    Are you sure you want to  Yes  No
    Your message goes here
  • Really nice presentation. Good and pricise.. Thank u. Regards, Raja. -Software Testing
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Testing Techniques

  1. 1. Software Testing Techniques Bill Bond 4/17/03
  2. 2. Overview <ul><li>This week - examine detailed testing techniques (technology) </li></ul><ul><li>Next week - discuss strategies that can be used to apply techniques (framework) </li></ul>
  3. 3. Objectives <ul><li>Testing - executing a program with the intent of finding an error </li></ul><ul><li>Good test case - high probability of finding an as-yet undiscovered error </li></ul><ul><li>Successful test - uncovers an as-yet undiscovered error </li></ul><ul><li>A destructive process </li></ul>
  4. 4. Two ways <ul><li>White box - Knowing internal working, verify operation of all the pieces, all the paths, early stages of testing </li></ul><ul><li>Black box - Knowing function desired, verify that function is fully operational, late stages of testing </li></ul>
  5. 5. Limitations <ul><li>Testing can not prove the absence of defects only that software defects are present </li></ul><ul><li>It is impossible to exercise “all” combinations </li></ul><ul><ul><li>Even small programs would take years </li></ul></ul>
  6. 6. White Box Testing <ul><li>Derive test cases to </li></ul><ul><ul><li>Exercise all independent paths in module all least once </li></ul></ul><ul><ul><li>Exercise all logical decisions on true and false sides </li></ul></ul><ul><ul><li>Execute loops on boundaries and within operational bounds </li></ul></ul><ul><ul><li>Exercise internal data structures </li></ul></ul>
  7. 7. Black Box Testing <ul><li>Focus on functionality and interface </li></ul><ul><ul><li>Incorrect, missing functions </li></ul></ul><ul><ul><li>Interface errors </li></ul></ul><ul><ul><li>Errors in data structures / external DB access </li></ul></ul><ul><ul><li>Performance errors </li></ul></ul><ul><ul><li>Initialization / termination errors </li></ul></ul>
  8. 8. Basis Path Testing <ul><li>Determine complexity </li></ul><ul><li>Test each execution path (execute every statement once) </li></ul><ul><li>Flow graph </li></ul><ul><ul><li>Nodes - one or more procedural statements </li></ul></ul><ul><ul><li>Arcs - (edges) - flow of control (flow chart arrows) </li></ul></ul><ul><ul><li>Edges must terminate at node (even if null) </li></ul></ul>
  9. 9. Graphs Sequence If While Until Case
  10. 10. More Definitions <ul><li>Region - Area bounded by edges and nodes (area outside “all” regions is also counted as a region) </li></ul><ul><li>Predicate node - node that contains a condition </li></ul>
  11. 11. Special Case Separate node created for each condition in “ if a or b then x else y” a b x x y
  12. 12. Cyclomatic Complexity <ul><li>Provides a quantitative measure of logical complexity </li></ul><ul><li>Defines number of independent paths in basis set ( upper bound on number of tests ) </li></ul><ul><li>Independent path - introduces a new set of processing statements or new condition (moves along a new edge) </li></ul><ul><li>Basis set - set of independent paths: all statements executed, all conditions tested </li></ul>
  13. 13. Cyclomatic Complexity <ul><li>V(G) = number of regions </li></ul><ul><li>V(G) = edges - nodes + 2 </li></ul><ul><li>V(G) = predicate nodes + 1 </li></ul>
  14. 14. Deriving Test Cases <ul><li>Use design or code - draw flow graph </li></ul><ul><li>Determine cyclometric complexity </li></ul><ul><li>Determine basis set of paths </li></ul><ul><li>Prepare test cases to force execution of each path </li></ul>
  15. 15. How Many Test Cases?
  16. 16. How Many Test Cases?
  17. 17. Equivalence Partitioning <ul><li>Divide input domain into classes of data </li></ul><ul><li>Select test that represents class of data </li></ul><ul><li>Uncover a class of errors </li></ul><ul><li>Valid / Invalid states </li></ul><ul><ul><li>Range </li></ul></ul><ul><ul><li>Specific value </li></ul></ul><ul><ul><li>Set </li></ul></ul><ul><ul><li>Boolean </li></ul></ul>
  18. 18. Boundary Value Analysis <ul><li>Errors occur at class boundaries </li></ul><ul><li>Concentrate on boundaries </li></ul><ul><ul><li>Range (a, b) - a, b, above, below </li></ul></ul><ul><ul><li>Set - min, max, above, below </li></ul></ul><ul><ul><li>Exercise data structures at boundary - example array of 100 elements </li></ul></ul>