百度百科定义：客体的一组固有特性满足要求的程度。

在人们的意识中，不符合事物的预期表现都和质量相关，但要穷举又非常困难，主要原因质量是个非常抽象的词。但作为质量工作者，仍然需要提升对质量的理解，来指导质量工作者的工作，为此需要让对质量的理解从抽象变得可描述、具体。

下面基于对近些年来从事软件质量工作的总结，简要介绍对质量理解的内容。

软件质量是比较抽象的词语，在软件工程领域，一般质量的好坏都会用问题数，bug数去衡量，而bug数与测试召回有很大关系，所以很多时候，大家聊到质量，都会直接想到测试、想到QAer，因此认为质量=测试=QA，这很正常。接下来更多的是从“价值”驱动的视角，讲下关于软件质量的几个不同理解，可能对后续的工作有一定帮助：

保障软件服务可用，也就是提供的产品或服务，让用户/客户能够正常的用起来。用可用这种方式去描述质量，就会变得更加具体。这层理解就会驱使质量保障或者测试活动的重心是放在服务的稳定性、SLA和功能的正确性、策略是否符合初衷等方面，这是软件质量领域目前投入最多的，这个理解和投入没错，因为这给予质量保障者最基本的职能。再者推敲一下，站在提供服务的公司视角看质量可用，保障软件可用核心目标是降低服务不可用带来的损失，其实最终需要看质量问题给业务带来的损失，因此从业者行话是控损：即控制业务损失和不符合预期的功能带来的体验问题。此阶段QAer的工作价值在于保交付，控业务损失，这样看到的就不是简单的问题数，任何问题对业务损失的影响才是从业者要去追求和研究的。

从质量驱动更多价值的角度，质量在保障服务可用的前提下，其实可以做的更进一步，即好用：也就是提供的产品或服务，不仅满足了用户/客户的基本诉求，更多的是关注服务对他们的满足、体验情况如何，这个层面质量的重心从保障服务的稳定性和正确性方面会逐渐转移到用户/客户体验提升的角度。该角度看质量其实会给业务带来更多损失之外的实际价值，比如留存、时长、生态闭环提升等等，目标是稳业务，由控损到稳业务的转变。特别强调的是，软件质量层面做的留存和业务PM做的留存方式不一样，业务PM更多的是从功能完整性的角度设计用更多好用的功能吸引用户，质量层面是从用户体验的视角去抽象出潜在问题，驱动产品和技术改进。比如对客户端APP来说，梳理出来的对好用的理解：

此阶段QAer的价值在于保交付，稳业务发展。

爱用就是让用户/客户成为服务的代言人，主动推荐服务给周边。这个核心理解如何挖掘用户、挖掘潜在需求进而转化成业务追求的价值，这个目标逐渐与PM工作殊途同归，但是做的工作方式不一样，比如软件质量从业者可以发挥更多技术优势，在竞品数据抓取、用户行为画像和分析方面提供服务等。因此，在爱用这个层面质量关注的重点也就不一样，手段是保证可用和好用的前提下，如何挖掘出更多潜在的用户和需求，促使业务持续增长。此阶段QAer的价值在于保交付，促业务增长。

综上所述，提到了软件质量从可用、好用、爱用的三层理解，稍微做个总结：

从质量发展的角度，三者依次进行，所以目前一般聊的质量还是在可用层面，下面的文章也主要是从保障服务可用的角度去展开阐述的。

为什么要做软件质量模型主要是希望通过模型的拆解，能够看到影响软件质量因素有哪些，方便软件质量工作者更好的安排工作和找到质量做好的工作归因，最终形成正循环，基于保障可用的目标是控制业务损失的思考，构建出来的软件质量模型为：

假设有一套如上图的软件系统，有A、B、C、D、E、F六个子服务，关系图如上图描述要算出子服务E的各类变更带来损失期望E，公式如下：

质量模型即问题给业务带来的损失：（变更数*问题密度（概率）*（研发漏出率）*（测试漏出率）*问题处理水平）

问题密度和研发召回的综合结果可以称为研发质量，是一个比较虚的概念。

