软件测试基础理论学习-常见软件开发模型（一）

瀑布模型

背景

瀑布模型的概念最早在1970年由软件工程师Winston W. Royce在其论文《Managing the Development of Large Software Systems》中提出。Royce虽然没有明确提出“瀑布模型”这个术语，但他描述了一种线性的、阶段性的开发流程，各个阶段之间具有严格的顺序性和依赖性，且每个阶段结束时都会产生一个可交付成果，并通过评审后才能进入下一个阶段。

在瀑布模型被提出之前，软件开发并没有统一的标准和规范，而瀑布模型成为第一个被广泛接受并应用于实践的软件过程模型之一，它在一定程度上填补了当时对于系统化软件开发过程框架的空白。尽管后来发现瀑布模型并不适用于所有情况，尤其是在需求不明确或频繁变更的情况下，但它为后续迭代和敏捷开发等更灵活的方法论奠定了基础，并促进了软件工程学科的发展。

核心思想

瀑布模型顾名思义，就是软件开发像“瀑布”一样，一直往下走，具体而言，就是把软件开发作为一系列线性、顺序的阶段，每个阶段完成后产出的成果成为下一个阶段的输入，并且每个阶段都有明确的目标和完成标准。该模型强调的是阶段间的严格依赖性和顺序执行，一旦一个阶段完成，一般不鼓励或者很难回溯到前一阶段进行修改。

主要特征

1. 阶段划分：它将整个软件生命周期划分为一系列相互衔接的阶段，如需求分析、设计（概要设计和详细设计）、编码、测试（单元测试、集成测试、系统测试等）以及运行维护。

2. 一次性流程：各阶段的工作成果需要通过严格的审查或验收后才能进入下一阶段，也就是说，每个阶段的工作必须在上一阶段完全结束并通过评审之后才能开始。

3. 文档驱动：瀑布模型非常注重文档化，每个阶段都产生相应的文档记录，作为阶段间沟通的基础，同时也作为项目审计和控制的重要依据。

4. 不可逆性：瀑布模型倾向于认为每个阶段只向前推进，而不向后反馈，即在一个阶段结束后难以对前面已经完成并验证过的阶段进行大规模更改。

5. 结构化方法：采用结构化的分析与设计方法，确保逻辑实现与物理实现分开，有利于分工协作和管理。

适用范围

1. 需求稳定的项目：在项目开始阶段，所有需求就已经明确、稳定，并且在整个开发过程中不会有重大变化。例如，航空航天、银行核心系统等领域的软件开发，这些领域的需求通常会经过详细规划和严格审查。

2. 规模较小且结构简单的项目：对于功能相对简单、架构清晰、实现难度不大的小型项目，瀑布模型可以有效管理整个生命周期。

3. 合同式项目：在项目合作中，客户与开发者之间签订了严格的合同，明确规定了项目的交付物、时间表以及变更控制流程，客户对项目实施过程参与度较低，仅关注最终产品是否符合约定标准。

优点

1. 把软件开发进行了明确的阶段划分

2. 软件开发会按照固定的顺序进行，对于大型项目较好管理和控制

3. 瀑布模型强调文档的完整性，有利于在遇到问题时进行沟通、管理和溯源

4. 由于每个阶段都有自己的验收标准和质量检查里程碑，所以如果出现问题，在早期就可以发现并且及时纠正，也降低了后期修改的成本

5. 在每个阶段结束的时候都会进行验收和审查，可以尽早的发现问题和风险

6. 对于需求明确并且无需频繁变动需求的大型项目，瀑布模型可以提交较好的计划性和可控性

7. 易于理解和培训

缺点

1. 需求变更适应力差，瀑布模型需要在最开始的时候就能全面、准确和明确的知道和定义所有的需求，并且在整个开发过程中，都需要保持相对稳定。但是在现在这个软件环境下，需求变动十分的频繁，需求也激增，用户常常会随着市场变化和技术进步而不断地修改调整需求

2. 瀑布模型需要在后期软件开发完成之后才会对系统进行全面的测试，这就会导致很多潜在的问题需要再项目接近尾声的时候才会被发现，导致修复成本高。【这并不与上述优点中的第四点矛盾，因为许多问题需要对系统进行集成测试才能被发现，而没有开发完成难以进行集成测试】

