Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

testing

310 views

Published on

  • Be the first to comment

  • Be the first to like this

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

×