1、开发模型

1.1、瀑布模型

  • 概念

    • 是线性模型的一种,在所有模型中占有重要地位,是所有其他模型的一个基础。
    • 每一个阶段执行一次,按线性顺序进行软件开发。

      1. ![图片.png](https://cdn.nlark.com/yuque/0/2020/png/1029078/1591325851193-94f77bcb-0b5a-4a56-9941-85387fef6264.png#align=left&display=inline&height=298&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=595&originWidth=589&size=31675&status=done&style=none&width=294.5)
  • 优点

    • 开发的各个阶段比较清晰。
    • 强调早期计划及需求调查。
    • 适合需求稳定的产品开发。
  • 缺点
    • 依赖于早期的需求调查,不适应需求的变化。
    • 单一流程不可逆。
    • 风险往往延至后期才显露,失去及早纠正的机会。
    • 问题在项目后期才开始暴露。
    • 前面未发现的错误会传递并扩散到后面的阶段,可能导致项目失败。
  • 改良

    • 沿用瀑布模型的线性思想,细化了各个阶段,在某些重要关注的阶段之间掺入迭代的思想。

      1.2、快速原型模型

  • 概念

    • 在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。
    • 第一步是建造一个快速原型,实现用户与系统的交互,用户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足用户的要求,开发人员可以确定用户的真正需求是什么。
    • 第二步是在第一步的基础上开发出用户满意的软件产品。

图片.png图片.png

  • 优点
    • 克服瀑布模型的缺点,更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。适合预先不能确切定义需求的软件系统的开发。
  • 缺点

    • 不适合大型系统的开发(适合开发小型的、灵活性高的系统)。前提要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新。

      1.3、螺旋模型

  • 概念

    • 螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期大致和瀑布模型相符合,螺旋模型沿着螺旋线旋转,即在坐标的4个象限上分别表示了4个方面的活动:制定计划、风险分析、实施开发、客户评估,如图所示:

                             ![图片.png](https://cdn.nlark.com/yuque/0/2020/png/1029078/1591326301976-21ce4b6a-97a4-4e87-9740-beb16c960850.png#align=left&display=inline&height=296&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=394&originWidth=673&size=140009&status=done&style=none&width=506)
      
  • 优点

    • 螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。
    • 需要架构师进行整体把控
  • 缺点

    • 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中, 如果未能够及时标识风险,势必造成重大损失。过多的迭代次数会增加开发成本,延迟提交时间。

      2、测试模型

      2.1、V模型(重点)

  • 概念

    • V模型是最具有代表意义的测试模型,最早是由Paul Rook在20世纪80年代后期提出,由英国国家计算机中心文献中发布,旨在改进软件开发的效率和效果;
    • V模型推出之前,人们通常把测试过程作为在需求分析、概要设计、详细设计、编码全部完成之后的一个阶段,尽管当时已经出现了测试工作会占用这个项目周期一半的时间,但是大多数人认为测试只是一个收尾工作;V模型在这个时候推出,就是为了改变之前行业的普遍认识。
    • V模型本身是软件开发中瀑布模型的变种,它反映了测试活动与分析和设计的关系。
    • V模型标明了测试过程中本身存在的不同阶段,从左到右,描述了开发过程和测试过程间的阶段对应关系。

               ![图片.png](https://cdn.nlark.com/yuque/0/2020/png/1029078/1591327650990-ebf3823d-7e31-478d-8d23-bf86402f9128.png#align=left&display=inline&height=297&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=593&originWidth=1027&size=46840&status=done&style=none&width=513.5)
      
  • V模型示意图详解:

    • 需求分析:用户需求、业务需求、需求规格说明书
    • 概要设计:系统架构、模块划分、模块与模块之间的接口。
    • 详细设计:模块内部实现的逻辑和方法。
    • 编 码:实现上面的设计。
    • 单元测试:检测代码的开发是否符合详细设计的要求。
    • 集成测试:检测此前测试过的各组成部分是否能完好地结合到一起。
    • 系统测试:检测已集成在一起的产品是否符合系统规格说明书的要求。
    • 验收测试:检测产品是否符合最终用户的需求。迭代。
  • 优点
    • 包含了底层测试(单元测试)和高层测试(系统测试);
    • 阶段划分清晰,方便工作的整体把控
  • 缺点

    • 测试阶段比较靠后,之前的的问题已经产生,修改不方便;v模型就是瀑布模型的变种,如果需求发生变化,必然要返工!

      2.2、W模型(重点)

  • 概念

    • 开发一个v,测试一个v,开发和测试并行;
    • 开发v(需求分析、概要设计、详细设计、编码、集成、实施、交付)
    • 测试v(系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试)

03-1-测试理论 - 图3

  • 优点
    • 开发伴随着测试并行,需求和设计一样要进行测试;
    • 尽早的介入测试,会更早的发现问题,降低修复成本;
    • 阶段依然明显,方便整体流程把控。
  • 缺点

    • 代码依然在测试之前,不方便代码的测试工作;
    • 如果没有文档,根本无法进行w模型;
    • 对于人员要求较高!

      2.3、H模型(了解)

  • 概念

    • 测试流程

测试准备:所有测试执行活动的准备;判断是否到测试就绪点;
测试就绪点:测试准入准则,即是否可以开始执行测试的条件;
测试执行:具体的执行测试的程序。

  • 其他流程

具体开发中的流程,如:设计流程
图片.png

  • 优点
    • 开发的H模型揭示了软件测试除测试执行外,还有很多工作;
    • 软件测试完全独立,贯穿整个生命周期,且与其他流程并发进行;
    • 软件测试活动可以尽早准备、尽早执行,具有很强的灵活性;
    • 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行,同时也是可以被迭代的。
  • 缺点

    • 管理型要求高:由于模型很灵活,必须要定义清晰的规则和管理制度,否则测试过程将非常难以管理和控制;
    • 技能要求高:H模型要求能够很好的定义每个迭代的规模,不能太大也不能太小;
    • 测试就绪点分析困难:测试很多时候,你并不知道测试准备到什么时候是合适的,就绪点在哪里,就绪点的标准是什么,这就对后续的测试执行的启动带来很大困难;
    • 对于整个项目组的人员要求非常高:在很好的规范制度下,大家都能高效的工作,否则容易混乱。例如:你分了一个小的迭代,但是因为人员技能不足,使得无法有效完成,那么整个项目就会受到很大的干扰。

      3、软件测试分类

      图片.png

      3.1、按开发阶段分类

  • 单元测试

    • 又称模块测试,针对软件设计中的最小单位——程序模块,进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
  • 集成测试
    • 又叫组装测试,通常在单元测试的基础上,将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。
  • 系统测试

    • 指的是将整个软件系统看为一个整体进行测试,包括对功能、性能、以及软件所运行的软硬件环境进行测试。
    • 系统测试在系统集成完毕后进行测试,前期主要测试系统的功能是否满足需求,后期主要测试系统运行的性能是否满足需求,以及系统在不同的软硬件环境中的兼容性等。

      3.2、按是否查看源代码分类

  • 黑盒测试

    • 又称数据驱动测试,完全不考虑程序内部结构和内部特性,注重于测试软件的功能需求,只关心软件的输入数据和输出数据。
  • 白盒测试
    • 指的是把盒子打开,去研究里面的源代码和程序结构。
  • 灰盒测试

    • 灰盒测试,是介于白盒测试与黑盒测试之间的一种测试,既可保证黑盒的关注点又可掌控白盒的内部结构,但不会去对内部程序功能和运作做详细了解,灰盒测试结合了白盒测试和黑盒测试的要素。

      3.3、黑盒测试的分类

  • 功能测试(functiontesting):是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求。

    • 逻辑功能测试(functiontesting)
    • 界面测试(UItesting)
    • 易用性测试(usability testing)
    • 安装测试(installationtesting)
    • 兼容性测试(compatibilitytesting)
  • 性能测试(performance testing):是软件测试的高端领域,性能测试工程师的待遇和白盒测试工程师不相上下,通常我们所说的高级软件测试工程师一般就是指性能测试或是白盒测试工程师。

    • 时间性能(事务响应时间等)
    • 空间性能(系统资源消耗)
    • 一般性能测试
    • 稳定性测试
    • 负载测试:通过负载测试来确定在各种工作负载下,系统各项性能指标的变化情况。
    • 压力测试:通过确定一个系统的瓶颈或者刚好不能接受的性能点,来获得系统能够提供的最大服务级别。

      3.4、按是否运行程序

  • 静态测试(static testing):指不实际运行被测软件,而只是静态地检查程序代码、界面或文档中可能存在的错误过程。

  • 动态测试(dynamic testing):是指实际运行被测程序,输入相应的测试数据,检查实际输出结果和预期结果是否相符的过程。

    3.5、其它分类

  • 回归测试

  • 冒烟测试
  • 随机测试(测试重点模块或之前出过问题的模块)
  • 验收测试:
    • 内测版本(alpha):内部人员测试,或者有很少一部分用户;此阶段要解决严重的问题
    • 公测版本(beta):所有用户都可以免费使用,通过用户的反馈修复软件的细节
    • 准正式版(gamma):跟正式版几乎一样