测试理论基础二

一 软件开发模型

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。
软件测试与软件的开发模式有着紧密的联系,作为一名测试人员,应该充分理解软件的开发模式,以便找准自己在其中的位置,从而发挥自身的价值。

  • 边做边改模式
    遗憾的是,许多产品都是使用"边做边改"模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。
    在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。

    边做边改模型

    这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:(1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;(2)忽略需求环节,给软件开发带来很大的风险;(3)没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难
    优点:前期见效快

  • 瀑布模型
    1970年Winston Royce(温斯顿·罗伊斯)提出了著名的"瀑布模型",直到80年代早期,它一直是唯一
    被广泛采用的软件开发模型。

    瀑布模型

    瀑布模型中,如图所示,将软件生命周期划分为可行性分析、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。
    但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:(1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;(2) 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;(3) 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。
    优点:

    • 开发的各个阶段比较清晰
    • 强调早期计划及需求调查
    • 适合需求稳定的产品开发
      缺点:
    • 依赖于早期的需求调查,不适应需求变化
    • 单一流程不可逆
    • 风险往往延至后期才显露,失去及早纠正的机会。
    • 问题在项目后期才开始暴露
    • 前面未发现的错误会传递并扩散到后面阶段,可能导致项目失败
  • 快速原型模型
    快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的需求,开发人员可以确定客户的真正需求是什么;第二步则是在第一步的基础上开发客户满意的软件产品。
    显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃、因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求

    原型表示.png

    image.png

    优点:

    • 可以克服瀑布模型的缺点,更好的满足用户需求并减少由于软件需求不明确带来的项目开发风险。适合预先不能确切定义需求的软件开发
      缺点:
    • 不适合大型系统的开发(适合开发小型的、灵活性高的系统)。前提要有一个展示型的产品原型,因此在一定程度上可能会限制开发人员的创新
  • 螺旋模型
    1988年,Barry Boehm(巴利·玻姆)正式发表了软件系统开发的"螺旋模型",它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。

    image.png

    如图所示,螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:(1)执行计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;(2)风险分析:分析评估所选方案,考虑如何识别和消除风险;(3)实施工程:实施软件开发和验证;(4)客户评估:评价开发工作,提出修正建议,制定下一步计划。

    优点:螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估
    缺点:采用螺旋模型需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能及时标识风险,势必会造成重大损失;过多的迭代次数会增加开发成本,延迟提交时间。

  • 其他开发模型
    https://www.jianshu.com/p/6f5c25626dbc

二 测试模型

随着测试过程的管理和发展,测试人员通过大量的实践,从而总结了不少测试模型,如常见的V模型、W模型、H模型等、这些模型与开发紧密结合,对测试活动进行了抽象,成为了测试过程管理的重要参考依据。

2.1 V模型(重点)

V模型
  • V模型是最具有代表意义的测试模型,最早是由Paul Rook在20世纪80年代后期提出,由英国国家计算机中心文献中发布,旨在改进软件开发的效率和效果;

  • V模型退出之前,人们通常把测试过程作为在需求分析、概要设计、详细设计、编码全部完成之后的一个阶段,尽管当时已经出现了测试工作会占用这个项目周期一半的时间,但是大多数人认为测试只是一个收尾工作;V模型在这个时候推出,就是为了改变之前行业的普遍认识;

  • V模型本身是软件开发中瀑布模型的变种,它反映了测试活动与分析和设计的关系;

  • V模型标明了测试过程中本身存在的不同阶段,从左到右,描述了开发过程和测试过程间的阶段对
    应关系。
    V模型大体可以划分为以下几个不同的阶段步骤:需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试

  • 需求分析
    即首先要明确客户需要的是什么,需要软件做成什么样子,需要有那几项功能,这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确的把客户所需要达到的功能,实现方式,等表述出来,给出分析结果,写出需求规格说明书。

  • 概要设计
    主要是架构的实现,指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。

  • 详细设计
    对概要设计中表述的各模块进行深入分析,对各模块组合进行分析等,这一阶段要求达到伪代码级别,已经把程序的具体实现的功能,现象等描述出来。其中需要包含数据库设计说明。

  • 软件编码
    按照详细设计好的模块功能表,编程人员编写出实际的代码。

  • 单元测试
    按照设定好的最小测试单元进行单元测试,主要是测试程序代码,为的是确保各单元模块被正确的编译,单元的具体划分按不同的单位与不同的软件有不同的规格,比如有具体到模块的测试,也有具体到类,函数的测试等。

  • 集成测试
    经过了单元测试后,将各单元组合成完整的体系,主要测试各模块间组合后的功能实现情况,以及模块接口连接的成功与否,数据传递的正确性等,其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划,一边将模块或其他软件单位组合成系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。

  • 系统测试
    经过了单元测试和集成测试以后,我们要把软件系统搭建起来,按照软件规格说明书中所要求,测试软件其性能功能等是否和用户需求相符合,在系统中运行是否存在漏洞等。

  • 验收测试
    主要就是用户在拿到软件的时候,在使用现场,会根据前边所提到的需求,以及规格说明书来做相应测试,以确定软件达到预期的效果。

    优点:

    • 包含了底层测试(单元测试)和高层测试(系统测试);
    • 清楚的标识了开发和测试的各个阶段;
    • 自上而下逐步求精,每个阶段分工明确,便于整体项目的把控。

    缺点:

    • 自上而下的顺序导致了,测试工作在编码之后,就导致错误不能及时的进行修改;
    • 实际工作中,需求经常变化,导致V模型步骤,反复执行,返工量很大,灵活度较低

2.2 W模型(重点)

W模型示意图

IEEE std1012-1998《软件验证和确认(V&V)》的原则中提出了在软件的需求和设计阶段也应有测试活动,并且提出了相应的原则;
W模型由Evolutif公司提出:开发一个V,测试一个V,组合的W模型;
测试伴随着整个软件开发周期,并且测试的对象不仅仅是程序,需求和设计同样要测试
优点:

  • 强调测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求和概要设计同样要测试;
  • 更早地介入测试,可以发现开发初期的缺陷,那么可以用更加低的成本进行缺陷修复;
  • 同样是分阶段的工作,便于控制项目过程
    缺点:
  • 依赖于软件开发和软件测试依然保持一前一后的线性关系,依然无法支持迭代、自发性和需求等变更调整;
  • 对于当前很多项目,在执行的过程中根本不产生文档,那么W模型基本无法适用;
  • 使用起来技术复杂度很高,对于需求和设计的测试要求很高,实践起来困难。
    2.3 H模型(了解)
    背景:
    人们发现虽然软件开发中需求、设计、编码等活动被分阶段执行、但是实践中,他们并不是完全串行的,它们之间更多时候是交叉和迭代执行。
    为了解决上面的问题,有专家专门提出了H模型,它将测试活动完全独立出来,形成一个完全独立的流程,同时将测试准备和测试执行也清晰表现出来
    H模型示意图

    测试流程:
  • 测试准备:所有测试执行活动的准备;判断是否到测试就绪点;
  • 测试就绪点:测试准入准则,即是否可以开始执行测试的条件;
  • 测试执行:具体的执行测试的程序。
    其他流程:
  • 具体开发中的流程,如:设计流程。
    优点:
  • 开发的H模型揭示了软件测试除测试执行外,还有很多工作;
  • 软件测试完全独立,贯穿整个生命周期,且与其他流程并发进行;
  • 软件测试活动可以尽早准备、尽早执行,具有很强的灵活性;
  • 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行,同时也是可以被迭代的。
    缺点:
  • 管理型要求高:由于模型很灵活,必须要定义清晰的规则和管理制度,否则测试过程将非常难以管理和控制;
  • 技能要求高:H模型要求能够很好的定义每个迭代的规模,不能太大也不能太小;
  • 测试就绪点分析困难:测试很多时候,你并不知道测试准备到什么时候是合适的,就绪点在哪里,就绪点的标准是什么,这就对后续的测试执行的启动带来很大困难;
  • 对于整个项目组的人员要求非常高:在很好的规范制度下,大家都能高效的工作,否则容易混乱。
    例如:你分了一个小的迭代,但是因为人员技能不足,使得无法有效完成,那么整个项目就会受到很大的干扰。

三 软件测试分类

软件测试分类

3.1按开发阶段分类

1. 单元测试
单元测试,又称模块测试。对软件的组成单位进行测试,其目的是检验软件基本组成单位的正确性。测试的对象是软件测试的最小单位:模块。

  • 测试对象:编码后或者编码前
  • 测试对象:模块
  • 测试人员:白盒测试工程师或开发人员
  • 测试依据:代码和注释+详细文档
  • 测试方法:白盒测试
  • 测试内容:模块接口测试、局部数据测试、路径测试、错误处理测试、边界测试
    补充:
    (1)学习测试依据时,我们可以对比软件测试的"V"模型结合记忆
    (2)白盒测试不止单元测试,单元测试是白盒测试
    (3)测试驱动开发:测试人员先编写测试用例,开发人员根据测试用例写程序
    2. 集成测试
    集成测试也成联合测试(联调)、组装测试:将程序模块采用适当的集成策略组装起来,对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
  • 测试阶段:一般是单元测试之后
  • 测试对象:模块间的接口
  • 测试人员:白盒测试工程师或开发工程师
  • 测试依据:单元测试的文档+概要设计文档
  • 测试方法:**黑盒测试与白盒测试(或灰盒测试)
  • 测试内容:模块之间数据传输、模块之间功能冲突、模块组装功能的正确性、全局数据结构、单模块缺陷对系统的影响
    补充:单元测试是一个模块内部的测试,集成测试是在模块之间进行测试(至少两个)
    3. 系统测试
    系统测试在系统集成完毕后进行测试,包括对功能、性能以及软件所运行的软硬件环境进行测试。前期主要测试系统的功能是否满足需求,后期主要测试系统运行的性能是都满足需求,以及系统在不同的软硬件环境中的兼容性等。包括回归测试和冒烟测试
  • 测试阶段:集成测试阶段之后
  • 测试对象:**整个系统(软件、硬件)
  • 测试人员:黑盒测试工程师
  • 测试依据:需求规格说明书
  • 测试方法:黑盒测试
  • 测试内容:功能、界面、可靠性、易用性、性能、安全性、兼容性
    回归测试(Regression Testing):指修改了旧的代码之后,重新进行测试已确认修改没有引入新的错误或导致其他代码产生错误。(自动回归测试将大幅度降低系统测试、维护升级等阶段的成本)

在整个软件测试过程中占有很大的工作比重,软件开发的各个阶段都会进行多次回归测试。
随着系统的庞大,回归测试的成本越来越大,通过正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

冒烟测试(smoke testing):该术语来自硬件,指对一个硬件或一组硬件进行更改或修复后,直接给设备加电。如果没有冒烟,则该组件就通过了测试,也可以理解为该种测试耗时短,仅用一袋烟的功夫就足够了。

  • 冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续正式的测试工作。
  • 冒烟测试的执行者是版本编译人。
  • 冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时,测试人员会先进行冒烟测试,保证基本功能正常,不阻碍后续测试。

补充:(1)系统测试是从完整的角度,广面去看待问题,不再看模块(2)虽然系统测试包括冒烟测试和回归测试,但三者之间是有严格的先后顺序的,即: 先冒烟、再系统、后回归。
4. 验收测试
是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段,也称为交付测试。验收测试的目的是确保软件准备就绪,按照项目合同、任务书、双方约定的验收依据文档,向软件购买方展示该软件系统满足原始需求。

  • 测试阶段:系统测试通过后
  • 测试对象:整个系统(包括软硬件)
  • 测试人员:主要是最终用户或者需求方
  • 测试依据:用户需求、验收标准
  • 测试方法:黑盒测试
  • 测试内容:同系统测试(功能、各类文档文档等)
    以手机举例:
    针对买回来的新手机以及它的美颜功能来进行测试。
    (1)当买回来的手机,它的美颜功能有问题时,我们只针对美颜功能的代码进行测试,就是单元测试。
    (2)对于新买回来的手机,检测手机通讯录是否可以增添、删除、更改手机号码,打电话时需要手动的输入电话,也可以在手机中查找,这就是集成测试。
    (3)新手机都会有一个合格标签,原因是出厂前手机厂商会对某一个型号的手机功能全部测试一遍,包括手机硬件本身,手机自带的APP等,这个叫系统测试。
    (4)当修好新买回来的手机的美颜功能以后,用户除了会查看美颜功能是否完好,还会查看其他功能是否也完好,这个叫回归测试。
    (5)对于新买回来的手机,我们做的第一件事是将常用的手机功能试一遍,第二件事情就是将所有功能都试一遍,这个叫冒烟测试。
    (6)对于新买回来的手机,一般都有7天包退,30天包换,我们一般都是在7天内把手机的所有功能都试一遍,这叫验收测试。

3.2按是否查看代码分类

1. 黑盒测试
黑盒测试也是功能测试,测试中把被测的软件当成一个黑盒子,不关心盒子的内部结构是什么,只关心软件的输入数据和输出数据。
2. 白盒测试
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是指打开盒子,去研究里面的源代码和程序结果。
白盒测试也是接口测试的一种
3. 灰盒测试
灰盒测试是介于白盒测试和黑盒测试之间的一种,灰盒测试多用于集成测试阶段,不仅关注输入、输出的正确性,同时也关注程序内部的情况。
灰盒测试:功能+接口

3.3 按测试执行方式分类

1.静态测试(Static testing)
静态方法是指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性,对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来发现软件错误。

  • 检查项:代码风格和规则审核;程序设计和结构的审核;业务逻辑的审核;走查、审查与技术复审手册。
  • 静态质量:度量所依据的标准是ISO9126。在该标准中,软件的质量用以下几个方面来衡量,即功能性、易用性、可靠性、效率性、可维护性、可移植性
    2. 动态测试(Dynamic testing)
    动态测试是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性、健壮性、等性能。
    (1)动态测试有三部分组成:构造测试用例、执行程序、分析程序的输出结果。
    (2)大多数软件测试都属于动态测试。

3.4 按测试对象分类

1.性能测试
检查系统是否满足需求规格说明书中规定的性能。通常表现在以下几个方面:

  • 对资源利用(如内存、处理机周期等)进行的精确度量

  • 日志事件(如中断,报错)

  • 响应时间

  • 吞吐量(TPS)

  • 辅助存储区(例如缓冲区、工作区的大小等)

  • 处理精度等进行的监测
    2. 安全测试
    安全测试是一个相对独立的领域,需要更多的专业知识。如:WEB的安全测试、需要熟悉各种网络协议、防火墙、CDN、熟悉各种操作系统的漏洞、熟悉路由器等。
    3. 兼容性测试
    兼容性测试主要是指,软件之间能否很好的运作,会不会有影响、软件和硬件之间能否发挥很好的效率工作,会不会影响导致系统的崩溃。

  • 平台测试

  • 浏览器测试

  • 测试软件能否与其它相关软件兼容

  • 数据兼容性测试
    最常见的兼容性测试就是浏览器的兼容性测试,不同浏览器在css,js解析上的不同会导致页面显示不同。
    常见的IE8的兼容性。

    4. 文档测试
    国家有关计算机软件产品开发文件编制指南中共有14种文件,可分为3大类。

  • 开发文件:可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。

  • 用户文件:用户手册、操作手册,用户文档的作用:改善易安装性;改善软件的易学性与易用性;改善软件可靠性;降低技术支持成本。

  • 管理文件:项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

    在实际的测试中,最常见的就是用户文件的测试,例如:手册说明书等。
    文档测试关注的点:

    • 文档的术语
    • 文档的正确性
    • 文档的完整性
    • 文档的一致性
    • 文档的易用性

5. 易用性测试(用户体验测试)
易用性(Useability)是交互的适应性、功能性和有效性的集中体现。又叫用户体验测试。
6. 业务测试
业务测试是指:测试人员将系统的整个模块串接起来运行、模拟真实用户实际的工作流程。满足用户需求定义的功能来进行测试的过程。
7. 界面测试
界面测试(简称UI测试),测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯,此外还要测试界面操作便捷性、导航简单易懂性,页面元素的可用性,界面中文字是否正确,命名是否统一,页面是否美观,文字、图片组合是否完美等。
8. 安装测试
安装测试是指:测试程序的安装、卸载。最典型的就是APP的安装、卸载。

3.5 按测试实施组织分类

1. α测试(Alpha Testing)
α测试由用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。
2. β测试(Beta Testing)
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客户场所进行。
3. 第三方测试
介于开发方和用户方之间的组织测试。

α测试与β测试的区别:
(1)测试的场所不同:Alpha测试指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行测试。
(2)Alpha测试的环境是受开发方控制的,用户的数量相对较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
(3)alpha测试优先于beta测试执行。通过的软件产品需要较大规模的beta测试,测试周期比较长。

3.6 按是否手工执行分类

1. 手工测试(Manual testing)
手工测试是由人一个一个的输入用例,然后观察结果,和机器测试相对应,属于比较原始但是必须的一种。

  • 优点:自动化测试无法代替探索性测试、发散思维类无既定结果的测试。
  • 缺点:执行效率慢,量大易错。
    2. 自动化测试(Automation Testing)
    所谓自动化测试,就是在预设条件下运行系统或应用程序,评估运行结果。(预先条件包括:正常条件和异常条件)。简单来说,自动化测试就是把人为驱动的测试行为,转化为机器执行的一种过程。
  • 自动化测试有:功能测试自动化、测试自动化、性能测试自动化、安全测试自动化。(一般情况下,我们说的自动化是指功能测试的自动化)
  • 自动化测试按照测试对象来分,还可以分为接口测试、UI测试等。接口测试的ROI(产出投入比)要比UI测试高。

自动化实施的步骤:
(1)完成功能测试,版本基本稳定
(2)根据项目特性,选择适合项目的自动化工具,并搭建环境
(3)提取手工测试的测试用例转换为自动化测试的用例
(4)通过工具、代码实现自动化的构造输入、自动检测输出结果是否符合预期
(5)生成自动测试报告
(6)持续改进。脚本优化

3.7 按测试地域分类

1. 国际化测试
软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及,还有软件外包行业的兴起,软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。
2. 本地化测试
之前我们一起学习的测试都是本地化测试。

四 企业面试题

  1. 软件测试方法一般知识中,(黑盒测试) 称为功能测试,(白盒测试)称为结构测试
  2. 关于自动化测试与手工测试的比较,正确的是【 C 】
    A:自动化测试能做的,手工测试不能做
    B:手工测试能做的,自动化测试都能做
    C:谁也不能完全代替对方
    D:自动化测试能做的,手工测试都能做
  3. 功能测试也叫做【 A 】
    A:FVT
    B:ST
    C:PT
    D:UAT
  4. 动态测试分为 黑盒 即功能测试,和 白盒 即结构测试。
  5. 为什么要在一个团队中开展软件测试工作?测试的目的是什么?
    参考答案
    因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。测试的目的就是希望能以最少的人力和时间发现各种错误和缺陷,修复验证后评估软件的质量。
  6. 您是否了解以往所工作的企业的软件测试过程?如果了解,请试述在这个过程中都有哪些工作要做?分别由哪些不同的角色来完成这些工作?
    参考答案
    需求分析-测试计划-测试方案-测试用例-测试执行-测试报告
    需求分析、各文档评审、用例设计、用例执行需求分析:项目组全体人员、产品人员等;测试计划和报告由测试经理负责;方案由经验丰富的测试工程师设计;其余是测试工程师
  7. 软件测试就是为了验证软件功能实现的是否正确,是否完成既定目标的活动,所以软件测试在软件工程的后期才开始具体的工作。 (×)
  8. 写出几种常见的不同内核的浏览器,同样内核的写在一格
    参考答案
    IE、Fiefox、Google Chrome、Opera、Safari
  9. 画出软件测试V模型
    需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试
  10. 集成测试、Alpha测试和Beta测试三者有何异同?
    集成测试,也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行集成测试。实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。程序在某些局部反应不出来的问题,在全局上很可能暴露出来,影响功能的实现。
    Alpha测试和Beta测试都属于验收测试。
    Alpha测试是由用户在开发者的场所进行,并且在开发者对用户的“指导”下进行测试。开发者负责记录发现在错误和使用中遇到的问题。总之,Alpha测试是在受控的环境中进行的。
    Beta测试是由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同,开发者通常不在Beta测试的现场,因Beta测试是软件在开发者不能控制的环境中“真实”应用。用户Beta测试试用期间报告的问题之后,开发者对软件产品进行必要的修改,并准备向全体客户发布最终的软件产品。

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