Your SlideShare is downloading. ×
Testing techniques
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Testing techniques

1,170
views

Published on

Published in: Technology, Education

1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,170
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
1
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Finding the Defects that Matter
  • 2. Contents Objective 1 Black Box Testing Technique 2 White Box Testing Techniques 3 Grey Box Testing Techniques 4 Never Ending Techniques 5
  • 3. Objective Rules are SIMPLE , but Walking the WALK is not The objective of this presentation is to understand the various testing techniques so that we can use them effectively
  • 4. Testing Techniques
  • 5. Black-Box Testing Main focus is on functionality of the system as a whole
      • Test cases can be designed as soon as the functional specifications are complete
      • Tests will be done from a end user's point of view. Because end user should accept the system.
      • It is difficult to identify tricky inputs, if the test cases are not developed based on specifications.
      • Chances of having repetition of tests that are already done by programmer.
  • 6. Black-Box Testing Techniques A technique for testing equivalence classes rather than undertaking exhaustive testing of each value of the larger class. A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function. “ A race occurs when two threads can access (read or write) a data variable simultaneously and at least one of the two accesses is a write .” Error Guessing is the art of guessing where errors can be hidden.
  • 7. Equivalence Partitioning Range: Valid Class:1 Invalid Class:2 Specific Value Valid Class:1 Invalid Class:2 Login page , user field can accept 6 to 55 character Valid Class :- 6 ≤ USR ≥ 55 Invalid Class: USR < 6 Invalid Class: USR > 55 If specifications state that a maximum of 4 online books can be registered against anyone session thru instructor. Valid Class: 1 ≤ No. of online books ≥ 4 Invalid Class: No. of online books > 4 Invalid Class: No. of online books < 1
  • 8. Equivalence Partitioning cont… Member of Sets Valid Class:1 Invalid Class:1 Boolean Valid Class:1 Invalid Class:1 If a discount code must be input as P for preferred customer, R for standard reduced rate, or N for none, and if each case is treated differently. Valid class = P, R, N Invalid class code is not one of P, R, N If checkbox is checked or unchecked. Checked/ Unchecked Either True / False Or Yes / No
  • 9. Boundary Value Analysis Extreme Ends of the Range Six Boundary Value
    • Login page of a any site as Goggle, E-Learning portal
    • User field accepts 6 to 55 character
    • Test Cases:
      • Extreme Ends of the Range: 6, 55
      • Just Beyond the Ends: 7, 56
      • Just Before the Ends: 5, 54
    Just Beyond the Ends Just Before the Ends
  • 10. Race Condition What occurs when a number of programs rely on certain timing conditions. A Program can only execute and carry out its task when a second program has completed. If the first program tries to execute before the second program has completed then anomalous results occur. Almost invariably race conditions give rise to anomalous behavior.
  • 11. Error Guessing Process of making an educated guess as to other types of areas to be tested . Intuition Experience The program reads a file. What happens if the program gets an empty file or the file does not exists? Tester would create test cases for those conditions.
  • 12. White-Box Testing Design test cases to exercise as many paths through the code as possible White box testing focuses on the internals of the systems.
  • 13. White Box Testing Techniques Statement Coverage requires that each statement will have been executed at least once. Simplest form of logic coverage. Also known as Node Coverage. Path Coverage requires that all program paths will have been traversed at least once. Condition Coverage requires that each condition will have been True at least once and False at least once. In this white box testing technique we try to identify how many program functions are covered by test cases. So, while providing function coverage, test cases can be written so as to exercise each of different functions in the code.
  • 14. Statement Coverage Example   i = 0 ; if (code = = &quot;y&quot;) { statement –1 ; statement –2 ; : : statement - n ; } else result = {marks / I} * 100 ; In this program, when we test with code = &quot;y&quot;, we will get 80% code coverage. But if the data distribution in the real world is such that 90% of the time, the value of code is not = &quot;y&quot;, then, the program will fail 90% of the time because of the exception-divide by zero. Thus. even with a code coverage of 80%, we are left with a defect that hits the users 90% of the time. The path coverage technique described below overcomes this problem.
  • 15. Cyclomatic Complexity Step – 1: Start writing the following C – program # include <stdio.h> # include <conio.h> (1) int main ( ) (2) { (3) int a, b, c, boolean = 0; (4) printf (&quot;nt Enter side-a :&quot;); (5) scanf (&quot;%d&quot;, & a); (6) printf(&quot;nt Enter side-b :&quot;); (7) scanf (&quot;%d&quot;, & b); (8) printf (&quot;nt Enter side-c:&quot;); (9) scanf (‘'%d&quot;, & c); (10) if ((a > 0) && (a < - 100) && (b > 0) && (b < . 100) && (c > 0) && (c < =100)) { (11) if ((a + b) > c) && ((c + a) > b) && ((b + c) > a)) { (12) boolean = 1; (13) } (14) } (15) else { (16) boolean = -1; (17) }
  • 16. Cyclomatic Complexity cont…... (18) if (boolean = = 1) { (19) if ((a = =b) && (b = =c)) { (20) printf (&quot;Triangle is equilateral&quot;); (21) } (22) else if ((a = =b) I I (b = = c) I I (c = = a)) { (23) print (&quot;Triangle is isosceles&quot;); (24) } (25) else { (26) printf(&quot;Triangle is scalene”); (27) } (28) } (29) else if (boolean = = 0) { (30) printf (&quot;Not a triangle&quot;); (31) } (32) else (33) printf (&quot;n invalid input range&quot;); (34) } (35) getch ( ); (36) return -1; (37) }
  • 17. Cyclomatic Complexity cont…... Step – 2 Draw the following Flow Graph Step – 3: Draw the following DD Path Graph
  • 18. Cyclomatic Complexity cont…... Step – 4: Calculation of Cyclomatic Complexity V(G) by three methods
  • 19. Cyclomatic Complexity cont…... Conclusion 1 Conclusion 2 Each of these paths consists of at least one new edge. Hence this basis set of paths is NOT unique. Test cases should be designed for the independent path execution as identified above . Conclusion 3 We must execute these paths at least once in order to test the program thoroughly.
  • 20. Condition Coverage: This technique of condition coverage or predicate monitors whether every operand in a complex logical expression has taken on every True / False value. Obviously, this will mean more test cases and the number of test cases and the number of test cases will rise exponentially with the number of conditions and Boolean expressions. For example, in if-then-else, there are 2 2 or 4 possible True / False conditions. The condition coverage which indicates the percentage of conditions covered by a set of test cases, is defined by the following formula Condition Coverage = (Total Decisions Exercised) / (Total Number of Decisions in Program) x 100 Thus it becomes quite clear that this technique of condition coverage is much stronger criteria than path coverage, which in turn is a much stronger criteria than statement coverage.
  • 21. Function Coverage: White box Testing Technique we try to identify how many program functions are covered by test cases. So, while providing function coverage, test cases can be written so as to exercise each of different functions in the code.
      • Functions (like functions in C) are easier to identify in a program and
    • hence it is easier to write test cases to provide function coverage.
      • Since functions are at higher level of abstraction than code, it is
    • easier to achieve 100% function coverage.
      • It is easier to prioritize the functions for testing.
      • Function coverage provides a way of testing traceability, that is, tracing
    • requirements through design, coding and testing phases.
      • Function coverage provides a natural transition to black box testing.
  • 22. Function Coverage cont…… Conclusion Better code coverage is the result of better code flow understanding and writing effective test cases. Code coverage up to 40-50% is usually achievable. Code coverage of more than 80% requires enormous amount of effort and understanding of the code.
  • 23. Gray Box Testing Technique
  • 24. Gray Box Testing Technique cont.. Consider a hypothetical case wherein you have to test a web application. Functionality of this web application is very simple, you just need to enter your personal details like email and field of interest on the web form and submit this form . Server will get these details, and based on the field of interest pick some articles and mail it to the given email. Email validation is happening at the client side using Java Scripts.
  • 25. Grey Box Testing Technique cont.. Server will never get invalid mail ID Server will never send mail to invalid ID Server will never receive failure notification for this mail System is making following assumptions
  • 26. Gray Box Testing Technique cont.. Due to any reason if Java Scripts are disabled . Server will get invalid mail ID Server will send mail to invalid mail ID Server will receive failure notification
  • 27. Never Ending Testing Techniques -- Check it out… There are a large number of testing techniques in addition to the defined ones. Try the techniques which best suits your application.
  • 28. Thank You