尧图网站建设  - 概念篇（2）-- 常见的开发模型)
测试(4) - 概念篇2-- 常见的开发模型文章目录测试(4) - 概念篇2-- 常见的开发模型1. 常见的开发模型1.1 瀑布模型1.1.1 特点1.1.2 缺点1.1.3 总结1.1.4 问题分析1.2 螺旋模型1.2.1 什么是原型1.2.2 特点1.2.3 缺点1.2.4 总结1.3 增量模型 迭代模型1.3.1 增量模型 迭代模型的区别1.3.2 增量模型 迭代模型配合使用1.3.3 使用场景1.4 敏捷模型重点1.4.1 Scrum三个核心角色五个关键会议Scrum的流程如何记忆1.4.2 敏捷中的测试工作轻文档快速迭代2. 为什么测试人员要学习开发模型3. 总结如果你是第一次看这篇博客可以看一看我软件测试–概念篇的博客介绍测试(3) - 概念篇1-- 什么是需求 软件生命周期1. 常见的开发模型开发模型实际上指的是开发一款软件/功能需要具备的开发流程首先介绍常见的开发模型之前我们需要明确一件事情上述我们讲到的软件开发的生命周期需求分析 → 计划 → 设计 → 编码 → 测试 → 运行维护这是软件开发的生命周期通用流程。也就是说无论是哪一个开发模型都是按照这个流程去设计的。就好比如炒一盘土豆丝土豆削皮并清洗切土豆丝烹饪食用这个流程是通用的你可以在任意环节在其基础上进行修改切土豆丝丝的长度粗细程度烹饪方法等打造属于你自己的土豆丝炒法。下面的介绍的开发模型也是如此是在软件开发的生命周期通用流程 上进行修改改进。1.1 瀑布模型1.1.1 特点瀑布模型是软件工程的基础框架采用线性顺序执行每个阶段仅执行一次。1.1.2 缺点其核心缺陷是可运行产品出现晚、风险高具体表现如下如果需求或设计问题存在问题到测试阶段才暴露会造成大量返工延长产品的开发周期测试在编码完成后进行若时间不足会导致测试不充分从而将软件的缺陷直接遗留给客户。但是目前仍有不少企业仍沿用其线性思想并在此基础上优化阶段、融入迭代理念。1.1.3 总结瀑布模型优缺点总结优点 / 特点强调开发的阶段性线性结构每个阶段只执行一次是其他模型的基础框架缺点测试后置前面各阶段遗留的风险推迟到测试阶段才被发现导致项目大面积返工失去了及早修复的机会必须留有足够的时间给测试活动否则导致测试不充分将缺陷直接暴露给用户产品质量差周期太长产品很迟才能被看到和使用可能会导致需求 / 功能过时1.1.4 问题分析瀑布模型存在严重的项目风险难道就不能被采用了吗并不是的。瀑布模型的适用场景需求固定的小型项目。然而企业中存在许多规模庞大、复杂度高、风险大的项目这种情况下可以采用哪种模型呢答螺旋模型。1.2 螺旋模型一般在软件开发初期需求不够明确时会采用渐进式开发模式螺旋模型就是渐进式开发模型的代表之一。螺旋模型尤其适合规模庞大、复杂度高、风险大的项目。这种迭代开发模式对软件测试提出了新的要求——不允许存在一段独立的测试时间与阶段测试必须跟随开发的迭代同步进行。这是 螺旋模型 的流程这张图片的流程你可以这样看我们也可以展开1.2.1 什么是原型你应该听说过设计图而设计图的前身叫做 原型图。设计图和你最终见到的样子是一模一样的就以百度的页面为例你看到的下面的百度页面就是 百度 这个搜索引擎的设计图。而这个设计图的前身原型图可能是长这样的随便画画看到这里你是不是觉得原型图它就像是 百度页面 的一个雏形所以设计图的制作人员就会根据 原型图 的样式绘画设计图。而我们的原型其实它就是一个软件项目的 雏形。1.2.2 特点螺旋模型 在每一个阶段都引入了 原型和风险分析。目的是为了避免各个阶段遗留的风险问题避免把问题遗留到后面的阶段导致大面积返工螺旋模型特别强调严格的全过程风险管控各个开发阶段的质量。1.2.3 缺点项目中可能存在的风险性与风险管理人员的技能水平有直接关系需求人员、资金、时间的增加和投入可能会导致项目的成本太高一句话就是风险管理人员水平参差不齐耗时资金消耗高1.2.4 总结螺旋模型优缺点总结优点缺点1. 强调严格的全过程风险管理。2. 强调各开发阶段的质量。3. 增加风险分析和原型1. 项目中可能存在的风险性与风险管理人员的技能水平有直接关系2. 需求人员、资金、时间的增加和投入可能会导致项目的成本太高1.3 增量模型 迭代模型这是增量模型的流程增量模型的思想是将大的需求分成多个小的需求每个小需求独立开发上线。那么图中的增量你可以理解为是一个一个的 小需求。而增量模型放在现在不会进行单独的使用而是搭配另一个模型进行使用那个模型是迭代模型这是迭代模型的流程迭代模型第一个上线的项目所有功能都需要实现但是每个功能不一定是完整版的不一定是最完美的。1.3.1 增量模型 迭代模型的区别如果我要画一副人物图截止到 2026年已经很少有企业会独立使用增量模型或者独立使用迭代模型了而是配合着一起使用。1.3.2 增量模型 迭代模型配合使用增量模型和迭代模型 如何配合着使用比如一个大的需求分成若干个需求分成小需求1小需求2小需求3…………此处使用了增量模型小需求1独立开发上线先是上线一个草稿版不是完整的不是最完美的根据用户的反馈和内部的意见对 小需求1进行更加完善的开发和改进。此处使用了迭代模型总结就是大需求使用增量模型分成多个小需求小需求独立开发上线使用 迭代模型进行开发。1.3.3 使用场景增量模型 和 迭代模型的适用场景大型项目且需求不明确。1.4 敏捷模型重点早期迭代瀑布模型曾是项目开发中广泛采用的流程模式。但如今开发人员在使用该模型进行软件开发时会遇到诸多问题。其中最主要的难点在于项目开发过程中难以有效响应客户提出的变更需求且整合这些变更往往需要付出高昂的成本与时间代价。为解决瀑布模型的上述缺陷20 世纪 90 年代中期即 199X 年业界提出了敏捷软件开发模型。敏捷模型的核心目标是帮助项目快速响应与适配需求变更。其根本目的是推动项目高效、灵活地落地交付。要实现这一目标就需要具备敏捷性通过让开发过程贴合项目实际删减对当前项目非必需的活动同时规避一切浪费时间与精力的环节从而达成轻量化、高效率的开发。敏捷模型具有四大核心特点轻文档、轻流程、重目标、重产出。敏捷开发包含多种实践方法其中Scrum是目前业界最为流行的一种。1.4.1 ScrumScrum是敏捷开发中的一种典型实践也被称为迭代式增量软件开发模型。 在 Scrum 模型中主要包含三个核心角色与五个关键会议。三个核心角色Scrum 由三类角色构成Product Owner产品经理、Scrum Master项目经理与 Development Team研发团队。Product Owner产品经理产品经理收集用户需求将用户需求转化为软件需求。专业化术语负责梳理用户故事User Story其实就是用户需求明确其商业价值并进行优先级排序制定产品发布计划对产品整体方向与成果负责。Scrum Master项目经理负责组织各类 Scrum 会议协调项目过程中的问题为研发团队提供支持与服务保障迭代顺畅进行推动项目的进行。Development Team研发团队由具备不同技能的成员组成通过紧密协作完成每个迭代周期的目标最终交付可用的产品增量。有这些成员开发人员又分为前端开发客户端开发后端开发测试人员设计测试用例产出测试报错为项目的质量做保障设计人员对项目进行初步的设计开发人员会根据设计人员产出的设计图设计方案进行开发。…………注意这里说的是角色而不是一个人。例如产品经理一个团队可以有多个产品经理。产品经理这是一个角色不是具体指一个人。对于项目经理解释一下并不是所有的团队都有项目经理若没有项目经理产品经理还会兼任项目经理的角色。但是对于 大厂来说百度字节腾讯管理精细化一个团队都是由项目经理的。五个关键会议Scrum的流程这个流程图是这么看的从起点开始按照 1234 的顺序。Scrum 的基本流程如下产品经理Product Owner负责整理用户需求User Story形成 产品待办列表Product Backlog。发布计划会议由产品经理讲解用户需求对其进行估算与排序会议输出本期迭代需完成的用户需求列表即迭代待办列表Sprint Backlog。迭代计划会议项目团队将每个用户需求拆解为具体任务确保覆盖故事完成的全部工作明确每项任务的负责人并完成工时初步估算。每日例会由 Scrum Master项目经理 组织每日会议团队成员同步三项内容昨天完成的工作今天计划开展的工作当前遇到的阻碍问题。演示会议迭代结束后召开演示会议邀请相关人员参与团队展示本次迭代成果期间大家提出的反馈记录下来由产品经理整理为新的用户需求。回顾会议项目团队对本期迭代过程进行总结复盘不足制定改进计划并在下一次迭代中落地执行实现持续优化。如何记忆上述干巴巴的文字专业名词也多不好背我们采用自己绘图的方式理解性的记忆Scrum 的基本流程根据自己手绘的流程图去理解性的记忆比如根据这张图我是这么理解的产品经理去收集用户的需求将用户的需求放入一个需求池中。产品经理根据需求池中的用户需求评估每一次用户需求的合理性和优先级将其转化为软件需求进行开发或者软件迭代项目经理产品经理组织开展会议将许多的软件需求拆解为任务明确每一个开发参与者需要承担的任务并明确任务负责人完成任务所需的时间。任务分配好之后各个部分参与人员按部就班的进行开发或者迭代开发和迭代期间每天都要开展例会每日例会这个例会每位开发或者产品迭代的参与者都要说明三件事5.1 昨天做了什么明确每个人各自的任务进度5.2 今天做什么明确今日的目标和计划5.3 期间遇到的问题有问题及时解决能够保证产品在规定的周期内按时交付并上线产品开发完成形成可交付的软件项目经理组织演示会议进行产品的演示会议的参与者对产品提出问题再次产生用户需求产品没有问题可以发布要回顾本次产品的开发或者迭代不断优化产品可能你觉得上述我说的流程还是比较麻烦但当你多看几遍其实是很符合大众认知的一个开发流程。1.4.2 敏捷中的测试工作在敏捷模型的开发流程中测试人员应该做什么这里总结为轻文档快速迭代轻文档敏捷模式倡导轻量级文档测试人员不再局限于传统 Excel 编写测试用例转而更多采用思维导图梳理测试思路、探索性测试强调测试自由度设计与执行同步开展并依据测试结果动态调整测试策略、自动化测试等高效方式。其实就是不要写太多文档了没必要写的文档不要写必要的文档例如测试用例测试报告等文档是必须要写的并且尽量简洁不要写得和论文一样长篇大论。快速迭代敏捷核心是高效协作测试人员需主动与开发人员沟通需求、研讨方案、共同定位缺陷根因深度融入迭代过程。2. 为什么测试人员要学习开发模型学习开发模型并不是为了单纯记住几个名词。对于测试人员来说更重要的是理解不同的开发模型会影响测试人员什么时候开始测试以及测试工作应该怎么开展。瀑布模型测试通常在开发完成之后进行因此测试相对比较靠后。需求 → 设计 → 开发 → 测试螺旋模型更加重视风险分析测试需要随着开发过程不断进行。增量 迭代模型每完成一个小需求就可能需要进行测试同时还需要对之前已经完成的功能进行回归测试。敏捷模型测试人员需要尽早参与需求讨论并且跟随每一次迭代进行测试。因此随着开发模型从传统的瀑布模型逐渐发展到敏捷开发测试人员也从“开发完成后再测试”逐渐转变为“尽早参与、持续测试、快速反馈”。这也是为什么现在学习软件测试除了学习功能测试、接口测试、自动化测试等具体技术之外还需要了解软件开发模型。只有理解了整个软件的开发流程才能更好地理解测试人员什么时候介入什么时候编写测试用例什么时候开始测试为什么需要回归测试为什么敏捷开发要求测试人员快速反馈3. 总结开发模型就介绍到这里总共讲了 5 个常见开发模型瀑布模型螺旋模型增量模型迭代模型敏捷模型中的 Scrum模型最后如果这篇博客能帮到你的请你点点赞有写错了写的不好的欢迎评论指出谢谢下一篇博客测试(5) - 概念篇3-- 常见的测试模型 测试(4) - 概念篇（2）-- 常见的开发模型
测试(4) - 概念篇2-- 常见的开发模型文章目录测试(4) - 概念篇2-- 常见的开发模型1. 常见的开发模型1.1 瀑布模型1.1.1 特点1.1.2 缺点1.1.3 总结1.1.4 问题分析1.2 螺旋模型1.2.1 什么是原型1.2.2 特点1.2.3 缺点1.2.4 总结1.3 增量模型 迭代模型1.3.1 增量模型 迭代模型的区别1.3.2 增量模型 迭代模型配合使用1.3.3 使用场景1.4 敏捷模型重点1.4.1 Scrum三个核心角色五个关键会议Scrum的流程如何记忆1.4.2 敏捷中的测试工作轻文档快速迭代2. 为什么测试人员要学习开发模型3. 总结如果你是第一次看这篇博客可以看一看我软件测试–概念篇的博客介绍测试(3) - 概念篇1-- 什么是需求 软件生命周期1. 常见的开发模型开发模型实际上指的是开发一款软件/功能需要具备的开发流程首先介绍常见的开发模型之前我们需要明确一件事情上述我们讲到的软件开发的生命周期需求分析 → 计划 → 设计 → 编码 → 测试 → 运行维护这是软件开发的生命周期通用流程。也就是说无论是哪一个开发模型都是按照这个流程去设计的。就好比如炒一盘土豆丝土豆削皮并清洗切土豆丝烹饪食用这个流程是通用的你可以在任意环节在其基础上进行修改切土豆丝丝的长度粗细程度烹饪方法等打造属于你自己的土豆丝炒法。下面的介绍的开发模型也是如此是在软件开发的生命周期通用流程 上进行修改改进。1.1 瀑布模型1.1.1 特点瀑布模型是软件工程的基础框架采用线性顺序执行每个阶段仅执行一次。1.1.2 缺点其核心缺陷是可运行产品出现晚、风险高具体表现如下如果需求或设计问题存在问题到测试阶段才暴露会造成大量返工延长产品的开发周期测试在编码完成后进行若时间不足会导致测试不充分从而将软件的缺陷直接遗留给客户。但是目前仍有不少企业仍沿用其线性思想并在此基础上优化阶段、融入迭代理念。1.1.3 总结瀑布模型优缺点总结优点 / 特点强调开发的阶段性线性结构每个阶段只执行一次是其他模型的基础框架缺点测试后置前面各阶段遗留的风险推迟到测试阶段才被发现导致项目大面积返工失去了及早修复的机会必须留有足够的时间给测试活动否则导致测试不充分将缺陷直接暴露给用户产品质量差周期太长产品很迟才能被看到和使用可能会导致需求 / 功能过时1.1.4 问题分析瀑布模型存在严重的项目风险难道就不能被采用了吗并不是的。瀑布模型的适用场景需求固定的小型项目。然而企业中存在许多规模庞大、复杂度高、风险大的项目这种情况下可以采用哪种模型呢答螺旋模型。1.2 螺旋模型一般在软件开发初期需求不够明确时会采用渐进式开发模式螺旋模型就是渐进式开发模型的代表之一。螺旋模型尤其适合规模庞大、复杂度高、风险大的项目。这种迭代开发模式对软件测试提出了新的要求——不允许存在一段独立的测试时间与阶段测试必须跟随开发的迭代同步进行。这是 螺旋模型 的流程这张图片的流程你可以这样看我们也可以展开1.2.1 什么是原型你应该听说过设计图而设计图的前身叫做 原型图。设计图和你最终见到的样子是一模一样的就以百度的页面为例你看到的下面的百度页面就是 百度 这个搜索引擎的设计图。而这个设计图的前身原型图可能是长这样的随便画画看到这里你是不是觉得原型图它就像是 百度页面 的一个雏形所以设计图的制作人员就会根据 原型图 的样式绘画设计图。而我们的原型其实它就是一个软件项目的 雏形。1.2.2 特点螺旋模型 在每一个阶段都引入了 原型和风险分析。目的是为了避免各个阶段遗留的风险问题避免把问题遗留到后面的阶段导致大面积返工螺旋模型特别强调严格的全过程风险管控各个开发阶段的质量。1.2.3 缺点项目中可能存在的风险性与风险管理人员的技能水平有直接关系需求人员、资金、时间的增加和投入可能会导致项目的成本太高一句话就是风险管理人员水平参差不齐耗时资金消耗高1.2.4 总结螺旋模型优缺点总结优点缺点1. 强调严格的全过程风险管理。2. 强调各开发阶段的质量。3. 增加风险分析和原型1. 项目中可能存在的风险性与风险管理人员的技能水平有直接关系2. 需求人员、资金、时间的增加和投入可能会导致项目的成本太高1.3 增量模型 迭代模型这是增量模型的流程增量模型的思想是将大的需求分成多个小的需求每个小需求独立开发上线。那么图中的增量你可以理解为是一个一个的 小需求。而增量模型放在现在不会进行单独的使用而是搭配另一个模型进行使用那个模型是迭代模型这是迭代模型的流程迭代模型第一个上线的项目所有功能都需要实现但是每个功能不一定是完整版的不一定是最完美的。1.3.1 增量模型 迭代模型的区别如果我要画一副人物图截止到 2026年已经很少有企业会独立使用增量模型或者独立使用迭代模型了而是配合着一起使用。1.3.2 增量模型 迭代模型配合使用增量模型和迭代模型 如何配合着使用比如一个大的需求分成若干个需求分成小需求1小需求2小需求3…………此处使用了增量模型小需求1独立开发上线先是上线一个草稿版不是完整的不是最完美的根据用户的反馈和内部的意见对 小需求1进行更加完善的开发和改进。此处使用了迭代模型总结就是大需求使用增量模型分成多个小需求小需求独立开发上线使用 迭代模型进行开发。1.3.3 使用场景增量模型 和 迭代模型的适用场景大型项目且需求不明确。1.4 敏捷模型重点早期迭代瀑布模型曾是项目开发中广泛采用的流程模式。但如今开发人员在使用该模型进行软件开发时会遇到诸多问题。其中最主要的难点在于项目开发过程中难以有效响应客户提出的变更需求且整合这些变更往往需要付出高昂的成本与时间代价。为解决瀑布模型的上述缺陷20 世纪 90 年代中期即 199X 年业界提出了敏捷软件开发模型。敏捷模型的核心目标是帮助项目快速响应与适配需求变更。其根本目的是推动项目高效、灵活地落地交付。要实现这一目标就需要具备敏捷性通过让开发过程贴合项目实际删减对当前项目非必需的活动同时规避一切浪费时间与精力的环节从而达成轻量化、高效率的开发。敏捷模型具有四大核心特点轻文档、轻流程、重目标、重产出。敏捷开发包含多种实践方法其中Scrum是目前业界最为流行的一种。1.4.1 ScrumScrum是敏捷开发中的一种典型实践也被称为迭代式增量软件开发模型。 在 Scrum 模型中主要包含三个核心角色与五个关键会议。三个核心角色Scrum 由三类角色构成Product Owner产品经理、Scrum Master项目经理与 Development Team研发团队。Product Owner产品经理产品经理收集用户需求将用户需求转化为软件需求。专业化术语负责梳理用户故事User Story其实就是用户需求明确其商业价值并进行优先级排序制定产品发布计划对产品整体方向与成果负责。Scrum Master项目经理负责组织各类 Scrum 会议协调项目过程中的问题为研发团队提供支持与服务保障迭代顺畅进行推动项目的进行。Development Team研发团队由具备不同技能的成员组成通过紧密协作完成每个迭代周期的目标最终交付可用的产品增量。有这些成员开发人员又分为前端开发客户端开发后端开发测试人员设计测试用例产出测试报错为项目的质量做保障设计人员对项目进行初步的设计开发人员会根据设计人员产出的设计图设计方案进行开发。…………注意这里说的是角色而不是一个人。例如产品经理一个团队可以有多个产品经理。产品经理这是一个角色不是具体指一个人。对于项目经理解释一下并不是所有的团队都有项目经理若没有项目经理产品经理还会兼任项目经理的角色。但是对于 大厂来说百度字节腾讯管理精细化一个团队都是由项目经理的。五个关键会议Scrum的流程这个流程图是这么看的从起点开始按照 1234 的顺序。Scrum 的基本流程如下产品经理Product Owner负责整理用户需求User Story形成 产品待办列表Product Backlog。发布计划会议由产品经理讲解用户需求对其进行估算与排序会议输出本期迭代需完成的用户需求列表即迭代待办列表Sprint Backlog。迭代计划会议项目团队将每个用户需求拆解为具体任务确保覆盖故事完成的全部工作明确每项任务的负责人并完成工时初步估算。每日例会由 Scrum Master项目经理 组织每日会议团队成员同步三项内容昨天完成的工作今天计划开展的工作当前遇到的阻碍问题。演示会议迭代结束后召开演示会议邀请相关人员参与团队展示本次迭代成果期间大家提出的反馈记录下来由产品经理整理为新的用户需求。回顾会议项目团队对本期迭代过程进行总结复盘不足制定改进计划并在下一次迭代中落地执行实现持续优化。如何记忆上述干巴巴的文字专业名词也多不好背我们采用自己绘图的方式理解性的记忆Scrum 的基本流程根据自己手绘的流程图去理解性的记忆比如根据这张图我是这么理解的产品经理去收集用户的需求将用户的需求放入一个需求池中。产品经理根据需求池中的用户需求评估每一次用户需求的合理性和优先级将其转化为软件需求进行开发或者软件迭代项目经理产品经理组织开展会议将许多的软件需求拆解为任务明确每一个开发参与者需要承担的任务并明确任务负责人完成任务所需的时间。任务分配好之后各个部分参与人员按部就班的进行开发或者迭代开发和迭代期间每天都要开展例会每日例会这个例会每位开发或者产品迭代的参与者都要说明三件事5.1 昨天做了什么明确每个人各自的任务进度5.2 今天做什么明确今日的目标和计划5.3 期间遇到的问题有问题及时解决能够保证产品在规定的周期内按时交付并上线产品开发完成形成可交付的软件项目经理组织演示会议进行产品的演示会议的参与者对产品提出问题再次产生用户需求产品没有问题可以发布要回顾本次产品的开发或者迭代不断优化产品可能你觉得上述我说的流程还是比较麻烦但当你多看几遍其实是很符合大众认知的一个开发流程。1.4.2 敏捷中的测试工作在敏捷模型的开发流程中测试人员应该做什么这里总结为轻文档快速迭代轻文档敏捷模式倡导轻量级文档测试人员不再局限于传统 Excel 编写测试用例转而更多采用思维导图梳理测试思路、探索性测试强调测试自由度设计与执行同步开展并依据测试结果动态调整测试策略、自动化测试等高效方式。其实就是不要写太多文档了没必要写的文档不要写必要的文档例如测试用例测试报告等文档是必须要写的并且尽量简洁不要写得和论文一样长篇大论。快速迭代敏捷核心是高效协作测试人员需主动与开发人员沟通需求、研讨方案、共同定位缺陷根因深度融入迭代过程。2. 为什么测试人员要学习开发模型学习开发模型并不是为了单纯记住几个名词。对于测试人员来说更重要的是理解不同的开发模型会影响测试人员什么时候开始测试以及测试工作应该怎么开展。瀑布模型测试通常在开发完成之后进行因此测试相对比较靠后。需求 → 设计 → 开发 → 测试螺旋模型更加重视风险分析测试需要随着开发过程不断进行。增量 迭代模型每完成一个小需求就可能需要进行测试同时还需要对之前已经完成的功能进行回归测试。敏捷模型测试人员需要尽早参与需求讨论并且跟随每一次迭代进行测试。因此随着开发模型从传统的瀑布模型逐渐发展到敏捷开发测试人员也从“开发完成后再测试”逐渐转变为“尽早参与、持续测试、快速反馈”。这也是为什么现在学习软件测试除了学习功能测试、接口测试、自动化测试等具体技术之外还需要了解软件开发模型。只有理解了整个软件的开发流程才能更好地理解测试人员什么时候介入什么时候编写测试用例什么时候开始测试为什么需要回归测试为什么敏捷开发要求测试人员快速反馈3. 总结开发模型就介绍到这里总共讲了 5 个常见开发模型瀑布模型螺旋模型增量模型迭代模型敏捷模型中的 Scrum模型最后如果这篇博客能帮到你的请你点点赞有写错了写的不好的欢迎评论指出谢谢下一篇博客测试(5) - 概念篇3-- 常见的测试模型