软件测试入门之软件开发和测试模型（面试必考）

说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！
接着上一篇博客继续往下写 ：https://blog.csdn.net/qq_41782425/article/details/103499612

文章目录

• 一、 软件开发模型
• • 1.为什么学习软件开发模型
  • 2.什么是软件开发模型
  • 3.常见的开发模型
  • • 3.1 大爆炸模型
    • • 3.1.1 直接冲过河去的模型
      • 3.1.2 特点
    • 3.2 边写边改模型
    • • 3.2.1 摸着石头过河的模型
      • 3.2.2 特点
    • 3.3 瀑布模型
    • • 3.3.1 制定周密计划的模型
      • 3.3.2 特点
    • 3.4 螺旋模型
    • • 3.4.1 计划赶得上变化的模型
      • 3.4.2 特点
    • 3.5 敏捷开发模型
    • • 3.5.1 起源
      • 3.5.2 敏捷宣言
      • 3.5.3 特点
• 二、 软件测试模型
• • 1.为什么学习测试模型
  • 2.常见的测试模型
  • • 2.1 V 模型
    • • 2.1.1 V 模型的提出和过程
      • 2.1.2 优点
      • 2.1.3 缺点
    • 2.2 W 模型
    • • 2.2.1 W 模型的提出和过程
      • 2.2.2 优点
      • 2.2.3 缺点
    • 2.3 H 模型
    • • 2.3.1 H 模型的提出和过程
      • 2.3.2 特点
    • 2.4 敏捷测试模型
    • • 2.4.1 极限编程
      • 2.4.2 极限测试
      • 2.4.3 基于 XP 的项目的步骤
      • 2.4.4 敏捷测试的要点总结
    • 2.5 测试模型的使用

一、 软件开发模型

1.为什么学习软件开发模型

了解开发能够更好的有针对性的做好测试。

2.什么是软件开发模型

软件开发生命周期模型是软件产品从最初构思到退役的过程。

3.常见的开发模型

• 大爆炸模型
• 边写边改模型
• 瀑布模型
• 螺旋模型
• 敏捷开发模型

3.1 大爆炸模型

3.1.1 直接冲过河去的模型

