按开发阶段划分
- UI界面层：1.功能验证测试2.兼容性：浏览器的兼容，系统的移植型3.用户测试
- 业务逻辑层：1.客户端模拟测试2.内外接口测试3.SDK接口测试
- 数据处理层：1.单元测试2.CodeReview
单元测试（模块测试）
简单来说就是代码测代码。
测试对象是软件设计的最小单位：模块。
测试阶段：编码后或编码前
（测试驱动开发：测试人员先编写测试用例，然后开发人员根据测试用例开发程序。）
测试人员：白盒测试或开发工程师
测试依据：代码和注释+详细文档设计
测试方法：白盒测试（白盒测试并不只是单元测试）
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
集成测试
集成主要目的是检查软件单位之间的接口是否正确。对系统的接口及集成后的功能进行正确性检测的测试工作.
测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试模块+概要设计wend
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
系统测试
对功能、性能以及软件所运行的软硬件环境进行测试，测试的大部分时间都在系统测试，包括回归测试和冒烟测试。（顺序：冒烟测试->回归测试->系统测试）
测试阶段：集成测试通过后
测试对象：整个系统
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等。
–)冒烟测试：
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，
目的是确认软件基本功能正常，可以进行后续的正式 测试工作
冒烟测试的执行者是版本编译人员
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
–) 回归测试：
指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
验收测试
测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）。
测试人员：主要是终用户或者需求方。
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试(功能…各类文档等)
按测试实施组织
在正式发布前，通常需要执行Alpha和Beta测试
α测试
α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
α测试不能由程序员或测试员完成，但是是在公司环境下测试
Beta测试
Beta测试是一种验收测试。Beta测试由软件的终用户们在一个或多个场所进行。
α测试与Beta测试的区别：
测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测 试。
Alpha测试的环境是受开发方控制的（在预发布环境下）,用户的数量相对比较少(用户基本不参与),时间比较集中。
beta测试的环境是不受开发方控制的(在用户环境下), 用户数量相对比较多,时间不集中。
alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。
第三方测试
介于开发方和用户方之间的组织的测试。
按是否运行划分
静态测试：静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。 对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错
动态测试：动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性 能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果.
按是否手工划分
手工测试：就是由人去一个一个的输入用例，然后观察结果
优点：自动化无法代替探索性测试、发散思维结果的测试
缺点：执行效率慢，量大易错
自动化测试：将手工测试需执行的一系列操作转换为机器测试。
自动化测试指软件测试的自动化，在预设状态下运行应用程序或者系统，预设条件包括正常和异常，最后评估运行 结果。将人为驱动的测试行为转化为机器执行的过程
自动化测试按照测试对象来分，还可以分为接口测试、UI测试（功能测试）等。接口测试的ROI（产出投入比）要比UI测试高
常见的自动化测试工具：QTP、selenium、Rational Robot 、jmeter、appium、soapui、Loadrunner等等
自动化测试的演变：测试工具----数据驱动----关键字驱动----测试框架----测试平台
自动化测试可以在整个测试过程中任何一个阶段实施，前提功能相对稳定 测试人员一般在系统测试时进行自动化测试 集成测试阶段多进行自动构建、部署，以及冒烟测试的自动化 单元测试针对代码级别进行测试，可进行静态代码检查，或者执行单元测试用例，典型的框架比如junit， jmock等，该部分多由开发人员实施
UI自动化特点：
用例维护量大 页面相关性强，必须后期介入 UI测试适合与界面变动较小的项目
接口自动化特点：
可在产品前期介入 用例维护量小 页面相关性小 适合接口变动较小，界面变动频繁的项目
自动化测试的优势:
降低大型系统的由于变更或者多期开发引起的大量的回归测试的人力投入，这可能是自动化测试最主要的任务，特 别是在程序修改比较频繁时，效果是非常明显的，自动化测试前期人力投入较多，但后期进入维护期后，可节省大 量人力，而手工测试后期需要增加大量人力用于回归测试
自动化实施步骤
实施自动化测试的前提条件：需求变动不频繁、项目周期足够长、自动化测试脚本可重复使用
1.完成功能测试，版本基本稳定
2.根据项目特性，选择适合项目的自动化工具，并搭建环境
3.提取手工测试的测试用例转化为自动化测试的用例
4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期
5.生成自动测试报告
6.持续改进，脚本优化。
按是否查看代码划分
黑盒测试：就是功能测试，只关心输入数据和输出数据间的关系。
白盒测试（结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。）：就是对代码及其结果进行的测试；接口测试也是白盒测试的一种
灰盒测试：就是既关心代码又关心输入与输出间关系的测试,基本是在集成测试中。
按测试地域划分
国际化测试：
本地测试：
按测试对象划分
(编写测试用例按以下方面着手)
作业：编写水杯的测试用例
业务测试:模拟真实用户的工作流程，满足用户需求定义的功能进行测试。
界面测试：测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是 否符合客户使用习惯
容错性测试：
概念：检查软件在异常条件下自身是否具有防护性的措施或某种灾难性恢复的手段。
容错性测试包括两个方面：
输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化 掉，而不会导致系统出错甚至崩溃。
灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系 统和数据是否能尽快恢复
对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；
对于人工干预的恢复系统，还需 估测平均修复时间，确定其是否在可接受的范围内。容错性好的软件能确保系统不发生无法意料的事故。
文档测试：
文档测试的关注点：
文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性
兼容性测试：
测试内容：平台测试；浏览器测试；软件本身能否向前或向后兼容；测试软件能否与其他相关软件兼容；数据兼容性测试
易用性测试：
是交互的适应性、功能性和有效性的集中体现
安装测试：
测试程序的安装、卸载
安全测试：
，需要熟悉各种网络协议 TCP\HTTP，防火墙，CDN，熟悉各种操作系统的漏洞，熟悉路由器等
性能测试：
检查系统是否满足需求规格说明书中规定的性能
通常表现在以下几个方面：
对资源利用（如内存、处理机周期等）进行的精确度量
对执行间隔
日志事件（如中断，报错）
响应时间
吞吐量（TPS）
辅助存储区（例如缓冲区、工作区的大小等）
处理精度等进行的监测
内存泄漏测试：
造成内存泄露的原因有很多，常见的有以下几种。
分配完内存之后忘了回收。
程序写法有问题，造成没办法回收。
某些API函数的使用不正确，造成内存泄露。
没有及时释放。
还可以使用一些专门的工具来 进行内存问题的检查，例如MemProof. AQTime、Purify、BundsChecker等
Code Review
1.执行review能够在代码评审期间发现bug，不必将bug的时间点推迟到测试阶段，越到后期，修改的代价越大；并且可以保证至少有两个人理解任何一份代码，保证进度；能够维护到代码的呈现为最优状态。
静态代码分析
代码静态分析（Program Static Analysis）是指在不运行代码的方式下，通过词法分析、语法分析、控制流、数据 流分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可靠性、可维护性等指标的一种代码分析 技术
代码静态分析的特点：（1）不实际执行程序（2）执行速度快、效率高（3）误报率较高
持续集成：CI
每次集成都通过自动化的编译、发布、自动化回归测 试来验证，从而尽快地发现集成错误
持续集成是为了持续交付
持续部署：CD
在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境中。比 如，我们完成单元测试后，可以把代码部署到测试环境中，交付给质量团队或者用户，以供评审