华为 OD 测试面经：HR 主管面与两轮技术面全记录

《面试题目》

HR 与主管面

1. 离职原因是什么？
2. 用例设计方法有哪些？
3. 你最失败的事是什么？
4. 有没有用过 AI、框架、模型？用来干什么？常用的 skill 是什么，怎么用的？
5. 职业规划是什么？
6. 云计算有了解吗？
7. 为什么选择华为？
8. 了解华为的技术栈吗？
9. 平时有研究新的技术产品吗？
10. 平时关注什么 IT 技术或产品？你关注芯片的什么方面，硬件还是别的？
11. 你倾向于开发还是测开？为什么？
12. 有什么问题想问的？
13. 自我介绍。

技术一面

1. 项目介绍，做的工作有哪些？
2. 测试设计要考虑的维度有哪些？具体到你的个人项目。
3. 自动化测试、性能测试、压力测试是怎么做的？
4. 性能达不到时，你怎么确定是系统的问题还是其他因素干扰导致的？怎么处理的？
5. 自动化框架怎么搭建？
6. Playwright 和 Selenium 这两种自动化工具怎么比较？
7. 云计算有了解吗？
8. 你后期的职业规划是什么？
9. 毕业专业和现在工作的联系性在哪？
10. 手撕代码，并讲解题思路。
11. 个人介绍。

技术二面

1. 测试覆盖率怎么算？覆盖不到的内容有哪些？
2. 项目测试是怎么设计的？
3. 自动化测试和手工测试的范围怎么界定？
4. 性能压测的流程与步骤、工具的使用过程是怎样的？
5. 问题定位、压力测试的条件以及指标有哪些？
6. 自动化脚本的结构是怎样的？
7. Linux 基础和 shell 脚本掌握到什么程度？
8. 显示等待和隐式等待的区别是什么？
9. 手撕代码，并讲解题思路。
10. 个人介绍。

《参考解析》

用例设计方法要能落到自己的项目上

常见方法有：等价类划分（有效/无效）、边界值（上点、离点、内点）、判定表与因果图（多条件组合）、正交实验（参数多、全组合爆炸时）、场景法（正常流 + 备选流 + 异常流）、状态迁移（有状态机的功能，如订单、支付）、错误推测（凭经验补边界）。面试官一定会追一句「具体到你的项目」，所以准备时把项目里最有代表性的模块拆一遍：接口测试用等价类 + 边界值，表单校验用判定表，订单状态用状态迁移图，多参数配置用正交表，最后按优先级排用例（P0 冒烟、P1 主流程、P2 异常）。报覆盖率时别只说百分比，要说清「按需求点、按接口、按代码行」三种口径分别是什么。

自动化框架搭建的分层

能画出一张分层图就赢一半：用例层（业务语义，一条用例对应一个场景）→ 页面对象层（PO/POM，元素定位与操作封装，页面变了只改这一层）→ 驱动层（Selenium/Playwright/Appium 的封装，统一超时、截图、重试）→ 数据层（测试数据与账号池，参数化驱动）→ 报告与通知层（HTML 报告、失败用例自动截图与 trace、发群/发邮件）→ CI 集成（Jenkins/GitLab CI 定时与提测触发、失败自动重跑一次、按标签分套件）。几个容易被追问的工程细节：用例要独立可重跑（不依赖执行顺序、自带数据准备与清理）、环境配置外置（不同环境切配置文件而不是改代码）、失败重试要区分「环境抖动」和「真 bug」、报告里必须能直接看到失败步骤的 DOM 快照或录像。

Playwright 和 Selenium 怎么比较

维度	Playwright	Selenium
通信方式	通过 CDP/自有协议直连浏览器，长连接	走 WebDriver 协议，多一跳 HTTP
等待机制	内置自动等待（元素可操作性检查），几乎不用写显式 sleep	需要显式等待或隐式等待配好，否则易 flaky
浏览器支持	Chromium、Firefox、WebKit 三内核，一套 API	支持最广，含老版本浏览器与更多厂商驱动
生态与语言	JS/TS、Python、Java、.NET，官方测试运行器	语言绑定最全，社区和存量用例最大
网络控制	原生支持路由拦截、mock 接口、篡改请求	要借助代理或浏览器扩展
移动端	实验性设备模拟，无原生 App 能力	配 Appium 可做 App 自动化
执行速度与稳定性	通常更快、更稳	依赖驱动与等待写法，写得不好 flaky 多

