目录

1.根据源代码可见度划分

   1.1黑盒测试

   1.2白盒测试

   1.3灰盒测试

2.根据开发阶段划分

   2.1单元测试

   2.2集成测试

   2.3系统测试

   2.4验收测试

3.按照实施组织划分

   3.1α测试

   3.2β测试

   3.3第三方测试

4.按照是否运行程序划分

   4.1静态测试

   4.2动态测试

5.根据软件测试工作的自动化程度划分

   5.1手工测试

   5.2自动化测试

6.按照测试对象划分

   6.1界面测试

   6.2可靠性测试

   6.3容错性测试

   6.4文档测试

   6.5兼容性测试

   6.6易用性测试

   6.7安装卸载测试

   6.8安全性测试

   6.9性能测试

   6.10内存泄漏测试

---

1.根据源代码可见度划分

   1.1黑盒测试

也称功能测试、数据驱动测试，它将被测软件看作一个打不开的黑盒，主要根据功能需求设计测试用例，进行测试。

概念：黑盒测试是从一种从软件外部对软件实施的测试，也称功能测试或基于规格说明的测试。这种观点将被测程序看作一个打不开的黑盒，黑盒里面的内容(实现)是完全不知道的，只知道软件要做什么。因无法看到盒子中的内容，所以不知道软件是如何实现的，也不关心黑盒里面的结构，只关心软件的输入数据和输出结果。

检测软件功能能否按照需求规格说明书的规定正常工作，是否有功能遗漏；

检测是否有人机交互错误，是否有数据结构和外部数据库访问错误，是否能恰当地接收数据并保持外部信息（如数据库或文件）等的完整性；

检测行为、性能等特性是否满足要求等； 检测程序初始化和终止方面的错误等。

黑盒测试的优点：不需要了解程序内部的代码以及实现，不关注软件内部的实现。从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维,测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。
黑盒测试的缺点:不可能覆盖所有代码

黑盒测试用到的测试方法有，等价类，边界值，因果图，场景法，错误猜测法等

   1.2白盒测试

与侧重于功能的黑盒测试相反，白盒测试方法的目标是对软件的内部结构及其背后的逻辑进行分析。因此，白盒测试有时称为结构测试或逻辑测试。这种方法非常耗时，并且要求测试人员具有强大的编码技能，对他们正在测试的软件的全面了解，并且可以访问所有源代码和体系结构文档，否则，测试人员将无法设计适当的测试用例。

因此，白盒测试通常是由专业开发人员执行的，他们使用他们的专业知识来获得结构的内部观点，弄清楚源代码中到底发生了什么，并修复了无法正常工作的问题。除了深入的知识外，该方法还需要用于源代码分析和调试的专用工具。

白盒测试的优点：代码覆盖率比较高

白盒测试的缺点：业务功能覆盖不高

白盒测试主要包含六种测试方法：   语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

   1.3灰盒测试

灰盒测试介于白盒测试与黑合测试之间。灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒测试的方法。

2.根据开发阶段划分

   2.1单元测试

单元测试是测试过程中的最小粒度，是对程序中的单个子程序或具有独立功能的代码段进行测试，包含入口和出口的参数，输入和输出信息，错误处理信息，部分边界数值测试。

   2.2集成测试

集成测试是单元测试的基础上，将通过单元模块组装成系统或子系统，再进行测试，重点是检查模块之间的接口是否正确。

   2.3系统测试

系统测试是测试发现问题的主要阶段，针对整个产品系统的进行测试，验证系统是否满足需求规格说明书的定义，以及软件系统的正确性和性能等是否满足要求。

其中系统测试中也涵盖了回归测试和冒烟测试

 回归测试：回归测试是指修改了旧代码后，重新进行测试以确认修改后没有引入新的错误或导致其他代码产生错误。回归测试一般是在进行软件的第二轮测试开始的，验证第一轮中发现的问题是否得到修复。当然，回归也是一个循环的过程，如果回归的问题通不过，则需要开发人员修改后再次进行回归，直到通过为止。

冒烟测试：是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。引入到软件测试中，就是指测试小组在正规测试一个新版本之前，先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有实现，则打回开发组重新开发。避免由于打包失误、功能严重缺失、硬件部件损坏导致软件运行失败等严重问题而引起大量测试人员从事没有意义的测试劳动，从而节省大量的时间成本和人力、物力成本。

   2.4验收测试

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，向软件购买者展示该软件系统满足其用户的需求。

3.按照实施组织划分

   3.1α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

   3.2β测试

Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
α测试与Beta测试的区别：

• 测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
• Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
• alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。

   3.3第三方测试

