04
聊聊测试
从下面的章节，开始重点介绍测试内容。
4.1 什么是测试
定义：为了揭露对象的潜在问题的行为集合或采用各种方式尽可能早和多的暴露被测对象问题的行为活动集
软件领域，对象一般包括：可以是函数、类、模块（可单独运行的实体）、局部子系统、后端全系统、APP、SDK等。
一般有两个理解：
VE（Verification）：验证
- 正不正确，偏客观
- 比如是不是符合需求
- 一般指各类功能性测试
VA（Validation）：确认
- 符不符合预期，偏主观
- 比如是不是用户想要的
- 一般指各类用户体验评估
4.2 质量与测试的关系
- Quality≠Test
- 测试只是用来反馈质量，并不能直接提升质量
- 测试反馈当前质量情况，间接推动质量改进
- 测试是质量保证工作中的重要一环
- 质量不是测出来的，质量保证工作存在于每个环节，每个成员都要为质量负责
- 如何更早的发现问题核心是调节分布，质量成本的内在驱动
所有这些关系，在理解完质量的前提下，看完测试章节，应该就能够建立起关系。
4.3 影响测试效果的关键因素
从测试的定义上看测试过程：
1、让对象在设定对应的条件下运行起来
2、为对象设定对应的指令集或行为集
3、对对象发送对应的指令集并收集对象表现的返回或行为数据
4、依托返回或数据，观测对象在对应环境和行为集的表现，发现问题
5、出现问题，进行问题的定位，找到问题根因
6、最后再评估还有哪些条件、行为等缺失，来弥补手段
把1和2叫做测试输入，3叫做测试执行，4叫做测试分析，5叫做测试定位，6叫做测试评估，因此就把测试拆分成了五个阶段：测试输入、测试执行、测试分析、测试定位和测试评估。
4.4 测试输入
定义：对对象运行时的仿真和指令集合构造，最大程度的覆盖和仿真对象实际服务状态；通常的理解是测试方案、测试用例集合包括功能、UI等、环境、流量和接口等。
物理意义：决定了召回问题的上限。
具体的测试行为包括：
如果对象是函数：函数的入参+组合，函数依赖的组合。
如果对象是模块：功能逻辑的测试用例、UI用例、测试方案、配置真实性+异常组合、流量真实性和异常组合、环境的仿真性（硬件、软件、连接配置、词表、配置等维度）。
如果对象是子系统/APP：所有子系统的配置真实性、流程真实性、环境的仿真性（硬件、软件、连接配置、词表、配置等维度）。
如果对象是客户端APP：用例反映的行为真实性与线上的差异、APP的配置真实性等。
要做好测试输入，首先要对对象进行客观的刻画，其次是要在刻画的前提下构建起对系统仿真度足够高的测试系统，最后针对系统的输入进行指令集的构建，传统上这三步中最后一步是人为主导的测试过程关注最多的，但是对测试召回的影响还存在刻画和仿真的研究，这两点人在其中能够发挥的作用是有限的，因此需要用技术来解决，如软件知识图谱的构建、环境仿真性提升等。
4.5 测试执行
定义：对被测对象运行对应的指令集并收集对象的行为表现数据过程。
物理意义：决定了召回的效率，即需要消耗多少资源和时间去召回问题。
具体的测试行为包括：发压、采集数据和存储、执行用例等。
当用例和环境设计好，枯燥的执行完全依靠人去进行，大家天然会想到这种方法是可不取的，因此一般都会引入技术，进行自动化执行，这也是当前测试技术领域研究最多的方面，即如何用技术让测试自动化起来。
4.6 测试分析
定义：通过各种维度的分析，观测对象的表现，以发现潜在的问题。
物理意义：在对应测试输入的前提下，决定了达到召回问题上限的水平。
具体的行为包括：
层级一：是否正常：主要是分析对象是否还健康的存活，这是对象发挥作用的先决条件；常见的是：是否退出、是否夯死、是否拒绝等
层级二：有没有：主要是分析对象的输出属性是否符合预期的存在；常见的是：输出必须有时间、广告或有某个元素等
层级三：对不对：主要是分析对象的输出属性是否符合预期的正确；常见的是：输出1+1必须是2等
层级四：好不好：主要是分析对象的输出属性是否有体验上的偏差；常见的是：性能变差、资源泄露、策略效果变差、符合用户预期等
针对不同对象，可能要分析的行为也不一样，因此在实际过程中需要综合考虑。
四个层级，分析起来的难度依次增大，也更加抽象，分析能力也是测试AI化最难突破的地方。
从定义上可以看到，测试分析是观测系统的表现，来判断系统的问题，以人为中心一般只能看到系统肉眼可见的表现，但是在问题已经出现但是还没有显性出来或人忽略的情况下，这种问题就经常会被忽略，因此需要用技术，通过抓取系统的各类表现数据，进行数据分析，最终得出是否有问题的判断。
4.7 测试定位
定义：当测试分析发现对象有问题的时候，根据变更行为和环境等因素，定位出对象出问题的原因，方便快速修复
物理意义：决定了修复效率，即出现了问题后准确找到问题根因所在。
具体的测试行为包括：问题根因定位、构建失败识别与自愈等。
定位是项非常高投入的工作，该工作做好了会极大的提升工作效率，因此也是技术一直想去突破的方向。
4.8 测试评估
定义：根据潜在的风险分析、揭错活动的行为覆盖集合，通过模型，指出可能潜在的风险；
物理意义：以第三方视角进行问题的查漏补缺。
具体的行为包括：
1、基于变更、系统topo等刻画，判断存在的风险大小
2、获取测试输入、分析的行为活动数据
3、利用模型，预估潜在的未充分揭错的风险，配以可视化的报告进行展现，指导测试者增加召回活动
测试评估是在做最后一步的风险决策和召回。
但是测试评估往往会被测试工作者忽略，主要是因为随着自动化水平的不断提升，形成了看报告是否pass的惯性，而往往会忽视其实自动化执行更多的是之前经验的积累（在没有智能测试生成的情况下）很难完全揭错新的变化或者随着系统的开发积累的变化带来的问题，因此测试评估要逐渐走入测试工作者的视野，但是评估工作需要充分的数据来进行分析和判断，因此测试评估更多要依赖技术+模型进行，最后依托人不断挖掘特征进行持续的准确决策。
4.9 从测试召回看测试投入
1、研究被测对象，即哪些指令集和运行环境会影响被测对象的行为，从而做好测试输入，如之前所说，测试输入决定了测试活动召回问题的上限，因此这是召回的起点，比如流量的完备性仿真性，topo的仿真性等；
2、研究被测对象，即从哪些潜在变化会影响被测对象的行为，进而给测试评估输入，只有充分理解风险引入，才能更好的评估风险，如代码变化对被测对象不同程度的影响；
3、研究被测对象，即被测对象哪些维度可以反映出其异常行为，这是测试分析的起点，也是尽可能达到召回上限问题数量的核心环节，如内存泄露的曲线拟合、性能波动等。
因此，围绕对象进行研究非常关键，其次才是用各种生成、分析、评估工具去想办法揭错。
所以从这个角度的去理解传统自动化，即执行更多偏向的是测试执行和测试定位，是不会提升召回能力的，测试召回的水平还是被撰写的用例、流量的仿真等决定了，这块往往会被自动化三个词而忽略。自动化就等于自动化执行，很多时候自动化执行起来了，大家关注的重心就是覆盖率、成功率、召回能力等，但其实应该包括测试生成、测试分析和评估的持续投入，然后用自动化技术将所有这些能力例行化的跑起来（历史自动化都是人写好了，但是需要持续的进行技术投入得到提升，不然召回能力就一直会停留在某个过去的时间，随着时间的推移就会导致自动化成为鸡肋）。为什么仍然进行自动化测试，从质量成本角度可能更好的理解，后面会有更加详细的介绍。
4.10 客观看待测试
测试不可能召回所有问题，主要原因如下：
1、对象因所处的时间、环境不一，造成测试时与对象实际服务时环境存在不可避免的差异；
2、测试的投入是有限制的，不能无时间、不考虑资源的无限投入去召回所有问题；
3、人受限于经验、精力盲区，偶然犯错误不可避免。
但是对于QAer不能放弃对问题的尽量多召回。
从测试召回的问题类型上看其实测试召回分为显性和隐性的，其中显性的叫做新功能测试，这个是测试的热点，也是一直以来业务赋予QAer最基本的职能，保障新功能的正确性和交付，但是其实QAer也要看到随着系统尤其是微服务架构的扩散，系统的复杂性逐渐提升，新功能带来对老功能和周边业务的影响不可避免，这块隐性的测试逐渐变得至关重要，但是因为精力、能力和关注的焦点等很容易被忽略，而且将人力投入在回归的浩瀚集合中，显然会是ROI比较低的手段，因此技术可能是解决回归测试的关键所在。
05
关于测试分类
5.1 从召回问题类型的角度分类
从召回问题的具体类型的角度，测试可以分为性能测试、功能测试、安全测试、接口测试、稳定性测试、UI测试、兼容性测试等，这样分的目标就是针对不同问题的表现，测试的方法是不一样的，可以更好的去理解对不同问题的召回手段重点。
5.2 从测试对象层级的角度分类
从召回问题级别的角度，测试可以分为白盒测试、单元测试、模块测试、系统级测试等，这个划分的标准是对测试对象的层级进行划分，比如白盒的对象可能是函数或类，模块测试可能是一个服务，这种划分方式，有助于指导合理的问题在合理的模块进行召回。
5.3 从技术的角度分类
从技术手段的角度，测试可以分为精准测试、自动化测试、压力测试、探索性测试、fuzzing测试、遍历测试、线上测试、手工测试，这种划分更多的看技术驱动，体现的是技术在测试作用，而不侧重分发现哪些类的问题。
5.4 从召回问题职责的角度分类
从召回问题职责进行划分，可以分为新功能测试和回归测试两大类。
通常新功能测试和回归测试这种划分在业界会说的比较少，因此下面重点介绍下这两种类型的划分的定义和好处。
5.5 新功能测试
定义：验证代码的实现是否符合业务需求。
建议：RD尽量先保证实现的正确性和合理性，所以理论上新功能测试的验证研发是主角，QA提供测试服务保障。
QA可研究的领域：测试服务化（环境、单测）、用例自动生成、白盒扫描、用例设计和评估等。
5.6 回归测试
定义：验证升级的代码对本服务或周边业务带来的影响
建议：回归测试建议是QA的主责，让RD花更多精力在新功能和价值创造上。
新功能测试和回归测试从测试方法论上，都符合测试输入、分析和评估的拆解，但是职责上有所侧重，正因为如此，处理方式应该有所不同：
1、新功能作为基础的保障，应该有RD进行，RD有职责验证自己的功能是否符合预期；
2、回归测试应该是QA的主责，以便RD更加专注新特性的研发。
QA可研究的领域：手工集成回归；接口自动化回归；业务影响的回归；联调等。
新功能测试和回归测试，其实可以很清晰的区分不同角色在召回问题这块的主要重点，方便角色有自身的定位，各司其职做好分工。
06
聊聊召回成本
定义：对质量造成的损失进行控制或召回过程需要消耗的总成本。
基本包括：单位时间成本*占用时长
为什么要提召回成本：
1、无止境的投入去控制质量（不代表不去追求更多的召回问题），会造成业务迭代效率和资源的浪费，进而可能产生的损失比问题造成的损失要小。
2、不同范围、阶段和角色对质量的控制和召回，所消耗的成本差异会很大，要追求ROI较高的召回，因此需要研究如何调节质量成本。
6.1 成本计算
单问题成本：问题召回成本+定位成本+修复成本 = 召回时间*单位召回资源成本 + 定位时间*单位定位资源成本 + 修复时间*单位修复成本
所有问题召回成本：就是所有单问题成本的总和
可以看到：同一个问题，在越小范围的召回比大范围的召回从定位时间、修复时间对应的单位人力成本（均是同一个人）是一样的，但是修复时间、定位时间会大大缩短，因此也可以降低召回成本，其实这就是质量前置的基本由来。
为了计算出召回成本，QAer对不同召回级别的召回成本的大体进行了分类划分：
偏白盒级的召回：此类的召回成本基本就等于人力成本，而修复和定位时间基本可以忽略。
偏模块级的召回：此类的召回成本基本就等于人力+自动化成本，而修复和定位时间适中。
偏系统级的召回：此类的召回成本基本就等于人力+自动化成本，而修复和定位时间比较高。
可以看出不同级别的召回，召回成本的差异非常大，因此需要将问题级别在映射到合理的召回级别上。
6.2 降成本方法——降工作量
要降低召回成本，首先要做的就是尽量减少无效的揭错行为集或重复的揭错行为集，因为存在两个真实的前提：
1、不是所有变更都有质量问题；
2、不是所有的行为都能揭错。
这就要求QAer需要“看”准了再测，也就是后续讲的基于风险的测试由来，所以QAer就提出智能构建：用于智能裁剪自动化任务；质量度模型：用于判断是否需要人工介入等。
6.3 降成本方法——调分布
其次同一个问题的发现希望投入的成本更低，包括定位、修复和发现，因此希望可以调节问题的合理分布，如尽可能的在代码层级召回、再在单模块、再是集成召回；其次尽量用机器去召回（一般认为人的成本比机器成本高），所以调分布这里面有几个理解：
调质量分布理解一，调手段：尽量用技术去调节召回的分布，让召回的技术成分提升；
调质量分布理解二，调阶段：合理的问题在合适的”阶段"召回，如新功能就应该在提测前尽量召回，复杂的跨系统问题尽量在集成测试阶段召回；
调质量分布理解三，调级别：问题在合理的级别召回，如低级的逻辑问题尽量在代码级别召回，功能性问题在模块级。
再回过头来说下质量前置：应该想办法让在对应级别的问题在该级别发现，而非一定是系统集成的问题要在开发环节召回，也并不是简单的将测试任务放到开发阶段、提交阶段。
无论是理解一、二、三，要实现它，离不开一个关键词就是技术：
1、理解一字面意思就是技术，用技术去调分布；
2、理解二想要通过阶段进行自动调整的前提就是要自动化，因为自动化可以随时随地进行；
3、理解三要用更加偏白盒级的方法召回也离不开技术。
6.4 技术是调问题分布的重要载体
PS：这里面说的技术，不只是自动化执行
1、自动化执行可以将用例所蕴含的召回经验积累和传递给其余角色，形成角色召回的穿插。
2、自动化执行可以将召回经验随时随地执行，因此可以将任务穿插在各个阶段、各个角色。
3、用质量度模型将召回经验训练成模型，进行风险预测做综合判断，进而进行拦截。
4、具备代码级、模块级和系统级的召回，天然就要求有更多的技术进行召回，尤其是代码层面的。
总结一下，测试章节的内容主要包括：
1、介绍了测试的概念，从测试概念出发，质量与测试的异同，以更好的开展测试工作；
2、对测试过程进行剖析，理解影响测试召回的关键环节和因素，以及技术在各个环节的关键作用；
3、对测试的分类，尤其是新和回归测试的分类，更好的做好角色区分；
4、从召回成本的角度去考虑测试工作的方式和技术召回的必要性。
综合对测试的介绍，提升技术在测试召回和测试效率的成分至关重要，也是做好测试的必然选择，下面章节主要和大家聊聊测试技术相关的理解。
07
聊聊测试技术
从下面的章节，就开始聊测试技术，也是前面推导出来的，传统上大家聊到测试技术，一般第一反应就是自动化，甚至有时候自动化就是测试技术好坏的代名词，但是通过上面关于质量、测试的本质进行剖析和分解：
1、发现自动化并不是那么回事，甚至传统自动化"本质"上不能提升测试召回能力的，更多的是可以通过调节分布和替代人的执行，因此只是提升效率的手段
2、一个非常有趣的现象：正因为理解的测试技术等于自动化，所以有测试平台、甚至测试平台就是QAer技术的代表，造成了测试技术在召回能力提升的研究变少，进而QAer看家本领丢失了，因此需要逐渐纠正这点。
在下面的章节，会去介绍在测试技术不只是自动化（执行），可以看到，为了提升测试召回，测试技术将更大有可为。
7.1 测试技术主要职责是高召回，提效率
如前面介绍，测试技术不等于自动化，所以测试技术的主要职责不只是提效，而是要先提召回，其次将整个过程自动执行起来替代人执行和调分布进而提升效率。
传统的自动化在下面图中：核心在执行，即将依赖人的测试先验知识，通过技术用机器执行起来，主要表现在测试召回的执行层面。但测试技术其实在辅助人、调动人和模拟人方面还可以做更多，尤其是chatGPT的加持情况，将极大的提升这方面的可能性。
-
测试技术作用一：提升测试召回效果
这就要回到之前对测试本质的洞察上来，影响测试召回的核心要素包含测试输入、分析和评估三层，想要提升测试召回效果，测试技术就应该在这里做更多的投入，下面分别举几个例子，可以更加理解在对应领域加强对测试召回的投入：
**1、测试输入：**被测系统准确刻画的前提下：进行系统仿真能力建设或直接在线上进行测试活动，如流量仿真性涵盖引流、录制和回放；环境仿真性：包含词表、配置和上下游关系等。然后是测试行为集的构建：如接口的fuzzing能力、流量的筛选能力等。
这里特别提下客户端测试，可能更好理解测试输入中仿真能力和行为集的构建的关键作用：客户端的测试特点就是不确定性，主要原因有两个：
一、APP应用部署的容器是在用户的个人手机上，不是可控的、标准化的、随环境变化而变化的；
二、APP应用的行为是由用户控制的，随机性和不可预期性很强，而服务端是通过接口提供服务的，接口提前开发者设计好的，标准化的。
这些就会带来：
一、测试者的测试用例，与用户真实行为存在差距，测试者只能保障功能基本可用或正确；
二、测试者执行，没法穷举所有操作行为和部署的非标准带来的回归成本；
三、出了问题，没法做到容器级别的快速回滚，而只能打扰用户做APP替换；
因此客户端的测试需要考虑机型的抽取（环境）、用例集合的设计和选取（测试活动集）得更加深入，技术在这里的空间也会是很大的。
**2、测试分析：**前面提到测试分析是对象在输入情况下的表现行为，进而发现潜在的问题，这里面就涉及到对问题的表现形式进行分析；比如服务core的表现形式是什么；内存泄露的表现形式；脏数据的表现形式，可以基于此做，对象存不存在、特性有没有、逻辑对不对，功能好不好的判断和分析，尤其是好不好的判断，更加需求策略基于统计和概率做分析判断。没有分析就没有召回，比如单测没有任何校验点那单测就是形同虚设。
所有这些其实综合起来，可以概括为：通过拿到更多的系统表现数据+策略做出出问题的判断，这就是测试分析。只是有些判断是显性的，有些是隐形的，有些看单指标就行，有些需要聚类，所以这就要求QAer做更多的研究。
**3、测试评估：**以前容易忽视的环节，认为测试执行完成，如果报告没问题就万事大吉，但是殊不知，问题在底下暗流涌动，因此需要对变更风险进行评估、测试准出评估，所以这个领域就存在变更特征挖掘、变更影响面挖掘、测试行为数据采集（覆盖率）、质量度模型做最终决策等相关技术得到涌现，甚至通过测试评估去决策生成后续的召回行为。
上述技术投入均有利于提升测试召回且需要持续投入，因为对象在不断变化，这也是促使QAer不断革新和变化的驱动力。
上述视角是从影响测试召回的三个关键因素去做的技术投入和分析的，下面从另一个视角，去分析测试技术在测试召回的不可替代作用。
前提一：靠“人”召回是经验和问题驱动的测试，人有视野、职责、经验、精力的限制，会导致测试漏出；
前提二：人能“看”到的往往是系统表面的表现形式，真正系统内部可能存在问题，但又未发生的是观测不到的。
基于这两点，技术可以帮助弥补上诉不足，因此从这两点也可以研究出对应的召回技术，如主动召回技术：智能UT、AISA(智能化代码缺陷检测)、线上风险检测（线上系统的风险实时检测，如单点部署风险、超时配置不合理风险等）等。
从测试召回对依赖“人”程度的层面，一般会把技术对召回的影响程度进行划分：
1、完全不依赖于“QAer”的召回技术或在人的职责之外的：如智能UT、AISA、遍历、质量模型、全用例生成等；
2、辅助人提升测试召回：覆盖率评估、用例辅助生成等。
线上测试的必要性分析
线下测试两个天然的弊端：
1、对象运行环境的仿真性（如拓扑、数据和状态）没法做到100%，而在某些极端情况下的问题出现恰好依赖这种仿真能力；
2、很多干预操作带来的不确定性，是线下测试的case构造无法穷举和拟合的，比如线上流量的特殊性、PM的操作、扩缩容等，这些操作在线下的缺少，往往也会导致一定问题的出现。
基于此在有条件的情况下，可以对线上系统进行有针对性的测试，提升系统的召回能力，以前线上测试存在安全、影响等问题，相关的实践比较少，但随着微服务云原生技术的兴起，为线上测试提供的基础技术保障，因此线上测试变成了可能， 尤其是针对重大活动或高流量场景变得尤为重要。
-
测试技术作用二：实现不依赖“人”执行——即自动化提效
前面说自动化--即狭义上理解的自动化执行，不会提升召回，那为什么还有提自动化，这里面需要做如下拆解：
1、测试输入、测试分析和测试评估技术研究，是从召回的角度考虑，但是这些过程如果能够自动化串联起来就会提效，所以要研究自动化；
2、测试执行如果全靠人工也是非常耗人力的，因此站在测试召回成本角度，要去研究自动化。
聊聊自动化
自动化本质：将成员的集体智慧转化为整个团队的利益，并将测试行为用机器运转起来。
整个过程包含测试的整体：含测试输入、分析、执行、定位和评估，自动化是这些测试召回技术跑起来的技术载体，先有前者，汇聚起来就是自动化。
从上述定义的角度看，自动化有以下几个特性：
1、自动化，可以不依赖人的精力，可以随时随地执行，这给质量前置、质量分布提供的前提条件。
2、自动化，可以用机器代替人，可以提升人效，进而让人有更多精力进行创造性的工作。
3、自动化，也是非常关键的，就是可以将团队从成立起来的智慧得到传承和积累，进而避免经验只在某个人身上，从这个角度上看其实也可以召回更多问题，但是召回能力还是依赖人的不断积累和输入。**因此一定要做好自动化的沉淀，这是团队集体智慧的持续体现。**这个对系统的回归至关重要。
4、大量的回归是可以增强信心。
自动化从召回问题类型的角度进行拆分：
1、新功能自动化：可以在辅助写好用例、环境自动化等方面做好支持，进行自动化执行；
2、回归自动化：新对老功能和业务影响的自动化，平时讲的比较多的就是自动化回归。
新功能自动化
新功能需要做到完全自动化，目前看还是非常困难的，需要根据功能点，进行测试用例的自动生成和执行，但是做辅助还是有可能的。
1、辅助用例生成
2、辅助环境生成、测试数据生成等
这块重点可以先focus在如何提供测试服务，而不是全自动化或一次行多次回放的单次可获得性的研究。
回归测试的重要性
原因一业务发展新要求：当前的测试热点是新功能，新功能带来对历史债的冲击和对外界业务的影响，靠人很难评估出来，而且从漏出的角度看确实这种问题增多，自动化回归的持续积累，因此不会依赖人判
原因二组织行为新挑战：人员变动包括离职、转岗、内部轮岗、池化等，基于业务经验的测试能力会得到挑战，需要让经验持续的得到积累
原因三近年来在召回技术投入的有限：从测试输入，测试分析和评估，三个影响召回能力的核心因素看，目前评估做的比较多，但是输入和分析的技术投入相比之前有明显不足，如环境仿真、配置仿真、流量等
原因四业务发展要求需要增强：降本增效大背景下，自动化召回尤其是回归比例需要提升（热点型测试，回归其实需要巨大投入）
原因五自动化回归水平体现测试技术水平：真正牛的自动化，在有效性、召回和ROI方面都需要AI的加持，可以提升质量信心和降本增效。
受限于测试技术的自动执行：回归测试其实包含手工回归和自动化回归，自动化回归的重要性上面也提到过，那么手工回归是亦是如此，其实本质是一样的，无非是执行者是机器还是人的区别，本质上也需要要做好沉淀、刻画、评估等工作，沉淀至关重要。因此手工回归测试也更需要做技术赋能的探索，比如用例推荐、在线化支持、准出评估等。
技术是实现高ROI回归测试的必然路径
回归测试的目标是通过测试活动召回变更对本业务历史功能和周边业务功能带来的问题，如果回归测试通过手工执行，那么人首先要搭好环境、运行所有已有的本业务功能和周边业务相关的功能的用例，然后观测系统的表现，这样就会带来几个问题：
1、随着系统的不断迭代，系统自身的功能逻辑变得非常复杂，那么用例数量肯定会随着增加
2、随着业务的发展，系统间的交互也会变得频繁而复杂，测试人员需要评估出对相关业务的影响，并执行对应用例，而且这类场景会变得越来越多
3、通常回归测试的召回问题数量比新功能问题的数量要少很多，而且有时候不一定会影响老功能，这就导致回归测试如果全铺进去做回归，ROI会变得特别低
上述的原因综合起来体现出来的就是：
1、回归测试需要高ROI的方式进行，靠人执行行不通；
2、回归测试依赖人评估影响，存在人的差异性，很容易导致评漏，需要用技术做沉淀，打平人的差异性。
因此只有技术才能够解决回归测试，而且是有可能的，因为回归是测试人员已经将用例撰写出来，核心就是自动化执行的问题，如果评估影响、选出用例、自动化的执行，这些均和技术息息相关。
综上自动化的总结：经验通过自动化得到沉淀，使得经验可以通过技术无差异的得到传承，进而解除对人的依赖，让新品快速达到高水平，而人的召回能力一直在这个高水平的情况下不断迭代，进而促使召回能力一直在上升。
-
聊聊百度一直做的基于风险的测试技术 Risk-based Testing Technology
定义：根据潜在的风险分析，决策测试输入和分析的行为，以ROI较高的方式进行揭错。
从理论推导的角度，首先测试召回是要考虑召回成本的，其次就是基于人的经验测试，其实存在盲区，因此要用机器帮忙做风险判断。
从收益的角度，为什么要Risk-based Testing Technology：
1、防止资源浪费，基于风险做测试行为的决策，如跑与不跑，跑多大力度；
2、弥补召回欠缺，基于风险做质量风险评估，召回更多潜在问题等；
3、追求执行高效，基于风险控制测试时长、测试频率等，测试实时指导，供测试人员准确判断测试结束行为。
理论上，基于风险的决策如果风险模型得到有效和持续沉淀，其召回能力不会低于人的基本水平，甚至会在某些场景下更高，其次可以达到ROI较高的手段。
基于风险的测试测试与精准测试测试区别：
1、数据源：精准测试重在覆盖率，基于风险的推荐：覆盖率只是其中的一个数据源；
2、策略上：风险的推荐含有模型等策略，精准测试一般不包含；
3、对测试的影响：精准测试重在“选”和“看”；基于风险的测试技术，重在决策，如决策行为是否执行，执行的行为到什么程度，以及仿真需要到什么程度和决策是否补充测试；
4、能力上：精准测试还包含定位，基于风险的测试技术不含定位能力。
7.2****聊聊TestGPT
最后这个环节，基于最近非常火的chatGPT，而衍生下来的Code-GPT等很多领域，做了些比较浅显的思考，后续会不断加强这块的沉淀，完善这块理解。
意义
chatGPT，对人类社会确实带来了很多变化，其成功理解其实有两个核心原因：
1、自然语言的表达，进一步降低普通人入局的门槛，使得大众均能够参与；
2、生成式的输出，使得人工智能有生命力、有结论性的输出，而非静态和信息的展现，激发了兴趣，真正可以帮助人类。
从技术上两个关键因素：
1、大量结构化数据和反馈闭环形成了正循环；
2、大模型的技术突破。
给软件测试的启发：
1、大模型、大数据这么复杂的事情均可以有较好的效果，如果垂直到软件测试领域，做对应基于code的大数据模型训练和基于应用的模型微调，是有可能做成的，这块增强了一定信心。
2、软件测试，按照之前说的分新功能和回归测试，新功能测试，如果代码生成、推荐都能搞定，那么就基本说明机器已经能够理解代码了，那么按照一定的标准生成用例也不在话下；其次是回归测试，回归测试本质上就是基于系统刻画和团队智慧的持续积累去决策和揭错，这些其实在软件领域就是数据的沉淀+大模型，基本上就可以形成最佳的回归方案。
因此TestGPT，暂且叫TestGPT是有可能做出来的，而且也有一定信心。
可行性分析
TestGPT，如果这两个假设一直持续下去，可以执行下去：
1、有非常强大的自动化体系以及内部的数据结构化能力，如果增加人工的在线化收集数据会变得更加完整。
2、有近几年对基于风险的测试的投入和基建，其实已经有了决策的影子存在，需要把对应实现的技术，与文心一言、chatGPT存在的差异性总结出来，站在巨人的肩膀，做好微调模型和数据的结构化。
3、需要解放思想，QA不能靠“经验“的竞争力去生存，而是靠”创造力“去生存，这样才能人在驱动机器，不然迟早会被AI淘汰。
具体场景——百度智能测试第三阶段
关于如何做，这边更多的是从可以投入的方向做了几个思考：
1、代码是产生质量问题的最前线。代码级质量技术包含：含代码理解、代码插桩、单测用例代码生成、静态缺陷智能识别、动态缺陷智能识别、风险度预测、缺陷智能定位、基于代码理解下的自然语言用例生成，这些前提都是可以充分理解代码逻辑基础上进行，从19年开始就有一定投入，希望抓住机会，可以在这些领域去研究，应该会产生意想不到的效果，进而提升开发和代码质量。
2、为每个模块，系统，业务训练出TestGPT：
- TestGPT会有以下几个功能：感知：感知到对象相关的各类变化和可能带来的影响；决策：基于感知结合已有的召回能力决策揭错行为集，决策具体的测试行为结果可能是：已有的行为集进行合理分发或新生成行为集或两者兼顾；反应：已有行为集的执行或实时生成行为集与执行；评估：结合变化+揭错行为集进行准出风险评估、最后进行必要的测试补充。
- QAer未来的主要工作去调优服务和训练风险模型（TestGPT，QAer负责训练对应模块、服务和业务的大模型，进行测试生成、决策（AI）和执行（自动化）），弱化经验型的流水线、测试任务概念。工作形态上：感知输入变更和需求信息，TestGPT输出测试方案、用例集合、执行结果，最终评估准出，当然也有可能通过全自动化会不用人员执行的过程，但是测试方案、用例集合等还是会沉淀下来。以模型和数据为本：测试人员基于业务系统的大模型的日常工作，包括模型创建、训练、调优、使用等。
3、TestGPT作为某团队的知识沉淀和积累，不再有知识库、文档等，成为每个QAer的工作秘书。
总结一下，测试技术章节的内容主要包括：
1、测试技术不只有测试自动化，其实在召回方面，测试技术更应该有广阔的空间；
2、随着业务持续迭代，带来的软件复杂性和依赖的持续增加，回归测试尤其是自动化回归测试变得尤为重要；
3、LLM时代下，TestGPT的可行性分析，相信会有很大空间；
4、在降本增效与LLM的双重加持下，测试技术将大有可为。
08
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
开源项目：docs.qq.com/doc/DSlVlZExWQ0FRSE9H
