📌 本文定位： 最近随着经常让AI帮我做网页、做应用，我自己测BUG的时候越来越多了，结合之前多年的系统部署和运维经验，我回顾了下我发现异常、排除异常的一些思路心得，梳理一份实战排障经验集合。一方面是整理完自己的思绪，另一方面是把我的经验思路变成一个可论证、可复制的技能。本文主要写五件事：面对一个软件系统，异常通常藏在哪些地方（第一章）；用什么去查（第二章）；锁定一个异常之后怎么把范围缩小（第三章）；那种时有时无的偶现 Bug 怎么对付（第四章）；以及排查完怎么验证、怎么提报（第五章）。

三个我的经验观念

第一，Bug 多数不是”测”出来的，是在”使用中用出来的”。

很多人可能觉得找 Bug 是测试工程师的专职工作，需要写测试用例、跑自动化、做覆盖率统计。

但根据我之前的经验，测试工程师很可能找不出来很多bug。很多时候，测试工程师是开发工程师的质检，他们两个人都对着同一个东西，就是需求文档。研发根据需求文档，编写程序的逻辑，而测试工程师根据需求文档描述的功能逻辑去验证研发的逻辑。

我感觉，专业的研发往往其实自己开发代码的过程中就会自己进行单元测试，这时候相对于需求而言，Bug其实已经少了很多了，测试工程师再对这需求预期进行测试，是在找”预期内的错误”，很多时候是给开发工程师查漏补缺的作用。所有也有不少公司，把测试的绩效当作扣开发工程师的绩效。哈哈哈。

这个思路想象成工厂里面的生产工和质检工的关系就对应上了。

所以测试工程师大多数时候是对着需求文档测文档预期的Bug。很多时候他们其实也发现研发写的一套代码逻辑可能存在问题了。可能符合文档但不符合用户的使用。但我遇到了的不少测试工程师反而会把这样的Bug放过。

因为大多数测试工程师都很忙。实际的项目经验中。开发工程师经常压着线提交代码，而测试工程师经常忙碌得为了业务模块能上线而排期测试。有时候哪怕知道代码逻辑有问题，但基本符合需求文档的预期，也是受限于精力和疲惫，也就是放过上线了。

真正让开发者头疼的、也最有价值的那批 Bug，往往来自重度用户的真实使用路径——因为用户的用法组合是测试用例永远枚举不完的。所以经常会听到那个关于测试工程师漏测了用户到酒馆要炒饭导致程序爆炸的梗。

很多时候多看一眼，多翻一翻，多按照用户的思维”我觉得应该”……往往就是这样，我换换思路，多试一下的尝试。Bug就发现了。

第二，定位 Bug ≠ 给出根因。

我以前刚在现场排查Bug的时候，总想着各种方法去测试，甚至翻找日志信息，去把所有疑点列出来填在Bug上报里面。最近我在用AI开发的过程中，我也是时不时想去看代码层面这个Bug到底怎么回事。

这种好奇心倒是好的。但如果作为测试的新手，其实容易背上精准定位问题的心理包袱。很多时候，作为测试的工作是找到了稳定复现Bug的流程，找到了Bug出现的前置条件或者能够详细的描述Bug的发生过程，这个已经是比较优良的Bug了。

毕竟程序的代码不是测试写的，代码中的逻辑其实大多数只有研发本人知道他埋的坑。与其花大量的时间去尝试定位原因，不如找到稳定、清晰描述的Bug发生的过程和现象。这已经很帮助开发者定位自己代码的问题了。

Bug上报的价值，绝大部分在”缩小范围”，而不是自己去”给出答案”。如果总是这样的思路，不如尝试转到开发。把问题从”软件坏了”缩到”在 A 条件下、只发生在 B 环节、可稳定复现、已排除 C 和 D”，开发者接手时能省下几个小时。剩下那一步——读代码找根因——开发者本人找代码永远比别人快，因为那是他的代码。

第三，不要指挥开发者，除非你确实很懂。

