软件测试的分类

软件测试按照所做工作的不同,可以分为很多的方面,下面我们一起来看一下,一些常见的分类,如下图:

这里写图片描述

1、按开发阶段划分

1.1、单元测试(Unit Testing)(模块测试)

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

单元测试是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。单元测试通常也是由开发编写的(白盒测试的一种)。可以使用的方法有静态代码分析,数据流分析,代码覆盖分析等。

  • 测试阶段:编码后或者编码前
  • 测试对象:模块
  • 测试人员:白盒测试工程师或开发人员
  • 测试依据:代码和注释+详细文档
  • 测试方法:白盒测试
  • 测试内容:模块接口测试、局部数据测试、路径测试、错误处理测试、边界测试
    • 接口测试:保证进出单元模块的数据流是正确的
    • 内部数据结构:保证临时存储的数据在算法执行过程中的完整性
    • 全局数据结构:全局数据结构对单元模块的影响应当审查
    • 边界:才用边界值分析技术,保证模块在边界条件和极限情况下正常执行
    • 语句覆盖:保证每个语句执行一次
    • 错误路径:对所有处理错误的路径进行测试

补充说明:

  1. 学习测试依据时,我们可以对比软件测试的“V”模型结合记忆
  2. 白盒测试不是单元测试,单元测试是白盒测试
  3. 测试驱动开发:测试人员先编写测试用例,开发人员根据测试用例写程序

1.2、集成测试(Integration Testing)

集成测试也称联合测试(联调)、组装测试:将程序模块采用适当的集成策略组装起来,对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。此外,如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进程。一个有效的集成测试有助于解决相关的软件与其它系统的兼容性和可操作性的问题

  • 测试阶段:一般是单元测试之后
  • 测试对象:模块间的接口
  • 测试人员:白盒测试工程师或开发工程师
  • 测试依据:单元测试的文档+概要设计文档
  • 测试方法:黑盒测试与白盒测试(灰盒测试)
  • 测试内容:模块之间数据传输、模块之间功能冲突、模块组装功能的正确性、全局数据结构、单模块缺陷对系统的影响

补充说明:单元测试是一个模块内部的测试,集成测试是在模块之间进行测试(至少两个)

1.3、系统测试(System Testing)

系统测试:将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试。

  • 测试阶段:集成测试阶段之后
  • 测试对象:整个系统(软件、硬件)
  • 测试人员:黑盒测试工程师
  • 测试依据:需求规格说明文档
  • 测试方法:黑盒测试
  • 测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等
    • 所有功能需求得到满足
    • 所有性能需求得到满足
    • 其他需求(如安全性、容错性、兼容性等)得到满足

补充说明:

  1. 系统测试是从完整的角度,广面去看待问题,不再看模块
  2. 虽然系统测试包括冒烟测试和回归测试,但三者之间是有严格的先后顺序的,即:先冒烟、再系统、后回归

回归测试(Regression Testing)

回归测试指修改了旧的代码之后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。(自动回归测试将大幅度降低系统测试、维护升级等阶段的成本)。

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

回归测试方式:

  • 覆盖全部测试用例。选择基线测试用例库中的全部测试用例组成回归测试包,测试成本最高

  • 基于风险选择测试。可以基于一定的风险标准来从基线测试用例库中选择回归测试包,首先运行最重要的、最关键的和最可疑的测试用例,测试从主要特征到次要特征

  • 基于操作剖面选择测试。测试所使用的测试用例个数可以由测试预算确定,回归测试可以优先选择那些最重要或最频繁使用的功能的测试用例

  • 重新测试修改的部分。当测试者对修改的局部化有足够信心时,可以通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和他的接口上

冒烟测试(smoke testing)

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

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

1.4、验收测试(Acceptance Testing)(交付测试)

验收测试(交付测试):是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段,也称为交付测试。

验收测试的目的是确保软件准备就绪,按照项目合同、任务书、双方约定的验收依据文档,向软件购买方展示该软件系统满足原始需求。

