对于测试方法你知道多少（这里有最全的软件测试方法）

总的划分情况。

(1)从下到上三层测试，投入相同的时间，人力资源等，回报率（产出)越来越低
(2)从下到上，测试的效率越来越低
(3)从下到上，定位问题越来越难

单元测试（UT unit test）

是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块、类、方法。又称为模块测试
测试阶段：编码后或者编码前（TDD）
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试（输入输出，参数的数量、类型、类型的排列、输出是否符合接口设计文档）
局部数据结构测试、路径测试、错误处理测试、边界测试（for循环的条件）

集成测试( IT Integration Testing)

将多个单元模块组合在一起，然后验证他们之间的“桥梁”能否正常工作（接口测试）
测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

系统测试：(ST)

由测试人员充当用户，对软件功能主体进行的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统
测试执行阶段：包括回归测试和冒烟测试。
测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

回归测试

是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

冒烟测试

这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。也可以理解为该种测试耗时短，仅用一袋烟功夫足够了。
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。

验收测试：

核心是为了让用户来接收软件产品，然后进行“买单”。验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）。
测试人员：主要是最终用户或者需求方。
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试(功能…各类文档等)
验收测试包括α测试和β测试UAT测试

α测试(Alpha Testing)俗称内测

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成

β测试(Beta Testing)俗称外测试

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

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

UAT测试

由客户派出对业务非常精通的人员来使用软件从而对功能进行测试。

静态测试(Static testing)

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

动态测试(Dynamic testing)

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

手工测试(Manual testing)

手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。
优点：能够进行自动化无法替代探索性测试、发散思维结果的测试，可以灵活的改变测试的环境。
缺点：执行效率慢，量大易错。

自动化测试(Automation Testing)

简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。自动化测试主要有二种形，一种是自已写测试脚本，另外一种就是通过笫三方的工具对被测对象进行测试。自动化测试可分为功能测试自动化、性能测试自动化、安全测试自动化。通常所说的自动化是指功能测试自动化。优点是可以高效的执行一些人工无法执行的操作。

自动化实施步骤：

• 1.完成功能测试，版本基本稳定
• 2.根据项目特性，选择适合项目的自动化工具，并搭建环境
• 3.提取手工测试的测试用例转化为自动化测试的用例
• 4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期
• 5.生成自动测试报告
• 6.持续改进，脚本优化。

黑盒测试(Black-box Testing)

黑盒测试也称功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据与输出数据，即能否完成指定动能。

白盒测试(White-box Testing)

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒指的打开盒子，去研究里面的源代码和程序结果。这种测试的主体就是软件的底层代码，不会在意外在的界面是否OK，只要求底层功能实现,同时逻辑正确。

灰盒测试(Gray-Box Testing)

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

业务测试

测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程。业务测试关注需求和用户。

界面测试

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

容错性测试

容错性测试是检查软件在异常条件下自身是否具有防护性的措施或某种灾难性恢复的手段。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面：

• 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。比较温柔的容错性测试通常构造一些不合理的输入来引诱软件出错，例如：
• 灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系
  统和数据是否能尽快恢复。对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。容错性好的软件能确保系统不发生无法意料的事故。
  从容错性测试的概念可以看出，当软件出现故障时如何进行故障的转移与恢复有用的数据是十分重要的。

文档测试

国家有关计算机软件产品开发文件编制指南中共有14 种文件，可分为3 大类。

• 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
• 用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
• 管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
  在实际的测试中，最常见的是用户文件的测试，
• 文档的术语
• 文档的正确性
• 文档的完整性
• 文档的一致性
• 文档的易用性

兼容性测试

兼容性主要是指软件在不同的环境下（如不同浏览器，不同系统等）能否很好的运做，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃。通常包含：

• 平台测试
• 浏览器测试
• 软件本身能否向前或者向后兼容
• 测试软件能否与其它相关的软件兼容
• 数据兼容性测试

最常见的就是浏览器的兼容性测试，不同浏览器在css，js解析上的不同会导致页面的显示不同。常见的IE8的兼容
性。

易用性测试

易用性（Useability）是交互的适应性、功能性和有效性的集中体现。也就是用户使用的感觉，又叫用户体验测试。

安装测试

测试程序的安装、卸载
典型的是app的安装、卸载

安全测试

安全测试是一个相对独立的领域，需要更多的专业知识。例如web的安全测试，需要熟悉各种网络协议TCP\HTTP，防火墙，CDN，熟悉各种操作系统的漏洞，熟悉路由器等。从软件来说，熟悉各种攻击手段，例如SQL注入、Xss等。

功能测试

验证软件的主体功能是否可用。

性能测试

检查系统是否满足需求规格说明书中规定的性能。通常表现在以下几个方面：

• 对资源利用（如内存、处理机周期等）进行的精确度量
• 对执行间隔
• 日志事件（如中断，报错）
• 响应时间
• 吞吐量（TPS）
• 辅助存储区（例如缓冲区、工作区的大小等）
• 处理精度等进行的监测

内存泄漏测试

很多软件系统都存在内存泄露的问题，尤其是缺乏自动垃圾回收机制的“非托管”语言 编写的程序，例如C、CH、Delphi等。从用户使用的角度来看，内存泄露本身不会造成什 么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执 行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。可以 把这种软件的问题比喻成软件的“慢性病”。
造成内存泄露的原因最常见的有以下几种

• 分配完内存之后忘了回收。
• 程序写法有问题，造成没办法回收。
• 某些API函数的使用不正确，造成内存泄露。
• 没有及时释放资源。