如果你尝试去理解代码，尝试深入代码逻辑中去找到根因，并尝试把自己认为的Bug发生诱因写上去，很容易把开发工程师带偏思路，反而让他走进了死胡同。所有对自己代码了解的开发工程师一般都会自己根据现象去自己排除问题。

要尊重别人的代码。对于问题的反馈，老老实实写”我做了什么、看到了什么”——而那恰恰是维护者最想要的无污染原始观察。

如果忍不住自己的好奇心和推理，一定想写点自己的推测想法，一定要把”我看到的”和”我猜的”分开写。这样的猜测信息，才是增值信息，而不是污染源。

第一章 现场遇到的 Bug，都是些什么样子

先把数据摆出来

整理这篇博客文章之前，我把过去五六年的项目和系统工作经验中提交的各种Bug从系统里导了出来。

有个医院物流机器人的项目，导出就有测试bug 888 条。另外还有我负责的几套政务类的系统——城市管理、生态监测、文旅体、统一认证平台——合起来 210 条。

这些表基本都是用户使用中或者我自己调试系统、使用系统时发现的问题，基于这些数据来进行分析。

一半以上是”改”出来的。 相当多的Bug，标题带着【新引入】，占 53.4%。这个我清楚原因，因为大多数时候系统总是匆忙中上线，系统功能带着各种缺陷和不足，随后在客户的要求下就开始不断的补技术债，要增加功能、要修改功能。这时候Bug就来说层出不穷的出现。

这件事对测试的意义很直接：回归测试比功能测试更能抓 Bug。功能测试验证的是”这东西能不能用”，回归测试验证的是”给系统改动过动了一下，看系统有没有被碰坏”。而且回归测试恰好是最容易在时间紧的时候被砍掉的，直接上到现场让用户来测的环节，哈哈哈。因为新功能要赶上线，老功能反正默认”以前是好的”。

将近每五个提报里，有一个不是代码问题。 从 210 条城市类系统的故障记录看，最终的解决分布是这样的：

后五项加起来 39 条，占比 18.6%。将近每五个提报里有一个，研发认为不是他们的问题，而是各种巧合、外部等情况。

“设计如此”这种最常见的是客户的理解和我们产品需求设计的理解不一致。有的是客户没有理解到这样设计功能的原因，需要培训对齐，有的是产品和客户沟通后没有理解到业务细节，把功能细节做错了。

“无法重现”这种最是麻烦，有时候是研发干累了，为了赶紧下班随便敷衍了。有的时候则是用户环境和研发环境不一致。用户环境有缓存、有脏数据等。有的时候，遇到这种问题得多在不同的设备上尝试。

共性问题引发的 Bug

经典的Bug现象，例如相似的报错现象出现在不同的系统模块。这种往往是由于有共同的根因，导致出现相似的Bug。这种情况也需要测试看哪些模块出现了这个类似的情况，统计起来按一个Bug进行上报。便于研发通过这个问题的共性，找到这个问题的边界。

我印象最深的是”数据约束违规”这五个字，在十四条工单里出现过，横跨三套系统、十几个不同的模块——首页、话题评价、分类管理、场馆管理、文物管理、动态数据分析、驾驶舱、生态一张图、任务上报……甚至有一条是登录的时候就报，根本进不去系统。

一开始我是一条一条提的，提到第三条才反应过来，这不是十几个地方各错一遍，是十几个地方都在调同一个东西。合起来报一条之后，底层修好，十几个模块一起好了。

因为看不出差别的脏数据引发的 Bug

还有一类问题比较气人，我在现场遇到过：机器人正常执行任务，每次到了任务点位就直接任务失败，反复测试下基本定位问题和点位的数据有关。直到最后发现”离心1”和”离心1 “，在界面上显示完全一样。但程序比对的时候是一个字符一个字符比的，多一个空格就是两个不同的东西，于是程序校验出问题了，就出Bug了。研发自己也没想到空格会有这样的影响。

和这种情况类似的还有：

有很多数据，人看着一样，但在程序的世界不一样，就变成了脏数据。

