面试官问你们接口自动化里怎么处理 302 跳转我当时的回答是关掉自动重定向然后就没有下文了。对方接着追问那 302 和 307 在重定向时对请求体的处理有什么区别你们的用例为什么选这个而不是那个那一刻我才意识到应用层这块知识在测试开发面试里根本不是背几个协议名能糊过去的它考的是你能不能把协议细节翻译成用例设计。上一篇把应用层的基础协议过了一遍HTTP、HTTPS、DNS、FTP、邮件协议的名词解释和端口列表都摆在那儿了。但真正坐在面试桌对面或者在工位上排查一个明明代码没问题但就是报错的问题时光知道端口号远远不够。这一篇补的就是这些东西报文字段级的细节、握手链路上的异常点、非 HTTP 协议在测试场景里的特殊表现以及怎么把协议知识落成抓包、Mock、断言这三样可交付的产物。不管你是刚开始准备测开面试还是已经做了两三年接口测试但总觉得知其然不知其所以然下面的内容应该都能对上号。1. 应用层在测开面试里的真实权重1.1 面试官追问应用层时究竟在筛什么传输层和网络层的知识面试官问起来大多停在TCP 三次握手为什么不是两次TIME_WAIT 太多怎么处理这类有标准答案的题目上答对答错都很快能判断。应用层不一样它离业务最近同一道题往下挖三层候选人的真实水平就藏不住了。第一层是名词层HTTP 默认端口、HTTPS 用的是什么、DNS 走 UDP 还是 TCP。这一层筛掉的是完全没准备的人答不上来基本就结束了。第二层是报文层一个请求发出去请求行长什么样首部字段有哪些消息体用什么编码。这一层筛掉的是只会用工具点一点的人。很多人做了一年接口测试从来没打开过原始报文看过Postman 里勾勾选选就把请求发出去了一旦遇到服务端说你的 Content-Type 不对就只会反复试。第三层是验证层如果某个字段改了会怎样怎么构造这个场景出了问题怎么定位到是应用层还是下面几层。这一层才真正区分会测和能设计测试。比如问 DNS第一层问端口 53第二层问 A 记录和 CNAME 的区别第三层就会问线上偶发首包耗时 3 秒以上你怎么判断是不是域名解析的问题这个问题没有标准答案但答得好不好一听就知道。我在准备复习的时候给自己定了个判断标准任何一个应用层协议如果我说不出它在什么情况下会慢、会错、会被中间设备改掉那这个协议我就没算学会。这套标准后来在面试里救了我好几次。1.2 一份自测清单应用层该复习到什么颗粒度光说要深入太虚下面这张表是我自己复习时用的颗粒度清单左列是协议中间是必须能脱口而出的点右列是面试里最容易被追问到底的方向。你可以拿它当检查表哪一行卡壳了就回去补哪一行。协议必须掌握高频追问方向HTTP/1.1报文三段结构、方法语义、状态码分类、连接复用幂等性怎么测、304 是怎么产生的、Connection 头的作用HTTP/2、HTTP/3多路复用、头部压缩、QUIC 基于 UDP多路复用下怎么定位单个流的慢请求HTTPS/TLS握手轮次、证书链、SNI、ALPN自签证书为什么在测试环境报错、抓不到明文怎么排查DNS记录类型、递归与迭代、TTL灰度切换后流量还打旧机器、首包慢怎么归因DHCP四步交互、租约、地址池测试机自己改了静态 IP 导致冲突邮件协议SMTP 发、POP3 收、IMAP 同步附件编码、中文主题乱码FTP主动模式与被动模式的端口差异NAT 环境下传不上去WebSocketUpgrade 握手、帧、心跳、关闭码断线重连怎么测、鉴权放在哪一步gRPCHTTP/2 承载、Protobuf 序列化、四种流式状态码在 trailer 里怎么断言MQTT发布订阅、QoS 三档、遗嘱与保留消息QoS1 重复投递怎么处理NTP层级、偏移、时钟回拨时间不同步导致的签名校验失败这张表不是让你背是让你知道自己缺哪块。我当时填这张表发现自己对 FTP 和 SNMP 几乎是空白对 gRPC 只停留在听说过的程度后来专门补了两天。补的时候不是为了面试是因为那段时间正好在做一个长连接推送的测试不补根本推进不下去。2. HTTP报文拆到字段级用例才写得出来2.1 一行请求行里藏着三个测试点请求行就三部分方法、请求目标、协议版本比如POST /api/v1/orders?fromweb HTTP/1.1。看起来很朴素但我见过太多用例就死在三个不起眼的地方。第一是方法语义和幂等性。GET、HEAD、PUT、DELETE 在语义上是幂等的POST 不是。这个知识点的价值不在于背定义而在于它能直接指导用例设计对幂等方法重复调用之后的资源状态应该和调用一次一致这就可以写一条重复提交校验的用例对非幂等方法重复调用会创建多条记录那就得写重复提交防护的用例比如前端按钮置灰、后端 token 去重、数据库唯一索引。面试里被问到你怎么测接口幂等如果只答多调几次看结果一样不一样那就太浅了得说清楚幂等键放在哪、重复请求返回什么、状态码是 200 还是 409。第二是请求目标里的查询串。?后面的部分在服务端解析时很容易出问题参数重复出现时取第一个还是最后一个、空值传a和完全不传a是不是一个意思、特殊字符有没有做百分号编码、号在查询串里到底代表空格还是加号。这几个点在测试里全是现成的用例。我自己就踩过一次一个搜索接口在页面里搜C传过去变成了C 因为被按查询串规则解码成了空格最后是靠百分号编码%2B才解决。第三是协议版本。HTTP/1.0 默认短连接HTTP/1.1 默认长连接这个差别会直接影响压测结果。同一套脚本如果服务端对 HTTP/1.0 的请求每次都关连接QPS 会掉一大截而你在压测报告里看到的是响应时间变长了很容易误判成服务端性能问题。2.2 状态码按责任方分类记忆背状态码列表是效率最低的方式我自己的做法是按出问题时先查哪一侧来分类。这样记的好处是线上看到一个状态码脑子里第一反应不是这是什么意思而是我该去哪儿看日志。状态码语义先查哪一侧测试里的典型场景400请求语法或参数不合法用例数据字段类型传错、JSON 格式坏掉401未认证或凭证失效鉴权链路token 过期、签名时间戳超窗403已认证但无权限权限配置越权访问、角色未绑定404资源不存在路由与 ID路径拼错、软删数据仍被查405方法不被允许用例方法本该 POST 写成 GET409状态冲突并发与重复提交库存扣减并发、重复下单413请求体过大客户端与网关限制附件上传边界值429触发限流脚本并发配置压测时没配限流白名单500服务端未捕获异常服务日志堆栈空指针、类型转换失败502网关拿到无效上游响应上游存活与端口服务刚重启、端口未监听503服务暂不可用熔断与线程池依赖降级、连接池打满504网关等待上游超时上游耗时慢查询、下游级联超时这里有个特别值得说的点502 和 504 经常被混为一谈但排查路径完全不同。502 是网关连上了上游但拿到的响应不合法或者根本连不上属于上游活着吗的问题504 是网关等太久了主动放弃属于上游太慢的问题。线上看到 502先 ping 端口、看进程看到 504先看慢日志和链路耗时。这个区分在面试里说出来对方基本能判断你是真排查过。还有一个容易被忽略的304。它不是错误是协商缓存命中。304 的响应里没有消息体如果自动化用例的断言里写了响应体不为空这条用例就会莫名其妙挂掉。我见过一个团队为了解决这个问题把所有 GET 请求都加了个随机参数来绕过缓存结果把缓存本身的正确性彻底测不到了这是典型的用错误方法掩盖问题。2.3 首部字段的冲突组合最容易出事故单个首部字段的含义查文档就有真正出事故的是组合。我把遇到过的几类整理一下都是可以直接变成用例的。Content-Length和Transfer-Encoding: chunked同时出现是最经典的一类。这两个首部都在描述消息体边界但描述方式不同。不同的网关、不同的服务端框架在处理这种报文时可能选择不同的判定依据结果就是请求体被切错位置后面的内容被当成新的请求解析。测试的做法是专门构造这种报文打给网关观察它接受还是拒绝、拒绝时返回什么状态码。合规的网关应该直接返回 400如果它默默接受了那就说明解析策略存在歧义这在联调环境里是必须记录的风险项。Host缺失或被改写是第二类。HTTP/1.1 强制要求带 Host缺了就是 400。但在多租户或者多域名共用一套后端的环境里Host 决定了路由到哪个虚拟主机。测试环境的域名和后端的 server_name 不一致时经常会出现请求发出去了返回的是默认站点的页面看起来像 404其实是 Host 匹配失败。Connection和中间设备的空闲超时是第三类也是最难查的。客户端以为长连接一直有效但中间的负载均衡或者网关配了 60 秒空闲就断第 61 秒客户端还往这条连接上写数据就会拿到一个 RST 或者干脆卡住。这类问题的表现是偶发超时重试就好了如果不抓包几乎定位不到。我在一个项目里遇到过花了整整一天才确认是网关的空闲超时比客户端的连接池保活时间短最后把客户端保活间隔调到 30 秒才稳定下来。Cookie上的SameSite、Secure、HttpOnly三个属性也值得单独过一遍。HttpOnly意味着前端脚本读不到如果你的自动化用例是靠前端脚本取 cookie 传给接口的那遇到HttpOnly就直接断了得改成从响应头的Set-Cookie里解析。SameSiteLax则会影响跨站请求带不带 cookie跨域场景下的登录态测试必须考虑这一条。3. HTTPS 与证书测试环境里最经典的玄学报错3.1 握手过程压缩成三句话TLS 握手细节能讲半小时但面试和工作里真正用得上的其实可以压缩成三句话。第一句客户端先发 ClientHello里面带上自己支持的协议版本、加密套件列表、一个随机数以及 SNI——也就是它想访问的域名。SNI 这一项特别关键因为一个 IP 上可能挂了很多个域名服务端靠它决定返回哪张证书。抓包里如果看到 ClientHello 里的 SNI 是空的而服务端又确实配了多张证书那基本就能确定问题出在客户端没带 SNI。第二句服务端回 ServerHello 加上证书链双方通过密钥交换算法协商出会话密钥。TLS 1.2 需要两个往返TLS 1.3 压缩到一个往返而且把密钥交换也塞进了 Hello 消息里。这个差别的实际意义是TLS 1.3 的首包耗时明显更低如果你的接口测试关注首包时间那 TLS 版本就是一个必须固定的变量。第三句握手完成后双方各自发 Finished 校验之后才是加密的应用数据。所以你在抓包里看到的第一个 HTTP 请求永远在 TLS 握手之后。还有一个细节值得单独提ALPN。客户端在 ClientHello 里会声明自己支持的应用层协议比如 h2 和 http/1.1服务端选一个回过去。如果客户端声明支持 h2 但服务端只认 http/1.1协商会降级如果两边声明不匹配又都不肯让步握手直接失败。这类问题在做协议升级测试时很常见表现是浏览器能打开命令行工具打不开因为两者的 ALPN 声明不一样。3.2 证书校验失败的五种成因和排查顺序测试环境里最常见的一类报错就是证书相关报错信息五花八门但成因基本就那么几种。我按排查成本从低到高排个序照着走一遍基本能定位。第一种系统时间不对。证书有生效时间和过期时间服务器或客户端的时钟偏出去几个月证书就直接判定无效。这个排查成本最低一条date命令就能确认。虚拟机挂起之后恢复、容器基础镜像时间没同步都会导致这个问题。第二种域名不匹配。证书的 SAN 字段里必须包含你实际访问的域名。这里有两个坑一是通配符证书*.example.test只匹配一级子域a.b.example.test就匹配不上二是访问时用的是 IP 而不是域名而证书里只有域名那必然失败。第三种证书链不完整。服务端只配了叶子证书没把中间证书一起发过来客户端本地又没有缓存过这个中间证书链就断了。判断方法很直接用命令行工具连上去把证书链打出来看有几张正常应该是叶子、中间、根根有时可以不带客户端本地有。这类问题在用自建证书的内网环境里特别常见。第四种信任根缺失。自签证书或者内部 CA 签的证书客户端默认不信任。解决办法要么把根证书导入信任库要么在测试客户端上显式指定 CA 文件。生产环境千万别用关闭校验这一招测试环境偶尔为了方便可以但要在用例里明确标注这是个临时手段。第五种吊销状态检查阻塞。有些客户端会去查证书吊销状态如果这个查询地址不可达可能会一直等到超时表现就是连接特别慢最后失败。这类问题最隐蔽因为证书本身完全合法。排查的时候我习惯用两条命令打头阵先看服务端到底发了什么# 看握手过程和证书链 openssl s_client -connect api.example.test:443 \ -servername api.example.test -showcerts /dev/null # 看详细的请求响应头确认协议版本和重定向 curl -vI https://api.example.test/health第一条命令里-servername参数千万别省省了就不发 SNI多域名环境下拿到的可能是默认证书你会误判成证书配错了。3.3 抓不到明文时的分层定位思路HTTPS 抓包看不到内容很多人的第一反应是装个证书就行了。但装证书这件事本身就会改变客户端的信任链可能把真实问题掩盖掉。我的做法是先分层定位确认问题到底在哪一层再决定要不要解密。先看 TCP 层连接建起来了吗有没有 RST有没有大量重传如果 TCP 层就不干净那跟 TLS 一点关系都没有。再看 TLS 层握手完成了吗ClientHello 发出去之后有没有 ServerHello 回来如果没有可能是端口不通、可能是服务端不支持客户端声明的版本、也可能是中间设备直接拦了。如果握手完成了但很快收到一个 alert那就去看 alert 的类型不同的 alert 对应不同的失败原因。最后才看应用层确实需要看明文再考虑在测试客户端上配置解密。这时候要注意解密只对你能控制的客户端有效服务端之间的流量是解不了的。这个分层思路在面试里答出来比直接说我用抓包工具要有分量得多因为它体现的是归因方法而不是工具熟练度。4. DNS、DHCP、NTP三个不显眼但要命的基础协议4.1 DNS 的递归与迭代以及三个高频坑DNS 查询分两种模式这个概念面试里问得不少但很多人答得含糊。简单说递归是你帮我查到底给我最终答案迭代是你告诉我下一步该问谁我自己去问。客户端发给本地 DNS 服务器的通常是递归查询本地 DNS 服务器去问根、问顶级域、问权威服务器这个过程是迭代的。记录类型里最常用的几个A 记录给 IPv4AAAA 给 IPv6CNAME 是别名MX 是邮件服务器TXT 常用来做域名验证NS 是权威服务器PTR 是反向解析。测试里最常打交道的是 A、CNAME 和 TXT。坑一本地 hosts 覆盖。开发或者测试为了图方便在 hosts 文件里把域名指到某台机器上过两天忘了删结果所有请求都打到那台机器。表现是代码明明改了但行为没变查半天查不到。我现在的习惯是遇到改了没生效的问题第一个动作就是看 hosts。坑二TTL 缓存导致切换延迟。做灰度或者机房切换的时候把 DNS 记录改了但因为各级缓存还留着旧记录一部分流量仍然打到旧地址。这个不是故障是设计使然。测试这类场景要明确 TTL 设了多久并且要在切换后观察足够长的时间窗口别一看还有旧流量就判定失败。坑三CNAME 链过长或者解析超时导致首包慢。CNAME 套 CNAME每多一层就多一次查询链太长的时候解析耗时会明显上升。这类问题的表现是接口本身很快但整体耗时高如果只看服务端日志是看不出来的必须在客户端侧计时把 DNS 耗时和连接耗时分开统计。验证解析链路最直接的办法是加 trace# 从根开始逐级追踪解析过程 dig api.example.test A trace # 指定某个 DNS 服务器查询对比不同服务器的返回 dig 203.0.113.53 api.example.test A short第二条命令里的 IP 用的是文档专用地址段实际用的时候换成你们环境里的 DNS 服务器地址就行。对比不同服务器的返回能快速判断是权威记录配错了还是某级缓存没刷新。4.2 DHCP 四步交互与地址冲突DHCP 的四步交互是 Discover、Offer、Request、Ack这个顺序面试里问得很多。客户端广播找服务器服务器回一个可分配的地址客户端再广播确认要哪个服务器最后确认。后面还有 Release 释放和 Nak 拒绝但核心就是这四步。这套机制在测试环境里的价值在于排查机器上不了网的问题。测试机拿不到地址先看是不是地址池满了再看是不是有人手工配了静态 IP 撞了。静态 IP 和 DHCP 分配的地址冲突是很常见的因为管理员配静态地址的时候不会去查 DHCP 的租约表。有些 DHCP 服务器在分配前会做一次地址探测如果发现这个地址有人在用就换一个这个机制叫冲突检测可以配但很多环境没开。还有一个场景是测试环境的机器频繁创建销毁。容器或者虚拟机批量起来的时候短时间内大量 DHCP 请求地址池容易被瞬间耗尽表现是部分机器起来后网络不通。这类问题在压测准备阶段特别容易遇到提前把地址池大小和租约时间算一遍能省很多事。4.3 NTP 时间漂移引发的连锁失败NTP 平时没人关注但它出问题的时候表现极其玄学。我遇到过一台上游服务的时间比标准时间慢了五分钟结果所有经过它的签名校验全部失败报错信息是签名无效查了整整一个下午才发现是时钟问题。时间偏差会导致哪几类故障第一类是带时间戳的签名和令牌偏差超过允许窗口就判定过期或者未生效。第二类是定时任务时钟回拨可能导致同一个任务被执行两次或者干脆跳过。第三类是日志排查多台机器时间不一致你按时间线拼出来的调用链完全是错的。第四类是分布式锁和缓存过期依赖时间的机制在时钟跳变时行为不可预测。NTP 本身是有层级的stratum 0 是基准时钟往下逐级同步。层级越高精度越差。测试环境里常见的问题是所有机器都指同一个内网时间源如果这个源本身不准那全环境一起错。我的做法是在自动化用例的公共前置里加一条时间偏差检查超过阈值直接失败比事后一个个查要省时间得多。5. 非 HTTP 协议族从邮件到消息推送的测试差异5.1 邮件协议的分工与编码坑SMTP 负责发POP3 和 IMAP 负责收这个分工很多人知道但后面的差别就不一定说得清了。POP3 的典型行为是把邮件下载到本地并从服务器删除适合单设备IMAP 是双向同步客户端的已读、删除、文件夹操作都会同步回服务器适合多设备。测试邮件相关功能时真正麻烦的不是协议本身是编码。邮件主题里的中文要用特定编码方式包裹附件要用 base64 或者 quoted-printable正文可能是纯文本、HTML 或者 multipart 混合。这几个东西任何一个处理不好用户看到的就是一堆乱码或者一个打不开的附件。我测过的坑里最典型的是长主题折行。邮件头有长度限制太长的主题会被折成多行每行末尾加一个标记表示下一行还是同一行。如果解析代码没处理这个折行主题就会被截断。还有附件文件名中文文件名在不同客户端下可能变成乱码因为编码方式不统一。这些细节在接口层面测不到必须真的发一封邮件、真的用客户端收下来看。5.2 FTP 主动与被动模式的端口差异FTP 用两个连接控制连接走 21 端口数据连接单独开。主动模式下服务端从自己的 20 端口主动回连客户端指定的端口被动模式下服务端开一个随机端口告诉客户端让客户端来连。这个差别在测试环境里的意义非常实际。客户端在 NAT 后面的时候主动模式基本用不了因为服务端回连的地址是内网地址根本连不到。所以现在默认都用被动模式。但被动模式也有坑服务端随机开的端口范围如果没在防火墙上放行数据连接就建不起来表现是能登录、能列目录、但传文件卡住。这个能登录但传不了文件的现象是 FTP 问题的典型特征因为控制连接和数据连接走的是不同的端口和方向。遇到这类问题先确认模式再确认端口范围基本就能定位。5.3 WebSocket、gRPC、MQTT 的测试手法差异这三个协议都属于长连接或者非请求响应的范畴测试思路和普通 HTTP 接口差别很大。我把关键差异列成表维度WebSocketgRPCMQTT承载先 HTTP Upgrade 再切协议HTTP/2 承载自有协议数据格式文本或二进制帧Protobuf 二进制自定义负载交互模式双向随时发一元、服务端流、客户端流、双向流发布订阅鉴权位置握手阶段带上凭证元数据里的 token连接时的用户名密码或证书断言重点帧内容、顺序、关闭码trailer 里的业务状态投递次数、顺序、离线堆积典型问题断线重连、代理不支持 Upgrade状态码在 trailer 里被漏断言QoS1 重复投递导致业务重复处理WebSocket 的握手是借 HTTP 完成的请求头里带Upgrade: websocket和一对随机的 key服务端返回 101 和计算后的 accept 值。测试的时候握手阶段能不能带鉴权信息是个关键点因为很多实现把 token 放在 URL 参数里这会带来日志泄露的风险。另外断线重连必须专门测包括网络闪断、服务端主动踢下线、长时间无数据被中间设备断开这几种情况重连之后消息有没有丢、顺序有没有乱都得覆盖。gRPC 最容易踩的坑是断言。因为 gRPC 的业务状态码不在 HTTP 状态码里而是在 trailer 里HTTP 层永远是 200。如果自动化框架只看 HTTP 状态码那所有业务错误都会被判成通过。这个坑我踩过一次一批用例全绿上线才发现错误处理逻辑根本没生效。MQTT 的核心测试点在 QoS。QoS 0 最多一次可能丢QoS 1 至少一次可能重复QoS 2 恰好一次开销最大。测 QoS 1 的时候必须验证业务侧有没有做去重否则同一条消息处理两次库存就扣两次。另外遗嘱消息和保留消息也要单独测遗嘱是客户端异常断开时由服务端代发的保留消息是新订阅者一连上就能收到的那条。6. 把协议知识落成测试产出抓包、Mock、断言6.1 抓包过滤表达式速查抓包工具本身不是重点重点是你能不能在三秒内把无关流量过滤掉。全量抓包然后靠肉眼翻效率低到不可接受。下面这些过滤表达式是我常用的直接抄就行。想看什么过滤表达式某个域名的 HTTP 请求http.host contains api.example.test只看 POST 请求http.request.method POST某个状态码http.response.code 502DNS 查询dns.qry.name contains example.testTLS 握手里的 SNItls.handshake.extensions_server_name api.example.test指定端口tcp.port 8443TCP 重传tcp.analysis.retransmission连接被重置tcp.flags.reset 1握手失败告警tls.alert_message有两个使用习惯值得说。一是先抓小窗口再放大别一上来就抓几万个包先抓十秒、先按主机过滤定位到大致范围再放开。二是抓包文件要留时间戳和场景标签我见过太多抓了但不知道是什么时候抓的的包等于白抓。6.2 Mock 服务的分层设计很多人理解的 Mock 就是返回一个假的 JSON这个理解太浅。真正好用的 Mock 是分层的不同层解决不同问题。最底层是传输层替换改 hosts 或者起一个本地端口把请求引到自己的服务上。这一层解决的是目标服务还没好的问题优点是接入成本极低缺点是只能整体替换没法精细控制。往上一层是协议层 Mock自己起一个 HTTP 服务能控制状态码、响应头、延迟、响应体大小、甚至故意返回半截然后断开。这一层解决的是异常场景构造不出来的问题。比如要测客户端对 504 的处理真实环境里很难稳定复现但 Mock 服务里加个 sleep 就能稳定复现。再往上是业务层 Mock针对第三方依赖打桩返回预制数据集。这一层的关键是数据集要覆盖正常、边界、异常三类不能只准备一份标准成功响应。我一般会准备至少五份正常、空数据、字段缺失、类型错误、超长内容。最高一层是故障注入包括延迟、超时、连接复用异常、响应体截断、编码错误。这一层测的是客户端的健壮性也是最容易漏测的部分。故障注入做得好很多线上问题在测试阶段就能暴露。这四层不是必须全做但至少要有协议层和业务层否则用例的覆盖面会很窄。6.3 四层断言模型从状态码到业务语义断言写得好不好直接决定用例有没有价值。我总结了一个四层模型按覆盖深度递进。第一层是传输层断言状态码、响应时间、协议版本、响应头里的关键字段。这一层最基础但也是最容易被写死的。比如把响应时间阈值写死成 500 毫秒换台机器跑就全挂了。这类断言要留余量或者改成相对比较。第二层是结构层断言字段是否存在、类型是否正确、必填项是否齐全、数组长度是否在范围内。这一层用 schema 校验比逐字段断言效率高得多而且新增字段不会导致用例失败。第三层是语义层断言业务状态码是不是预期值、金额精度对不对、时间格式是不是约定的格式、枚举值是不是在允许集合里。这一层才是真正验证业务的前面两层只是保证能解析。第四层是行为层断言幂等性、重试后的最终状态、并发下的数据一致性、消息顺序。这一层最难写但价值最高因为它测的是系统在真实压力下的行为。我见过不少团队的用例只做到第一层和第二层结果就是用例全绿但线上照样出问题。补断言这件事的投入产出比其实很高加一条幂等断言可能只要十分钟但能挡住一类线上事故。7. 几个我反复踩过的坑和怎么绕开7.1 长连接被中间设备悄悄掐断这个坑我在三个不同的项目里遇到过。客户端建了连接池服务端也没问题但中间的网关或者负载均衡配了空闲超时比客户端的保活间隔短。结果就是连接看起来还在写进去的数据石沉大海。判断方法是在客户端和服务端同时抓包对比时间线客户端认为连接还在的时间点之后服务端有没有收到数据。如果没有那就是中间断了。绕开的办法不是把超时调大而是让客户端的保活间隔小于中间设备的空闲超时。中间设备的超时通常是运维配置的你得先去问清楚是多少再定客户端的参数。这个先问清楚再定参数的顺序很重要我见过有人凭感觉把保活设成 30 秒结果中间设备的超时是 15 秒照样断。7.2 重定向和鉴权头的配合302 跳转的时候浏览器会怎么处理 Authorization 头答案是看情况不同实现不一样而且跨域的时候通常会丢掉。如果你的自动化用例依赖重定向后仍然带着凭证那大概率会失败。我的建议是自动化用例里一律关闭自动重定向自己手动跟随每一步都显式带上需要的头。这样虽然麻烦一点但行为可控出问题也好定位。生产环境里更要避免依赖重定向传递敏感头用一次性的跳转票据代替。7.3 缓存头配错导致测试互相污染测试环境里如果开了缓存前一条用例写入的数据可能被后一条用例读到旧值表现就是用例单独跑都过一起跑就挂。这类问题的根源往往是缓存头没配对或者 CDN 层缓存了本不该缓存的响应。绕开的办法有两个方向一是在测试请求里带上绕过缓存的标记让服务端返回最新数据二是在用例设计上保证数据隔离每条用例用独立的数据标识。前者见效快但治标后者麻烦但治本。我倾向于两条都做先用前者保证用例稳定再慢慢把数据隔离补上。7.4 时间相关的用例不能靠 sleep用固定 sleep 等待异步结果是所有测试里最脆弱的写法。机器快一点就白等机器慢一点就失败。正确做法是轮询加重试上限同时监控轮询次数次数异常高说明系统本身有问题不该靠调大重试次数掩盖。还有一个和时间相关的细节断言里如果涉及当前时间一定要用服务端返回的时间做基准不要用本地时间。两端时钟只要差几秒跨天的用例就会失败而且失败信息看起来毫无道理。我个人在实际操作中的体会是应用层这块知识最容易陷入看懂了但用不上的状态。看文档的时候每条都明白真到了要设计用例、要定位问题的时候脑子里却调不出来。后来我改了个方法每学一个协议就强迫自己回答三个问题——它在什么情况下会慢、在什么情况下会错、在什么情况下会被中间设备改掉。这三个问题回答得出来这个协议才算真的进了脑子。比如 HTTP 的会被改掉答案就是各种代理会加上或剥离X-Forwarded-For、会改写Connection、会压缩或者重新编码响应体DNS 的会慢答案就是递归链路长、CNAME 套太多层、缓存没命中。这些答案不是为了背给面试官听的是为了你在工位上看到异常现象时能立刻想到该去哪儿看一眼。最后再分享一个小技巧复习到某个协议卡住的时候别急着去搜XX 协议详解先打开抓包工具自己发一个请求把报文一层层展开看。原始报文里能看出来的东西比任何教程都直观。看完了再回去读文档理解速度会完全不一样。