UI界面层（UI）：（相对来说比较简单，人员多，）功能验证测试，兼容性与用户测试

业务逻辑层（Server）：（比上一层难，）客户端模拟测试，内外接口测试（相对而言），SDK接口测试

数据处理层（unit）：（比较重要，要求高，比较难，人员少，）单元测试（白盒测试，对代码进行测试），CodeReview(代码复审)。

SDK：全称：SoftWare DeftWare DeveLopment Kit,一般是指软件工程师特定的软件包建立的开发工具集合；

ROI：投入产生比

1.1 单元测试（模块测试）

它是对软件组成的单元进行测试。其目的是检验软件基本组成单元的正确性，测试的对象是软件设计的最小单位：模块。又称为模块测试。针对于代码测试

测试内容：

1）模块接口测试：针对于参数，边界值测试

2）局部数据结构测试：模块内部的数据参数进行测试；

3）路径测试：if else ，两条路都要走

4）错误处理测试：错误数据测试，代码内部和接口的错误处理

5）边界测试：考虑边界值

测试方法：白盒测试（针对于代码测试）
测试依据：代码和注释+详细设计文档
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试阶段：编码后或者编码前（TDD）
编码前测试（测试驱动开发）：研发人员根据测试人员的测试用例进行编写代码，代码的缺陷比较少

1.2 集成测试

集成测试也称联合测试（联调）、组装测试，将程序模块采用集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试方法：黑盒（测试功能）和白盒（测试代码）
测试内容：

1）模块之间的数据传输

2）模块之间功能冲突

3）模块组装功能正确性

4）全局数据结构

5）单模块对系统的影响

测试依据：单元测试的模块+概要设计文档
测试人员：白盒测试工程师或开发工程师

1.3 系统测试

花费时间最长，最核心的阶段，在集成测试之后

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。

测试方法：黑盒测试
测试人员：黑盒测试人员
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
测试对象：整个系统（软、硬件）
测试阶段：集成测试通过之后
测试依据：需求规格说明文档

1.3.1 回归测试

在系统测试的之中或之后进行回归测试；把之前测试的再测试一次

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

一定要有修改

在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

1.3.2 冒烟测试

核心是测试人员决定是否通过测试，测试人员是否进行测试的依据，在系统测试之前

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式的测试工作，冒烟测试的执行者是版本编译人员。

冒烟测试一般在开发人员
概念来自于硬件
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
先冒烟，再系统再回归，都归属于系统测试

1.4 验收测试

它是部署软件之前的最后一个测试操作。是技术测试的最后一个阶段。

测试的目的：确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买者展示该软件系统是否满足原始需求。
测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）
测试人员：主要是最终用户或者需求方
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试（功能、各类文档等）

2.按测试实施组织

2.1 α测试

α测试是由一个用户在开发环境下进行的测试，也可以市公司内部的用户在模拟式操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用化、可靠性、性能和支持）。

测试环境：公司内部，开发环境或预发布环境
预发布环境：上线前的环境，和真实的生产环境差不多（我们现在用的各种软件）
测试人员：本系统的测试人员和研发人员之外的人员
测试周期：比较短，比β短
测试阶段：α测试在β测试之前

2.2 β测试

β测试是一种验收测试，是由软件的最终用户们在一个或多个场所下进行。

测试环境：用户的真实环境测试，验收测试
测试人员：用户
测试周期：比较长，用户验收周期拖得很长（涉及到钱的问题）
测试阶段：在α之后

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

2.3 第三方测试

介于开发方和用户方间的组织的测试

外包，研发和测试分开，只把测试外包出去为第三方测试

如果把两中都外包出去，不加第三方测试

3.按是否运行划分

3.1 静态测试

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

不仅仅测试代码还要测试文档，文档正确性、准确性

可以人工，也可以用工具

检查项：代码风格和规格审查；程序设计和结构的审查；业务逻辑的审核‘走查、审查与技术复审手册。
静态质量：度量所依据的标准是ISO9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性、可靠性、可用性、有效性、可维护性、可移植性。

代码静态分析和文档测试都属于静态测试

3.2 动态测试

动态测试方法是指通过1运行被测试程序，检查运行结果与预期结果的差异，并进行运行效率、正确性和健壮性等性能，由三部分组成：构造测试用例、执行程序、分析程序的输出结果。

大多数软件测试工作都属于动态测试。

4.按是否手工划分

4.1 手工测试

由人去一个一个的输入用例，然后观察结果，和机器测试相对应

优点：自动化无法替代探索性测试，发散性思维的测试

缺点：执行效率慢，量大易错

4.2 自动化测试

自动化测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说就是把以人为驱动的测试行为转化为及其执行的一种过程。

一般有：

功能自动化测试（UI），一般所说的自动化测试就是功能自动化测试（功能测试自动化）
接口自动化测试
安全自动化测试

可以用于：冒烟测试，回归测试

优点：执行效率高，减少成本，手工测试的缺点

缺点：没有发散性思维，逆向思维，把程序写死了，手工测试的优点

步骤：

1）完成功能测试，版本基本稳定

2）根据项目特性，选择适合项目的自动化工具，并搭建环境

3）提取手工测试的测试用例转化为自动化测试的用例，转化率有的公司要求非常高

4）通过工具、代码实现自动化的构造输入，自动化检测输出结果是否符合预期

5）生成自动测试报告

6）持续改进，脚本优化

5.按是否查看代码划分（重点，必须掌握）

5.1 黑盒测试（Black -Box Testing）

黑盒测试就是功能测试，不看代码，只对软件的功能进行测试，只关心软件的输入数据和输出数据是否和自己想要的一样；

5.2 白盒测试（White-Box Testing）

白盒测试就是对代码进行测试，数据结构、路径覆盖、接口、错误处理、边界值等进行测试。

5.3 灰盒测试（Gray -Box Testing）

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

6.按测试地域划分

6.1 国际化测试

6.2 本地化测试

7.按测试对象划分（重点，必须掌握）

7.1 业务测试

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

业务测试关注需求和用户

7.2 界面测试

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

7.3 容错性测试

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

容错测试包括两个方面：

1）输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。

比较温柔的容错性测试通常构造一些不合理的输入来印有软件错误

（1）输入错误的数据类型

（2）输入定义域之外的数值；

粗暴一些的容错性测试俗称“大猩猩”测试，除了不能拳打脚踢之外，什么招式都可以使出来。

针对输入框输入异常数据，输入无效的等价类看程序员如何测试

2）灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

对于自动回复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。容错性好的软件能确保系统不发生无法意料的事故。

从容错性测试的概念可以看出，当软件出现故障时如何进行故障的转移与恢复有用的数据是十分重要的。

7.4 文档测试

开发文档：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。

用户文档：用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性，降低技术支持成本。

管理文档：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

在实际的测试中，最常见的是用户文件的测试。

文档测试的关注点：

（1）文档的术语

（2）文档的正确性

（3）文档的完整性

（4）文档的一致性

（5）文档的易用性

7.5 兼容性测试

测试有 WEB测试（浏览器、操作系统）、APP测试

兼容性主要是指软件之间能否很好的运作，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会导致系统的崩溃。

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

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

7.6 易用性测试

易用性（Useability）是交互的适应性、功能性和有效性的集中体现。和界面测试相同，没有统一的的标准，每个人使用习惯不一样，只要符合90%的习惯就好。

越简单越好，能一步完成就一步完成

7.7 安装测试

测试程序的安装、卸载；

典型的就是APP的安装、卸载

7.8安全测试

发展比较好；

安全测试是一个相对独立的领域，需要更多的专业知识。例如web的安全测试，

7.9性能测试