双写：同一份数据存了两个地方

只要一个软件把同一份数据存在两个位置，就值得专门看一遍。本地文件加数据库索引、缓存加源数据、内存里的状态加落到磁盘的、主库加备份库、页面上的列表加数据库里的表——这类软件太多了。

我遇到最典型的一次是删掉的东西，自己回来了：界面上删了一条，刷新，还在。

查法是土办法：分别打开两个地方，用眼睛比。两边一比就知道毛病不在”存”这一步，在”从这儿搬到那儿”那一步。范围立刻少一半。

静默失败：程序没成功，但程序告诉你成功了

特别是现在的AI大模型，经常出现这样的幻觉。特别是任务量大、难度大的任务。还容易出现AI把自己的思考链当作自己已经做了的事情。有的时候一定得知道，系统提示归提示，系统提示完成了某个状态，不代表真的这个状态就改变了。

有的时候也是相关的用户操作界面设计没有完善好。程序执行了，不给用户一个反馈。

界面上说的和数据库里存的，是两件事。以前端提示为准做的判断，有一半是错的。

所以在现场我养成一个毛病：看到”成功”两个字，先不信，去翻一眼它到底落在哪了。

状态切换的那一瞬间

大部分流程，稳定状态是好的。而状态切换的瞬间最容易出问题。特别是这个瞬间叠加一些外部情况的变化。

例如模仿不耐烦的用户，提前点击了按钮、或者快速点击了按钮；例如点击保存配置后立马的刷新页面；新建之后马上编辑，编辑页打开是空的；提交任务后在系统提示仍在进行中时，进行刷新页面。

这类问题的共同点是：它们只在转换某个状态的极小的时间窗口时出现。你正常点，慢一点，就遇不上；你手快，或者网络卡了一下，就撞上了。

测试这种情况就要抱着故意按最坏的用户操作情况去试。不等加载完就点下一步，重复点两下，点完立刻切走再切回来，把网断三秒再接上。出问题就说明，未来用户实际使用的时候也会遇到这些问题。

物理世界的 Bug

这种做纯软件的人可能碰不到，做硬件设备的人会经常遇到各种玄学。

例如我曾经在现场给机器人配置新上了一批不锈钢的镂空推车。机器人稳定地去撞这个推车。最后测试下来，在特定的角度下，镂空推车的不锈钢腿在机器人的雷达和深度相机的死角中。

类似的情况还有，玻璃门影响机器人激光传感器。最诡异的，我认为是无线WIFI网络。在武汉的一个项目，有些机器人在任务行动中总是出现异常表现，而且总是在人员参观的时候出现。反复的测试和排查，发现问题和吊顶高度、AP的分布以及人群对信号的影响都有关系。真是太难了。

这些属于上触碰到了现实传感器的性能边界。所以搞带传感器的设备，第一个要问的不是”代码哪里错了”，而是它的感官是什么、看得见什么、看不见什么。

并发与重复操作

用户现场更常见的是人比我们的测试快，”手快”，人比我们的测试多，”人多”。

• 两个人同时改同一条记录，后保存的把先保存的覆盖了
• 同一个按钮快速点三下，建了三条
• 一个账号在两台设备上同时登录，一边的操作把另一边踢掉
• 定时任务和手动操作撞在一起，跑了两次

这类问题在公司的单人测试里基本测不出来，因为它要求的条件是”同时”。也是属于经常最后沦落到让用户来测试的常见问题。

第二章 用什么去查

提报本身就是第一工具

正确的反馈和填报异常的方式，是帮助寻找到Bug的第一工具。

重现步骤这个字段，我平均写 330 个字，最长写过 1446 个字。

字多不一定是耗好事，容易让阅读的人阅读困难。特别是我们在公司日日夜夜都在跑测试，已经跑得头脑昏昏沉沉的测试同学。哈哈，最讨厌看到长篇大论，只想你告诉他，先干啥、后干啥，然后复现出来bug现场，找研发查看。

