Software Testing Verification and Validation:软件测试验证和确认
Ch.19 - Verification & Validation Software Testing: Verification and Validation Verification “Are we building the product right?” Validation “Are we building the right product?” Barry Boehm, 1979 Verification and ValidationTechniques Static Techniques Software Inspections(against source code) Dynamic Techniques Software Testing(requires executable program) Verification and ValidationStatic techniques Software Inspections of requirements documents of design documents (design reviews) of source code (code reviews) automated static analysis Verification and ValidationDynamic techniques Software Testing specification vs. implementation Defect testing [Ch.20] verifying non-functional requirements (e.g. performance; reliability) Statistical testing [Ch.21] automated dynamic analysis (if applicable) Verification and ValidationGoals Establish that software is fit for purpose,not “bug-free” “Good enough” depends on: Software function (critical nature?) User expectations Market competition, price Testing vs. Debugging Verification and Validation looking and categorizing existence of system defects [example] [bug list] “What?” Debugging locating and correcting these defects “Why?” Regression Testing Canned test runs to verify that new defects were not introduced during “debugging” session. Not exhaustive Targeted to a particular interface components, sub-systems, integrated system Different levels (lengths) of regression tests Targeted regressions The Test Plan Planning should begin right after requirements specification Acceptance tests can be written then System, sub-system tests can be written against designs The Test Plan Software Inspections (code reviews) >60% of program errors can be detected in code review [Fagan86] >90% if more formal approach used (e.g. “Cleanroom” process) [Mills87] (We’ll talk about Cleanroom later) Software Inspections (code reviews) Why are reviews more effective for finding defects in systems/subsystems (i.e., before acceptance tes