它的测试数据通常是系统测试的测试数据的子集。。。所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

  • 测试阶段:系统测试通过后
  • 测试对象:整个系统(包括软硬件)
  • 测试人员:主要是最终用户或者需求方
  • 测试依据:用户需求、验收标准
  • 测试方法:黑盒测试
  • 测试内容:同系统测试(功能、各类文档文档等)

下面,我们以手机为例,举个例子:

针对买回来的新手机以及它的美颜功能来进行测试。

  1. 当买回来的手机,它的美颜功能有问题时,我们只针对美颜功能的代码进行测试,就是单元测试。
  2. 对于新买回来的手机,检测手机通讯录是否可以增添、删除、更改手机号码,打电话时需要手动的输入电话,也可以在手机中查找,这就是集成测试。
  3. 新手机都会有一个合格标签,原因是出厂前手机厂商会对某一个型号的手机功能全部测试一遍,包括手机硬件本身,手机自带的APP等,这个叫系统测试。
  4. 当修好新买回来的手机的美颜功能以后,用户除了会查看美颜功能是否完好,还会查看其他功能是否也完好,这个叫回归测试。
  5. 对于新买回来的手机,我们做的第一件事是将常用的手机功能试一遍,第二件事情就是讲所有功能都试一遍,这个叫冒烟测试。
  6. 对于新买回来的手机,一般都有7天包退,30天包换,我们一般都是在7天内把手机的所有功能都试一遍,这叫验收测试。

2、按是否查看代码划分

2.1、黑盒测试(Black-box Testing)

  • 黑盒测试也是功能测试,测试中把被测的软件当成一个黑盒子,不关心盒子的内部结构是什么,只关心软件的输入数据和输出数据。

2.2、白盒测试(White-box Testing)

  • 白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是指打开盒子,去研究里面的源代码和程序结果。

白盒测试也是接口测试的一种。

2.3、灰盒测试(Gray-Box Testing)

  • 灰盒测试是介于白盒测试和黑盒测试之间的一种,灰盒测试多用于集成测试阶段,不仅关注输入、输出的正确性,同时也关注程序内部的情况。

灰盒测试:功能+接口

可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

3、按是否运行划分