不过有时候触发的Bug，特别是涉及硬件设备的Bug，存在很多的前置条件，要复测都需要准备一系列的前提条件。这种时候就省不了，宁可长一点，也要把条件写全。具体怎么写，我在第五章里放了个模板。

日志和数据库

日志是最便宜排除故障的证据。

1是找报错信息，报错信息很多时候就藏在发生故障的原因。2是看时间，出问题的时间点前后三十秒的日志，往往能看到状态发生的变化，有的时候故障原因就在报错的前面。3是看频率，同一个报错，出问题的时候是否有时间规律，还是说是”用户点了一下”之后发生的。

我不会读代码，但我会搜字符串。这两件事的差距，比想象中小。

数据库这个门槛看起来高，但多操作几次，其实就会了。连上数据库、找到表、看那一行。特别是现在有AI协助。

对于异常，最常查的就是三个问题：

1. 这条数据到底有没有？——验证”提示成功”是不是真的
2. 这个字段存的是什么？——验证”界面显示”和”实际存储”是否一致
3. updated_at 数据的更新时间是发生在什么时候？——验证”有没有真的更新”

第三个特别有用，因为它能排除一整类假设。比如界面看着是对的，一查更新时间还是三天前，那就是根本没写进去。

抓请求

浏览器按 F12，进 Network 面板，勾上 Preserve log，然后操作一遍。主要看四样：状态码、请求参数、返回内容、耗时。

经常能遇到的就是前端和后端交接的数据不一致。我记得以前看到过一个梗就是，后端程序员直接把数据库地址扔给前端程序员，并备注”需要什么，自己直接取”。哈哈哈。

有一次我碰到一条报错，英文的，很长：Cannot deserialize value of type ... from Array value。这句本身就是——它想把一包东西变成一个对象，打开一看是个列表。翻译过来就是前端发了一包东西，后端以为里面只有一个，结果打开是一堆。

这种一般直接把报错原文抄上去就够了。研发看到 Array 和 Entity 这两个词，自己知道去哪找。

现场的东西

涉及到硬件设备的情况，有时候也经常需要用到录像，反复对着录像中的设备的运动行为进行对比。

最后一条是我吃了亏才记得带。很多问题爬到机柜后面看一眼就明白了，靠猜能耗一上午。

第三章 怎么把范围缩小

先找一个对照

对照实验是我用得最多、也最能缩小范围的办法。

A 场景出问题。你要找的是：B 场景和 A 场景条件几乎一样，但 B 没问题。

举几个我实际用过的：

下任务那条是我印象最深的。现场反馈点”出发”之后要十几二十秒机器人才动，我的第一反应是网络，医院内网、跨楼层、无线未必好。但”我觉得是网络”不算证据。现场还有消毒机器人，走同一套系统、同一个网络、同一批服务器，我去操作它——也慢，而且进”待执行任务”页面还要等个把分钟。这才把网络排除了。

所以怀疑是环境的时候，就去找一个共用环境、但不共用同一段代码的东西，看它有没有同样的症状。同一个网络下另一台设备、同一个账号下另一个功能、同一份数据在另一个页面，都算。

一次只换一个变量

很多时候做对照，我们依然无法缩小问题范围，那就开始变量测试。一次换一点点变量，看哪种变量情况下问题突然又复现了。

要提醒一句：一次只动一个。有的人换了浏览器、清了缓存、又换了个账号，好了，也不知道是哪一样好的。看起来快，实际上后面还得回头重做一遍。

二分

范围太大的时候用，我们可以用类似那个二分查找的算法思路，来推导发生问题的临界条件在哪里。

版本有顺序：知道上一版是好的，这一版坏了，从中间那个版本试起，好就往后半段找，坏就往前半段找。

模块有顺序：十个模块都报错，先只看公共的那一层。

数据有顺序：一千条里几条导不进去，先导五百条，看坏的在哪一半，再对半切，三次就能缩到一百多条。

长度有顺序：长文本丢字，一半长度试一次，能找到临界点在哪。

没有顺序的东西用不了这招，比如”哪些用户会出问题”，就切不开。