质量成本：为了控制某个变更带来业务损失，所消耗的资源成本，包括人力资源、IT资源等，具体形态上包括：开发者投入到质量活动的成本（为了质量考虑的设计、开发）、问题召回成本、定位和修复成本、为了提升鲁棒性额外增加的IT资源成本等。这里要特别提下召回成本：应该是包含所有为了保障该变更的质量活动，与定位、修复成本还有一定区别，因为这两项成本是已经确定了有质量问题的前提下进行的，无需考虑无效因素。

变更因素包含需求变更、线上词表变更、运维操作、业务操作、硬件/业务变化、依赖业务变化影响等，这些因素均会直接或间接对系统带来影响，进而可能带来业务损失的影响，质量工作者需要尽量考虑更全面的变化因素，有以下几个好处：

这里特别要提是：有些变更是对线上系统直接操作，所以线下仿真起来特别困难且不现实，因此对线上操作的必要审批、流程和checker需要加强。

问题密度从物理上反映的一个系统产生缺陷的水平，问题密度与很多因素相关如：架构设计、技术债务、开发能力、系统韧性、业务复杂性、依赖程度等，该指标真正反映了一个研发团队在质量的技术水平，因此从研发的角度，应该多重视该指标的建设与提升，质量内建是一件非常值得研究的事情，尤其是架构、技术债务潜移默化的影响，容易被人忽视。

研发召回反映了一支研发团队对生产代码的质量问题的召回水平，该指标可以反映出质量意识，业务因历史或紧急等情况不得不接受短期实现，因此就需要有比较好的质量意识进行自测，QA在此时可提供测试服务、测试用例和评估等辅助工具，辅助研发进行自测。需要说明的是，不是导向研发要召回所有问题，但基本的功能正确性和系统健壮需要保障，而回归、相互影响等消耗较大的工作可以交给专业QA进行，研发则更加专注架构和技术创新，两者应该各司其职，做好明确的分工，因此需要这么一个指标。

问题密度+研发召回：可以统称为研发质量，即研发可以通过降低问题密度+自测提升交付质量

前面提到研发召回有自身专注的召回问题类型，而QAer则是作为新功能的兜底和回归测试的主力。针对新功能更多的是查漏补缺；而随着业务和模块复杂性提升，对回归需要足够重视和加强，这是开发和QAer很容易忽视的地方。而在质量模型变更类型更加丰富的情况下，测试召回不能将视野只局限在线下进行，所以需要特别提三点：

为什么？首先系统会随着外部环境、代码积累和硬件老化而逐渐出现一些潜在的新问题，系统问题可能会爆发，很典型的性能瓶颈问题；其次线下测试的仿真性天然会存在很大差异，因此必要的线上测试和风险巡检是不可避免的。关于测试召回是QAer一直以来投入的大头，因此在后面的章节专门会对测试进行展开介绍。

故障的发生无论召回的大网有多严密都会出现。在故障不可避免发生的前提下，QAer要做的是尽可能降低故障对业务造成的损失。控制好故障对业务造成的损失反映的就是系统对故障的处理水平，造成损失有两个主要因素：

1、故障影响面：定义为单位时间对业务造成的损失量；尽量控制故障影响的范围，这里也包括流量、机房对其余业务的扩散。因此在传统意义上，有单沙盒、单机、单机房的checker和线上监控，这些手段都是希望尽早的感知到，控制好影响面。因此当系统不可避免会产生很多问题，或者线下召回体系不那么健全时，对故障影响面的控制，一般都会成为团队首选。但是这种情况不可取，“毕竟常在水边走，哪有不湿鞋”的道理，大家均是懂的，而且即使影响面控制到小范围，仍然是对业务造成了影响。

2、故障的恢复时长：顾名思义就是让故障快速止损，以降低业务损失，为了更好拆解对应的事情，一般会把故障的恢复时长，进行进一步拆解MTTR为MTTA、MTTI、MTTO等一系列指标，分别反映故障感知时间（发生到人开始跟进处理）、故障止损操作开始时间（即发生故障到开始决定要干什么止损操作的时间）、故障操作时间（即开始操作到故障最终恢复时间）

MTTA：故障感知时间，从发生到被人开始跟进处理的时间，基本的技术方向投入，其实checker和监控，这是QAer一直以来投入的技术方向，如何更全面、阈值更灵活的报警并且触达到该触达的人，一直是该方向研究的关键。

