4600 字 + 20 图：测试必知的软件开发流程

软件工程简述

什么是软件工程？

听到「软件工程」四个字，多数人既熟悉又陌生！熟悉是因为与自己的职业息息相关，大多数公司都或多或少地在用软件工程，比如敏捷模型，单元测试、性能测试都属于软件工程范畴，为什么软件工程被各公司重视？有两点原因：

1. 生活越来越依赖软件，公司需要经济且快速的方式开发出可靠、可信的系统，
2. 软件工程提供了更低的测试成本、质量保障成本和长期维护成本

奇怪的是，虽然工作中经常接触到软件工程，为什么多数人对其感到很陌生？因为每个人接触的只是软件工程片段，比如测试同学接触的是软件工程测试部分，研发同学接触软件工程开发部分。那究竟什么是软件工程呢？软件工程是一门工程学科，涉及软件生产的各个方面，从最初的系统规格说明直到投入使用后的系统维护，都属于其学科范畴。

多数人对软件工程存在偏见，认为其过于落后跟不上互联网应用发展，并不是这样！不同的系统使用的软件工程方法各不相同，在过去的 50 多年里，软件工程也在随着系统发展变化。举个例子，汽车嵌入式控制系统，该系统十分注重安全性不允许被任意修改，因此需要烧录到 ROM 中。

不难想像，由于 ROM 的只读性，修改控制系统会十分昂贵！为避免汽车被召回，厂商需要反复检测控制系统是否完好。上述例子需要哪些软件工程呢？汽车控制系统无界面，不会与用户产生交互，该厂商使用的软件工程应该是无交互非迭代类。

再看一个反例，现在的互联网应用，大多采用交互式的 web 应用，很多公司会使用迭代开发。

控制系统和 web 系统不相同，两者使用的软件工程方法也不同，控制系统使用的是非迭代开发流程，而 web 系统使用的是迭代开发流程。因此得出一个简单结论**“只要两个系统不相同，使用的软件工程方法就不同！”**，这个结论对吗？当然不对，不能一棒子打死！软件工程也存在一些通用的研究方向，比如：

• 开发流程可被管理：管理人员可以控制开发流程并制定开发计划，比如设立项目 deadline。
• 关注可靠性和性能：所有的系统都应该运行正常并且能够抵抗外部攻击，此外，系统也应当高效运行不浪费资源。
• 理解需求：开发人员需要了解客户的需求，要在预算范围内有的放失，比如项目 deadline 是三天，与主要功能无关的需求都可以延期。
• 系统复用：开发人员应该尽可能地复用已有功能，避免造轮子。

互联网应用

最后谈一谈与生活息息相关的互联网应用。最初的 Web 只是静态页面，简单而直接，2000 年左右web 开始崛起，浏览器越来越强悍，用户可以在页面上干更多的事！之前需要用光盘看视频，现在打开浏览器即可观看，人们越来越喜欢 web 应用，服务型系统如雨后春笋般出现。相对于个人计算机应用，服务器型应用更容易修改和升级，软件即服务的思想在 21 世纪初被提出，这一思想已成为 web 应用交付的标准方法，例如 Google 移动应用、微软的 ofice365、 Adobe 的 Creative 套件。

当 web 应用越来越多，其依赖的服务器也越来越多，维护服务器的成本也越来越高，中小型公司难以承担如此高昂的维护费用，“云”伴随而生，即由一家公司专门维护服务器，将服务器租借给其他公司，软件运行在远端云上。

不可否认，Web 应用对「软件工程」造成了巨大影响，主要有以下几点：

1. Web 应用更依赖复用：开发人员常常使用 Web 框架开发 Web 应用，框架集成了很多常用功能，比如 SpringBoot 集成了事务管理，数据持久化、Web 框架等等。
2. 增量开发和交付：用户的需求并不准确，开发完成后，用户可能更改需求或者提出新需求，公司会采用增量开发/交付。
3. 富页面技术出现：AJAX（ Holdener2008）和 HTML5（ Freeman2011）等富页面技术出现。

注意：纵然 Web 应用飞速发展，但前面讨论的软件工程思想同样适用。

软件开发流程

「软件开发流程」是指软件开发的开发生命周期。不同的系统会采用不同的软件开发流程，但每一个开发流程都包含 4 个基本行为：

