一、前言
软件开发过程中，每一个角色，涉及到相关的背景、知识点都是很多的，构建一个体系，对于知识的梳理、理解、融会贯通帮助颇多。
测试体系，涵盖了和测试相关的各个方面，包含了人、制度、流程、产物等。一个规范的测试体系，既可以保障整个项目流程的规范， 更可以提高工作效率，突出工作重点，提高产品质量。
二、背景
作为一个研发的时候，知道的测试相关实践，都比较零碎；如今作为一个专项技术测试，虽然负责的是EP相关，但是归属在质量部， 是非常有必要去梳理一下测试的架构体系，有助于用全局观的视角查漏补缺、完善知识体系，构建核心竞争力。
本文主要从软件测试的定义、价值出发，回溯软件测试的目标、过程、思想的变化，进一步从测试分类、测试模型、测试流程、测试技术 和测试工具几个维度进行展开。
三、软件测试
1. 定义
1. IEEE标准的定义
使用人工或自动的手段来运行或测定某个系统的过程：
- 检验是否满足规定的需求；
- 找出预期结果与实际结果之间的差别。
2. GBT-15532的定义
对软件进行检测和评估，已确定其是否满足所需结果的过程和方法
- 验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、软件需求规格说明、软件设计说明和软件产品说明等规定的 软件质量要求；
- 通过测试，发现软件缺陷；
- 为软件产品的质量测量和评价提供依据。
3. 软件测试定义的理解
2. 价值
四、软件测试理论体系
1. 目标
2. 过程
软件工程发展历程，为研究和克服软件交付危机而生 
3. 思想
4. 体系
软件测试的目标、过程、思想，逐步发展，在一定程度上形成了测试理论体系，主要从以下几个维度归纳总结：
- 测试分类
- 测试模型
- 测试流程
- 测试技术
- 测试工具
五、测试分类
1. 测试分平面图
软件测试领域首先令人头大的是繁多的测试名词概念和多种角度的分类，不但增加了理解难度，还提高了交流成本。
按照软件发现版本分类：
- α（alpha）内部测试版
- β（beta）外部测试版
- γ（gamma）正式候选版
按照需求实例化程度分类：
- ATDD，acceptance test-driven design，验收驱动设计
- BDD，behavior-driven design，行为驱动设计，用户故事场景化。
- BRE(SBE)，specification by example，实例化需求，在BDD基础上，更加明确需求的具体表现。
按照测试方法分类：
- 黑盒测试
- 白盒测试
- 灰盒测试
按照测试阶段分类：
- 单元测试
- 集成测试
- 系统测试
- 验收测试
按照测试形式分类：
- 静态测试
- 动态测试
按照软件质量特性分类：
- 功能测试
- 安全测试
- 性能测试
- 可靠性测试
- 压力测试
- 安装测试
- 用户界面测试
- 兼容性测试
其他：
- 冒烟测试
- 回归测试
- 随机测试
- 探索性测试
平面图分类分成三层：
- 测试方法：常见的黑白灰
- 测试层次：按照软件构建层次，单元、集成、系统、验收测试等
- 测试形式：按代码是静态还是动态二进制来区分为静态测试和动态测试 从不同的维度，可以知道：
- 垂直维度，白盒测试主要对应着单元测试和静态动态偏左的方向；灰盒测试处在以集成测试层次为中心的两边发散； 黑盒测试侧偏向于系统和验收测试，把整个系统看成一个黑夹子
- 水平角度：从测试层次里，可以看出功能性和非功能性指标的适应范围。再看下接口测试，接口测试单独拿出来看，不太好给其定位， 其实在这里可以很明确的看出来它是个测试工具，它适用于测试的各个层次，比如最小单元为服务接口时的测试， 服务和服务集成的入口接口测试，验收里的商户API接口测试。
2. 测试分类四象限
测试分类四象图，是敏捷软件测试里比较流行的一个分类。
-
垂直维度 体现了测试的层次：面向技术和面向业务，其实就是SUT的内部构造和SUT对外提供的功能，内部过程不正确， 功能一定不正确，功能正常，也无法等价SUT内部正常
-
水平维度 体现了测试的目的：测试驱动构建质量和测试评价产品质量，通过这两个目标，可以做软件质量目标质量分解
-
斜对角维度 Q1Q3的对角，指出了Q1更容易实现自动化测试，Q3用手工测试效果更好，比如和客户演示的时候； Q2Q4的对角，体现了测试分析的重要性，Q2面向业务驱动构建质量，这个时候面向需求做分析，可采用RBE/ATDD/BDD等 测试左移技术来实施，Q4面向SUT内部技术实现评价产品质量而做的相关分析，比如安全层面的一些技术分析
3. 测试分类三维图
上面的三维图，就比较好展示出测试的维度正交，做任何一个明确测试基本上都是由这三维图上的一个点来确认， 测试目标是什么，测试方法选哪个，测试对象是哪层。
1) 维度一：测试目标
2）维度二：测试方法
- 黑盒测试 指的是把被测的软件看作是一个黑盒，只关心软件的输入和输出 它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒技术设计测试用例的方法：等价类划分、边界值分析、错误推测、因果图和综合策略。
- 白盒测试 指的是把盒子盖子打开，去研究里面的源代码和程序结果它是按照程序内部的结构测试程序， 通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
白盒测试设计测试用例方法：控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、条件组合覆盖测试、路径覆盖测试）、 数据流测试、程序变异、程序插桩、域测试和符号求值等。 - 灰盒测试 介于白盒与黑盒之间，在关注输出正确的同时也考虑内部的实现逻辑。这种关注不象白盒那样详细、完整，只是通过一些 表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多， 如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
3) 维度三：测试分层
测试分层，在不同场景下，分层可能会稍微有些区别，可以参考测试金字塔的测试分层模型。
六、测试模型
1. 传统的VWXH模型
我们知道软件开发有模型，比如瀑布式开发模型和敏捷开发模型，那么测试过程的也有一定的抽象，如下：
- V 模型，非常明确地标注了测试过程中存在的不同类型的测试。
- W 模型，非常明确地标注了生产周期中开发与测试之间的对应关系。
- X 模型，这个模型指出整个测试过程是在探索中进行的。
- H 模型，软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行 。
V模型的流程是从上到下、从左到右，该过程呈线性发展趋势，需求在早期存在缺陷时，可能到最后环节才会发现， 并且测试工程师测试活动严重滞后于开发活动。
W模型是在V模型的基础上演变而来的，解决了V模型开发测试活动串行的问题，但仍然存在测试活动受开发活动的影响， 并不能做到真正的测试活动与开发活动分离，互不影响。
X模型也是旨在解决V模型的缺点，主要是进行了一定程度的迭代。 H模型与W模型一样，揭示了软件测试活动应该是一个独立的软件生产流程，贯穿整个软件生命周期，测试活动应该尽早准备、 尽早执行，当测试准备工作完成后，一旦到达测试就绪点，就可开展测试执行活动，不会受制于研发活动。
2. 测试金字塔
测试金字塔中每层中涉及的测试技术均有自己的优势和局限性，由于上层GUI测试的脆弱（不稳定性）、耗时（执行效率）问题， 以及问题表现位置（UI）和问题根因位置（代码）距离太远的问题，测试金字塔由关注测试数量转向关注测试质量， 推荐增加底层的测试投入。 实际执行中，开发人力不足、单测投入度不够、开发单测能力不足等，导致很多团队中不做单元测试或者被动执行流于形式， 有人提出了金字塔结构的反模式或者中间态模式。 
3. 测试模型左移&右移
测试左移，就是指在开发阶段之前定义测试，目标是防止缺陷和减少风险。 测试右移，就是直接在生产环境中监控，并且实时获取用户反馈，目标是确保在现实世界环境中的运行和性能。 
二者强调在持续测试过程中测试活动越过了传统测试的时间、角色、部门限制，将测试活动发展为连贯的持续性的质量保障活动。
4. TDD
七、测试流程
测试的基本流程： 
1. 测试目标
不同水准的测试目标：
- 最低目标：正常的输入与正常的处理过程，有一个正确的输出。
- 基本目标：对异常的输入能捕获错误，并进行相应提示或屏蔽。
- 较高目标：对隐式需求进行测试。
2. 测试设计
测试设计过程，采用5W2H的方式进行。 
测试用例是测试设计的核心，从手工撰写到后面自动化脚本，以便测试框架自动执行： 
3. 测试执行
4. 测试度量
八、测试技术
通常，软件测试的工作量很大（据统计，测试会占用到40%的开发时间；一些可靠性要求非常高的软件，测试时间甚至 占到开发时间的60%）。而测试中的许多操作是重复性的、非智力性的和非创造性的，并要求做准确细致的工作，自动化 测试能够节省人力、增强测试稳定性，提高测试效率。
软件测试自动化实现的原理和方法主要有：
- 直接对代码进行静态和动态分析
- 测试过程的捕获和回放
- 测试脚本技术
- 虚拟用户技术和测试管理技术
下面主要介绍流量录制回放、MBT以及精准测试。
1. 流量录制回放
流量录制回放，主要包含：录制、回放、对比。 
流量录制，主要包括录制流量调用顺序，生成用例库 
- 录制任务启动后，调度服务下发抽样规则，各服务根据call_graph_id计算哈希值抽样
- 将call_graph_id流过的所有服务的请求和回复，按照序列记录下来，包括上下文信息、时间、服务器和模块等
- 场景识别，将录制的流量串接成测试用例，支持实时导流和萃取之后的用例库回放
- 采集用例库，识别流量报文中的字段，为测试剧本设置标签
- 配置用例库，根据测试剧本的标签，在系统中萃取一系列用例库，方便开发快速根据业务配置进行调用
2. MBT的原理和实现
MBT(Model-based Testing)，通过建立测试场景模型（以下简称测试模型），生成测试用例代码的一种测试方法。 目前基于模型测试工具主要有Spec Explorer、PyModel和NModel。 SUT，System Under Test，被测系统模型，也称类比模型。 TRM，Test Ready Model，测试准备模型，也称分析模型。
测试建模的方法从宏观上来看，主要分为SUT建模和TRM建模。从微观上来看又派生了很多的模型。在实际工作中， 我们拿到被测系统后，会在脑海里进行瞬时画像建模，也就是构建了心智模型。而从心智模型过渡到测试用例，中间过程的 不同决定了不同的测试设： 
- 路径一（红色箭头）：从心智模型（Mental Model）直接得到测试用例（Ad-hoc Test Design，基于临时需求）；
- 路径二（黄色箭头）：从心智模型得到TRM模型，再由TRM模型生成测试用例（Traditional Exploratory传统测试设计）；
- 路径三（紫色箭头）：从心智模型到SUT模型，再由SUT模型生成测试用例（教科书式）；
- 路径四（蓝色箭头）：从心智模型到SUT模型，再由SUT模型到TRM模型，最终由TRM模型生成测试用例（MBT）。
MBT是一个循序渐进、逐步完善的过程，需要将被测系统的各个方面进行考虑： 
- 我们拿到被测需求后，首先会进行SUT抽象建模；
- 分析需求进行TRM建模；
- 初步模型验证；
- 基于模型可控地生成测试用例；
- 优化并生成可执行测试用例。 根据用户关注重点的差异，第一步可以对被测系统进行功能建模，也可以进行用户使用环境建模；第四步可以针对一些 模式（Patterns）或测试特异性（Test specifications）来生成用例，也可以根据测试覆盖率等 软件测试度量规则（Criteria）来生成测试用例。
3. 精准测试的原理
精准测试，旨在建立大型软件系统的测试数据与源代码之间高度的可视化追述机制，实现精准缺陷预防和定位，缩短测试周期，提高测试效率 让测试不再盲目，更具有针对性.
其核心原理，是将测试用例和产品代码建立了一个双向的mapping关系。 
通过正向追溯，开发人员可以看到测试人员执行用例的代码细节，以方便进行缺陷的修复，测试数据可以直接为开发调试 提供依据，快速定位并修复缺陷。 通过逆向追溯，测试人员通过修改的源代码快速确定测试用例的范围，极大减少回归测试的盲目性和工作量，快速修订测试用例， 达到测试覆盖率最大化。
关键特性：
- 软件测试示波器，实时的计算测试过程数据并展现。
- 用例和代码双向追溯，通过程序自动的记录和显示这个测试用例执行的代码。
- 智能筛选回归用例集，根据代码的变动范围来直接精确的定位需要回归的用例，这样使回归测试所需的时间更短，回归的范围更准确。
- 测试覆盖率精确分析，精准测试覆盖率形式多样，最高支持标准MC/DC（修订的条件/判定覆盖）的100%覆盖率要求。
- 软件缺陷快速定位，根据缺陷与用例的对应关系，快速找到执行用例对应的代码行。
九、测试工具
测试工具主要有：接口测试、压力测试、抓包工具等。
- 接口测试：一般主要是Curl命令，Postman，Postwomen，Swagger UI, Yapi等
- 压力测试：Jmeter，SoupUI等
- 抓包工具：Fiddler，Charles，Wireshark，Whitle等
一般大型公司内部，也会有自己搭建的内部平台。比如腾讯的星海、QTA等。
十、测试未来趋势
软件测试未来发展趋势被概括为”六化”：
1. 敏捷化：流程
敏捷和DevOps等流程的引入，特别是
- 测试驱动开发，TDD
- 质量内建，开发参与更多的测试，比如单元测试、API测试和Code Review
- 测试左移，加强需求评审、设计评审，推行ATDD/BDD
- 测试右移，开展在线测试（含性能、安全、易用性、可靠性）、日志/数据分析，反过来改进产品。
2. 高度自动化：技术
包括自动化框架的建立和优化，测试工具、测试平台开发等
3. 云化：基础设施
测试环境是一个不可忽略的问题，如何快递的构建一整套测试环境，使其易于维护、部署、管理，从而更好的支持自动化测试， 这就是测试的基础设施考虑的问题。
4. 服务化：中台与API
让软件测试成为一种服务，构建测试中台，让任何研发人员也可以自动获取测试的能力，比如测试环境自动获取，测试用例动态生成， 测试数据动态净化，测试文档动态生成，测试业务领域知识动态自动提取等。
5. 模型化：MBT
过去人们常说的自动化测试，只是半自动化，也就是测试执行的自动化。但是测试数据的准备、环境的维护也是一个比较耗时耗力的事情。 彻底的自动化应该是测试数据、测试脚本都是自动生成的，基于模型的测试，才能更精准、更有效。
6. 智能化：大数据与AI
AI能够服务其它行业，自然能够服务于测试，而且在上述自动化、云化、服务化、模型化的基础上，AI更能发挥作用， 包括测试数据的自动生成、自主操控软件、缺陷和日志的智能分析、优化测试分析与设计等。