1. 开场软件测试面试到底在考什么干测试这些年我面试过不少候选人也陪很多人做过模拟面试。说句实话软件测试面试题翻来覆去就是那些经典问题但真正能答好的人不多。“软件测试20道经典面试题”这个标题在各类求职群里被传了很久很多人下载了文档背了答案一到面试现场还是露馅为什么因为光背答案不思考背后的考察点面试官随便追问一句就垮了。这篇文章我把测试面试里最高频的20道题逐题拆开讲每一题都会告诉你面试官真正想听什么、怎么答才能拿分、常见的错误答案是什么样的。面对的基础问题、用例设计题、Linux命令、MySQL查询、接口测试、自动化框架选型我都会覆盖到零基础转行的人可以把它当复习提纲有经验的人也可以用来查漏补缺。文章比较长建议收藏后对着题目先自己答一遍再看答案效果会好很多。2. 测试理论与流程这5道题答不好后面全白搭2.1 什么是软件测试它的目的是什么这道题几乎是每场面试的第一问看似简单但答得好不好直接决定面试官对你的第一印象。很多人上来就说“软件测试就是找bug”这个回答虽然不能说错但太片面了显得没有系统学过测试。我给一个比较完整的答法软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程目的在于检验它是否满足规定的需求并找出预期结果与实际结果之间的差异。目的不只是发现缺陷还包括评估软件质量、验证功能是否符合需求、降低上线风险以及为后续维护提供依据。面试官追问“测试和调试有什么区别”时你要能说清楚测试是为了发现错误而执行程序的过程调试是发现错误后定位并修复错误的过程前者是找问题后者是解决问题两者是前后衔接但性质不同的活动。这道题答到位了面试官才会觉得你是系统学过测试的而不是只会点点点。2.2 软件测试的七大原则是什么原则类问题是理论考察的重点七大原则我不建议死记硬背英文缩写最好能用中文理解后再用自己的话表达。完整的七大原则包括测试证明存在缺陷而不是证明不存在缺陷穷尽测试是不可能的测试需要基于风险分析来确定重点测试应尽早介入越早发现缺陷修复成本越低缺陷存在集群性少量模块往往集中了大部分缺陷这就是二八原则在测试中的体现杀虫剂悖论同样的用例反复执行会逐渐失效需要不断更新用例测试依赖于上下文不同场景下的测试策略完全不同电商系统和嵌入式系统的测试重点就不一样不存在缺陷的谬论没有发现bug不代表软件没有问题只是没测到而已。面试官如果追问“你怎么理解缺陷集群性”你可以结合一个真实场景来说比如在电商项目中订单模块和支付模块的bug往往占全项目bug总量的百分之七八十因为这两个模块逻辑复杂、分支多、交互频繁。这样一来理论就不只是理论而是真正指导过你的测试工作。2.3 一条完整的测试用例包含哪些要素这道题考察的是基本功面试官想确认你有没有真正写过用例而不只是看过概念。完整的测试用例通常包含以下要素用例编号、所属模块、用例标题、前置条件、测试步骤、测试数据、预期结果、实际结果、优先级、用例类型、设计人、设计日期。实际工作中用例编号往往有规范比如“LOGIN_001”标识模块加序号方便追踪和回溯。前置条件容易被新手忽略但它非常重要因为很多用例的执行依赖特定的环境或数据状态不写清楚别人根本没法执行。测试数据也要具体比如“用户名输入admin密码输入abc123”而不是笼统写“输入正确用户名和密码”。预期结果必须可验证、无歧义比如“系统提示登录成功跳转到首页并显示用户昵称”这样执行用例的人才好判断通过还是失败。面试时你可以补充一句公司里用例一般会分开维护在TestLink、禅道或者Excel里但不管用什么工具核心要素都是一样的。这会让面试官觉得你有实际项目经验。2.4 什么是等价类划分怎么用等价类划分是黑盒测试里最基础也最常用的用例设计方法属于面试必考。它的核心思想是把输入条件划分成若干个子集从每个子集中选取少量代表性数据进行测试从而用最少的用例获得最大的覆盖率。具体分两步。第一步划分有效等价类也就是符合需求、合法的输入集合第二步划分无效等价类也就是不符合需求、非法的输入集合。在实际面试中面试官可能会让你现场对一个输入框做等价类划分比如“用户名长度为6到18位只能包含字母和数字”这时候你要能快速回答有效等价类包括长度在6到18位之间且只包含字母和数字的字符串比如“abc12345”无效等价类包括长度小于6位的、长度大于18位的、包含特殊字符的、包含中文的、为空的。每个有效等价类至少取一个用例每个无效等价类也至少要有一个用例覆盖因为无效等价类是验证系统容错能力的关键很多新手只测有效数据这是不对的。面试官还可能追问“等价类和边界值有什么区别”这个问题我会在下面第7题里详细展开回答。2.5 一份测试计划应该包含哪些内容这道题考察的是你对测试工作的整体把控能力面试官希望听到的不只是测试计划里的几个章节名称而是你真正理解测试计划要解决什么问题。一份完整的测试计划一般包含测试目标、测试范围、资源安排、进度计划、风险预估与应对、测试策略与工具、准入准出标准。测试范围要明确哪些功能需要测、哪些不测比如迭代版本里只改了登录模块那支付模块可能就不在本次测试范围内这事不写清楚后期容易扯皮。准入准出标准也要讲明白比如需求文档评审通过、提测包部署成功才允许开始测试冒烟测试用例全部通过、遗留问题都在可接受范围内才算测试完成。答题时可以结合自己的经历来讲比如“我之前在某某项目里测试计划里专门有一块是风险预估有一次因为开发人员离职模块交接导致延期因为提前在计划里标注了这个风险并预留了缓冲时间所以整体进度没有受到太大影响”。有项目细节支撑这个答案会立刻变得丰满。3. 用例设计实战这5道题会暴露你的真实水平3.1 如何设计登录功能的测试用例登录功能是面试里最经典的用例设计题几乎每次面试都会遇到而且面试官往往不看你怎么写而是看你考虑得全不全。这道题看起来简单但想答得滴水不漏需要有清晰的层次。我的建议是分维度来答。功能维度输入正确的用户名和密码能登录成功输入错误的用户名或密码提示错误信息用户名为空、密码为空、两者都为空时的提示大小写是否敏感密码框是否有掩码是否有记住密码功能是否支持回车键登录。安全维度连续多次输错密码是否锁定账号登录状态下的会话超时密码在传输和存储上是否加密这个可以提一下但不做深入。界面和体验维度错误提示是否友好键盘焦点是否默认在用户名输入框刷新页面是否会自动退出。反向和异常场景已删除的账号能否登录被禁用的账号能否登录密码过期后首次登录是否需要强制改密。还有一个容易被忽略的维度是兼容性和权限不同浏览器、不同分辨率下登录页是否正常不同角色的账号登录后进入的页面和权限是否不同。面试官问你“还有什么要补充的”你把这些维度抛出来基本上就能过这一关了。3.2 什么是边界值分析和等价类有什么区别边界值分析和等价类划分经常一起考你要能说清楚两者的区别等价类划分关注的是输入数据的“类”从每类中取代表性的数据边界值分析关注的是等价类边界的“值”重点测试边界上以及边界附近的数据因为大量缺陷往往发生在输入或输出范围的边界上。比如一个输入框要求输入1到100的整数。用边界值分析就应该重点测1、100这两个边界值以及它们的左右邻值0、2、99、101。为什么是这些值因为0和101是刚刚超出边界的数据最容易暴露问题2和99是边界内侧的数据用来验证边界内最近距离是否正常。真实项目中边界值运用非常广泛比如分页功能第一页和最后一页、金额字段的最小值0.01和最大值、时间范围的起始时间和结束时间。面试时你如果能举一个具体的项目案例比如“我之前测一个优惠券满减功能满100减10我就重点测了99.99、100.00和100.01这几个金额”这个答案就很有说服力。3.3 Bug的生命周期是什么这道题考察的是你对缺陷管理流程的理解。Bug生命周期比较标准的描述是新建、确认、分配、修复、验证、关闭。如果验证未通过bug会重新打开并回到修复状态如果开发认为不是bug或者是重复提交的问题可能会拒绝或置为重复状态。我建议答的时候不要只背这个流程要加上你对这个流程的思考。比如转测阶段为什么bug要先经过测试经理或组长确认而不是直接分配给开发因为有些现象可能不是bug可能是环境问题、数据问题或操作问题确认可以避免浪费开发资源。再比如关闭bug前要不要再回归一次答案是必须的而且要验证关联模块有没有受影响。有些面试官会追问“你觉得这个流程有什么可以优化的地方”这时候可以提几点比如可以增加一个挂起状态用于处理那些需要产品经理决策的设计类问题或者增加bug状态流转的时效提醒避免bug在开发手里停留太久没有响应。这种回答说明你不只是用过流程还思考过流程本身存在的问题。3.4 如何写一份高质量的缺陷报告缺陷报告是测试工程师最核心的产出物之一面试官问这道题往往是想了解你有没有真正在项目中提过bug以及你提的bug开发愿不愿意看、肯不肯改。我来梳理一份高质量缺陷报告的关键要素和我上面的测试用例要素类似但侧重点不同。首先标题要简洁清楚一眼能看出问题比如“登录页点击登录按钮无响应控制台报500错误”而不是“登录有问题”这种模糊描述。其次操作步骤要可以复现按步骤执行能准确重现问题步骤不要跳步每步尽量详实。然后是实际结果与预期结果要写清楚实际发生了什么、期望发生什么。环境信息也别漏了操作系统、浏览器版本、设备型号、网络环境有时候就是bug产生的先决条件。附件很重要一张清晰的截图或一段录屏比写一千字都管用对开发定位问题帮助巨大。此外优先级和严重程度的区分也是面试常考点。严重程度指缺陷对系统的影响程度比如系统崩溃、数据丢失就是致命级优先级指缺陷需要被修复的紧迫程度比如一个错别字虽然严重程度低但如果是出现在注册页第一个表单上的品牌名优先级就会比较高。面试能把这个讲明白说明你在项目里是真提过bug的。3.5 冒烟测试和回归测试有什么区别这两个概念在测试流程里经常被混淆面试几乎必考。冒烟测试是在提测版本上进行的一种快速、基础的功能验证目的是确认主要功能流程是否可用决定这个版本能不能进入正式测试阶段。它的特点是范围小、执行快一般选择核心业务流程跑一遍比如电商项目就测“下单选品加入购物车提交订单走完一单”如果这都不通那这个版本直接打回不用继续深入测。回归测试是修改或新增代码后对已有功能进行重复测试目的是验证修改没有引入新的缺陷也就是常说的“不破坏原有功能”。回归测试的范围取决于变更的影响范围可能是全量回归也可能是针对受影响模块的冒烟级回归。面试时如果被追问“你怎么确定回归测试的用例范围”你可以这样回答先基于代码变更分析影响的模块和功能再结合用例库中的关联关系进行筛选同时参考修改之前bug集中的区域最后根据本次迭代的risk级别决定是冒烟回归还是全量回归。这个回答会把面试官带入到你的项目经验里比单纯背定义好很多。4. 技能实操Linux、MySQL、接口题这样答不丢分4.1 测试人员常用的Linux命令有哪些面试问到Linux考察的是你日常操作服务器的能力毕竟测试环境部署、日志查看、服务启停都离不开Linux。我按使用场景分类来答比零散罗列命令更显条理。文件与目录操作ls、cd、cp、mv、rm、mkdir、find、tar。权限相关chmod、chown、chgrp。进程与服务ps、top、kill、systemctl、service。网络相关netstat、ping、curl、telnet。日志查看tail、head、grep、less、awk、sed。这里面试官最常让人现场演示的是这样几条场景比如查看某个进程是否在运行用ps -ef | grep java实时查看某个应用日志用tail -f app.log查找日志里包含某个关键字的行用grep ERROR app.log看系统整体负载用top或free -h。这些命令不需要背得多么精深但至少要在面试时能流畅地说出使用场景。如果连ps -ef和grep的配合都没用过面试官很可能认为你的环境操作经验是空白的。4.2 如何从日志中排查接口报错日志排查能力是面试中高级岗位时经常考察的点初级岗位也免不了要会基础操作。最典型的做法是三分步走。第一步看日志尾部最近的报错定位时间点用tail -200 app.log查看最近200行第二步根据错误关键字过滤比如用grep ERROR\|Exception app.log | tail -50找到报错详情第三步顺着报错信息往上翻看抛出异常之前的上下文日志确认是参数问题、环境问题还是代码逻辑问题。更完整一点的答法是结合链路ID来排查。现在很多微服务项目在入口会给每个请求生成一个traceId日志里会打印出来你拿到这个ID之后直接grep全链路日志就能看到这个请求经过的每一个服务节点到底卡在哪一步。面试如果聊到这里面试官基本就能确认你有过一定的线上问题排查经验。有一个特别容易踩的坑日志没打全或者日志级别设置不对比如生产环境日志级别是WARN那ERROR和WARN会打但INFO方法入参和出参信息就没有。所以排查接口报错时也要检查一下日志级别配置是否合理必要时跟开发协调调低级别重新打印一段日志。4.3 测试常用的SQL操作有哪些数据库操作在测试工作中频率很高面试题主要集中在增删改查、关联查询、聚合统计、排序分页这几个方面。最基础也是最常考的是一条查询语句的完整结构比如SELECT 字段 FROM 表 WHERE 条件 GROUP BY 字段 HAVING 过滤条件 ORDER BY 字段 LIMIT 起始位置, 条数你要能说出每个子句的执行顺序和作用。场景类的SQL题也很多比如“查出订单表中每个用户的最新一条订单记录”这属于典型的子查询加关联查询写法大致是SELECT o.* FROM orders o WHERE o.create_time (SELECT MAX(create_time) FROM orders WHERE user_id o.user_id);再比如统计类需求“统计每个状态下订单的总金额和数量”用GROUP BY配合SUM和COUNT即可。面试官如果问“HAVING和WHERE有什么区别”你要回答WHERE是在分组前对记录进行过滤不能使用聚合函数HAVING是在分组后对分组结果进行过滤可以使用聚合函数。这个区别虽然基础但是面试出现频率极高。对测试人员来说SQL还经常用在造数据和验证数据上。比如测试一个支付成功但回调没有返回的异常场景可能需要直接修改订单表状态字段来模拟这时候一条UPDATE orders SET status PAID WHERE order_no xxx就能解决问题。面试时能把SQL和数据准备的工作结合起来讲会更有说服力。4.4 接口测试是什么为什么要做接口测试接口测试面试频率极高几乎每一家招测试的公司都会问。接口测试是测试系统组件之间或系统与外部系统之间接口的验证重点关注数据的传递、处理的正确性以及接口的性能和安全。为什么需要接口测试我在项目里最直观的感受是很多缺陷在UI层面很难发现或者发现成本很高。比如一个修改用户信息的接口如果不对参数合法性做校验传入一个超长字符串接口就报500这种问题在UI层根本测不到因为前端会做长度限制挡住非法输入。接口测试就是在UI层之前先拦截掉这一类问题它执行速度快、稳定性高、可以在后端开发完成时就介入测试是左移测试理念的重要实践方式。接口测试题目里面试官常问的还有“如何设计接口测试用例”这个问题的答法和前面登录功能用例的思路是一脉相承的。举个例子对一个“新增用户”的接口用例要考虑必填字段是否齐全、字段类型和长度是否合法、业务规则是否正确比如手机号格式、没有传token时是否被拦截、并发重复提交会怎样、接口返回的数据格式是否和文档一致。把这些维度说全面试官就知道你是真正做过接口测试的不是只会用postman点点点。4.5 HTTP常见的状态码有哪些状态码属于计算机网络基础测试人员在定位问题时要经常和它们打交道。高频的状态码要熟练到脱口而出200请求成功、201创建成功、301永久重定向、302临时重定向、304未修改命中缓存、400请求参数错误、401未认证、403权限不足、404资源不存在、405请求方法不允许、500服务器内部错误、502网关错误、503服务不可用、504网关超时。面试官一般会结合场景让你答比如“用户登录成功后跳转你觉得可能涉及哪些状态码”或者“一个接口在postman里返回401你第一时间怎么排查”。我的标准回答是401说明身份认证没过先检查token是否有效、是否过期、是否漏传了认证请求头如果token没问题再确认当前账号的权限配置如果还是不行看接口路由是否需要特定角色才能访问。这种问题没有标准答案考察的是你遇到问题时的排查思路所以回答时要展现出清晰的逻辑线。5. 自动化与性能进阶这几题答好了能拉开差距5.1 什么项目适合做自动化测试自动化测试是面试分水岭初级面试一般只问概念中级以上就会深入到选型和落地。问“什么项目适合做自动化”其实是在考察你有没有真正评估过自动化的ROI而不是盲目追新。我的回答思路是适合自动化的项目通常具备这几个特征。第一需求相对稳定页面和接口改动不频繁如果需求每周都在大改自动化用例维护成本会把收益完全吃掉。第二回归测试量大且重复性高比如核心流程的回归每次都人工点一遍性价比极低自动化刚好能解这个问题。第三项目周期长至少是持续迭代半年以上的项目短期项目还没写完脚本就上线了意义不大。第四执行环境相对可控比如测试环境比较稳定、数据可准备不会动不动就因为环境问题导致脚本大面积失败。反过来不适合自动化的场景也要能说出来一次性项目、UI频繁重做的阶段、短周期活动页、需要大量主观判定的界面测试。面试时能双向分析比单纯说“适合”或者“不适合”更能体现你的工程思维。5.2 自动化测试框架有哪些你怎么选型这题需要有实际使用经验才能答得生动。主流方向分两大类接口自动化框架和UI自动化框架。接口侧的典型组合是Python加requests加pytest配合Allure做报告、通过Jenkins定时执行Java侧则常用RestAssured加TestNG加Maven。UI侧Python首选Selenium或Playwright移动端则是Appium。选型的核心逻辑不是哪个框架火就选哪个而是要结合团队技术栈、被测系统形态、人员技能水平来决定。比如团队全员Java你非要推Python那维护成本就会很高不如直接用RestAssured加TestNG如果团队没什么自动化基础建议从接口自动化开始因为接口用例写起来比UI稳定得多也容易出成果等接口自动化体系跑通了再逐步引入UI自动化会更稳妥。面试官如果追问“pytest和unittest怎么选”你要能回答pytest功能更丰富支持fixture、参数化、插件生态好兼容性也好现在新项目基本都用pytestunittest是Python标准库不需要额外安装但写起来更繁琐项目已经用了就没必要迁移。好的选型回答不是罗列功能点而是体现你对团队和项目现状的理解。5.3 性能测试的常用指标有哪些性能测试在面试中通常不会太深但常用的几个指标一定要能说清楚。TPS每秒事务数和QPS每秒查询数是最容易混淆的TPS指系统每秒能处理的事务数一个事务可能包含多次请求QPS指每秒能处理的查询或请求次数。响应时间RT指从发送请求到收到响应的时间通常关注平均响应时间、90%响应时间也叫P90和最大响应时间P90比平均值更能反映大部分用户的体验。并发用户数要能区分两个概念一是系统同一时间处理的请求数二是一段时间内同时在线但未必并发操作的用户数这两个数差了数量级。错误率指失败请求占总请求的比例一般都要低于千分之一最好为零。CPU使用率、内存占用、磁盘IO、网络IO这些系统资源指标也是性能测试的必看项。面试官如果问“性能测试中发现TPS上不去你从哪些方面排查分析”这是一个很好的开放题。我的回答思路是先看服务端资源是否打满CPU如果是瓶颈就考虑优化代码逻辑或扩容再检查数据库连接池是否够用、慢SQL是否存在然后看中间件层面Redis、MQ是否有积压或超时还有网络带宽、LB配置、JVM参数。顺序上先易后难先看监控再定位代码和配置同时要会判断性能瓶颈到底在应用层、数据层还是基础设施层。5.4 如何保证软件质量这道题回答得好坏直接反映你是“只测功能”的测试执行者还是有全局质量意识的测试工程师。一个可参考的回答框架第一需求阶段就要介入不只是在测试阶段才看需求文档要参加需求评审从测试角度审视需求的完整性、可测性、逻辑是否有矛盾把问题在早期暴露。第二设计阶段关注技术方案了解开发的设计思路预判可能出现问题的模块。第三开发阶段推动代码评审和单元测试测试要关注单元测试覆盖率虽然不要求测试人员写研发代码但要能看懂覆盖情况覆盖不到的关键分支用测试来补。第四测试阶段做好用例设计、充分执行和缺陷跟踪这部分不用多说。第五上线后要有线上监控和应急响应机制线上出问题能快速定位回滚或者修复。这个框架把质量保障从“测试阶段”拉长到了“全生命周期”面试官会认为你有质量内建的意识而不只是一个点工。5.5 接口测试中怎么处理依赖和Mock这个问题面试官常爱追问因为它直接关系到接口自动化落地时最头疼的问题。比如要测试下单接口但下单前需要先登录拿token还要依赖库存服务和支付回调这些前置条件怎么处理我的做法是分三层。第一层通过调用前置接口真实获取数据比如登录接口拿token下单前先调用创建订单的准备接口拿到订单号这种最稳妥但缺点是被依赖的接口不稳定时会连带失败。第二层造测试数据直连数据库比如先insert一条商品信息和库存记录再调下单接口这样能减少对外部服务的依赖。第三层用Mock工具模拟依赖服务比如接口还没开发好或者第三方支付回调不好真实触发用MockServer来返回预设的响应让被测接口在可控条件下运行。面试官追问“Mock数据和生产数据不一致怎么办”你要回应Mock只能解决联调和测试阶段的问题不能替代真实联调所以在上线前一定要做一次全链路真实环境验证Mock的回归结果要有明确标记不能和生产环境混为一谈。这样回答就显得很有经验。6. 面试实战策略这样答才加分这样答会挂6.1 答题的思路与话术模板面试答题不是背书而是一个展示逻辑和思维的过程这里分享一个通用的三步答题法。第一步先给结论或直接定义开门见山回答核心问题第二步展开解释原理或方法论把关键点有层次地铺开第三步结合实际项目场景收尾给出一个自己真实遇到过的例子或解决过的痛点。举个例子面试官问“你们项目怎么做接口测试的”同样的内容两种答法。普通答法我们用Postman测接口把每个接口的用例都测一遍看返回码和数据有问题就提单。进阶答法我们项目使用的是Python加requests加pytest的框架接口自动化主要覆盖两类场景第一类是核心业务正向流程第二类是异常参数和权限校验脚本通过Jenkins在每天凌晨跑一遍早上上班先看Allure报告失败了会定位到具体用例和失败原因在解决这类问题之前我们曾因为参数校验缺失导致生产上出现脏数据。同一个项目后者听起来就像自己主导过整个体系而前者像只被动执行过。6.2 最容易踩的坑这几类回答千万别踩第一坑只背答案不解释。比如问“什么是等价类”你只背定义不举例子不给应用场景面试官根本没法判断你是真懂还是死记。破解办法是在每个题目备一个实操案例。第二坑无限拓展没有重点。问一个简单问题你从测试理论扯到DevOps再到AI测试讲了一堆跟问题无关的东西面试官反而觉得你逻辑混乱。第三坑不懂装懂。面试时最忌讳的其实是编造项目经历比如简历上写着做过性能测试面试官追问LoadRunner里的参数化怎么设置时答不上来这种情况下直接被一票否决。策略是明确自己的能力边界会用就说会用不会就说了解并知道去学面试官看重的是诚实和学习能力。第四坑吐槽前公司。面试官问“为什么离开上一家公司”时有些人会滔滔不绝说原公司流程乱、测试不受重视、代码质量差这类吐槽只会让面试官担心你入职后也会这样评价新团队。一个稳妥的答法是把原因归结为个人成长诉求比如希望接触更复杂的业务、更大的平台、更规范的质量体系建设。6.3 文档与面试作品的整理方法很多候选人不知道一份整理清晰的面试文档本身就是加分项。我的建议是准备一份自己的核心面试笔记不是从网上下载的“软件测试面试八股文”而是结合自己项目和经历整理的手写版分类按测试基础、用例设计、Linux命令、SQL语句、接口与自动化、项目总结来做。在“项目总结”这一节我建议每个项目都提炼一段一分钟左右的描述包含四个部分项目背景和业务形态、你在项目中的角色和职责、你负责的核心模块和典型测试场景、你遇到的挑战和最终解决方案。这段描述要反复练习到可以自然讲出来面试中自我介绍和项目提问环节都用得上。另外如果有条件可以把之前写过的测试用例、缺陷报告、接口测试脚本或自动化测试报告中的一部分脱敏后整理成作品集面试时展示给面试官比嘴上说一百句“我有经验”都管用。7. 最后再分享一点我的真实感受面试这件事我在不同阶段有完全不同的体会。刚入行的时候我也背过网上下载的面试题合集背了好几遍还是慌后来才想明白面试官真正在意的是你有没有完整的测试思维而不是能不能一字不差地背出某个定义。所以这篇文章里我刻意把每一道题的“为什么”讲透面试时哪怕很多细节记不全只要理解了底层逻辑变成自己的话去表达效果不会差。还有一点想提醒正在准备面试的朋友任何时候都不要只准备答案要准备场景。你可以在面试前把每道题的答案都对应到一个自己真实的项目经历上这样即使被追问也不至于无话可说。20道经典面试题只是起点把它们吃透后你会发现大多数面试问题都逃不出这个框架剩下的就看你的表达和心态了。祝面试顺利。