不知道测试什么？你需要知道的软件测试类型和常识【经典长文】

文章篇幅较长，阅读完大概20min，建议收藏阅读，读完会有收获。欢迎点赞关注。

有多少软件测试类型呢?

我们作为测试人员了解很多种不同的软件测试类型，例如功能测试(Functional Test)、非功能测试、自动测试、敏捷测试、以及它们的各种子类型. 尽管在我们的测试过程中会接触很多种测试类型, 或者听说过某些测试类型，但是很少人敢说精通所有的测试类型.

每个测试类型都有自己的特点、优势和劣势。所以我写这篇文章，科普一下我们今天最常用的测试类型.

不同的软件测试类型

下面是软件测试的通用类型列表

功能测试类型:
- 单元测试(Unit testing)
- 集成测试(Integration testing)
- 系统测试(System testing)
- 健全性测试(Sanity testing)
- 冒烟测试(Smoke testing)
- 接口测试(Interface testing)
- 回归测试(Regression testing)
- Beta/验收测试(Beta/Acceptance testing)
非功能测试类型:
- 性能测试(Performance Testing)
- 负载测试(Load testing)
- 压力测试(Stress testing)
- 容量测试(Volume testing)
- 安全测试(Security testing)
- 兼容性测试(Compatibility testing)
- 安装测试(Install testing)
- 恢复测试(Recovery testing)
- 可靠性测试(Reliability testing)
- 可用性测试(Usability testing)
- 一致性测试(Compliance testing)
- 本地化测试(Localization testing)

来看看这些测试类型的细节

0) A/B测试(A/B Testing)

顾名思义， A/B测试就是准备两个(A/B)或两个以上的版本，让不同的用户来随机访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。如上图，谷歌使用A/B测试来决定导航应该是红色还是蓝色。

1) Alpha测试(Alpha Testing)

Alpha测试这是软件工程中很常见的测试类型。它的目标就是尽可能地在发布到市场或交付给用户之前找出所有的问题和缺陷。

Alpha测试一般在开发的末段且在Beta测试之前进行。在这个测试过程中可能会驱动开发者进行一些小(minor)的设计变动. Alpha测试一般在开发者网站进行，即只对开发者或内部用户开放，一般可以为此类测试创建内部虚拟的用户环境。

一般大型的软件项目都有规范化的软件版本周期:

Pre-alpha: 有时候软件会在Alpha或Beta版本前先发布Pre-alpha版本, 相比Alpha和Beta，这是一个功能不完整的版本
Alpha: Alpha版本功能还没完善，需要进一步测试。Alpha版本通常会发送到开发软件的组织或某群体中的软件测试者进行内部测试。
Beta: 一般Beta版本会包含所有功能，但可能又有一些Bug，需要调试反馈。 Beta版本是软件最早对外公开的软件版本，由公众（通常为公司外的第三方开发者和业余玩家）参与测试。
Release Candidate(rc): 发布候选版本，如果没有出现问题则可发布成为正式的版本。这个版本包含完整且比较稳定的功能

举一个典型的例子, 最近把我坑得有点惨的iOS13的发布计划:

June 3: iOS 13 beta 1 and first look at WWDC 2019                 # -> WWDC后就可以装的，相当于pre-alpha或Alpha阶段吧
June 17: iOS 13 beta 2 launched for developers
June 24: iOS 13 public beta release date for adventurous testers  # -> 公开Beta版本，相当于上面说的Beta阶段
July 3: iOS 13 developer beta 3 launch with some new features
July 8: iOS 13 public beta 2 release date
Early September 2019: iOS 13 Golden Master (final dev beta)       # -> 九月初，该发最终Beta版本了，相当于进入RC阶段了
Mid-September 2019: iOS 13 likely to launch with new 2019 iPhones # -> 正式版本

现在很多开源项目，已经淡化了瀑布式的软件版本周期，变成一种持续(Continuous)的、常态化的行为, 例如Firefox:

2) 验收测试(Acceptance Testing)

验收测试通常是部署软件之前的最后一个测试操作, 也称为交付测试, 由最终客户执行，他们会验证端到端(end to end)的系统流程是否符合业务需求，以及功能是否是满足最终用户的需求。只有当所有的特性和功能按照期望的运行，客户才会接受软件

这是测试的最后阶段，在验收测试之后，软件将投入生产环境. 所以它也叫用户验收测试(UAT)

举个例子，验收测试就相当于收快递, 包裹是软件、你就是客户，是验收方，如果货物不符合你的要求，是要退货的。

3) 临时测试(Ad-hoc Testing)

Ad-hoc中文应该理解为临时的意思。顾名思义，这种测试是在临时基础上进行的, 有时候也称为随机测试。即没有参考测试用例、没有针对该测试的任何计划和文档。Ad-hoc测试的目的就是通过执行随意的流程或任意的功能来找出应用的缺陷和问题

Ad-hoc测试一种非正式的方法，可以由项目中的任何人执行。尽管没有测试用例很难识别缺陷，但是有些时候在Ad-hoc测试期间发现的缺陷可能无法使用现有的测试用例来识别, 也就是说它一般用来发现‘意外’的缺陷.

