软件测试中的网络问题

1.背景

在测试过程中，出现的问题，除了代码问题，还有很多的网络问题，所以需要了解网络知识，这样能发现网络问题，尽快解决就能提高效率。

2.计算机网络体系结构

OSI七层模型：物理层，数据链路层，网络层，传输层，会话层，表示层，应用层。

OSI七层模型只是理想的，实际实现的只有4层。

3.TCP/IP协议（传输控制协议/因特网互联协议）

由网络层的IP协议和传输层的TCP协议组成，协议采用了4层的层级结构，也就是说实际上实现了链路层，网络层，传输层，应用层。

测试的过程中我们重点关注的是网络层和应用层。网络层IP，应用层HTTP，DNS是我们接触到最多的。

4.应用层协议（简单了解）

• TFTP（Trivial File Transfer Protocol,简单文件传输协议）
  用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务。端口号为69。TFTP是一个传输文件的简单协议，它基于UDP协议而实现，但是我们也不能确定有些TFTP协议是基于其它传输协议完成的。此协议设计的时候是进行小文件传输的。比如当需要将程序或者文件同时向许多机器下载时就往往需要使用到TFTP协议。

• HTTP（Hyper Text Transfer Protocol，超文本传输协议）
  是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出；而 [9] 消息内容则具有一个类似MIME的格式。

