软件测试按照开发阶段划分：
1.单元测试：粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
单元测试：是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
2.集成测试：界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。 主要用来测试模块与模块之间的接口，同时还要测试一些主要业务功能。集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合为程序的更大部分。方法是测试片段的组合，并最终扩展成进程，将模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有集成测试进程。
3.系统测试：粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。在经过以上各阶段测试确认之后，把系统完整地模拟客户环境来进行的测试。系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案.。它的的任务是尽可能彻底地检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统"做得怎样？"。这阶段又可分为三个步骤：模块测试，测试每个模块的程序是否有错误；组装测试，测试模块之间的接口是否正确；确认测试，测试整个软件系统是否满足用户功能和性能的要求。该阶段结束应交付测试报告，说明测试数据的选择，测试用例以及测试结果是否符合预期结果。测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。
系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试
4.验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。
按照技术划分可分为：
1.黑盒测试：不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。 一般会有一个输入值，一个输入值，和期望值做比较。黑盒测试也称功能测试，它是通过测试来检测 每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序 内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
2.白盒测试：主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑构，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖。白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。 这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
3.灰盒测试：灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
设计测试时的思路问题白盒、黑盒：是指我们看待所测试对象时的位置，是以“身处其中”（白盒）也即可以知晓其内部运作机制的角度看待并设计和执行测试用例，还是以“置身事外”（黑盒）也即只知道外面可以看见的情况完全不知道内部情况如何的方式看待并设计和执行测试用例。在往年那个生产力匮乏、工具也欠缺的年代，这种说法还很有启发作用，毕竟要去观察和跟踪系统内部运行状态并不那么容易，但在如今这个时代，哪还有什么白盒、黑盒之分？难道你在白盒测试编程语言本身的时候，会深入到编译器内部去观察语言执行情况？或者是检查硬件的数字或脉冲信号？2. 跟被测对象强相关的测多大东西、测哪个方面的问题单元测试、系统测试等：是我们所选定的测试对象的范围或规模的不同，单元测试就是关注一个类、一个函数这个级别的表现的测试，系统测试则是关注系统整体的行为。每个公司可能都会有自己的一些测试范围的名词，例如模块测试之类的。功能、压力、性能等：是我们所测试对象的不同面或者说不同的属性，或者说是被测对象在不同维度所表现出来的不同行为，也可以简称为测试类型。就好像一个人，会不会洗碗（功能）？能够连续洗碗4个小时吗（压力）？最快能够在10分钟内洗几个碗（性能）？3. 跟整体研发方式强相关的测试时间点问题集成测试、回归测试等：其实是测试的阶段，也即是说我们在计划一个项目时，按照时间顺序以及自身测试水平和能力所需要的中间过程，并非是必须的，也会因为不同的测试开展方式而有极大的不同。例如，在敏捷方式下开展测试，就没有单独的集成测试和回归测试阶段，可以认为是无时无刻不再进行集成和回归。又例如，在传统方式（例如瀑布）下，由于需求分析和测试用例设计进行方式的原因，集成和回归则会被看作是一种测试类型，以覆盖其他测试类型没有覆盖的部分。4. 跟整体测试活动相关的生产力问题测试工具：测试工具这个词本身是很泛（也即很广义）的，简单来讲，就是测试工作中用到的任何工具都可以称之为测试工具。而测试工作又包含了很多活动，例如分析需求、拟订测试计划、设计测试用例、执行测试用例、编写测试报告、提交缺陷等等，这也意味着会有很多种不同用途的测试工具，甚至，可能还有不同厂商打包不同用途的（狭义）测试工具而提供的测试工具包（也被称为测试工具）……如果你们的需求文档是用Word编写的，那么你可以认为Word是你们的一种需求工具。如果你们用DOORS或其他工具保存，那你可以认为DOORS是你们的需求管理工具。如果你们用了Lotus Notes或者QC等来管理你们的测试计划和测试用例，那么你可以认为它们是测试管理工具。如果你使用了Jira或Bugzilla等来管理你们的缺陷，那么你可以认为它们是你们的缺陷追踪系统。如果你们用了Redmine、VersionOne等敏捷项目管理工具来管理你们的测试工作任务，那么你可以认为它们也是你们的项目管理工具。如果你们使用了Robotframework、Watir、Robotium、LoadRunner等各种工具来编写自动化测试用例和执行，那么你可以认为它们就是你们的测试自动化工具。
