Testing General Requirements DFT Multilevel Testing Testinggeneral requirements

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 /nsec?

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 Scan chain ·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

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

Testing stages (software; hardware stages similar): levels of test___ white box black box integration system development stage code class ER-diag. use case

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