场景法（业务流程法）和状态迁移法有什么区别？

👔 Raina面试官： 场景法和状态迁移法有什么区别？什么时候用哪个？

🙋 候选人：

• 场景法走业务流程，状态迁移法盯单个对象的状态变化。
• 场景法：用户从浏览商品→加购→结算→支付，跨多个页面和角色，强调端到端路径。状态迁移法：订单对象在待支付、已支付、已取消等状态间合法/非法跳转，强调状态和事件。
• 有清晰状态机的模块（工单、审批、订单）用状态迁移；跨系统长链路用场景法，两者可叠加——场景里的每一步也可能触发状态变化。

👔 Raina面试官： 非法状态跳转怎么测？

🙋 候选人：

• 列状态转换表，对每个状态列出允许和不允许的事件。不允许的通过直接改 URL、重放 API、篡改状态字段去触发，期望系统拒绝并给出明确错误。
• 这类用例特别容易漏，因为正向流程文档通常只写 happy path，测试要主动补全转换表。

错误推测法在实际工作中怎么用？和探索性测试有什么关系？

👔 Raina面试官： 错误推测法工作中怎么用？和探索性测试啥关系？

🙋 候选人：

• 错误推测靠经验和直觉猜哪里容易出问题——空值、超长、并发、特殊字符、权限边界、网络抖动。
• 探索性测试是有 charter 的自由测试，错误推测常作为探索的方向之一。区别：错误推测可以是设计用例时的脑力活动；探索性测试是执行方式，强调同时学习、设计、执行。
• 我会把历史生产 Bug、同类项目踩坑清单整理成 checklist，迭代初做一轮探索性 session，比纯 scripted 测试更容易发现意外。

👔 Raina面试官： 探索性测试没有用例，怎么向领导证明你测了？

🙋 候选人：

• 用session 记录：Charter 目标、时间盒、覆盖区域、发现的缺陷和未覆盖风险。
• 不是没文档，而是文档形式不同——测试笔记、思维导图、缺陷单就是产出。探索性适合新功能摸底和回归后的补漏，不替代核心用例自动化。

日志表、审计表的数据准确性怎么验证？

👔 Raina面试官： 日志表、审计表的数据准确性你怎么验证？

🙋 候选人：

• 审计表测的是该记的有没有记、字段对不对、能不能对上业务操作。
• 先跟产品/合规对齐审计范围：谁、何时、对什么对象、做了什么、结果如何。每条业务操作（登录、改权限、删数据、审批）触发后查 audit 表：记录数 +1、actor_id/action/target_id/timestamp 正确、敏感字段脱敏。
• 还要测负向：失败操作是否也记 attempt、未授权操作是否记拒绝。自动化可用操作 API → 查 audit 表闭环；批量 job 要抽样对账 row count 与源表变更是否匹配。

👔 Raina面试官： 审计表和业务表不在一个库怎么办？

🙋 候选人：

• 用trace_id / business_id 做跨库关联，测试验关联字段必填且可 join。
• 异步写 audit 要测延迟窗口内查询是否最终一致；丢失 audit 往往比丢业务数据更严重，我会把 audit 写入失败标 P0。

测试环境与生产数据库结构不一致时，你怎么控制风险？

👔 Raina面试官： 测试库和生产库结构不一致，你怎么控制风险？

🙋 候选人：

• 结构漂移是漏测和误报的高危源，测试侧要推动可度量的对齐机制。
• 日常：用 schema diff 工具（flyway/liquibase 版本号、Atlas、mysqldiff）对比 test/staging 与 prod，CI 里 migration 必须过。发布前：staging 结构应与 prod 一致或领先一个待发布 migration，不允许 test 长期落后。
• 风险控：结构不一致时，相关 case 标环境风险、缩小 release 范围；涉及新字段/索引的必在 staging 复测。我会把schema 版本写进测试报告，不一致时有权 block。

👔 Raina面试官： 开发说 test 库随便改，不用跟 prod 一样，你怎么回应？

🙋 候选人：

• 可以数据随便，结构不能随便——否则测的是另一个产品。
• 折中：个人 dev 沙箱随意，共享 test/staging 必须跟 migration 管线走。没有 migration 的改表一律不进共享环境。

测试工程师需要掌握哪些 Linux 常用命令？

👔 Raina面试官： 做测试的，Linux 命令你觉得哪些必须会？

🙋 候选人：

• 不用背几百个，文件、进程、网络、日志、权限五类够用日常排查。
• 文件目录：ls、cd、find、grep、awk/sed 基础、tail/head/less、cat、wc、sort、uniq。进程：ps、top/htop、kill、nohup、systemctl status/start/stop。网络：curl、wget、ping、telnet/nc、ss/lsof -i。权限与环境：chmod/chown、env、export、df/du。
• 组合能力比单命令重要：tail -f app.log | grep ERROR、find . -name '*.log' -mtime -1。Docker 环境再加 docker ps/logs/exec。

👔 Raina面试官： vim 要到什么程度？

🙋 候选人：

• 会打开、搜索、退出就不丢人；日常 less 够看日志。
• 但要会在服务器上改配置备份、改测试脚本——nano/vi 基本编辑即可。重点是把日志和进程查清楚，不是当运维大神。