MTTI：故障止损决策时间，也即根据故障表象、系统关联关系、变更等情况，决策研发或OP要进行的止损行为，这块依赖策略，更依赖系统表现行为数据，更方便的做决策。

MTTO：故障开始操作到恢复的时间，这块反映的是操作人员的专业性和系统自恢复的能力，和架构很大关系，比如故障的启动时间、启动是否有依赖等等，任何1min可能都会造成巨大损失，架构上需要特别注意。

站在控制业务损失的角度，处理水平，需要逐渐进入QAer整体视野，并开始加强导向和技术投入，目前对该方向的研究和理解也在逐步加深，在此文中暂时不展开讲相关内容。

质量成本：定义为了让对象的有更好质量，在此过程中消耗的人力和资源成本。

从定义上成本包括：研发架构开发和维护、测试召回（QAer和机器）、线上问题报警、决策和运维、故障定位和问题修复成本，这些均需要考虑进去，站在QAer团队的视角，可能考虑更多的是测试召回成本、线上问题报警和决策的成本。

为什么要在此提出质量成本，主要有两个原因：

从上述过程可以看出，要做好质量控制，所有环节均可开展工作，那么如何选择最合理的方式开展质量工作，这就要考虑成本因素，因此如何调整质量的召回分布，进而去保障质量而控制投入，将会是在降本增效的大背景下，QAer一直需要研究的话题，即回归出一个质量成本和损失量的ROI控制公式。

总结一下，质量章节内容主要包括：

从下面的章节，开始重点介绍测试内容。

定义：为了揭露对象的潜在问题的行为集合或采用各种方式尽可能早和多的暴露被测对象问题的行为活动集

软件领域，对象一般包括：可以是函数、类、模块（可单独运行的实体）、局部子系统、后端全系统、APP、SDK等。

一般有两个理解：

VE（Verification）：验证

• 正不正确，偏客观

• 比如是不是符合需求

• 一般指各类功能性测试

VA（Validation）：确认

• 符不符合预期，偏主观

• 比如是不是用户想要的

• 一般指各类用户体验评估

所有这些关系，在理解完质量的前提下，看完测试章节，应该就能够建立起关系。

从测试的定义上看测试过程：

把1和2叫做测试输入，3叫做测试执行，4叫做测试分析，5叫做测试定位，6叫做测试评估，因此就把测试拆分成了五个阶段：测试输入、测试执行、测试分析、测试定位和测试评估。

定义：对对象运行时的仿真和指令集合构造，最大程度的覆盖和仿真对象实际服务状态；通常的理解是测试方案、测试用例集合包括功能、UI等、环境、流量和接口等。

物理意义：决定了召回问题的上限。

具体的测试行为包括：

如果对象是函数：函数的入参+组合，函数依赖的组合。

如果对象是模块：功能逻辑的测试用例、UI用例、测试方案、配置真实性+异常组合、流量真实性和异常组合、环境的仿真性（硬件、软件、连接配置、词表、配置等维度）。

如果对象是子系统/APP：所有子系统的配置真实性、流程真实性、环境的仿真性（硬件、软件、连接配置、词表、配置等维度）。

如果对象是客户端APP：用例反映的行为真实性与线上的差异、APP的配置真实性等。

要做好测试输入，首先要对对象进行客观的刻画，其次是要在刻画的前提下构建起对系统仿真度足够高的测试系统，最后针对系统的输入进行指令集的构建，传统上这三步中最后一步是人为主导的测试过程关注最多的，但是对测试召回的影响还存在刻画和仿真的研究，这两点人在其中能够发挥的作用是有限的，因此需要用技术来解决，如软件知识图谱的构建、环境仿真性提升等。

定义：对被测对象运行对应的指令集并收集对象的行为表现数据过程。

物理意义：决定了召回的效率，即需要消耗多少资源和时间去召回问题。

具体的测试行为包括：发压、采集数据和存储、执行用例等。

当用例和环境设计好，枯燥的执行完全依靠人去进行，大家天然会想到这种方法是可不取的，因此一般都会引入技术，进行自动化执行，这也是当前测试技术领域研究最多的方面，即如何用技术让测试自动化起来。

