喷泉模型
喷泉模型（Fountain Model）
目录 |
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。采用喷泉模型的软件过程如下图所示：
喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。各活动之间无明显边界，例如设计和实现之间没有明显的边界，这也称为“喷泉模型的无间隙性”。由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙。
喷泉模型是由B．H．Sollers和J．M．Edwards于1990年提出的一种新的开发模型。喷泉模型主要用于采用面向对象技术的软件开发项目，喷泉一词本身就体现了迭代和无间隙的特征。无间隙指在各项活动之间无明显边界，如分析、设计和编码之间没有明显的界限。在编码之前再进行需求分析和设计，期间添加有关功能，使系统得以演化。喷泉模型在系统某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的系统。由于对象概念的引入，需求分析、设计、实现等活动只用对象类和关系来表达，从而可以较为容易地实现活动的迭代和无间隙，并且使得开发过程自然地包括复用。
1、喷泉模型的优点
喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
2、喷泉模型的缺点
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
1.传统的喷泉模型
传统的喷泉模型如下图所示，目前主要应用于面向对象的软件开发中 。该模型的主要特点是认为软件开发的各个阶段是相互重叠和多次反复的，从图中可以看出，软件开发的规格说明阶段、设计阶段、编码阶段和测试阶段可以交叠在一起，同时进行。这体现了各个开发过程的并行关系。喷泉的水可以喷上去又可以落下来，水既可以落在中间，也可以落在底部。这一点在模型中表现为各个测试阶段的并行。喷泉的水不停的喷发、坠落，代表着开发和测试阶段的复杂性和重复性。
2.改进的喷泉模型
在传统喷泉模型的基础上，提出了改进的喷泉模型，如下图所示。以喷泉模型为基础，可以实现尽早的、全面的展开测试，同时将测试工作进行迭代。另外，改进的喷泉将需求纳入，使得模型完全实现了整个开发过程的无边界、交互性。
该模型每一次测试过程包括四个阶段。
第一阶段为测试需求阶段，包括提取和验证需求。这一阶段的测试主要是采用静态测试。
第二阶段为测试分析阶段，又分为制定测试计划、测试设计与开发两个步骤。测试计划包括确定测试策略和测试系统，预估测试工作量等。测试设计与开发包括开发测试用例，验证并调试测试等。
第三阶段为测试执行阶段，强调测试人员和开发人员的配合。该阶段的测试方法包括单元测试、集成测试、系统测试及验收测试。除了对程序进行测试外，还要对文档等进行测试。记录测试结果并写出测试总结报告，为下一轮的迭代测试打基础。
第四阶段为测试维护阶段。开发者的维护包括修复顾客操作和为满足不断变化的顾客需求而对产品功能进行增强时发现的缺陷；测试组的维护意味着对缺陷的修复进行验证，测试增强了的功能以及产品的新发布版本上运行回归测试以确保修改前的产品具有的功能不因产品的新变化而被破坏。
从模型图中可以看出，该模型除具有传统喷泉模型的优点外，还体现了以下特点：
(1)布式特点当软件结束计划阶段，分布在不同地域的软件开发小组可以根据计划，在不同或者相同的时间启动项目开发。
(2)测试的充分软件测试中测试用例的覆盖率直接决定了软件测试的质量。改进的喷泉模型大大扩大了设计和选取测试用例的范围，可以从包括程序、文档等所有可以使用的信息中获得，提高了测试用例的覆盖率，保证测试的充分性和完全性。
(3)完全实现了测试和开发的同步，以及各个过程内各个阶段之间的同步。真正实现了“全过程”测试，提高了软件测试的质量。
喷泉模型实例分析[1]
在给一个中型制造企业开发物流管理信息系统的过程中，使用改进模型。这个物流管理信息系统基于C／S和B／S混合架构，一共分为六大子系统，目的是解决企业内部存在的“信息孤岛”问题，实现企业内部信息共享，帮助企业提高信息化水平。按照以往经验，开发一个物流管理信息系统，其中有一半的时间是进行各类测试。在开发这个系统时，所面临的问题主要有以下几点：
(1)企业的需求非常不固定，经常变化。
(2)由于企业的规模不大，资金有限，要求在规定的时间内必须完成开发。
(3)系统必须能正常运行，要求测试的完备性。
该系统开发小组一共四个成员，基于上述三个问题，采用了改进的喷泉模型进行软件测试，一个编程，一个测试，开发与测试同步。本文以信息系统中的仓库子系统为例，介绍如何使用该测试模型来解决以上问题。仓库子系统结构如图5所示。
图中一共分为三层，上层、中间层和底层，实际还有一层，称为顶层。底层采用单元测试，中间层和上层采用集成测试，顶层采用系统测试。在整个系统开发过程中，严格按照测试模型进行测试和开发。具体步骤和做法为：
(1)顺层开发阶段，对应模型中的顾客分析。主要是对需求的确定和验证。在确定用户需求时，根据企业需求不稳定的现状，把企业的需求进行分类，共分为三类：稳定的，不稳定的和极不稳定的。
利用这些需求完成最初的需求说明书，根据测试模型，测试人员开始进行设计验收测试用例。对于极不稳定的需求编制成一份文档，并进行确认，在以后的开发过程中边开发边对这些需求进行更改。
(2)当开发进行到概要设计(图中的上层)时，对应测试模型中的系统分析阶段。按照测试模型，采用边开发边测试的办法。根据上一阶段已经通过验收测试的需求说明书，将整个系统分成了六大子系统，销售子系统、采购子系统、仓库子系统、生产子系统、财务子系统和服务器子系统。此时，测试人员结束验收测试用例的设计，而进入集成测试用例的设计。
(3)详细设计阶段，对应测试模型的子系统分析。首先把仓库分成系统管理、入库管理、出库管理、调拨管理、库存统计和辅助管理六个模块，这个过程测试人员继续执行测试用例的设计。然后进入测试模型中的模块分析阶段，即开发人员根据需求文档进行更细小的模块划分。系统管理这个模块由四个更小的模块组成，入库管理、出库管理、调拨管理、库存统计和辅助管理同样进行了更细的划分。在这一过程中，需求中的不稳定因素被确定下来，测试人员结束集成测试用例设计，转而开发单元测试用例设计，测试人员大概能完成3／4的集成测试用例设计，并开始对文档进行验收测试，记录测试结果，反馈给开发人员，使其可以及时修改需求中出现的错误。
(4)代码编写阶段。开发人员根据详细设计的结果，从底层开始进行代码开发。测试人员继续进行单元测试用例的设计，测试用例的获取范围也扩大，可以从程序中选择。例如完成库存管理单元时，开发人员继续开发下一个小单元，测试人员则开始进行单元测试，并把测试后的结果反馈给开发人员，这样开发人员能及时地改正错误。当开发人员完成系统管理，开发入库管理时，测试人员对系统管理进行集成测试，并同时进行单元测试。同样将测试结果及时反馈给开发人员。当整个仓库子系统完成了2／3的模块时，测试人员边进行单元测试和集成测试，边进行系统测试用例设计以及系统测试需要的测试环境设计。完成所有子系统时，开始进行系统测试。
在最后执行的验收测试中发现的错误，先确定子系统，再确定模块，最后直接回到需求中查找错误，并执行回归测试。下表是测试过程中的一个测试实例。
为了能更清楚的说明改进的喷泉模型的优势，我们把该模型每个阶段测试的结果和旧有模型进行了比对，如表2所示，并进行了图形分析，如下图所示。
表2 新旧模型测试结果对比
| 旧模型 | 新模型 | |||
| 测试用例 | 出错率 | 测试用例 | 出错率 | |
| 需求分析阶段 | 已完成的文档 | 11% | ||
| 系统设计阶段 | 准确无误的文档信息 | 10.2% | 已经完成的所有文档 | 18.6% |
| 代码开发阶段 | 文档、程序 | 24.6% | 所有文档、程序 | 17.5% |
| 验收测试阶段 | 需求说明、程序 | l9% | 所有文档、程序 | 10% |
从表2和上图中可以看出，由于新模型实现了开发与测试并行，各个开发和测试阶段的并行，扩大了测试用例的覆盖率，而且软件中出现的错误在前期就能及时发现，不仅保证了测试的有效性和完备性，同时大大降低了测试在软件中的费用。