• SNMP(Simple Network Management Protocol，简单网络管理协议）
  SNMP 使网络管理员能够管理网络效能，发现并解决网络问题以及规划网络增长。通过 SNMP 接收随机消息（及事件报告）网络管理系统获知网络出现问题。SNMP是管理进程（NMS）和代理进程（Agent）之间的通信协议。

• FTP（File Transfer Protocol，文件传输协议）
  FTP允许用户以文件操作的方式（如文件的增、删、改、查、传送等）与另一主机相互通信，使用TCP传输。然而， 用户并不真正登录到自己想要存取的计算机上面而成为完全用户， 可用FTP程序访问远程资源， 实现用户往返传输文件、目录管理以及访问电子邮件等等， 即使双方计算机可能配有不同的操作系统和文件存储方式。比如，在大学时期，老师会在他自己的电脑建一个ftp，然后将ftp地址给学生，让学生将作业上传到ftp，老师就可以批阅。

• SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）
  SMTP是一种提供可靠且有效的电子邮件传输的协议。SMTP是建立在FTP文件传输服务上的一种邮件服务，主要用于系统之间的邮件信息传递，并提供有关来信的通知。

• DNS（Domain Name System，域名系统）
  它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用UDP端口53。当前，对于每一级域名长度的限制是63个字符，域名总长度则不能超过253个字符。比如访问www.baidu.com，这是个域名，方便人们记忆，实际映射的是一个ip，IP不便于人们记忆。

• Telnet
  是Internet远程登录服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的能力。在终端使用者的电脑上使用telnet程序，用它连接到服务器。终端使用者可以在telnet程序中输入命令，这些命令会在服务器上运行，就像直接在服务器的控制台上输入一样。可以在本地就能控制服务器。要开始一个telnet会话，必须输入用户名和密码来登录服务器。Telnet是常用的远程控制Web服务器的方法。

应用层的这些协议没有谁更厉害，只是在不同的场景使用不同的协议，就像有的护肤品适合干性皮肤，有的适合油性皮肤。

5.传输层协议（理解端口号）

• TCP
  是面向连接的、可靠的流协议，通过三次握手建立连接，通讯完成时要拆除连接。

• UDP
  是面向无连接的通讯协议，UDP通讯时不需要接收方确认，属于不可靠的传输，可能会出现丢包现象。

TFTP协议使用的UDP传输，HTTP，FTP，SMTP使用TCP传输。
传输层是通过端口号，端口号用来识别同一台计算机中进行通信的不同应用程序。因此，它也被称为程序地址。
通俗来说，端口号表示计算机里面的一个app，由于计算机里面有很多app，那服务器要把信息传给哪个app呢，就是通过端口号识别的，我们把每个app都设置一个端口号。

下面的图是重点记住的知识点

6.网络层协议（简单了解）

• IP（Internet Protocol，网际互连协议）
  它可以向传输层提供各种协议的信息，例如TCP、UDP等；对下可将IP信息包放到链路层，通过以太网、令牌环网络等各种技术来传送。
• ICMP（Internet Control Message Protocol，=控制报文协议）
  用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。
• RIP（Routing Information Protocol，路由信息协议）
  是基于距离矢量算法的路由协议，利用跳数来作为计量标准。在带宽、配置和管理方面要求较低，主要适合于规模较小的网络中。
• OSPF（Open Shortest Path First，路由协议）
  OSPF适合在大范围的网络：OSPF协议当中对于路由的跳数，它是没有限制的，所以OSPF协议能用在许多场合，同时也支持更加广泛的网络规模。只要是在组播的网络中，OSPF协议能够支持数十台路由器一起运作。

7.三次握手和四次挥手

• 客户端与服务端传输数据—三次握手
  首先要连接起来，然后再传数据。
  

《三次握手》的故事：
客户端：服务器，我有请求的能力，可以连接吗？（伸手）
服务器端：客户，我有接收消息和回复的能力，快来连上。（伸手）
客户端：好勒，连上成功。（握手）
传输层的TCP协议需要三次握手。

问：为什么是三次握手，不是二次握手或四次握手呢？

在TCP协议中，三次握手在可靠性和效率之间取得了平衡，而二次握手无法保证可靠性，四次握手则增加了不必要的开销。
1.二次握手的问题
无法确认服务端的接受能力：二次握手只能确认客户端的发送能力和服务端的接受能力，但无法确认服务端的发送能力和客户端的接收能力。这可能导致连接不可靠。
重复连接请求：如果客户端的SYN包延迟到达，服务端可能会误以为是新的连接请求，导致重复连接。
2.四次握手的冗余
效率低下：四次握手会增加额外的通信开销，而三次握手已经足够确保双方的发送和接受能力，四次握手显得多余。
不必要的延迟：多一次握手会增加连接建立的延迟，影响性能。

• 客户端与服务端断开联系—四次挥手
  

《四次挥手》的故事：
旁白：客户端和服务端信息交流结束，到了要分开的时候了。
客户端：服务器，我走了，可以吗？（示意挥手）
服务器端：你等我一下，我还没忙完。（示意稍等）
旁白：一会儿，服务器端忙完，于是去告诉客户端。
服务器端：我忙完了，你走吧，我先下线了。（示意挥手并收回手）
客户端：好的，那我走了。（示意挥手并收回手）
客户端等了一会儿消息，由于服务器下线了，没有回复客户端，于是客户端也下线了。

问：为什么是四次挥手，不是三次挥手呢？

四次挥手确保了数据传输的完整性和连接的可靠关闭，而三次挥手可能导致数据丢失，五次挥手则增加了不必要的复杂性。
1.三次挥手的问题
数据丢失风险：在三次挥手中，客户端发送FIN包后，服务端可能仍有数据需要发送。如果服务器在发送完数据前就关闭连接，可能导致数据丢失。
无法确认服务端的数据发送完毕：三次挥手无法确保服务端在关闭连接前完成所有数据的发送和确认。
2.五次挥手的冗余
不必要的复杂行：四次挥手已经能够确保双方都完成数据发送和接收，五次挥手会增加额外的步骤，带来不必要的复杂性。
效率低下：多一次挥手会增加连接关闭的延迟，影响性能。

这个请求头里面的字段Connection: keep-alive。意思就是保持客户端和服务器端连接，不要断开，否则，服务器在一段时间没有得到请求，就会断开，用户再操作的时候又要建立连接。

8.TCP/IP中的数据包

TCP首部：源IP端口号，目标IP端口号。
IP首部：源IP地址，目标IP地址，传输协议TCP
以太网包首部：里面有MAC地址，每台手机或电脑都有MAC地址来标识。查询手机电脑的MAC地址方法

场景：用户A给用户B发送信息

9.HTTP请求

• HTTP请求的传输过程。

1. 浏览器输入

2. DNS解析：客户端将域名解析为IP地址
   客户端检查本地DNS缓存
   如果缓存中没有，客户端向DNS服务器发送查询请求
   DNS服务器返回对应的IP地址

3. 建立TCP连接：客户端与服务器通过TCP协议建立连接
   客户端向服务器发送SYN包
   服务器响应SYN-ACK包
   客户端发送ACK包，完成三次握手，建立TCP连接

4. 发送HTTP请求：客户端通过已建立的TCP连接发送HTTP请求
   客户端构造HTTP请求报文，包括请求行（方法、URL、协议版本）、请求头（如host、User-Agent等）和请求体（如POST数据）
   客户端将请求报文发送到服务器。

5. 服务器处理请求：服务器接收并处理HTTP请求
   服务器解析请求报文，确定请求的资源和方法。
   服务器根据请求处理相应的资源，可能涉及数据库查询、文件读取等操作
   服务器生成HTTP响应报文，包括状态行（协议版本、状态码、状态消息）、响应头（如Content-Type、content-length等）和响应体（如HTM内容）

6. 服务器发送HTTP响应：服务器将HTTP响应发送回客户端
   服务器将响应报文通过TCP连接发送给客户端。
   客户端接收响应报文。

7. 客户端处理响应：客户端接收并处理HTTP响应
   客户端解析响应报文，提取状态码、响应头和响应体。
   根据响应内容，客户端进行相应操作，如渲染HTML页面、执行JavaScript代码、显示图片等。

8. 关闭TCP连接：客户端和服务器关闭TCP连接。
   客户端发送FIN包，请求关闭连接。
   服务器响应ACK包，并发送自己的FIN包。
   客户端发送ACK包，完成四次挥手，关闭TCP连接。

9. 持续连接（可选）
   如果使用HTTP/1.1的持久连接（keep-Alive），TCP连接可以保持打开状态，用于后续的HTTP请求和响应，减少连接建立和关闭的开销。

• HTTP 报文结构
  报文结构：报文首部，空行，报文主体。
  报文格式：请求报文，响应报文

报文首部：服务器端或客户端需处理的请求或响应的内容及属性。在客户端和服务器处理时起至关重要作用的信息几乎都在这里。
空行：回车符，换行符
报文主体：应被发送的数据。所需要的用户和资源的信息都在这里。

（1）请求报文结构：请求行，请求头部，回车换行，请求数据

问：get和Post请求有什么区别？

get适合用于获取数据，数附加在URL中，安全性较低，可以被缓存，幂等。
post适合用于提交数据，数据包含在请求体中，安全性较高，不会被缓存，非幂等。
1.数据传输方式
get数据附加在URL之后，以查询字符串的形式传递，数据长度受URL长度限制（通常为2048字符）
post数据包含在请求体中，不会显示在URL中，数据长度不受URL长度限制，可以传输大量数据。
2.数据安全性
get数据在URL中可见，不适合传输敏感信息，数据可能会被浏览器历史记录，服务器日志等保存。
post数据在请求体中传输，相对更安全，适合传输敏感信息。数据不会被浏览器历史记录保存，但仍可能被服务器日志记录。‘
3.缓存
get请求可以被缓存，适合用于获取静态资源。浏览器可能会缓存get请求的结果，提高性能。
post请求不会被缓存，适合用于提交数据或执行操作。每次post请求都会被视为新的请求，不会被缓存。
4.幂等性
get幂等方法，多次执行相同的get请求不会对资源长生影响。适合用于获取数据，不会改变服务器状态。
post非幂等方法，多次执行相同的post请求可能会对资源产生不同影响。适合用于提交数据或执行操作，可能会改变服务器状态。
5.使用场景
get用于获取数据，如查询信息，获取页面内容等。例如：搜索，分页，获取资源详情
post用户提交数据，如表单提交，文件上传等。例如：用户登录，注册，提交订单
6.数据编码
get数据以URL编码形式传递，特殊字符需要转义。例如：空格转换为+或%20
post数据可以以多种编码形式，如application/x-www-form-urlencoded，mulripart/form-data，applicationg/json。
7.浏览器行为
get可以被书签保存，方便重复访问，可以被浏览器预取或预加载。
post不会被书签保存，每次提交都需要重新操作，不会被浏览器预取或预加载。

（2）响应报文结构：状态行，响应头部，回车换行，消息体


响应状态码：1，2，3开头的状态码都表示没问题，只需要等服务器即可。4开头的状态码就是客户端错误，看看客户端请求数据是否有问题，5开头的状态码就是服务器端出现错误。

10.网络联通问题

• 查看源ip地址目的IP地址是否联通
  如果源ip地址是本机，在cmd命令里面输入：ping 目的IP地址
  
  如果源ip地址不是本机，用ip连接工具，如用MobaXterm连接源IP地址，然后命令里面输入：ping 目的IP地址
  

• 查看源ip地址与目的ip地址里面的应用（比如app）是否联通
  输入命令：telnet IP地址 端口号
  有时候两个ip联通了，但是目的ip地址的应用没有对外开放，导致源ip地址不能访问。

如果网络没联通，需要开通网策（即越过防火墙），或者开白名单（即授权使用）。

11.高频面试题汇总

在软件测试日常工作中，绝大多数偶现bug、接口异常、页面加载问题，都不是代码bug，而是网络环境导致的。不管是功能、接口还是APP测试，都离不开网络排查。同时网络基础也是软件测试面试的必考重点，面试官不考死理论，重点看你会不会结合测试工作实操、会不会排查问题。

11.1软件测试工作中常见的网络问题及解决方案

1. 网络波动/超时问题
   这是测试里最常见的问题，日常测试经常遇到接口请求超时、页面白屏、点击操作没反应、上传下载文件失败等情况。大多是测试环境带宽不够、服务器拥堵、自己本地网络不稳、跨网段访问延迟高造成的。
   测试排查思路：我会先区分是本地网络问题还是服务端问题。先ping服务器IP、telnet端口看通不通，再用Postman、curl单独调接口，多试几次看是必现还是偶尔出问题。同时对比本地、测试、预发多套环境，排除是自己电脑网络的单机问题。
2. 网络延迟导致的偶现bug
   这类bug特别隐蔽，正常网速下完全没问题，只有网络卡顿、延迟高的时候才会复现，很容易漏测上线。常见的有重复提交订单、页面状态错乱、消息推送延迟、接口数据渲染异常等。
   测试排查思路：工作中我会用Charles、Fiddler模拟弱网、高延迟、丢包的场景，主动复现这类问题。抓到接口日志后，核对接口的超时配置，检查前后端有没有做防抖、超时重试、异常兜底处理，避免弱网下出问题。
3. 跨域请求问题
   主要在Web、H5、小程序测试时遇到，最直观的现象就是前端页面点操作没反应，浏览器控制台直接报跨域错误，接口全部请求失败。核心原因就是浏览器的同源策略，协议、域名、端口有一个不一样，就会被拦截。
   测试排查思路：首先看控制台报错，确认是哪个域名、端口出现的跨域。然后核对后端有没有配置CORS跨域权限，是否放行前端的域名和请求方式。重点会区分是测试环境专属问题，还是所有环境都存在，避免测试环境正常、生产上线出bug。
4. DNS解析异常问题
   日常会遇到偶尔打不开网站、切换手机热点/无线网后接口请求失败、域名访问报错的情况。基本都是DNS解析出错、本地hosts冲突、DNS缓存污染导致的。
   测试排查思路：我会用nslookup命令查域名解析的IP对不对，刷新本地DNS缓存，切换公共DNS再测试。同时检查本地hosts文件，看是不是手动绑定了错误的IP，排除本地配置干扰。
5. 端口占用/端口不通问题
   本地启动项目、测试环境部署服务时经常碰到，表现为服务启动失败、接口访问不通、数据库和Redis连接失败。主要是端口被占用、服务器防火墙/安全组没开放端口、跨环境端口受限导致的。
   测试排查思路：先用命令查看端口是否被占用，占用了就换端口或者结束进程。如果端口没问题，就找运维核对服务器安全组和防火墙，确认我们的测试机器IP是被放行的，区分是端口没启动，还是网络拦截导致的不通。
6. HTTPS证书异常问题
   APP、小程序、HTTPS网站测试高频问题，表现为页面提示证书不安全、APP联网失败、小程序接口全部报错、页面空白。一般是证书过期、域名不匹配、测试环境自签名证书没信任导致的。
   测试排查思路：先看证书有效期和绑定域名，确认是否过期、不匹配。测试设备手动安装并信任证书，分别排查是浏览器、手机系统拦截，还是服务端证书配置问题，快速定位问题根源。

11.2高频网络面试题

1. 说一说HTTP和HTTPS的区别，测试中如何区分两者问题？

我日常测试中经常接触这两种协议，最大的区别就是安全性、端口和性能不一样。
第一是端口不同，HTTP默认是80端口，HTTPS是443端口；第二是安全性，HTTP是明文传输，数据不加密，很容易被窃听和篡改，安全性很差；HTTPS是加了SSL/TLS加密的，传输数据是加密状态，还能校验身份，防篡改防窃听，现在绝大多数APP和网站都是HTTPS。
第三是性能，HTTPS多了加密解密的握手过程，会比HTTP稍微慢一点，有轻微延迟；第四是证书，HTTP不需要证书，HTTPS必须要有合法的CA证书。
结合我测试工作来说：HTTP我基本只在测试内网测试环境、后台管理系统时遇到，主要问题就是数据明文传输，存在数据泄露风险；而HTTPS是我日常测APP、小程序、线上项目最常用的，经常遇到的问题就是证书过期、证书域名不匹配、设备未信任证书，导致接口请求失败、页面空白，这也是我测试时重点校验的点。

✅ 速记：HTTP80明文不安全、速度快；HTTPS443加密安全、需证书、略有延迟。测试重点盯HTTPS证书过期、不信任、域名不匹配问题。

2. 简述TCP和UDP的区别，分别对应哪些测试场景？

我在接口测试、实时业务测试中经常用到这两个协议，两者核心区别就是可靠性和连接方式不同。
TCP是面向连接的，需要三次握手建连、四次挥手断连，传输数据特别可靠，不会丢包、不乱序，还支持重传和纠错，但缺点是速度稍慢、有延迟。像我们日常测的接口请求、网页访问、文件上传下载、数据库连接，全都是TCP场景。测试的时候我重点关注超时、断网重连、数据丢失、重复请求的问题。
UDP是无连接的，不用提前建连，直接发数据包，速度快、延迟极低，但是不可靠，会丢包、数据可能乱序。一般用来测对速度要求高、能接受少量丢包的业务，比如直播、语音通话、视频回放、游戏实时数据。测试时我主要关注画面卡顿、声音延迟、数据丢包错乱的问题。

✅ 短句速记（考前快速背）：TCP面向连接、可靠、慢，用于接口、文件传输，测数据完整性；UDP无连接、快、不可靠，用于直播语音，测卡顿丢包。

3. 什么是三次握手、四次挥手？为什么不能两次握手？

三次握手就是TCP建立连接的过程，目的是双向确认客户端和服务端的收发能力都正常，保证连接可靠。
简单说就是：客户端发请求、服务端确认回复、客户端再最终确认，三步完成，连接就建好了。
四次挥手是断开连接的过程，因为TCP是全双工通道，客户端和服务端都能单独发数据，所以需要分开断开。客户端先关闭自己的发送通道，等服务端数据传完，再关闭服务端的通道，双向彻底断开，一共四步。
之所以不能两次握手，是因为两次只能证明客户端能发、服务端能收，没办法确认服务端能发、客户端能收。会导致服务端白白建立无效连接，占用服务器资源，造成资源浪费，所以必须三次握手双向确认。

✅ 短句速记（考前快速背）：三次握手建连、双向确认收发正常；四次挥手断连、全双工分开断开。两次握手无法双向校验，浪费服务端资源。

4. 接口请求超时，你会怎么排查？（测试高频实操题）

口语化背诵答案：工作中我经常遇到接口超时的问题，我会按照从本地到服务端、从网络到代码的分层思路一步步排查，效率很高：
第一步，先排查自己本地网络。先ping服务器地址、telnet端口，看本地和服务器的链路通不通，是不是自己网络卡顿、断网导致的问题。
第二步，排除前端问题。我会脱离页面，直接用Postman或者curl单独调用这个接口，多请求几次，判断是前端代码问题，还是接口本身的网络问题，同时区分是必现还是偶现。
第三步，排查服务端状态。我会看服务器CPU、内存是不是占满了，有没有刚刚部署代码、重启服务。再让开发帮忙查后端日志，看是不是接口报错、数据库阻塞、代码执行过慢导致响应超时。
第四步，排查环境网络。检查服务器防火墙、安全组有没有拦截请求，测试环境带宽是不是拥堵，有没有跨网段访问限制。
最后定位问题归属，分清是本地网络、环境配置、服务性能还是代码bug，然后提对应的问题或优化建议。

✅ 短句速记（考前快速背）：先查本地链路通不通，再独立调接口排前端，接着看服务器资源和日志，最后查防火墙和环境带宽，精准定位问题。

5. 什么是弱网测试？怎么做弱网测试？核心测试点是什么？

弱网测试是我APP和小程序测试中必做的一项，就是模拟现实中网速差、延迟高、丢包、网络抖动的场景，比如地铁、地下室的弱网环境，验证我们的产品在恶劣网络下能不能正常使用，容错性好不好。
我工作中主要用Charles、Fiddler来做弱网模拟，设置低带宽、高延迟、随机丢包，覆盖2G、3G、网络抖动、断网等场景。
我的核心测试点主要有四个：第一，弱网加载的时候，有没有友好的加载提示和网络报错提示，不会白屏、闪退、卡死；第二，弱网下用户重复点击操作，会不会出现重复下单、数据错乱的问题；第三，网络中断再恢复后，页面状态、接口数据能不能正常还原，不会异常；第四，上传下载、视频播放、消息推送这类核心功能，在弱网下稳不稳定。

✅ 短句速记（考前快速背）：弱网测试模拟差网络，用Charles/Fiddler操作；重点测提示友好、无重复操作bug、断网恢复正常、核心功能稳定。

6. 什么是跨域？为什么会出现跨域？怎么解决跨域问题？

跨域是浏览器的安全限制，也是我Web测试中经常遇到的问题。只要当前页面和请求接口的协议、域名、端口有一个不一样，浏览器就会判定为跨域，直接拦截接口请求，导致前端操作失效。
出现跨域的核心原因就是前后端地址不一致，浏览器为了防止恶意请求做的同源策略限制。
日常工作中解决跨域主要有四种方式：测试环境最常用的是后端配置CORS，放行前端的域名和请求方式；其次是前端配置代理转发规避跨域；也可以统一前后端的域名端口，保证同源；生产环境一般用Nginx反向代理来解决。
我测试的时候会重点核对多套环境的跨域配置，避免测试环境改了配置没问题，生产环境没配置导致线上出bug。

✅ 短句速记（考前快速背）：协议、域名、端口任一不同即跨域，由浏览器同源策略导致。主要靠后端CORS、前端代理、Nginx反向代理解决，需多环境校验。

7. 说说HTTP常见的请求状态码及测试含义

我日常抓包、看接口日志时，经常通过状态码快速判断问题类型，常用的就四类：
2xx是成功状态，最常见的是200，代表接口请求正常成功；还有201创建成功、204无返回数据，都是正常状态。
3xx是重定向，301是永久重定向、302是临时重定向，我测试时重点检查跳转地址对不对，有没有出现死循环跳转的问题。
4xx是客户端问题，基本都是前端和请求参数的问题。404是接口地址不对、资源不存在；401是没登录、未授权；403是权限不足；400是参数传错、格式不对。
5xx是服务端问题，都是后端服务和代码导致的。500是服务器内部代码报错；502是网关转发失败，一般是服务挂了；503是服务不可用，大概率是服务器过载、服务停机维护。

✅ 短句速记（考前快速背）：2xx成功，3xx重定向，4xx前端参数/权限问题，5xx后端服务异常，根据状态码快速定位问题端。

8. 接口出现502/503报错，如何排查？

工作中测试环境经常遇到502和503，我能快速区分并排查：
502是网关错误，意思是请求到了Nginx网关，但是转发不到后端服务。我会优先排查后端服务是不是宕机、重启、端口异常，再核对Nginx的转发配置有没有问题。
503是服务不可用，一般是服务器压力太大、资源耗尽、服务熔断，或者服务没启动、正在维护导致的。我会先看服务器CPU、内存负载，看服务是否正常运行，有没有请求量过大导致扛不住的情况。
通用排查方式就是查看Nginx日志和后端服务日志，确认问题是临时网络波动、环境问题，还是代码导致的服务异常，同时验证是偶现还是必现问题。

✅ 短句速记（考前快速背）：502网关转发失败，查服务和Nginx配置；503服务过载不可用，查服务器负载和服务状态，结合日志定位问题。

9. 你在测试中遇到过哪些网络相关的bug？举例说明

我在项目测试中遇到过不少网络相关的bug，印象最深的有三个，都是真实上线风险很高的问题：
第一个是弱网偶现bug。之前测电商下单功能，正常网速完全没问题，但是我用Charles模拟弱网高延迟后，发现接口超时没有做防抖处理，用户着急重复点击提交，会生成多笔重复订单。这个问题正常网络复现不了，属于典型的网络场景漏测问题，我复现后提了bug，让开发加了防抖和超时拦截。
第二个是环境跨域bug。有一次测试环境前后端域名不一致，后端没配置跨域，导致前端所有接口请求失败、页面无法操作。但生产环境域名是统一的，所以只有测试环境有问题，属于环境配置差异bug，最后协调后端补齐了跨域配置解决的。
第三个是HTTPS证书问题。测试环境的证书过期了，导致整个APP无法联网，所有接口全部报错、页面空白。排查后确认是证书过期、未及时更新，更换合法证书后就恢复正常了。

✅ 短句速记（考前快速背）：实战三类网络bug：弱网重复提交、测试环境跨域配置异常、HTTPS证书过期失效，均已正常提bug并验证修复。

10. TCP粘包、拆包是什么？测试中如何发现和规避？

我在测长连接、消息推送、实时通信项目时，接触过TCP粘包和拆包的问题。
因为TCP是流式传输，没有固定的数据包边界。发送端连续发几个小数据，就会合并成一个包发给接收端，这就是粘包；如果单次发送的数据太大，就会被拆分成多个小包传输，这就是拆包。
体现在测试现象上，就是接收的数据错乱、缺失、拼接异常，消息解析失败、数据展示不全。
我测试时会通过高频连续发送数据、压测长连接接口的方式，复现这类问题。同时检查开发有没有做数据包长度校验、数据分隔、报文解析处理，确保不会因为粘包拆包导致业务异常。

✅ 短句速记（考前快速背）：TCP无边界导致小数据粘包、大数据拆包，会造成数据异常。通过高频压测复现，校验开发的报文分隔和校验逻辑即可规避。