3. 由于需要详尽的文档，所以会导致文档如果有修改，那么维护起来就会比较困难，可能会导致信息传递延后或者与实际情况脱节

4. 客户参与度低，客户只能够在最后的交付阶段，才能够看到产品，会大大降低可以的满意度和产品的市场竞争力

5. 资源分配不均衡，例如在前期可能投入全部人力去进行需求的整理、收集，就会导致编码阶段的时间被压缩，影响后续的测试和交付

瀑布模型的这些缺点大部分是致命的，例如一开始就需要知道全部的需求，这对客户来说并不现实，因为现在的互联网软件都需要实时更新，不断修改；再例如客户参与度低会导致客户不知道软件开发进度，是否偏离了原有的设定，是否符合现在的需求等。

迭代开发模型

背景

迭代开发模型的出现主要是为了应对传统的瀑布模型在软件开发过程中暴露出来的不足和缺点。

迭代开发模型最初是在20世纪70年代末到80年代初被提出和发展起来的，它反映了软件开发行业对更加动态和迭代过程的需求，以适应不断变化的技术环境和市场需求。

核心思想

通过一系列连续的、逐步细化的开发周期，每次迭代都产生可运行的产品增量，并根据反馈进行调整优化，以适应需求变化和风险控制。

主要特性

1. 分阶段递增：不要求一次性完成整个系统的开发（相对于瀑布模型而言），并且在每个阶段（迭代）中都包括了完整的开发活动（需求分析，设计，编码，测试，评估等），每次迭代都会产生一个可运行的产品版本，这个版本可能是最终产品的部分功能或者子集

2. 适应变化：迭代模型允许根据上一阶段的反馈和学习结果来调整下一阶段的目标和计划，从而更好地适应需求的变化和技术的进步。它强调灵活性和响应能力，以应对不确定性和复杂性

3. 增量价值交付：在每个迭代结束时，团队会提供一个具有实际功能的新产品版本，这些版本逐步增加新的特性和改进，并且可以被用户或者利益相关者评估和使用。这样就能够在项目的早期阶段就开始获取反馈并实现价值交付

4. 持续客户参与与反馈：客户或用户能够定期看到正在开发中的产品，并提供反馈意见，这不仅加强了沟通和理解，也有助于产品更贴近市场需求

5. 持续集成与验证：随着每个迭代的完成，新的代码会被逐步加入到现有的系统中，并进行充分的集成和验证，以确保系统的稳定性与质量

适用范围

1. 需求不完全明确或可能会变化的项目：在项目的早期阶段，用户可能无法准确地定义所有需求，迭代模型能够在后续迭代中根据反馈和学习结果逐步细化和修订需求。

2. 大型复杂项目：对于规模较大、复杂度高的软件开发项目，通过分阶段迭代可以降低管理难度，每个迭代专注于解决部分问题，从而更好地控制风险和管理不确定性。

3. 客户期望高度参与的项目：迭代模型鼓励客户在每个迭代周期结束后对产品进行评估和提供反馈，这样客户可以在项目早期就参与到产品的形成过程中来，并影响产品的最终形态。

4. 技术挑战性大或创新性强的项目：在探索新技术或者构建全新系统时，采用迭代方式能够更早地验证技术方案，及时调整方向，降低技术风险

5. 需要快速响应市场变化的项目：当市场环境、业务需求或竞争态势变化较快时，迭代模型能保证团队迅速适应变化并不断交付具有价值的产品增量

6. 资源有限但需持续优化的项目：在有限的资源条件下，迭代模型可以帮助团队通过持续改进的方式优化产品功能和性能

优点

• 部分优点已经体现在上述的主要特性中，这里对于重复内容不再进行陈述。

1. 降低软件开发的风险，由于每次迭代都只关注一部分需求，所以如果在某个迭代中出现问题或错误，影响范围都比较小，修复成本也较低

2. 对于资源管理和优先级排序更加容易和方便，可以根据每次迭代的成果和市场反馈灵活的调整下一阶段的开发计划和资源安排

缺点

1. 需求管理困难，由于迭代开发模型中会不断地产生新的需求，会导致开发计划混流，也会增加项目管理和协调的复杂性