替换

把怀疑的部件整个换掉，看问题跟不跟着走。

换一台设备、换一个账号、换一份数据、换一个网络、换个时间点——问题跟着走到新地方，说明毛病在”跟着走的那个东西”上，不在环境上。

最小复现

把操作路径一条一条删，删到再删就复现不了为止。

比如”点了新增保存之后列表刷新不出来”：完整操作能复现，少填几个字段还能复现，只填必填项还能复现，不进”新增”直接在列表点”编辑”保存也能复现，换个模块的新增就不能复现了。

到这一步，范围就从”整个系统的保存功能”缩到了”这个模块的保存逻辑”。研发不用跟着你的路径走一遍，照最后那三步就能看到问题。

提一个二选一的问题

有时候不用自己做实验，只要问对一个问题，就能把搜索空间对半砍。

问题长这样：如果 A 成立，做 X 会出现现象 P；如果不成立，X 不会出现 P。

提出这个问题的时候，你不需要知道答案。光是把它写出来，研发自己就知道该先试哪边。

别把相关当成因果

我踩过这个坑。

有一次现场某台机器人一直掉线，同时那几天内网在调整。我几乎就认定是网络调整导致的问题了。后来内网调整完，问题还在，进一步排查才发现是那台机器的 IP 跟另一台冲突了。

两件事可能高度相关，不代表必然是一件事导致另一件事。确认的办法就是把这个相关性去掉，看问题还在不在。那次的做法是把机器人接到我们手机搭的局域网里测，内网的因素就排掉了。

第四章 偶现的 Bug

麻烦在没法验收

偶现的 Bug 最麻烦的地方不是难修，是没法验收。

必现的 Bug 修完，照着步骤点一遍，好了就是好了。偶现的 Bug 修完，你只能”再用一段时间看看”。而这段时间里，谁也不知道是真好了还是没撞上。

所以对付偶现的 Bug，第一步不是找原因，是把它变成可以衡量的东西。

把”偶尔”变成数字

不要说”有时候会丢”，要说”连续发 19 条，丢了 4 条，21%”。

有了这个数，就有了验收标准：修好之后连续发 20 条，应该是 0 丢。测出来丢 1 条，就是没修好。

对于这种偶现的Bug，肯定得用上Excel进行统计了。记序号、时间、操作、结果。连着记二十条，规律自己就浮出来了。可能是长度相关，可能是时间间隔相关，可能是某种操作之后。

我的近千个Bug反馈工单中，标了【偶现】的有 81 条，9.1%。这 81 条里，最后能定位到原因的，基本都是当时记了次数、记了时间的那种。

加取证装置，别干等

偶现的问题，等是等不来的。你得让它在发生的时候自己留下东西。

成本最低的是屏幕录像，手机架在那里录一整天，出了就回看。其次是打开控制台，F12 一直开着，出了就能看到红色的报错——很多人出问题的时候控制台是关着的，事后什么都看不到。再就是让程序把日志写进文件，而不是只打到屏幕上，屏幕一刷就没了。

还有一件小事，我吃过很多次亏：记时间点。出问题的时候记下几时几分几秒，不然事后想不起来，日志翻半天翻不到。

出了别急着重启

出了问题的第一反应，不要是”重启试试”，除非你确定这次已经不打算查了。

重启会把现场清掉，内存里的状态、临时文件、进程的异常状态全没了。这时候直接找研发现场查看最佳。即使研发无法来查看，也要尽量留证：截图别只截出错那块，拍一下设备上的指示灯，记时间，有条件把日志导出来，再看一眼是不是所有功能都不行还是个别的。

我见过最可惜的一次，一个”雷达不更新”的问题，重启就好了，然后谁也说不出为什么。如果下次再出现，先别重启，先看进程还在不在、有没有留下崩溃文件，价值完全不一样。

“重启就好了”的那一类

这类问题有它自己的规律：它是状态问题，不是逻辑问题。