定义：通过各种维度的分析，观测对象的表现，以发现潜在的问题。

物理意义：在对应测试输入的前提下，决定了达到召回问题上限的水平。

具体的行为包括：

针对不同对象，可能要分析的行为也不一样，因此在实际过程中需要综合考虑。

四个层级，分析起来的难度依次增大，也更加抽象，分析能力也是测试AI化最难突破的地方。

从定义上可以看到，测试分析是观测系统的表现，来判断系统的问题，以人为中心一般只能看到系统肉眼可见的表现，但是在问题已经出现但是还没有显性出来或人忽略的情况下，这种问题就经常会被忽略，因此需要用技术，通过抓取系统的各类表现数据，进行数据分析，最终得出是否有问题的判断。

定义：当测试分析发现对象有问题的时候，根据变更行为和环境等因素，定位出对象出问题的原因，方便快速修复

物理意义：决定了修复效率，即出现了问题后准确找到问题根因所在。

具体的测试行为包括：问题根因定位、构建失败识别与自愈等。

定位是项非常高投入的工作，该工作做好了会极大的提升工作效率，因此也是技术一直想去突破的方向。

定义：根据潜在的风险分析、揭错活动的行为覆盖集合，通过模型，指出可能潜在的风险；

物理意义：以第三方视角进行问题的查漏补缺。

具体的行为包括：

测试评估是在做最后一步的风险决策和召回。

但是测试评估往往会被测试工作者忽略，主要是因为随着自动化水平的不断提升，形成了看报告是否pass的惯性，而往往会忽视其实自动化执行更多的是之前经验的积累（在没有智能测试生成的情况下）很难完全揭错新的变化或者随着系统的开发积累的变化带来的问题，因此测试评估要逐渐走入测试工作者的视野，但是评估工作需要充分的数据来进行分析和判断，因此测试评估更多要依赖技术+模型进行，最后依托人不断挖掘特征进行持续的准确决策。

因此，围绕对象进行研究非常关键，其次才是用各种生成、分析、评估工具去想办法揭错。

所以从这个角度的去理解传统自动化，即执行更多偏向的是测试执行和测试定位，是不会提升召回能力的，测试召回的水平还是被撰写的用例、流量的仿真等决定了，这块往往会被自动化三个词而忽略。自动化就等于自动化执行，很多时候自动化执行起来了，大家关注的重心就是覆盖率、成功率、召回能力等，但其实应该包括测试生成、测试分析和评估的持续投入，然后用自动化技术将所有这些能力例行化的跑起来（历史自动化都是人写好了，但是需要持续的进行技术投入得到提升，不然召回能力就一直会停留在某个过去的时间，随着时间的推移就会导致自动化成为鸡肋）。为什么仍然进行自动化测试，从质量成本角度可能更好的理解，后面会有更加详细的介绍。

测试不可能召回所有问题，主要原因如下：

但是对于QAer不能放弃对问题的尽量多召回。

从测试召回的问题类型上看其实测试召回分为显性和隐性的，其中显性的叫做新功能测试，这个是测试的热点，也是一直以来业务赋予QAer最基本的职能，保障新功能的正确性和交付，但是其实QAer也要看到随着系统尤其是微服务架构的扩散，系统的复杂性逐渐提升，新功能带来对老功能和周边业务的影响不可避免，这块隐性的测试逐渐变得至关重要，但是因为精力、能力和关注的焦点等很容易被忽略，而且将人力投入在回归的浩瀚集合中，显然会是ROI比较低的手段，因此技术可能是解决回归测试的关键所在。

从召回问题的具体类型的角度，测试可以分为性能测试、功能测试、安全测试、接口测试、稳定性测试、UI测试、兼容性测试等，这样分的目标就是针对不同问题的表现，测试的方法是不一样的，可以更好的去理解对不同问题的召回手段重点。

从召回问题级别的角度，测试可以分为白盒测试、单元测试、模块测试、系统级测试等，这个划分的标准是对测试对象的层级进行划分，比如白盒的对象可能是函数或类，模块测试可能是一个服务，这种划分方式，有助于指导合理的问题在合理的模块进行召回。

