Software Testing Tecniques


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Testing Tecniques

  1. 1. Software Testing Tecniques By Ersan BİLİK 13 Aug 2006
  2. 2. Why is it important ? <ul><li>Human inabilitiy </li></ul><ul><li>Quality assurance </li></ul><ul><li>Security </li></ul><ul><li>Avoiding Performance Costs </li></ul><ul><li>Avoiding Actions for Damage </li></ul><ul><li>Happy Customers </li></ul><ul><li>Did You Know ? </li></ul><ul><ul><li>Some Testing Process costs more than the system itself such as Nuclear Reactors and Airplane testings. </li></ul></ul>
  3. 3. Objectives <ul><li>Intent of finding an error </li></ul><ul><li>Test case should has a high probability of finding an as-yet undiscovered error. </li></ul><ul><li>Successful test is one that uncovers an as-yet undiscovered error. </li></ul><ul><li>Testing cannot show the absence of defects, it can only show that sofware errors are present. </li></ul>
  4. 4. Principles <ul><li>All tests should be traceable to customer requirements. </li></ul><ul><li>Tests should be planned long before testing begins. </li></ul><ul><li>The Pareto principle applies to software testing. </li></ul><ul><li>Testing should begin “in the small” and progress toward testing “in the large”. </li></ul><ul><li>Exhaustive testing is not possible. </li></ul><ul><li>To be most effective, testing should be conducted by an independent third party. </li></ul>
  5. 5. Testability <ul><li>Simply, how easily a computer program can be tested ? </li></ul><ul><li>Programmers prepare checklist of possible design points, features etc. </li></ul>
  6. 6. Testability Key Points <ul><li>Operability – The better it works, the more efficiently it can be tested. </li></ul><ul><li>Observability – What you see is what you test. </li></ul><ul><li>Controllability – The better we can control the </li></ul><ul><li>Software, the more testing can be automated and optimized. </li></ul><ul><li>Decomposability – By controlling the scope of testing, the more testing can be automated and optimized. </li></ul><ul><li>Simplicity – The less there is to test, the more quickly we can test it. </li></ul><ul><li>Stability – The fewer the changes, the fewer the disruptions to testing. </li></ul><ul><li>Understandability – The more information we have, the smarter we will test. </li></ul>
  7. 7. TEST CASE DESIGN <ul><li>A good test case reduces time and effort. </li></ul><ul><li>Any engineered product can be tested in two ways. </li></ul><ul><ul><li>Knowing the specified function that a product has been designed to perform, tests can be conducted that demonstrate each function is fully operational. </li></ul></ul><ul><ul><li>Knowing the internal workings of a product, test can be conduct to ensure that “all gears mesh”. </li></ul></ul><ul><li>The first test approach is called black-box testing and the second, white-box testing. </li></ul>
  8. 8. WHITE BOX TESTING <ul><li>Usually done by programmer. </li></ul><ul><li>Guarantee that all independent paths within a module have been exercised at least once. </li></ul><ul><li>Exercise all logical decisions on their true and false sides. </li></ul><ul><li>Exercise internal data structures to assure their validity. </li></ul><ul><li>100% testing is impossible. </li></ul><ul><li>Only a limited number of important logical paths can be selected and exercised. </li></ul>
  9. 9. BASIS PATH TESTING <ul><li>A white-box testing technique. </li></ul><ul><li>Proposed by Tom McCabe. </li></ul><ul><li>Simply, derives a logical complexity measure of a procedural desing which helps creating test cases to exercise basis set are guaranteed to execute every statement in the program at least one time during the test. </li></ul>
  10. 10. Flow Graph Notation <ul><li>A simple notation for the representation of control flow which can be used to use basis path method. </li></ul><ul><li>Simply, shows the control structure of the program. </li></ul><ul><li>Show how to convert this flowchart into a flow graph notation if there is time. </li></ul>
  11. 11. Cyclomatic Complexity
  12. 12. Cylomatic Complexity Cyclomatic complexity for addClass() Statement C# Java If…Else 0 0 Select…Case 0 0 For… 0 0 Do…While 1 1 For each… 0 0 Total Complexity 2 2 Results C# Java CC 2 2 Bad Fix Probability %5 %5 Risk Low Low Type of procedure A simple procedure A simple procedure Conclusion The CC results are stable.
  13. 13. Cyclomatic Complexity Cyclomatic complexity for addForm() Statement C# Java If…Else 16 18 Select…Case 0 0 For… 0 0 Do…While 0 0 For each… 0 0 Total Complexity 17 19 Results C# Java CC 17 19 Bad Fix Probability %10 %10 Risk Moderate Moderate Type of procedure A more complex procedure A more complex procedure Conclusion In C# language each event has their on method. Therefore Java uses only specific methods to the specific event. The event mechanism in java handled by if statement in the specific events methods by getting source of the objects name.
  14. 14. Deriving Test Cases <ul><li>Using the design or code as a foundation, draw a corresponding flow graph. </li></ul><ul><li>Determine the cyclomatic complexity of the resultant flow graph. </li></ul><ul><li>Determine a basis set of linearly independent paths. </li></ul><ul><li>Prepare test cases that will force execution of each path in the basis set. </li></ul>
  15. 15. Graph Matrices <ul><li>A matrice with a size of n x n </li></ul><ul><li>( n= Σ nodes) </li></ul><ul><li>One side of N = Node , Other side = Connected to Node. </li></ul><ul><li>We can determine CC and derive test case. </li></ul><ul><li>Demonstrate if we have time. </li></ul>
  16. 16. Control Structure Testing <ul><li>Condition testing </li></ul><ul><ul><li>Test Case design method that exercises the logical conditions contained in a program. </li></ul></ul><ul><ul><li>E1 (relational-operator) E2 </li></ul></ul><ul><li>Data Flow Testing </li></ul><ul><ul><li>Selects test paths of a program according to the locations of definitions and uses of variables in the program. </li></ul></ul><ul><li>Loop Testing </li></ul><ul><ul><li>Focuses exclusively on the validity of loop constructs. </li></ul></ul>
  17. 17. BLACK BOX TESTING <ul><li>Focuses on the functional requirements of the software. </li></ul><ul><ul><li>Incorrect or Missing functions </li></ul></ul><ul><ul><li>Interface errors </li></ul></ul><ul><ul><li>Errors in data structures or external data base access </li></ul></ul><ul><ul><li>Performance errors </li></ul></ul><ul><ul><li>Initialization and termination errors. </li></ul></ul>
  18. 18. Graph-Based Testing Methods <ul><li>Show objects as nodes. </li></ul><ul><li>Show links between objects. </li></ul><ul><li>Build test cases. </li></ul><ul><li>Test them ! </li></ul>
  19. 19. Equivalance Partitioning <ul><li>Divides the input domain of a program into classes of data from which test cases can be derived. </li></ul><ul><li>Such as checking the possibilites of what objects should have. </li></ul><ul><li>Give bank example. </li></ul>
  20. 20. Boundary Value Analysis <ul><li>Generate test cases from the boundaires of objects. </li></ul><ul><li>Such as knowing the boundaries of a specific object can take. </li></ul><ul><li>Design the test cases. </li></ul>
  21. 21. Comparsion Testing <ul><li>Usually for critical systems. </li></ul><ul><li>Begins after all black-box testing is done. </li></ul><ul><li>If output of the each version is same, it is assumed that all implementations are correct, else investigate to determine if a defect in one or more versions is reponsible for the difference. </li></ul>
  22. 22. Specialized enviroments and applications <ul><li>Testing GUI`s </li></ul><ul><li>Testing of Client/Server Architechtures. </li></ul><ul><li>Testing Documetation and Help Facilities. </li></ul><ul><li>Testing for Real-Time Systems. </li></ul>
  23. 23. Common Test Findings
  24. 24. Conclusion <ul><li>Testing is a difficult process. </li></ul><ul><li>White Box testing focuses on logical operations. </li></ul><ul><li>Black Box testing focuses on functionalities of program. </li></ul><ul><li>Understandability is a must. </li></ul><ul><li>Tests should be neither more simple nor so complex. </li></ul><ul><li>Thinking every possibility is important. </li></ul>
  25. 25. Questions / Comments <ul><li>Any questions or comments are highly appericiated. </li></ul>