一文带你了解主流的测试类型

单元测试

单元测试也可以叫做模块测试——对软件的组成单位进行测试，目的是为了检验软件基本组成单位的正确性。测试的对象是软件测试的最小单位：模块。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
单元测试一般都是开发人员或者专业的白盒测试人员（这些需要对代码有很深的研究）来测试的。

集成测试

单元测试是一个模块内部的测试，当有多个单独的模块测试完成后，我们需要把这些模块放到一起进行整体的测试，这个测试叫做集成测试。集成测试也称联调测试、组装测试，即将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成测试主要关注的是关联处比较复杂，容易发生错误的模块。集成测试是在模块之间进行测试（至少两个），将两个或者两个以上的模块进行组装。

系统测试

系统测试指的是在真实或模拟系统运行的环境下，验证完整的程序系统是否可以正确的运行，并满足用户的功能需求，这里完整的程序系统可以理解为把整个软件系统看作一个整体，包括软件和硬件。举个例子，当下公司正在开发一个新的支付系统，要求测试团队对它做系统测试。那我们的测试目的，就是要把各种功能模块全部搭建并运行起来，对它进行整体的功能测试、安全测试、性能测试等，以验证它的功能，安全性，性能等各方面表现是否满足用户需求。
系统测试主要内容包括：
	a. 功能测试
	测试软件系统的功能是否正确，是否符合用户的需求，其依据是需求文档，如《产品需求规格说明书》。设计软件的目的就是满足用户对其功能的需求，如果偏离了这个目的，则任何测试工作都没有意义。
	功能测试又可细分为很多种：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等。
	
	b. 健壮性测试
	测试软件系统在在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错性，二是恢复能力。	
常见的、典型的系统测试包括：
	1. 恢复测试
	恢复测试主要关注导致软件运行失败的各种条件，并验证其恢复过程能否正确执行。在特定情况下，系统需具备容错能力。另外，系统失效必须在规定时间段内被更正，否则将会导致严重的经济损失。
	
	2. 安全测试
	安全测试用来验证系统内部的保护机制，以防止非法入侵。在安全测试中，测试人员扮演试图侵入系统的角色，采用各种办法试图突破防线。因此系统安全设计的准则是要想方设法使侵入系统所需的代价更加昂贵。
	
	 3. 压力测试

	压力测试是指在正常资源下使用异常的访问量、频率或数据量来执行系统。在压力测试中可执行以下测试：
		i. 如果平均中断数量是每秒一到两次，那么设计特殊的测试用例产生每秒十次中断。
		ii. 输入数据量增加一个量级，确定输入功能将如何响应。
		iii. 在虚拟操作系统下，产生需要最大内存量或其他资源的测试用例，或产生需要过量磁盘存储的数据。

验收测试

验收测试是技术测试的最后一个阶段，也称为交付测试。验收测试是部署软件之前的最后一个测试阶段。验收测试的目的是确保软件准备就绪，向软件购买者展示该软件系统能够满足用户的需求，一般是以用户为主的测试。验收测试的常用策略有两种，正式验收和非正式验收。

回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

Alpha测试

α测试是由用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。α测试即为非正式验收测试。

Beta测试

Beta测试是一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就会进入发布阶段。验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求， 确保所开发的软件产品符合用户的各项要求。 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

动态测试

运行程序而进行的测试，测试只是编程之后的阶段，这也是由传统的瀑布模型决定的。

静态测试

在不运行软件系统时对软件或阶段性成果进行评审，包括需求评审、设计评审、代码评审（含代码的静态分析）等。引入静态测试，就可以尽早发现问题，把问题消灭在萌芽之中，将每个阶段产生的缺陷及时清除，极大地提高产品的质量，有效地降低企业的成本。

自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计测试用例并通过评审之后，由测试人员根据测试用例中描述的规则流程一步步执行测试，把得到的实际结果与期望结果进行比较。在此过程中，为了节省人力、时间和硬件资源，提高测试效率，便引入了自动化测试的概念。

