一、按是否查看代码划分

白盒测试

又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。

白盒测试方法

1、代码检查法
2、静态结构分析法
3、静态质量度量法
4、逻辑覆盖法

其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。

5、基本路径测试法
6、域测试
7、符号测试
8、路径覆盖
9、程序变异。

白盒测试要求

1.保证一个模块中的所有独立路径至少被使用一次。
2.对所有逻辑值均需测试 true 和 false。
3.在上下边界及可操作范围内运行所有循环。
4.检查内部数据结构以确保其有效性。

黑盒测试

也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

黑盒测试作用

1、功能不正确或遗漏；
2、界面错误；
3、输入和输出错误；
4、数据库访问错误；
5、性能错误；
6、初始化和终止错误等。

灰盒测试

是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

二、按是否运行程序划分

静态测试

指测试不运行的部分，只是静态地检查程序代码、界面或文档可能存在的错误的过程。例如测试产品说明书，对此进行检查和审阅。

静态测试内容及过程

1、测试需求分析
2、测试概要设计
3、测试详细设计
4、测试执行与结果分析

静态测试技术

1、代码检查
2、程序结构静态分析
3、程序代码质量度量
4、评审与检查

动态测试

指通过运行软件来检验软件的动态行为和运行结果的正确性

动态测试内容及过程

1、功能确认与接口测试
2、覆盖率分析：主要代码的执行路径覆盖范围进行评估
3、性能分析：性能分析的测试是动态测试的重要内容
4、内存泄漏分析：内存泄漏有可能导致整个软件系统运行的崩溃

三、从测试是手动还是自动划分

手工测试

由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。

自动化测试

把以人为驱动的测试行为转化为机器执行的一种过程。

自动化测试的适用场景

1、回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；
2、此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；
3、采用自动化测试工具有利于测试报告文档的生成和版本的连贯性；
4、自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖。

四、按测试级别划分

单元测试

是最微小规模的测试，测试的是某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。

单元测试主要测试模块

1、组件内部模块接口检测
2、局部数据结构检测
3、路经检测
4、边界条件检测
5、出错处理检测

集成测试

指一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前，单元测试需要完成。

集成测试策略

1、非增量式测试
采用一步到位的方式结构测试。在对所有模块进行测试后，按照程序结构图将各模块连接起来，把连接后的模块当成一个整体进行测试。
2、增量式测试
增量式测试与非增量式测试不同，集成式逐步实现的，测试也是逐步完成的，因此，可认为是将组件测试与集成测试结合进行。增量集成测试可按照不同次序实施，由此产生了俩种不同的方法：自顶向下结合的方式和自底向上结合的方式

a、自顶向下的增量式测试：一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。
b、自底向上的增量式测试：从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。

系统测试

将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。

这部分测试主要包含功能测试、性能测试、安全测试、可靠性测试、恢复性测试与兼容性测试等。

为何系统测试需要独立的测试环境？

1、系统测试时，很可能发生失效并对客户的运行环境造成破坏，在系统发生系统崩溃和数据丢失的代价是严重与巨大的
2、测试者对运行环境的参数设置与配置的控制可能有限，或完全没有，容易产生失控
3、由于客户环境下的其他系统在测试时也同时在运行，测试条件可能会逐渐发生变更，使得系统测试执行不能重现，或很难重现，这将验证影响测试结果，造成测试结论的失真

系统测试目标

1、 确保系统测试的活动是按计划进行的；
2、 验证软件产品是否与系统需求用例不相符合或与之矛盾；
3、 建立完善的系统测试缺陷记录跟踪库；
4、 确保软件系统测试活动及其结果及时通知相关小组和个人。

系统测试原则

1、测试机构要独立；
2、要精心设计测试计划，包括负载测试、压力测试、用户界面测试、可用性测试、逆向测试、安装测试、验收测试；
3、要进行回归测试；
4、测试要遵从经济性原则。

验收测试

是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试形式

1、根据合同的验收测试，通过验收判断合同的条款是否得到满足
2、用户和用户群组织的验收测试活动，为整个系统得到确认的最后的测试阶段
3、验收测试通常由测试备份、灾难恢复、用户管理、维护项目和安全攻击的检查
4、用户现场的测试（β测试与α测试）

以用户为主的测试，验收组应该由项目组成员、用户代表组成
α测试：由用户在开发环境下执行的测试活动，开发者在测试人员身边，发现问题及时沟通解决。在不受控环境下执行测试。
β测试：开发者不在测试人员身边，发现问题由专人统一收集，再由研发人员进行修改。在不受控环境下执行测试。
UAT测试：用户接受度测试（一般商业用户验证系统可用性进行的测试）。

验收测试完成的任务

1、明确验收项目，规定验收测试通过的标准
2、决定验收测试组织结构、利用的资源
3、选定测试结果分析方法
4、指定验收测试计划并进行评审
5、设计验收测试所用的测试用例
6、审查验收测试准备工作
7、执行验收测试
8、分析测试结果
9、做出验收结论，确认通过验收或不通过验收

验收测试计划包含的内容

