【软件测试】常用的开发、测试模型

哈喽，哈喽，大家好~ 我是你们的老朋友：保护小周ღ

今天给大家带来的是 【软件测试】常用的开发、测试模型，首先了解, 什么是软件的生命周期, 测试的生命周期, 常见的开发模型: 瀑布, 螺旋, 增量, 迭代, 敏捷. 常用的测试模型, V 模型, W 模型. 从他们的 特点、缺点、使用场景出发

一起来看看叭~

本期收录于博主的专栏: 软件测试_保护小周ღ的博客-CSDN博客

适用于编程初学者，感兴趣的朋友们可以订阅，查看其它 “软件测试内容”。

更多精彩敬请期待：保护小周ღ *★,°*:.☆(￣▽￣)/$:*.°★* ‘

一、模型

随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编写，而是扩展到了整个软件生命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新和替换新的版本。软件工程还包括很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管理，在这些方面也逐步地建立起了标准或规范。

1.1 软件生命周期

人的生命周期: 生命的孕育开始 —— 幼儿——儿童——少年——青年——老年——生命结束

假如，我作为一个开发厂商想建造一个房子，房子的生命周期是什么样子？

需求分析： 首先的有一个目的，为什么要建房子？圈哪里的地？商品房还是居民用房？建筑50层楼的技术是否可以实现？投入产出比如何？

计划：什么时候开始建房，什么时候竣工，多久可以销售入住？

设计： 房屋结构设计（地下车库，几室几厅），先打地基，再创建房屋架构，然后砌墙，封顶，粉刷装修，水电工程。

编码: 按照分析好和设计好的内容建造房子。

测试： 房屋验收，房屋是否牢固安全，是否漏水，水电是否可用，建筑是否合规……

运行维护：用户在使用房子的过程中出现了各种问题, 比如, 房屋漏水, 墙面掉漆, 重新装修, 下水道堵塞等问题就需求购房人自己花钱进行维护, 包括物业的费用也是需求支付的~

1.2 软件测试的生命周期

从产品的角度分析，测试是在开发之后。

从测试的角度分析，测试是贯穿与产品的整个生命周期的。

1.3 经典面试题

如果产品上线后出现问题，测试人员该怎么做？

项目，测试完成之后，需要进行项目上线，产品在线上运行期间，测试人员也需要及时关注产品线上运行情况，是否出现产品质量问题。

如果出现了问题：

尝试问题复现（普遍都存在问题还是个别问题）复现成功之后通知项目组内成员进行问题定位。

尝试定位问题出现的原因，帮助开发人员尽快的定位问题并解决问题。

反思问题（为什么出现问题，如何解决，后续如何避免）如果问题比较严重的话，需要写一个文档总结。

1.4 开发模型

学习模型只需要记住特点、缺点、使用场景即可。

1.4.1 瀑布模型（Waterfall Model）

优点： –强调开发的阶段性； –强调早期计划及需求调查； –强调产品测试。

缺点： –依赖于早期进行的唯一一次需求调查，不能适应需求的变化； –由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； –风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。 瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工.

在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

目前还是有软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想 , 所以也说瀑布模型是其他模型的基础框架.

1.4.2 螺旋模型（Spiral Model）

旋模型（Spiral Model）是一种软件开发过程模型，由巴里·布姆（Barry Boehm）于1988年提出。它结合了迭代开发和瀑布模型的特点，强调风险管理和持续改进。螺旋模型的主要特点是将开发过程分为若干个螺旋圈，每个圈代表一个迭代周期。每个周期包括以下四个阶段：

确定目标和计划：确定当前迭代的目标，制定计划，包括资源、时间和预算。
风险分析：评估潜在风险，制定相应的应对策略。
工程和实施：进行实际的开发工作，包括设计、编码和测试。
评估和审查：评估开发结果，审查是否达到目标，并获取反馈，以改进下一周期的工作。

在螺旋模型中，原型（Prototype）是指在开发过程中创建的初步或部分实现版本，用于验证需求和设计的有效性。原型允许开发团队与用户互动，收集反馈并进行迭代改进。通过这种方式，原型帮助识别需求变更和潜在问题，确保最终产品更符合用户需求。

特点：螺旋模型中增加了风险分析和原型

缺点：

项目中可能存在的风险性与风险管理人员的技能水平有关。

需要人员、资金、时间的增加和投入，可能会导致项目的成本太高。

使用场景： 规模庞大，复杂度高，风险大的项目尤为适合使用螺旋模型。

小结：

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。

这对于那些规模庞大、复杂度高、风险大的项目尤为适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。

1.4.3 增量模型和迭代模型

迭代模型和增量模型都是软件开发中常用的过程模型，但它们在实施方式上有所不同。

迭代模型：这个模型强调通过多个迭代周期来逐步改进软件。在每个迭代周期中，开发团队会进行需求分析、设计、编码和测试，并根据反馈不断完善软件。最终产品是在多个迭代过程中逐步成型的。每个迭代结束时会有一个可工作的版本。
增量模型：在增量模型中，软件系统被分成多个增量（即功能模块），每个增量都是一个独立的功能集合。开发团队会先开发一个基础版本，之后逐步增加更多功能模块，每个模块在完成时都会交付使用。每个增量都是可用的功能，最终通过这些增量形成完整的系统。

关键区别：

迭代模型侧重于逐步改进，主要是通过多次迭代完善已有功能。增量模型里把大的需求划分成一个个可以独立开发上线的功能。
增量模型侧重于逐步交付功能，主要是通过逐步增加新的功能来完善系统。