自动化测试又可分为：功能自动化测试与性能自动化测试。
功能自动化测试：是把以人为驱动的测试行为转化为机器执行的一种过程。通过测试工具录制/编写测试脚本，对软件的功能进行测试，并验证测试结果是否正确，从而代替部分的手工测试工作，达到节约人力成本和时间成本的目的。

性能自动化测试：通过性能工具来模拟成千上万的虚拟用户向系统发送请求，从而验证系统的处理能力。

性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

软件的性能包括很多方面，主要有时间性能和空间性能两种。
时间性能：主要是指软件的一个具体的响应时间。例如一个登录所需要的时间，一个商品交易所需要的时间等。当然，抛开具体的测试环境，来分析一次事务的响应时间是没有任何意义的，它需要在搭建好的一个具体且独立的测试环境下进行。
空间性能：主要指软件运行时所消耗的系统资源，例如硬件资源，CPU、内存、网络带宽消耗等。

兼容性测试

兼容性测试是指检查软件之间能否正确地进行交互和共享信息。随着用户对来自各种类型软件之间共享数据能力和充分利用空间同时执行多个程序能力的要求，测试软件之间能否协作变得越来越重要。软件兼容性测试工作的目标是保证软件按照用户期望的方式进行交互。
兼容性通常有四种：向前兼容与向后兼容、不同版本间的兼容、标准和规范、数据共享兼容。
	a. 向前兼容和向后兼容。向前兼容是指可以使用软件的未来版本，向后兼容是指可以使用软件的以前版本。并非所有的软件都要求向前兼容和向后兼容，这是软件设计者需要决定的产品特性。
	b. 不同版本之间的兼容。不同版本之间的兼容指要实现测试平台和应用软件多个版本之间能够正常工作。如要测试一个流行的操作系统的新版本，当前操作系统上可能有数十或上百万条程序，则新操作系统的目标是与它们百分之百兼容。因为不可能在一个操作系统上测试所有的软件程序，因此需要决定哪些程序是最重要的、必须测试的。对于测试新应用软件也一样，需要决定在哪个版本平台上测试，以及与什么应用程序一起测试。
	c. 标准和规范。适用于软件平台的标准和规范有两个级别：高级标准和低级标准。
		i. 高级标准是产品应当普遍遵守的。若应用程序声明与某个平台兼容，就必须接受关于该平台的标准和规范。
		ii. 低级标准是对产品开发细节的描述，从某种意义上说，低级标准比高级标准更加重要。
	d. 数据共享兼容。数据共享兼容是指要在应用程序之间共享数据，要求支持并遵守公开的标准，允许用户与其他软件无障碍的传输数据。

主动测试

主动测试是指测试人员和被测程序系统直接交互，测试人员根据所要测试的目标，主动向被测程序系统发送特定的测试输入信息，同时检查程序的输出结果，看是否符合预期。在主动测试中，测试程序及其配置和运行环境完全处在测试人员的控制之下，被测程序并不是处于正常的工作状态，而是处于被测状态。主动测试中，测试人员必须花费大量的精力来设计可执行的测试用例被动测试是指被测程序系统运行在真实的环境之下，处于正常的工作状态，测试人员不干预被测程序的运行，只是被动地接收被测程序的输入和输出信息，然后通过分析来判断程序运行是否正常。

被动测试

被动测试不需要设计测试用例，可以长时间进行测试而无需人工干预，并且不影响被测试线的执行和运行环境。被动测试需要我们对于结果进行充分的分析和判断。目前我们绝大多数的测试都是主动测试，只有线上观察、OP的系统监控、性能测试等属于被动测试。

易用性测试

易用性测试指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用。

A/B测试

A/B测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。

白盒测试

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

黑盒测试

在测试时把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

灰盒测试

是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。