1、功能测试
2、出错/恢复测试
3、特殊情形测试
4、文档测试
5、强度测试
6、恢复性测试
7、对软件可维护性的检查与评价
8、某些用户操作性的测试
9、软件的用户友好性检验
10、软件的安全性测试

五、功能性测试细分

逻辑功能测试

常用方法：等价类划分法、边界值法、因果图法、决策表法、状态转换法、配对法（正交实验法）等

界面测试

简称UI测试，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。

易用性测试

从软件使用的合理与方便程度，对软件进行的测评，发现该软件不便于用户使用的某些缺陷

安装测试

包括软件安装与卸载是否正常的检验

安装：
1、典型安装和完全安装：检查安装步骤、安装过程中各个界面
2、自定义安装、检查安装步骤、安装过程中各个界面，安装到不同路径和选项（组件）
3、中断安装：关闭程序、关机、断网、安装磁空间不足时，能否实现断续性的安装
4、检查能否同时安装同一软件的多个版本
卸载：
1、从程序组里卸载：检查桌面、程序组、注册表中信息是否被删除
2、从控制面板中卸载：检查桌面、程序组、注册表中信息是否被删除
3、中断卸载过程：检查关闭程序、关机、断网等操作，是否显示卸载成功等信息
4、检查是否可卸载正在使用的程序

六、非功能性测试细分

性能测试

检验软件是否达到性能设计的要求，周到为达到性能要求所产生的原因，性能测试检验系统的性能运行表现。可分为健全测试、衰竭测试、负载测试、强迫测试、压力测试、恢复测试

安全测试

目的是验证系统内的保护机制能否在实际运行中保护系统且不受非法入侵和各种非法干扰。

恢复性测试

恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。

对自动恢复需要验证准确性的点

1、重新初始化
2、检查点
3、数据恢复
4、重新启动

对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内

兼容性测试

兼容性测试是检测各软件之间能否正确地交互及共享信息，其目标是保证软件按照用户期望的方式进行交互，使用其他软件检查软件操作的过程。

兼容性主要包含硬件系统的兼容性测试和软件系统的兼容性测试俩个部分。兼容性包括向前兼容与向后兼容、不同版本间的兼容、数据共享兼容。

七、按其他情形划分

回归测试

指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。

回归测试的方式

1、再测试全部用例
2、基于风险选择测试
3、基于操作剖面选择测试
4、再测试修改的部分

冒烟测试

在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

确认测试

在集成测试完成之后，分散开发的个模块将连接起来，从而构成完整的软件。其中，各模块之间接口存在的各种错误都已经消除，此时可以进行系统工作的最后部分确认测试。确认测试可检验所开发的软件能否按用户提出的要求进行，若能达到这一要求，则认为开发的软件是合格的。

确认测试准则

1、经过检验的软件功能、性能及其他要求均已满足需求规格说明书的规定，因而可被认为是合格的软件
2、经过检验发现与需求说明时由相当的偏离，得到各项缺陷的清单。对于这种情况，可能在交付期之前把发现的缺陷与问题完全修改与纠正过来。通常，确认需要经过开发者与用户协商，以共同确定确认测试的准则。

配置与审查

确认测试的重要内容之一是配置审查工作，也称作配置审计，其目的在于确保已开发软件（产品）的所有文件资料均已编写齐全，这里包括已发布的软件版本等并得到分类编目，足以支持运行以后的软件维护工作。
1、用户手册
2、操作手册
3、设计资料
4、已发布的软件资产（程序）版本

探索性测试

可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。

探索性测试提问范围

1、产品
a、该软件是做什么的？
b、能控制和观测到软件的哪些方面？
c、应该测试什么？
…
2、测试
a、应该采用不一样的测试策略吗？
b、怎样提高对产品好坏的理解程度
c、如果系统存在严重问题，应该如何发现它？
d、应该加载什么文档？按哪个按钮？输入什么值？
e、这测的测试是否有效？
f、从测试中学到什么东西可以应用到下一次测试？
g、刚才发生了什么问题？如何更好地检查它？
…
3、问题
a、这个缺陷问题违背了什么软件质量标准？
b、在这个产品中可以发现什么类型的软件错误？
c、现在看到的是一个问题吗？如果是，为什么？
d、这个问题的严重程度如何？为什么需要修正？
…

探索性测试类型

1、自由式探索式测试：指的是对一个应用程序的所有功能，以任意次序、使用任何如数进行随机探测，而不考虑哪些功能是否必须包括在内。
2、基于场景的探索式测试：使用场景作为指导的探索式测试人员经常会修改他感兴趣的输入或者是追寻一些并没有包括在脚本中的潜在副作用。不过，由于最终的目标是完成给出的场景，这些测试上的弯路、最终总是会回到脚本文件记载的用户主要执行路径。
3、基于策略的探索式测试：应用所有的已知技术(如边界值分析或组合测试)和未知的本能(如异常处理往往容易出现软件缺陷)，来指导测试人员进行测试。
4、基于反馈的探索式测试：在上一次我根据应用程序的最后状态选了每某一个输入之后、下一次我就会选中另外一个输入。或者是，在上一次遇到这个界面时我用A属性，这一次我就会用B属性。