testing

278 views
207 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
278
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

testing

  1. 1. Principles of testing <ul><li>TESTING BASICS: </li></ul><ul><li>Basic principles of testing: </li></ul><ul><li>Testing must be: </li></ul><ul><ul><ul><li>thorough </li></ul></ul></ul><ul><ul><ul><li>ongoing </li></ul></ul></ul><ul><ul><ul><li>developed with design </li></ul></ul></ul><ul><ul><ul><li>efficient </li></ul></ul></ul><ul><li>most effective--independent testing </li></ul><ul><li>exhaustive test--usually not possible </li></ul>
  2. 2. Design for testability (DFT) <ul><li>design for testability (DFT)--what makes software &quot;testable&quot;? </li></ul><ul><ul><ul><li>operability: few bugs, incremental test </li></ul></ul></ul><ul><ul><ul><li>observability: you can see the results of the test </li></ul></ul></ul><ul><ul><ul><li>controllability: you can control state + input to test </li></ul></ul></ul><ul><ul><ul><li>decomposability: you can decompose into smaller problems and test each separately </li></ul></ul></ul><ul><ul><ul><li>simplicity: you choose the “simplest solution that will work” </li></ul></ul></ul><ul><ul><ul><li>stability: same test will give same results each time </li></ul></ul></ul><ul><ul><ul><li>understandability: you understand code, inputs, and outputs </li></ul></ul></ul>
  3. 3. Types of testing <ul><li>Types of testing: </li></ul><ul><ul><ul><li>white box--&quot;internals” (also called &quot;glass box&quot;) </li></ul></ul></ul><ul><ul><ul><li>black box--&quot;interfaces” (also called &quot;behavioral&quot;) </li></ul></ul></ul><ul><ul><ul><li>system--”functionality” (can be based on specs, use cases) </li></ul></ul></ul><ul><ul><ul><li>application-specific-- </li></ul></ul></ul><ul><ul><ul><ul><li>GUIs </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Client/Server </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Real-time </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Documentation/help </li></ul></ul></ul></ul>
  4. 4. Testing strategies testing strategies: verification--functions correctly implemented validation--we are implementing the correct functions (according to requirements)
  5. 5. Spiral design/testing strategy A general design/testing strategy can be described as a &quot;spiral”: requirements  design  code system test  integ. test  unit test (system) (black (white box) box) when is testing complete? One model: &quot;logarithmic Poisson model” f(t)=(1/p)ln(I 0 pt+1) f(t) = cumulative expected failures at time t I 0 = failures per time unit at beginning of testing p = reduction rate in failure intensity START END Requirements/ System Tests Design/ Integration Tests Code/ Unit Tests
  6. 6. OO testing strategy <ul><li>OO testing: </li></ul><ul><ul><li>emphasis is on interfaces </li></ul></ul><ul><ul><li>use UML tools to support testing strategies and development of test cases </li></ul></ul><ul><ul><ul><li>--system tests: use cases; quality measurements </li></ul></ul></ul><ul><ul><ul><li>--black box tests: ER diagrams, object message diagrams, </li></ul></ul></ul><ul><ul><ul><li> dataflow and state diagrams </li></ul></ul></ul><ul><ul><ul><li>--white box tests: class and state diagrams, CRC cards </li></ul></ul></ul>
  7. 7. Good, Bad, and Successful Tests <ul><li>good test: has a high probability of finding an error </li></ul><ul><li>(&quot; bad test&quot;: not likely to find anything new) </li></ul><ul><li>successful test: finds a new error </li></ul><ul><li>most effective testing: </li></ul><ul><li>by an &quot;independent” third party </li></ul>
  8. 8. Black box testing--example <ul><li>Examples: </li></ul>Denotes link that leads to one or more test cases Car GasStation: station P company employee
  9. 9. Black box testing guidelines General guidelines: test BOUNDARIES test output also choose &quot;orthogonal” cases if possible
  10. 10. Using specifications for system tests <ul><ul><li>System tests should verify that specifications have been met </li></ul></ul><ul><ul><li>For UML-based strategy: </li></ul></ul><ul><ul><li>each use case ---> one or more system tests </li></ul></ul><ul><ul><li>each quality / performance requirement  </li></ul></ul><ul><ul><li>one or more system tests </li></ul></ul><ul><ul><li>Additional qualitative or quantitative tests (not from use cases): </li></ul></ul><ul><ul><li>examples: is system “user-friendly”? </li></ul></ul><ul><ul><li>are timing requirements met? </li></ul></ul><ul><ul><li>are available resources sufficient? </li></ul></ul>
  11. 11. Using specifications for system tests <ul><ul><li>Example: </li></ul></ul>2. Receive call 3. Use scheduler Cellular network User Associated sequence diagrams 1. 2. 3. Associated test cases 1. 2. 3. 3 use cases Tests verify use case supported 1. Place call

×