从技术手段的角度，测试可以分为精准测试、自动化测试、压力测试、探索性测试、fuzzing测试、遍历测试、线上测试、手工测试，这种划分更多的看技术驱动，体现的是技术在测试作用，而不侧重分发现哪些类的问题。

从召回问题职责进行划分，可以分为新功能测试和回归测试两大类。

通常新功能测试和回归测试这种划分在业界会说的比较少，因此下面重点介绍下这两种类型的划分的定义和好处。

定义：验证代码的实现是否符合业务需求。

建议：RD尽量先保证实现的正确性和合理性，所以理论上新功能测试的验证研发是主角，QA提供测试服务保障。

QA可研究的领域：测试服务化（环境、单测）、用例自动生成、白盒扫描、用例设计和评估等。

定义：验证升级的代码对本服务或周边业务带来的影响

建议：回归测试建议是QA的主责，让RD花更多精力在新功能和价值创造上。

新功能测试和回归测试从测试方法论上，都符合测试输入、分析和评估的拆解，但是职责上有所侧重，正因为如此，处理方式应该有所不同：

定义：对质量造成的损失进行控制或召回过程需要消耗的总成本。

基本包括：单位时间成本*占用时长

为什么要提召回成本：

单问题成本：问题召回成本+定位成本+修复成本 = 召回时间*单位召回资源成本 + 定位时间*单位定位资源成本 + 修复时间*单位修复成本

所有问题召回成本：就是所有单问题成本的总和

可以看到：同一个问题，在越小范围的召回比大范围的召回从定位时间、修复时间对应的单位人力成本（均是同一个人）是一样的，但是修复时间、定位时间会大大缩短，因此也可以降低召回成本，其实这就是质量前置的基本由来。

为了计算出召回成本，QAer对不同召回级别的召回成本的大体进行了分类划分：

要降低召回成本，首先要做的就是尽量减少无效的揭错行为集或重复的揭错行为集，因为存在两个真实的前提：

这就要求QAer需要“看”准了再测，也就是后续讲的基于风险的测试由来，所以QAer就提出智能构建：用于智能裁剪自动化任务；质量度模型：用于判断是否需要人工介入等。

其次同一个问题的发现希望投入的成本更低，包括定位、修复和发现，因此希望可以调节问题的合理分布，如尽可能的在代码层级召回、再在单模块、再是集成召回；其次尽量用机器去召回（一般认为人的成本比机器成本高），所以调分布这里面有几个理解：

再回过头来说下质量前置：应该想办法让在对应级别的问题在该级别发现，而非一定是系统集成的问题要在开发环节召回，也并不是简单的将测试任务放到开发阶段、提交阶段。

无论是理解一、二、三，要实现它，离不开一个关键词就是技术：

PS：这里面说的技术，不只是自动化执行

总结一下，测试章节的内容主要包括：

综合对测试的介绍，提升技术在测试召回和测试效率的成分至关重要，也是做好测试的必然选择，下面章节主要和大家聊聊测试技术相关的理解。

从下面的章节，就开始聊测试技术，也是前面推导出来的，传统上大家聊到测试技术，一般第一反应就是自动化，甚至有时候自动化就是测试技术好坏的代名词，但是通过上面关于质量、测试的本质进行剖析和分解：

在下面的章节，会去介绍在测试技术不只是自动化（执行），可以看到，为了提升测试召回，测试技术将更大有可为。

如前面介绍，测试技术不等于自动化，所以测试技术的主要职责不只是提效，而是要先提召回，其次将整个过程自动执行起来替代人执行和调分布进而提升效率。

传统的自动化在下面图中：核心在执行，即将依赖人的测试先验知识，通过技术用机器执行起来，主要表现在测试召回的执行层面。但测试技术其实在辅助人、调动人和模拟人方面还可以做更多，尤其是chatGPT的加持情况，将极大的提升这方面的可能性。

• 测试技术作用一：提升测试召回效果

这就要回到之前对测试本质的洞察上来，影响测试召回的核心要素包含测试输入、分析和评估三层，想要提升测试召回效果，测试技术就应该在这里做更多的投入，下面分别举几个例子，可以更加理解在对应领域加强对测试召回的投入：

