软件测试面试记录：抓包、缓存测试与完整测试流程

《面试题目》

1. 以往工作中，你是如何排查问题的？
2. 请求数据是加密的，如何进行抓包？
3. 你的 SQL 掌握到什么程度？
4. Redis 里的缓存数据怎么测试？
5. 如何通过日志分析排查问题？详细步骤。
6. 日常会用到哪些 Linux 命令，分别用在什么场景？
7. 接口都有哪些请求方法？
8. GET 和 POST 的区别？
9. HTTP 和 HTTPS 的区别？
10. HTTPS 的「三次握手、四次挥手」是怎么回事？
11. HTTP 常见状态码有哪些，分别是什么意思？
12. 单元测试是怎么做的？
13. 完整的测试流程是什么？你在其中发挥了什么作用？
14. 多环境测试：分别在哪些环境测、各自要求是什么？
15. 有没有做过安全测试？是怎么做的？
16. 测试过程中需求频繁变更，你会怎么做？

《参考解析》

排查问题先定边界，再逐层缩小范围。 先确认现象：哪个环境、哪个版本、哪些用户、什么时间开始、能否稳定复现；再看最近变更（发布、配置、数据、依赖）作为第一嫌疑。然后按请求链路分层：客户端/网络 → 网关与负载均衡 → 应用日志与指标 → 缓存/数据库/下游服务。每一层用证据说话：错误码、traceId、时间窗口、线程栈、慢查询、GC、连接池。提出假设后做对照实验，一次只改一个变量；定位后补回归用例，确认修复没有引入新问题。说不清复现条件时，先加日志和监控，而不是盲猜。

加密请求的抓包，关键在拿到解密点，而不是硬破算法。 如果是自家应用，优先让开发提供测试环境的密钥、证书或抓包开关，在网关/客户端 SDK 层解密；用 Charles、mitmproxy、Fiddler 做代理，安装并信任证书，必要时写插件按协商好的算法解密。遇到证书绑定（pinning），测试包可以临时关闭校验，或让开发提供可抓包的 debug 包；生产包不要为了抓包去改证书校验。另一种思路是从网关访问日志、链路追踪或服务端埋点取明文参数，既能验证业务又不动加密链路。要守住边界：只抓测试账号和测试环境，不把生产用户数据落到本地。

Redis 缓存测试要覆盖「读、写、失效、异常」四类。 读：命中与不命中、缓存穿透（查不存在的数据）、缓存击穿（热点 key 过期瞬间）、缓存雪崩（大批 key 同时过期）；写：更新数据库后缓存是否同步、先删缓存还是先更库、并发读写会不会读到旧值；失效：TTL 是否生效、主动删除是否成功、降级到数据库时行为是否正确；异常：Redis 宕机、主从切换、集群槽迁移、内存淘汰时业务是否可用。测试手段包括构造并发、人为改 TTL、用 DEBUG SLEEP 或代理延迟、停节点做故障注入，最后核对数据库与缓存的一致性。

SQL 的掌握程度按「能独立完成测试取数」来答。 日常要会多表 JOIN、子查询、聚合与分组、窗口函数、日期函数和 CASE WHEN；能看懂执行计划，知道索引、最左前缀、回表和深分页为什么慢；测试数据构造要会批量插入、事务回滚和脱敏。验证类 SQL 常用来做「页面结果 vs 数据库结果」的对账，比如按主键查状态、按时间窗口统计条数、用 EXCEPT/LEFT JOIN ... IS NULL 找差异。被问到时不要只说「会增删改查」，举一个你写过的对账或造数例子，比背语法更有说服力。

日志分析要带着问题去查。 先确定时间窗口和关键字（traceId、用户 ID、订单号、错误码），再用 ELK/Loki/Splunk 聚合，按服务、级别、异常类型分组；先看 ERROR 和超时，再看 WARN 和上游返回；把一条请求的日志按 traceId 串起来，定位失败发生在哪一跳。常用 Linux 命令：tail -f 看实时日志，grep/zgrep 过滤，less 翻页，awk 取列，sort | uniq -c | sort -rn 做 TopN，sed 脱敏，journalctl -u 看服务日志，ss -tulnp 看端口与连接，ps/top 看进程资源，df -h/free -m 看磁盘与内存。

HTTP 方法与状态码是基础分。 常见方法有 GET、POST、PUT、PATCH、DELETE、HEAD、OPTIONS；GET 取资源、参数在 URL、可缓存、幂等，POST 提交数据、参数在 body、通常不幂等，PUT 全量更新且幂等，PATCH 局部更新，DELETE 删除且幂等。状态码：2xx 成功（200、201、204），3xx 重定向/缓存（301、302、304），4xx 客户端错误（400 参数错、401 未认证、403 无权限、404 不存在、409 冲突、429 限流），5xx 服务端错误（500、502 网关错误、503 不可用、504 超时）。HTTPS 是 HTTP over TLS，TCP 三次握手建立连接后还要做 TLS 握手（证书校验、密钥协商），之后才是加密的 HTTP 报文；四次挥手是 TCP 关闭连接的过程，不是 HTTPS 特有。答题时把这一点纠正清楚，比顺着错误说法背更有区分度。

单元测试由开发写、测试把关。 选框架（JUnit/TestNG、pytest、Jest），一个用例只验证一个行为，依赖用 mock/stub 隔离，覆盖正常、边界、异常分支；断言要具体，避免只断言「不抛异常」；用覆盖率看缺口，但不把覆盖率当唯一目标；最后接进 CI，提交即跑。完整测试流程是：需求评审 → 测试计划与范围 → 用例设计（等价类、边界值、场景法、判定表）→ 环境与数据准备 → 执行与缺陷跟踪 → 回归与准入准出 → 发布验证 → 复盘。测试在其中的作用不是最后点一遍，而是从需求阶段就把可测性、验收标准和风险提出来。

多环境测试的重点是「差异可控」。 开发环境验证联调与基础功能，测试环境跑完整回归和接口自动化，预发/ staging 尽量贴近生产配置做发布前验证，生产做灰度与冒烟。每个环境的数据库、缓存、第三方 mock、域名、证书、开关都可能不同，测试前先确认配置差异，避免「测试环境过了、生产挂」。安全测试至少覆盖认证授权、越权、SQL 注入、XSS/CSRF、敏感信息泄露、文件上传、接口重放与限流；用工具扫一遍只是起点，关键业务流要手工验证。需求频繁变更时，先做影响分析，按风险分层用例：核心链路每次回归，边缘功能抽检；能自动化的稳定部分沉到回归集，变动大的部分用探索式测试补位，同时把变更记录和验收标准同步给产品与开发，避免测试范围失控。