1. 规格说明：描述了软件功能和一些约束条件。
2. 开发：开发出符合规格说明的软件。
3. 确认：确保软件符合客户的需求。
4. 演化：客户的需求是不断变化的，软件需要不停地迭代以满足需求。

“就四个行为 🤔，会不会太简单了？”不要小看这四个行为，每一个行为都能展开，例如「规则说明」包含了体系结构设计，「开发」包含了单元测试....，如果不断地展开能围绕地球好几圈！“「软件开发过程」展开这么复杂，那么公司是如何运用的？”要想知道公司是怎么运用的，首先要知道「软件开发模型」（又称软件开发周期），比如让你去读一本难懂的书，相信没多久就会放弃，于是可以看看别人总结好的读书笔记。「软件开发模型」相当于「软件开发流程」的读书笔记，包含了「软件开发流程」的骨架而忽略了细节，下面是一些常见的软件开发模型：

1. 瀑布模型：将开发流程分为四个阶段，即规格说明、开发、确认、演化。
2. 增量开发：「规格说明」、「开发」和「确认」交错进行。
3. 集成和配置：该方法依赖于可复用的构件或系统。系统开发过程关注在新的使用环境中配置这些构件并将它们集成为一个系。

公司会同时运用多个模型，举个例子，若某些功能简单明了，可使用瀑布模型进行规格说明和开发，当然，不差钱的公司可以直接采购。若某些功能很模糊，需要多次确认，则采用增量开发。

瀑布模型

瀑布模型起源于军事系统工程（ Royce1970），该模型把软件开发过程分成多个阶段，一个阶段结束，像瀑布一样流动到下一个阶段。比如下图一开始对客户的需求进行分析，分析完成后进入设计阶段。

1. 需求分析和定义：开发人员经过深入细致的调研和分析，准确理解用户要求，将用户非形式的需求表述转化为完整的需求定义。
2. 系统和软件设计：系统设计又称「概要设计」，采用结构化的设计方法来确定软件的系统结构，主要任务是把需求分析阶段得到的系统扩展用例图转换为软件结构和数据结构。软件设计又称「详细设计」，即进行各模块内部的具体设计，它的任务是为软件结构图中的每一个模块确定实现的算法和局部数据结构。
3. 实现与单元测试：进行软件开发，并建立单元测试用例，注意，此时程序是分散的单元，还未集成到一起。
4. 集成与系统测试：各程序单元集合成完整的系统，对其进行集成测试（web 应用又称接口测试）和系统测试（web 应用又称客户端测试）。测试之后将软件系统交付给客户。
5. 运行与维护：「运行和维护」是时间最长的阶段，在这个阶段系统被安装并使用。开发人员需要进行维护，主要包括修复错误、优化功能、开发新需要。

瀑布模式严格遵循分级思想：前一阶段完成，才能进行下一阶段。举例来说，项目开始时进行需求分析和定义，设计完成后才能进行系统设计和软件设计。这里存在一个难题，作为设计参与者，就像老王卖瓜自卖自夸，很难客观地评价自己的方案好坏，如何客观地判定当前阶段是否完成？比如民事引起纠纷，如果两方不能达成一致往往会选择法院进行判定，法官属于权威人士其建议一定是公正且客观的！瀑布模型也会选择一些”权威人士“进行评审，前一个阶段结束后，可以进行评审，评审通过后再进行下一阶段。「瀑布模型」进行评审后，会产生一个或多个审批通过（批准）的文档

然而，「瀑布模型」不适合软件开发行业，因为软件开发的各阶段不是简单的线性关系，比如在设计过程中可能发现需求问题；在编码过程中可能发现设计问题等。如果某阶段出现问题，那么其前阶段的文档也应进行修改。例如开发时发现某需求坑太多实现成本过高，不打算开发这个功能，应从需求文档删除这个需求。

瀑布模式下，需求分析和定义阶段结束后便不允许被修改，直到上线出了问题才能反工！

虽然「瀑布模型」在互联网软件行业水土不服，但却非常适合以下系统：

1. 嵌入式系统：嵌入式系统涉及硬件，硬件一经出厂便很少被召回修改。
2. 核心系统：开发阶段进行反工会增加大量成本，因为相关的非核心系统都要随之修改，核心系统需要具备完整详细的文档。
3. 大型系统：大型系统由多家公司联合开发，由多个子系统组合而成，需要完整详细的规格说明以便相互协作开发，若开发阶段修改方案会导致所有子系统都会受影响。

