自动化测试技术分享 | 敏捷开发、瀑布与迭代模型的项目应用分析

以下为作者观点：

“敏捷”、“瀑布”、“迭代”是目前开发模式描述中应用比较多的词汇。那么，这些词汇有什么概念差异呢？别急，这就来为大家一一解惑。

首先瀑布模型、迭代模型都属于软件开发生命周期（SDLC）模型，从软件工程发展史上看，瀑布模型由罗伊斯博士（Winston W.Royce）于1970年提出，是一种线性模型，强调准入与准出的标准，V模型、W模型等属于它的变种模型。迭代模型，继承了瀑布的方法，但相比瀑布模型，加入了循环优化和并行的理念，其核心思想是，一次性做好几乎是不可能的，因此会根据需求目标把需求分段或者分块实现。与此相关的，原型模型、增量模型、螺旋模型等核心思想都与之相似。

瀑布模型

迭代模型

1995年由肯·施瓦伯（KenSchwaber）和杰夫·萨瑟兰（Jeff Sutherland）发布了迭代增量软件开发过程（Scrum），而后出现了极限编程（XP）、特性驱动开发（FDD）、自适应软件开发（ASD）、动态系统开发方法（DSDM）等开发方法。

2001年，17位世界著名的软件工程专家将这些“轻量级”开发方法抽象统一到共同原则，由此诞生了著名的《敏捷宣言》。敏捷开发一般意义是指这一系列轻量级项目管理方法的总称，后来敏捷这个词语也被泛化为小步快跑、快速迭代、应需而变的原则与思维方法统称。

敏捷宣言与诠释

围绕项目管理的质量三角模型：范围、时间、成本。

瀑布模型的最大优势是成本总体可控，对于实施范围很明确的项目，通过明确的职责分工，可以很清楚了解消耗的总体成本和时间计划，而缺点则是对需求的水平要求往往较高，如果需求方向与实际用户需求差异较大，或者设计能力不足，往往重新开始的成本很高。

狭义的理解，敏捷开发即按Scrum模式推进项目。其最大优势是适应范围可变类型项目，贴近客户需求，特别对初创产品类的项目，敏捷实施可以让整个开发过程不断适应客户要求，调整原型，是一种掉头能力很强的项目开发方法。它的缺点是总体投入成本较高，较依赖于自动化水平释放产能压力。

从2016年起，兴业银行在境外网银项目开始试点，集团统一消息推送平台、IT综合管理系统开发、兴业管家项目等陆续开始尝试运用Scrum过程开发。经过一段周期的实践与总结，也形成了模型评估的方法，通过对项目组织情况、人员意愿、技术条件等方面的问卷形式，对项目(任务)是否适合采用敏捷开发有一个较为简略的判定分，通过对分数的划线，判定项目组是否适用敏捷开发(Scrum)，总体上有成效不错的项目组，也有只是浅尝辄止的情况。

关于敏捷的思考

1.从质量三角出发理性选择合适模型

兴业银行从推动敏捷转型伊始，并非要求彻底封杀瀑布模型开发，而是在互联网产品爆发式增长的宏观背景下，从提高业务满意度、应对产品需求多变的角度，引入新的开发模型，旨在促进项目的多模式运作，应用更多的应用轻量级开发模型（迭代模型、Scrum模型）与最佳实践（用户故事、看板、单元测试、持续集成、持续发布）等，以快制胜，适应互联网时代产创的要求。

一般来说，对于需求范围明确、进度优先、成本有限的项目，瀑布模型较为合适；对于需求薄弱（想不清）、客户体验要求高、成本不是首要的，Scrum开发较为合适；对于需求旺盛、周期长、但每一期的需求都比较明确的项目可以选择迭代开发模型；而对于短期需求、产品容易定型的项目，比如短期的监管类项目，瀑布模型又更为合适。

无论选择哪种项目开发模型，敏捷的轻量级开发实践更像是一个百宝箱，都可以在项目中酌情选用，比如看板、结对编程、自动化单元测试、自动化测试等。因此，如果是广义的敏捷，事实上所有项目都可以进行推广和实践敏捷。

