# 1. Charles/Fiddler 抓取 HTTPS 的原理（中间人代理+证书信任）与手机端配置步骤？ A Charles 通过窃取服务器的私钥来解密 HTTPS 流量 B 中间人代理通过与客户端和服务器分别建立 TLS 连接，使两侧都信任代理证书从而解密流量 ✓ 正确答案 C 只要代理端口开启，无需证书即可解密任意 HTTPS 流量 D HTTPS 抓包会破坏服务器端的安全性
# 2. 如何用抓包工具做断点改包与 Mock 响应（Map Local/Rewrite）来验证客户端健壮性？ A Breakpoint 适合临时人工改包验证，Map Local/Rewrite 适合规则化、可重复的 Mock ✓ 正确答案 B Map Local 只能修改请求头，不能修改响应体 C Rewrite 只能针对 https 请求生效 D 断点改包会永久修改服务器上的数据
# 3. 移动端 App 抓包的常见问题，证书未信任、代理绕过、SSL Pinning 与双向认证如何处理？ A 安装证书后所有 App 都能被抓包，无需考虑 SSL Pinning B Android 7.0+ 默认信任用户安装的证书 C SSL Pinning 通过把服务器证书钉死在客户端来防止代理中间人，需 Hook 或重打包等加固手段绕过 ✓ 正确答案 D 双向认证只需抓包工具即可自动完成
# 4. 弱网模拟（限速/丢包/高延迟）在 Charles 与浏览器 DevTools 中的实现与差异？ A Charles 通过代理层对流量限速/丢包/加延迟，适合移动端真机弱网测试 ✓ 正确答案 B 弱网模拟只能模拟慢速，不能模拟丢包 C DevTools 的弱网模拟会作用于整个系统所有 App 的流量 D 弱网模拟只影响请求，不影响响应
# 5. 浏览器 DevTools Network 面板定位接口问题的关键指标（Timing 瀑布、状态码、请求/响应头）？ A TTFB 很长通常说明服务器处理或网络往返慢，问题倾向在后端或网络 ✓ 正确答案 B Timing 瀑布无法反映 TLS 握手耗时 C Content Download 时间只与服务器处理速度有关 D 状态码 4xx 一定代表后端代码 bug
# 6. HTTPS 抓包（SSL 代理/证书安装）与移动端抓包的工程配置与合规边界？ A 抓包过程中录制的用户数据可随意留存与分享 B 只要开启 SSL Proxying 所有手机都能直接抓包，无需配置证书 C 抓包应最小化范围、脱敏展示并及时销毁数据，绕过 Pinning 等手段需在授权范围内使用 ✓ 正确答案 D 合规问题只存在于生产环境，测试环境可随意抓包
# 7. 用 Wireshark 定位弱网问题的关键过滤器与时间线分析（TCP 重传/RTT）？ A 重传次数与网络质量无关 B 过滤器 `tcp.analysis.retransmission` 只能查看 UDP 流量 C Wireshark 无法解密 HTTPS 内容，因此对弱网分析无用 D 出现大量 TCP 重传与 RTT 升高通常提示网络丢包或拥塞 ✓ 正确答案
# 8. 抓包定位问题的流程，从抓包（Wireshark/Charles/Fiddler）到协议分析，如何还原请求-响应链路？ A 抓包后应直接看响应体，无需关注请求头与状态码 B Wireshark 与 Charles 功能完全相同，可任选其一 C 还原请求-响应链路需要结合时间戳与 traceId，把各环节报文对齐到同一请求 ✓ 正确答案 D 抓包只能用于定位后端问题，无法定位前端问题
# 9. HTTP 状态码与响应头在缺陷定位中的解读，4xx/5xx、缓存头、CORS 头如何辅助判断问题归属？ A 5xx 通常指向服务端问题，而 CORS 头缺失可能导致浏览器拦截跨域请求 ✓ 正确答案 B 所有 4xx 都代表前端代码有 bug C 401 表示服务器内部发生异常 D Cache-Control 只影响性能，与缺陷定位无关
# 10. 从抓包时间线定位页面性能瓶颈，DNS、TCP/TLS 握手、首字节时间与资源瀑布各阶段如何解读，前后端慢如何判定？ A TTFB 越短说明服务器负载越高 B TTFB 长且下载快，说明瓶颈在后端处理或网络往返 ✓ 正确答案 C 资源瀑布图无法区分前端与后端耗时 D DNS 慢属于后端应用问题
# 11. 抓包重放的工程应用，重放录制请求验证幂等、限流与重复提交，重放时如何修正时间戳、签名与 token 等动态参数？ A 重放前应修正时间戳、签名与 token 等动态参数，否则请求可能因过期失效 ✓ 正确答案 B 重放时必须原样发送旧请求，不能修改任何参数 C 重放只用于验证功能，无法验证幂等与限流 D 签名参数与时间戳无关，无需重新计算
# 12. 抓包发现请求带加签/加密时，测试的应对策略有哪些？ A 加签请求无法在测试环境验证，只能跳过 B 优先向开发获取测试环境密钥或关闭加密开关，必要时用 Hook 解密，并验证签名与防篡改 ✓ 正确答案 C 加签只影响性能，不影响正确性验证 D 加密请求只能做黑盒测试，无法做任何断言
# 13. 接口抓包与代码定位的联动，如何从抓包反推前后端责任归属？ A 以请求/响应是否符合接口契约为判据，结合 traceId 与代码定位来反推责任 ✓ 正确答案 B 只要接口返回 5xx，责任就一定是前端 C 抓包报文无法作为缺陷证据 D 请求参数错误应归后端处理
# 14. SSL Pinning 绕过测试的方法与合规边界，Hook/重打包/代理插件等手段的工程与法律考量？ A 可以随意对任何 App 进行绕过测试，无需授权 B 绕过 Pinning 只影响 App 性能，不涉及法律问题 C 重打包不会影响 App 的签名与完整性 D Hook、重打包、代理插件等手段存在工程与法律风险，应在授权范围内对自有或被测产品进行 ✓ 正确答案
# 15. gRPC/WebSocket/HTTP2 等协议的抓包调试方法，工具支持与解密配置？ A WebSocket 是短连接，无法在抓包工具中查看 B HTTP2 与 HTTP1 报文格式完全相同 C gRPC 基于 HTTP2 与 protobuf 二进制，需专用工具与正确的 TLS 解密配置才能调试 ✓ 正确答案 D 所有协议都能用同一个工具以相同方式直接读出明文
# 16. 抓包工具自身的风险管控，抓包数据包含敏感信息时如何脱敏与销毁？ A 抓包数据都是测试数据，无需考虑敏感信息 B 抓包文件可以永久保存在本地方便复用 C 应最小化抓包范围、对敏感字段脱敏、加密存储并及时销毁，遵守数据安全规范 ✓ 正确答案 D 脱敏会破坏抓包数据的完整性，因此不应脱敏
# 17. 抓包与日志的联合分析，如何把抓包时间线与服务端日志、数据库操作对齐还原完整请求链路？ A 抓包与日志相互独立，无法关联 B 只有商用的分布式追踪工具才能关联，ELK 无法做到 C 以时间戳为横轴、traceId 为关联键，把抓包、服务端日志与数据库操作对齐还原完整链路 ✓ 正确答案 D 数据库慢日志与接口耗时无关
# 18. 抓包能力的自动化集成，如何把代理抓包嵌入自动化测试，实现请求导出、断言与失败现场留存？ A 抓包只能手工操作，无法嵌入自动化 B 代理嵌入自动化后可记录请求、断言接口响应，并在失败时保存 HAR 与报文留作现场 ✓ 正确答案 C 失败留痕只能靠截图，无法保存报文 D 自动化中只能断言 UI，不能断言网络请求
