测试种类大汇总(45类)
Hello，大家好，工作之余就测试种类做了一下汇总和整理，以平白的语言叙述了出来，不妥之处还请大家指出来，共同进步。
我涉及到的有单元测试、端到端测试和冒烟测试。
首先是测试总的来说可以分为两大类：功能测试和非功能测试。
功能测试类型包括：单元测试、集成测试、系统测试、健全性测试、冒烟测试、接口测试、回归测试、Beta/验收测试。
非功能性测试类型包括：性能测试、负载测试、压力测试、容量测试、安全测试、恢复测试、可靠性测试、可用性测试、一致性测试、本地化测试。
0）A/B测试(A/B Testing)
就是准备两个(A/B)或者两个以上的版本，让不同的用户随机去访问这些版本，收集各版本的用户体验数据和业务数据。最后分析、评估出最好的版本
1）Alpha测试
这是软件工程中很常见的测试类型。目标就是尽可能地在发布到市场或者交付给用户之前找出所有的问题和缺陷。该测试一般是在开发的末端且在Beta测试之前进行，在这个测试过程中可能会驱动开发者进行一些小的设计变动，一般是在开发者网站进行，即只对开发者或者内部用户开放，一般可以为此类测试创建内部的虚拟用户环境。
Pre-alpha：有时候软件会在Alpha或者Beta版本前会发布该测试，相比前两者，这是个功能不完整的版本。
Alpha：版本功能还没有完善，需要进一步测试，该版本通常会发送到开发软件的分组织或者某群体中的软件测试者进行内部测试。
Beta：该版本会包含所有的功能，但是可能又有一些bug，需要调试反馈，Beta版本是软件最早的对外公开的软件版本，由公众(通常是公司外的第三方开发者和业余玩家)参与测试。
Release Candidate(rc): 发布候选版本，如果没有出现问题则可以发布成为正式的版本。这个版本包含完整并且比较稳定的功能。
2)验收测试
通常都是部署软件之前的最后一个测试操作，也称为交付测试，由最终客户执行，他们会验证端到端的系统流程是否符合业务需求，以及功能是否满足最终用户的需求。只有当所有的特性和功能按照期望的运行，客户才会接受软件。这是测试的最后阶段，在验收测试之后，软件将投入生产环境，所以它也叫做用户验收测试。举例来说，验收测试就是相当于收快递，包裹是软件、你就是客户，是验收方，货物不符合要求，是要退货的。
3)临时测试
这种测试在临时基础上进行的，有时候也称为随机测试，即没有参考任何测试用例、没有针对该测试的任何计划和文档。它的目的就是通过执行随意的流程或者或任意的功能来找出应用的缺陷和问题，它可以由项目的任何人来执行尽管没有测试用例很难识别缺陷，但是有些时候会发现无法使用现有的测试用例来识别，也就是说它是随机性的，没有事先任何的测试计划。
4)可访问性测试 它是为了确定软件或者应用程序是否可供残疾人使用。残疾人指的是聋人、色盲、智障人士、失明者、老年人和其他残疾人群体，这里会执行各种检查，比如针对视觉残疾的字体大小测试，针对色盲的颜色和对比度测试等等。5)Beta测试 它是一种正式的软件测试类型，在将产品发布作为商业用途之前完成的最终测试，通常，发布的软件或者产品的Beta版本仅仅限于特定区域的特定数量的用户，所以最终用户实际使用软件后会将一些问题反馈给公司，公司可以在全面发布之前采取必要的措施。
6)后端测试
前端应用输入的数据，一般都会存储在数据库，所以针对数据库的这类测试称为数据可测试或者后端测试，市面上有不同的数据库，所以该测试会涉及表结构、模式、存储过程以及数据结构等。后端测试一般不会涉及GUI，通过后端测试可以发现一些数据库问题，比如数据丢失、死锁、数据损坏。这些问题在生产环境之前进行修复至关重要。
7)浏览器兼容测试
这是兼容性测试的子类型，由测试团队执行，主要针对的是Web应用，用于确保软件可以在不同的浏览器或者操作系统中运行，或者验证Web应用程序是否能在浏览器的所有版本上运行，以确定应用最终兼容的范围。
8)后向兼容测试
适用于验证新开发或更新的软件是否能在就版本环境运行比如向后兼容的测试会检查新的软件是否能正确的处理旧版本软件创建的问及那格式，比如新版的office是否可以打开旧版本创建的文件同理也可以检查新版本是否可以兼容旧版本创建的数据表、数据文件、数据结构、配置文件。总则：任何软件更新应该在先前版本基础之上良好运行。
9)黑盒测试
它不考虑软件的内部系统设计，它基于需求和功能进行测试，只关心系统的输入和输出以及功能流程。换句话说该测试只是从用户的角度出发针对软件界面、功能以及外部结构进行测试，而不考虑程序内部逻辑结构，黑盒测试下面还有很对哦种类，例如集成测试、系统测试、大部分非功能性测试。
10)边界值测试
边界值测试，是测试应用处于边界条件的行为。很多边界开发者是很难考虑周到的，所以才有一个专门的测试类型来验证这种情况，边界值测试检查应用处于边界值时是否存在缺陷，边界值测试通常用于测试不同范围的数字，每个范围都有一个上下边界，就是针对这些边界值进行测试。比如数字范围是1-500，那么边界值就是在这些值上进行验证：0、1、2、499、500、501.
11)分支测试
是白盒子测试的子类型，在单元测试中实施，顾名思义，表示测试要覆盖程序代码的各种条件分支，避免遗漏缺陷，是单元测试覆盖率的一个指标之一。
12)比较测试
是将产品的优点和弱点与旧版本或者同类进行比较，比如IM会和微信作比较
13)兼容性测试
这是一个大类，用于验证应用在不同环境、web服务器、硬件、网络条件下的行为。兼容性测试确保软件可以在不同的配置、不同的数据库、不同的浏览器以及他们不同的版本下运行。
14)组件测试
一般也称为模块测试，一般是由开发者在完成单元测试后执行。将多个功能组合起来作为单一的整体进行测试，目的是发现多个功能在相互连接起来后的缺陷。组件测试可大可小。大的可以到几个单独的页面、模块、子系统的组合。比如将多个页面组合起来，测试他们流程跳转，就属于组件测试。
15)端到端测试
也是一种黑盒测试类型，类似于系统测试，端到端测试在线模拟的、完整的、真实应用环境下模拟真实用户对应用进行测试，比如应用会和数据库交互、会使用网络通信、或者在适当的情况下其他硬件、应用、系统进行交互，端到端指的是从一个端点到另一个端点的意思，所以端到端测试重点是用于测试模块和模块之间的协调性。当应用是分布式系统或者需要其他外部系统协同时，端到端测试扮演着非常重要的角色。它可以全面检查以确保软件在不同平台和环境中能准确地交互，该测试有以下目的： 确保应用可以和外部系统之间良好的协调，对于前端来说，是确保页面和后端之间的良好协调。 检查从原系统到目标系统的所有系统流 从最终用户角度验证需求 识别异构环境中的问题 我们工作中就是使用ECU-TEST测试软件去检查Ibox上的车载app是否存在异常，主要的范围是测试车载软件的性能，是否可以正常打开，数据是否加载得出来，触发的事件后台有没有记录，与后台能不能正常通信等。
16)等价划分
一种黑盒测试的测试技术，通过等价划分，可以将所有的输入数据合理地划分为多个分组，只需在每个分组中取一个数据作为测试的输入条件，这样可以实现用少量的代表性的测试数据取得较好的测试结果，所以这个测试的目的是：在不导致缺陷的前提下，移除指定分组中重复的用例，简化测试的工作。比如一个程序接受-10到10之间的值，使用等价分区方法可以划分为三个组，0、负值、正值。接下来的测试只需要从这三个分组中取一个成员进行测试，不需要每个成员都测试一遍。
17)实例测试
实时测试，包含着实时场景还涉及基于测试人员经验的场景。
18)探索测试
类似于Ad-Hoc测试，探索性测试是由测试团队进行的非正式测试。目的是探索应用并查找应用中存在的缺陷，在测试期间有一定几率发现重大甚至可能导致系统故障的缺陷。探索性测试期间，最好跟踪记录好测试的流程、以及开始该流程之前的活动记录，方便复现bug。
19)功能性测试
是一个大类，又称为行为测试，功能测试会忽略内部实现而关注组件的输出，目的是验证是否符合需求，这是一种面向功能需求的黑盒测试类型，它是相对于非功能测试而言的，功能测试需要关注功能或者业务，需要业务耦合程度高，非功能测试则是通用的，比如压力测试、负载测试等，这些都有通用的工具来支持，不需要很少定制化操作。
20)GUI测试
目的是根据业务需求验证GUI，在详细设计文档和GUI模型中一般会提到应用期望的GUI。 常见的包括测试屏幕上显示的按钮和输入字段的大小、表格中所有文本、表格或内容的对齐规则等等。
21)大猩猩测试
指的是由测试人员执行的测试类型，有时也由开发人员执行，大猩猩测试中，对模块中的一个模块或者功能进行了彻底和严格的测试，改测试会对一个功能或者模块进行重复"上百次"的测试，人类根本受不了，所以说是又称为令人沮丧的测试 目的是检查应用程序的稳健性。
22)乐观路线测试
乐观路线测试的目标是在正常流程上成功测试应用。它不会考虑各种负面或者异常情况。重点只是关注于验证应用在有效和合法输入条件下能生成期望的输出。比如银行付款，只考虑账户有钱的正常状态。
23)增量集成测试
增量集成测试是一种自下而上的测试方法，即在添加新功能时立即集成应用程序进行连续测试。应用程序功能和模块应该足够独立，以便单独测试。通常由程序员或者测试人员完成。
24)安装卸载测试
安装和卸载测试时在不同硬件或者软件环境下的不同操作系统上进行完整/部分的安装、升级、卸载、回滚等测试，常用于桌面端应用。
25)集成测试
是指将所有的模块集成之后，验证合并后的功能。模块通常是代码模块、单个应用、网络上的客户端和服务器应用等等 集成测试一般在单元测试之后，所以单元测试时集成测试的基础，没有进行单元测试的集成测试是不靠谱的。所以最简单的形式是：把两个已经测试过的单元组成一个组件，测试他们之间的接口，也就是说集成测试在单元测试的基础之上，将单元测试中独立的单元合并起来，验证他们的协调性，合并后的组件又是一个新的单元，这样逐步合并测试，最终形成完整的应用程序。这种类型的测试常用于B/S软件和分布式系统。
26)负载测试
这是一种非功能性测试，负载测试的目的是检查系统可以承受多少负载而不会降低性能，或者是说最大工作负载是多少负载测试有助于查找特定负载系统下最大容量以及导致软件性能下降的任何原因，可以使用JMeter、LoadRunner、WebLoad、Silk执行程序等工具执行负载测试。 负载测试经常和性能测试、压力测试、稳定性测试等联系在了一起，上图中的TPS(Transation Per Second)指的是每秒钟系统可以处理的交易或者事务的数量；Server Resource指的是系统资源占有。 性能测试主要是位于a-b之间，在系统测试初期就会规划一个预期目标，比如给定资源Ax，a点就是性能期望值。也就是说在给定固定资源Ax的情况下，如果TPS可以达到a点甚至更高，就说明系统性能达到或者好于预期，通过性能测试可以验证系统的处理能力有没有达到预期。 负载测试：位于b-c之间。对系统不断增加并发请求，直到系统的某项或者多项指标达到安全的临界值，比如c，这个c就是所谓的最大负载量，后面再增加请求压力，系统的处理能力不但不能提高，反倒会下降，通过压力测试可以得出系统的最大安全负载值。 压力测试可以得出系统最大的安全负载值。 压力测试位于c-d之间，在超过安全负载的情况下，继续对系统增加压力，直到达到崩溃点，即上图的d通过夜里测试可以得出系统的最大承受能力 稳定性测试，位于a-d之间，在a、b、c、d不同的点(代表特定的硬件、软件和网络环境)，让系统运行一段较长的时间，检测系统在不同条件下的系统运行的稳定性。
27)猴子测试
是由测试人员进行的，即把自己当成猴子，在没有任何知识背景或者理解应用的前提下，随意输入和操作。目标是通过随机输入数据来检查应用程序是否崩溃，猴子是随机执行的，没有测试用例，也没有必要了解全部功能。
28)变异测试（可变性测试）
是一种白盒测试，这是一种和单元测试反着来的测试类型。通常单元测试是通过测试用例来验证代码是否可靠，而编译测试是反过来，它首先是更改其中一个程序的源代码，再跑单元测试，如果单元测试可以通过则可能说明测试用例没有效果，或者测试用例没有覆盖到这处代码的变异。所以说变异测试可以反过来验证你的测试用例是否有效。还有就是可以帮助我们找出一些无法被当前测试所防止的潜在错误。
29）悲观测试
和乐观测试相反，它要求测试者要具有打破常规的思绪，考虑各种情况，使用各种邪恶的、不怀好意、不合法的操作来测试系统，悲观测试会使用不正确的数据、无效的数据进行输入来验证，它来验证系统是否可以识别异常情况并且按照预期进行。
30）非功能性测试
每一个大型组织都会有一个独立的团队，通常称为非功能测试(NFT)或者性能团队。其涉及测试肺功能的需求有负载测试、压力测试、安全性、容量、恢复测试等。NFT的目标是确保软件或者应用程序的响应时间是否满足业务需求。例如在加载任何页面或者系统都不应该花费太多的时间并且在负载峰值期间应该维持良好的运行状态
31)性能测试
这个术语常常和压力和负载测试，性能测试主要是用于检查系统是否满足性能需求，会使用不同的性能和负载工具来执行此测试。 性能测试这个范围比较大，广义上的性能测试包括上文提到的负载测试、压力测试、稳定性测试、容量测试等，狭义的性能测试指的是在特定资源条件下，测试系统能否达到期望值，也就是基线测试(Baseline Test). 基线测试：在给定的资源下，测试最佳的性能，用作后续测量的参考基线。注意基线测试和基准测试是有区别的这么理解，基准是你想达到的，比如100短跑的世界纪录，基线是你的成绩。 负载测试：在预期峰值的生产负载下测量系统的性能。 稳定性测试：在指定负载下，长时间测量系统的稳定性 压力测试：测试极端条件下的系统性能
32)恢复测试
用于验证应用或者系统中崩溃或者灾难中恢复的程度，确定系统是否能够在灾难发生后继续运行。比如应用通过网络电缆接收数据，突然断开网络的链接过一段时间再去连上网线，系统应该恢复由于网络线缆拔出而丢失连接的数据。
33)回归测试
在修改任意模块或者功能后，将应用作为一个整体进行测试，称为回归测试。目的就是验证在软件原有的功能变动后是否保持完整性。有观点认为回归测试就是回归测试，是指重复之前的全部或者部分相同的测试工作，其实是有点道理的，而且因为局部修改而牵动全身的意外在平时开发中并不少见，这种意外性就是回归测试的存在的目的。 因为在回归测试中很难覆盖所有的的系统，通常最好是使用自动化测试工具进行这类测试，比如每次修改完代码，跑单元测试来确保不影响其他软件单元。
34)基于风险的测试
在该测试中，功能或者需求将根据其优先级进行测试。基于风险的测试会优先测试高度关键的功能，因为这些功能对业务影响最大或者故障概率非常高，。而优先级由业务需求决定，因此一旦为所有功能设置了优先级，则应该首先执行高优先级功能，然后再去执行低优先级功能，低优先级功能可以在时间充裕时测试或者不测试。 基于风险测试应该在“不够时间来测试整个应用，但是又要按时交付软件”的情况下执行，通常还需要客户和高级管理层的讨论和批准之后才进行。
35)完整性测试
完整性测试用于确定一个新的软件版本是否可以开始正式的测试，如果一个应该在一开始使用时就崩溃，那么就说明系统还是不够稳定，没有必要进行下一步测试，这种情况应该给开发，以免浪费时间。 在软件设计阶段，测试就会编写冒烟测试用例； 开发团队在提交版本给测试之前会自己跑一下冒烟测试用例，检查一下没有重大意义的，影响测试进程的bug，如果有则退回开发。 如果通过了完整性测试，则进行冒烟测试，如果没有通过冒烟测试也会立即打回开发。顺利通过完整性测试和冒烟测试之后才会进入正式测试阶段。 目的之一就是为了降低测试团队的工作负担
36)安全性测试
这也是一个庞大的学科，而且知识每天都在更新，所以安全测试一般由特殊的安全团队执行，他们以各种黑客手段进行渗透测试。 安全测试旨在确保应用或者网站免受内部和外部威胁的侵害，这个测试包括预防恶意程序、病毒；检验授权和身份验证过程的安全性。他还会检查软件对任何黑客攻击和恶意程序的反应方式，以及在遭到黑客攻击后如何维护软件以保护数据安全。
37)冒烟测试
冒烟测试，每当开发团队提交新的构建的时候，软件测试团队就会首先验证构建，并不确保不存在重大问题，如果存在重大的问题会直接打回开发团队。 如何通俗的理解冒烟测试呢？这个属于硬件或者硬件组件进行更改或者修复后，直接给设备加电，如果没有冒烟，则该组件就通过了测试。举个例子，给三星Note7加电，如果没有爆炸，就通过冒烟测试。测试团队在确保构建稳定后才会进一步执行详细的测试。冒烟测试会检查构建中是否存在中断缺陷，这将阻止测试团队进一步详细测试。即如果测试人员发现主要功能不能工作，他们会拒绝这次构建，并且退回给开发团队。冒烟测试一般会在回归测试或者其他详细测试之前进行。
38)静态测试
静态测试有点类似于代码review，在不执行任何代码的情况下执行(也就是不运行应用),它涉对可交付成果审查(inspection)、review和演练(walkthrough).比如检查代码语法、命名约定、项目组织。 静态测试不仅适用于代码，也适用于测试用例、测试计划和设计文档。如果在静态测试阶段发现缺陷，可以将缺陷成本降到最低。比如在设计阶段就发现问题，相比到开发阶段甚至到生产环境出现问题要好解决。 以前端为例，静态测试可能包括： 使用Lint工具对程序进行规范检查，相关的工具有ESLint、TSLint、Stylint等，甚至Typescript这些类型检查也可以归到这个范畴。代码审查，有一些问题是无法通过Lint工具覆盖的，比如代码逻辑、异常捕获、项目组织、内存泄漏等等，这些需要人工走审查。检查代码是否与设计一致，是否符合软件需求、概要和详细设计，不仅可以看出代码问题，也可以反过来更早发现需求或者设计是否正确。
39)压力测试
通过压力测试，模拟系统收到超过其规格的压力时失败的方式和时间，找出系统的崩溃点。这个测试在高负载情况下执行的，例如存取超过容量限制的数据、执行复杂的数据库查询、连续暴力输入到系统加载到数据。
40)系统测试
系统测试在完整的系统测试上进行测试，也就是说系统测试一般都在集成测试之后进行，集成测试之后系统成为了一个整体，整个系统测试是在这个基础上、在真实运行环境验证系统是否符合业务需求。这是一种黑盒测试类型的，基于总体需求规范，涵盖系统的所有组合部分。 系统测试其实不是一个具体的测试技术，而是一个测试阶段。这个阶段会有很多种测试，一般包括：功能测试、非功能测试’归类一下系统测试的目的： 确保应用可以作为一个整体良好的运行、确保符合业务需求、确保在真实情况下可以良好的运行，比如进行一些非功能测试，验证系统的健壮性。其实系统测试和端到端测试类似，可以对比看下： 端到端测试一般针对被测应用本身的以及其依赖的的其它系统。重点关注前端、后端以及中间件之间的处理流程测试类型包含功能测试和非功能测试。
41)单元测试
测试独立的软件单元或者模块可以称为单元测试,通常是由开发者完成，不是测试人员完成，因为他需要详细了解内部程序设计和代码。 单元测试是和开发者最为密切的测试类型，它的测试对象是软件单元，软件单元可以是一个函数/方法、一个类或者一个GUI组件等。 这是一种白盒测试，所以要求开发者自己进行，因为只有开发者才知道单元的内部实现，单元测试一般会用测试覆盖率来验证单元测试的完成度。 主要是将逻辑出现的各个异常在测试的过程中全方位覆盖，保证100%的覆盖率
42)可用性测试
可用性测试用来检测应用的用户友好程度。它会验证新用户可以轻松理解应用流程，如果用户陷入麻烦，测试人员要记录好并提供帮助。可以认为可用性测试是在检查系统的导航性。
43)漏洞测试
其涉及识别软件、硬件和网络中的漏洞。如果漏洞容易受到攻击，或者容易受到病毒和蠕虫感染，黑客或者恶意程序就会控制系统。
44)容量测试
非功能测试，会检查应用在遇到大量数据的系统行为和响应时间，这种大量数据可能会影响系统的性能处理和处理时间的速度。
45)白盒测试
也称为玻璃盒测试、结构测试、逻辑驱动测试或者是基于代码的测试，基于应用程序代码的内部逻辑。即测试人员应该知道内部软件和代码是如何工作的，对所有的逻辑路径进行覆盖测试，其中，单元测试和静态测试就是典型的白盒测试，基本上白盒测试可以等同于单元测试。逻辑路径包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖等。
这只是测试的一部分，实际上有超过100种的测试类型，但是并非所有的测试类型都会被所有项目使用。总的来说就是依据实际的需求来。
更多知识可以关注下面的公众号查看：