4) 可访问性测试(Accessibility Testing)

可访问性测试的目的是确定软件或应用程序是否可供残疾人使用。残疾是指聋人，色盲，智障人士，失明者，老年人和其他残疾人群体。这里会执行各种检查，例如针对视觉残疾的字体大小测试，针对色盲的颜色和对比度测试等等。

不同平台、不同应用类型对可访问性支持情况不太一样，比如iOS相比其他操作系统则更重视可访问, 而国外比国内更重视可访问性。

5) Beta测试(Beta Testing)

上文Alpha测试已经提及Beta测试, Beta测试是一种正式的软件测试类型，在将产品发布到市场或者实际最终用户之前，由客户在真实的应用环境中执行。

执行Beta测试目的是确保软件或产品中没有重大故障，并且满足最终用户的业务需求。当客户接受软件时，Beta测试才算通过。

通常，此类测试由最终用户或其他人完成。这是在将应用发布作为商业用途之前完成的最终测试。通常，发布的软件或产品的Beta版本仅限于特定区域中的特定数量的用户。所以最终用户实际使用软件后会将一些问题反馈给公司。公司可以在全面发布之前采取必要的措施。

Beta测试在正式版本之前也可能会迭代进行多次.

6) 后端测试(Back-end Testing)

前端应用输入的数据，一般都会存储在数据库，所以针对数据库的这类测试称为数据库测试或者后端测试. 市面有不同的数据库，如SQL Server，MySQL和Oracle等。数据库测试会涉及表结构，模式，存储过程，数据结构等。

后端测试一般不会涉及GUI，测试人员通过某些手段直接连接到数据库，从而可以容易地运行一些数据库请求来验证数据。通过后端测试可以发现一些数据库问题，比如数据丢失、死锁、数据损坏。这些问题在系统投入生产环境之前进行修复至关重要

7) 浏览器兼容测试(Browser Compatibility Testing)

这是兼容性测试的子类型，由测试团队执行. 浏览器兼容测试主要针对Web应用，用于确保软件可以在不同浏览器或操作系统中运行; 或者验证Web应用程序是否支持在浏览器的所有版本上运行, 以确定应用最终兼容的范围.

浏览器兼容测试是前端开发者绕不开的坑。

我们有很多策略来应对浏览器兼容性，比如渐进增强或者优雅降级, 还有制定浏览器兼容规范;

为了抚平浏览器之间的差异，我们会使用各种特性检测工具(Modernizr), 还有各种polyfill(CSS Normaliz, polyfill/shim, css-autoprefixer);

当然为了测试跨浏览器兼容性，还要一些辅助工具，例如BrowserStack, 对于我们这些小团队，只能下一堆Portable(Portable浏览器运行时相互隔离的, 所以不会存在配置文件等冲突问题) 浏览器，手工测试了。

8) 后向兼容测试(Backward Compatibility Testing)

向后兼容测试, 用于验证新开发或更新的软件是否能在旧版本的环境中运行。

比如向后兼容测试会检查新版软件是否可以正确地处理旧版本软件创建的文件格式。例如新版的Office 2016是否可以打开2012创建的文件。

同理也可以检查新版本是否可以兼容旧版本软件创建的数据表、数据文件、数据结构、配置文件。

任何软件更新应该在先前版本的基础之上良好地运行

9) 黑盒测试(Black Box Testing)

黑盒测试不考虑软件的内部系统设计，它基于需求和功能进行测试, 只关心系统的输入/输出以及功能流程。

换句话说黑盒测试从用户的角度出发针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构.

黑盒测试下面有很多子类，例如集成测试、系统测试、大部分非功能性测试

10) 边界值测试(Boundary Value Testing)

边界值测试, 测试应用处于边界条件(boundary level)的行为。很多边界条件开发者是很难考虑周到的，所以才有一个专门的测试类型来验证这种情况

边界值测试检查应用处于边界值时是否存在缺陷。边界值测试通常用于测试不同范围的数字, 每个范围都有一个上下边界，边界测试则是针对这些边界值进行测试。

比如数字范围为1-500, 那么边界值测试会在这些值上进行验证: 0、1、2、499、500、501

11) 分支测试(Branch Testing)

这是白盒测试的子类型，在单元测试中实施. 顾名思义，分支测试表示测试要覆盖程序代码的各种条件分支, 避免遗漏缺陷。分支覆盖是单元测试覆盖率的一个指标之一

12) 比较测试(Comparison Testing)

比较测试，将产品的优点和弱点与旧版本或者同类(竞品)产品进行比较.

比如类似王自如这种数码测评栏目，评测一个手机或者其他数码产品时，一般会横向和友商产品进行比较，有时候也会纵向和上一代产品比较.

还有一种比较典型的例子就是和行业的领导者比较，比如我们做IM的，会经常和微信比较: ‘你这个应用的启动速度怎么比微信慢这么多?’

13) 兼容性测试(Compatibility Testing)

