最近帮几个朋友做模拟面试发现一个挺有意思的现象大家手里的软件测试面试题清单都很长但真正被问到核心问题时很多人连“这个题到底在考什么”都没想清楚。测试岗位的面试早就不是背概念就能过关的年代了面试官更在意你有没有测试思维、踩过哪些坑、能不能独立把一件事推进到底。这篇软件测试面试题汇总我按面试中真正高频出现的板块来梳理测试基础、用例设计、接口与自动化、数据库与Linux、再到项目经验和软技能。每个问题我都会说明背后的考察意图以及怎么回答才能让面试官觉得“这人真的干过活”。不管你是准备校招、转行还是社招跳槽这套思路都能直接用。1. 面试官问“测试基础”时真正想听的回答1.1 软件测试的定义与目的别把“找bug”当标准答案这是最基础的一题但恰恰是很多人丢分的第一题。你要是回答“软件测试就是找bug”面试官表面上点头心里已经在给你打低分了。找bug只是手段不是目的。测试的本质是“验证软件是否符合需求”和“确认软件是否适合上线交付”也就是英文里常说的 Verification 和 Validation 的区别。更准确地说软件测试是通过一系列手段在有限的成本和时间内尽可能多地发现缺陷并对软件质量给出一个可量化的评估结论。注意“尽可能多”这三个字它隐含了一个重要认知测试不可能穷尽所有输入和路径所以你做的每一件事都是在风险和成本之间做权衡。面试官问这个问题其实是想看你对测试定位的理解是否成熟。我在面试里比较推荐的回答框架是三句话第一句说验证需求和发现问题第二句说评估质量风险第三句说推动质量改进。这三句话连起来就从执行者视角跳到了价值视角面试官会明显感觉到你和应届生的区别。1.2 测试生命周期与开发模型V模型、W模型、敏捷模型怎么答关于开发模型面试高频考点是 V 模型和 W 模型近几年敏捷模型问得也越来越多。V 模型把开发和测试串成一条对应关系需求分析对应验收测试设计概要设计对应系统测试设计详细设计对应集成测试设计编码对应单元测试。它的优点是清晰直观缺点是测试被放到了开发后面发现问题的时间会滞后。W 模型其实是“双 V”开发和测试同步并行。需求一出来测试就开始写测试计划设计一出来测试就开始设计用例。这样做的好处是测试左移能尽早发现需求层面的问题。你可以这样记忆V 模型是“开发完成后再测试”W 模型是“边开发边测试”。敏捷模型这几年问得特别多因为越来越多的公司切了 Scrum。敏捷测试强调的是持续测试、快速反馈、自动化优先以及测试人员和开发人员的深度协作。面试官如果追问“敏捷里没有独立的测试阶段你怎么保证质量”千万不要说“那就不用测了”而是要说测试活动被拆散到每个迭代里每个 Sprint 都要做增量回归自动化测试在这个模式里不是可选项而是必需品。1.3 测试分类功能、回归、冒烟、探索性测试的区别与选择测试分类这道题看起来简单但面试官往往会在你回答后追加一句“那你们项目里这些测试都什么时候做”。如果你答不上来就说明前面是在背书。按我的经验最务实的回答是先把分类逻辑讲清楚再结合项目场景说明怎么选。按是否知道内部结构分为黑盒、白盒和灰盒测试。测试工程师日常以黑盒为主白盒通常是开发或测试开发做代码覆盖率分析时用的。按是否运行程序分为静态测试和动态测试。静态测试不运行程序只看代码、文档和设计比如代码走查动态测试则是跑起来看表现。按测试目的又分为冒烟测试、回归测试、功能测试、性能测试、安全测试、兼容性测试、探索性测试等。这里有个高频追问冒烟测试和回归测试有什么区别。冒烟测试是每次提测之后先用最核心的几条用例快速验证主流程能不能跑通如果主流程都断了直接把版本打回去没必要往下测。回归测试则是功能修改或新增之后验证原有功能没有被破坏。你可以理解为冒烟是“进门检查”回归是“全面复查”。1.4 缺陷生命周期与管理从提交到关闭的完整链路缺陷管理题几乎是必考的因为它直接反映你有没有真实做过测试。bug 的生命周期一般是New → Open → Fixed → Retest → Closed。如果开发说不是 bug会走 Rejected如果修改延期会走 Deferred如果测试复测后确认没修好要 Reopen。面试时最好画一条状态流转链把每个状态怎么触发讲清楚。比状态流转更重要的是 bug 的编写质量。面试官会给你一个场景或者直接让你描述一个你自己提过的 bug考察你能不能把复现步骤、预期结果、实际结果、日志和截图讲清楚。我总结过一个教训最差的 bug 报告是“点击按钮没反应”最专业的 bug 报告是“在 iPhone 15 微信 8.0.4 环境下点击注册按钮后超过 3 秒无任何响应控制台报 500 错误数据库出现重复注册记录”。缺陷优先级和严重级别一定要分清楚。严重级别描述影响程度优先级描述修复紧迫程度。P0 级 bug 意味着系统无法继续使用比如支付成功但订单没生成。P1 是核心功能异常但有绕过方案。P2 是普通功能缺陷。P3 是界面或文案问题。面试官如果发现你连这两者都分不清会直接怀疑你的实战经验。2. 测试用例设计这一组高频题最拉开工龄差距2.1 等价类与边界值几乎所有面试官都会追问的组合等价类划分和边界值分析是测试用例设计里出现频率最高的两个方法。它们经常一起考原因很简单等价类负责把无穷的输入划分成有限的几类边界值负责在每类边界附近找最容易出错的点。实际开发中很多 bug 都出在边界上比如 18 岁能不能注册、100 人分组上限、金额 0 元能不能提交。等价类要分有效等价类和无效等价类。有效等价类是符合需求的输入无效等价类是不符合需求的输入。很多人写用例时只盯着有效数据忘了无效数据才是最容易发现 bug 的地方。比如一个手机号输入框有效等价类是 11 位数字无效等价类包括10 位数字、12 位数字、含字母、含特殊字符、为空。每一类至少写一条用例。回答这类题时有个加分技巧先说“我会先划分等价类再在边界附近补用例”。举个例子一个年龄输入框要求 18 到 60 岁等价类就是 18-60 的有效区间、小于 18 的无效区间、大于 60 的无效区间。边界值则需要覆盖 17、18、19、59、60、61 这六个点。把上下边界正负一都讲出来面试官就知道你不是背概念而是真的会落地。2.2 决策表、因果图与场景法什么时候用才不会被扣分除了等价类边界值决策表、因果图和场景法也是常考的设计方法。但它们在实际项目中用得没有前两者频繁所以面试官更看重你“知道什么时候该用”。先说决策表它适合处理多个输入条件之间有组合逻辑的场景比如登录时有“用户名正确/错误”和“密码正确/错误”四种组合加上“账号是否锁定”就是八种组合。决策表就是把条件桩、动作桩、条件项和动作项列成表格保证组合覆盖完整。面试官让你设计“满 100 减 20 且会员再打 9 折”之类的优惠券用例时就是考察这个。因果图和决策表本质上是一回事因果图偏重梳理因和果的关系决策表偏重把关系变成可执行的用例。两者很多题目可以通用不必刻意区分。场景法则更适合流程类测试比如电商下单的流程正常下单、支付超时、库存不足、取消订单、退款。每个流程都是一条场景主场景加备选场景就构成了流程覆盖。很多人在面试中容易出现一个致命错误不管什么题都把所有方法全部堆上去。面试官问我“怎么给搜索框设计用例”你说“我用等价类、边界值、决策表、因果图、场景法、错误推测法全都来一遍”听上去很全实际很假。正确的思路是优先用等价类和边界值覆盖输入用场景法覆盖交互流程再用错误推测法补充高风险点。方法是为目标服务的不是用来凑数的。2.3 经典面试题登录框、购物车、搜索框的用例设计思路这组经典题真的很常见。你搜软件测试面试题的时候十个清单里有八个会有登录框但它依然每年都考因为面试官想通过这道题看清你的思维体系。登录框怎么说才能说得漂亮首先划分功能点用户名校验、密码校验、验证码、登录按钮、记住密码、忘记密码、第三方登录。然后每个功能点再细分成正常流和异常流。用户名要考虑已注册、未注册、空值、含空格、超长密码要考虑正确、错误、为空、大小写、是否触发锁定。验证码要考虑正确、错误、过期、为空、看不清时刷新。最后补上网络异常、服务器报错、连续失败锁定、切后台再回前台这些场景。把这条链路讲完你已经覆盖了几十条用例比背模板强得多。购物车和搜索框同理。购物车的核心场景是加购、修改数量、删除商品、单选全选、结算跳转、库存变化、价格变化。特别要注意的是“库存不足”和“价格变动”这类异常场景很多人会漏掉。搜索框则要覆盖正常搜索、空关键字、单字符、超长关键字、特殊字符、emoji、大小写混合、搜索结果为空、搜索历史、热门搜索以及搜索行为上报。我建议你准备这类题时真的把用例写出来而不是在脑子里列个大概。因为面试现场紧张脑子里的东西很容易丢。我当年准备时是把登录框写了五十多条用例写到后面才发现边界和异常场景是永远补不完的关键是把优先级最高的场景先讲到让面试官感受到你“会分层、有取舍”。2.4 面试官追问“你怎么保证用例覆盖完整”时的回答套路用例设计完后面试官通常来一句“你怎么保证你的用例是完整的”这个问题没有标准答案但回答得好不好直接决定你能不能通过。我的建议是不要慌用“分层覆盖 评审 度量”来回答。分层覆盖指的是需求功能点全部覆盖、核心流程分支覆盖、关键边界覆盖、高风险异常覆盖。评审指用例写完后会拉开发产品和测试同事一起过一遍查漏补缺。度量指用需求覆盖率、代码覆盖率、用例执行通过率等数据来衡量测试的充分程度。如果面试官继续追问“代码覆盖率到百分之多少才算合格”千万别给死数字。通常行覆盖率和分支覆盖率是两个口径分支覆盖比行覆盖更严格单元测试阶段一般追求分支覆盖 70%-80% 以上集成测试阶段更多依赖场景覆盖。你可以说“覆盖率只是一个参考指标真正重要的是风险和业务价值覆盖率”这句话会显得你有整体思维。还有一个辅助答题的加分点提到“测试数据构造”和“测试环境隔离”。如果你能说出“我会准备独立的测试账号和测试数据避免脏数据干扰用例执行同时把用例和验收标准绑定”面试官会判定你有过实战项目经验而不是只在题库里刷过。3. 接口与自动化测试近两年面试占比飙升的板块3.1 HTTP协议与接口测试基础状态码、请求方法、token机制现在做测试不会接口基础几乎寸步难行面试题里接口部分的比例明显比以前高。首先要掌握 HTTP 的基础知识请求方法、状态码、请求头和请求体。状态码是最容易被追问的。2xx 表示成功3xx 表示重定向4xx 表示客户端错误5xx 表示服务端错误。高频要记住200 成功、201 创建成功、301 永久重定向、302 临时重定向、400 请求参数错误、401 未认证、403 无权限、404 接口不存在、405 方法不允许、500 服务端异常、502 网关错误、503 服务不可用、504 网关超时。为什么要区分 401 和 403这是面试官常埋的坑。401 是“你没登录或凭证失效”403 是“你登录了但没权限”。很多人在项目里把这两个搞混接口测试断言就容易错。我处理接口测试时会专门把认证授权类的返回码提取出来做测试矩阵防止开发把权限逻辑写错。token 机制也是接口测试的核心考点。常见的流程是登录成功后服务端返回一个 token后续请求在请求头 Authorization 里带上 token 才能访问受保护的接口。测试时要注意 token 过期、token 无效、token 未传、token 被篡改这四种情况。如果项目用的是 JWT还需要理解 payload 里的过期时间很多安全类 bug 就藏在 token 校验逻辑里。3.2 接口测试工具Postman与Jmeter的选择逻辑工具题高频出现的两个名字是 Postman 和 Jmeter。面试官不一定要求你把两个工具都精通但肯定希望你能说清楚“什么时候用哪个”。Postman 适合功能层面的接口调试和接口用例维护。它最实用的几个功能是环境变量管理、集合管理、断言脚本Tests、数据驱动Runner。环境变量一定要理解因为你在开发、测试、生产环境之间切换时baseURL 这类变量可以直接通过环境切换来更新而不是手工改。断言部分建议至少会用 pm.response.code 和 pm.expect能对状态码、响应时间和响应体字段做基础校验就够了。Jmeter 则更多用于性能测试但很多团队也会用它来做轻量级接口回归。它基于线程组来模拟并发通过 HTTP Request Sampler 发请求用查看结果树来观察响应。面试官问“怎么用 Jmeter 做参数化”你要能说出 CSV Data Set Config 或用户自定义变量。问“怎么处理登录后才能访问的接口”你要能说出 HTTP Cookie 管理器或提取 token 的表达式。思路比工具重要。你不需要把每个按钮都背下来但你需要表达清楚接口测试的步骤是 1 梳理接口清单和入参出参2 构造请求和测试数据3 设计断言4 执行并分析结果5 把接口用例固化到 CI。工具只是这五个步骤里的一部分。3.3 自动化框架选型Selenium、Pytest、TestNG怎么讲才能加分自动化测试几乎是必问板块。面试官会问“你项目中自动化怎么做的”然后根据你的回答深入追问。回答这类问题前先明确一个前提自动化测试不是什么都自动跑要选对对象和场景。UI 自动化里 Selenium 仍然是主流特别是在 Web 端。你需要掌握几个核心概念WebDriver 的定位方式id、name、className、xpath、cssSelector、显式等待和隐式等待的区别、常见元素操作和异常处理。这里我特别提醒一下很多面试者会说“我用 xpath 定位元素”但被问到“xpath 有哪些写法”时就说不上来。相对路径和绝对路径的区别、contains 的用法、轴定位的用法至少要能说清楚一两个。接口自动化方面Python 生态用 Pytest 比较多Java 生态用 TestNG 或 JUnit。Pytest 的高频考点是 fixture 和参数化以及 conftest.py 的作用。你要能解释 fixture 的 scopefunction、class、session分别控制什么生命周期。用参数化可以优雅地实现测试数据驱动而不是复制粘贴几十个测试函数。TestNG 则要知道 BeforeSuite、Test、DataProvider 这几个注解和使用场景。框架层面真正加分的是 Page Object Model页面对象模型。它能讲清楚“页面元素定位与业务操作分离”比如把登录页所有元素封装成一个类测试用例只调用登录方法而不直接写 findElement。讲到这里面试官会认为你有设计意识而不是只是会调库。3.4 UI自动化与接口自动化的利弊什么时候该做什么时候不该做这道题是送分题但很多人答成“接口自动化比UI自动化好”这其实是不成熟的体现。正确的回答是两者不是谁替代谁的关系而是分层配合的关系。UI 自动化的优点是贴近用户真实操作能发现页面交互和前端渲染的问题缺点是执行慢、稳定性差、对元素变更非常敏感。接口自动化的优点是执行快、稳定性高、可以在开发阶段就介入缺点是覆盖不到前端展示和用户交互的缺陷。面试官如果问“如果让你在项目里选你优先做哪个”我会回答优先做接口自动化把核心业务链路用接口层覆盖住再用少量 UI 自动化覆盖关键用户主流程。理由很简单测试金字塔里底层单元和接口层的数量最大ROI 最高UI 层数量最少但成本最高。这个回答既体现成本意识又能体现工程思维。有一点要主动讲清楚自动化测试不是为了让测试人员失业而是把人从重复劳动里解放出来去做探索性测试和风险评估。这句话在面试里说出来会让人觉得你不只会写脚本懂得测试价值的本质。3.5 持续集成与测试环境CI/CD里测试的角色最近两年面试官很爱问持续集成相关的问题特别是“测试在 CI 里怎么发挥作用”。你需要理解一个基本链路开发提交代码 → CI 触发构建和单元测试 → 构建成功部署到测试环境 → 测试触发自动化冒烟和回归 → 通过后进入下一个环节。测试人员在 CI/CD 里做的是定义质量关卡避免坏了的功能流到下游。会用到的工具包括 Jenkins、GitLab CI、GitHub Actions面试只需要挑一个能讲细节即可。核心要理解 Pipeline 的阶段划分和每个阶段的质量准入标准。比如代码提交后先跑单元测试通过率不达标就阻断构建部署到测试环境后由自动化接口测试执行冒烟用例失败就自动回滚或通知失败。我在实际配置 CI 时有一个心得体会自动化用例的执行时间不能太长整体控制在 15 到 20 分钟以内否则开发会不愿意等。所以测试设计里要区分冒烟集和回归集冒烟集在提交时跑回归集扔到夜间定时跑。这一个小小的设计就能让 CI 从“摆设”变成“真的被团队依赖的工具”。4. 数据库与Linux测试面试里的“隐形门槛”4.1 SQL必考题连表查询、聚合函数、分组过滤面试里 SQL 题只要出现基本都是现场手写。最常见的考法是给你两张或三张表比如用户表、订单表、商品表让你查出某些数据。如果你连基本的 select 都写不利索面试基本就凉了因为测试工作里大量验证数据需要查数据库。必会的语法包括SELECT 指定字段、WHERE 条件过滤、ORDER BY 排序、LIMIT 分页、GROUP BY 分组、HAVING 分组后过滤、聚合函数 COUNT/SUM/AVG/MAX/MIN、INNER JOIN/LEFT JOIN 连表。这些是最基本的地基不建议绕过。一道经典的 SQL 面试题是“查出订单表中重复下单的用户 id 和下单次数”答案大概是SELECT user_id, COUNT(*) AS order_count FROM orders GROUP BY user_id HAVING COUNT(*) 1;GROUP BY 之后不能用 WHERE 过滤必须用 HAVING这是很多人会丢分的地方。另一道经典题是“查每个部门薪资最高的员工”用窗口函数会比较优雅SELECT department_id, employee_name, salary FROM ( SELECT department_id, employee_name, salary, ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rn FROM employees ) t WHERE rn 1;如果面试官考察的是按薪资排名还可以用 DENSE_RANK 或 RANK最好能说清这三个窗口函数的区别RANK 有并列时会跳号DENSE_RANK 并列不跳号ROW_NUMBER 不管并列都依次编号。这在“查工资排名第 N”的题型里是核心考点。4.2 测试人员为什么要会Linux日志查看、环境部署、服务启停Linux 是另一项测试面试里的隐形门槛。很多人会觉得“测试会点点点不就行了为什么要会 Linux”但实际项目里测试经常需要自己查日志、看服务状态、改配置文件、拉测试环境。最典型的场景是定位线上或测试环境的问题你操作界面发现报错但开发问你要报错日志你得自己去日志目录把相关时间的错误信息捞出来。还有测试环境部署新版本如果服务起不来至少要知道去看服务状态和启动日志而不是一句“环境坏了”就把问题抛回去。面试官问 Linux 时通常不会只让你背命令清单而是给你一个场景“线上用户反馈注册失败你怎么排查”。我建议你按这个链路回答先用 tail 或 grep 看应用日志和错误日志再用 curl 请求接口看返回码然后看数据库连接是否正常最后把关键日志和相关参数反馈给开发。这样一整套回答比罗列命令强太多了。4.3 高频Linux命令grep、tail、find、awk怎么组合使用常用命令里最高频的几个是tail、grep、find、ps、netstat、awk、sed、top、chmod、df。逐个背不难难在组合应用。查日志最常用的组合是 tail 加 grep。实时跟踪日志文件你可以用tail -f /data/logs/order-service.log如果要查某个时间段的错误可以先 grep 出错误行再继续看上下文grep ERROR /data/logs/order-service.log | tail -n 100grep 配合 -i 忽略大小写、-r 递归目录、-n 显示行号这三个参数一定要记住。awk 则是处理列数据的好用工具比如日志里第 4 列是时间第 7 列是响应时间你想统计响应时间超过 1000ms 的请求条数可以用awk $7 1000 {count} END {print count} access.log服务状态和端口查看也很常考ps -ef | grep java 看进程是否存活netstat -tlnp | grep 8080 看端口被谁占用ss -tlnp 也可以。top 看系统整体负载。这些命令不需要全会但高频场景下必须能脱口而出。4.4 数据库事务与隔离级别测试环境的脏数据问题有些面试官喜欢在 SQL 之外追加事务和隔离级别的问题尤其是做银行、电商或支付系统的公司。事务的 ACID 四个特性必须知道原子性、一致性、隔离性、持久性。能结合实际例子讲更好比如转账过程中扣款和加款必须同时成功或同时失败这就是原子性。隔离级别从低到高分别是读未提交、读已提交、可重复读、串行化。低级别可能产生脏读、不可重复读、幻读高级别并发性能更差。MySQL 默认的隔离级别是可重复读Oracle 和 SQL Server 默认是读已提交。面试官问“测试时查不到刚刚插入的数据为什么”往往就和事务隔离级别或事务未提交有关。测试环境里最常踩的坑就是脏数据测试用例执行完不清理数据残留影响下次用例结果或者因为事务没提交数据看不到造成误判。如果你能在面试中提到“我会在测试设计里考虑数据清理策略比如用独立账号、独立租户或者执行前后快照对比”面试官会非常买账。这已经超过纯概念考察的范围进入了工程实践的深度。5. 业务场景题与软技能轮从技术到Offer的最后一公里5.1 经典场景题压测、线上bug、版本紧急上线怎么处理除了基础题面试中经常会出现业务场景题这类题考察的是临场判断和应变能力。答得好的人往往不是技术最强的而是处理问题思路最清晰的。第一个高频场景是“如果线上出了严重 bug你怎么处理”。不要只回答“我赶紧提 bug”。正常流程是确认问题影响范围和复现条件 → 保留现场收集日志和截图 → 通知测试负责人和开发负责人 → 评估是否需要马上回滚或热修复 → 回归验证修复结果 → 复盘原因补充回归用例防止再犯。这里“保留现场”是最关键的一步有人一上来就重启环境导致问题无法复现这是大忌。第二个高频场景是“版本原定明天上线今天提测了新版本你要怎么安排测试”。正确的策略是分层评估先明确本次改动范围和影响面再确定关键主流程安排冒烟测试对于没测到的部分做风险评估并同步给项目经理。不是闷头把所有用例全部跑完而是用优先级思维把质量信息和风险信息暴露出来。第三个高频场景是“让 1000 个用户同时用系统你怎么做压测”。这时要说出性能测试的几个核心步骤明确性能指标TPS、并发数、响应时间、错误率→ 设计压测脚本 → 在压测环境执行 → 逐步加压观察拐点 → 分析瓶颈CPU、内存、磁盘、数据库慢查询→ 输出性能报告。同时要分清并发用户数和 TPS 不是一回事1000 个在线用户不等于瞬间同时操作的 1000 个并发请求。5.2 如何描述项目经验简历、自我介绍与STAR法则面试后半段基本都会让你“讲一下你最满意的项目”或“你在项目中担任什么角色”。这一环节许多测试工程师答得散乱经常是“这个系统有登录、购物车、订单、支付模块我负责测订单模块”听完没有任何记忆点。建议用 STAR 法则组织Situation项目背景、Task你负责的任务、Action你具体怎么做、Result结果如何量化。比如“我做的是电商平台的订单模块测试。这个系统并发量高、金额敏感我负责从需求评审到上线的全流程测试。测试过程中我设计了基于边界值的优惠券用例发现了一个满减计算精度 bug通过分析数据库日志定位到浮点运算问题。上线后订单模块的 P0 级缺陷为零。”注意Result 部分一定要有可量化的结果比如“发现 xx 个 bug”“线上 P0 缺陷为零”“自动化用例覆盖核心链路 xx 条”。面试官记住的不是你“参与了项目”而是你“创造了什么结果”。自我介绍也是同样逻辑不要复述简历。我比较推荐“三段式”第一段说过去的经历背景第二段说你最擅长的测试方向第三段说为什么想来应聘这个岗位。总时长控制在 1 分钟到 1 分半钟语速不要太快显得有条理比显得背书更讨喜。5.3 高频的“你还有什么想问的”回答方向面试尾声被问“你还有什么想问的”如果你说“没有了”会显得对这个机会不太在意。但瞎问也踩雷比如一上来就问薪资加班容易显得功利。比较好的方向是三类第一类是岗位实际工作内容“想了解一下目前团队的自动化测试覆盖情况以及接下来半年测试建设的主要方向是什么。”这类问题能展示你关心工作本身也能帮你判断这个岗位是否符合预期。第二类是团队与技术栈“咱们测试团队平时用哪些工具和框架接口自动化是自研还是用现成平台”这既能展示你懂一些主流技术也能侧面判断团队的工程化程度。第三类是成长与协作“测试和开发在需求阶段是怎么协作的有没有需求评审和测试评审的固定流程”这类问题能看出你关注流程说明你不是一个只执行的人。如果面试官人选合适你甚至可以追加一个稍微带观点的问题“我了解到很多团队在推进测试左移不知道咱们这边有没有在需求分析和设计阶段让测试介入”这种问题只要语气谦虚往往会让面试官眼前一亮觉得你有行业思考。根据我的经验面试考验的从来不是你知道多少题的标准答案而是你能不能把一个测试问题的本质想清楚。软件测试面试题汇总只是骨架真正让你通过的是骨架上的细节和逻辑。如果你现在时间有限先把前面说的测试基础、用例设计、接口自动化、数据库、Linux、项目经验这六个板块过一遍再用自己的真实项目把每道题串起来练习比硬背一百道题有效得多。最后一个小建议面试前找朋友做几次模拟问答特别是场景题和项目介绍输出一遍比默念十遍都有用。