Question 1

给一个登录功能设计测试用例

Accepted Answer

我按三层展开而不是罗列点子：功能层用等价类+边界值——正确账密、错误密码 1/N/N+1 次触发锁定、空输入、超长输入、大小写与前后空格；安全层覆盖 SQL 注入、暴力破解限频、密码是否明文传输/回显、验证码绕过；非功能层补并发登录、弱网超时重试、多端登录互踢和会话过期。写完我会做优先级标注：P0 是主流程+锁定+注入这类上线必测，探索性场景标 P2。我的习惯是最后反问一句需求边界——比如「是否支持第三方登录」，因为用例设计考察的第一件事其实是需求澄清能力，直接埋头写恰恰是扣分项。

Question 2

哪些用例值得自动化？怎么衡量自动化收益？

Accepted Answer

我的标准是三个：执行频率高（每次回归都要跑）、路径稳定（UI 不常改）、跨环境重复（多浏览器/多机型）——同时满足的先自动化；探索性测试、一次性验证和 UI 频繁变动的页面留人工。我反对「自动化率」这种虚指标，收益要算三笔账：回归耗时（我上一个项目从 3 人天压到 40 分钟）、自动化拦截的缺陷数（每月看报表，连续为零的用例集要审视）、维护成本（用例失败中「脚本坏了」占比超过 30% 就说明选错了层级，该下沉到接口层）。我们后来把 60% 的 UI 用例改写成接口+少量 UI 冒烟，维护成本降了一半，拦截率反而升了。

Question 3

开发不认你提的 bug，怎么办？

Accepted Answer

我先自查再沟通：把复现步骤、环境版本、日志和抓包补全，确认不是环境或数据问题——事实不完整就去争论是最伤信任的。证据齐了还被拒，我会当面（而不是在工单里来回）对齐分歧点：多数分歧其实是「是不是 bug」的口径问题，比如需求文档没写清。这时我引用需求或让 PM 裁决口径，而不是和开发互相说服。真是优先级分歧，就按团队的缺陷等级标准给出影响面数据（多少用户、什么场景、能否绕过）让标准说话。我处理过一个被拒三次的偶现崩溃：录屏+日志定位到特定机型内存不足，开发看完数据当天就接了。原则是对事实较真、对人客气，升级也升级「口径裁决」而不是「谁对谁错」。

Question 4

你怎么理解「质量是整个团队的事」？落地做过什么？

Accepted Answer

我的理解是：测试的职责不是「把住最后一道门」，而是让缺陷在更便宜的阶段被发现。我落地过四个动作：需求评审时提可测试性问题（这个规则的边界值是什么、失败态怎么提示），当场消灭歧义；和开发约定单测覆盖底线并进 CI 卡口；提测必须过冒烟准入，不达标打回，把「边测边修」的成本还给开发侧；上线走灰度+核心指标监控，把生产当最后一层测试网。效果有数字：这套机制跑半年后，提测打回率从 35% 降到 8%，回归周期从 3 天缩到 1 天，线上 P1 缺陷半年 2 起 → 0 起。质量左移不是测试多干活，而是把质量成本显性化，让每个角色在自己最便宜的位置拦截问题。

Question 5

性能测试怎么做？指标怎么定？

Accepted Answer

我从业务模型推压测模型，而不是拍一个并发数：先拿生产峰值数据（或业务方的目标，如大促预估 QPS）定基准，按接口调用比例构造混合场景，加合理思考时间，再乘安全系数（一般 1.5-2 倍峰值）。指标分两层：服务层看 RT 分位数（P95/P99 而不是平均值，平均值会掩盖长尾）、TPS、错误率；资源层看 CPU/内存/连接池/慢查询。执行时用阶梯加压找拐点——TPS 不再线性增长、RT 开始陡升的那个点就是系统容量，比「压到多少并发不挂」有意义得多。我压过一个下单链路：拐点出现在预估峰值的 1.2 倍，瓶颈定位到数据库连接池打满，扩池+加缓存后容量提到 2.5 倍，这个结论直接写进了大促容量预案。

Question 6

发布前时间不够，测试范围怎么砍？

Accepted Answer

我按两个维度收敛必测集：变更影响面（代码 diff 涉及的模块+它们的依赖方）和业务关键度（资金、登录、核心转化链路永远在必测集里）。两者取并集是 P0，只测这些；其余明确列为「本次放弃项」，连同风险评估书面发给项目组——砍范围可以，静默砍不行，出了问题要能回答「当时是否知情」。真实案例：一次大版本提测晚了两天，我把 400 条回归压到 120 条 P0，放弃了低频设置页和兼容性矩阵的一半，同时给放弃项挂了线上监控加灰度放量兜底。结果上线后漏出 1 个低频设置页样式问题，在灰度 5% 阶段被监控发现当天修复，核心链路零事故。事后我把这次的取舍系数沉淀成了团队的发布风险评估模板。

Question 7

线上出了你测过的模块的事故，你怎么复盘？

Accepted Answer

我复盘的第一原则是先建立事实链、后谈责任：拉时间线（变更→测试→发布→告警→止损），回答三个问题——缺陷是什么机制触发的、我的用例为什么没拦住（场景缺失/测试环境与生产差异/数据构造不到位）、监控为什么没更早发现。我真实处理过一次：我测过的支付回调模块线上丢单，根因是生产有一个测试环境没有的第三方重试配置，属于环境差异导致的场景缺失。复盘时我先如实认领「用例未覆盖重试并发」这一段，然后给机制改进：用例库补回调并发场景、推动测试环境同步该配置项、给丢单加实时告警——三项都有 owner 和完成时间，一个月后同类配置差异又拦下一起潜在事故。我不接受「测试背锅」也不推诿，事故是流程的漏洞，复盘的产出必须是让同一漏洞无法再漏。

Question 8

介绍你搭建或改进过的测试体系

Accepted Answer

我最有代表性的是把一个 20 人研发团队的回归体系从纯手工改成分层自动化。改造前的痛点有数字：每次发版回归 3 人天、发布频率被压到两周一次、季度漏测事故 4 起。我的动作分三步：先做用例分层审计，把 800 条手工用例按「接口可验证/必须 UI/可删」分类，砍掉 30% 冗余；再搭接口自动化框架（pytest+allure，接 CI 每日跑），覆盖核心链路 300 条；最后留 50 条 UI 冒烟做发布前门禁。推动中最大的阻力是开发认为写接口断言拖慢交付，我用第一个月的数据说服：自动化拦截了 12 个回归缺陷，相当于省了约 6 人天修复成本。半年后回归压到 4 小时、发布提速到每周、漏测事故降到季度 1 起。我的角色是方案设计+框架搭建+跨团队推动，两名初级同学负责用例迁移。

测试工程师高频面试题：8 道必考题与作答要点