1.3 软件开发模式的分类_软件测试实用教程-QQ阅读女生青春网

上QQ阅读APP看书，第一时间看更新

1.3 软件开发模式的分类

软件开发模式是软件工程研究的重要领域。软件测试与软件的开发模式息息相关。在不同的开发模式中，测试的作用有细微的差别，测试人员应该充分理解软件的开发模式，以便找准自己在其中的位置和角色定位，以便充分发挥测试人员的价值。

1.3.1 软件开发模式的发展

软件工程是一门综合了软件开发过程、方法和工具的学科。软件开发模式的发展大概经历了3个重要的阶段，如图1.5所示。

图1.5 软件开发模式的发展

软件开发模式的发展大概经历了以下3个阶段，每个阶段都有其鲜明的特征。

（1）以软件需求完全明确为前提的第一代软件过程模型，如瀑布模型等。

（2）在初始阶段需求不明朗的情况下采用的渐进式开发模型，如螺旋模型和原型实现模型等。

（3）以体系结构为基础的基于构件组装的开发模型，例如基于构件的开发模型和基于体系结构的开发模型等。

在软件工程中，软件开发模型用来描述和表示一个复杂的开发过程。

一般人们在提起软件开发模型的时候，首先想到的大概是著名的“瀑布模型”。但是现在大部分软件开发过程都不可能是严格的“瀑布”过程，软件开发的各个阶段之间的关系大部分情况下不会是线性的。

常见的软件开发模型主要有以下3类。

（1）线性模型。

（2）渐进式模型。

（3）变换模型。

1.3.2 线性模型

一般在软件需求完全确定的情况下，会采用线性模型，最具代表性的是“瀑布模型”，如图1.6所示。

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求阶段引入的一个缺陷要等到测试阶段甚至更后的阶段才发现的话，通常会导致前面阶段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日。”

图1.6 瀑布模型

尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。

在瀑布模型中，测试阶段处于软件实现后。这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

1.3.3 渐进式模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一，如图1.7所示。

螺旋模型的基本做法是在“瀑布模型”的每一个阶段之前引入严格的需求分析和风险管理。这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。后面讲到的RUP和敏捷工程方法都包含了这个最佳实践。

增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发，如图1.8所示。

因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚（见图1.9）。而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色（见图1.10）。

图1.7 螺旋模型

图1.8 增量开发模型

图1.9 增量开发示意图

图1.10 迭代开发示意图

而目前很多软件过程所说的迭代开发，实际上意味着增量开发和迭代开发的结合。

1.3.4 变换模型

变换模型是基于模型设计语言的开发模式，是目前软件工程学者们在努力研究的方向。一个简单的变换模型如图1.11所示。

图1.11 变换模型

变换模型的主要思想是省略编码和测试阶段，代之以自动化的程序变换过程，而主要集中精力在前面的需求分析和建模。

看起来这样一种软件开发模式似乎可以把测试人员排除在外，实际上，它是要把测试人员提到原型验证阶段，这无疑对测试人员的能力提出了新的要求。因为程序变换过程是一个严格的形式推导过程，所以只需对变换前的设计模型加以验证，变换后的程序的正确性将由变换法则的正确性来保证。

注意

在每一次迭代原型出来后，测试人员都需要从原型界面、系统主要功能、性能等方面对原型进行评审。

1.3.5 RUP过程模型

业界普遍认为，开发复杂的软件项目必须采用基于 UML 的、以构架为中心的、用例驱动与风险驱动相结合的迭代式增量开发过程，这一过程通常被称之为RUP （Rational Unified Process,Rational 统一过程）。

为什么叫 Rational 统一过程呢？这就要从 RUP 的创始人 Ivar Jacobson讲起了。

现代软件开发之父Ivar Jacobson博士（见图1.12）被认为是深刻影响或改变了整个软件工业开发模式的几位世界级大师之一。他是模块和模块架构、用例、现代业务工程、Rational 统一过程等业界主流方法、技术的创始人。Ivar Jacobson博士与Grady Booch和James Rumbaugh一道共同创建了UML建模语言，被业界誉为UML之父。Ivar Jacobson 的用例驱动方法对整个OOAD行业影响深远，他因此而成为业界的一面“旗帜”。

图1.12 Ivar Jacobson博士

1987年，Ivar Jacobson离开爱立信公司，创立了Object System公司，吸纳了增量迭代思想，开发出Objectory过程。

1991年，爱立信收购了Object System。

而到了1995年，Rational公司又从爱立信收购了Objectory, Jacobson与Grady Booch、James Rumbaugh一起开发了UML，这期间Objectory过程逐渐进化为Rational统一过程（RUP）。

2003年，IBM收购了Rational公司。

RUP过程模型（见图1.13）强调6项最佳实践。

图1.13 RUP过程模型

① 迭代地开发软件（Develop Iteratively）。

② 管理需求（Manage Requirements）。

③ 应用基于构件的构架（Use Component Architectures）。

④ 为软件建立可视化的模型（Model Visually ,（UML））。

⑤ 不断地验证软件质量（Continuously Verify Quality）。

⑥ 控制软件的变更（Manage Change）。

从RUP过程模型图中，我们可以看到，在软件研发的每个阶段，都或多或少地包括了业务建模、需求分析、设计、编码实现、测试、发布、配置与变更管理、项目管理、环境搭建等工作。

RUP强调自动和快速地持续测试，把测试划分为单元测试、集成测试、系统测试和验收测试4大阶段，测试类型涵盖软件的功能、性能、可靠性，可以进一步地细分成如表1-1所示的类别。

表1-1 RUP的测试分类

续表

IBM Rational提供了RUP相关支持工具，网址如下：

http://www.ibm.com/developerworks/cn/rational/

读者可以下载试用版进行学习和使用。其中我们测试人员常用的包括以下工具。

① Rational Quality Manager—测试管理工具。

② Rational Functional Tester—自动化测试工具。

③ Rational Performance Tester—性能测试工具。

④ Rational AppScan—安全测试工具。

需要注意的是，进行RUP实践并不是说一定就要用Rational这一套工具。采用RUP过程模型可以结合任何软件厂商提供的合适的工具。

读者如果想学习到更多关于RUP的知识，可参考IBM网站所提供的资源：

http://www.ibm.com/developerworks/cn/rational/theme/rational-rup/rup.html?S_TACT=105AGX5 2&S_CMP=content

1.3.6 敏捷运动

2001年，以Kent Beck、Alistair Cockburn、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷”（Agile）作为新的过程家族的名称。

在会议上，他们提出了《敏捷宣言》（http://agilemanifesto.org/），如图1.14所示。

图1.14 敏捷宣言

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观。

个体与交互重于过程和工具

可用的软件重于完备的文档

客户协作重于合同谈判

响应变化重于遵循计划

在每对比对中，后者并非全无价值，但我们更看重前者。

由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程（Social Engineering）的。敏捷的主要贡献在于更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。

1.3.7 极限编程（XP）

敏捷运动让一大批被称为“敏捷派”的轻量过程繁荣起来，包括XP、SCRUM、Crystal、Context Driven Testing、Lean Development等，其中又以XP堪称代表。

1996年 Kent Beck为了挽救C3项目而创建了XP（Extreme Programming）过程。Kent Beck （见图1.15）是软件开发方法学的泰斗，倡导软件开发的模式定义、CRC 卡片在软件开发过程中的使用、HotDraw软件的体系结构、基于xUnit的测试框架、在软件开发过程中测试优先的编程模式。