作者 | 百度挪动生态质效工程师们
导读
在降本增效、以 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，公式如下：
品质模型即问题给业务带来的损失：（变更数_问题密度（概率）_（研发漏出率）（测试漏出率）问题解决程度）
\(E\)：品质模型即问题给业务带来的损失：示意一段时间内所有变更对业务带来的损失，可能是商业损失、用户散失等；
\(M\)：代表某段时间服务的总变更数，i 示意第 i 个变更，变更类型可能不同。蕴含需要变更、线上词表变更、运维操作、业务操作、硬件 / 业务变动、依赖业务变动等，这层思考决定品质关注的广度，应该做到尽量别漏，任何的变更都可能会对系统造成毁坏；
\(S_{i}\)：示意第 i 次变更，此处个别用 1 示意；
\(\rho _{i}\)：第 i 次变更，产生问题的概率（即问题密度），特地留神，随着零碎复杂性减少，产生问题的概率不仅蕴含对本身的，也蕴含对其余服务影响的，如图中 服务 E 的 问题密度，应该要把对 C 和 A 的问题影响算进去，该值是通过后验回归进去的，相似总问题数 / 变更次数；此值反映了研发对系统的生成 bug 程度；
\(\gamma _{i}\)：研发漏出率：研发漏出问题数 / 总问题数
研发漏出问题数：线上问题 + 提测后 QA 测试召回问题，1- 研发漏出率即为研发召回；此值能够反映出研发人员的自测程度；
\(\lambda _{i}\)：测试漏出率，线上问题总数 / 研发漏出问题数，1- 测试漏出率即为测试召回率，此值反映了测试人员的召回问题程度；
\(D_{i}\)：故障影响面，单位工夫造成损失；
\(MTTR_{i} \)：故障解决时长，从问题产生到最终止损实现的操作时长。
故障影响面（单位工夫造成损失）* 故障解决时长（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——
举荐浏览：
百度 APP iOS 端包体积 50M 优化实际 (一) 总览
基于 FFmpeg 和 Wasm 的 Web 端视频截帧计划
百度研发效力从度量到数字化变质之路
百度内容了解推理服务 FaaS 实战——Punica 零碎
精准水位在流批一体数据仓库的摸索和实际
视频编辑场景下的文字模版技术计划