1、测试输入：被测系统准确刻画的前提下：进行系统仿真能力建设或直接在线上进行测试活动，如流量仿真性涵盖引流、录制和回放；环境仿真性：包含词表、配置和上下游关系等。然后是测试行为集的构建：如接口的fuzzing能力、流量的筛选能力等。

这里特别提下客户端测试，可能更好理解测试输入中仿真能力和行为集的构建的关键作用：客户端的测试特点就是不确定性，主要原因有两个：

这些就会带来：

2、测试分析：前面提到测试分析是对象在输入情况下的表现行为，进而发现潜在的问题，这里面就涉及到对问题的表现形式进行分析；比如服务core的表现形式是什么；内存泄露的表现形式；脏数据的表现形式，可以基于此做，对象存不存在、特性有没有、逻辑对不对，功能好不好的判断和分析，尤其是好不好的判断，更加需求策略基于统计和概率做分析判断。没有分析就没有召回，比如单测没有任何校验点那单测就是形同虚设。

3、测试评估：以前容易忽视的环节，认为测试执行完成，如果报告没问题就万事大吉，但是殊不知，问题在底下暗流涌动，因此需要对变更风险进行评估、测试准出评估，所以这个领域就存在变更特征挖掘、变更影响面挖掘、测试行为数据采集（覆盖率）、质量度模型做最终决策等相关技术得到涌现，甚至通过测试评估去决策生成后续的召回行为。

上述技术投入均有利于提升测试召回且需要持续投入，因为对象在不断变化，这也是促使QAer不断革新和变化的驱动力。

上述视角是从影响测试召回的三个关键因素去做的技术投入和分析的，下面从另一个视角，去分析测试技术在测试召回的不可替代作用。

基于这两点，技术可以帮助弥补上诉不足，因此从这两点也可以研究出对应的召回技术，如主动召回技术：智能UT、AISA(智能化代码缺陷检测)、线上风险检测（线上系统的风险实时检测，如单点部署风险、超时配置不合理风险等）等。

从测试召回对依赖“人”程度的层面，一般会把技术对召回的影响程度进行划分：

线上测试的必要性分析

线下测试两个天然的弊端：

基于此在有条件的情况下，可以对线上系统进行有针对性的测试，提升系统的召回能力，以前线上测试存在安全、影响等问题，相关的实践比较少，但随着微服务云原生技术的兴起，为线上测试提供的基础技术保障，因此线上测试变成了可能， 尤其是针对重大活动或高流量场景变得尤为重要。

• 测试技术作用二：实现不依赖“人”执行——即自动化提效

前面说自动化--即狭义上理解的自动化执行，不会提升召回，那为什么还有提自动化，这里面需要做如下拆解：

聊聊自动化

自动化本质：将成员的集体智慧转化为整个团队的利益，并将测试行为用机器运转起来。

整个过程包含测试的整体：含测试输入、分析、执行、定位和评估，自动化是这些测试召回技术跑起来的技术载体，先有前者，汇聚起来就是自动化。

从上述定义的角度看，自动化有以下几个特性：

自动化从召回问题类型的角度进行拆分：

新功能自动化

新功能需要做到完全自动化，目前看还是非常困难的，需要根据功能点，进行测试用例的自动生成和执行，但是做辅助还是有可能的。

1、辅助用例生成

2、辅助环境生成、测试数据生成等

这块重点可以先focus在如何提供测试服务，而不是全自动化或一次行多次回放的单次可获得性的研究。

回归测试的重要性

受限于测试技术的自动执行：回归测试其实包含手工回归和自动化回归，自动化回归的重要性上面也提到过，那么手工回归是亦是如此，其实本质是一样的，无非是执行者是机器还是人的区别，本质上也需要要做好沉淀、刻画、评估等工作，沉淀至关重要。因此手工回归测试也更需要做技术赋能的探索，比如用例推荐、在线化支持、准出评估等。

技术是实现高ROI回归测试的必然路径

回归测试的目标是通过测试活动召回变更对本业务历史功能和周边业务功能带来的问题，如果回归测试通过手工执行，那么人首先要搭好环境、运行所有已有的本业务功能和周边业务相关的功能的用例，然后观测系统的表现，这样就会带来几个问题：