2. 项目集成问题，使用该模型的时候，每次迭代都会输出一个新的功能模块，在最后把这些零散的模块集成到一起的时候，可能会遇到许多技术问题

3. 成本控制问题，在需求不明确的前提下，频繁的变更需求必然会导致项目研发周期的延长，也会导致提高整体研发成本

4. 迭代间隔设置问题，如果每次迭代的间隔过小，就会导致团队陷入强大的工作压力和疲劳中

增量模型

背景

它吸收了瀑布模型中按阶段划分任务的优点，同时结合了快速原型法的迭代思想，允许在项目早期就启动开发工作，将整个软件系统分解为一系列可管理的小块（增量），每个增量构建都包含一部分可运行的功能。每个增量部分经过设计、实现、测试后被集成到现有系统中，这样用户可以逐步看到并使用软件的新功能，而且随着增量的增加，软件产品的功能逐渐完善。【可能感觉和上文的迭代开发模型有点类似，后文会着重讲述区别】

核心思想

将软件开发分解为一系列逐步增加的“增量”版本，每个增量构建是一个可独立交付和运行的功能子集。

适用范围

和上文中的迭代开发模型基本相同，可以增加的一点是：

• 针对模块化程度高，易于分解的系统，更加适合使用增量模型

优点

和上文中的迭代开发模型基本相同，可以增加的一点是：

• 增量模型具有良好的模块化特性，每个增量相对独立，在后期维护中，只需要对特定的部分进行升级或操作，不会影响整个系统的其他部分

缺点

和上文中的迭代开发模型基本相同，可以增加的一点是：

• 难以把握进度，因为需求不断地增加，整个项目的最终完成时间难以预测

疑问一：迭代开发模型和增量模型的区别是什么？

两者在软件开发过程中，通常都会使用，其实并没有特别严格的界限，具体而言，其实就是两者的关注的侧重点和实施方式不同。

迭代开发模型和增量模型是软件工程中两种适应性、灵活的开发方法，它们都允许在开发过程中逐步细化和完善产品，但侧重点和实施方式有所不同。以下是全面且独到地分析两者的区别：

迭代开发模型

• 核心思想：迭代开发是一种以时间盒为单位进行循环工作的方式，在每个迭代周期内，团队会经历需求分析、设计、实现、测试直至交付一个可工作的软件版本的过程。每个迭代都可以看作是一个小型项目，包含了完整的软件开发生命周期。

增量开发模型

• 核心思想：增量开发将整个系统划分为一系列连续的、逐步增加的模块或组件，每个增量阶段专注于构建一部分新的功能，然后将其与现有系统集成。

区别总结

1. 范围界定：迭代开发关注的是整个软件生命周期过程的重复执行，而增量开发关注的是产品功能的逐步累加。

2. 目标侧重：迭代开发着重于在短时间内产生可用于评估的完整功能子集，增量开发则更注重按照预定的功能模块顺序逐一实现并交付。

3. 用户参与程度：迭代模型下，用户可以在每个迭代周期结束后提供反馈，从而影响下一迭代的内容；而在增量模型中，用户的直接反馈可能仅限于已完成并交付使用的增量部分。

4. 灵活性对比：迭代模型在处理需求变化方面更为灵活，因为它允许在每个迭代开始前重新评估和修订需求；增量模型虽然也能应对部分需求变化，但在已经完成的增量上做大的改动可能会带来更高的成本。

综上所述，迭代开发和增量开发虽然都支持动态的需求管理和产品的渐进式完善，但前者更加强调过程中的反馈和学习机制，后者则更倾向于有序的、逐步扩展的系统构建策略。在实际应用中，两者经常结合使用，形成迭代增量开发模式，兼顾了敏捷性和结构化开发的优点。

---

敏捷开发模型

背景

2001年，以Kent Beck、Mike Beedle、Alistair Cockburn、Ward Cunningham、Martin Fowler、Jim Highsmith、Bob Martin、Ken Schwaber和Jeff Sutherland等人为代表的17位软件专业人士在美国犹他州雪鸟滑雪胜地召开了一个研讨会，并共同签署了《敏捷宣言》。这份宣言标志着敏捷开发运动的正式诞生，它提出了一系列价值和原则，倡导以人为本、灵活应变、持续改进和早期交付价值的核心理念。

