狄耐克软件测试岗面试：用例设计与 bug 提交

《面试题目》

1. 自我介绍。
2. 计算机专业更多不是做研发吗，为什么想做测试？
3. 1000+ 多条测试用例，实际迭代了多少条用例？
4. 需求评审阶段会做什么计划？
5. 测试计划是怎么制定的？
6. 测试项目会做总结吗，怎么做？
7. 有了解嵌入式测试吗？
8. 提交的 bug 要包含什么？
9. 输入框限定 1~50，用等价类怎么设计用例？
10. 要测试摄像功能，你会怎么设计测试用例？
11. 接口测试要怎么做？
12. 你觉得自己性格怎么样？
13. 对加班什么看法？
14. 开发觉得不是 bug，你怎么做？
15. 怎么样能快速融入团队？
16. 实习过程中有遇到压力大的事吗？
17. 网页测试有进行弱网测试吗？
18. 做完手头上的任务，是会主动找人要活干还是等着分配任务？
19. Linux 的命令还记得哪些？
20. 对网络了解怎么样，知道汽车模型吗？

《参考解析》

「为什么做测试」这题要答成职业选择，不能答成退而求其次。 说「研发太卷所以来做测试」等于自报没有内驱力。可用的角度有三个：一是测试的产出直接对应质量与线上事故，价值可量化；二是测试需要横跨产品、开发、运维的视野，能更快理解整个系统，很多测试后来转产品、转研发、转质量架构都是这条路；三是自己的性格与能力确实匹配——喜欢把边界情况想全、对不一致的地方敏感、能接受重复性工作并把它自动化掉。最后落到「我打算怎么在这个岗位上成长」，比如先熟悉业务和用例体系，再往接口自动化、性能、质量度量方向走，让人觉得你有长期打算。

用例量与迭代次数这类问题的考点是「你有没有真正维护过用例」。 1000 多条用例，迭代中真正执行、真正被改动、真正被淘汰的分别是多少，是三个不同的数。回答要给结构：新需求新增多少、需求变更修改多少、线上问题回流补了多少、废弃删掉多少，以及哪些是核心回归集（每次都跑）、哪些是选跑集。同时说清用例的维护机制——用例挂在哪（用例管理平台还是 Excel）、有没有和需求编号双向关联、失效用例的剔除规则。能报出「核心回归集只占两成但覆盖八成风险」这种结构化的结论，比报一个大数字有说服力。

需求评审与测试计划的输出物要说具体。 需求评审阶段的动作：提前读需求和原型、把疑问列成清单当场提（歧义、缺失的异常流程、影响范围、兼容性要求），评审后输出测试范围与测试点清单、风险与依赖清单（哪些要第三方配合、哪些环境难准备）。测试计划的要素固定为六项：测什么（范围与不测什么）、怎么测（策略、用例设计方法、自动化范围）、谁来测（人力与排期）、用什么环境与数据、进入与退出标准（用例执行率、通过率、遗留缺陷等级分布）、风险与应对。答的时候要强调「退出标准」——面试官很爱追问「你怎么判断这版可以发了」，答「用例都跑完」是错的，正确的口径是：关键用例全通过、遗留缺陷满足等级门槛（比如没有未解决的高等级缺陷）、核心回归通过，且已知风险已经明确记录并由产品确认接受。

bug 单的要素是固定八项，缺一项就会被开发打回。 标题（一句话说清现象与位置）、环境（版本号、机型、系统、账号、网络）、前置条件与数据、复现步骤（编号、可照做）、实际结果、期望结果、复现概率、附件（截图、录屏、日志、抓包与请求 ID）。再补两条经验：一是提交前自己按步骤从零复现一遍，确认不是脏数据或缓存导致；二是给现象加定位线索（比如报错堆栈、接口响应、时间点），能显著缩短开发定位时间，也减少来回扯皮。

「输入框 1~50」的等价类设计要给出完整的表，而不是一句「有效等价类是 1 到 50」。 按输入维度切：有效等价类是一个（区间内的合法整数，如 1、25、50）；无效等价类至少要覆盖下界外（0、-1）、上界外（51、100）、类型不符（小数 1.5、字母、中文、特殊字符、空格与全空格）、空值与 null、首尾空格、超长输入、纯 0 开头、以及科学计数法或十六进制这类解析边界。再叠加场景维度：输入后是否保存成功、边界值是否被截断、前后端校验是否一致、提交接口是否也被绕过校验（前端限制了但接口没限制，这是常见漏洞）。边界值分析要和等价类一起用，取 0/1/2/49/50/51 这组点。答完后主动补一句「如果字段还有业务语义（比如金额、数量），还要加业务规则校验和精度处理」——这能显出你不是只会套模板。

摄像功能这类硬件相关功能的用例设计要按「维度矩阵」展开。 功能维度：拍照、录像、连拍、前后置切换、变焦、闪光灯、对焦（自动/手动/触屏）、分辨率与帧率档位、以及各档位组合是否都能生效。质量维度：成像清晰度、色彩与白平衡、强光与逆光、暗光噪点、运动模糊。兼容与资源维度：存储卡满或不可写、存储权限被拒、电量低、来电打断、后台切换、锁屏、多应用同时占用摄像头（相机被抢占时的降级行为）。异常维度：拍摄中拔卡、进程被杀后文件是否损坏、录制中断电文件能否修复。再加上性能指标：启动耗时、对焦耗时、录制时长上限、发热与掉帧。这套「功能 × 质量 × 异常 × 性能」的切法是通用的，任何硬件功能都能套。

接口测试和弱网测试的答法要点出工具与关注点。 接口测试的流程是：从接口文档或抓包拿到契约（URL、方法、鉴权方式、参数与约束）→ 用 Postman/JMeter 或代码框架构造请求 → 校验状态码、业务码、字段类型与必填、返回结构与文档一致性 → 补异常用例（缺参、越权、重复提交、超时重试、并发、幂等、边界值与类型错误）→ 沉淀成可回归的自动化集合并接入 CI。弱网测试关注的是「超时与重试策略是否正确、有没有重复提交、加载态与错误提示是否友好、断网恢复后数据是否一致」，手段包括浏览器 DevTools 的 Network throttling（离线、3G、高延迟）、Charles/Fiddler 的限速与断点、以及抓包看是否有请求被静默丢弃。顺带说一句「弱网下最常暴露的是幂等和本地缓存问题」，比只列工具更像有经验。

行为类问题只有一条答题原则：把「正确的态度」翻译成「发生过的行为」。 「加班怎么看」——不要表忠心也不要谈条件，说清自己能接受项目期的强度，同时说明自己会优先通过提高效率减少无效加班，并举一个自己排期、提前交付的例子。「开发说不是 bug」——先自查是否按文档和需求判断、是否能提供复现与证据；再拉上产品对齐「预期到底是什么」；判断标准以需求和文档为准，都不明确就走评审记录，从不在群里争论。这类问题的反例都是「我会据理力争」「以理服人」这种空话。「主动要活还是等分配」要答「做完先自检和补用例，再同步进度并主动认领下一块，同时把可复用的部分（脚本、用例模板）沉淀下来」，这才是有产出的主动性。压力大的经历用 STAR 讲一个真实的、有结果的故事，落到「我现在处理同类问题的做法变了」。