上述的原因综合起来体现出来的就是：

因此只有技术才能够解决回归测试，而且是有可能的，因为回归是测试人员已经将用例撰写出来，核心就是自动化执行的问题，如果评估影响、选出用例、自动化的执行，这些均和技术息息相关。

综上自动化的总结：经验通过自动化得到沉淀，使得经验可以通过技术无差异的得到传承，进而解除对人的依赖，让新品快速达到高水平，而人的召回能力一直在这个高水平的情况下不断迭代，进而促使召回能力一直在上升。

• 聊聊百度一直做的基于风险的测试技术 Risk-based Testing Technology

定义：根据潜在的风险分析，决策测试输入和分析的行为，以ROI较高的方式进行揭错。

从理论推导的角度，首先测试召回是要考虑召回成本的，其次就是基于人的经验测试，其实存在盲区，因此要用机器帮忙做风险判断。

从收益的角度，为什么要Risk-based Testing Technology：

理论上，基于风险的决策如果风险模型得到有效和持续沉淀，其召回能力不会低于人的基本水平，甚至会在某些场景下更高，其次可以达到ROI较高的手段。

基于风险的测试测试与精准测试测试区别：

最后这个环节，基于最近非常火的chatGPT，而衍生下来的Code-GPT等很多领域，做了些比较浅显的思考，后续会不断加强这块的沉淀，完善这块理解。

意义

chatGPT，对人类社会确实带来了很多变化，其成功理解其实有两个核心原因：

从技术上两个关键因素：

给软件测试的启发：

因此TestGPT，暂且叫TestGPT是有可能做出来的，而且也有一定信心。

可行性分析

TestGPT，如果这两个假设一直持续下去，可以执行下去：

具体场景——百度智能测试第三阶段

关于如何做，这边更多的是从可以投入的方向做了几个思考：

总结一下，测试技术章节的内容主要包括：

1、加强质量技术的研究，质量技术远非是当前的广度和深度

架构鲁棒性、服务闪回、软件可持续性、测试召回技术、测试自动化技术、代码检测技术、监控召回技术等领域远远没达到理想的状态，需要从业者思考、研究和切实的解决。

2、加强对被测对象的研究

一切的基础，知己知彼，方能主动，研究好和刻画出测试对象，理解测试对象非常关键。

3、加强测试技术的研究，测试技术远非是当前的广度和深度

测试技术不等于自动化执行，想提升测试召回，测试输入、分析、评估，技术上还可以做很多。

4、重视回归测试，加强对经验的持续沉淀

随着业务复杂性增强，模块和跨业务的积累和交叉会变得负责和不可控，需要用持续智慧的沉淀，进行准确的回归进行相互影响的召回，不能只是面向“新需求的功能验证测试“。

5、提升对主动召回技术的投入，弥补人的盲区

受限于客观条件，人有其经验、精力等盲区，用不依赖人的技术做召回，是查漏补缺的关键。

6、技术是调节召回成本分布的重要载体

• 自动化执行可以将用例所蕴含的召回经验积累和传递给其余角色，形成角色召回的穿插。

• 自动化执行可以将召回经验随时随地执行，因此可以将任务穿插在各个阶段、各个角色。

7、相信TestGPT，QAer应该靠“创造”力生存而非“经验”生存

某某对这个业务非常熟悉，不能成为个人竞争力的理由，经验会被AI或其余人替代。

质量和测试不只是“点点点”，而且很多质量问题不能完全靠“点点点”能解决的，需要用技术的思路去解决问题就会发现有很多值得研究的技术，不只是软件工程领域，类似在人类社会都是永恒不变值得研究课题如前几年的精准防控等。加强思考，以未来已来的心态去拥抱变化。

- EOF -

加主页君微信，不仅Linux技能+1

主页君日常还会在个人微信分享Linux相关工具、资源和精选技术文章，不定期分享一些有意思的活动、岗位内推以及如何用技术做业余项目

加个微信，打开一扇窗

看完本文有收获？请分享给更多人

推荐关注「Linux 爱好者」，提升Linux技能

点赞和在看就是最大的支持❤️