按照测试阶段分类：
1.单元测试——对软件中的最小可测试单元进行检查和验证
像c语言，单元测试可以看作是里面各个函数；java这种面向对象的语言，可以看作是每一个类；有界面的功能软件，单元可以看作是具体的功能项，比如一个菜单项，一个子窗口的具体功能。单元就是人为规定的最小可测试单元。
（1）单元测试一般都是针对代码的测试，在测试中需要有一些原则遵循。
1）尽可能保证各个测试用例是相互独立的
避免在一个测试脚本中、测试类中调用其他的依赖的类。
当上面测试用例失败的时候，很难判断是login出现问题，还是调用的依赖方法getpassfrodb出现的问题。正确的方法是编写一个模拟的方法来取代使用外部依赖。对于必须验证的依赖的关系，可以放到后面的集成测试中来做，这样才能保证有一个易维护的高质量单元测试。
2）一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计需求。
现在的敏捷研发，还强调有结对编程，也可以由结对的编程人员来做这个测试。总之，实施单元测试的人，需要对被测试的模块代码有相当程度的了解。
（2）软件测试的不同阶段中，单元测试是一个非常重要的阶段，可以说是其他测试阶段的基础。为什么呢？
1）第一点 能够尽早发现缺陷：现在的敏捷研发还强调TDD（测试驱动开发），就是先编写单元测试，再编写功能代码，并保证这些代码能够使单元测试用例通过。这样不仅能够保证所编写出来的代码经过了充分必要的单元测试，而且在编写单元测试的时候是对需求事迹的二次确认和理解的过程，这样就能够保证我们的开发人员在开发的时候对需求设计有一个清晰的理解。
2）第二点 有利于重构：软件产品不断地变化，重构总是存在的。单元测试能够很大程度上保证重构后的正确性，有了单元测试能够在重构时候快速识别出出现问题的地方。
3）第三点 简化集成：通过单元测试保证了最小测试模块的稳定性和正确性，为后面的集成测试奠定了基础。只有充分的单元测试，集成测试才能更加聚焦到模块的关系上，而不用再花时间到单元内部的逻辑验证上。
4）第四点 文档：现代的敏捷研发还提倡一个代码级文档，就是尽可能地减少文档。因为代码总是在不断地变化，经常需要修改，如果还同步维护一个文档， 修改代码也意味着文档的修改，会使工作量成倍的提高。单元测试包含了对功能模块的基本的理解，如果单元测试比较规范，其实通过对单元测试代码的阅读就能基本理解模块功能的特性，就可以很大程度上减少文档的存在。
5）第五点 用于设计：通过编写单元测试可以把设计思路体现在单元测试组织中，而且相对于UML（基于图形的设计方法），单元测试有一个最大的优点就是，设计的本身是可以用来验证设计的。
（3）单元测试的限制
1）不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误。
2）每一行代码，一般需要3~5行测试代码才能完成单元测试，所以存在投入和产出的一个平衡。3~5行是一个经验数字，可以看出单元测试的投入是非常大的。前面也说过穷尽测试是不可能的，所以要在单元测试中找到一个最佳的性价比。
（4）单元测试框架（单元测试是对代码进行测试，需要各种各样的框架）
以junit为例说明
打开eclipse，建一个java工程，将junit依赖库导入到项目中
测试这个功能代码，右键new->junit test setup teardown
待测类的方法进行选择,finish之后会生成单元测试代码的基本的框架
编写之后
死循环超时限制 除法除零的异常
单元测试脚本右键
2.集成测试
简单理解就是在单元测试基础上，针对已经完成单元测试的模块，把它们组装为更高一级的模块或子系统，针对这些子系统进行集成。它的测试对象是已经经过单元测试的各个模块之间的接口。
（1）集成测试的主要方案
1）Big Bang 一次性集成（大爆炸），主要是把大部分的开发模块都耦合起来，形成一个完整的软件系统或系统的主要组成部分，并把他们拿来做集成测试。所有的东西都组装好，然后来做测试。
2）自顶向下 这是一个递增的组装软件结构的方法，一般来说从主程序开始，沿着控制层逐层向下的集成，通过这种方式逐层测试，覆盖到所有的模块。
3）自顶向上 也是最常用的集成方法（其他集成方法或多或少会吸收这种集成方式）。从程序模块的最底层的模块开始，逐层向上组装并测试。好处就是针对已经组装过的测试，不需要再对上一层编写装模块。能够比较好的锁定软件故障的位置。
4）核心系统集成 就是先把核心的软件部分挑选出来，并对这些部件进行集成测试，在测试通过的基础上，再逐步扩展到外围的部件，直到最后形成稳定的软件产品
5）高频集成 同步于软件开发过程，每隔一段时间开发团队就要对现有的代码进行一次集成测试（持续集成）
敏捷研发常用集成为核心系统集成和高频集成的结合。2和3在瀑布式软件研发模式中常用
（2）集成测试和单元测试的主要区别
| 单元测试 | 集成测试 | |
|---|---|---|
| 测试对象不同 | 软件的基本单元（最小的单元） | 以模块和子系统为单元（主要测试模块和模块之间接口的关系） |
| 测试的依据不同 | 软件的详细设计（测试用例的主要依据是详细设计文档） | 软件的概要设计（测试用例的主要依据是概要） |
| 测试的方法不同 | 只关心单元的内部 | 关注接口之间的集成 |
3.系统测试
集成测试、单元测试，很多地方会采用模拟的方式来做，而系统测试更多的使用真实的运行环境。
系统测试一般要做功能测试、性能测试、稳定性测试等。
（1）系统测试的关注点
关注系统本身的使用
关注被测系统与其它相关系统间的连通
关注系统在不同使用压力下的表现（大并发量cpu内存达到极限的情况下）
关注系统在真实使用环境下的表现
（2）系统测试和集成测试的区别
| 集成测试 | 系统测试 | |
|---|---|---|
| 测试对象 | 通过了单元测试的各个模块所集成起来的构件（组件） | 除了软件之外，还包括计算机硬件相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统 |
| 测试时间 | 介于单元测试和系统测试之间 | 集成测试之后 |
| 测试内容 | 各个单元模块之间的接口 | 整个系统的功能和性能 |
| 测试角度 | 偏于技术角度的验证 | 偏于业务角度的验证 |
4.验收测试
（1）细分
用户验收测试：开发方在移交产品之前进行的测试
运行验收测试：从运维的层面看系统是不是可以正常运行和维护（备份、容灾、灾难恢复）
合同和规范验验收测试
alpha测试：开发者提供的场景和环境中运行，一般是由用户来执行的（alpha版本）
beta测试：完全的脱离了开发者的环境，在用户提供的场景或者环境下测试（beta版本） release版本 正式版本
敏捷研发中还有一种测试叫做ATDD验收测试驱动开发(TDD测试驱动开发的延伸、BDD行为驱动开发）。就是在写开发代码之前，首先定义好用户故事的验收条件，然后开发功能代码，保证功能代码满足验收测试的条件