在瀑布模型中，测试是一个独立的、顺序进行的阶段，通常发生在开发的后期。它的核心特征是线性、顺序性和阶段性。整个软件开发过程被严格划分为一系列连续的阶段，每一个阶段的输出作为下一个阶段的输入，如同瀑布一般逐级下落。测试活动紧密嵌入在这些阶段中，并在编码阶段之后集中进行。

各测试阶段详解

如上图所示，在瀑布模型中，集中的“测试阶段”会严格遵循从微观到宏观、从内部到外部的顺序，依次进行以下测试：

1. 单元测试

对应开发阶段：编码。

目标：验证单个程序单元（如函数、类、模块）的正确性。

执行者：通常由开发人员完成。

焦点：代码的内部逻辑和数据结构。

2. 集成测试

目标：将已通过单元测试的模块逐步组装起来，测试模块之间的接口、数据传递和协同工作是否正确。

方法：可以采用自顶向下或自底向上的集成策略。

焦点：接口的完整性和集成的稳定性。

3. 系统测试

目标：在完整的、集成的系统上进行测试，以验证系统是否满足需求规格说明书的要求。

测试范围：包括功能性测试和非功能性测试（如性能测试、安全测试、负载测试、可靠性测试等）。

执行者：独立的测试团队。

焦点：系统的整体行为和外部的可见输出。

4. 验收测试

目标：这是交付前的最后一道测试关卡，为了从用户或客户的角度确认软件是否准备使用，满足合同中规定的所有需求。

执行者：最终用户或客户代表。

焦点：业务的符合度和用户的体验，而不仅仅是技术上的正确性。

瀑布模型阶段化测试的优缺点

优点：

结构清晰，易于管理：测试阶段明确，计划性强，便于安排资源和进度。

文档齐全：每个阶段都有完整的文档输出（如测试计划、测试用例、缺陷报告），测试过程可追溯。

门槛明确：每个阶段都有明确的入口和出口准则（例如，只有所有单元测试通过才能进入集成测试），保证了阶段交付物的质量。

适合需求明确的项目：对于需求固定、变更很少的项目，这种模式可以有条不紊地保证质量。

缺点：

缺陷发现延迟：最大的风险在于，需求和设计阶段产生的缺陷，可能要等到项目后期的测试阶段才被发现，此时修复成本非常高。

灵活性差，难以应对变更：一旦进入测试阶段，再要回溯修改需求或设计，代价巨大，几乎不可行。

测试压力集中：所有测试活动都堆积在项目后期，如果前期进度延误，测试时间会被严重压缩，导致测试不充分，质量风险高。

客户反馈滞后：客户直到验收测试阶段才能看到可运行的软件，可能导致最终产品与客户预期不符。

瀑布模型的“阶段化测试”是一种传统的、严谨的、计划驱动的测试方法。它在需求极其稳定、定义清晰的项目（如安全关键系统、某些政府项目）中依然有其价值。然而，在当今快速变化的市场环境下，其固有的滞后性和僵化性使得它难以适应频繁的需求变更。因此，在许多现代软件开发中，它已被更灵活、测试活动更前置（左移）的敏捷或DevOps模式所取代。理解这种模型，有助于我们更好地把握软件测试发展的脉络和不同模型下的测试方式。