百度工程师的软件质量与测试随笔
作者 | 百度移动生态质效工程师们
导读
在降本增效、以 chatGPT 为代表的大模型技术横空出世的背景下，对软件质量和软件测试的领域也带来了巨大冲击，也使得软件质量工作者开始变得焦虑，主要体现在：公司对软件质量从业者的不重视加剧，一些追求临时交付的开发或质量行为屡见不鲜。基于此，近期对 10 多年以来从事软件质量工作的相关思路总结起来，希望帮助从业者在复杂多变的环境下看清楚些方向和做出更加合理的判断。
文章希望能够用通俗的语言，来阐述对软件质量和测试的理解，以便更好的引导从业者开展软件质量和测试工作，也可以理解作为软件质量工作者平时工作的内容和意义，甚至理解为什么这样做，先说明以下几点：
1、文章不会大规模的讲测试技术实现；
2、文章局限在软件质量和测试，对其余相关事宜不会具体展开。
希望阅读这篇文章会给你带来：
1、从软件质量角度，准确的判断做的事情究竟在贡献什么、价值在哪里；
2、从软件质量角度，理解做的事情为什么而做，为什么目标服务；
3、客观的认识软件质量和测试关系；
4、重视软件质量和测试技术，一些短期看不到收益的事情，不代表不重要；
5、测试技术充满挑战，有深度也有广度，作为测试工作者应该需要有这份自信；
6、能够促使从业者更多的思考。
全文 19098 字，预计阅读时间 48 分钟。
01 什么是质量
百度百科定义：客体的一组固有特性满足要求的程度。
在人们的意识中，不符合事物的预期表现都和质量相关，但要穷举又非常困难，主要原因质量是个非常抽象的词。但作为质量工作者，仍然需要提升对质量的理解，来指导质量工作者的工作，为此需要让对质量的理解从抽象变得可描述、具体。
下面基于对近些年来从事软件质量工作的总结，简要介绍对质量理解的内容。
02 从可用、好用、爱用三层理解软件质量
软件质量是比较抽象的词语，在软件工程领域，一般质量的好坏都会用问题数，bug 数去衡量，而 bug 数与测试召回有很大关系，所以很多时候，大家聊到质量，都会直接想到测试、想到 QAer，因此认为质量=测试=QA，这很正常。接下来更多的是从“价值”驱动的视角，讲下关于软件质量的几个不同理解，可能对后续的工作有一定帮助：
软件质量第一层理解—可用
保障软件服务可用，也就是提供的产品或服务，让用户/客户能够正常的用起来。用可用这种方式去描述质量，就会变得更加具体。这层理解就会驱使质量保障或者测试活动的重心是放在服务的稳定性、SLA 和功能的正确性、策略是否符合初衷等方面，这是软件质量领域目前投入最多的，这个理解和投入没错，因为这给予质量保障者最基本的职能。再者推敲一下，站在提供服务的公司视角看质量可用，保障软件可用核心目标是降低服务不可用带来的损失，其实最终需要看质量问题给业务带来的损失，因此从业者行话是控损：即控制业务损失和不符合预期的功能带来的体验问题。此阶段 QAer 的工作价值在于保交付，控业务损失，这样看到的就不是简单的问题数，任何问题对业务损失的影响才是从业者要去追求和研究的。
软件质量第二层理解—好用
从质量驱动更多价值的角度，质量在保障服务可用的前提下，其实可以做的更进一步，即好用：也就是提供的产品或服务，不仅满足了用户/客户的基本诉求，更多的是关注服务对他们的满足、体验情况如何，这个层面质量的重心从保障服务的稳定性和正确性方面会逐渐转移到用户/客户体验提升的角度。该角度看质量其实会给业务带来更多损失之外的实际价值，比如留存、时长、生态闭环提升等等，目标是稳业务，由控损到稳业务的转变。特别强调的是，软件质量层面做的留存和业务 PM 做的留存方式不一样，业务 PM 更多的是从功能完整性的角度设计用更多好用的功能吸引用户，质量层面是从用户体验的视角去抽象出潜在问题，驱动产品和技术改进。比如对客户端 APP 来说，梳理出来的对好用的理解：
1、产品对用户打扰-升级弹窗是否合理；
2、产品对用户硬件和物理体感的影响——CPU、内存、网络、磁盘等损耗和性能较差；
3、产品对用户需求满足情况——如发布的功能与用户习惯的偏差等。
此阶段 QAer 的价值在于保交付，稳业务发展。
软件质量第三层理解—爱用
爱用就是让用户/客户成为服务的代言人，主动推荐服务给周边。这个核心理解如何挖掘用户、挖掘潜在需求进而转化成业务追求的价值，这个目标逐渐与 PM 工作殊途同归，但是做的工作方式不一样，比如软件质量从业者可以发挥更多技术优势，在竞品数据抓取、用户行为画像和分析方面提供服务等。因此，在爱用这个层面质量关注的重点也就不一样，手段是保证可用和好用的前提下，如何挖掘出更多潜在的用户和需求，促使业务持续增长。此阶段 QAer 的价值在于保交付，促业务增长。
综上所述，提到了软件质量从可用、好用、爱用的三层理解，稍微做个总结：
1、可用核心是控制问题带来的业务损失，QAer 的工作价值在于保交付，控业务损失；好用核心是提升体验，驱动业务可持续发展，QAer 的价值在于保交付，稳业务发展；爱用核心是挖掘用户驱动业务正增长，QAer 的价值在于保交付，促业务增长；
2、从用户/客户的视角，三者的层次依次是：服务好已有用户/客户、留下更多用户/客户和挖掘潜在用户/客户；
3、这种划分赋予了质量这个抽象的词，在软件工程领域更加形象的理解，方便大家理解软件质量的工作。
从质量发展的角度，三者依次进行，所以目前一般聊的质量还是在可用层面，下面的文章也主要是从保障服务可用的角度去展开阐述的。
03 软件质量建模过程解读
为什么要做软件质量模型主要是希望通过模型的拆解，能够看到影响软件质量因素有哪些，方便软件质量工作者更好的安排工作和找到质量做好的工作归因，最终形成正循环，基于保障可用的目标是控制业务损失的思考，构建出来的软件质量模型为：
假设有一套如上图的软件系统，有 A、B、C、D、E、F 六个子服务，关系图如上图描述要算出子服务 E 的各类变更带来损失期望 E，公式如下：
质量模型即问题给业务带来的损失：（变更数 * 问题密度（概率） * (研发漏出率）* （测试漏出率）* 问题处理水平）
：质量模型即问题给业务带来的损失：表示一段时间内所有变更对业务带来的损失，可能是商业损失、用户流失等；
：代表某段时间服务的总变更数，i 表示第 i 个变更，变更类型可能不同。包含需求变更、线上词表变更、运维操作、业务操作、硬件/业务变化、依赖业务变化等，这层考虑决定质量关注的广度，应该做到尽量别漏，任何的变更都可能会对系统造成破坏；
：表示第 i 次变更，此处一般用 1 表示；
：第 i 次变更，产生问题的概率（即问题密度），特别注意，随着系统复杂性增加，产生问题的概率不仅包含对自身的，也包含对其余服务影响的，如图中服务 E 的问题密度，应该要把对 C 和 A 的问题影响算进去，该值是通过后验回归出来的，类似总问题数/变更次数；此值反映了研发对系统的生成 bug 水平；
：研发漏出率： 研发漏出问题数/总问题数
研发漏出问题数：线上问题+提测后 QA 测试召回问题，1-研发漏出率即为研发召回；此值可以反映出研发人员的自测水平；
：测试漏出率，线上问题总数/研发漏出问题数，1-测试漏出率即为测试召回率，此值反映了测试人员的召回问题水平；
：故障影响面，单位时间造成损失；
：故障处理时长，从问题发生到最终止损完成的操作时长。
故障影响面（单位时间造成损失）* 故障处理时长（MTTR）统称为问题处理水平。
问题密度和研发召回的综合结果可以称为研发质量，是一个比较虚的概念。
质量成本：为了控制某个变更带来业务损失，所消耗的资源成本，包括人力资源、IT 资源等，具体形态上包括：开发者投入到质量活动的成本（为了质量考虑的设计、开发）、问题召回成本、定位和修复成本、为了提升鲁棒性额外增加的 IT 资源成本等。这里要特别提下召回成本：应该是包含所有为了保障该变更的质量活动，与定位、修复成本还有一定区别，因为这两项成本是已经确定了有质量问题的前提下进行的，无需考虑无效因素。
3.1 变更因素
变更因素包含需求变更、线上词表变更、运维操作、业务操作、硬件/业务变化、依赖业务变化影响等，这些因素均会直接或间接对系统带来影响，进而可能带来业务损失的影响，质量工作者需要尽量考虑更全面的变化因素，有以下几个好处：
1、从质量角度，质量除了代码影响本身，还有更多的考量因素，需要召回的面更加全面，不至于那么被动。
2、从效能角度，QAer 职责不只是“需求”交付，还在保障线上系统的正常运转和“需求”变化带来的对整个业务系统正常运转。
这里特别要提是：有些变更是对线上系统直接操作，所以线下仿真起来特别困难且不现实，因此对线上操作的必要审批、流程和 checker 需要加强。
3.2 问题密度
问题密度从物理上反映的一个系统产生缺陷的水平，问题密度与很多因素相关如：架构设计、技术债务、开发能力、系统韧性、业务复杂性、依赖程度等，该指标真正反映了一个研发团队在质量的技术水平，因此从研发的角度，应该多重视该指标的建设与提升，质量内建是一件非常值得研究的事情，尤其是架构、技术债务潜移默化的影响，容易被人忽视。
3.3 研发召回
研发召回反映了一支研发团队对生产代码的质量问题的召回水平，该指标可以反映出质量意识，业务因历史或紧急等情况不得不接受短期实现，因此就需要有比较好的质量意识进行自测，QA 在此时可提供测试服务、测试用例和评估等辅助工具，辅助研发进行自测。需要说明的是，不是导向研发要召回所有问题，但基本的功能正确性和系统健壮需要保障，而回归、相互影响等消耗较大的工作可以交给专业 QA 进行，研发则更加专注架构和技术创新，两者应该各司其职，做好明确的分工，因此需要这么一个指标。
问题密度+研发召回：可以统称为研发质量，即研发可以通过降低问题密度+自测提升交付质量
3.4 测试召回
前面提到研发召回有自身专注的召回问题类型，而 QAer 则是作为新功能的兜底和回归测试的主力。针对新功能更多的是查漏补缺；而随着业务和模块复杂性提升，对回归需要足够重视和加强，这是开发和 QAer 很容易忽视的地方。而在质量模型变更类型更加丰富的情况下，测试召回不能将视野只局限在线下进行，所以需要特别提三点：
1、加强线上测试；
2、加强线上操作的审核和完善流程；
3、加强线上风险检测力度。
为什么？首先系统会随着外部环境、代码积累和硬件老化而逐渐出现一些潜在的新问题，系统问题可能会爆发，很典型的性能瓶颈问题；其次线下测试的仿真性天然会存在很大差异，因此必要的线上测试和风险巡检是不可避免的。关于测试召回是 QAer 一直以来投入的大头，因此在后面的章节专门会对测试进行展开介绍。
3.5 处理水平
故障的发生无论召回的大网有多严密都会出现。在故障不可避免发生的前提下，QAer 要做的是尽可能降低故障对业务造成的损失。控制好故障对业务造成的损失反映的就是系统对故障的处理水平，造成损失有两个主要因素：
1、故障影响面：定义为单位时间对业务造成的损失量；尽量控制故障影响的范围，这里也包括流量、机房对其余业务的扩散。因此在传统意义上，有单沙盒、单机、单机房的 checker 和线上监控，这些手段都是希望尽早的感知到，控制好影响面。因此当系统不可避免会产生很多问题，或者线下召回体系不那么健全时，对故障影响面的控制，一般都会成为团队首选。但是这种情况不可取，“毕竟常在水边走，哪有不湿鞋”的道理，大家均是懂的，而且即使影响面控制到小范围，仍然是对业务造成了影响。
2、故障的恢复时长：顾名思义就是让故障快速止损，以降低业务损失，为了更好拆解对应的事情，一般会把故障的恢复时长，进行进一步拆解 MTTR 为 MTTA、MTTI、MTTO 等一系列指标，分别反映故障感知时间（发生到人开始跟进处理）、故障止损操作开始时间（即发生故障到开始决定要干什么止损操作的时间）、故障操作时间（即开始操作到故障最终恢复时间）
MTTA：故障感知时间，从发生到被人开始跟进处理的时间，基本的技术方向投入，其实 checker 和监控，这是 QAer 一直以来投入的技术方向，如何更全面、阈值更灵活的报警并且触达到该触达的人，一直是该方向研究的关键。
MTTI：故障止损决策时间，也即根据故障表象、系统关联关系、变更等情况，决策研发或 OP 要进行的止损行为，这块依赖策略，更依赖系统表现行为数据，更方便的做决策。
MTTO：故障开始操作到恢复的时间，这块反映的是操作人员的专业性和系统自恢复的能力，和架构很大关系，比如故障的启动时间、启动是否有依赖等等，任何 1min 可能都会造成巨大损失，架构上需要特别注意。
站在控制业务损失的角度，处理水平，需要逐渐进入 QAer 整体视野，并开始加强导向和技术投入，目前对该方向的研究和理解也在逐步加深，在此文中暂时不展开讲相关内容。
3.6 质量成本
质量成本：定义为了让对象的有更好质量，在此过程中消耗的人力和资源成本。
从定义上成本包括：研发架构开发和维护、测试召回（QAer 和机器）、线上问题报警、决策和运维、故障定位和问题修复成本，这些均需要考虑进去，站在 QAer 团队的视角，可能考虑更多的是测试召回成本、线上问题报警和决策的成本。
为什么要在此提出质量成本，主要有两个原因：
1、在降本增效的大背景下， 任何事情都不可能无限制的投入，尤其需要特别注意两点：一个是无效投入，一个是低效投入，在保障质量可用的世界里，这两个现实的状态是存在的：不是所有变化都有质量问题；不是所有的行为都会揭错，这就要求 QAer 尽量杜绝这类的工作浪费。关于低效就是希望需要找到 ROI 更高的方式去召回，比如明明可以追求自动化，却一直不肯投入。
2、如果要让质量绝对的好，那么就意味着需要无限时间的进行测试，但是这显然是不现实，核心是降低故障发生的概率和故障发生时的快速处理，因此里面需要有个平衡，这个平衡可能就是要把质量成本考虑进去的。
从上述过程可以看出，要做好质量控制，所有环节均可开展工作，那么如何选择最合理的方式开展质量工作，这就要考虑成本因素，因此如何调整质量的召回分布，进而去保障质量而控制投入，将会是在降本增效的大背景下，QAer 一直需要研究的话题，即回归出一个质量成本和损失量的 ROI 控制公式。
总结一下，质量章节内容主要包括：
1、从服务可用、好用、爱用三个层次，更加具象化的描述软件质量，以加深对质量的实际理解；
2、从控制业务损失的视角，建立了从“需求”、开发、自测、测试和问题控制等多方面影响损失的质量模型，让大家更加清晰的看到影响质量的因素和角色，方便从业者更好的理解自身在质量领域的定位和工作内容；
3、在降本增效的大背景下，质量成本是不可忽视的一个因素，需要逐渐降质量成本考虑进去，以更好的去判断用什么样的方式去召回才能发挥最好的效果。
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 至关重要，可以看下面几句话
1、加强质量技术的研究，质量技术远非是当前的广度和深度
架构鲁棒性、服务闪回、软件可持续性、测试召回技术、测试自动化技术、代码检测技术、监控召回技术等领域远远没达到理想的状态，需要从业者思考、研究和切实的解决。
2、加强对被测对象的研究
一切的基础，知己知彼，方能主动，研究好和刻画出测试对象，理解测试对象非常关键。
3、加强测试技术的研究，测试技术远非是当前的广度和深度
测试技术不等于自动化执行，想提升测试召回，测试输入、分析、评估，技术上还可以做很多。
4、重视回归测试，加强对经验的持续沉淀
随着业务复杂性增强，模块和跨业务的积累和交叉会变得负责和不可控，需要用持续智慧的沉淀，进行准确的回归进行相互影响的召回，不能只是面向“新需求的功能验证测试“。
5、提升对主动召回技术的投入，弥补人的盲区
受限于客观条件，人有其经验、精力等盲区，用不依赖人的技术做召回，是查漏补缺的关键。
6、技术是调节召回成本分布的重要载体
自动化执行可以将用例所蕴含的召回经验积累和传递给其余角色，形成角色召回的穿插。
自动化执行可以将召回经验随时随地执行，因此可以将任务穿插在各个阶段、各个角色。
7、相信 TestGPT，QAer 应该靠“创造”力生存而非“经验”生存
某某对这个业务非常熟悉，不能成为个人竞争力的理由，经验会被 AI 或其余人替代。
09 总结
质量和测试不只是“点点点”，而且很多质量问题不能完全靠“点点点”能解决的，需要用技术的思路去解决问题就会发现有很多值得研究的技术，不只是软件工程领域，类似在人类社会都是永恒不变值得研究课题如前几年的精准防控等。加强思考，以未来已来的心态去拥抱变化。
——END——
推荐阅读：
版权声明: 本文为 InfoQ 作者【百度Geek说】的原创文章。
原文链接:【http://xie.infoq.cn/article/b97eaf0098f00988e4f42def5】。文章转载请联系作者。
百度官方技术账号 2021-01-22 加入
关注我们，带你了解更多百度技术干货。
评论