瀑布开发模式---测试

　　瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。 　　瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。

　　1、瀑布模型有以下优点：

　　1）为项目提供了按阶段划分的检查点。

　　2）当前一阶段完成后，您只需要去关注后续阶段。

　　3）可在迭代模型中应用瀑布模型。

　　增量迭代应用于瀑布模型。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

　　2、瀑布模型有以下缺点：

　　1）在项目各个阶段之间极少有反馈。

　　2）只有在项目生命周期的后期才能看到结果。

　　3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

　　尽管瀑布模型招致了很多批评，但是它对很多类型的项目而言依然是有效的，如果正确使用，可以节省大量的时间和金钱。对于您的项目而言，是否使用这一模型主要取决于您是否能理解客户的需求以及在项目的进程中这些需求的变化程度，对于经常变化的项目而言，瀑布模型毫无价值，对于这种情况，您可以考虑其他的架构来进行项目管理，比如名为螺旋模型（spiral model）的方法。

　　在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

        按照瀑布模型的阶段划分，软件测试可以分为单元测试(模块测试)，集成测试（组装测试，或子系统测试），系统测试。具体测试如下：

瀑布模型开发阶段
阶段	主要工作	应完成的文档	应完成的文档质量控制手段
系统需求	调研用户需求及用户环境	可行性报告	规范工作程序及编写文档
	论证项目可行性	项目初步开发计划	对可行性报告及项目初步
	制定项目初步计划
	开发计划进行评审
需求分析	确定系统运行环境	需求规格说明	在进行需求分析时采用成熟的技术与工具，如结构化分析
	建立系统逻辑模型	项目开发计划	规范工作程序及编写文档
	确定系统功能及性能要求	用户手册概要	对已完成的4种文档进行评审
	编写需求规格说明、用户手册概要、测试计划	测试计划
	确认项目开发计划
概要设计	建立系统总体结构，划分功能模块	概要设计说明书	在进行系统设计时采用先进的技术与工具，如结构化计SD、结构图SC
	定义各功能模块接口	数据库设计说明书（如果有）	编写规范化工作程序及文档
	数据库设计（如果需要）
	制定组装测试计划	组装测试计划
	对已完成的文档进行评审
详细设计	设计各模块具体实现算法	详细设计说明书	设计时采用先进的技术与工具，如结构图SC
	确定模块间详细接口	模块测试计划	规范工作程序及编写文档
	制定模块测试方案	对已完成的文档进行评审
实现	编写程序源代码	程序调试报告	在实现过程中采用先进的技术与工具，如结构图SC
	进行模块测试和调试	用户手册	规范工作程序及编写文档
	编写用户手册
	对实现过程及已完成的文档进行评审
集成测试	执行集成测试计划	系统源程序清单	测试时采用先进的技术和工具
	编写集成测试报告	集成测试报告	规范工作程序及文档编写
验收测试	测试整个软件系统（健壮性测试）	确认测试报告
	试用用户手册	用户手册
	编写开发总结报告	开发工作总结	对测试工作及已完成的文档进行评审
维护	为纠正错误，完善应用而进行修改	故障报告	维护时采用先进的工具
	对修改进行配置管理	修改报告	规范工作程序及编写文档
	编写故障报告和修改报告	配置管理
	修订用户手册		对维护工作及已完成的文档进行评审