选型结论：新项目做 Web 端 E2E 优先 Playwright；要覆盖 IE/老版本浏览器、或项目组要统一 Web 与 App（Appium）技术栈时选 Selenium。

性能测试的完整流程与指标

流程是：需求与目标（预期 TPS、响应时间、并发用户数）→ 场景建模（基准、单接口、混合业务、峰值、稳定性、异常）→ 脚本开发（参数化、关联、断言、思考时间）→ 数据准备（量级要与生产同数量级，否则索引命中率完全不同）→ 梯度加压执行 → 全链路监控 → 定位调优 → 回归验证。指标要能报出：TPS/QPS、响应时间（平均、P95、P99、最大值）、并发数与错误率、以及资源侧 CPU/内存/IO/网络/连接池/GC 情况。压测条件必须交代清楚：压测机与被测服务是否同机（同机会抢 CPU 导致数据不可信）、是否预热、加压方式是阶梯还是瞬时、持续时间（稳定性测试一般 8 小时起）。

「性能不达标，怎么判断是系统问题还是干扰因素」这题的标准答法是逐层排除：先看压测机自身是否是瓶颈（CPU 打满、网络打满、客户端连接数限制），再看中间层（网关、负载均衡、DNS、带宽），再看服务端（线程池/连接池耗尽、锁竞争、慢 SQL、GC 停顿、下游依赖超时），每一步都用监控数据说话而不是猜。定位问题最有效的手段是「同一脚本、同一数据、同一压力下做变量对照」——只改一个因素再跑一遍。

覆盖率与手工/自动化的范围界定

覆盖率分需求覆盖率、用例覆盖率、代码覆盖率（行、分支、条件、路径）几类；测不到的地方通常是：异常路径（网络中断、断电、磁盘满、依赖超时）、并发与竞态（只在特定时序下出现）、第三方服务内部逻辑、UI 样式与主观体验、性能与容量边界、以及死代码。承认这些盲区并说清如何用故障注入、混沌工程、灰度观察来补，比硬说「覆盖 100%」可信得多。

自动化与手工的界定标准：重复执行频率高、界面与流程稳定、断言明确、数据可构造的回归用例交给自动化；一次性探索、需求还在频繁变动、涉及主观判断（视觉、易用性）、依赖不可控环境的留给手工。上线前的探索性测试、验收测试、兼容性抽检基本都是手工。

显示等待与隐式等待

隐式等待是给整个 WebDriver 设一个全局超时，找元素时如果立刻找不到就在这个时间窗口内轮询重试；它只对「查找元素」生效，对 click 之后状态变化、元素可点击性、Ajax 渲染完成都不管用，而且和显式等待混用会让实际等待时间叠加、行为难以预测。显示等待是针对具体条件设的超时（WebDriverWait + expected_conditions，如 element_to_be_clickable、visibility_of_element_located、text_to_be_present_in_element），语义清楚、超时可控。工程上推荐统一用显式等待（Playwright 干脆内置了自动等待），不要用 sleep；隐式等待最多设一个很小的全局兜底值。

Linux 与 shell 常考点

文件与文本处理：grep/awk/sed/cut/sort/uniq/wc 组合统计日志里的错误码分布；find 按时间与大小找文件。进程与资源：ps/top/htop、free、df、iostat、netstat/ss、lsof 看端口占用，kill -15 与 kill -9 的区别。日志排查：tail -f、grep -C、journalctl、按时间窗口过滤。脚本本身要会写：变量与引号、$? 与 set -e、for/while、函数、if [ ] 与 [[ ]]、管道与重定向、xargs、以及用 crontab 做定时任务。测试岗最常被问的场景是「用 shell 从一堆日志里统计每个接口的失败次数并排序」。

手撕代码与讲解题思路

测试岗的手撕通常不会太难，高频是：字符串处理（反转、回文、统计字符）、数组（两数之和、去重、找重复）、链表（反转、找环、合并有序链表）、栈队列、简单 DP（爬楼梯、最长公共子串）、以及排序查找。答题节奏比题目本身重要：先复述题意并确认边界（输入为空、长度为 1、有重复、数据范围、是否允许改原数组）→ 说思路和复杂度 → 写代码 → 自己举 2~3 个用例过一遍（含一个边界）→ 说明还能怎么优化。写完主动检查，是面试官最想看的一步。