如何通过日志快速定位问题？（grep、tail、less 等）

👔 Raina面试官： 测到一半接口挂了，你怎么用日志快速定位？

🙋 候选人：

• 我的套路是先圈时间，再圈 trace_id，再圈 ERROR 栈。
• tail -f 或 tail -n 500 看最新；grep request_id/trace_id 把一次请求串起来；grep -i error/exception 找栈；less + /pattern 在大文件里跳。多服务时用同一 trace_id 在 gateway、业务、DB 日志间交叉看。
• 还会对比：失败请求和成功请求的参数 diff、失败是否集中在某版本/pod。把关键日志片段贴 bug 单，比说接口不行有用十倍。

👔 Raina面试官： 日志量太大 grep 很慢怎么办？

🙋 候选人：

• 缩小范围：按时间切文件、先 grep 时间段再 grep 关键词。
• 有 ELK/Loki 就上平台搜；没有就用 awk 按时间列过滤，或 zgrep 查压缩归档。测试环境应能开 debug 级别复现一次，比在生产 TB 日志里大海捞针强。

测试环境里服务启停、进程排查你会怎么做？

👔 Raina面试官： 测试环境服务启停、进程排查你平时怎么做？

🙋 候选人：

• 先搞清楚部署方式（systemd / Docker / K8s），再用对应命令，别一律 kill -9。
• systemd：systemctl status/stop/start/restart service_name，journalctl -u service -f 看日志。Docker：docker ps、docker logs -f、docker restart。Java 进程：ps aux | grep java、jstack 看死锁（配合开发）。启停后做 smoke：健康检查接口、核心链路一条。
• 测试前确认环境版本和分支；多人共用环境启停要先沟通，避免把别人 case 跑挂。

👔 Raina面试官： 服务起不来你怎么判断是端口占用还是配置错？

🙋 候选人：

• 看启动日志最后 50 行 + ss -tlnp | grep 端口。
• Address already in use → 端口冲突；配置文件 not found / connection refused → 配置或依赖服务。把完整报错和 env 差异贴给开发，比反复起不来高效。

如何查看端口占用和网络连通性？

👔 Raina面试官： 端口占用和网络连通性你怎么查？

🙋 候选人：

• Linux 上ss 或 lsof 查端口，curl/nc/telnet 验连通，分层排除。
• 端口：ss -tlnp（监听）、ss -tnp（连接）；lsof -i :8080 看谁占用。连通：ping 只能证明 ICMP；业务用 curl -v http://host:port/health 或 nc -zv host port。DNS 问题 nslookup/dig；路由 traceroute。
• 微服务场景还要测：test 容器能否访问中间件（Redis/MySQL）、安全组/防火墙是否放行、K8s service 和 ingress 是否指对。

👔 Raina面试官： Windows 测试机呢？

🙋 候选人：

• netstat -ano | findstr 8080 查端口，Test-NetConnection -ComputerName -Port 验连通。
• 原理一样：先本地端口，再网络层，再应用层 HTTP。跨环境问题常是 VPN、hosts、代理——我会先 ping 通再 curl。

测试数据清理脚本你会怎么写和维护？

👔 Raina面试官： 测试数据清理脚本你怎么写和维护？

🙋 候选人：

• 清理脚本和造数脚本一样重要，原则是安全、幂等、可审计。
• 写法：WHERE 带 test 前缀或 created_by='automation' 或 tag 字段，禁止无 WHERE 全表删。按外键逆序 delete 或 truncate 子表。支持 dry-run 模式先 print 将删行数。维护：跟 schema 变更同步、放 Git review、CI 里 nightly 清或每 suite teardown 调。
• 生产库绝不在脚本里留 prod 连接串；用环境变量 + 二次确认。删错一次就社死，所以我会加 delete limit + 事务可 rollback 试运行。

👔 Raina面试官： 清理不干净导致用例 flaky 怎么办？

🙋 候选人：

• 根因多是遗漏关联表或异步任务又写回。
• 梳理实体依赖图，清理顺序写进文档；关定时 job 或 mock 外部回调。flaky case 先查是否数据残留，再怀疑代码。

Docker 容器化对测试环境管理有什么影响？

👔 Raina面试官： Docker 容器化对测试环境管理有什么影响？

🙋 候选人：

• 整体是环境一致性变好、生命周期变短、调试方式变。
• 好处：docker-compose 一键起依赖（MySQL/Redis/MQ）、版本 pin 跟 prod 接近、CI 里 ephemeral env 用完即毁。挑战：日志在容器里要 docker logs；文件持久化要 volume；网络是 bridge 还是 host 影响连通；本地和 CI 资源差异导致 OOM。
• 测试策略：镜像 tag 跟 release 对齐；集成测试 against compose stack；数据用 init SQL 或 testcontainers 自启依赖。我会推动compose 即文档，新人一条命令起环境。

👔 Raina面试官： 容器环境和真实 K8s 还有差距，怎么补？

🙋 候选人：

• compose 测功能与集成，staging K8s 测部署、配置、网络策略。
• 关键 release 前在 staging 跑 E2E；差异项（HPA、ingress TLS）单独 checklist，不假装 compose 等于生产。