标签：软件开发 day03 模型 模式 开发 测试 软件测试
软件生命周期
软件开发生命周期模型是软件产品从最初构思到退役的过程。软件生命周期的典型六个阶段如下所示：
- 问题的定义及规划
- 需求分析
- 软件设计
- 程序编码
- 软件测试
- 运行维护
常见的开发模型
常见的开发模型有下面的几种
大爆炸模型又叫直接冲过河去的模型
好比一大堆东西（人力和资金）放在一起，巨大的能量释放，要么产生了优秀的产 品，要么是一堆废品。
特点
大爆炸模式是最简单的软件开发模式，计划、进度安排和正规开发过程都几乎 没有，所有精力都花在开发软件和编写代码上； 一般，大爆炸模式几乎没有测试，只有调试，通常都会避免 在此模式下进行测试。
边写边改模型又叫摸着石头过河的模型
- 项目小组在未刻意采用其他开发模式时默认的开发模式。
- 它在大爆炸模式基础上更进了一步，至少考虑到了产品需求。
- 开发小组通常最初只有粗略的想法，接着进行一些简单的设计，然后开始漫长 的来回编写、测试和修改缺陷的过程，直到觉得足够才发布产品。
特点
- 此种模式没有计划和文档编制，项目能够迅速展现成果，所以比较适合用完就扔的项目；
- 与大爆炸模式类似，测试在边写边改模式中未特别强调，但是在编写代码和修 复缺陷过程中举足轻重；
- 软件测试会陷入无休止的循环往复，因为每天都可能在测试新版本。
瀑布模型又叫制定周密计划的模型
1970 年，温斯顿•罗伊斯（WinstonRoyce）提出，直到 80 年代早期，它一直是唯一被广泛采用的软件开发模型。 采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时，写好文档，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来直到准备好。
特点
- 瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节 都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以制定精确 的计划和进度。
- 测试对象非常明确，即程序。
- 在瀑布模型中，测试被认为是在软件开发过程的后期阶段进行的“一次性”活 动，这带来一个巨大的缺点，因为测试仅在最后进行，所以一些根本性问题可 能出现在早期，但是直到准备发布产品时才可能发现。违背了软件测试要贯穿于整个软件生命周期的原则。
- 不适合用户需求的变化。
螺旋模型又叫计划赶得上变化的模型
1988 年，Barry Boehm（巴利•玻姆）提出。 开始不必详细定义所有细节，从小开始，定义重要功能，努力实现这些功能， 接收客户反馈，然后进入下一阶段，重复上述过程，直至得到最终产品。
特点
- 螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边 写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）。加上该 模式发现问题早、成本低的特点，可以算做相当好的开发模式。
- 软件测试员喜欢该模式。因为通过参与最初设计的设计阶段，可以尽早地影响 到产品，可以把产品的来龙去脉弄得很清楚；并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员地测试一直都在进行，所以最 后一步只是一个验证表面所有部分都没有问题。
- 特别适合于大型复杂系统。
- 引入了其他模型不具备的风险分析，使软件在无法排除重大风险时，有机会停止，以减少损失。
迭代模型
迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他元素，强调开发的深入在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。迭代过程具有以下优点：
- 降低了在一个增量上的开支风险。
- 降低了产品无法按照既定进度进入市场的风险。
- 加快了整个开发工作的进度。
- 迭代过程这种模式使适应需求的变化会更容易些。
敏捷开发模型
2001 年初，在犹他州的 Snowbird，由于看到很多软件开发团队陷入了不断增 长的过程的泥潭，一批业界专家聚集在一起概括出了一些可以让软件开发团队 具有轻量化、快速工作、响应变化能力的价值观和原则，他们称自己为“敏捷 联盟”。另外一些名称：如快速原型、极限编程或进化开发等。 敏捷联盟在随后几个月，他们创建了一份价值观声明，也就是敏捷联盟宣言。 这不是一份抽象的方法论集合，并没有提供任何死板僵化的开发方法和复杂的 技术结构层次，而更像是一份针对客户和开发个体的箴言警句集。敏捷开发的核心思想是：以人为本，适应变化。
特点
- 敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。
- 敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做 好“迎接变化”的准备，客户是敏捷的关键环节。
- 敏捷开发没有单一固定的开发方法或过程，很多快速的开发模式都可以看作是
- 敏捷。但这些模式都有三个共同点：依赖客户的参与、测试驱动以及紧凑的迭 代开发周期。
增量模型
增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
优点：
- 可以分批次地提交软件产品；
- 以组件为单位进行开发降低了软件开发的风险；
- 开发顺序灵活；
快速原型模型（趋势）
迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。这种模型适合预先不能确切定义需求的软件系统的开发。
- 优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险；
- 缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下；
软件测试模型
常见的测试模型有下面几种
V 模型
1980 年， Paul Rook （保罗•洛克）提出，旨在改进瀑布模型的开发效率和效果。 “V”的左端表示传统的瀑布开发模型，而“V”的右端表明相应的测试阶段。揭示了开发过程与测试过程中各阶段的对应关系
优点
- V 模型明确地将测试分为不同的级别或阶段。
- 每个阶段都与开发的各阶段相对应。
- V 模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确 性，高层测试是为了整个系统满足用户的需求。
缺点
- V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证；
- 需求的满足情况一直到后期的验收测试才被验证；
- 没有体现出“尽早地和不断地进行软件测试”的原则。
W 模型（重点）
基于尽早和不断测试的原则，W 模型既强调了测试方案设计，也强调了测试 执行。由两个V字型模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系。
优点
- W 模型从 V 模型演化过来，实际上开发是 V，测试是并行的 V，测试与开发 同步进行。
- 测试伴随整个软件开发周期。尽早发现软件缺陷可降低软件开发的成本
- 测试的对象不仅仅是程序，需求、设计等同样要测试。
缺点
- W 模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动 也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段 工作。这样就无法支持迭代的开发模型。
H 模型
真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、 增量。为了解决 V 模型和 W 模型存在的问题，有专家提出了 H 模型。
特点
- 它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测 试执行活动清晰地体现出来。测试贯穿产品整个生命周期，与其他流程并发地 进行。
- 软件测试不仅仅指测试的执行，还包括很多其他的活动（计划、需求分析、用 例设计、环境搭建、提交缺陷、评估总结等）。
- 当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
- 软件测试要尽早准备，尽早执行。
- 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按 照某个次序先后进行的，但也可能是反复的。
X模型（了解）
X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
测试模型的使用- 不同的软件生命周期模型需要使用不同的测试方法。
- 应尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用 模型，否则也没实际意义。
- 各种模型可以适当结合。
标签：软件开发,day03,模型,模式,开发,测试,软件测试 来源： https://blog.csdn.net/weixin_44462792/article/details/114276848
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。