汇川技术秋招测试开发工程师面经

《面试题目》

1. 请做一下自我介绍。
2. 介绍一下你的实习项目。
3. 介绍一下研究生时期的项目（论文方向与导师的项目）。
4. 介绍一下实习工作经历：腾讯云实习里的 workbuddy 专家 skill 测试，这个专家是什么背景？你负责的人群挖掘 skill 具体做了什么？
5. 为什么要做 Web 自动化测试这个项目？
6. 为什么选择测试开发这个方向？
7. 你有哪些想了解的？（测试业务是否稳定、团队规模如何、有没有建设内部 AI 平台）

《参考解析》

自己动手造自动化框架这段经历，要讲成「问题—取舍—收益」而不是「我用了 Playwright」。 起点是重复劳动：回归用例靠人点、每次发版都要重跑一遍、漏测和回归成本随功能增长而线性上升，所以提议搭一套基于 Playwright 的 UI 自动化。讲的时候要交代为什么选它——单进程驱动多浏览器、自动等待（actionability check）省掉大量显式 sleep、调试工具体验好，相比 Selenium 的驱动链路更短、flaky 更容易定位。然后是框架本身的工程点：用例与页面对象分层（Page Object 或更轻的 fixture 组织）、测试数据与环境配置外置、失败自动截图与录屏、重试策略只对已知 flaky 场景生效、以及接入 CI 按提交触发。收益要量化：覆盖了多少条核心回归路径、单轮回归从几小时压到几分钟、上线前发现的问题数或缺陷逃逸率的变化。最后主动补一句局限——UI 自动化维护成本高、只覆盖端到端主流程，稳定的业务规则应该下沉到接口层断言，这条边界意识比堆用例数更能体现测试开发的判断力。

Agent 工作流测试与 AI 接口测试：断言要写在「结果与约束」上，而不是文本相等。 大模型输出天然不确定，用「期望字符串」做断言必然全红，可用的手段是分层：结构层断言输出符合 Schema（能否解析、字段是否齐全、类型是否正确）；事实层用规则或第二个模型做校验（答案里的数字是否来自给定上下文、引用是否真实存在）；行为层断言工具调用轨迹（调了哪些工具、顺序、参数是否合法、有没有越权），这层往往是最有价值的——它测的是编排逻辑而不是措辞。稳定性上要做「同输入多跑几次」统计通过率，把偶发失败与必然失败区分开，并固定模型版本、温度和 prompt 版本，否则回归结果没有可比性。压测则与普通接口不同：要关注 token 吞吐与排队延迟、并发下的限流与降级是否按预期触发、失败重试会不会放大成雪崩，以及成本上限（每次调用的 token 与金额）是否被守住。把这些讲清楚，等于回答「AI 系统到底怎么测」这个当前最想听的问题，也自然把话题引到你做过的人群挖掘 skill 与专家 skill 上。

转测试开发的职业叙事要闭环。 面试官关心的不是动机有多动人，而是这条路你走通了没有。可以按这样的结构讲：起点是校企合作项目里需要人做验证，实际做下来发现质量问题的根因往往在流程与工具，而不是某一次手工测试；为了把活干完，自学了接口测试、自动化框架、压测与 CI 接入，把「帮算法团队测 Agent 工作流」这段经历做成了可复用的方法；然后是主动选择——对比开发与测试开发，自己更喜欢从系统层面找问题、也愿意长期维护工程基础设施。同时要正面回应常见的顾虑：测试开发不等于只会点页面，它会写框架、写工具、看监控、定位线上问题，技术深度不输业务开发；也要承认短板（比如对业务领域知识还需要积累），并给出入职后的具体计划。最后反问环节问「测试业务是否稳定、团队规模、有没有内部 AI 平台」是很好的选择，这些问题能帮你判断团队是在做真正的工程基建，还是只做手工回归——回答的质量比数量重要。