「形式化方法」由瀑布模型演变而来，形式化方法是借助数学的方法来解决软件工程领域的问题，主要包括建立精确的数学模型以及对模型的分析活动。细节不再介绍，有兴趣的同学可以参考以下资料：

• Event-B Website: Event-B.org
• Course: J. Paul Gibson's Teaching - Event-B
• A study in the Use of Event-B for System Development From A Software Engineering Viewpoint: http://www.ai4fm.org/papers/MSc-Padidar.pdf

增量式开发

「增量式开发」先进行初始实现，然后根据用户反馈进行迭代开发，最终得到完整系统，如下图。

「规格说明」、「开发」和「确认」是交织在一起的，活动之间可以进行反馈。比如开发时因成本高准备放弃一功能，需求文档也需要标注“取消该功能”。

增量开发是最常用的软件开发方法，其融合了计划驱动和敏捷两大特性.

• 计划驱动：提前确定好增量，比如周一开晨会确定本周增量“迭代功能 A”。
• 敏捷：首先确定初版增量，后面增量取决于进度和优先级，比如先开发核心功能，开发完毕后再对其它功能进行排期，如果 A 功能简单且重要就实现 A 功能，如果 B 功能复杂且价值不大，则暂不实现 B 功能。

粗糙地说，「增量式开发」很符合人类思维！因为计划赶不上变化，第一次制定的方案通常不是完美的，方案会根据实际情况逐步修正，往细了说，「增量式开发」有以下三个优点：

1. 降低了变更成本：增量式开发允许修改文档。
2. 容易得到反馈：版本迭代完成后，客户可以立刻使用并给予反馈。
3. 客户更早获利：「增量式开发」会快速迭代出第一个版本，客户可以更早使用。

凡事都是双刃剑，增量式开发也有缺点，从管理的角度看存在两个问题：

1. 过程不可见：项目管理人员通过交付物制定里程碑，但是增量式开发要求快速迭代，没时间编写文档，导致开发过程不可见。
2. 结构退化：增量式开发以完成需求为主，而需求是客户提出的，他们并不关心代码结构，不关心自己的需求会不会导致代码凌乱。于是向系统中添加新特性越来越困难，成本也越来越高。为了缓解结构退化和代码混乱，敏捷方法建议定期重构。

面对大型、复杂以及长周期的系统时，增量式开发就有些力不从心。这类系统由不同团队开发，需要一个稳定的框架，体系结构文档需要明确、清晰地定义各个团队的职责。

集成与配置模型

很多程序员面向 Google 编程！为什么热衷 Goolge？因为网上存在相似代码，只需要修改一下便能运用。软件开发流程中便有类似的方法「面向复用编程」，想象一下小时候玩的拼装玩具，如何组装一辆坦克？普通小车装配上大炮即可成为坦克。

「面向复用编程」与组装一辆坦克相似，假设目前开发一款软件 A，有两种思路。

• 第一种：若「可利用软件库」中存在与软件 A 相似，并且已经开发完成的软件 B，则直接使用软件 B 即可。
• 第二种：若没有现成的软件，则从「可复用软件库」中挑选合适「组件」，然后放在工作台（集成框架）中进行组装即可，

基于「集成和配置模型」的整体开发流程如下图：

1. 需求规格说明：分析用户需求。
2. 软件发现和评估：从「可复用软件库」中搜索与需求类似的「组件」或「系统」，然后对其进行评估，确定是否满足基本需求。
3. 需求精化：根据「挑选出来的组件或者系统」对需求进行修改，让需求适配已有的「组件」或「系统」。
4. 配置应用系统：若存在相似系统，那么进行配置后即可使用。
5. 组件适配和集成：若存在相似的组件，则需要对组件进行修改或者重新开发。

有三类系统比较适合使用此方法。

1. 经配置后即可独立运行的系统：此类系统比较通用，只须少部分调整即可应用。
2. 与其他框架集成：基于某些框架进行模块开发，例如使用 Java Spring 框架。
3. web 服务：可以通过 http 调用的服务。

基于「配置和集成的面向复用的软件工程」显著降低了软件开发量、成本和风险，同时更快速的进行交付。但是大部分情况此方法无法满足用户的全部需求，比如上述流程中的「需求精化」会修改用户的需求以适配方案。

给自己一个成长的机会，关注我的公众号：测试员！