腾讯娱乐测试开发面经

《面试题目》

1. 自我介绍。
2. 问问学校情况。
3. 讲讲实习经历。
4. 你做的这个东西难点在哪里，怎么解决的？
5. 学过哪些课程？（顺势问到操作系统、网络传输协议，问了网络七层模型）
6. Python 和 Java 的区别与使用感受？
7. 你知道 Python 中的注解（decorator）吗？
8. 你做过性能测试吗？知道哪些工具？你是怎么做的性能测试？
9. 讲一下你对性能测试的理解。
10. 反问：业务介绍、本次面试体验哪些地方应当改善提高。

《参考解析》

网络七层模型按 OSI 从下到上：物理层（比特流、电气特性）、数据链路层（帧、MAC 寻址、差错检测、ARP 归属这里）、网络层（IP 寻址与路由、ICMP）、传输层（TCP/UDP，端到端、端口、流控与拥塞控制）、会话层（会话建立与同步，实际很少单独实现）、表示层（编码、加密、压缩）、应用层（HTTP/DNS/FTP/SMTP）。实际工程里更常用 TCP/IP 四层或五层模型：网络接口层、网络层、传输层、应用层。面试官问这题通常是想让你往下延伸到具体协议：HTTP 属应用层、依赖传输层 TCP、靠 IP 在网络层寻址、最终封装成以太网帧在链路层传输；每层加自己的头（封装/解封装），MTU 1500 决定了 IP 分片。能主动说出「OSI 是参考模型、TCP/IP 是事实标准，实际协议栈把上三层合并成应用层」，答案的层次就出来了。

Python 与 Java 的差异从四个维度答。① 类型系统：Python 是动态强类型（运行时才检查类型，变量只是名字绑定），Java 是静态强类型（编译期检查，类型是变量的属性）；这决定了 IDE 补全、重构和大型工程可维护性的差别。② 运行方式：Python 是解释执行（CPython 有字节码 + GIL），Java 是编译成字节码跑在 JVM 上，JIT 把热点代码编译成机器码，所以 CPU 密集场景 Java 通常更快；Python 靠 C 扩展（NumPy/PyTorch）在数值计算上反超。③ 并发模型：CPython 有 GIL，多线程不能并行执行字节码，所以 CPU 密集要用多进程或 C 扩展，I/O 密集可以用 asyncio；Java 是真线程模型，java.util.concurrent 生态成熟。④ 生态与工程：Java 的 Spring 系、强类型、Maven/Gradle 让它更适合大型企业系统；Python 的脚本能力、数据与 AI 生态让它在测试、运维、算法侧更顺手。落到测试开发岗位上可以补一句：「写测试框架和工程化用 Java 更稳，写自动化脚本和造数据用 Python 更快」，显示你知道工具选择要跟着场景走。

Python 的装饰器本质是「接收函数（或类）作为参数、返回新可调用对象的高阶函数」，语法糖 @decorator 等价于 func = decorator(func)。用途是横切关注点：日志、计时、重试、缓存（functools.lru_cache）、权限校验、参数校验、pytest 的 @pytest.fixture/@pytest.mark.parametrize。写自定义装饰器时必须用 functools.wraps 保留原函数的 __name__/__doc__（否则调试和测试收集会出问题），带参数的装饰器要三层嵌套（decorator(arg) → wrapper(func) → inner(*args)）。常见追问是「多个装饰器的执行顺序」——从下往上包裹、从上往下执行（@A 在 @B 上面时等价于 A(B(f))，调用时先进入 A 的前置逻辑），以及「装饰器与闭包的关系」（装饰器靠闭包保存原函数引用）。测试岗的加分点是举自己写过的例子：比如写一个 @retry(times=3, backoff=1) 或 @measure_time 用在自动化用例上。

性能测试是这题的主菜，按「目标 → 指标 → 工具 → 方法 → 分析」五步答。目标先明确：是压测容量（找系统上限）、验证瓶颈（定位某个模块）、还是回归对比（版本间性能不退化）——目标不同，压测模型完全不同。核心指标：TPS/QPS、响应时间（平均、P50/P90/P95/P99，一定要看尾部而不只是平均）、并发数、错误率、资源水位（CPU、内存、GC、磁盘 I/O、网络、连接池）。要先讲清并发数与 TPS 的关系不是线性的：并发增加，TPS 先升后平，再到某个点因为资源竞争或排队而下降、响应时间陡增，那个拐点就是容量上限。工具：JMeter、Locust、Gatling、wrk、ab、k6，以及云压测服务；测试岗还要能写脚本而不是只会用 GUI。方法：先做基准压测拿基线 → 逐步加压（阶梯式或定并发持续压）→ 观察指标拐点 → 用 APM/arthas/perf/top 定位瓶颈（是 CPU、GC、锁、数据库还是下游依赖）→ 优化 → 复测对比（同一份脚本和数据集，控制变量）。容易踩的坑要主动说：压测机自己成为瓶颈（用多台分布式压测或先确认压测机水位）、测试数据不具备代表性（热点分布、数据量级）、只压单接口不看混合场景、没有做预热（JIT 和缓存需要预热）、忽略下游限流和缓存命中率的影响。

「对性能测试的理解」这题要给观点而不是罗列工具。可以说：性能测试的价值不在「跑出一个 TPS 数字」，而在用可控的方式提前暴露系统在压力下的失效模式——是哪个资源先到顶、到顶之后是降级还是雪崩、恢复要多久。所以一次合格的性能测试必须同时产出三样东西：容量结论（能扛多少、留多少余量）、瓶颈清单（按影响排序）、改进与复测记录。测试开发的角色偏向「把这件事工具化和自动化」：把压测脚本纳入 CI（每次发版跑基准场景做性能回归，超阈值就拦住）、统一指标采集与报告模板、把环境差异（数据量、机器规格）写进结果，避免不同人跑出不可比的数字。

关于「面试官先问基础还是先问项目」，这位作者总结了一个观察：先问项目再转基础知识，往往意味着面试官对你的项目经历不太满意、想再从基础侧面看看；而先问基础知识再聊项目，说明还有深聊的余地。这个判断不必当成铁律，但有用的一点是：被问到基础八股时，可以主动把话题接回自己的项目（「这个概念我在 XX 项目里用过，当时是这么处理的」），比干背定义更容易把面试拉回你熟悉的区域。回头看第一问「难点在哪里」，准备时按「现象 → 定位手段 → 根因 → 改法 → 怎么证明改好了」五段写一遍，是测试岗最能加分的叙事结构。