2.DevOps是敏捷推广的核心价值

无论是瀑布还是敏捷，开发模型的选择并不能根本解决产出效率问题。提到敏捷，不得不提的是另一个词语：DevOps。对于采用Scrum/原型模式的项目，项目成本消耗总体是增加的，这些成本需要借助DevOps流水线的各类自动化活动削减，如果连单元测试、自动化测试都没有运作起来的项目，其实使用敏捷开发是很累的事，基本上难以长期坚持，或者只是模仿了个表象，这样的强行敏捷，只能靠不断的加班冲刺弥补产能缺口，短期可行，长期来看弊大于利。

在人力资源相对稳定的情况下，提高产能的方式主要就是：让机器替代人工。要实现这一目标，有两个方向：一是将复杂工序分解简化，通过固定工艺把简单的工序串联起来，形成自动化流水线，把机器对重复性劳动的优势发挥出来。二是提高机器的AI能力，进而能在更多复杂工序上替代人工。第一种方式，难点在于新工艺的洞察沉淀与新工艺推广，需要从动态的工序中找到可标准化的静态模式，引导开发人员形成更优的工作习惯；第二种方式，是目前人工智能领域，对机器算法要求高，目前的火爆全网的ChatGPT是这个领域的先驱。

3.资产复用为自动化流水线保鲜

整个DevOps流水线是一个跨中心、团队的复杂项目，总体架构脱离不了三部分：应用、数据与技术。应用即流水线上的各类功能应用系统，如看板、星盘、测管平台、制品库等，它们最终都将向自动化方向发展，技术方面主要依赖于云原生、虚拟机、多地网络节点、共享存储、灾备切换等IaaS层能力支撑，主要特性是分布式与云化。

DevOps流水线的数据架构是一个极为重要但容易被忽略的环节，在流水线上跑过的数据，有应用版本、部署脚本、自动化串联脚本、测试案例、造数脚本、缺陷、文档报告等各类资产，虽然它们都会以一定规范存放在配置库、制品库、资产库等各类专业系统中，但在对于价值复用来说，不仅是自身过程的积累，还需要考虑全局性的交叉继承与引用,比如：在开发阶段的测例怎么被测试阶段使用；测试阶段的测例怎么被下一轮测试使用；测试典型缺陷如何共享给研发人员；生产缺陷如何在整个流水线中被转换为预警信息。在整个DevOps流水线上的资产应该都具备数字化与开放使用能力，才能使其始终保持新鲜与活力。

4.选择敏捷开发模式还需要注意对质量风险的容忍度

互联网类产品，多数都采用了微服务+组件化的构建方式，采用敏捷开发，特别是原型迭代模式的开发，短期交付质量有可能是低于预期，但A产品的问题基本不会影响到B产品的运营，不容易引发系统性风险，这里系统性风险，指的是出现缺陷会导致全局功能不可用或者蝴蝶效引发大规模的影响。

银行产品却并不能如此乐观，大量资金交易类系统牵一发动全身，如传统核心业务系统、支付系统、零售理财、资金交易等业务系统，对于缺陷的容忍度还是极低的，在强监管的压力下，数据应用的风险也越演越烈，目前在规划的技术中台、数据中台本身都是系统性风险可能存在的要害领域，因此，在选择开发模式时，对风险容忍度还需要考虑。对于试水的面客类产品，如果缺陷容忍度较高，出了缺陷可以马上更新，在动态的质量达到客户预期即可，那么Scrum是很好的应用场景；但如果是基础平台，停运一分钟损失1个亿，那么还是建议从需求角度就把好关，严格按阶段设置质量门禁、充分测试较为合适。

当然，随着测试自动化水平的提高、缺陷库以及精准定位等技术的应用，缺陷的发生概率也将越来越低，因此在重要信息系统建设项目上能否应用Scrum等快速迭代，本质上还是与项目所配套的基础自动化水平、质量保证能力相关，如果在重要链路的质量保障手段已经很充分并且自动化水平较高，项目应用选择哪类开发模型选项就会灵活许多。

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】

在这里插入图片描述