单元测试(UT)、功能测试(FT)：
目的：1、尽量避免写的代码测试人员频繁的来找你其他地方又出问题了；2、提供的接口不可用；3、一个bug修复了引入了其他的bug或者其他用例变红了；
理解：在实现函数功能的时候编写对应的测试代码，尽量保证”输入-输出”的正确性，在测试用例比较多的时候对系统有强身健体的功效，适用的人群是：非大牛者
优点：
保证函数基本功能
修改代码后批量跑UT保证修改的代码对其他逻辑无影响
修复bugs后增加用例代码，更加强壮
有利于代码重构
可以支持nightly build,检验前天代码质量，检查代码覆盖率
测试代码是函数的说明书，轻文档
减少bugs数量和排查修复时间精力
缺点：
需要花时间去搭建一个测试代码平台和维护
前期需要很多的时间维护UT,FT代码（但后期系统越大作用越明显）
UT是单元测试，Unit Test
单元测试任务包括：
1 模块接口测试；
2 模块局部数据结构测试；
3 模块边界条件测试；
4 模块中所有独立执行通路测试；
5 模块的各条错误处理通路测试。；
IT是集成测试，Integration Test
集成测试阶段是以**黑盒法**为主，在自底向上集成的早期，白盒法测试占一定的比例，随着集成测试的不断深入，这种比例在测试过程中将越来越少，渐渐地，黑盒法测试占据主导地位。
ST是系统测试，System Test
从技术角度看，系统测试是整个测试阶段的最后一步，所有的开发和测试在这一点上集中表现为生成一个具有一定功能的软件系统。该阶段主要对系统的准确性及完整性等方面进行测试。主要进行：功能确认测试、运行测试、强度测试、恢复测试、安全性测试等。系统测试的测试人员由测试组成员（或质量保证人员）或测试组成员与用户共同测试。在整个系统开发完成，即将交付用户使用前进行。在这一阶段，完全采用黑盒法对整个系统进行测试。
UAT是验收测试，User Acceptance Test
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
软件开发中的完成测试环境所包括的环节包括：UT、IT、ST、UAT
UT = Unit Test 单元测试
IT = System Integration Test 集成测试
ST = System Test 系统测试
UAT = User Acceptance Test 用户接受测试(俗称:验收测试)
单元测试
单元测试是对软件组成单元进行测试,目的是检验软件基本组成单元的正确性,测试对象是软件设计的最小单位 - 模块,又称为模块测试
单元测试的实质是代码测代码
测试阶段: 编码后或者编码前(TDD,编码前属于测试驱动开发)
测试对象: 最小模块
测试人员: 白盒测试工程师或开发工程师(这一点很好的体现了代码测代码的实质)
测试依据: 代码和注释 + 详细的设计文档
测试方法: 白盒测试
测试内容: 模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
集成测试
集成测试也称联合测试(联调)、组装测试,将程序模块采用适当的继承策略组装起来,对系统的接口(接口属于白盒)以及组装好的功能(功能属于黑盒)进行正确性检查的测试工作
集成测试的主要目的是检查软件单位之间的接口是否正确
测试阶段: 一般在单元测试以后
测试对象: 模块间的接口(单元测试的接口是指一个模块的接口,这里是强调模块间)
测试人员: 白盒测试工程师或者开发工程师
测试依据: 单元测试的模块 + 概要设计文档
测试方法: 黑盒测试和白盒测试的组合
测试内容: 模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
系统测试
系统测试是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。
包括对功能、性能、以及软件所运行的软硬件环境进行测试
系统测试包括冒烟测试和回归测试
测试阶段: 集成测试通过之后
测试对象: 整个系统(软、硬件)
测试人员: 黑盒测试工程师
测试依据: 需求规格说明书
测试方法: 黑盒测试
测试内容: 功能、界面、可靠性、易用性、性能、兼容性、安全性等(来自于需求文档,非功能需求)
冒烟测试:
冒烟测试是一个准入标准, 是是否接受软件测试的依据
测试对象：每一个新编译的需要正式测试的软件版本
测试目的 : 确认软件基本功能正常,可以继续后续的正式测试工作
执行人员 : 测试人员
开发人员开发完毕后交给测试人员进行测试
测试人员进行冒烟测试,保证基本功能正常,不阻碍后续测试
回归测试:
回归测试的测试用例是从功能测试用例中提取的
回归测试是指修改了旧的代码以后,重新进行测试,确认修改没有引入新的错误,或导致其他代码产生错误,
自动回归测试将大幅度降低系统测试、维护升级等阶段的成本(自动化测试)
在整个软件测试系统中,占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试,随着系统的庞大,回归测试的成本也会越来越大,听过选择正确的回归测试策略来改善测试效率和有效性是非常有意义的
回归测试和冒烟测试都可以使用自动化测试
一般的顺序是: 冒烟测试 -> 系统测试 -> 回归测试
验收测试（UAT）
验收测试是部署软件之前最后一个测试操作,他是技术测试的最后一个阶段,也称为交付测试,验收测试的目的是保证软件准备就绪
测试阶段: 系统测试通过之后
测试对象: 整个系统(包括软硬件)
测试人员: 需求方
测试依据: 用户需求、验收标准
测试方法: 黑盒测试
测试内容: 功能、界面、可靠性、易用性、性能、兼容性、安全性等(同系统测试)
| 测试过程 区别 |
UT |
FT |
ST |
| 定义 |
是对软件基本组成单元（软件设计的最小单位）进行正确性检测，如函数或一个类的方法。 |
（通常所说的接口联调）是单元测试的逻辑扩展。在单元测试的基础上，将所有模块按照HLD要求组装成为子系统或系统，验证模块间的接口是否正确的。 |
将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。 |
| 测试依据 |
1、源程序本身，包括代码和注释 2、LLD |
1、单元测试的模块 2、HLD
|
SRS |
| 测试目的 |
与LLD是否符合 |
与HLD是否符合 |
与SRS是否符合 |
| 测试方法 |
属于白盒测试范畴 |
属于灰盒测试范畴 |
属于黑盒测试范畴 |
| 考察范围 |
主要测试单元内部的数据结构、逻辑控制、异常处理等 |
主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能 |
主要测试整个系统相对于需求的符合度 |
| 评估基准 |
逻辑覆盖率 方法： TDD（测试驱动开发） |
接口覆盖率 方法： 1.每个接口被覆盖的程度 2.每个接口的等价类、边界值被覆盖的程度 |
测试用例对需求规格的覆盖率 方法： 1. 等价类两两组合 2. 边界值分析 3. 业务流程法 4. 状态迁移法 5. 错误猜测法 6. 输出域覆盖 |
| 被测对象 |
一个或一组函数 |
子系统、模块间接口 |
完整的软件系统及系统交互的软硬件平台。 |
| 测试时机 |
编码之后，代码 已经通过编译之后 |
在单元测试之后
|
集成测试之后
|
| 测试人员 |
开发人员或 白盒测试工程师 |
函数间/模块内集成是开发人员；模块间集成是白盒测试员;子系统间集成是黑盒测试员； |
黑盒测试工程师
|
| 测试 通过标准 |
1、单元测试用例的执行率为100%，通过率为95% 2、语句的覆盖率达100% 3、分支的覆盖率达85%
|
1、各个单元模块结合到一起能够协同配合，正常运行 2、测试用例的执行率为100%，通过率为95%
|
1、系统功能、性能等满足需求规格说明书中的要求 2、测试用例的执行率为100%，通过率为95%
|
| 测试策略 |
控制流测试、数据流测试、排错测试、分域测试等
|
大爆炸、自顶向下测试、自底向上测试、三明治
|
功能测试、性能测试、随机测试等 |
一.分层测试策略
1.场景搭建难度大、测试代价大的ST，可以使用FT/UT补位；
2. ST用例已比较全面，
3.在团队文化层面鼓励FT/UT的开发，将UT编写列为开发人员的必备技能；
我们团队ST自动化比例较高，在这种背景下。考虑到在这三类测试中，基于系统和场景的ST的测试结果可信度最高。为确保测试收益，又兼顾效率，团队依然是将主要精力放在增加ST自动化的覆盖率上。同时结合测试前移，在CI里集成冒烟、CRT测试，加快反馈速度；
UT/FT、ST测试用例比例示意图
二.用例设计原则
ST：基于系统、业务场景；
UT/FT：基于功能、模块、函数；
三.职责分工
四.测试分层的实施流程
分层测试的实施流程
五.收益
测试周期缩短；
需求实现的快速反馈；
测试和开发人员的编程能力提升；
六.测试计划
验收测试，集成测试，系统测试，外侧
参考互联网数据