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)恢复测试
用于验证应用或者系统中崩溃或者灾难中恢复的程度，确定系统是否能够在灾难发生后继续运行。比如应用通过网络电缆接收数据，突然断开网络的