Testing: General Requirements; DFT; Multilevel Testing

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

good test: has a high probability of finding an error ("bad test": not likely to find anything new) successful test: finds a new error

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

how thoroughly can we test? example: VLSI chip 200 inputs 2000 flipflops (one-bit memory cells) # exhaustive tests? What is the overall time to test if we can do 1 test / msec? 1 test /  sec?  test  sec?

Design for Testability (DFT)--principles  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 Scan chain

Two goals of testing: verification--functions correctly implemented validation--we are implementing the correct functions (according to requirements)

levels of test___ development stage white box code black box class integrationER-diag. systemuse case Testing stages (software; hardware stages similar):

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, e.g., real-time

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