这是一个大类, 兼容性测试用于验证应用在不同环境、web服务器、硬件、网络条件下的行为。兼容性测试确保软件可以在不同的配置、不同的数据库、不同的浏览器，以及它们不同的版本下运行。兼容性测试由测试团队实施

14) 组件测试(Component Testing)

组件测试(此组件非GUI组件, 取组合测试可能更好理解一点)，一般也称为模块测试(Module Testing), 一般由开发者在完成单元测试后执行。组件测试将多个功能组合起来作为单一的整体进行测试，目的是发现多个功能在相互连接起来之后的缺陷。

组件测试可大可小，小到函数级别或者类级别的组合，大可以大到几个单独的页面、模块、子系统的组合。举一个前端例子，将多个页面路由组合起来，测试它们的流程跳转，就属于组件测试。

15) 端到端测试(End-to-End Testing)

端到端测试也是一种黑盒测试类型，类似于系统测试. 端到端测试在模拟的、完整的、真实应用环境下模拟真实用户对应用进行测试，比如应用会和数据库交互、会使用网络通信、或者在适当的情况下和其他硬件、应用、系统进行交互. 端到端是指从一个端点到另一个端点的意思，所以端到端测试重点用于测试模块和模块之间的协调性。

当应用是分布式系统或者需要和其他外部系统协同时，端到端测试扮演着非常重要的角色, 它可以全面检查以确保软件在不同平台和环境产品能准确地交互。端到端测试有以下目的:

确保应用可以和外部系统之间良好的协调。对于前端来说，是确保页面和后端之间良好协调
检查从源系统到目标系统的所有系统流
从最终用户角度验证需求
识别异构环境中的问题

前端也有很多自动化的端到端测试工具，比如nightwatch，通过它们可以模拟用户对页面进行操作，从而检验整个应用流程是否正常和符合需求:

因为和系统测试很相似，所以它们也被经常拿来比较。

16) 等价划分(Equivalence Partitioning)

等价划分, 这是一种黑盒测试的测试技术. 通过等价划分，可以将所有的输入数据合理地划分为多个分组，我们只需在每个分组中取一个数据作为测试的输入条件, 这样可以实现用少量代表性的测试数据取得较好的测试结果.

所以说这个测试的目的: 是在不导致缺陷的前提下，移除指定分组中的重复的用例, 简化测试的工作

比如一个程序应用接受-10到+10之间的值，使用等价分区方法可以划分为三个分组: 0、负值、正值. 接下来的测试只需从这个三个分组中取一个成员进行测试, 而不需要-10到+10每个成员都测试一遍.

17) 实例测试(Example Testing)

It means real-time testing. Example testing includes the real-time scenario, it also involves the scenarios based on the experience of the testers.

实例测试意味着实时测试。实例测试包含了实时场景、另外还涉及基于测试人员经验的场景。

18) 探索测试(Exploratory Testing)

探索性测试有点类似于Ad-Hoc测试. 探索性测试是由测试团队进行的非正式测试。此测试的目的是探索应用并查找应用中存在的缺陷。像探险一样，在测试期间是有一定几率发现的重大、甚至可能导致系统故障的缺陷.

在探索性测试期间，建议跟踪记录好测试的流程、以及开始该流程之前的活动记录, 方便复现bug.

探索测试不需要任何文档和测试用例.

20) 功能测试(Functional Testing)

功能测试是一个大类, 又称为行为测试， 功能测试会忽略内部实现而关注组件的输出，目的是验证是否符合需求，这是一种面向功能需求的黑盒测试类型。

功能测试是相对非功能测试而言的, 功能测试需要关心功能或者业务，需要业务耦合程度高；而非功能测试则是通用的，比如压力测试、负载测试，这些测试都有通用的工具来支持，不需要或很少定制化操作.

21) GUI测试(Graphical User Interface (GUI) Testing)

GUI测试的目的是根据业务需求验证GUI。在详细设计文档和GUI模型(UI设计文档)中一般会提到应用期望的GUI.

常见的GUI测试包括测试屏幕上显示的按钮和输入字段的大小、表格中所有文本、表格或内容的对齐规则等等. 如果团队有UI设计规范，还会验证是否符合设计规范

22) 大猩猩测试(Gorilla Testing)

大猩猩测试是由测试人员执行的测试类型，有时也由开发人员执行。在大猩猩测试中，对模块中的一个模块或功能进行了彻底和严格的测试。原文没有说出大猩猩测试的精髓，大猩猩测试会对一个功能或模块进行重复‘上百次’的测试, 人类根本受不了这样子的测试方式，所以大猩猩测试的另一个别名是‘令人沮丧的测试(Frustrating Testing)’

这种测试的目的是检查应用程序的稳健性(robustness)

23) 乐观路线测试(Happy Path Testing)

乐观路线测试的目标是在正常流程上成功测试应用。它不会考虑各种负面或异常情况。重点只关注于验证应用在有效和合法输入的条件下生成期望的输出. 比如银行付款，只考虑账户有钱的正常状态