前面提到Glenford J. Myers，他早期给软件测试的简单定义是：“程序测试是为了发现错误而执行程序的过程”，也体现出当时对软件测试的认识非常具有局限性。这也是受软件开发瀑布模型的影响，认为软件测试是编程之后的一个阶段。只有等待代码开发出来之后，通过执行程序，像用户那样操作软件发现问题，这就是“动态测试”。

对于需求阶段产生的缺陷，在不同阶段发现和修复的成本是不一样的。如果在需求阶段发现需求方面的缺陷并进行修复，只要修改需求文档，其成本很低。需求阶段产生的缺陷，如果在需求阶段没有发现，等待设计完成之后才被发现，就需要修改需求和设计，成本增大。需求阶段产生的缺陷，如果在需求和设计阶段都没有发现，等待代码写完之后才被发现，就需要修改需求、设计、代码，成本就更大。设计上的问题，在设计阶段被发现，只要修改设计，如果在后期发现，返工的路径就变长了，其修复的成本自然就增大。缺陷发现得越迟，其修复的成本就越高，如图1-1所示，呈现了不同阶段产生的缺陷在不同阶段修复的成本，所以这要求我们尽早发现缺陷。

为了尽早发现缺陷，我们有必要将软件测试延伸到需求、设计阶段，即对软件产品的阶段性成果——需求定义文档、设计技术文档进行评审或验证。这不同于软件质量保证（Quality Assurance，QA），虽然QA侧重评审，但它重点评审流程、评审管理，包括对需求、设计、编码和测试过程规范性的评审。而这里提到的需求和设计的评审依旧是对软件产品的检验或验证，只是需求文档和设计文档只是软件产品的阶段性产品。如果按照“软件=程序+文档+数据结构”这样的定义，需求文档和设计文档等也属于软件的组成部分，软件测试自然也包括需求和设计的验证。

基于上述考虑，将早期的动态测试延伸到静态测试，即 从狭义的软件测试发展到广义的软件测试。

·狭义的软件测试：动态测试——运行程序而进行的测试，测试只是编程之后的阶段，这也是由传统的瀑布模型而决定的。

·广义的软件测试：动态测试+静态测试，将需求评审、设计评审、代码评审（含代码的静态分析）等也纳入软件测试工作之中。这也使“软件测试”不再停留在编程之后的某个阶段上，而成为贯穿整个软件研发周期的质量保证活动，这也是本书“ 全程软件测试 ”的最早立意所在。

静态测试就是在不运行软件系统时对软件或阶段性成果进行评审，包括需求评审、设计评审、代码评审等。 引入静态测试，就可以尽早地发现问题，把问题消灭在萌芽之中，将每个阶段产生的缺陷及时清除，极大地提高产品的质量，有效地降低企业的成本。 0oelKyEq6JUTkULwhkBC+G117ZpGEQyPMt/HnJ0A/HVgQ1U4pl8BLz7Dk+ecriio