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

文章篇幅较长，阅读完大概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相比其他操作系统则更重视可访问, 而国外比国内更重视可访问性。