3.1、静态测试(Static testing)

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

  • 检查项:代码风格和规则审核;程序设计和结构的审核;业务逻辑的审核;走查、审查与技术复审手册。
  • 静态质量:度量所依据的标准是ISO9126。在该标准中,软件的质量用以下几个方面来衡量,即功能性(Functionality)、可靠(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性(Maintainability)、可移植性(Portability)。

静态测试:代码静态分析和文档测试都属于静态测试。

3.2、动态测试(Dynamic testing)

  • 动态测试是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性、健壮性、等性能。

(1)动态测试有三部分组成:构造测试用例、执行程序、分析程序的输出结果。
(2)大多数软件测试都属于动态测试。

4、按测试对象划分

4.1、性能测试

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

  • 对资源利用(如内存、处理机周期等)进行的精确度量
  • 对执行间隔
  • 日志事件(如中断,报错)
  • 响应时间
  • 吞吐量(TPS)
  • 辅助存储区(例如缓冲区、工作区的大小等)
  • 处理精度等进行的监测

4.2、安全测试

安全测试是一个相对独立的领域,需要更多的专业知识。如:WEB的安全测试、需要熟悉各种网络协议、防火墙、CDN、熟悉各种操作系统的漏洞、熟悉路由器等。

4.3、兼容性测试

兼容性测试主要是指,软件之间能否很好的运作,会不会有影响、软件和硬件之间能否发挥很好的效率工作,会不会影响导致系统的崩溃。

  • 平台测试
  • 浏览器测试
  • 软件本身能否向前或向后兼容
  • 测试软件能否与其它相关软件兼容
  • 数据兼容性测试

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

4.4、文档测试

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

  • 开发文件:可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
  • 用户文件:用户手册、操作手册。
    用户文档的作用:改善易安装性;改善软件的易学性与易用性;改善软件可靠性;降低技术支持成本。
  • 管理文件:项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

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

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

4.5、易用性测试(用户体验测试)

易用性(Useability)是交互的适应性、功能性和有效性的集中体现。又叫用户体验测试。

4.6、业务测试

业务测试是指:测试人员将系统的整个模块串接起来运行、模拟真实用户实际的工作流程。满足用户需求定义的功能来进行测试的过程。

4.7、界面测试

界面测试(简称UI测试),测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯,此外还要测试界面操作便捷性、导航简单易懂性,页面元素的可用性,界面中文字是否正确,命名是否统一,页面是否美观,文字、图片组合是否完美等。

4.8、安装测试

安装测试是指:测试程序的安装、卸载。最典型的就是APP的安装、卸载。

4.9、内存泄漏测试

内存泄漏的检测:

1、对于不同的程序可以使用不同的方法来进行内存泄露的检查,还可以使用一些专门的工具来进行内存问题的检查,例如MemProof. AQTime、Purify、BundsChecker等。 有些开发工具本身就带有内存问题检查机制.要确保程序员在编写程序和编译程序的时候打开这些功能。

2、通过代码扫描分析工具来检查

5、按测试实施的组织

5.1、α测试(Alpha Testing, Alpha 测试)

  • Alpha 测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。
  • Alpha 测试的目的是评价软件产品的 FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

预发布环:和生产环境是一样的,由本项目以外的研发和测试人员进行的测试、公司内部的客户不参与,项目以外的人员都可以进行与

5.2、β测试(Beta Testing,Beta 测试)

  • Beta 测试是一种验收测试。Beta 测试由软件的最终用户们在一个或多个客房场所进行。

Alpha 测试与 Beta 测试的区别:

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

5.3、第三方测试

  • 介于开发方和用户方之间的组织测试。

6、按是否手工执行划分

6.1、手工测试(Manual testing)

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

  • 优点:自动化测试无法代替探索性测试、发散思维类无既定结果的测试。
  • 缺点:执行效率慢,量大易错。

6.2、自动化测试(Automation Testing)

所谓自动化测试,就是在预设条件下运行系统或应用程序,评估运行结果。(预先条件包括:正常条件和异常条件)。简单来说,自动化测试就是是把人为驱动的测试行为,转化为机器执行的一种过程。

  • 自动化测试有:测试自动化、性能测试自动化、安全测试自动化。(一般情况下,我们说的自动化是指功能测试的自动化)
  • 自动化测试按照测试对象来分,还可以分为接口测试、UI测试等。接口测试的ROI(产出投入比)要比UI测试高。

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

7、按测试地域划分

7.1、国际化测试

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

本地化和国际化测试与其他类型的测试存在很多不同之处。下面是本地化和国际化测试的一些要点。

1、本地化后的软件在外观上与原来版本是否存在很大的差异,外观是否墼齐、不走样。
2、是否对所有界面元素都进行了本地化处理,包括对话框、菜单、工具栏、状态栏、提示信息(包括声音的提示)、日志等。
3、在不同的屏幕分辨率下界面是否正常显示。
4、是否存在不同的字体大小,字体设置是否恰当。
5、日期、数字格式、货币等是否能适应不同国家的文化习俗。例如,中文是年月日,而英文是月日年。
6、排序的方式是否考虑了不同语言的特点。例如,中文按照第一个字的汉语拼音顺序排序,而英文按照首字母排序。
7、在不同的国家采用不同的度量单位,软件是否能自适应和转换。
8、软件是否能在不同类型的硬件上正常运行,特别是在当地市场上销售的流行硬件上。
9、软件是否能在Windows或者其他操作系统的当地版本上正常运行。
10、联机帮助和文档是否已经翻译,翻译后的链接是否正常。正文翻译是否正确、恰当, 是否有语法错误。

软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。它要求测试人员具备一定的翻译能力、语言文化,同时具备测试人员的基本技能。

7.2、本地化测试

之前我们一起学习的测试都是本地化测试。


软件测试的分类
https://flepeng.github.io/test-软件测试的分类/
作者
Lepeng
发布于
2021年3月8日
许可协议