介于开发方和用户方间的组织的测试 

4.按照是否运行程序划分

   4.1静态测试

静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。

   4.2动态测试

动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。

5.根据软件测试工作的自动化程度划分

   5.1手工测试

手工测试就是由人去一个一个的去执行测试用例，通过键盘鼠标等输入一些参数，查看返回结果是否符合预期结果。手工测试并不非专业术语，手工测试通常是指我们在系统测试阶段所进行的功能测试，为了更明显的与自动化测试进行区分，所以这里使用了手工测试。

   5.2自动化测试

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

 自动化测试又可分为：功能自动化测试与性能自动化测试。我们一般所说的自动化测试就是指功能自动化测试，通过相关的测试技术，通过编码的方式用一段程序来测试一个软件的功能，这样就可以重复执行程序来进行重复的测试。如果一个软件一小部分发生改变，我们只要修改一部分自动化测试代码，就可以重复的对整个软件进行功能测试；从而大大的提高了测试效率。性能自动化测试，当然，除了早期阶段，现在的性能测试工作都是通过性能测试工具辅助完成的。通过工具可以模拟成千上万的用户向系统发送请求，用来验证系统的处理能力。

6.按照测试对象划分

   6.1界面测试

界面测试（简称 UI 测试 ) ，指按照界面的需求（一般是 UI 设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：
验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；
界面的布局和色调符合当下时事的发展

   6.2可靠性测试

可靠性（ Availability ）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务 的时间占总时间的百分比表示。

可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%

可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%：
如果可用性达到 99.99% ，对于一个全年不间断（ 7*24 的方式）运行的系统，意味着全年（ 252600min) 不能 正常工作的时间只有52min ，不到一个小时。
如果可用性达到 99.999% ，意味着全年不能正常工作的时间只有 5min 。

   6.3容错性测试

容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。
容错性测试包含以下方面：
输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内 部消化掉，而不会导致系统出错甚至崩溃。  比如数据级测试，校验测试，环境容错性测试，界面容错性测试
灾难恢复性测试。 通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

   6.4文档测试

在进行文档测试时，文档测试关注要点：

 

   6.5兼容性测试

兼容性测试需求是指明确要测试的兼容环境，考虑软，硬件的兼容，就软件兼容来说，主要考虑以下几个方面：
系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的。
测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容
测试与第三方系统以及第三方数据的兼容性

   6.6易用性测试

易用性和可用性是2个不同的概念。

可用性是说软件是不是可以使用的，可以使用并不代表容易使用。

易用测试一般来说，是针对UI层面的测试，针对用户的交互界面，比如说页面是否最多点击3次鼠标就能达到用户的目的，如果超出了3次，原则上来说，就过于复杂了。还有页面风格的一致性，业务流程的逻辑，是否过于复杂。有没有误导用户的一些指引，包括网站的布局，样式，这些都属于易用性测试的范畴。

   6.7安装卸载测试

应用的安装和卸载在任何一款 APP 中都属于最基本功能。一旦出错，就属于优先级为紧要 Critical 的缺陷。主要需要考虑以下方面：
软件不同的安装和卸载方式；
应用是否可以在不同的环系统，版本下安装（安装兼容性）
安装或者卸载过程中是否可以手动暂停，或者取消
安装空不足的时候系统是否有提示
是否可以正常的卸载，以及应用软件的各种卸载方式
卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等

   6.8安全性测试

安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下
输入域，如输入恶性或者带有病毒的脚本或长字符串；
代码中的安全性问题，如SQL/XML注入
不安全的数据存储或者传递
数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
有问题的访问控制，权限分配等
假冒ID：身份欺骗
篡改，对数据的恶意修改，破坏数据的完整性

   6.9性能测试

要进行软件产品的性能问题分析，首先要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优。常见的性能问题如下：
资源泄露
资源瓶颈
线程死锁，线程阻塞
查询速度慢或效率低
受外部系统影响越来越大
衡量一个系统性能好坏的关键性指标有，用户响时间，事务平均响应时间（ TPS ），吞吐率，每秒点击次数，内存和CPU 使用率等。

   6.10内存泄漏测试

造成内存泄露的原因有很多，最常见的有以下几种。
分配完内存之后忘了回收。
程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）。
某些API函数的使用不正确，造成内存泄露。
内存泄漏的检测方法
人工静态法：代码走读，人工查找未被回收的内存。
自动工具法：借助相应测试内存泄漏的工具，如Visual Leak Detector，记录每次内存分配，清楚告诉用户内存是如何泄漏的。
6.2按是否查看代码划分