• 一大堆东西（人力和资金）放在一起，巨大的能量释放，要么产生了优秀的产品，要么是一堆废品。
  
  • 项目小组在未刻意采用其他开发模式时默认的开发模式。
  • 它在大爆炸模式基础上更进了一步，至少考虑到了产品需求。
  • 开发小组通常最初只有粗略的想法，接着进行一些简单的设计，然后开始漫长的来回编写、测试和修改缺陷的过程，直到觉得足够才发布产品。
  • 此种模式是测试期间最有可能碰到的模型。

  3.2.2 特点

  • 此种模式没有计划和文档编制，项目能够迅速展现成果，所以比较适合用完就扔的项目；
  • 与大爆炸模式类似，测试在边写边改模式中未特别强调，但是在编写代码和修复缺陷过程中举足轻重；
  • 软件测试会陷入无休止的循环往复，因为每天都可能在测试新版本。

  3.3 瀑布模型

  3.3.1 制定周密计划的模型

  
  • 1988 年，Barry Boehm（巴利?玻姆）提出。
  • 开始不必详细定义所有细节，从小开始，定义重要功能，努力实现这些功能，接收客户反馈，然后进入下一阶段，重复上述过程，直至得到最终产品。
  • 特别适合于大型复杂系统。

  3.4.2 特点

  • 螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）。加上该模式发现问题早、成本低的特点，可以算做相当好的开发模式。
  • 软件测试员喜欢该模式。因为通过参与最初设计的设计阶段，可以尽早地影响到产品，可以把产品的来龙去脉弄得很清楚；并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员地测试一直都在进行，所以最后一步只是一个验证表面所有部分都没有问题。

  3.5 敏捷开发模型

  3.5.1 起源

  • 另外一些名称：如快速原型、极限编程或进化开发等。
  • 2001 年初，在犹他州的 Snowbird，由于看到很多软件开发团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出了一些可以让软件开发团队具有轻量化、快速工作、响应变化能力的价值观和原则，他们称自己为“敏捷联盟”。

  3.5.2 敏捷宣言

  • 敏捷联盟在随后几个月，他们创建了一份价值观声明，也就是敏捷联盟宣言。
  • 这不是一份抽象的方法论集合，并没有提供任何死板僵化的开发方法和复杂的技术结构层次，而更像是一份针对客户和开发个体的箴言警句集。
    

  2.1.2 优点

  • V 模型明确地将测试分为不同的级别或阶段。
  • 每个阶段都与开发的各阶段相对应。
  • V 模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性，高层测试是为了整个系统满足用户的需求。

  2.1.3 缺点

  • 测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。
  • 测试的对象就是程序本身。忽视了测试活动对需求分析，系统设计等活动的验证和确认的功能，直到后期的验收测试才被发现。
  • 过程是线性的、顺序的，不能反复和迭代。

  2.2 W 模型

  2.2.1 W 模型的提出和过程

  • 基于尽早和不断测试的原则，W 模型既强调了测试方案设计，也强调了测试执行。
    

  2.3.2 特点

  • 它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。测试贯穿产品整个生命周期，与其他流程并发地进行。
  • 软件测试不仅仅指测试的执行，还包括很多其他的活动（计划、需求分析、用例设计、环境搭建、提交缺陷、评估总结等）。
  • 当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
  • 软件测试要尽早准备，尽早执行。
  • 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

  2.4 敏捷测试模型

  2.4.1 极限编程

  • 20 世纪 90 年代 Kent Beck 设计了一种名为极限编程（eXtreme Programming，XP）的新型软件开发方法。

  2.4.2 极限测试

  • 为了满足 XP 的流程和思想，开发人员使用了极限测试方法，该方法强调连续测试。
  • 测试在 XP 中的地位非常重要，所以需要首先创建单元（模块）测试和验收测试，然后才能创建代码库。这种形式的测试称为极限测试（eXtreme Testing，XT）。
  • XP 模型需要客户参与，高度依赖模块的单元和验收测试。
    √     对任何一个递增的代码变更，开发人员都必须进行单元测试，以确保代码库满足其规格说明的要求。
    √     单元测试完成后，用户进行验收测试。

  2.4.3 基于 XP 的项目的步骤

  • 1.程序员与客户会晤，决定产品需求并建立使用场景。客户不在场时，程序员进行会晤，将需求分解为独立的任务，并估计完成每项任务所需的时间。程序员向客户提交任务清单和时间估计，并要求客户产生一个功能优先级清单。
  • 2.每一对程序员依据应用程序的规格说明，对其编程任务生成单元测试用例。
  • 3.编程小组依据程序员具备的能力，将任务分配给结对的程序员。两位程序员协同工作，在同一台机器开发代码库，对代码进行实时检查。所有代码归所有程序员所有。遵循一致的系统隐喻，所有的代码看上去都一致。每一对程序员完成其任务，编写出代码库。每一对程序员在所有单元测试通过之前，不断修改和重测他们的代码。所有的结对程序员每天都整合、集成他们的代码库。编程小组发布应用程序的一个预览版本。
  • 4.客户进行验收测试，要么确认该应用程序，要么提交一份报告指出存在的 bug 或不足。程序员在验收测试成功的基础上发布一个产品版本。开发人员和编程小组可以随时接触客户，这样可以快速、准确地解决问题。
  • 5.程序员根据最新的经验更新时间估计。
  • 6.不允许加班。如果每周都全力工作了 25 小时，就不需要加班。在重大发布前的一星期例外。

  2.4.4 敏捷测试的要点总结

  • 敏捷测试是协同测试的一种形式，程序员结对编程，程序员分饰测试员角色，敏捷测试是连续测试。
  • 敏捷测试侧重单元测试和验收测试。单元测试的过程是先设计单元测试用例，然后进行编码，之后执行测试。
  • 敏捷测试强调客户参与，单元测试通过之后代码集成到代码库中，再由客户进行验收测试。

  2.5 测试模型的使用

  • 不同的软件生命周期模型需要使用不同的测试方法。
  • 应尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没实际意义。
  • 各种模型可以适当结合。

  来源：cdtaogang

  声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！