按测试阶段分类
单元测试
对软件中最小可充实单元进行检查和验证
单元测试的原则
尽可能保证各个测试用例是相互独立的
一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求
单元测试的益处
能尽早发现缺陷
有利于重构
简化集成
单元测试一定程度替代文档
用于设计，单元测试体验设计思路，设计本身可以用来验证设计
单元测试的限制
不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误
每一行代码，一般需要 3-5 行测试代码才能完成单元测试，所以存在投入和产出的一个平衡
单元测试框架
JUnit
NUnit
PHPUnit
CppUnit
集成测试
是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动
集成测试的主要实施方案
Big Bang
所有的东西都组装好，然后在进行测试
自顶向下
递增组装软件结构的方法，一般来说从主程序开始，沿控制层逐层向下来集成
自底向上
最常用的集成方法，从程序模块最底层的模块开始，逐层向上组装，并逐层的测试；好处是，针对我们已经集成的测试，不需要再针对上一层编写装模块
核心系统集成
先把核心的部分挑选出来，并对这些部分进行集成测试，在测试通过的基础上，在向外围拓展进行测试
高频集成
同步软件开发过程，每过一段时间，就对软件进行集成测试，常说的持续集成
系统测试
是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，已发现软件潜在的问题，保证系统正常运行
关注点
关注系统本身的使用
关注系统与其他相关系统间的连通
关注系统在不同使用压力下的表现
关注系统在真实使用环境下的表现
验收测试
也称交付测试，针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统
细分
用户验收测试 - 一般由开发方交付前自己做的测试
运行验收测试 - 从运维层面看系统是否能够正常运行，比如系统上线后备份、容灾
合同和规范验收测试
alpha 测试 - 开发者提供的环境进行的测试，一般由用户来执行
beta 测试 - 完全脱离开发环境，由用户提供的环境进行测试
按测试手段分类
黑盒测试、白盒测试
静态测试、动态测试
手工测试、自动化测试
黑盒测试
着眼于外部结构，不考虑内部逻辑，一般针对于软件外部的界面、可见的功能来测试，一般是从用户的视角通过不同的数据和事件来驱动系统，通过输出结果来进行判断
优点
容易实施，不需要关注内部的实现
更贴近用户的使用角度
缺点
测试覆盖率比较低，一般只能覆盖到代码量的不到 40%
针对黑盒的自动化测试，复用率较低，维护成本较高
黑盒测试主要测试什么
主要（更多）应用于 系统测试 阶段
是否有不正确或遗漏的功能
在接口上，输入是否能正确的接受，能否输出正确的结果
是否有数据结构错误或外部信
