软件开发与测试模型

一、 软件开发模型

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

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

2. 什么是软件开发模型

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

3. 常见的开发模型

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

3.1 大爆炸模型

3.1.1 直接冲过河去的模型

  • 一大堆东西(人力和资金)放在一起,巨大的能量释放,要么产生了优秀的产 品,要么是一堆废品。
    软件开发与测试模型_第1张图片

3.1.2 特点

  • 大爆炸模式是最简单的软件开发模式,计划、进度安排和正规开发过程都几乎 没有,所有精力都花在开发软件和编写代码上;
  • 一般,大爆炸模式几乎没有测试,即使有也要挤在产品发布前,通常都会避免 在此模式下进行测试。

3.2 边写边改模型

3.2.1 摸着石头过河的模型

软件开发与测试模型_第2张图片

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

3.2.2 特点

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

3.3 瀑布模型

3.3.1 制定周密计划的模型

软件开发与测试模型_第3张图片

  • 1970 年,温斯顿•罗伊斯(WinstonRoyce)提出,直到 80 年代早期,它一直 是唯一被广泛采用的软件开发模型。
  • 采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时,写好文档,项目小组组织审查,并决定是否进入下一步。如果项目未 准备好进入下一步,就停滞下来直到准备好。

3.3.2 特点

  • 从测试的角度看来,瀑布模式比截至到目前为止的其他模式更有优势。
  • 瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时,所有细节 都已确定并有文档记录,而且实现在软件之中。由此,测试小组得以制定精确 的计划和进度。
  • 测试对象非常明确,即程序。
  • 在瀑布模型中,测试被认为是在软件开发过程的后期阶段进行的“一次性”活 动,这带来一个巨大的缺点,因为测试仅在最后进行,所以一些根本性问题可 能出现在早期,但是直到准备发布产品时才可能发现。

3.4 螺旋模型

3.4.1 计划赶得上变化的模型

软件开发与测试模型_第4张图片

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

3.4.2 特点

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

3.5 敏捷开发模型

3.5.1 起源

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

3.5.2 敏捷宣言

  • 敏捷联盟在随后几个月,他们创建了一份价值观声明,也就是敏捷联盟宣言。
  • 这不是一份抽象的方法论集合,并没有提供任何死板僵化的开发方法和复杂的 技术结构层次,而更像是一份针对客户和开发个体的箴言警句集。
    软件开发与测试模型_第5张图片
    • 通过过程和工具理解个人和交流的作用
    • 通过全面的文档理解运行的软件
    • 通过合同和谈判得到客户的协作
    • 在计划的执行中做出对变更的响应
  • 敏捷开发的核心思想是:以人为本,适应变化。

3.5.3 特点

  • 敏捷开发提倡迭代式和增量式的开发模式,并强调测试在其中的重要作用。
  • 敏捷开发是以用户为中心、以客户需求为导向的开发过程,在此过程中随时做 好“迎接变化”的准备,客户是敏捷的关键环节。
  • 敏捷开发没有单一固定的开发方法或过程,很多快速的开发模式都可以看作是 敏捷。但这些模式都有三个共同点:依赖客户的参与、测试驱动以及紧凑的迭 代开发周期。

二、 软件测试模型

1. 为什么学习测试模型

指导测试过程。

2. 常见的测试模型

  • V 模型
  • W 模型
  • H 模型
  • X 模型
    • 前置模型
    • 敏捷测试模型

2.1 V 模型

2.1.1 V 模型的提出和过程

  • 1980 年,Paul Rook(保罗•洛克)提出,旨在改进瀑布模型的开发效率和效果。
  • “V”的左端表示传统的瀑布开发模型,而“V”的右端表明相应的测试阶段。
    软件开发与测试模型_第6张图片

2.1.2 优点

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

2.1.3 缺点

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

2.2 W 模型

2.2.1 W 模型的提出和过程

  • 基于尽早和不断测试的原则,W 模型既强调了测试方案设计,也强调了测试执行。
    软件开发与测试模型_第7张图片

2.2.2 优点

  • W 模型从 V 模型演化过来,实际上开发是 V,测试是并行的 V,测试与开发 同步进行,有利于尽早地全面的发现问题。
  • 测试伴随整个软件开发周期。
  • 测试的对象不仅仅是程序,需求、设计等同样要测试。

2.2.3 缺点

  • W 模型中,需求、设计、编码等活动被视为串行的,同时,测试和开发活动 也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段 工作。这样就无法支持迭代的开发模型。

2.3 H 模型

2.3.1 H 模型的提出和过程

  • 真正的测试级别之间不存在严格的次序关系,各阶段间可以反复触发、迭代、 增量。为了解决 V 模型和 W 模型存在的问题,有专家提出了 H 模型。
    软件开发与测试模型_第8张图片

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 测试模型的使用

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

你可能感兴趣的:(软件测试理论基础)