你的设计文档被同事评价"读不懂"，面试官问你怎么看待这个反馈，你如何论证？
说"读不懂"是很有价值的反馈，因为它暴露了"我写文档时把自己当成了唯一的读者"。这样回应：先承认这是一个真实存在的不足，说明我写文档时可能用了太多术语和跳步，没有从"新读者"的视角组织。然后给出具体的改进：补充背景与目标、用图示代替长文、先给结论再给细节、找同事预读。最后说"我欢迎这种反馈，因为它帮我培养'以读者为中心'的写作"。
面试官问"怎么看反馈"，本质是考察你"是否虚心、能否自我迭代"。正确的回应是接纳反馈、分析原因、给出改进，而不是辩解"同事不懂"。展示你"把反馈当学习资源"的心态，比文档本身更重要。
面试官质疑你的设计文档在团队 review 时没人提反对意见、是不是走形式，你如何论证？
承认"没人提反对意见"既可能是好事也可能是坏事：好事是方案设计得周全、考虑充分；坏事是评审可能走过场、大家没认真看。然后说明我如何让评审有效：主动邀请持有不同意见的人、先列出我方案中的已知风险和取舍、请 reviewer 专门挑战"哪里可能出问题"。如果确实没人反对，我会主动问"这是不是说明我有盲区"。展示你"不满足于走形式，主动求真实反馈"。
面试官问"没人反对是不是走形式"，是考察你"是否把评审当真"、以及"是否自己发现了盲区"。关键是要警惕"零反对"的成功假象，主动制造质询，这才是成熟的评审心态。
面试官质疑你的项目做了视觉回归测试但缺少基础用例库、测试体系不完整，你如何论证补齐路径？
承认只做视觉回归测试、缺少基础用例库是"测试体系"的失衡——视觉回归管的是"界面是否突变"，但基础用例管的是"功能是否正确"，两者是不同层级。然后给出补齐路径：先补核心业务流程的用例（happy path），再补边界与异常，最后把视觉回归与功能测试结合。说明"我没有只堆一种测试，而是理解测试分层，并知道按优先级补齐"。
面试官问测试体系不完整，是考察你"是否理解测试金字塔/分层"。视觉回归只管外观，基础用例管功能，缺一不可。关键是要给出结构化补齐路径，展示你懂"测试分层 + 优先级"。
面试官质疑你的设计文档写在公司私有的 Confluence 里，问能展示吗，你如何论证？
说明我能展示的边界：涉及公司商业机密或客户数据的具体内容不能公开，但"设计方法、架构思路、权衡取舍"这类可抽象的部分可以公开。然后给出抽象方案：把 Confluence 里的设计提炼成一份"脱敏版"——去掉敏感信息，保留架构图、决策树、tradeoff 分析，用通用示例替代具体业务。展示"我理解保密边界，也懂得如何把可分享的部分讲清楚"。
面试官问公司私有文档能否展示，是考察你"保密意识"与"抽象表达能力"的平衡。正确做法不是"不能展示"一刀切，而是抽象出可公开的核心知识，既守住保密边界又展示能力。
面试官质疑你的设计文档只考虑了 happy path、没考虑异常情况，你如何论证？
承认这是设计文档的真实不足，说明"只考虑 happy path"会让设计在真实场景中失效——真实系统大量时间在跑异常路径（超时、失败、重试、数据不一致）。然后给出改进：补充异常路径设计（失败重试、降级、超时、幂等、数据一致性），并为每个异常场景定义处理策略。同时说明我理解"健壮性来自对异常的周全设计"，会把异常路径作为设计文档的必备章节。
面试官问只考虑 happy path，是考察你"是否具备应对真实复杂性的设计思维"。Happy path 是理想，异常路径才是真实世界。关键是承认盲区并展示你会系统补全异常设计。
你的设计文档被 leader 说"太学术化"，面试官问为什么这样写，你如何论证受众意识？
承认"太学术化"是真实的反馈，说明我写文档时可能追求了"严谨、完备"，但忽略了受众是"要快速决策的工程团队"，而不是"审论文的评委"。然后给出改进：先讲结论和决策，再给背景；多用示例和图示，少用抽象术语；按"读者要做什么"来组织。同时说明我理解"文档风格要匹配受众"，leader 的反馈让我调整了写作方式。
面试官问"为什么这样写"，是考察"你是否理解文档要服务受众"。太学术化说明你把"严谨"置于"可读"之上。关键是要承认并展示你会按受众调整风格，而不是为"学术化"辩护。
面试官看穿你的设计文档里"参考 XX 项目"其实是 copy，你如何论证学习？
诚实承认这确实不是单纯的"参考"，我需要说清楚我的真实行为：如果我照搬了别人的设计，那就是 copy，不是参考，这不够诚实。但如果我是在理解其原理后，针对自己的场景做了适配和取舍，那我可以讲清楚"我借鉴了什么、我改了什么、为什么"。关键是把"学习"讲清楚：说明我如何从别人的方案中提炼可迁移的原则，并结合自己的约束做了调整。如果确实是 copy，诚实承认并说明这是学习初期的产物，现在已经学会"带着分析去参考"。
面试官看穿 copy，是考察"诚实度"和"学习能力"。对"参考"的合理定义是"借鉴思想、结合自身场景适配"，而不是照搬。核心是诚实区分，并展示你"带着分析去学习"而非"复制"。
面试官质疑你的设计文档有 30 页但没人看，你如何论证信息密度？
承认"30 页没人看"恰恰说明文档没帮到读者，长度不等于价值。然后说明我的理解：文档的信息密度和结构比篇幅更重要，一个好的设计文档应该"结论先行、可快速扫读、关键决策有据可查"。给出改进：把 30 页压缩成"1 页摘要 + 分层详述"，摘要给决策者，细节给深入者；删除冗余，把核心"为什么、权衡、风险"放最前。展示"我懂文档要服务于读者，而非满足自己的完备欲"。
面试官问"为什么不写短点"，是考察你"是否理解文档的价值密度"。30 页没人看是典型的"自嗨型文档"。关键是要理解"信息密度 + 分层 + 结论先行"，而非堆篇幅。
面试官质疑你的设计文档没有版本演进记录（v1/v2/v3），你如何论证演进过程？
承认没有版本演进记录是真实的不足，说明版本记录能体现"设计如何随约束变化而演进"，这是很宝贵的资产。然后给出两种补救：一是如果文档管理工具支持历史，说明"演进过程其实留在 git 历史里"，用 git log 展示；二是说明我理解"设计文档应记录决策的演变"，补一份"演进摘要"（v1 解决了什么、v2 因什么约束改了、v3 现状），让读者看到取舍链条。展示"我懂演进记录的价值，并会用 git/文档补上"。
面试官问版本演进，是考察你"是否有记录决策演变"的意识。设计会随约束变化，演进记录能体现你的迭代思维。关键是要展示"演进过程可追溯"，无论是 git 历史还是补摘要。
面试官质疑你的设计文档被 leader 大改后只有 30% 是你写的，问哪些是你真实想法，你如何论证？
诚实回答"哪些是真实想法"：明确区分原始设计里我的核心观点、被 leader 修正的部分、以及我最终认同的部分。承认"leader 大改"说明我的初稿有不足，但也要说明我从中学会了什么——比如 leader 改在哪里、为什么改、我的原始想法错在哪。然后说明"真实想法"不等于"最终文本"，我认可 final 版本是因为理解了它的合理性，而不是被动接受。展示"我既能诚实归因，也能从修改中学习"。
面试官问"哪些是你真实想法"，是考察"诚实与所有权认知"。关键不是掩盖"被改了很多"，而是诚实划分贡献、并展示你从 leader 的修改中理解了更优方案。承认被改 + 说明学到什么，比硬撑"都是我写的"更成熟。
你的设计文档被业务方说"看不懂"但 leader 说"必须写得详细"，你如何处理这种矛盾？
说明这个矛盾其实源于"同一份文档试图服务两类不同读者"：业务方需要"业务视角、结果导向"，leader 需要"技术细节完整"。正确解法不是二选一，而是"分层"：提供一份面向业务方的摘要（讲清楚做什么、价值、风险、时间），和一份面向技术评审的详述（架构、权衡、细节）。两者通过链接关联。这样既满足 leader 的"详细"，又满足业务方的"看得懂"。展示"我理解多受众，会用分层文档化解矛盾"。
面试官问业务方与 leader 的矛盾，是考察"多受众文档的分层能力"。这不是"听谁的"问题，而是"用不同文档层服务不同角色"的问题。关键是展示分层思维，而非讨好某一方。
面试官质疑你的设计文档里有 tradeoff 分析但结论是错的，问为什么不重新分析，你如何论证？
承认 tradeoff 结论错了是真实的，但关键是区分"分析过程"和"结论正确性"：错误结论说明我的分析依据（数据、假设、权重）有偏差。然后说明我会重新分析：检查我做 tradeoff 时的假设是否成立、数据是否准确、权重是否合理，用新的证据重新评估。同时说明"重新分析"不是推翻，而是迭代——记录旧结论为何错、新结论为何对。展示"我懂 tradeoff 是动态的，结论错了就要重新决策"。
面试官问"为什么不重新分析"，是考察你"是否被错误结论困住"或"是否愿意迭代"。诚实承认 + 展示重新分析的方法论（重查假设、数据、权重），比坚持错误结论或全盘否定更有说服力。
面试官质疑你的设计文档只有 1 页、不够深入，你如何论证简洁与深度的平衡？
说明"1 页"不等于"浅"，关键是这一页里写了什么：如果 1 页里包含了目标、约束、决策、权衡、风险，那它就是高密度的深入文档。解释"简洁"是刻意为之——把无关废话删掉，保留核心决策与理由。然后说明"深度"可以分层：1 页是入口，详细推导可以放附录或口头展开。如果确实因为 1 页而漏了关键权衡，则承认并补充。展示"我懂简洁是为深度服务，不是牺牲深度"。
面试官问 1 页不深入，是考察你"是否理解简洁与深度的关系"。深度来自"决策与权衡的密度"，而非篇幅。关键是展示 1 页里承载了核心决策，并可用分层补足细节。
面试官质疑你的设计文档没有 Mermaid 等图表、要求现场画图，你如何论证？
承认设计文档没有图表是真实的不足，说明"图文结合"能显著提升理解效率，尤其架构图、流程图、时序图。然后应对现场要求：当场用 Mermaid 或白板/画图工具画出关键架构或流程，展示"我脑子里有清晰的图景，只是没提前写进文档"。同时说明我会把图表作为文档的必备部分（架构图、数据流、时序图）补上。展示"我不仅能讲，还能画"。
面试官要求现场画图，是考察"你是否真的理解系统结构"。图表是"想清楚"的体现。关键是能当场画出核心结构，并说明以后会把它写进文档，而不是被"没图表"将住。
面试官质疑你的设计文档被 PM 说"技术导向不是业务导向"，你如何论证平衡？
承认我的文档确实偏技术导向，说明我写文档时站在了"实现者"视角。然后说明如何平衡：把技术方案翻译成业务语言——先讲"这个方案解决什么业务问题、带来什么价值、有什么风险"，再落到技术实现。技术细节是支撑，业务价值是主线。同时说明我理解 PM 需要的是"决策依据"，而不是"实现细节"。展示"我懂技术文档要给业务决策者看，需要用业务语言讲清价值"。
面试官问技术导向 vs 业务导向，是考察你"能否从业务视角看技术"。关键是理解文档的读者不只是工程师，还有业务方。用"业务价值为主线、技术为支撑"的写法，是平衡两者的关键。
面试官质疑你的设计文档里方案被 CTO 否了，问为什么没坚持，你如何论证？
说明"没坚持"不一定是软弱，关键是区分"盲从"和"理性妥协"：如果 CTO 否的方案理由充分（比如有更优解、有我没考虑到的约束），那我接受并理解了为什么；如果 CTO 的理由缺乏依据，我本应进一步论证。诚实回顾当时的情况：我是"理解了所以接受"，还是"有异议但没表达"。展示"我理解坚持要基于论据，妥协要基于理解，而不是一味迁就或被否定就放弃"。
面试官问"为什么没坚持"，是考察"你是否有独立判断和理性坚持的能力"。正确回答不是"我该誓死坚持"，而是区分"被合理说服"与"盲从"。诚实反思你有无异议、是否表达，是成熟的表现。
面试官质疑你的设计文档里 QPS 预估与实际不符，你如何论证为什么预估错？
承认 QPS 预估与实际不符，但要分析"为什么错"——预估偏差通常源于几个因素：流量假设不准、业务模型简化、忽略了峰值/读放大/缓存命中率等。诚实说明我预估时的假设是什么、哪个假设错了、实际数据如何。然后说明改进：用真实的压测数据和监控数据校准，预估要留足余量，且把"预估-实测-校准"作为迭代闭环。展示"我懂性能预估是估计而非确定，且会持续校准"。
面试官问 QPS 预估错，是考察你"是否理解预估的局限"和"能否诚实复盘"。预估错是常态，关键是能否分析出偏差的根因（假设、模型、数据），并展示用实测数据校准的闭环方法。
面试官质疑你做的项目上线后出了 race condition bug，问为什么没做并发测试，你如何论证？
承认 race condition 是测试盲区导致，说明"并发类 bug 用普通单线程测试很难发现，需要专门的并发测试"。坦率讲：我当时没有做并发/竞态测试，这是我的疏忽。然后给出补强：用并发测试工具（如 race detector、stress test、并发压力测试）覆盖共享状态与并发路径，并在 CI 中跑。同时说明我理解"并发 bug 的隐蔽性"，会主动把并发测试纳入测试策略。展示"我承认盲区，并知道怎么补"。
面试官问"为什么没并发测试"，是考察你"是否理解并发测试的价值"和"是否诚实"。race condition 是并发测试缺失的典型后果。关键是要承认盲区、给出补强方法，而不是辩解"并发 bug 难测"。
面试官质疑你做的项目上线后频繁出边界 case bug，问为什么不测试边界，你如何论证？
承认边界 case bug 频发说明"边界测试"做得不到位，坦率讲这是我的测试策略盲区——我可能只测了正常输入，忽略了空值、极值、超长、并发下的边界。然后给出补强：系统梳理边界（空/最大值/最小值/非法类型/超长/空集合），用边界值分析和等价类测试覆盖，增加 property-based testing 自动生成边界输入。展示"我懂边界测试是测试质量的关键，会用系统方法补强"。
面试官问"为什么不测试边界"，是考察你"是否理解边界测试的价值"。边界 bug 频发是典型的测试覆盖不足。关键是要承认盲区、给出系统补强方法（边界值分析、等价类、property-based testing）。
面试官质疑你的项目里有测试但全是手动测试、没有自动化，你如何论证工程化？
承认全是手测、没有自动化是真实的工程化短板，说明手测"不可重复、不可回归、随着规模变大必然遗漏"。坦率讲：这是初期项目图省事，但我知道这不是正确做法。然后给出自动化路径：把高频回归的手测用例转成自动化测试，接入 CI，设置覆盖率目标，让"跑一次测试"成为常态。展示"我理解自动化的价值，也知道怎么把手测迁移到自动化"。
面试官问全手测，是考察你"是否理解自动化测试的价值"。手测在规模小时可应付，但不可回归。关键是承认并给出自动化迁移路径，展示工程化意识。
面试官质疑你的项目里有测试但被测试的对象已经 deprecated，你如何论证测试维护？
承认测试对象已 deprecated 说明"测试没有跟上代码演进"，这是测试维护的失职。说明"测试过时"比"没测试"更糟，因为它会给人虚假的安全感。然后给出处理：评估这个 deprecated 接口是否还有代码在用，若有则更新测试对象，若已移除则删除或改写测试。同时说明我理解"测试要和代码同步维护，deprecated 的对象要清理"。展示"我懂测试维护，会清理过时测试"。
面试官问测试对象 deprecated，是考察你"是否重视测试维护"。过时的测试是负债。关键是要承认"测试没跟上代码"，并展示清理/更新的维护意识。
面试官质疑你的项目里修复 bug 时测试改动没人 review，你如何论证质量？
承认"修 bug 时测试改动没人 review"是质量流程的漏洞，说明测试改动如果不 review，可能掩盖问题或引入新的错误。然后说明我理解的重点：测试本身也是代码，需要被 review；修 bug 时改测试要说明"为什么改、改了什么、是否削弱了覆盖"。给出改进：把测试改动纳入强制 review，提交时说明测试变更理由。展示"我懂测试是质量的第一道防线，也需要被审查"。
面试官问修测试没人 review，是考察你"是否理解测试 change 也要被审查"。测试是质量保障，如果不 review 就失去了可信度。关键是要承认流程缺失并展示你会补上。
面试官质疑你的项目 CI 跑了但 deployment 测试经常失败，问为什么不修复，你如何论证？
承认 deployment 测试经常失败却没修复，是真实的懈怠，说明"CI 绿灯 + 部署测试红灯"是自相矛盾的，会让 CI 失去意义。坦率讲：可能是部署测试依赖真实环境、或 flaky，我选择忽略而没认真处理。然后给出修复计划：定位失败的根因（环境依赖、flaky、配置），修复后让部署测试也稳定通过，并设置"部署测试失败即阻断发布"。展示"我理解 CI 必须可信，部署测试失败必须修复而非忽略"。
面试官问为什么不修复部署测试失败，是考察你"是否严肃对待 CI 可信度"。让部署测试长期红灯是自欺。关键是要承认、定位根因、修复，并让失败阻断发布。
面试官质疑你的项目上线后出 bug，而测试报告显示通过但实际有逻辑漏洞，问为什么没测到，你如何论证？
承认"测试通过但没测到逻辑漏洞"是测试有效性的问题，说明"测试通过"不等于"逻辑正确"，可能因为：测试基于错误的假设、没覆盖那条逻辑路径、或断言不够严格。然后诚实分析这次 bug 为什么没测到，并给出补强：用更强的断言、覆盖分支而非仅行、补边界与组合场景、用 property-based testing 探索意想不到的输入。展示"我理解测试通过≠正确，会系统补测试盲区"。
面试官问"为什么没测到"，是考察你"是否理解测试局限与盲区"。测试通过但漏逻辑是常见问题，根因常是假设错误、覆盖不足、断言弱。关键是要诚实分析并给出补强。
面试官质疑你的项目测试全是单元测试、没有 E2E，你如何论证？
承认只有单元测试没有 E2E 是测试金字塔的失衡，说明单元测试验证"零件"，E2E 验证"整机装配"，两者互补。坦率讲：E2E 成本高、易 flaky，我可能为了省事跳过了。然后给出补强：至少补 1-2 条覆盖核心业务闭环的 E2E 用例，用测试框架（如 Playwright/Cypress）跑通"用户主流程"，并说明 E2E 应聚焦关键路径而非全量。展示"我理解测试分层，知道 E2E 的价值与适量原则"。
面试官问缺 E2E，是考察你"是否理解测试分层"。单元测试验证局部，E2E 验证完整流程。关键是要承认失衡并给出补强（补核心闭环 E2E），同时体现"E2E 要适量"的成熟判断。
面试官质疑你的项目测试数据全是 mock 的，问真实数据测试过吗，你如何论证？
诚实回答：mock 数据方便可控，但真实数据有重复、脏数据、超长、特殊字符、分布不均等，mock 未必覆盖。然后区分：哪些场景我用了真实数据验证（如导入真实 CSV 跑过）、哪些只用 mock。承认"真实数据验证不足"是真实短板，并给出补强：用抽样的真实数据跑测试、做数据脱敏后用于测试、用真实数据做 sanity check。展示"我理解 mock 与真实数据差异，会用真实数据补验证"。
面试官问真实数据测试过吗，是考察你"是否理解 mock 的局限"。mock 数据可控但可能失真。关键是要诚实区分真实/mock 验证情况，并给出用真实数据补强的方案。
面试官质疑你的项目测试覆盖率 80% 但大多是 getter/setter 测试，你如何论证"有意义覆盖"？
承认 80% 覆盖率里大多是 getter/setter 测试，说明这个数字是"虚高"的，没有反映真实的核心逻辑覆盖。正确理解：getter/setter 这种"只读/只写"代码覆盖率意义有限，真正有价值的是核心业务逻辑、分支、异常路径的覆盖。然后给出改进：把测试重心转向核心逻辑，用"分支覆盖"和"突变测试"衡量有意义覆盖，并把 getter/setter 这类低价值测试排除在覆盖率统计之外。展示"我懂覆盖率不是越高越好，而是要看覆盖了什么"。
面试官问"有意义覆盖"，是考察你"是否理解覆盖率指标的正确用法"。描述性代码（getter/setter）拉高覆盖率但不代表质量。关键是要展示你懂"覆盖率要衡量核心逻辑"，而非迷信数字。
面试官质疑你的项目 mutation testing score 很高但实际 bug 很多，你如何论证测试有效性？
承认 mutation score 高但 bug 多，说明"指标漂亮"和"真实质量"脱节，可能有几个原因：突变测试覆盖的代码本身不是核心逻辑、或者突变测试的配置（多少突变、哪些算子）选择不当、或者 bug 出在突变测试没覆盖的路径。诚实分析后说明：mutation testing 是"测试有效性"的参考，但不是质量保证，真正的质量来自对核心逻辑的覆盖与运行验证。然后给出改进：让 mutation testing 聚焦核心模块，结合真实 bug 复盘补测试。展示"我懂指标可能失真，会用真实结果校准"。
面试官问 mutation score 高但 bug 多，是考察你"是否理解指标的局限"。任何单一指标都可能失真。关键是要诚实分析指标与真实质量脱节的原因，并展示用真实结果校准的方法。
面试官质疑你的项目里有 contract 测试但没强制执行，问为什么，你如何论证？
承认 contract 测试"写了但没强制执行"是真实的缺陷，说明"有测试但不强制"等于形同虚设——不强制就不能保证契约在 CI 里被验证。坦率讲：可能是为了让 CI 快速通过、或遗漏了接入。然后给出补强：把 contract 测试接入 CI 作为强制步骤，失败即阻断合并，并说明"contract 测试的价值在于强制，否则无意义"。展示"我理解 contract 测试必须强制执行才有效"。
面试官问 contract 测试没强制，是考察你"是否理解测试的价值在于强制执行"。有测试不强制等于摆设。关键是要承认并给出"接入 CI 强制阻断"的补强。
面试官质疑你的项目里有测试但 flaky（不稳定），你如何论证测试质量？
承认 flaky 测试是测试质量的重大隐患，说明 flaky 会让 CI 结果不可信，进而导致"测试失败被忽略"。坦率讲：flaky 通常源于时序、外部依赖、随机、环境差异。然后给出处理：定位 flaky 根因（重试掩盖还是真实问题）、消除不稳定因素（固定种子、mock 外部依赖、检查全局状态）、对偶发失败用重试但要记录。展示"我理解 flaky 是测试负债，必须严肃消除"。
面试官问 flaky 测试，是考察你"是否重视测试稳定性"。flaky 会让测试失去可信度。关键是要承认并给出定位根因、消除不稳定因素的方案，而不是"重试掩盖"。
面试官质疑你的项目测试运行很慢（30 分钟），你如何论证开发体验？
承认 30 分钟的测试很慢会严重拖累开发体验，说明"反馈延迟"会让开发者不愿跑测试、bug 发现滞后。然后给出优化：分层测试（快的单元测试即时跑，慢的集成/E2E 单独跑或按需跑）、并行化、减少不必要的 IO/网络、用缓存与增量测试。同时说明我理解"测试速度是工程质量的一部分"，会为"快速反馈"优化。展示"我懂测试要快，才会被真正使用"。
面试官问测试慢，是考察你"是否理解测试速度对开发体验的影响"。慢测试会让人回避测试。关键是要给出分层、并行、缓存等提速方案，体现"快速反馈"意识。
面试官质疑你的项目测试覆盖率按行算很高但按分支算很低，问为什么不用 branch 覆盖率，你如何论证？
承认我选行覆盖率是一个"更容易好看"的指标，而分支覆盖率更能反映"逻辑路径是否被覆盖"。诚实说明：行覆盖率高但分支低，可能是因为我用了行覆盖来"显得高"，而没有真正覆盖所有逻辑分支。然后给出改进：改用分支覆盖率作为质量指标，补足未覆盖的分支（if/else、循环、异常路径），并说明"分支覆盖率更能反映测试有效性"。展示"我理解会选更有意义的指标，不自我粉饰"。
面试官问为什么不用 branch，是考察你"是否理解覆盖率指标的含义"。行覆盖忽略分支逻辑，易虚高。关键是诚实承认，并选择能反映逻辑路径的分支覆盖。
面试官质疑你的项目用了 property-based testing 但覆盖率低，你如何论证方法选择？
说明 property-based testing 的价值不在于拉高"覆盖率"，而在于"用大量自动生成的输入验证属性（不变量）"，它能发现手工测试想不到的边界组合。所以"覆盖率低 + property-based testing"并不矛盾——它覆盖的是"性质"而非"行"或"分支"。然后说明我用它的理由：对算法/状态转换类逻辑，property-based 比手写用例更有效。同时承认如果覆盖率确实低，说明 property-based 用例覆盖的模块少，会补充针对性用例。展示"我理解不同测试方法各有侧重，会选择合适的方法"。
面试官问 property-based testing 覆盖率低，是考察你"是否理解该方法的适用场景与指标"。property-based testing 探索性质而非提覆盖率。关键是要解释方法的选择逻辑，同时诚实评估覆盖。
面试官质疑你的项目里有 mutation testing 但分数不高，你如何论证测试深度？
承认 mutation score 不高说明"测试深度"确实不足，因为 mutation testing 会注入 bug，看测试能否发现，得分低意味着测试没抓住某些变异。诚实说明：这暴露了测试断言不够强、或某些路径没覆盖。然后给出提升：针对未杀死突变的用例，加强断言、补覆盖、或调整测试策略。同时说明"mutation testing 帮我找到了测试盲区，这是它的价值"。展示"我承认低分，并把它当作改进测试深度的信号"。
面试官问 mutation 分数不高，是考察你"是否理解 mutation testing 的意义"和"能否诚实提升"。低分说明测试深度不足。关键是要承认并把它作为查漏补缺的信号，而非辩解。