逻辑错了，重启也没用，一定会再错。重启能好，说明是某个状态被破坏了——内存涨满了、某个进程死了、某个锁没释放、某个连接断了没重连。

所以遇到这类，不要问”为什么坏了”，要问”什么东西的状态被破坏了”。

它还有一个现实的处置方式：如果查不出根因，就先做到”能自动恢复”。先把重启做成一键的、定时的，保证业务能跑。这不是放弃，这是在”查不出来”和”业务停摆”之间选一个。

第五章 排查、验证、提报

先排查，定位到了再提

我现在的顺序是这样的：

1
2
3
4
5
6
7
8
9

客户反馈"不好用"
    ↓
自己先复现一遍（换设备、换账号、清缓存）
    ↓ 还能复现
缩小范围（对照、二分、替换）
    ↓ 缩到"在什么条件下、哪个环节"
跟研发口头沟通一句，确认这是不是已知问题
    ↓ 不是
才提 Bug

中间那一步”跟研发口头沟通”被跳过的话，很容易漏掉一些情况。例如可能已经是已知在修、或者新版已经修复的问题。

一条 Bug 里写什么

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

【版本】
ROS / 固件 / 应用软件（纯 Web 项目写前端 / 后端 / 数据库脚本）

【环境】
设备型号、操作系统、浏览器、网络环境

【复现步骤】
1、从哪进，点到哪
2、填了什么值、点了什么
3、第几步出问题

【实际结果】
发生了什么。报错原文直接抄，不要转述。

【期望结果】
我认为应该是什么。

【我看到的（实测）】
- 界面上：xxx
- 数据库里：xxx
- 日志里：xxx
- 接口返回：xxx

【我猜的（可忽略）】
可能是 xxx。这条没验证。

【已排除】
- 不是浏览器：换 Chrome / Edge 都一样
- 不是账号：换个账号也一样
- 不是网络：同一个网络下 PC 端正常

【发生次数】
测试 19 次，出现 4 次，约 21%

【附件】
截图、录屏、日志片段、接口返回原文

“我看到的”和”我猜的”分开务必写，这种情况便于让研发了解哪些是你猜的范围，哪些是证据。研发不想关系你猜的范围的时候，直接看现象就行。”我看到的”，那是证据；看”我猜的”，那只是线索，研发可以不理。你也不会因为猜错而显得不专业。

把”慢”写成数字

现场用户说”太慢了””卡””等好久”。这些词没法验收。

我在验收表上见过太多这种表述，最后都变成扯皮。所以尽量换算成数：

一旦变成数字，这件事就从”你觉得快不快”变成了”能不能改、改到多少”。附带的好处是修完之后能验收，原来 6 秒现在 3 秒，达成了没有一眼看得出来。

性能类先说清怎么测的

性能问题最容易扯皮，因为每个人的测法不一样。

我跑过一个吞吐测试，表头是这么设计的：目的是固定时长内 3 个口共同执行入库出库、不混合，另测 4 小时稳定性、可混合；测的是平均每个周转箱出入库用时、平均整库每箱用时、单小时箱数估算；记的是开始时间、结束或故障时间、任务用时、数量、优化点、对应 Bug 号。

最后那列”对应 Bug 号”最有用。跑完一轮，哪个环节拖后腿、拖了多少、是不是已经被记录过，一眼就能对上。

同时跑几个口、跑多久、任务混不混、数据量多大、环境是不是同一个，这几个也得写进报告。不写这些，两个人数出来的数没法比。

能做和不必做的

我把排查这件事分成几层，看看自己在哪一层，比空想着”我要变专业”实在。

L0 到 L2 我都能做，L3 靠搜索和 AI 也做得到，L4 我不做。

不做 L4 不是能力问题，是分工问题。我在第 3 个观念里说过，不懂就别指挥。你猜错的根因会把研发带进死胡同，比他重新看一遍代码慢得多。

最后

虽然我不是专业做测试的。但排查问题有时候让人做起来挺有趣的。但有时候也很烦人。

记录了下以前排查问题的这些思路想法，算是经验之谈了。