1. Testing: General Requirements, DFT, Multilevel Testing Testing: General Requirements DFT Multilevel Testing-- System, Black Box, White Box Tests

2. Testing--General Requirements and Strategies Testing--general requirements: thorough ongoing DEVELOPED WITH DESIGN (DFT--design for test) note: this implies that several LEVELS of testing will be carried out efficient Testing: general strategies: Fault avoidance: reduce possibility of faults through techniques such as configuration management, good development process Fault detection: use debugging and testing to find and remove faults Fault tolerance: use techniques such as redundant modules, let them “vote” on what the output should be

3. Efficiency / How Thoroughly Can We Test? Testing is difficult: example: VLSI chip--200 inputs; 2000 flipflops (one-bit memory cells) # exhaustive tests? What is the overall time to test if we can do1 test / msec? 1 test /  sec?  test  sec? Testing functionality (as with the above chip) is an example of an NP-complete problem, i.e., a problem for which the only algorithms we know to actually find the answer would take time exponential in the problem size Testing software is even harder, there are usually semantic issues which are difficult to deal with

4. Good, Bad, and Successful Tests “Psychology of testing”: good test: has a high probability of finding an error ("bad test": not likely to find anything new) successful test: finds a new error

5. Most Effective Testing Is Independent most effective testing: by an "independent” third party It is more difficult to “see” the errors you have included in your own work: --subconsciously you want the system to work --you may know what you intended and overlook what is actually there --an independent tester brings a fresh viewpoint to the question of what works and what doesn’t --testing requires expertise; common practice of putting the most inexperienced team members in charge of testing is not really effective Question: what does this imply about your team testing strategy for the quarter project?

6. Automated Testing Automated testing Testing must be thorough and must be repeated frequently during development. Thus it is a good candidate for automation. Example system for automated testing in Java:JUnit (Fig. 11-29) TestCase ConcreteTestCase TestResult Test run (TestResult) TestSuite

7. Testing—UML extension Example: U2TP—UML 2 Testing Profile (2005 extension to UML) Extends UML to allow the modeling of testing Can be used with manual or automated testing Example: Figure 11-31: ----Context: organize test cases, test components, system under test (SUT) ----Components: set up tests ----SUT: what is being tested

8. Matching Testing with Design and Language How will testing match with design/language? e.g.: *procedural: example--sort an array *oo: example--develop an "array class” what kinds of test need to be done in each case?

9. Design for Testability (DFT) Design for Testability (DFT)--what makes software "testable"? understandability: you understand module, inputs, and outputs decomposability: you can decompose into smaller problems and test each separately operability: only a few errors possible--incremental test strategy controllability: you can control state + input to test observability: you can see the results of the test simplicity: you choose the “simplest solution that will work” stability: same test will give same results each time

10. Testing strategies At different points in the development cycle, tests may have different goals, e.g.: --verification--functions correctly implemented (according to specifications) --validation--we are implementing the correct functions (according to requirements)

11. Spiral design/testing strategy A general design/testing strategy can be described as a "spiral”: requirements  design  code system test  module,integ. tests  unit test (system) (black (white box) box) when is testing complete? One model: "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, Specs/System Tests Design/Integration Tests Code/Unit Tests Design/Module Tests

12. Development and Testing Stages levels of test___ development stage white box code black box class integrationER-diag. systemuse case We will use these stages for the quarter project. We will use a modified XP strategy: ----develop test with design at each stage ----during implementation, all tests must be passed (100%) ----if modifications are made, all tests must be rerun ----if errors are found, new tests must be written to cover them (“regression testing”) ----complete test suite, updated during development, must be maintained

13. Types of testing Types of testing:  white box--"internals” (also called "glass box")  black box—modules and their "interfaces” (also called "behavioral")  system--”functionality” (can be based on specs, use cases)  application-specific-- GUIs Client/Server Real-time Documentation/help

14. Good testing strategy steps in good test strategy: quantified requirements test objectives explicit user requirements clear use "rapid cycle testing" build self-testing software filter errors by technical reviews review test cases and strategy formally also continually improve testing process

15. OO testing strategy OO testing: emphasis is on interfaces use UML tools to support testing strategies and development of test cases --system tests: use cases; quality measurements --black box tests: ER diagrams, object message diagrams, dataflow and state diagrams --white box tests: class and state diagrams, CRC cards

16. Using specifications for system tests System tests should verify that specifications have been met For UML-based strategy: each use case ---> one or more system tests each quality / performance requirement  one or more system tests Additional qualitative or quantitative tests (not from use cases): examples: is system “user-friendly”? are timing requirements met? are available resources sufficient?

17. Using specifications for system tests Example: 1. Place call 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

18. Black box testing--what to test black box testing: test functional requirements of components. Must check:  incorrect or missing components  interface errors  data structures or external data access  behavior /performance errors  initialization and termination errors

19. Black box testing--testing graph start point is usually a graph: objects to be modeled relationships connecting them ("links") link properties example: can use ER diagrams, object message diagrams, state diagrams, with additional information on links as necessary

20. Black box testing--examples Examples: CarGasStation: station P company employee Denotes link that leads to one or more test cases

21. Black box testing techniques Some useful techniques for black box testing: transaction flow data flow state modeling timing modeling (all "dynamic") much testing focuses on "boundary values" between components

22. Black box testing--input partitioning example: equivalence partitioning for input for black box test: condition# ”cases” of input range1 valid, 2 invalid value1 valid, 2 invalid set member1 valid, 1 invalid boolean1 valid, 1 invalid

23. Black box testing guidelines General guidelines: test BOUNDARIES test output also choose "orthogonal” cases if possible

24. White box testing White box testing: we will look at specific strategies later on (e.g., path testing)