假如有一个软件,共有ABCDE五个功能。

增量模型: 可以先开发A B功能,再开发CDE

迭代模型: 先开发ABCDE的基础版本,然后再在基础版本上不断地进行功能的完善。

这两个模型都允许在开发过程中响应变化，但迭代模型更加注重在每个周期内不断完善，而增量模型则注重逐步交付功能。

1.4.4 敏捷模型

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷”(Agile)作为新的过程家族的名称。在会议上，他们提出了《敏捷宣言》（http://agilemanifesto.org/）：我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍，我们形成了如下价值观：

1. 个体与交互重于过程和工具

2. 可用的软件重于完备的文档

3. 客户协作重于合同谈判

4. 响应变化重于遵循计划

5. 在每对比对中，后者并非全无价值，但我们更看重前者。

敏捷模型是一种灵活、迭代的软件开发方法，强调快速交付、高度协作和持续改进。其核心原则包括：

持续交付：将软件分为小的功能增量，定期交付工作版本，确保用户可以尽早看到功能实现并提供反馈。

响应变化：对需求的变化保持开放态度，允许在开发过程中随时调整需求。

协作：强调团队成员之间的紧密合作以及与客户的持续沟通。

简化工作：关注最简洁、最有效的解决方案，避免过度开发。

自组织团队：鼓励团队自主决定工作方式和任务分配，以提高效率和创新。

敏捷模型包括多种具体实施方法，如Scrum、Kanban和Extreme Programming (XP)。敏捷方法适合需求不稳定或变化频繁的项目，可以帮助团队快速适应变化并优化产品。

敏捷开发有很多种方式，其中scrum是比较流行的一种。scrum里面的角色: scrum由 product owner(产品经理)、scrum master(项目经理) 和 team(研发团队)组成。 product owner 负责整理 user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。 scrum master 负责召开各种会议，协调项目，为研发团队服务。 研发团队则由不同技能的成员组成(美工, 前端, 后端, 测试等 )，通过紧密协同，完成每一次迭代的目标，交付产品。

Scrum 模型的核心就是: 三个角色, 五个重要会议

在敏捷开发中，测试的方式也有了新的变化：

测试的核心依旧是找Bug，但是我们需要调整心态，跟上敏捷节奏，保持灵活和开放的态度。
不再完全依赖文档，测试用例的作用有所减弱。我们更多地使用思维导图来理清思路，进行探索性测试——即在测试过程中不断设计和调整计划，根据实际情况进行调整。此外，自动化测试也成为重要的工具。
敏捷强调团队合作，测试人员应更加主动，与开发人员频繁沟通，了解需求、讨论设计，并一起分析和解决Bug的根源。这样能更好地配合团队，提升工作效率。

1.5 测试模型

1.5.1 V模型

V模型是一种软件开发和系统工程的开发模型，通常用于系统工程和软件开发中的需求管理和质量保证。它的名字来源于模型图的形状，类似于字母“V”。

V模型的主要阶段包括：

需求分析：

用户需求分析：确定系统需要实现的功能和性能要求。

系统需求分析：将用户需求转化为系统的具体需求。

系统设计：

高层设计：设计系统的总体结构和组件。

详细设计：对系统的各个组件进行详细的设计，包括数据结构、算法等。

实现：

编码：按照设计文档进行代码编写。

验证：

单元测试：测试单个模块或组件的功能是否符合设计要求(对程序最小单位进行测试, "最小单位" 是认为定义的, 可能是一个方法, 一个接口, 一个类)。

集成测试：测试系统各个模块之间的接口和集成效果。

系统测试：测试整个系统是否满足用户需求。

验收测试：由用户进行测试，确认系统是否符合用户需求并准备投入使用。

V模型的优点：

清晰的过程：通过分阶段的设计和测试，帮助团队逐步明确需求和解决问题。

早期验证：每个阶段都对应着验证阶段，能够及早发现和修复问题。

文档完善：需求、设计和测试的文档化，便于后期的维护和升级。

V模型的缺点：

缺乏灵活性：一旦需求变更，可能需要返回到之前的阶段进行修改，导致成本和时间的增加。

适应性差：不适用于快速变化的需求环境，如敏捷开发所需的那种灵活性。

总的来说，V模型适用于需求明确且变更少的项目，帮助确保系统开发过程的每个阶段都经过了充分的验证。

1.5.2 W 模型 (双 V 模型)

W模型是V模型的扩展，旨在进一步加强测试阶段的详细性和验证过程的完整性。它强调在开发过程中并行进行的验证和确认活动。

W模型的特点包括：

需求阶段：与V模型类似，确定用户需求和系统需求。

设计阶段：包括高层设计和详细设计。

实现阶段：编码和开发过程。

测试阶段：

单元测试：检查每个模块是否按设计工作。

集成测试：验证模块之间的接口和交互。

系统测试：测试整体系统的功能是否符合需求。

验收测试：最终用户验证系统是否满足其需求。

优点：

全面验证：详细的测试阶段确保系统各方面都经过充分验证。

结构清晰：强调每个阶段的测试和确认，帮助识别早期问题。

风险管理：早期和持续的验证减少项目风险。

缺点：

复杂性高：相较于V模型，W模型增加了测试和验证的复杂性。

灵活性差：变更管理困难，一旦需求或设计变更，可能需要重做多个阶段的工作。

时间和成本：详细的测试过程可能增加项目的时间和成本。