敏捷宣言：敏捷软件开发宣言

敏捷开发模型，如Scrum、极限编程（XP）、水晶方法（Crystal Methods）、精益软件开发（Lean Software Development）等，就是在这一背景下发展起来的，它们共享了敏捷宣言的精神，但各自具有不同的实践和侧重点，旨在帮助团队更好地适应市场变化，更快地交付高质量的软件产品，同时保持高度的灵活性和团队士气。

核心思想

• 敏捷开发是一种以人为核心，迭代，循序渐进的开发方式。

• 在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。

• 简单的说，敏捷开发并不是追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

Scrum

Scrum是敏捷开发的一种实现方式，可以说是一种开发流程框架，也可以说是一种“套路”。Scrum框架中包含了三个角色，三个工件，三个活动。

• 首先，我们围绕最小化可行产品的特性来进行产品规划，然后把最小化可行产品开发出来，接下来就是测试和评审这个产品，直到准备发布，循环这个过程，我们就会得到一个可发布的产品，这个过程通常只需要一到三周左右，再继续重复这个阶段，你就会得到几个增量式版本，如下：

这时候就有一个概念：

• 冲刺周期（Sprint）：中文译为冲刺、短跑，是Scrum的专有术语。冲刺周期，通俗的讲就是实现一个“小目标”的周期。一般需要1-3周时间。

Spring可以直接理解为一个固定时间段

下图可以形象的概括Sprint

在这其中，有三个角色能够帮助团队更好的工作：

• 产品经理（Product Owner）：负责确定产品特性，同时产品经理会提出产品亮点

• 流程管理员（Scrum Master）：是整个团队的负责人，负责帮助团队尽其可能完成工作，组织日常会议和保障其他工作

• 开发团队（Scrum Team）：Scrum的团队通常由开发人员，测试人员，文案以及其他帮助研发的人组成，主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5-10人左右，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力。同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标

也有三种文档，也可以叫做三个工件：

• 产品需求列表（Product Backlog）：产品经理会先从众多用户故事中筛选出优先项，并把它们列入产品开发列表中，需求列表会随着每次的Sprint送代和更改

在这里，需要补充一个概念：

• 用户故事（User Story）：用户的外在业务需求。拿银行系统来举例的话，一个Story可以是用户的存款行为，或者是查询余额等等，也就是所谓的小目标本身。格式为「作为一名__用户，我需要__功能，所以__能够」，产品经理通过用户故事来了解需求的细节，为Scrum团队合理指定任务优先级

• 迭代需求列表（Sprint Backlog）：有了产品需求列表，我们需要挑选出最优项的用户故事作为每次迭代完成的目标，剩下的继续评估优先级，交到下次的迭代中

• 燃尽图（Burndown Chart）：用于展示整个Spring代办列表的进度，当燃尽图曲线接近0的时候，也就意味这次Spring即将完工

还有三种不同形式的会议需要用到：

• Spring计划会议（Spring Planning）：在每个Sprint开始时召开，由全体人员参加。这个会议主要有两件事情要确定。①确定当前Sprint的目标 ②选定当前Sprint要处理的最具价值的用户故事，创建迭代需求列表

• 每日站会（Daily Scrum）：一般在15分钟以内。团队成员相互交流任务的进展，计划以及遇到的困难。

• Sprint回顾会（Sprint Retrospective）：用来回顾在当前结束的Sprint中的工作，会给产品经理演示开发好的功能，进行经验总结、反思，并拟定响应的改进措施

来总结整个Scrum的流程：

疑问二：Scrum实现的敏捷开发和迭代开发模型的区别？

• Scrum 实现的敏捷开发是一种严格遵循敏捷原则和实践的迭代开发方式，它的优势在于高度的灵活性、快速适应变化的能力以及对团队协作和沟通的强调；一般的迭代开发模型则更侧重于分阶段递增式完善产品，其灵活性和敏捷性相较于 Scrum 可能有所欠缺

• 虽然迭代开发允许在后续迭代中对前一阶段的需求和设计进行修改，但在实际操作中，对于需求变更的响应速度和灵活度可能不如 Scrum 架构下的敏捷开发，因为Scrum在每次Spring中都会对需求重新排序