一. 按测试对象划分
按照测试对象划分，一共可以分为10种，下面有个顺口溜去记这10个测试：
- 文档内存兼容性
- 界面易用可双安
1. 文档测试
在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司在需求评审阶段时对需求文档进行测试，来保证需求文档的质量。
文档测试的关注点：
文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性
2. 内存泄漏测试
很多软件系统都存在内存泄露的问题，尤其是缺乏自动垃圾回收机制的“非托管”语言编写的程序，例如C、CH、Delphi等。
从用户使用的角度来看，内存泄露本身不会造成什么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。可以把这种软件的问题比喻成软件的“慢性病”。
造成内存泄露的原因有很多，最常见的有以下几种：
分配完内存之后忘了回收
程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）
某些API函数的使用不正确，造成内存泄露
内存泄漏的检测方法：
人工静态法：代码走读，人工查找未被回收的内存。
自动工具法：借助相应测试内存泄漏的工具，如Visual Leak Detector，记录每次内存分配，清楚告诉用户内存是如何泄漏的。
3. 兼容性测试
兼容性测试需求是指：明确要测试的兼容环境，考虑软，硬件的兼容，就软件兼容来说，主要考虑以下几个方面：
与应用环境的兼容性
浏览器兼容性测试（Chrome、Firefox…）
系统兼容性测试（Windows、Linux、macOS）
系统自身版本的兼容。软件通常包含多个版本，新版本要确保用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的。
测试与第三方系统以及第三方数据的兼容性。（比如一些广告或矩阵产品）
4. 可靠性测试
可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示：
可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）* 100%
系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等。
可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%
如果可用性达到99.99%，对于一个全年不间断（7*24的方式）运行的系统，意味着全年（252600min)不能正常工作的时间只有52min，不到一个小时。
如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min。
不同的应用系统，可用性的要求是不一样的，非实时性的信息系统或一般网站要求都很低，99%和99.5%就可以了，但是军事系统，要求则很高。
5. 容错性测试
容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。
容错性测试包含以下方面：
输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。比如数据级测试，校验测试，环境容错性测试，界面容错性测试。
灾难恢复性测试：通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。
可靠性和容错性的区别
有一架飞机，飞机有四个引擎，假如说有一个引擎坏了，但是飞机仍然可以正常飞行。
飞机可以正常飞行是容错性好的表现，引擎坏了是不可靠的表现。
6. 性能测试
我们在使用软件的时候有时会碰到软件网页打开时越来越慢、查询数据时很长时间才显示列表和软件运行越来越慢等问题，这些问题都是系统的性能问题引起的。
解决办法是首先要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优。常见的性能问题如下：
资源泄露
资源瓶颈
线程死锁，线程阻塞
查询速度慢或效率低
受外部系统影响越来越大
衡量一个系统性能好坏的关键性指标有，用户响时间，事务平均响应时间（TPS），吞吐率，每秒点击次数，内存和CPU使用率等。
7. 界面测试
软件只是一种工具，软件与人的信息交流是通过界面来进行的，界面是软件与用户交流最直接的一层，界面的设计决定了用户对我们设计的软件的第一印象。界面如同人的面孔，具有吸引用户的直接优势，设计合理的界面能给用户带来轻松愉悦的感受。
界面测试（简称UI测试)，指按照界面的需求（一般是UI设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：
验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；
界面的布局和色调符合当下时事的发展。
常见的界面错误有：重叠，截断，文字不合理自动换行等。
8. 易用性测试
软件需要具备简单易上手的属性。易用性包含七个要素：符合标准和规范、直观性、一致性、灵活性、舒适性、正确性和实用性。我们主要讨论以下几个方面：
（1）标准性和规范性
对于现有的软件运行平台，通常其UI标准已经不知不觉地被确立了，成为大家的共识。多数用户已经习惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。比如安装软件的界面的外观，在什么场合使用恰当的对话框等。
所以用户界面上的各中信息应该符合规范和习惯，否则用户使用起来会不舒适，并得不到用户的认可。
测试人员需要把与标准规范，习惯不一致的问题报告为缺陷。
（2）直观性
用户界面的直观性，要求软件功能特性易懂，清晰。用户界面布局合理，对操作的响应在用户的预期之中。比如数据统计结果用报表的形式（条形图，扇形图等）展示清晰直观。
（3）灵活性
软件可以有不同的选项以满足不同使用习惯的用户来完成相同的功能。但是灵活性的设计要把握好度，不然可能由于太多的用户状态和方式的选择，导致增加了软件设计的复杂性和程序实现的难度。
例如手机键盘有九宫格和全键盘，还支持手写，满足了不同用户的需求。
（4）舒适性
舒适性主要强调界面友好，美观、操作过程顺畅、色彩用运恰当、按钮的立体感等。例如左手鼠标的设置给习惯用左手的人带来了便利，也为右手十分劳累时提供了另一种途径。
9. 安全性测试
安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，保护数据正常传输和抵御黑客、病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下：
输入域，如输入恶性或者带有病毒的脚本或长字符串
代码中的安全性问题，如SQL注入、XSS漏洞
不安全的数据存储或者传递
数据文件、邮件文件、系统配置文件等里面有危害系统的信息或者数据
有问题的访问控制，权限分配等，比如水平越权、垂直越权
假冒ID：身份欺骗
篡改，对数据的恶意修改，破坏数据的完整性
10. 安装卸载测试
应用的安装和卸载在任何一款APP中都属于最基本功能。一旦出错，就属于优先级为紧要Critical的缺陷。其测试主要需要考虑以下方面：
软件不同的安装和卸载方式
应用是否可以在不同的环系统，版本下安装（安装兼容性）
安装或者卸载过程中是否可以手动暂停，或者取消
安装空不足的时候系统是否有提示
是否可以正常的卸载，以及应用软件的各种卸载方式
卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等
二. 按开发阶段划分
1. 单元测试
单元测试是针对系统最小单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试。
通常由白盒测试工程师或开发工程师来进行测试。
2. 集成测试
集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
3. 冒烟测试
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。
4. 系统测试
集成测试完成之后，测试人员准备项目环境，将程序看成一个整体，对程序/系统进行系统测试，保证系统功能符合产品规格说明书的要求。
5. 回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
回归测试在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，需要借助自动化测试来进行回归测试。
6. 验收测试
通常是用户来进行验证测试，目的就是为了验证产品/程序是否符合用户的需求。这里实际上主要是由产品人员/运营人员来进行验收。
三. 按是否查看代码划分
1. 黑盒测试
黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。所以，黑盒测试又称之为数据驱动测试，只注重软件的功能。
黑盒测试的优点
不需要了解程序内部的代码以及实现，不关注软件内部的实现。
从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维。
测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。
黑盒测试的缺点：不可能覆盖所有代码，程序效率和后继维护性得不到保障。
黑盒测试设计测试用例的方法：等价类，边界值，因果图，场景法，错误猜测法等。
2. 白盒测试
白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。
白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
3. 灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
4. 为什么不直接用灰盒测试？
因为灰盒测试没有白盒测试详细、完整，也没有黑盒测试覆盖产品功能范围那么广。所以灰盒测试是不能取代黑盒测试和白盒测试的。但是黑盒测试可以取代灰盒测试，但是不建议，需要消耗很大的代码，需要设计非常非常多的测试用例。
5. 那种测试方法用的多？
白盒测试和黑盒测试用的多。在工作中需要根据实际情况来结合白盒测试和黑盒测试。通常来说测试人员使用黑盒测试方法相对要多一点。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取