软件测试面试完全指南（考点·题库·话术）

这是一份按面试流程排的测试岗备考指南。它不打算用篇幅堆砌来显得全面，而是力争每一段都有可用的信息：定义讲清楚为什么，方法配场景，话术给模板，题目留全。全文分三大部分——核心考点详解、高频面试题清单、面试话术与模拟问答——外加开篇的备战地图和结尾的复盘建议。你可以从头读，也可以把它当工具书按需查阅。

开篇：这篇指南怎么用

市面上流传的测试面试资料，多半是三种形态：一份没有答案的题目清单、一篇讲不清边界的知识点罗列、或者一堆互相抄来抄去的”高频题”。它们各自能解决一部分问题，却没人把它们拼成一张能真正走完面试的地图。这篇指南要做的，就是补上这一块：框架补齐，清单整理成可检索的题库，话术和模拟问答归到一处。

全文分三个部分，各有各的读法。

第一部分 · 核心考点详解：这是主菜。用问答形式把测试基础、用例设计、HTTP 与接口、Bug 管理与流程、自动化、性能、数据库与 Linux、安全、编程、Web 与 App、管理与协作这些板块逐一讲透。每一个知识点都尽量给出”为什么”和”怎么用”，而不是只丢一个定义。适合从零开始读，也适合按目录跳到自己薄弱的那一块。
第二部分 · 高频面试题清单：一份按主题归类、保留全部题目的题库。它的价值不在于给你答案，而在于让你知道自己还有哪些角落没扫到。建议用法是：读完第一部分后，用这份清单自测，凡是”看到题目说不上三句”的，回到第一部分对应章节补。
第三部分 · 面试话术与模拟问答：从自我介绍到送命题到反问环节，配速记卡和一段可以对着念的模拟脚本。这部分不考你懂多少，考你能不能把懂的东西在有限时间里说清楚。

结尾附面试后复盘和试用期建议——面试不是终点，入职头三个月才是真正决定你在这家公司能走多远的地方。

面试备战地图（按优先级排序）

时间永远不够用，所以准备面试的第一件事不是埋头刷题，而是分清什么必须会、什么会了加分、什么知道个概念就行。下面这张地图按”不会是否直接挂”把考点排了序，照着优先级投入时间，比平均用力高效得多。

第一优先级：必问，答不上来基本就结束了

模块	必须掌握的内容	面试占比参考
测试基础理论	软件测试的定义、目的、原则；测试级别（单元/集成/系统/验收）的区别；功能/性能/安全测试各是什么；缺陷生命周期；缺陷报告的要素；测试左移/右移；回归测试与冒烟测试的区别	约 30%
测试用例设计	等价类划分 + 边界值（几乎必考，常给一个输入框让你现场写）；场景法（给业务流程让你写）；决策表（问概念为主）；状态转换（电商/订单类系统常问）	现场实操
接口测试	HTTP 协议基础：GET/POST/PUT/DELETE 区别、状态码（200/201/400/401/403/404/500）、Header 与 Body、Cookie/Session/Token；RESTful 概念；接口测试流程；接口用例设计（正常/异常/边界/安全/幂等）；接口关联（token 传递）；Fiddler/Charles 抓包；Postman 会发请求、写断言、跑 Collection	40% 以上
数据库	SQL 增删改查；多表 JOIN 查询；聚合函数与 GROUP BY；”一个用户表一个订单表，查每个用户的订单总数”这类题必会	必问
Linux 基础	cd/ls/pwd/mkdir/cp/mv/rm；tail -f、grep、less 看日志；ps、top 查进程；netstat / lsof 查端口	大概率问

第二优先级：加分项，问到说明面试官在认真挑人

模块	必须掌握的内容
接口自动化	自动化框架怎么搭（语言 + 库 + 分层结构）；Python + pytest + requests 组合；用例组织（conftest.py、fixture、parametrize）；断言写法；测试报告（Allure / HTML）；数据驱动（Excel/YAML/JSON）；Mock；CI/CD 集成（Jenkins/GitLab CI）
Python 编程	数据类型（list/dict/set/tuple）与常用操作；字符串处理与正则；文件读写；函数、类、继承；异常处理；常见算法题（反转字符串、判断回文、列表去重、FizzBuzz）；”写一个函数调用 mock 的登录接口返回 token”这类实操题
Git	clone/pull/push/commit/branch/checkout/merge；冲突的基本概念

第三优先级：知道概念就够，不问细节

模块	掌握到什么程度
性能测试概念	负载测试与压力测试的区别；并发用户数、吞吐量、响应时间、TPS/QPS 的含义；JMeter 能干什么
前端/移动端测试常识	浏览器兼容性怎么测；App 测试与 Web 测试的区别（安装卸载、弱网、权限、手势）；adb 会几个基本命令

一套可执行的四阶段准备计划

地图给了优先级，接下来是把它落到日历上。下面是按四周排的节奏，每阶段的产出都很具体——不是”学完某某”，而是”能做出某某”。

阶段	做什么	验收标准	时间
第 1 周	测试基础 + 用例设计 + SQL + Linux	拿到一个输入框能现场写等价类边界值用例；能写出 JOIN + GROUP BY 的统计查询；能说出排查线上问题的 Linux 命令链	每天 2–3 小时
第 2 周	接口测试（Postman 实战 + HTTP 协议）	能看懂接口文档、独立设计接口用例、用 Postman 做接口关联和参数化	每天 2–3 小时
第 3–4 周	Python + pytest + requests，搭一个真实项目的接口自动化框架	能跑通”登录拿 token → 数据驱动跑用例 → Allure 出报告”的完整闭环	每天 3–4 小时
全程	刷面试题（牛客网、知乎”测试工程师面经”）	用第二部分的题库自测，能对 80% 的题说出结构化答案	碎片时间

地图里有一个容易被忽略的细节：接口测试的时间占比（40% 以上）比测试基础（30%）还高。很多人复习时把大量时间花在背测试理论上，结果到了接口环节一问三不知。把这个比例记住，复习时按比例分配时间。

第一部分核心考点详解

第一部分的写法是问答体，但每个”答”都尽量走完整：先给结论，再补为什么，最后落到面试里该怎么用。凡是能用生活场景讲清楚的概念，都配了类比——不是为了生动，是因为抽象的测试概念只有在具体场景里才记得住、讲得出。

1. 测试基础与流程

Q：软件测试是什么？目的又是什么？

先想一个包子铺的场景：你早上揉面、包馅、蒸好，直接端给客人吃，客人咬一口发现馅是生的。你一定会想”我应该在出餐前自己先尝一口”。软件测试就是在软件交给用户之前”先尝一口”的过程——在规定的条件下对程序进行操作，发现程序中的错误，衡量软件质量，并评估它是否满足设计要求。

大白话就是三件事：找 Bug、确认软件能用、帮团队判断”现在能不能发布”。

这里有一个必须纠正的误区：很多人以为测试的目的是”证明软件没问题”。这是错的。把测试想象成质检员检查一批灯泡——你的目的不是”证明这批灯泡都是好的”（因为你可能根本没查到坏的），而是”尽可能把坏的找出来”。所以测试的真正目的是尽可能多地发现缺陷并协助开发修复，最终交付一个质量过关的产品。可以分三层理解：一是找 Bug（最基本）；二是验证功能确实按需求做了；三是收集质量数据，帮老板做发布决策（比如”目前还有 3 个严重 Bug 没修，建议别发版”）。

Q：软件测试有哪几条核心原则？

完整的测试原则有七条，面试记住核心几条即可，每一条都要能配一个例子。

测试显示缺陷的存在，但不能证明系统没有缺陷：你测了 100 次没发现问题，只能说明”目前还没找到”，不等于软件没 Bug。就像用金属探测器扫了沙滩 100 遍没找到地雷，不等于沙滩没地雷——也可能是探测器坏了，或者地雷埋得太深。
穷尽测试是不可能的：输入空间和路径组合庞大，不可能测完所有情况，必须在有限时间内选最有价值的用例。就像你不可能试完所有调料组合去测”什么味道最好”，只能挑最常见的几种。
测试尽早介入（测试左移）：别等代码写完才测，需求评审时就该参与。别等房子盖好了才说”厕所太小了”，应该在画图纸时就提出来——改图纸比拆墙便宜得多。
缺陷集群效应（二八定律）：80% 的 Bug 集中在 20% 的模块里。一家餐厅的大部分投诉都集中在”上菜慢”和”鱼不新鲜”这两件事上，其他菜基本没人抱怨。老出问题的模块，以后还会出问题。
杀虫剂悖论：重复执行相同的用例，会发现越来越少的新缺陷。同一批杀虫剂用久了，虫子就免疫了。所以要定期更新和补充用例。
测试活动依赖于测试内容：不同项目（嵌入式、Web、App）的测试策略完全不同，没有一把万能钥匙。
测试只能证明缺陷存在，与第一条呼应——这是测试的根本局限，也是为什么测试不可能”零 Bug”。

Q：单元测试、集成测试、系统测试、验收测试有什么区别？

用一个开火锅店的类比一次性说清。你不可能等整个店装修好、员工招齐、开业当天才第一次检查东西好不好用，你肯定是：先检查每个零件（锅具漏不漏水、煤气灶点火），再检查组合（锅 + 煤气 + 排烟管连起来能不能正常煮东西），然后整店试运营（服务员端菜、收银、厨房出餐全流程），最后请朋友来吃（模拟真实客人看体验）。

级别	谁来做	测什么	火锅店类比	软件里的例子
单元测试	开发	最小代码单元（一个函数/方法）	检查煤气灶能不能点火	测 calculateDiscount(原价, 折扣率) 函数，输入 100 和 0.8，看返回是不是 80
集成测试	开发/测试	模块之间的接口和交互	锅 + 煤气 + 排烟管连起来，火能不能传到锅里	登录模块调用户模块查权限，两个模块连起来测，看数据传得对不对
系统测试	测试	整个系统端到端，含功能与非功能	整店试运营，从进门到结账全流程	打开 App → 搜索商品 → 下单 → 支付 → 收到订单通知，全流程走一遍，还要测性能、安全
验收测试	产品/客户	需求是否满足，能不能上线	请朋友来试吃，问”能不能正式开业”	产品经理拿着需求文档逐条核对，确认无误后签字放行

这里有三个面试最爱挖的坑。

坑一：单元测试是谁做的？很多人答”测试做的”——错，是开发做的。测试主要参与集成之后的级别。
坑二：集成测试测的是什么？不是测单个功能，而是测模块之间的”接缝”——数据传对了没有、接口通不通、格式对不对。
坑三：系统测试和验收测试的区别？系统测试是”按需求文档测它对不对”，验收测试是”按产品经理想法看满不满意”。一个是找 Bug，一个是签放行条。

单元测试和集成测试还有各自的细分策略，被追到时可以补。单元测试常用孤立测试（把被测单元与外界隔离，覆盖率最高）。集成测试有四种策略：自顶向下（先验核心、无需驱动模块，但底层缺陷发现晚）、自底向上（先验底层、无需桩模块，但高层错误发现晚）、三明治（上下同时集成，折中方案，中间层覆盖容易不足）、大爆炸（一次性全部集成，定位难，只适合小项目）。验收测试里再分 Alpha 测试（开发环境、内部受控）与 Beta 测试（用户环境、真实场景）。

Q：能不能用一个完整项目把测试流程串起来？

能。假设你是一家外卖平台的测试工程师，要上线”拼单”功能——多个用户合起来下一个大订单、分摊配送费。这个功能足以把大部分核心流程串一遍。

第一幕，测试左移。产品画好了原型，开发还没动笔，你去参加需求评审。你会发现原型上写”最多 5 个人拼单”，却没写第 6 个人进来怎么办。你当场提出来，产品补一句”那就提示已满员”。这个问题在画图纸阶段就解决了——改图纸比拆墙便宜得多，这就是测试左移：测试在需求/设计阶段就介入，提前发现问题。

第二幕，三个维度测。开发写完了功能，你从三个方向测它。”它做对了没有”——这是功能测试，拉 3 个朋友拼单、选餐、提交、支付，流程走通、金额算对。”人多了扛不扛得住”——这是性能测试，你想中午高峰期 5000 人同时发起拼单服务器会不会挂，用工具模拟并发。”坏人能不能搞破坏”——这是安全测试，你把别人拼单链接里的 orderId 改成另一个数字，看能不能看到别人的订单，如果能，就是越权漏洞。

第三幕，冒烟测试。拿到开发提测的版本，第一件事不是全面测，而是快速走一遍主流程：打开 App → 进拼单页面 → 创建拼单 → 加商品 → 提交。结果第一步就闪退。你立刻叫停，把版本打回给开发——连主路都走不通的版本，不值得花时间全面测。冒烟测试就是拿到版本后先快速验证核心功能能不能跑通。名字来源是电路板通电：如果冒烟了说明烧了，直接返工。

第四幕，缺陷生命周期。开发修好闪退，你重新冒烟通过，开始全面测，发现一个 Bug：拼单人数满 5 人后，第 6 个人还能加入，而且金额算错了。你提了 Bug，它就进入了缺陷生命周期：

状态	发生了什么	生活类比
New（新建）	你发现 Bug，提交到系统	你发现包子馅是凉的，记在本子上
Open（打开/确认）	开发组长确认是个 Bug，分配给开发 A 修	店长看了记录，说”确实有问题，让厨师长去查”
In Progress（处理中）	开发 A 在改代码	厨师长在重新蒸一笼
Fixed（已修复）	开发 A 说”改好了，你再测”	厨师长说”重新蒸好了，你尝尝”
Verified / Reopened（已验/重新打开）	回归测试——修好就 Verified，还有问题就 Reopened 打回	尝一口，熟了就 OK，还凉就拿回去重蒸
Closed（关闭）	确认彻底修好，关单	包子没问题，本子上划掉这条

还有两个常见状态要记住：Rejected（拒绝）——开发说”这不是 Bug，需求就是这么设计的”；Deferred（延期）——Bug 不严重，下个版本再修。有些团队还会细化出 Assigned、Reopen、Duplicate（重复）等状态，但主干就是”新建 → 指派 → 修复 → 待验证 → 关闭，不合格就重开”。

第五幕，缺陷报告。提 Bug 不能只写”拼单有 Bug”，得写清楚标题（一眼看懂是什么问题）、环境（版本号、系统、机型——开发说复现不了，多半是环境不同）、前置条件（没有这个前提复现不了）、步骤（一步步写清，让开发照着做就能复现）、期望结果（什么才是对的）、实际结果（现在错成什么样）、附件（截图 + 录屏 + 后台日志）、优先级与严重程度（帮开发排优先级）。好的 Bug 报告的标准是：开发拿到后不需要问你任何问题，就能复现并修复。

第六幕，回归测试。开发修好了”满员还能加入”的 Bug，你验证确实修好了。但你不能只测这一条——因为开发改的是拼单人数校验逻辑，这个逻辑跟”创建拼单””退出拼单””支付金额计算”都有关联。你要把所有跟拼单相关的用例再跑一遍，确保没改出新的问题。回归测试就是”修改代码后重新执行之前的用例，确保修旧 Bug 没引入新 Bug”。

	冒烟测试	回归测试
什么时候做	拿到新版本第一件事	Bug 修复后 / 上线前最后一轮
测什么	只测主流程能不能跑	测所有相关功能（范围广）
目的	决定”这个版本值不值得测”	确保”改完之后没把别的地方搞坏”
类比	开水龙头看有没有水	修完水管后全屋检查有没有漏水

第七幕，测试右移。版本上线，拼单功能开放。你没闲着——监控线上日志看有没有大量报错，收集用户反馈看客服有没有收到投诉。上线第 2 天客服反馈”有用户拼单支付成功了但订单状态还是待支付”，你立刻拉日志定位，发现是个偶现的并发问题，紧急修复。测试右移就是测试活动延伸到生产环境，通过监控、日志、用户反馈持续保障质量。

Q：你们公司的测试流程是怎样的？

标准流程是：需求评审 → 测试计划 → 用例设计 → 用例评审 → 环境搭建 → 测试执行（提 Bug、回归）→ 测试报告。用 STLC（软件测试生命周期）来表述则是：需求分析 → 计划 → 分析 → 设计 → 实施 → 执行 → 总结。

面试里被问到”上一个公司的流程”，不要背标准答案，要说出你实际参与过的差异。小公司常常简化成：需求评审 → 写用例 → 提测后执行 → 提 Bug → 回归 → 上线 → 出简版报告。可以这样组织回答：”我们团队用的是简化版流程，需求评审由产品、前端、后端、测试、UI、项目经理一起参加，测试拿到需求后先用思维导图梳理功能点，再写用例并组织评审，提测后先冒烟再全面执行，Bug 修复后做回归，最后出一份简版测试报告。”

测试什么时候开始？标准答案是”拿到需求文档就开始了”，第一步是需求评审。为什么要评审？三个原因：怕开发理解错做出不符合要求的东西、怕测试理解错按错误标准去测、让产品/开发/测试三方达成共识避免后面扯皮。怎么评审？从六个维度下手：正确性（不偏离用户原始需求）、明确性（没有含糊词）、完整性（覆盖所有需求）、限制性（说清能做/不能做什么）、优先级（标好先做啥后做啥）、一致性（文档前后不矛盾）。

Q：测试计划、测试报告、测试结束标准分别是什么？

测试计划：整体计划由测试经理编写，测试人员负责模块级计划。核心内容包括测试范围、环境配置、测试策略（准入准出标准、工具、方法）、任务分配与时间规划、风险预判（需求偏差、时间不足等）。面试若问”测试计划六要素”，可以按”做什么（范围）、怎么做（策略/方法）、谁来做（人员分工）、什么时候做（进度）、在什么环境做（环境配置）、有什么风险（风险预案）”来答。

测试报告：模块报告由测试人员写，整体报告由测试经理整理。核心内容包括测试环境、测试依据、结果汇总（用例执行情况、Bug 分布与修复情况、覆盖率）、风险评估、测试结论。更完整的版本还会包含引言、测试概况、测试分析（用例执行率、缺陷修复率、覆盖率）、总结（质量评定、遗留问题、结论、建议）。

测试结束标准：完成所有计划的测试；用例执行通过率达标；所有 Bug 关闭；回归确认没有影响上线的缺陷；提交测试报告。出口准则和完成标准经常被当成同义词，严格说出口准则是”达到什么条件才能进入下一阶段”，完成标准是”测试任务什么时候算干完”，实操中两者高度重合。

Q：常见的测试模型有哪些？

V 模型：需求 → 概要设计 → 详细设计 → 编码 → 单元测试 → 集成测试 → 系统测试 → 验收测试，开发与测试是一一对应的 V 字。缺点是测试后置，忽视前期验证，等发现需求错误时成本已经很高。
W 模型：V 模型的升级，开发和测试并行推进，测试从需求阶段就介入，弥补了 V 模型测试后置的缺陷。
H 模型：把测试看成一个完全独立的流程，贯穿软件全生命周期，跟开发与其他流程并发进行。
X 模型：强调探索性测试，把”探索式测试”作为核心手段，适合需求极不明确或快速迭代的场景。

Q：敏捷测试与传统测试有什么区别？

维度	传统测试	敏捷测试
周期	长（月/季）	短（天/迭代）
介入时机	开发完成后介入	从需求阶段即介入（测试左移）
角色	专职 QA	强调全员测试，开发、产品都参与
计划性	计划相对固定	计划灵活，随迭代调整
自动化	鼓励自动化	依赖自动化，是 CI/CD 的基础

怎么适应敏捷？参与 User Story 拆解并定义验收标准；把自动化测试嵌入持续集成；采用 TDD（测试驱动开发）或 BDD（行为驱动开发）；缩短反馈环，每个迭代都做完整测试。

Q：什么是软件质量特性？测试和调试什么关系？

软件质量八大特性：功能、性能、兼容、易用、可靠、安全、可维护、可移植。也有教材按 ISO 9126 归纳为功能性、可靠性、易用性、效率、可维护性、可移植性等。测试与调试的区别：测试是”发现错误”的过程，调试是”定位并修正错误”的过程；测试由测试人员主导，调试主要由开发完成；测试是验证行为，调试是诊断行为。一句话概括：测试负责把问题暴露出来，调试负责把问题解决掉。

Q：QA 和 QC 有什么区别？测试人员是 QA 吗？

QC（质量控制）关注产品本身，逐点验证特性是否达标，是”事后把关”；QA（质量保证）关注流程，监督整个研发流程以预防缺陷产生，是”事前预防”。测试人员通常兼具两者：既做 QC（执行用例、提 Bug），也做 QA（参与需求评审、推动流程改进）。所以严格说”测试人员 = QA”是不准确的，更贴切的定位是”质量守门员 + 流程推动者”。软件测试工程师的定位还包括质量把关、缺陷发现、数据反馈与风险评估。

Q：什么是验证、确认、评审、检查？

这几个词常被混用。验证（Verification）是”我们是不是正确地做了产品”，对照设计规格检查实现对不对；确认（Validation）是”我们是不是做了正确的产品”，对照用户需求检查结果有没有用。软件开发周期里，验证关注过程与规格，确认关注最终价值与需求满足。评审是较正式的、有组织的检查活动，结论通常是”通过/有条件通过/不通过”；检查更偏向非正式的、小范围的核对。评审的参与者包括用户、开发、测试、需求方，目的是尽早发现缺陷、优化性能与安全。阶段评审关注关键节点的可行性，同行评审关注具体模块的缺陷排查。

2. 测试用例设计方法

用例设计是测试面试里唯一一个”能在现场立刻分出高下”的环节。给你一个输入框或一个业务流程让你写用例，胜过背一百个定义。下面把高频方法拆开讲，重点是每个方法的”适用场景”和”现场怎么写”。

Q：等价类和边界值是什么？怎么用？

先讲为什么需要它们。你是游乐园的安检员，检查游客年龄：3 岁以下免费，3～65 岁全价票，65 岁以上半价票。你不可能让每个年龄的人都进来试一遍（0 岁、1 岁、2 岁……150 岁），那要测 151 次。你需要一种方法，用最少的用例覆盖最多的 Bug 可能——这就是等价类加边界值做的事。

等价类划分的核心思想是：同一堆里的数据，软件的处理逻辑是一样的，测一个就等于测了一堆。就像你挑苹果，红富士、青苹果、烂苹果三堆，从每堆拿一个尝一口就够了，不必把每个苹果都咬一遍。

假设需求是”拼单人数输入框，范围 1～5 人”，等价类可以这样分：有效等价类（1～5 人，正常创建拼单）；无效等价类①（0 人及以下，提示”人数不能为 0″）；无效等价类②（6 人及以上，提示”拼单已满员”）；无效等价类③（非数字，如字母/符号/中文，提示”请输入有效数字”）。从每一类挑一个代表值来测，4 个用例就覆盖了所有情况。

边界值分析专攻等价类的”接缝处”。因为程序员写代码时最容易在边界判断上写错——本来该写 count >= 1 && count <= 5，结果写成 count > 1（漏了等于 1 的情况）或 count < 5（漏了等于 5 的情况）。所以要专门盯着边界两边测：下边界 1 对应测 0、1、2；上边界 5 对应测 4、5、6。这就是经典的”边界值三点法”——边界外、边界上、边界内各取一个。

两者合起来用，面试官给你”拼单人数输入框，范围 1～5 人”这个需求，你现场写出的用例表应该是这样：

用例编号	输入人数	属于哪类	期望结果
TC-01	0	无效等价类 + 下边界外	提示”人数不能为 0″
TC-02	1	有效等价类 + 下边界上	正常创建拼单
TC-03	3	有效等价类 + 中间值	正常创建拼单
TC-04	5	有效等价类 + 上边界上	正常创建拼单
TC-05	6	无效等价类 + 上边界外	提示”拼单已满员”
TC-06	-1	无效等价类（负数）	提示”请输入有效数字”
TC-07	“abc”	无效等价类（非数字）	提示”请输入有效数字”
TC-08	空（不填）	无效等价类（必填项）	提示”请输入人数”

筛出这张表，面试官基本就点头了——七八条用例，覆盖全面，逻辑清晰。等价类的典型例子还可以用手机号：有效等价类是 11 位真实手机号；无效等价类是 10 位/12 位数字、非数字字符、空值、已注销手机号。

Q：场景法是什么？给你一个业务流程怎么现场写？

等价类和边界值测的是一个输入框，但实际软件是一连串操作连起来的。场景法就是按用户真实使用的路径来测，一条路径就是一条用例。

用 ATM 取钱理解三个核心概念：基本流（插卡 → 输对密码 → 选取款 → 输入 200 元 → 吐钞 → 退卡，一切顺利）；备选流（插卡 → 输对密码 → 选取款 → 余额不足 → 提示”余额不足”，不是主路但也是正常功能分支）；异常流（插卡 → 输错 3 次密码 → 吞卡，极端情况）。

换成拼单功能，面试官让你用场景法写用例，你现场应该写出这些场景：

场景编号	场景名	路径描述	期望结果
SC-01	基本流	创建拼单(3 人) → 好友加入 → 各自选餐 → 发起支付 → 全部支付成功 → 订单完成	拼单成功，每人扣款正确
SC-02	备选流-有人不支付	创建拼单 → 好友加入 → 发起人支付 → 好友 A 超时未支付	好友 A 被踢出，其余人拼单继续或取消
SC-03	异常流-满员	已有 5 人拼单 → 第 6 人尝试加入	提示”已满员”
SC-04	异常流-过期	创建拼单 → 30 分钟内未支付	拼单自动取消，已支付金额原路退回
SC-05	备选流-退出	加入拼单后、支付前点击”退出拼单”	成功退出，人数 -1，金额恢复

现场不用写这么多，写出基本流加 2～3 个备选/异常流，面试官就知道你懂方法论了。场景法的标准话术模板是：”我先用场景法梳理用户的基本流，然后围绕基本流找出备选流和异常流。基本流是 XX → XX → XX，备选流是 XX，异常流是 XX。”就这么几句话，结构清晰。

Q：决策表和状态转换法呢？

这两个属于低频考点，一个类比加一个例子就够用，不用深挖。

决策表解决的是多个条件组合的问题。类比是”你妈给你定规矩”——条件有两个：”下雨吗”和”考试是否 ≥90 分”，组合起来有 4 条规则。软件里的例子是订单优惠规则：”会员 + 满 100 减 20″还是”非会员 + 满 200 减 30″，两个条件互相影响，用决策表穷举所有组合就不会漏分支。面试中能说一句”当有多个输入条件互相影响时，我用决策表穷举所有组合，确保不漏分支”就够了。

状态转换针对的是”一个东西在不同状态之间跳来跳去”。类比是外卖订单状态：待支付 → 已支付 → 商家接单 → 配送中 → 已完成，中间还能走到”已取消”。软件里的例子是拼单状态：创建中 → 拼单中 → 已满员 → 已支付 → 已完成，也可能转到已过期或已取消。测试重点是每个状态转换的触发条件，以及”不能跳着转”（比如不能直接从”创建中”跳到”已完成”）。面试里说”我画状态转换图，测每个合法转换加非法转换，比如从 A 直接跳到 C 应该被拒绝”就到位了。

Q：除了这些，还有哪些用例设计方法？

错误推测法：基于经验和直觉推测容易出错的地方。典型对象包括空格、特殊字符、超长字符串、空值、非法格式。没有明确依据，但实战中最有效。
正交表（正交试验法）：用在多输入条件组合的场景，用最少的用例覆盖最多的组合，尤其适合系统测试。比如三个开关各两种状态，全组合是 8 种，正交表能压缩到更少的用例数。因果图/判定表：把输入条件（因）和输出结果（果）的因果关系画出来，再转成判定表，适合逻辑关联强的场景。
错误推测 + 等价类 + 边界值 + 正交表 + 因果图 + 场景法 + 状态转换，合起来常被称为经典的黑盒用例设计方法。

白盒测得用白盒的方法，常见的是逻辑覆盖（语句覆盖、判定覆盖、条件覆盖、路径覆盖）、循环覆盖、基本路径覆盖。面试中被追到白盒，能说清”白盒看代码逻辑分支覆盖，适合单元测试和集成测试”即可。

Q：一份合格的测试用例包含哪些要素？

标准要素有八个：用例编号（唯一标识，如 Login-001）、用例标题（简明描述测试目的）、所属模块、优先级、前置条件（执行前需满足的环境或状态）、测试步骤与测试数据、预期结果（具体、可验证）、实际结果与执行状态。落到管理工具里，还会关联需求 ID、缺陷 ID，并补充编写人、执行人、所属版本。

好的用例有什么特点？一是全覆盖需求，步骤、数据、结果清晰可复用；二是有足够的异常用例，且不重复；三是经过评审。用一句话回答”好的测试用例长什么样”：换一个人拿着它，不看需求文档也能把测试跑完，且结果可验证。

Q：你怎么保证用例覆盖率？没有需求文档怎么测？

覆盖率没有绝对的 100%。提高覆盖率的思路是：先用思维导图梳理所有功能点，确保每个功能点都有对应用例；核心业务主流程必测（如注册 → 登录 → 下单 → 支付）；异常场景要补全（网络中断、数据为空、权限不足、输入非法字符）；兼容性要覆盖不同浏览器、设备、分辨率。覆盖率低的原因通常是 ROI 太低、部分场景难自动化、低频用例没必要覆盖。

没有需求文档时怎么测？先自己探索软件功能，把不确定的点列出来找产品确认；参考同类型产品的逻辑、历史用例和 Bug 库；先写出测试用例，组织产品和开发一起评审对齐，再执行。集中把模糊点反馈给产品，重大问题同步测试经理。

Q：现场写用例：登录、购物车、身份证输入框

这类”给你个功能写用例”的题，核心是先拆维度，再填细节。以登录功能为例，按功能、性能、安全、兼容、UI、易用、接口、异常八个方向铺开：功能正常（正确账号密码登录成功，跳转首页）；异常校验（错误密码提示”密码错误”、账号不存在提示”用户不存在”、用户名或密码为空提示”请输入”）；边界（用户名密码长度上下限、首尾空格处理）；安全（密码加密显示、连续 5 次登录失败锁定 15 分钟、防 SQL 注入/XSS、Cookie 加 HttpOnly、多端登录互斥）；性能（100 人同时登录响应 < 2 秒、页面加载耗时）；兼容（不同浏览器/手机端功能正常、布局不错乱）；UI（按钮排版、响应式）；易用（快捷键、复制粘贴）。如果测的是 App 登录，还要补第三方登录、手势登录、一键登录。

购物车（以电商为例）从入口到结算走一遍：先测购物车页面加载，再按”添加商品 → 查看商品 → 修改数量 → 删除商品 → 结算”的流程。关注点包括：功能（数量增减、选中/取消选中、库存不足提示、优惠券抵扣、跨店满减计算、删除后数据同步）；边界（数量上限如 99、库存为 0 时添加、价格小数点后多位）；异常（网络中断时添加商品、重复添加同一商品、删除后刷新页面）；兼容（不同浏览器/App 端购物车数据是否同步）；性能（大量商品加载时页面响应速度）。

身份证输入框这类题，回到等价类 + 边界值：有效（18 位合法身份证、最后一位是 X）；无效（位数不足/超长、含非法字符、校验位错误、地区码非法）；边界（17/18/19 位）；特殊（空值、全空格、X 的大小写）。

再往发散处走，还有几类经典题必须准备：纸杯测试（外观、容量、材质安全性、耐热耐冷、密封性、环保、成本、印刷、运输包装）；电梯测试（功能：开关门、楼层按钮、超载报警；性能：满载运行速度；安全：紧急制动、超载保护、夹人检测；兼容：不同楼层、不同电压环境；异常：断电、急停、门锁故障）；笔测试（外观、书写流畅度、笔帽安全性、墨水容量、耐摔、笔夹牢固度、笔迹颜色、环保）；微信红包/朋友圈发小视频/扫码支付（涉及金额计算、并发、幂等、可见范围、状态同步、退款的都要特别关注）。

3. HTTP 协议与接口测试

Q：为什么测试工程师要懂 HTTP？

想象你到餐厅吃饭。你（浏览器/App）是顾客，餐厅（服务器）是后厨。你们之间必须有一套说话的规则，不然你喊”来个包子”，后厨可能给你端碗面。HTTP 就是这套”顾客和后厨说话的规则”——它规定了你怎么点单、用什么格式说、后厨怎么回你、回你的时候带什么状态信息。接口测试的本质就是绕过前端页面，直接按这套规则跟服务器对话，所以懂 HTTP 是接口测试的前提。

Q：GET 和 POST 有什么区别？（最高频）

用餐厅类比。GET 像你问服务员”今天有什么菜”——只是获取信息，不改菜单；POST 像你递一张纸条给后厨”我要一份鱼香肉丝，少辣”——是提交数据，可能改变后厨状态。

	GET	POST
数据放哪	拼在 URL 上（?name=xxx&age=18），像大声喊出来	放在请求体（Body）里，像偷偷写纸条递过去
能看见吗	URL 上可见，不安全，别传密码	Body 里，URL 看不到
数据长度	有限制（通常 2KB～8KB，受 URL 长度限制）	理论上无限制
幂等性	是（多次执行结果相同）	否（可能产生副作用）
缓存	通常可缓存	通常不缓存
用途	查询数据	提交/修改数据

面试常追问两个点：”GET 和 POST 哪个更安全？”答案是 POST（数据不在 URL 上）；”GET 能传密码吗？”答案是能但不该这么做。加分答法是补一句：除了 GET 和 POST，还有 PUT（完整更新，类比把整份菜单换掉重做）、DELETE（删除，直接撤掉这道菜）、PATCH（局部更新）、HEAD（只返回报文头）、OPTIONS（查询支持哪些方法）。

Q：常见状态码有哪些？

状态码是后厨回你的”表情”——一眼就知道结果。

状态码	类别	餐厅类比	常见场景
200	成功	“来了您呐，菜齐了”	请求成功，返回数据
201	创建成功	“新菜做好了”	POST 创建资源成功，比如注册成功
204	成功但无内容	“菜上了，盘子里没东西”	删除成功，无返回体
301 / 302	重定向	“这道菜在隔壁窗口”	永久/临时跳转
304	未修改	“跟上次一样，别重复上”	用缓存
400	客户端错误-参数问题	“你说啥？没听懂”	传的参数格式不对
401	未认证	“你谁啊？先登录”	没带 Token 或 Token 过期
403	禁止访问	“你是 VIP 才能进这包厢”	登录了但没权限
404	找不到	“这菜我们店没有”	URL 写错，或资源不存在
500	服务器内部错误	“后厨着火了”	代码崩了
502 / 503	网关错误 / 服务不可用	“后厨临时停业”	网关挂了或服务过载

记忆口诀：2xx 成功，4xx 你的错（客户端），5xx 服务器崩了。

Q：Header 和 Body 有什么区别？

	Header（头）	Body（体）
餐厅类比	你跟服务员说的”暗号”（”我是 VIP””我要打包”）	你递过去的纸条内容（具体点什么菜）
放什么	Content-Type、Authorization（Token）、Cookie	实际的 JSON 数据，如 {“username”:”test”,”password”:”123″}
在哪看	浏览器 F12 的请求头里	请求体里

面试常问：”Token 放哪？”答案是放 Header 的 Authorization 字段里，不放 Body。常用的请求头还有 User-Agent（客户端标识）、Accept（接收类型）、Referer（来源）、Content-Type（请求体格式）。而 POST 的 Content-Type 常见有四种：application/x-www-form-urlencoded（表单）、application/json（JSON）、multipart/form-data（文件上传）、text/xml（XML）。

Q：Cookie、Session、Token 有什么区别？

这三个最容易混，用一个游乐园类比一次性打通。你去游乐园玩：

概念	游乐园类比	技术解释
Cookie	游乐园给你一张纸质手环，戴在手上，每次进门保安看一眼手环就放行	服务器发给浏览器的一小段数据，浏览器自动存着，每次请求自动带上
Session	游乐园前台自己记了一本本子：”手环编号 #123 = 张三，VIP”。手环只是编号，真正的信息存在本子里	服务器内存里存的用户信息，给客户端一个 SessionID（通常存在 Cookie 里）
Token	你手机上的电子票二维码，里面加密写了你的信息。验票员一扫就知道你是谁，游乐园自己不用记本子	一串加密字符串，包含用户信息，服务器不需要存任何东西，收到解密就知道你是谁

核心区别一句话记住：Cookie + Session = 服务器记你（有状态）；Token = 你自己带着自己的信息（无状态，服务器不记）。

面试连环追问要预判：Token 存在哪？前端存 localStorage 或 Cookie 里，每次请求放 Header 带过去。Token 过期了怎么办？用 Refresh Token 换新的，或者重新登录。为什么现在都用 Token 不用 Session？Session 占服务器内存，用户多了扛不住；Token 无状态，服务器不用存，好扩展。Cookie 里该存什么？重要信息存 Session，普通信息存 Cookie。

Q：什么是 RESTful API？

想象你去一家餐厅，后厨有 100 道菜。不好的点菜方式是每次都说一大段话——”我要那个、之前来过的、上次隔壁老王点的、那个辣的”——混乱。RESTful 的方式是每道菜都有固定编号，你直接说”给我 D12 号菜”。RESTful 就是给服务器上每一个”资源”都编号，用统一的动作操作它。

概念	大白话	例子
资源（Resource）	服务器上的”东西”——用户、订单、商品	一个用户、一个订单
URL 是资源的地址	每个资源有唯一 URL，就像每道菜有唯一编号	GET /users/123 表示”给我看编号 123 的用户”
用 HTTP 方法表示动作	不写 /getUser、/deleteUser 这种 URL，而用 GET/POST/PUT/DELETE 表示查增改删	DELETE /users/123 表示”删掉用户 123″

传统写法 vs RESTful 写法的对比：查用户 123，传统是 GET /getUser?id=123，RESTful 是 GET /users/123；创建用户，传统是 POST /createUser，RESTful 是 POST /users；改用户 123，传统是 POST /updateUser?id=123，RESTful 是 PUT /users/123；删用户 123，传统是 GET /deleteUser?id=123（错），RESTful 是 DELETE /users/123。

面试必考：为什么 GET /deleteUser?id=123 是错的？因为 GET 是”只读”的，不应该用来做删除这种改变服务器状态的操作。而且 GET 请求可能被浏览器预加载、被记录在日志里——用户一打开页面，就被删了。

RESTful 还有一个核心理念叫无状态（Stateless）。有状态像你去常去的面馆，老板记住你了——”老样子？”你不用每次重说。无状态像你去肯德基，每次点餐都得从头说，服务员不会记你上次点了啥。RESTful API 就是肯德基模式——每个请求都自带全部信息（Token 在 Header 里），服务器不需要”记得”你之前来过，因此可以随便换服务器，你照样点餐。

Q：接口测试的完整流程是什么？

这是一道”按顺序说出来就得分”的题。标准五步：

步骤	做什么	生活类比
① 看接口文档	读 Swagger/API 文档，搞清楚 URL、参数、请求方式、返回格式	拿到菜谱，先看要什么食材、怎么炒
② 设计测试用例	覆盖正常/异常/边界/安全/幂等	想好要试哪些做法——正常炒、多放盐、不放油
③ 执行测试	用 Postman/Fiddler 发请求，看返回结果	按菜谱下锅炒
④ 断言	自动判断返回的状态码 + 响应体是否符合预期	尝一口——咸淡对不对、熟没熟
⑤ 出报告	记录通过/失败的用例，截图或导出结果	写试菜报告给老板

面试中按这 5 步说出来，面试官就知道你有完整方法论。他追问哪一步你再展开。

三个高频追问要预判。问”接口文档都没有你怎么测？”答：”找开发要；实在没有就抓包看 App/Web 实际请求，然后自己整理成文档再测。”问”你怎么判断接口测通了？”答：”三层验证——① 状态码 200；② 响应体里的业务字段对不对；③ 去数据库查数据是不是真的写进去了。”问”接口测试能完全替代 UI 测试吗？”答：”不能。接口测的是后端逻辑对不对，UI 测的是前端展示 + 用户体验 + 端到端流程，两者互补。”

接口分析文档时，要重点看这几项：接口地址（完整 URL 含域名、路径、端口）、请求方法、请求头（Content-Type、Authorization）、请求参数（必填/选填、类型、长度、枚举值）、响应体（字段含义、类型、示例值）、错误码（各状态码对应含义）。文档里写的每一个约束，都是一条异常用例的来源。

Q：接口测试用例应该怎么设计？

接口测试面对的是一堆参数而不是页面按钮，所以有些维度是页面测试里不突出的。用例要从五个维度覆盖。

维度 1：正常场景（Happy Path）。所有参数都正确，期望返回成功。比如创建订单接口：userId=123、productId=456、quantity=2、addressId=789，期望状态码 200、业务 code 为 0，且数据库里多出一条订单记录。

维度 2：异常场景（参数级）。针对每个参数单独搞破坏。

异常类型	举例	期望
必填参数缺失	不传 userId	返回 400 + 提示”userId 不能为空”
参数类型错误	userId 传字符串 “abc”	返回 400 + 提示”参数类型错误”
参数值非法	quantity 传 -1	返回 400 + 提示”数量必须大于 0″
参数超长	address 字段传 1000 个字符	返回 400 + 提示”地址长度超限”

面试必考追问：”你是怎么知道该测哪些异常参数的？”答：”看接口文档里每个参数的类型、是否必填、长度限制、枚举值范围——文档里写的每一个约束，都是一条异常用例的来源。”

维度 3：边界值。还是那套套路，比如 quantity 限制 1~99：0 报错、1 成功（下边界）、99 成功（上边界）、100 报错。

维度 4：安全测试（接口特有）。接口直接暴露给外部，黑客可以直接调你的接口，所以安全测试在接口层必须做：越权访问（用用户 A 的 Token 请求用户 B 的订单接口，期望 403）；SQL 注入（参数传 ‘ OR 1=1 –，期望 400 或被拦截）；未授权访问（不传 Token 调需要登录的接口，期望 401）；敏感信息明文（看返回体有没有密码、身份证号明文，应脱敏或不存在）。面试被问”你做过接口安全测试吗”，答：”做过基础的——越权访问、SQL 注入、不传 Token 测 401、敏感信息脱敏检查。深度的安全测试有专门的安全团队做。”

维度 5：幂等性测试（接口特有，最容易漏）。幂等就是”调一次和调十次结果一样——不会多创建、不会多扣钱”。餐厅类比：你喊”来一份炒饭”喊了 3 次，如果是幂等的，后厨只做一份；如果不是，你喊 3 次就上 3 份，你多付两份钱。为什么接口必须测幂等？因为网络会抖——前端点了”提交订单”，请求发出去了但网络超时，前端没收到响应，用户以为没成功又点了一下，这时接口不幂等就会创建两个订单、扣两次钱。测试方法是：用相同请求参数（相同 orderNo）连续调 2 次创建订单接口，期望第 1 次返回成功，第 2 次返回”订单已存在”或同样结果，且数据库只有 1 条订单。追问”怎么实现幂等？”答：”常用方案——① 前端按钮置灰防重复提交；② 后端用唯一键/幂等表，比如订单号加唯一索引，第二次插入直接报错；③ 用 Redis 存请求指纹，短时间内相同请求直接返回上次结果。”

接口用例还可以按前置条件（登录态、默认参数）、业务逻辑（正逆向、参数关联、必填校验）、数据校验（返回值与数据库一致性）来组织，再叠加垃圾数据清理（用反向接口删除或直连 DB 清理）和 HTTPS 证书处理（requests 库可用 verify=False 跳过校验）。

Q：接口之间有关联怎么办？token 怎么传？

先想游乐园的场景：你先在门口买票（登录接口），拿到一张二维码票（token）。接下来玩过山车、鬼屋、碰碰车，每个项目都要刷这张票，你不可能每次玩项目都重新买票。接口关联的本质就是：前一个接口的返回值，作为后一个接口的输入。

最常见的关联是”登录 → 拿 token → 后续接口都带着”：① POST /login 传账号密码，响应体里拿到 token；② GET /orders 查订单列表，Header 里带上 token；③ POST /orders 创建订单，同样带 token。如果 ②③ 不带 token，就返回 401。

以 Postman 为例，核心就两步。第一步，在登录接口的 Tests（后置脚本）里把 token 存进环境变量：
var jsonData = pm.response.json();
pm.environment.set(“token”, jsonData.data.token);
就像买完票把二维码存进手机里。第二步，后续接口在 Header 里引用变量：
Authorization: Bearer {{token}}
就像玩每个项目时从手机里调出二维码刷一下。

其他关联场景逻辑一样：创建订单后查订单详情（创建返回 orderId → GET /orders/{{orderId}}）；添加商品后修改商品（添加返回 productId → PUT /products/{{productId}}）；删除前先确认存在（查询列表返回 ID 列表 → 取第一个 ID 去删除）。核心逻辑都是：前一个响应里的某个字段 → 存变量 → 后一个请求用 {{变量名}} 引用。JMeter 里对应的是”JSON 提取器”或”正则表达式提取器”，配合 CSV Data Set Config 做参数化。

Q：Postman 面试会怎么考你？

面试官可能怎么考	你要展示什么
“你现场用 Postman 发一个 GET 请求”	URL 填对、Params 加对、Send 后看响应
“写个断言，验证状态码是 200 且 message 是 success”	Tests 里写 pm.response.to.have.status(200) + pm.expect(jsonData.message).to.equal(“success”)
“怎么跑一批接口（Collection）”	Runner 里选 Collection，设迭代次数，跑完看结果报告
“怎么参数化，用不同数据跑同一个接口”	用 CSV/JSON 文件做数据驱动，Tests 里用 pm.iterationData.get(“字段名”) 读数据
“怎么生成测试报告”	Newman 命令行跑 Collection 导出 HTML 报告，或 Allure（如果做自动化）

面试加分项：说一句”我平时用 Postman 做冒烟测试，每次开发提测我跑一遍 Collection，3 分钟出结果，比手工点快多了”——面试官会记一笔”有提效意识”。Postman 的其他高频用法还包括：用 Collection 组织接口、用 Environment 管理变量（如 baseURL、token）区分测试/生产环境、用 Pre-request Script 动态获取参数、用 Cookie 管理器自动管理 Cookie。

Q：什么是 Mock 测试？什么时候用？

Mock 就是”假装有个接口，其实是你自己造的假数据”。什么时候用？依赖的接口还没开发完（你总不能干等），Mock 一个返回先测你的；第三方接口调不了（比如支付接口，总不能每次测试都真扣钱）；模拟异常场景（让 Mock 返回 500，测你前端怎么处理）。面试里说一句”我用 requests-mock 或者 pytest 的 monkeypatch 来 Mock 接口返回，主要用在第三方依赖和异常场景模拟”就够了。

性能测试里也会用到 Mock。有个经典问题是：”系统 A 调用系统 B，我把系统 B 的接口都 Mock 了做性能测试，有什么好处和坏处？”好处是排除外部依赖的干扰，能单独压测系统 A 的性能，且不受 B 的不稳定影响；坏处是测不出 A 与 B 联调时的真实瓶颈（网络延迟、B 的处理耗时），结果可能偏乐观。

Q：抓包工具是干什么的？什么时候需要抓包？

抓包工具（Fiddler、Charles、Wireshark）的原理是作为网络中间人拦截并解析通信数据包。出现”前后端互相甩锅”时特别有用：前端说接口返回数据不对，开发说接口没问题——抓包看实际传了什么参数、服务端实际返回了什么，就能定位是前端传错了还是后端返回错了。判断标准很简单：前端传参与抓包参数不一致，是前端问题；参数一致但返回错误，是后端问题，再结合状态码与日志辅助判断。抓包还能用于断点调试（改请求/响应）、模拟弱网、接口测试。

抓 HTTPS 包需要先安装并信任抓包工具的根证书，让它能解密再重新加密数据。Fiddler 是应用层代理，能拦 HTTP(S)；Charles 功能类似，Mac 上常用。

Q：接口测试常见的 Bug 有哪些？

参数校验缺失（该报错的没报错）、未授权访问（没带 Token 也能调）、越权（能访问别人的数据）、响应格式错误、状态码异常（该返回 400 却返回 200）、数据与数据库不一致、接口未实现、边界处理错误、明文传敏感信息、并发下数据异常、响应超时。接口测试的核心价值在于测试前移——前端还没完成时就能提前介入，发现底层问题，降低修复成本；它比 UI 自动化更稳定、执行更快、语言无关、更容易定位问题、覆盖率更高。

Q：接口自动化和 Web 自动化有什么区别？

接口自动化测试对象是接口，不涉及 UI 渲染，因此效率更高、更稳定、维护成本更低。动态参数和依赖接口的处理靠 pytest 的 fixture 管理测试状态、传递参数。结果断言通常分三层：协议状态码、业务状态码、具体业务数据。接口自动化框架常按分层设计：common（公共方法）、config（配置）、log（日志）、report（报告）、testcase（用例）、utils（工具），pytest.ini 为配置文件。这套思路在自动化章节还会展开。

4. Bug 管理与测试流程实战

Q：一条完整的缺陷记录包含哪些要素？

标准要素包括：摘要/标题、重现步骤、测试数据、测试环境（系统、浏览器、版本）、所属模块、严重程度、优先级、指派人、预期结果、实际结果、附件（截图/日志）、编号、备注。工具里还会带上状态和版本字段。回到拼单那个例子，一条合格的 Bug 记录是：标题”拼单满 5 人后第 6 人仍可加入且金额计算错误”；环境”v2.3.1，iOS 17，iPhone 14″；前置条件”已创建一个 5 人拼单，状态为进行中”；步骤”1. 打开拼单页面 2. 点击加入拼单 3. 用第 6 个账号确认加入”；期望”提示拼单已满员，无法加入”；实际”第 6 人成功加入，每人应付金额从 20 元变成 24 元”；附件”截图 + 操作录屏 + 后台日志”；严重程度”严重（P0）——涉及多扣钱”。

如何定义严重等级和优先级？严重程度看问题本身对系统的影响：致命（崩溃、丢数据、核心流程阻断）、严重（主功能失效）、一般（界面/格式错误）、建议（文案/体验优化）。优先级看修复的紧迫性，由严重程度、影响用户范围、是否阻塞其他测试共同决定。两者不一定一致——一个”界面错别字”严重程度低，但如果是品牌名写错，优先级可能很高；一个”极端场景下崩溃”严重程度高，但触发条件极罕见，优先级可能中等。

Q：开发不认为是 Bug，或有争议怎么办？

标准流程三步走：先核对需求文档，拿依据说话，而不是凭主观判断；然后平和沟通，说明这个问题对用户的实际影响；如果还是谈不拢，上报测试经理，拉上产品一起开评审会定结论。关键是把”我和开发的争论”转化为”对照需求标准的判定”——需求文档是唯一裁判。

衍生问题也要准备。开发说”这是需求设计如此”时，先确认自己读的是不是最新需求，如果不是，认；如果是需求本身有问题，就推动产品和开发一起改需求。测试组员提前测完了但你发现还有很多问题，怎么处理？先不指责，私下找组员沟通，确认他是漏测了某些场景（异常流程、边界值）还是理解偏差，一起复现问题；如果是用例设计有遗漏，及时补充用例并同步给团队；如果是需求理解偏差，拉上产品和开发重新对齐；最后把问题同步给测试组长，避免影响上线节奏，后续组织用例评审时更严格把关。

Q：Bug 复现不了怎么办？页面报 404/500 怎么处理？

复现不了时，先保留当时的截图、日志和操作记录，尽量尝试复现；如果实在复现不了，也要把问题提上去并标注”偶现”，让开发留意，在后续测试中持续关注，必要时上报评审。开发频犯低级错误怎么办？推动流程改进——要求提测前自测、设置冒烟准入；加强测试覆盖；推行”常见缺陷自查清单”促进自检；必要时配套奖惩。测试过程中看到 404 通常是 URL 或路由问题，500 通常是服务端异常，处理思路是：确认前端请求的参数与 URL 是否正确 → 抓包或看后端日志定位报错堆栈 → 是前端问题就让前端改，是后端问题提 Bug 给后端并附上日志。

修复一个 Bug 导致其他 Bug 出现，怎么处理？这正是回归测试存在的意义——记录问题关联，把新旧问题一起回归验证，并在 Bug 记录里注明关联关系，避免开发顾此失彼。发现的缺陷越多，说明软件缺陷越多吗？不一定。缺陷数量还取决于测试人员的经验、用例质量、测试时间，缺陷发现的多往往也说明测试做得细，所以不能单看数量下结论，要看缺陷密度和趋势。所有缺陷都能修复吗？不是。有些缺陷受技术或成本限制只能绕行，有些被判定为”设计如此”，有些被延后到下个版本——测试要区分”能修、该修、先修哪个”。

Q：测试时间不够、进度跟不上怎么办？

常见应对：申请加班、申请支援、与产品协商延期或缩减范围、优先保障核心高优先级功能。更专业的答法是结合风险评估做取舍：先按业务重要性把功能划分为 P0/P1/P2，时间不够时保证 P0 全覆盖，P1 部分覆盖，P2 顺延；同时把风险和取舍明确同步给项目和产品，让决策层知情。项目经理/测试经理在版本周期里一般会跑 3~5 轮测试，具体轮次受需求规模、人员能力、软件质量影响；每轮之间都要评估是否可以进入下一轮，这就是”准入准出”的把关。

Q：测试报告要写哪些内容？

日常测试报告通常包含：测试环境、测试依据、用例执行情况（执行数/通过率）、Bug 统计（新增/修复/遗留、按严重程度和模块分布）、风险评估、测试结论（是否可以上线、遗留问题和对上线的影响）。交给用户的版本还会加上引言、测试范围概述、测试过程描述、质量评定和建议。测试报告的价值不是”证明我测过了”，而是给决策者提供”能不能发版”的判断依据。

Q：与开发、产品、用户的沟通有哪些典型场景？

开发不认 Bug：对照需求文档，分歧则与产品对齐，统一标准，用文档而不是情绪说话。
线上 Bug：先在测试环境复现（复现不了就拉日志和监控），能复现就按系统 Bug 提单并评估优先级与发布计划；怀疑是环境问题就联合运维/开发排查。
用户投诉：记录细节，功能缺陷推动修复，体验问题反馈给产品优化——不要一句”这是设计如此”把人堵回去。
犯错了怎么办：第一时间评估影响范围，如果是漏测立即补测并提 Bug，同步给开发和产品；如果是环境问题快速排查修复；事后复盘原因（需求理解错？用例漏写？流程问题？），制定改进措施（增加交叉测试、补充检查清单），不隐瞒不推诿。
接到无法解决的客户抱怨电话：先安抚并完整记录问题，承诺反馈时限，转交能处理的人，事后回访确认。核心是让客户感到”被认真对待”。

Q：回归测试怎么选范围？

回归不是每一次都全量重跑，要结合时间、资源、风险来选策略：全面回归（改动大、影响面广时全跑）、部分回归（只跑受影响模块）、选择性回归（只挑高风险用例）。减少回归工作量的常见手段包括：维护核心用例集、标记用例与需求的关联、用自动化覆盖稳定的回归场景。回归测试不是”把所有用例重新点一遍”，而是”基于改动影响面，选出风险最高的那部分用例重跑”。面试里把这句话说出来，比背定义加分。

Q：测试对象到底是什么？软件为什么会出错？

测试对象不只是代码，还包括需求文档、设计文档、程序代码、用户手册、配置数据、以及最终交付的整个系统——文档测试、配置测试都属于测试范畴。软件出错的原因主要有：需求本身有歧义或缺失、设计与编码引入错误、不同模块交互产生的接口错误、环境/数据差异、以及人的认知与协作偏差。理解”错误从哪来”，才能理解为什么测试要左移（在需求阶段拦截）、要覆盖集成（在接缝处拦截）。软件测试的风险主要体现在：测试不完备导致漏测、需求变更导致用例失效、时间不足导致覆盖下降、测试环境与生产环境不一致导致问题无法提前暴露。做好测试的关键点：早期介入、有效的用例设计、清晰的标准（准入准出）、充分的环境与数据准备、以及持续的沟通与复盘。

5. 自动化测试

Q：先建立一个全局画面：一个自动化框架长什么样？

把它想象成一家中央厨房。菜谱（告诉厨房做什么菜）对应测试用例，也就是 pytest 的 test_xxx.py 文件；食材仓库（菜从哪来）对应测试数据，放在 Excel/YAML/JSON 文件里；厨具（炒菜的工具）对应发请求的工具，比如 requests 库；尝菜标准（咸淡对不对）对应断言，也就是 assert 语句；试菜报告（给老板看）对应测试报告，比如 Allure 或 HTML 报告；排班表（什么时候自动跑）对应定时执行，比如 Jenkins 或 GitLab CI。面试里能把这套类比讲出来，面试官立刻知道你有全局观。

Q：自动化测试适用于什么场景？怎么选工具？

适合自动化的场景：回归测试（版本迭代后快速验证核心功能）、冒烟测试（每日构建后验证系统可用）、数据驱动测试（大量重复数据输入）、高频执行（性能压测、持续集成流水线）。不适合的场景：UI 频繁变动、一次性测试、探索性测试。工具选择上，Web UI 常用 Selenium（支持多语言）、Cypress、Playwright；API 常用 Postman（轻量）、RestAssured（Java）、Requests（Python）、JMeter（性能 + 功能）；移动端常用 Appium（跨平台）。选择依据是项目技术栈、团队技能、维护成本、社区支持、CI/CD 集成能力。

自动化与手工测试怎么分工？健康的比例没有绝对数字，原则是”稳定、高频、重复、有明确预期的场景交给自动化，探索性、易变、一次性的场景留给手工”。自动化的核心指标包括用例覆盖率、时间成本、投入产出比（ROI）、缺陷发现数。覆盖率很难做到 100%，因为 ROI 低、部分场景难自动化、低频用例没必要覆盖——面试里能主动说出”覆盖率不是越高越好”，是个加分点。

Q：一个标准的接口自动化框架怎么组织？

以 pytest + requests 为例，典型的项目结构是：
api_test/
├── conftest.py —— 全局配置（登录拿 token、公共 fixture）
├── config/config.yaml —— 环境配置（dev/test/prod 的 base_url）
├── test_cases/ —— 用例（test_login.py、test_order.py、test_user.py）
├── common/ —— requests_util.py（封装请求，统一处理 token、日志）、assert_util.py（封装断言）
├── data/ —— 测试数据（login_data.yaml）
├── reports/ —— 生成的测试报告
└── pytest.ini —— pytest 配置文件

面试必考”你的自动化框架是怎么组织的”，答：”按分层设计——test_cases 放用例、common 放公共方法、data 放测试数据、config 放环境配置、conftest 做全局 fixture。这样用例跟代码分离，好维护。”

Q：pytest 的核心用法有哪些？

① fixture——”准备工作”。fixture 就是测试前自动帮你做的事，类比进厨房炒菜前有人已经把锅热好、油倒好了。最常用的场景是登录拿 token：在 conftest.py 里用 @pytest.fixture(scope=”session”) 定义一个 get_token，向登录接口发起请求，把返回的 token 返回出去。追问 scope 有哪些？function（每个用例都跑）、class（每个类跑一次）、module（每个文件跑一次）、session（整个会话只跑一次）。为什么用 session？登录只需要一次，所有用例共用同一个 token，省时间。

② parametrize——”数据驱动”。不用写 10 个用例测 10 组数据，写 1 个用例 + 10 组数据就行。用 @pytest.mark.parametrize(“username,password,expected”, […]) 把数据列在装饰器里，用例函数接收参数。追问”你怎么做数据驱动”，答：”用 @pytest.mark.parametrize 装饰器，把测试数据和用例逻辑分离。数据可以写在代码里，也可以从 YAML/Excel 文件读。”

③ assert——”断言”。Python 原生，不用装库：assert resp.status_code == 200；assert resp.json()[“code”] == 0；assert “orderId” in resp.json()[“data”]。加分做法是封装一个公共断言方法，比如 assert_code_message(resp, expected_code=0, expected_message=”success”)，把状态码、业务码、message 一次性校验。

Q：conftest.py 是干什么的？

一句话：conftest.py 是 pytest 的”全局配置中心”——里面定义的 fixture 可以被所有测试文件自动共享，不用 import。类比公司前台——你不用每个部门自己招前台，一个前台服务全公司。可能被问”它和普通文件有什么区别”（里面的 fixture 自动生效，所有 test 文件都能直接用，不用 import）和”可以有多个 conftest.py 吗”（可以，放在不同目录下，作用域不同，就近生效）。

Q：数据驱动怎么写？

面试里说”我用 YAML 做数据驱动”比说”写在代码里”高一个档次。YAML 文件里按用例列出 username、password、expected；Python 里写一个 get_test_data() 用 yaml.safe_load 读文件，再用 @pytest.mark.parametrize(“case”, get_test_data()) 把数据喂给用例，用例里 case[“username”] 取字段。这样数据和逻辑彻底分离，改数据不用动代码。

Q：测试报告怎么生成？你的自动化跑完怎么看结果？

答：”用 Allure 生成 HTML 报告——能看到每个用例的通过/失败状态、请求参数、响应内容、失败截图和日志。也可以集成到 Jenkins，每次跑完自动发邮件给团队。”基本命令是先 pytest –alluredir=./reports 生成数据，再 allure serve ./reports 启动本地服务看报告。其他方案：pytest –html=report.html 生成简单 HTML 报告；JUnit/TestNG 有内置 XML 报告；Java 里常用 ExtentReports，支持图表和截图。Allure 的优势是跨语言、支持步骤和附件、有趋势图。

Q：CI/CD 是什么？你的自动化怎么集成进去？

CI（持续集成）是代码提交后自动构建、测试；CD 是持续交付（代码随时可评审，就绪生产）或持续部署（测试通过后自动部署到生产）。面试必问”你的自动化怎么集成到持续集成里”，答：”Jenkins 里配一个任务，代码推到 Git 后自动触发 pytest 执行，跑完生成 Allure 报告，失败就发钉钉/邮件通知。也可以用 GitLab CI 写 .gitlab-ci.yml 配置流水线。”你不需要会配 Jenkins（那是运维的事），但要知道整个流程。Jenkins 是开源 CI 工具，支持任务调度、自动化构建测试、结果可视化；主节点（master）管任务，从节点（slaves）执行任务，多节点适配多环境；备份要备份 JENKINS_HOME 目录。

Q：Selenium 的原理是什么？

Selenium WebDriver 通过浏览器驱动（如 ChromeDriver）与浏览器通信：脚本按 WebDriver 协议发请求（早期是 JSON Wire Protocol），driver 作为服务端解析后在浏览器里执行操作（点击、输入、获取元素），浏览器再把结果（DOM、截图、日志）返回给脚本。一句话表述：”我写代码 → WebDriver 发给浏览器驱动 → 驱动控制浏览器操作 → 返回结果给我。”

元素定位有八大方式：Id、Name、Class Name、Tag Name、Link Text、Partial Link Text、CSS Selector、XPath。find_element 返回第一个匹配，find_elements 返回所有匹配的列表。定位失败常见原因：表达式写错、没有等待元素加载、iframe 遮挡、页面布局变化。动态元素怎么定位？用稳定属性、父子/兄弟关系相对定位、遍历、或用 XPath 的父节点轴（.. 或 parent::*）；隐藏元素（type=”hidden” 或 display:none）可以用 JS 移除属性后再定位。判断元素是否显示用 is_displayed()，判断是否存在用 try…except 捕获 NoSuchElementException。

Q：等待机制有哪几种？该用哪个？

三种：强制等待 time.sleep(5)，固定阻塞线程，不推荐；隐式等待 driver.implicitly_wait(10)，全局设置查找元素的等待时间，等页面加载，灵活性低；显式等待 WebDriverWait(driver, 10).until(EC.presence_of_element_located((By.ID, “username”)))，针对特定元素和条件，满足即执行，最多等指定时长，最推荐。稳定性优化就是”用显式等待替代 time.sleep()，并加异常捕获”。常见异常要记住：NoSuchElementException（元素未找到）、AssertionError（断言失败）。

Q：POM 模式是什么？有什么好处？

POM（Page Object Model）把每个页面封装成一个类，类里包含该页面的元素定位和操作方法，测试脚本只调用页面对象的方法，不直接操作元素。好处是页面变化时只需改这个页面对象，不用改所有用例，提高复用性和可维护性。相关的还有数据驱动模型（测试数据从外部文件读取，同一脚本传不同数据）和混合模型（PO + 数据驱动，实际项目最常用）。

Selenium Grid 用于分布式测试，多环境并行执行以缩短时间、提高效率：Hub 是中心节点，负责管理和分发；Node 是执行节点，负责实际跑脚本。

Q：自动化脚本的稳定性问题怎么处理？

显式等待替代 time.sleep；元素定位优化，使用稳定 ID、CSS Selector，避免依赖动态属性；对偶发失败用例设置重试（pytest-rerunfailures 插件，执行时加 –reruns 3）；环境隔离（用 Docker 容器化测试环境，确保一致性）；记录详细日志便于定位失败原因；CI/CD 里并行执行，失败及时通知。其他实战细节：用 driver.close() 关闭当前页、driver.quit() 关闭所有页并结束进程；用单例或全局变量管理 driver，所有页面对象共用一个 driver，避免重复创建浏览器；用例失败或异常时自动截图，便于回溯。

Q：特殊场景怎么处理？

验证码：测试环境禁用或使用测试专用验证码、手动输入、对接开发留的万能码接口，或把含验证码的用例标记为不稳定。
alert 弹窗：用 switch_to.alert 切换后 accept() 确认 / dismiss() 取消。
多窗口：通过 window_handles 获取句柄列表后切换。
iframe 元素：用 switch_to.frame() 切入后定位，操作完用 switch_to.default_content() 切回主文档。
文件上传：用 send_keys() 传文件路径，或用 AutoIt 模拟。
执行 JS：用 driver.execute_script() 在脚本里执行 JavaScript。

Q：Appium 是怎么工作的？移动自动化与 Web 自动化有什么区别？

Appium 基于 WebDriver 协议，支持 iOS/Android/FirefoxOS。环境搭建：安装 Node.js、JDK、Android SDK（或 Xcode）、Appium（npm install -g appium）、Appium Desktop，配置 ANDROID_HOME 和 PATH，用 adb devices 连接设备或启动模拟器，再 pip install Appium-Python-Client。核心操作是配置 Desired Capabilities（platformName、deviceName、appPackage、appActivity 等），用 webdriver.Remote(‘http://localhost:4723/wd/hub’, desired_caps) 启动会话，元素定位方式与 Selenium 类似，用 driver.quit() 关闭会话。Appium 的定位策略同样支持 ID、XPath、Accessibility ID 等；当定位策略都失败时，回到”抓取页面结构（用 Inspector / UIAutomator Viewer）→ 寻找稳定属性 → 组合定位”的思路。Selenium 和 Appium 的关系：Appium 复用了 WebDriver 协议，可以理解为”移动端版的 Selenium”。

维度	Web 自动化	App 自动化
工具	Selenium	Appium
用例设计方法/测试原理/模型/执行策略	一致
额外测试点	浏览器兼容	中断测试、安装卸载、多设备适配、弱网
兼容性聚焦	浏览器（Chrome/Firefox/Safari）	厂商 + 系统版本（华为/iPhone、Android 12/15）

移动端常见问题包括：ADB 检测不到设备（装驱动、开 USB 调试、重新插拔并授权）、定位/等待不足导致脚本报错、需求频繁变更时暂缓自动化开发（等版本稳定再推进）。App 崩溃日志的抓取：iOS 靠 iTunes Connect、Xcode、第三方 SDK；Android 靠第三方 SDK、加固工具，或在代码里捕获异常写入日志。Monkey 测试可做随机压力测试，但它能发现闪退却难以复现具体路径——用 Monkey 发现闪退后，一般结合日志和 seed 尽量复现，复现不了就作为偶现问题提单。

Q：Python 在自动化里的几个常见追问

列表和集合的区别：列表有序可重复、支持索引；集合无序不可重复、不支持索引，常用于去重和交并集运算。
浅拷贝和深拷贝：浅拷贝只拷贝对象本身，对象里的子对象还是引用原地址（改子对象会影响原对象）；深拷贝递归拷贝所有层级，完全独立（copy.copy() 是浅拷贝，copy.deepcopy() 是深拷贝）。
生成器：用 yield 返回值的函数，每次调用 next() 才执行到下一个 yield，节省内存，适合处理大量数据。
跳过用例 / 失败重跑：pytest 里用 @pytest.mark.skip 或 @pytest.mark.skipif 跳过用例；失败重跑装 pytest-rerunfailures 插件，执行时加 –reruns 3。
self / cls / super：self 是实例方法首参，指代实例；cls 是类方法首参，指代类；super 用于调用父类的属性和方法。unittest 里 setUp() 在每个测试方法前执行、tearDown() 在每个测试方法后执行。

6. 性能测试

Q：面试官为什么爱问性能测试？

大多数岗位不是指望你去做专职性能测试，而是看你有没有”性能意识”——测功能时会不会想到”人多了会不会崩”。所以性能环节的目标是”概念清楚、指标会说、流程能描述、工具知道是什么”，不必深到调优细节。

Q：性能测试的核心指标有哪些？

指标	大白话	餐厅类比
响应时间	用户发出请求到看到结果要多久（关注平均、最小、最大、90%/95%/99% 分位）	点完菜到上菜的时间
并发用户数	同一时刻多少人同时操作	同时坐在店里吃饭的人数
吞吐量	系统每秒能处理多少请求	后厨每分钟能出几道菜
TPS / QPS	每秒事务数 / 每秒查询数	收银台每秒能结几单
资源利用率	CPU、内存、磁盘 IO、网络带宽占用率	后厨的煤气、水电消耗
错误率	失败请求占总请求的比例	上错菜的比例
点击率（HPS）	每秒请求数，常用于 Web 服务器	单位时间的点单量

响应时间有一组实用的判断阈值，叫”2/5/8 原则”：2 秒内算快，2~5 秒可接受，5~8 秒算慢，超过 8 秒基本不可接受（上传下载类场景可适当放宽）。

Q：负载测试和压力测试有什么区别？

	负载测试	压力测试
目的	找到系统能承受的最大极限在哪	把系统压到崩溃，看它怎么挂、挂了能不能恢复
做法	慢慢加人，加到响应变慢的那个点	直接塞爆，看什么时候宕机
类比	慢慢往电梯里塞人，看塞到几个时报警	直接往电梯里塞 50 个人，看电梯会不会塌

一句话记住：负载是”找到极限”，压力是”打爆看反应”。相关概念还有：容量测试（测最大并发用户数/数据量）、强度测试（在低资源下验证系统运行情况）、极限测试（过量用户连续操作）。

Q：性能测试的完整流程是什么？

需求分析 → 测试准备（计划、用例、环境、数据）→ 脚本开发（录制或手写、参数化、加断言、配监听器）→ 场景执行 → 结果分析 → 调优 → 报告。场景设计上分两类：单接口压测（固定参数，阶梯式增加并发，如 10 → 50 → 100 → 500，观察 TPS 和响应时间的变化）；混合场景（按业务比例分配并发，如登录 20%、查询 50%、下单 30%，用线程组或 Controller 配置不同脚本的混合执行）。脚本里三个关键技术：关联（提取动态参数如 SessionID 供后续请求使用）、思考时间（模拟用户操作间隔，贴近真实）、参数化（把固定数据换成动态参数，适配不同数据）。

需求调研时要区分对象关注点：用户关注响应速度，开发关注响应时间和数据库交互，管理员关注体验和调优。没有明确性能需求时，可以通过沟通客户、分析线上日志、对标竞品、经验推导来确定目标。敏捷项目则是每个迭代定目标、建自动化体系、结合业务场景评估（比如报名系统只在报名前压测）。

Q：性能瓶颈一般出现在哪些环节？怎么分析？

环节	常见瓶颈	分析与优化
服务器	CPU 过载、内存不足、磁盘 IO 瓶颈、线程池耗尽	用 top/vmstat/iostat 监控，扩容、优化线程模型、负载均衡
数据库	慢查询、锁竞争、连接池耗尽、索引缺失	慢查询日志 + EXPLAIN 分析，加索引、优化 SQL、分库分表、读写分离
网络	带宽不足、延迟高、丢包	ping/traceroute/Wireshark 排查，压缩数据、CDN 加速、优化路由
代码	算法低效、死循环、资源未释放、同步阻塞	算法优化、异步处理、缓存（Redis）、减少 I/O

TPS 上不去是很典型的现象，原因可能有很多：带宽不足、连接池过小、GC 频繁、数据库无索引或未读写分离、通信低效、硬件不足、压力机自身达到上限、业务逻辑复杂、缓存命中率低。页面卡顿则要从三处找：后端接口慢、前端 JS 耗时、网络延迟。内存泄漏表现为内存持续增长不释放，最终导致宕机或响应变慢。

Q：JMeter / LoadRunner 你知道多少？

JMeter 是 Apache 开源的压测工具，能模拟多用户并发请求接口并生成性能报告。基本用法：添加线程组（设置并发数、循环次数），添加 HTTP 请求（配置接口参数），添加监听器（查看结果树、聚合报告、图形结果），参数化用 CSV Data Set Config，关联用 JSON 提取器，压测后分析响应时间、吞吐量、错误率，定位性能瓶颈。JMeter 保持 Session 的做法是把登录后的 Session 存下来，后续请求读取。如果登录接口需要先返回参数再带着参数请求才能完成登录，就用 JSON 提取器把参数提取出来，供后续请求引用。

LoadRunner 分三部分：VUGen（脚本录制）、Controller（场景调度）、Analysis（结果分析）。它和 JMeter 的流程类似——需求分析、脚本开发、场景设计与执行、结果分析、调优。面试里主动说一句”我了解概念，深度压测有专职性能团队做，但我有性能意识，功能测试时会关注并发场景”就够了。

典型的场景题：”打车高峰期滴滴服务端挂了 30 分钟，工程师抢修后立即上线，之后又挂了，可能有哪些原因？”可以从几个角度答：抢修只是临时扩容或重启，没有定位根因（如某段慢 SQL 或缓存雪崩），流量一恢复就再次打满；限流降级措施没有生效；数据库连接池或线程池没有恢复；依赖的外部服务还在故障——本质是”故障恢复不是重启就完事，要找到并消除根因”。

7. 数据库与 Linux

Q：SQL 基础增删改查怎么写？

测试工程师用 SQL 的场景很明确：接口测完去数据库验证数据对不对、造测试数据、排查线上数据问题。所以最该熟练的是查询，其次是造数和改数。

查：SELECT * FROM 表名 WHERE 条件;（查所有）
查指定列：SELECT column1, column2 FROM 表名 WHERE condition;
插：INSERT INTO 表名 (列1, 列2) VALUES (值1, 值2);
改：UPDATE 表名 SET 列=值 WHERE 条件;（务必带 WHERE，否则全表更新）
删：DELETE FROM 表名 WHERE 条件;（慎用）
排序：ORDER BY 列 DESC/ASC；限制条数：LIMIT 10。
模糊查询：WHERE 列 LIKE ‘%关键词%’。

给个热身练习（面试常让你现场写）：查所有用户的用户名和年龄；查年龄大于 25 岁的用户；查城市是”北京”的用户并按年龄从大到小排；插入一条新用户张三、30 岁、上海；把用户 ID=1 的年龄改成 28。这几条写利索了，基础语法就算过关。

Q：JOIN 多表查询怎么写？（面试最高频）

先理解为什么需要 JOIN。你有两本账：本子 A 记着”谁是谁”（用户 ID → 用户名），本子 B 记着”谁花了多少钱”（用户 ID → 订单金额）。老板问”张三花了多少钱”，你光看本子 B 只知道”用户 ID=1 花了 200 元”，不知道用户 ID=1 是谁，必须把两本本子按用户 ID 对在一起看——这就是 JOIN。

用两张表说明。用户表 users：id、username、age、city，数据有 (1, 张三, 28, 北京)、(2, 李四, 22, 广州)、(3, 王五, 35, 北京)。订单表 orders：id、user_id、amount、status、created_at，数据里有 (101, 1, 150.00, paid)、(102, 1, 80.00, paid)、(103, 2, 200.00, pending)、(104, 4, 99.00, paid)。注意 orders 里有条 user_id=4，但 users 表里没有 id=4 的用户——这条订单对应的用户被删了。这个”脏数据”正是区分三种 JOIN 的关键。

JOIN 类型	大白话	类比
INNER JOIN	只保留两表都能对上的行	只找”有订单且用户还在的”
LEFT JOIN	以左表为准，右表对不上就填 NULL	列出所有用户，有没有订单都行
RIGHT JOIN	以右表为准，左表对不上就填 NULL	列出所有订单，用户不在也行

经典题一：查每个用户的用户名和他们的订单总金额（只有下过订单的用户才显示）。答案用 INNER JOIN + SUM + GROUP BY：
SELECT u.username, SUM(o.amount) AS total FROM users u INNER JOIN orders o ON u.id = o.user_id GROUP BY u.id;
结果只会有张三（230.00）和李四（200.00），王五没订单不显示，user_id=4 因用户不存在也被过滤掉。

经典题二：列出所有用户及其订单金额，没下单的也要显示。
SELECT u.username, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id;
这时王五会以 NULL 出现。经典题三：找出没有下过任何订单的用户。
SELECT u.username FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL;

Q：聚合函数和 GROUP BY 怎么用？

聚合函数有 COUNT(*)、SUM(列)、AVG(列)、MAX(列)、MIN(列)。配合 GROUP BY 分组：
SELECT user_id, COUNT(*) AS order_count FROM orders GROUP BY user_id;
这就是”一个用户表一个订单表，查每个用户的订单总数”的答案。加排序和过滤要注意执行顺序：WHERE 在分组前过滤，HAVING 在分组后过滤，ORDER BY 最后排序。SQL 的完整执行顺序是 FROM → ON/JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT，这个顺序面试常考，因为很多人以为 SELECT 最先执行。

Q：事务、索引、存储过程分别是什么？

事务的 ACID：原子性（要么全执行要么全回滚）、一致性（前后状态都合法）、隔离性（并发互不干扰）、持久性（提交后永久生效）。MySQL 里用 begin / rollback / commit 控制事务，set autocommit=0 可关闭自动提交。面试常考的”转账”场景就是典型事务：扣 A 的钱和加 B 的钱必须一起成功或一起失败。

索引：优点是查询快、能保证唯一性；缺点是占空间、增删改变慢。为 WHERE 和 JOIN 用到的字段建”短索引”，避免过度索引而拖慢写入。常用的关系型数据库概念还有：主键（唯一非空，标识一行）、外键（关联另一张表的主键）、超键（能唯一标识元组）、候选键（最小的超键）。

存储过程和函数：存储过程是一组预编译的 SQL 集合，可带输入输出参数、可返回多个值；函数必须有返回值、通常用于计算。触发器是当某张表发生增删改时自动执行的 SQL，用于做联动或审计。测试相关考点：存储过程要单独测参入参出和异常分支。

delete / truncate / drop 的区别：delete 删数据、可回滚、会触发触发器；truncate 删全表数据、不可回滚、无触发器、速度快；drop 删表结构加数据、不可回滚。

Q：查询怎么优化？怎么排查线上问题？

优化思路：给 WHERE 和 JOIN 字段加索引；避免 SELECT *；用 EXPLAIN 看执行计划（重点关注 type、key、rows）；避免在索引列上做函数运算；分页查询用 LIMIT；数据量大时考虑分库分表、读写分离。看 SQL 效率主要靠 EXPLAIN 和慢查询日志。MySQL 分页用 LIMIT offset, size。

线上问题排查的 SQL 套路：慢查询开慢查询日志、用 EXPLAIN 看执行计划；数据异常用 SELECT * FROM 表 WHERE 条件 LIMIT 10 看具体数据；死锁用 SHOW ENGINE INNODB STATUS;；连接数过多用 SHOW PROCESSLIST;；数据不一致用 JOIN 或 UNION 找出差异；权限问题用 SHOW GRANTS FOR user;。生成 10 万条测试数据可以用存储过程循环插入或写脚本批量插入。提取倒数 10 条数据用 ORDER BY id DESC LIMIT 10。

Q：关系型数据库和 NoSQL 有什么区别？

	关系型（MySQL/PostgreSQL）	非关系型（MongoDB/Redis）
存储模型	表结构固定，支持 SQL、事务	键值/文档存储，不支持标准 SQL
优势	易维护、事务完备、适合业务数据	扩展性强、读写快，适合日志、缓存
劣势	读写性能相对低、扩展难	事务和复杂查询弱

Redis 是内存键值存储，能到十万级 QPS，单线程安全，支持多种数据结构，可做缓存、分布式锁、消息队列，支持持久化。测试 Redis 相关场景时要关注：缓存命中、缓存与数据库的一致性、缓存雪崩/穿透、过期策略。MySQL 与 MongoDB 的本质差别在于：MySQL 是结构化、强一致的关系模型，MongoDB 是灵活的文档模型、无固定表结构。

Q：Linux 常用命令有哪些？

测试工程师为什么要会 Linux？因为你测的服务器跑在 Linux 上，线上出问题了，你不能说”我不知道怎么查”——你得登上去看日志、查进程、确认服务是不是挂了。类比：包子铺后厨在地下室，前台客人投诉包子有问题，你得下地下室看监控录像（日志）+ 确认蒸笼还在不在工作（进程）。

文件操作基础

命令	干什么	例子
pwd	显示当前目录	pwd → /home/test
ls	列出目录内容	ls -la（详情 + 隐藏文件）
cd	切换目录	cd /var/log
mkdir	创建目录	mkdir testdata；多级目录 mkdir -p a/b/c
cp / mv / rm	复制 / 移动（改名）/ 删除	cp a.txt b.txt；rm -f a.txt
touch	创建空文件	touch file
cat / less / more	查看文件	cat file；less file（分页，/ 搜索，q 退出）

面试常问”rm -rf / 是什么”，答：”递归强制删除根目录下所有文件——删库跑路命令，绝对不能在生产环境敲。”问这个是看你有没有安全意识。

查看日志（面试最高频）

这是你作为测试工程师用得最多的技能。面试官必问”线上用户反馈下单失败，你怎么排查”，标准回答流程是：登服务器 → cd 到日志目录（如 /var/log/app/）→ ls -lt 看最新日志文件 → tail -f 文件名实时跟踪 → 让用户再操作一次，观察有没有报错 → grep “ERROR” 文件名过滤错误 → 用 less 或 cat 看报错前后的完整上下文。

tail -f app.log：实时跟踪日志，类比盯着监控屏幕实时看。加分点：tail -n 200 app.log 可以只看最后 200 行，不用从头刷。
grep “ERROR” app.log：搜含 ERROR 的行；grep -i “timeout” 忽略大小写；grep -A 5 -B 5 “NullPointer” 显示匹配行的前 5 行后 5 行。面试必考”-A -B 是什么”，答：”A=After，B=Before——看报错不能只看那一行，要看上下文才知道原因。”
less app.log：大文件翻页查看，按 / 搜索关键词，n 看下一个，q 退出。
查看文件末尾 50 行：tail -50 文件名；过滤含 ERROR 的行：grep “ERROR” 文件名。

查进程和端口

命令	干什么	类比
ps aux \| grep java	查 java 进程在不在	看蒸笼有没有在冒烟
top	实时看 CPU/内存占用	看哪个蒸笼最费煤气
kill -9 PID	强制杀进程	直接关掉某个灶
netstat -tlnp \| grep 8080	看 8080 端口有没有被监听	看哪个后门开着
lsof -i :8080	看哪个进程占了 8080 端口	看谁在守门
pgrep 进程名 / ps -ef \| grep 进程名	查进程 PID	找到是哪一笼

面试常问”怎么看服务器 CPU 飙高了”（答 top 看 %CPU 列，某进程 90%+ 就是异常）和”怎么确认服务是不是启动了”（答：先看进程 ps aux | grep 服务名，再看端口 netstat -tlnp | grep 端口号，进程在 + 端口在 = 服务活着）。

完整的线上排查场景（背下来）

场景：线上用户说”支付页面打不开”，你怎么用 Linux 排查？

先确认服务活着：ps aux | grep payment-service；netstat -tlnp | grep 8080。
服务不在 → 说明挂了，找运维/开发重启。
服务在 → 去日志目录看实时日志：cd /var/log/payment/；tail -f payment.log。
同时开另一个窗口看错误：grep “ERROR” payment.log | tail -20。
让用户重试支付，观察日志里有没有异常堆栈。
如果是数据库连不上，看 ERROR 日志里的连接超时信息；如果是 CPU 100%，top 看哪个进程吃资源。
把日志截图和关键报错发给开发定位。

其他高频考点

find 和 grep 的区别：find 按文件名/属性找文件（find . -name “*.log”、find . -type f -size +5M 找大于 5M 的文件、find / -name “*.conf”）；grep 在文件内容里搜文本。
文件权限 755：所有者有读/写/执行（7），组和其他有读/执行（5），含义是”所有者可读写执行，组和其他可读可执行”。rwxrw-r– 代表所有者读写执行、组读写、其他只读。
隐藏文件：Linux 里以点号开头的文件（如 .bashrc）就是隐藏文件。
打包解包：tar -czvf a.tar.gz 目录（打包压缩），tar -xzvf a.tar.gz（解压拆包）。
查看 IP：ifconfig / ip addr；查看磁盘：df -h；查看内存：free -h；查看主机名：hostname。
常用端口：Apache/Nginx 80、MySQL 3306、Tomcat 8080、Redis 6379、DNS 53（UDP）。
解压/查日志/查进程组合拳：ps -ef | grep tomcat 查 PID，然后 kill -9 PID 杀掉；用 tar 打包日志回本地分析。

Q：怎么在 Linux 上部署测试环境、备份数据库？

部署测试环境的步骤：安装依赖（Java、MySQL、Nginx、Docker）→ 上传应用包（.jar/.war/Docker 镜像）→ 配置环境变量和配置文件（如 application.yml）→ 启动应用（java -jar app.jar 或 docker run -d 镜像名）→ 配置 Nginx 反向代理指向应用端口 → 访问 http://server_ip:port 验证。查看应用日志：如果应用输出到控制台，用 nohup java -jar app.jar > app.log 2>&1 & 重定向后再 tail -f app.log；如果写入文件，直接 tail -f /path/to/logs/app.log，配合 grep 过滤、less 分页。

数据库备份恢复：Navicat 里右键数据库”转储 SQL 文件”备份、”运行 SQL 文件”恢复；命令行用 mysqldump -u 用户名 -p 库名 > backup.sql 备份，mysql -u 用户名 -p 库名 < backup.sql 恢复；也可以配合 crontab 做定时备份。

8. 安全测试

Q：常见的安全漏洞有哪些？

测试工程师至少要认识这几类漏洞及其验证方法。

漏洞	原理	基础验证方法	防范
SQL 注入	在表单/URL 里插入恶意 SQL，窃取或篡改数据	输入框输入 ‘ OR ‘1’=’1，看是否能绕过登录或返回异常数据	参数化查询、输入校验、最小权限
XSS（跨站脚本）	注入恶意脚本，控制用户浏览器（存储型、反射型、DOM 型）	输入 <script>alert(‘xss’)</script>，看是否弹窗	输入输出转义、CSP 策略
CSRF（跨站请求伪造）	盗用用户身份发起恶意请求	构造伪造请求，看是否在用户不知情下被执行	Token 验证、Referer 校验、SameSite Cookie
越权访问	垂直越权（低权限做高权限操作）、水平越权（访问他人数据）	改 URL 参数，如把 user_id=1 改成 user_id=2，看能否访问他人数据	服务端做权限校验，不信任前端
未授权访问	未登录也能调用需鉴权的接口	不传 Token 直接调接口，看是否返回 401	统一鉴权拦截
敏感数据泄露	明文传输或存储密码、身份证号等	检查 URL、Response 里是否暴露敏感信息	加密传输、脱敏存储
文件上传漏洞	上传可执行脚本拿到服务器权限	尝试上传 .php/.jsp 等脚本文件	类型白名单、重命名、上传目录不可执行、独立域名
目录遍历	越权读取系统文件	尝试访问 ../ 看能否读取系统文件	路径校验、白名单
DDoS	伪造大量请求占满资源，导致服务不可用	（通常由安全团队做）	限制 SYN 半连接数、缩短 SYN 超时、关闭不必要服务

漏洞的成因可以归纳为：设计缺陷、弱密码、软件复杂度高、人为失误、管理不规范。软件安全性测试可以从几个维度展开：用户认证、加密、入侵检测与漏洞扫描、数据备份恢复、防病毒。

Q：渗透测试和 Burp Suite 你了解吗？

渗透测试是模拟黑客攻击，主动发现漏洞——这是安全测试和功能测试最大的区别：功能测试验证”设计好的功能对不对”，渗透测试验证”没设计的东西会不会被利用”。Burp Suite 是常用的渗透工具，核心功能有：Proxy（拦截、修改、重放请求）、Scanner（自动扫描漏洞，需专业版）、Intruder（自动化攻击，如爆破、模糊测试）、Repeater（手动重放请求、改参数调试）、Sequencer（分析会话令牌随机性）、Decoder/Encoder（编解码）。入门流程是：配置浏览器代理指向 Burp → 开启 Intercept 捕获登录请求 → 用 Repeater 修改参数重放观察响应 → 用 Intruder 对登录接口做字典爆破 → 用 Scanner 扫描目标站点（需授权）→ 结合 SQLMap 做注入测试 → 学习 OWASP Top 10 的原理和利用方法。

安全测试对测试工程师的要求是”会做基础验证 + 知道边界在哪”。面试里被追问深度问题，坦诚说明”专业的渗透测试有安全团队负责，我做的是基础安全测试”是完全可以接受的回答。

9. 网络协议基础

Q：TCP 和 UDP 有什么区别？

	TCP	UDP
连接	面向连接、可靠、保序、点对点、首部 20 字节	无连接、不可靠、不保序、支持多播、首部 8 字节
效率	较低（要确认、重传）	较高
适用	文件传输、网页浏览、邮件	视频、游戏、直播等实时场景

三次握手（建立连接，确认双方的收发能力）：客户端发 SYN → 服务端回 SYN+ACK → 客户端发 ACK。四次挥手（断开连接）：一方发 FIN → 另一方回 ACK →（另一方处理完）再发 FIN → 一方回 ACK，双方关闭。

Q：OSI 七层模型和 TCP/IP 四层是什么？

OSI 七层：物理层（比特流）、数据链路层（帧，MAC 地址）、网络层（路由，IP）、传输层（端到端，TCP/UDP）、会话层（会话管理）、表示层（格式转换、加密）、应用层（用户接口，HTTP/FTP/DNS）。TCP/IP 四层是：数据链路层、网络层、传输层、应用层。记忆时可以记设备对应：HUB 在物理层，Switch 在数据链路层，Router 在网络层。MAC 地址属于二层（硬件分配，同链路通信），IP 地址属于三层（拓扑分配，跨网络通信）。

Q：其他网络高频知识点

DNS：域名到 IP 的映射，用 UDP 53 端口。
访问 www.baidu.com 的过程：DNS 解析（浏览器缓存 → 系统缓存 → hosts → 路由器 → 根域名服务器）→ TCP 三次握手 → 发 HTTP 请求 → 服务器返回 HTML → 浏览器渲染。
子网掩码：与 IP 按位与运算，区分网络地址和主机地址，结果相同即同一局域网。例：192.168.5.0/24 用掩码 255.255.255.248，可划 32 个子网，每子网 6 个可用 IP。
LAN / WAN：LAN 局域网（高带宽、小范围），WAN 广域网（跨地域），Internet 是最大的 WAN。
同步 vs 异步：同步要等返回再执行（下单扣库存）；异步不等返回直接执行（下单发通知）。
防火墙：通过包过滤、状态检测、代理等方式控制进出的网络流量，分为包过滤防火墙、应用代理防火墙、状态检测防火墙等。

10. 编程与 Python 基础

测试岗的编程题通常不难，重点考察”能不能写出干净、可用的代码”以及”数据结构与常见操作熟不熟”。写代码时顺手说明思路和边界处理，比闷头写完更得分。

Q：Python 的数据类型和可变性

可变类型：List、Dict、Set；不可变类型：Number、String、Tuple。列表是动态可变的、性能略低；元组不可变、轻量高效。列表和集合的区别：列表有序可重复、支持索引；集合无序不可重复、不支持索引，常用于去重和交并集运算。字典和 JSON 的区别：字典是 Python 对象，JSON 是跨语言的文本格式，二者可以互相转换但规范不同（JSON 的 key 必须是字符串）。range 与 xrange：Python 2 里 range 返回列表、xrange 返回生成器；Python 3 里只有 range，且返回惰性序列。

参数传递：值传递传的是拷贝，不改原值；地址传递传的是地址，可改原值。Python 里一切皆对象，传入可变对象（列表、字典）时函数内的修改会影响外部，传入不可变对象（字符串、元组）则不会。内存管理主要靠引用计数（引用为 0 回收），辅以标记清除和分代回收；小于 256 字节的小对象用私有内存池，大对象走系统 malloc。命名规范：_xx 表示内部使用、__xx 表示私有（名称修饰）、__xx__ 是魔术方法或系统属性。

Q：面向对象、继承、设计模式

编程范式上，结构化（面向过程）是自顶向下、适合流程清晰的场景，但难以适配变更；面向对象有封装、继承、多态，复用性高。继承的作用是复用父类的属性和方法，减少冗余、提升可维护性；重写（覆盖）父类方法可以实现子类特化。设计模式分三类：创建型（工厂、单例）、结构型（适配器、装饰器）、行为型（策略、观察者）。单例保证全局唯一，适合日志、配置、线程池；工厂封装创建逻辑，解耦调用与实现。开闭原则（对扩展开放、对修改关闭）是设计模式背后的核心思想。

Q：常见算法题怎么写？

字符串反转：return s[::-1]，或遍历从后往前拼接。
判断回文：原文与反转后相等即回文（注意忽略大小写和空格）。
列表去重并保持顺序：list(dict.fromkeys(lst)) 是最简洁的写法；或用一个 set 记录出现过的元素再遍历保留。用 set 去重会打乱顺序。
冒泡排序：相邻元素两两比较、大的往后换，每一轮把最大的冒到最后；如果某一轮没有交换，可以提前终止（说明已经有序）。
二分查找：针对有序序列，每次取中间值与目标比较，缩小区间，复杂度 O(logN)。
斐波那契第 N 项：递归（简单但有重复计算）或迭代（用两个变量滚动，效率高）。
找前 4 个最大的数：用堆（heapq.nlargest(4, lst)）或排序后取前 4 个，前者在大数据量下更优。
统计代码行数（去注释和空行）：逐行读，strip 后跳过空行和以 # 开头的行，累加计数。
删除字符串 a 中包含的 b：若 b 是字符集合，用 ”.join(c for c in a if c not in set(b))。
字符串转数字（不允许用 int）：遍历每个字符，ord(c) – ord(‘0’) 得到数值，累积 sum = sum * 10 + digit。
单词反序输出：“Hello world” → “world Hello”，用 s.split()[::-1] 再 join。
1~9999 中数字 3 出现的次数：按个位、十位、百位、千位分别统计每一位上 3 出现的次数再求和。
10000! 末尾有多少个零：数因子 5 的个数——n//5 + n//25 + n//125 + n//625 + …，与 5 相比因子 2 总是足够。
字典按 value 排序：sorted(d.items(), key=lambda x: x[1])，返回列表；要保留字典可用 dict(sorted(…))。
两个列表找相同和不同元素：相同用 set(a) & set(b)，不同用集合差集或对称差集。

Q：一道综合编程题

面试官常考：”写一个函数，输入用户名和密码，调用一个 mock 的登录接口（用假数据模拟，不真发请求），如果用户名是 admin 且密码是 123456，返回 {“code”: 0, “message”: “success”, “data”: {“token”: “abc123”}}；否则返回 {“code”: 401, “message”: “用户名或密码错误”}。”这道题同时考了条件判断、字典构造和函数设计。写的时候顺手加上参数校验（空值判断）和注释，面试官会更认可。

Q：Java 多线程相关（提到就要能答）

三个线程 T1、T2、T3 按顺序执行：用 join() 依次等待（T1.join() 后再 T2.start()），或用信号量/条件变量控制。
start() 和 run() 的区别：start() 启动新线程并由 JVM 调度 run()，run() 只是普通方法调用，不会开新线程。
线程安全的单例：用双重检查锁（volatile + synchronized）或静态内部类实现。
结构化 vs 面向对象：结构化强调步骤和数据分离，面向对象强调封装与复用；前者适合算法密集，后者适合复杂业务。
内存泄漏的原因与检查：对象被引用却不再使用导致无法回收；用内存分析工具（MAT、jvisualvm）或监控内存曲线排查。

11. Web 与 App 测试

Q：Web 测试和 App 测试有什么相同点和区别？

相同点：测试流程一致，都需要做功能、接口、性能、安全测试，用例设计方法和测试原理相通。区别集中在”移动端特有”的那些维度。

维度	Web 测试	App 测试
安装/卸载	不需要	必须测（安装包、升级、卸载残留）
网络	基本都是 WiFi/有线	弱网、断网、网络切换（4G→WiFi）
权限	不需要	必须测（相机/定位/通讯录权限弹窗）
手势	鼠标点击	滑动、长按、双击、捏合缩放
兼容性	不同浏览器（Chrome/Firefox/Safari/Edge）	不同机型 + 系统版本（华为/iPhone、Android 12/15）
回退	浏览器后退按钮	手机物理返回键/手势返回

浏览器兼容性怎么测？”主流浏览器各跑一遍主流程，用云测平台（如 BrowserStack）覆盖不同版本，重点看 CSS 布局错乱和 JS 报错。”兼容性测试和配置测试的区别：兼容性测”软件在不同软硬件环境下的适配”，配置测试测”硬件配置导致的差异”。常用浏览器有 Chrome、Firefox、Safari、Edge、IE（逐渐淘汰），Web 服务器有 Nginx、Tomcat、Apache，其中 Apache 偏向稳定和模块化、Nginx 偏向高并发和反向代理。

Q：登录功能要怎么测？

登录是最高频的场景题，按八个维度铺开：功能（正常/空参/特殊字符/边界/掩码/首尾空格剔除）、性能（加载耗时、响应时间）、安全（登录限次、防 SQL 注入与 XSS、密码加密、Cookie 加 HttpOnly、多端登录互斥）、兼容（多浏览器/多终端）、UI（布局、样式、响应式）、易用性（快捷键、复制粘贴）、接口（后端逻辑验证）、异常（高负载、弱网、断电）。如果是 App 登录，还要加第三方登录、手势/指纹/人脸登录、一键登录。

Q：浏览器缓存怎么理解？

缓存分 memory cache（内存缓存，临时）和 disk cache（硬盘缓存，根据 HTTP 头判断时效）。不可缓存的场景包括：响应头带 Cache-Control: no-cache 或 max-age=0、带 Pragma: no-cache、动态请求、POST 请求、没有缓存标识的响应。测试缓存时的关注点：修改内容后是否及时更新、退出登录后敏感页面是否还能通过后退看到。

Q：App 测试要额外关注什么？

四大组件与生命周期：Android 四大组件是 Activity（界面）、BroadcastReceiver（广播）、ContentProvider（跨应用共享）、Service（后台任务）。Activity 有 Active/Running、Paused、Stopped、Killed 等状态。点击 App 图标启动程序的过程，可以理解为创建进程 → 初始化 Application → 启动 MainActivity。
冷启动 vs 热启动：冷启动是后台无进程、新建进程并初始化 Application 和 MainActivity；热启动是后台已有进程，只需初始化 MainActivity。冷启动更慢。
稳定性：Crash（闪退，可能由内存泄漏、逻辑错误、兼容性、网络异常引起，能稳定复现就提单，偶现就查日志）；ANR/无响应（内存不足、死锁、空指针、资源缺失、缓存过多、代码异常）。
兼容性：覆盖厂商、系统版本、网络制式、分辨率。Android 用虚拟机、实时渲染，应用可后台常驻；iOS 是沙盒机制、普通渲染优先级、仅系统服务可后台。
升级：多渠道下载、网络切换、中断（暂停/关机/低电量）、存储不足、权限变更、新旧覆盖/卸载重装、强制/非强制更新、旧数据迁移。
流量与电量：横向对比（硬件单独耗电 vs 总耗电的差值）、纵向对比（同机型运行 vs 不运行应用的差值），工具辅助测量。
交叉测试：来电/短信/音视频/低电量干扰；补充后退、通知栏、UI 适配、触屏、安装卸载、升级、弱网切换、横屏。

App 崩溃（闪退）怎么抓日志？Android 用 adb logcat（把日志保存到本地可用 adb logcat > log.txt）；此外可接入第三方 SDK、加固工具，或在代码里捕获异常写入日志。监测内存、CPU、流量可以用 Android Profiler、adb 命令或第三方工具。移动应用灰度发布的做法是：小范围放量（比如先 1% 用户）→ 观察崩溃率、性能、反馈 → 逐步扩大比例 → 全量，出问题可快速回滚。

Q：小程序、H5、Windows 程序测试有什么区别？

小程序 vs H5：小程序在微信内运行，开发成本低、能调用较多系统权限、原生渲染更流畅；H5 在浏览器运行，需要多端兼容、权限受限、性能依赖优化。
Windows 程序：关注安装/卸载/重复安装、杀毒软件拦截、分辨率与缩放适配、多系统兼容、磁盘不足、端口占用。
经典场景用例：朋友圈发小视频（拍摄/本地选择、时长限制、上传中断、弱网、可见范围、压缩清晰度、多端同步）；扫码支付（扫码成功/失败、金额计算、并发扣款、幂等、退款、优惠券叠加、超时、异常网络）；朋友圈点赞（点赞/取消逻辑、可见范围、状态同步、排序、多端一致、消息通知、隐私）。

12. 测试管理与协作

Q：测试团队怎么分工？怎么把控进度？

分工方式有三种：按流程（每个人负责一段，交叉覆盖）、按模块（每人负责固定模块）、按类型（按单元/接口/功能拆分）。大团队常把”按类型 + 按模块”结合。团队架构分项目型（归项目组，沟通高效）、职能型（归测试部，资源复用高）、综合型（功能/自动化驻项目、性能/安全按需委派，是主流）。

进度把控：拿到需求后评估工作量、排出用例和执行的里程碑；每日站会同步进展、计划和问题；紧急需求可以按”需求 + 用例 3 天 → 功能 + 回归 5 天（含 1 天缓冲）→ 报告 1 天”的节奏排，同时同步风险，必要时组织 BUGBash（集中找 Bug 活动）。

Q：怎么给团队打 KPI？怎么建设团队？

测试团队考核的常见维度：缺陷发现数量与质量（是否发现有效缺陷、是否漏测）、用例覆盖与执行率、上线质量（线上缺陷数）、自动化提效、以及协作与流程贡献。要避免”只按 Bug 数量考核”——那会诱导为了数量而刷低质量 Bug。团队建设包括：招聘适配的人、定期培训、团队活动、台账机制（站立会/日报/周报）、激励优秀成员、通过分享会做知识传递（可在版本间隙开展）。

Q：常用工具有哪些？

类别	常用工具	关键点
缺陷管理	JIRA、禅道、Bugzilla、Mantis、TestDirector	流程是新建 → 分配 → 修复 → 回归 → 关闭，非缺陷驳回、无法修复标为暂不处理
用例管理	TestLink、禅道、QC、Wiki	支持用例库、版本管理、执行跟踪、报表
版本控制	Git、SVN	SVN 集中式、权限严、操作简单；Git 分布式、本地操作灵活、适合敏捷
抓包	Fiddler、Charles、Wireshark	Fiddler 是应用层代理，可拦 HTTP(S)，用于定位前后端问题
接口	Postman、SoapUI、JMeter	Postman 易上手、支持协作和 CI；SoapUI 支持 REST/SOAP

面试若被问”禅道和 QC 的区别””Bugzilla 有什么问题”，可以从功能完整度、使用门槛、报表能力、二次开发难度几个角度答。要记住一个立场：工具只是辅助提效，核心仍是测试思路和问题定位能力，避免过度依赖工具。

Q：Git 你平时怎么用？

一句话版：”我从远程仓库拉代码 → 建个分支改代码 → 提交到本地 → 推到远程 → 提 Merge Request 让开发 review。”对应命令：git clone 拉项目 → git pull origin develop 拉最新 → git checkout -b test/order-auto 建分支（名字要有意义）→ 改代码 → git add → git commit -m “说明” → git push origin 分支 → 在 GitLab 上提 Merge Request。

问题	标准答案
Git 和 SVN 的区别	Git 是分布式（每人本地有完整仓库，断网也能 commit），SVN 是集中式（必须连服务器）
git pull 和 git fetch 区别	pull = fetch + merge，直接拉下来并合并；fetch 只拉不合并，让你先看看再决定
什么是分支，为什么用	分支是独立开发线，用它是为了不污染主分支，改完提 MR 让开发 review 后再合入
冲突怎么解决	pull 下来发现冲突 → 打开冲突文件 → 手动删除 <<<< 标记 → 保留正确代码 → 重新 add + commit + push
怎么回退版本	git log 看 commit ID → git reset –hard 版本号（生产环境慎用 hard，会丢代码）

Q：怎么理解测试在公司里的角色？

测试兼具 QC（质量控制，逐点验证特性）和 QA（质量保证，监督全流程风险），是”质量守门员 + 流程推动者”。核心竞争力不是”会点多少工具”，而是能设计出别人想不到的用例、能快速定位问题根因、能用数据说服团队该不该上线。一个优秀的测试工程师需要：扎实的测试理论与用例设计能力、至少一门编程语言、接口与自动化能力、数据库与 Linux 基本功、以及良好的沟通与推动力。

几个观念性问题要能说清。零缺陷为什么不可能？因为完全测试资源不足、输入输出组合太多、实现路径多样、需求没有绝对标准、概率性缺陷难复现。八二原则体现在：80% 缺陷集中在 20% 模块；80% 缺陷靠手工发现，20% 靠自动化发现；还有约 5% 的缺陷要上线后长期使用才会暴露。测试的”优先级意识”就建立在这些现实之上——资源永远有限，必须把力气花在风险最高的地方。

Q：不同类型的公司面试重点有什么不同？

公司类型	考察重点
大厂（如腾讯系）	多轮：基础/代码 → Leader 专业/项目 → 总监潜力/素养 → HR 软素质。首轮重测试基础（用例覆盖率）、专项（性能/安全工具）、延伸（Linux/DB/编程/环境搭建），可能现场写算法
电商类大厂（如京东系）	五个维度：Linux 操作、SQL 复杂查询、编程（快排/深浅拷贝/GC，不熟考思想）、测试（流程/V 模型/用例设计）、逻辑（如 10 只鼠测 1000 瓶毒酒）
外派/外包	项目熟悉度、问题解决/Bug 挖掘/争议处理能力、技能（Linux/SQL）、个人规划与离职原因，留提问环节
创业公司	基本素养（沟通/主动/学习力）、技能与项目深挖（用例设计、测试改进、测试金字塔/左移/右移）、岗位匹配（敏捷经验、MySQL/Linux、自动化/性能实践、职业规划），30~40 分钟定适配
服务型公司	业务逻辑占约 40%；员工面（SQL、用例设计、Redis/Nginx）、组长面（脚本编写、环境搭建、接口/自动化/性能）、项目经理面（表达/协作/情商）。必备：测试理论、Java/Python/Go、JMeter/Locust、MySQL/Redis/Mongo/ES、Linux/Shell、Git、Jenkins、学习能力
区块链类	优先级：逻辑 > 测试技术 > 沟通 > 垂直领域 > 稳定性（≥2 年）> 规划 > 优劣势；加分项：技术博客/著作、安全测试经验、开发经验

第二部分高频面试题清单（300 题）

下面这份清单把常见的 300 道面试题按主题归了类，保留了全部题目。它的用法不是从头背到尾，而是当成一份”体检表”：第一部分的考点详解帮你把原理讲透，这份清单帮你查漏。逐条过一遍，凡是你看到题目愣住超过三秒的，回到第一部分对应章节补。题目前标了主题，方便跳转。

一、自我介绍与软性热身题

请做一个自我介绍。
你有什么优点和缺点？
你为什么要做软件测试这一行？
你为什么离开上一家公司？
你对我们公司了解有多少？
为什么我们应该录取你？
你的测试职业发展是什么？3–5 年的职业规划？
你自认为做测试的优势在哪里？
你找工作时最重要的考虑因素是什么？
说说你的期望薪资。
你通常对于别人的批评会有什么反应？
如果明知这样做不对，你还会依主管的指示去做吗？
如果你接到一个客户抱怨的电话、确知无法解决他的问题，你会怎么处理？
你觉得什么样的人最难相处？
你的工作通常能在时限内完成吗？

二、测试理论基础

测试基础概念

什么是软件测试？软件测试的目的是什么？
软件测试的原则有哪些？
软件测试的流程是什么？
一套完整的测试应该由哪些阶段组成？
软件测试有哪些分类？
黑盒测试和白盒测试的区别是什么？你是怎么运用的？
黑盒测试和白盒测试常用的方法有哪些？请举例。
黑盒测试和白盒测试各自的优缺点？
软件产品质量特性是什么？
什么是软件的生命周期？常见的软件生命周期模型有哪些？
什么是软件质量保障？
软件测试与调试的关系是什么？
软件质量的八大特性是什么？
什么是 UML？什么是 CMM？
什么是验证、评价、预排、检查？
软件测试的对象是什么？
软件带来错误的原因有哪些？
做好软件测试的关键点有哪些？
什么是”杀虫剂怪事”？
完全测试程序是可能的吗？
软件测试的风险主要体现在哪里？
为什么尽量不要让时间有富裕的员工去做测试？
软件测试人员就是 QA 吗？QA 和 QC 的区别是什么？
你怎么理解回归测试？是否思考过如何减少回归测试工作量？
测试产品与测试项目的区别是什么？
测试工具在测试工作中是什么地位？

测试流程与模型

画出软件测试的 V 模型图。
请根据 V 模型分别概述测试人员在需求定义、设计、编码、系统集成阶段的工作任务及文档。
W 模型的描述？
常见测试模型有哪些？
软件测试的基本流程有哪些？
需求测试注意事项有哪些？
测试人员需要何时参加需求分析？
如果需求一直在变化怎么办？
测试活动中的风险有哪些？

测试用例设计

什么是测试用例？测试用例的基本要素有哪些？
设计测试用例的主要方法有哪些？
等价类划分、边界值分析、因果图/判定表、场景法、正交法分别举例说明。
正交表测试用例设计方法的特点是什么？
你认为做好测试用例设计工作的关键是什么？
好的测试用例有哪些特点？
描述测试用例设计的完整过程。
功能测试用例需要详细到什么程度才算合格？
怎么才能够全面测试到每一个点？
如何设计测试用例才能保证覆盖率？
黑盒测试主要是为了发现哪几类错误？

测试类型详解

单元测试的主要内容是什么？
单元测试的策略有哪些？
集成测试也叫组装测试，请简述集成测试的主要内容。
集成测试通常有哪些策略？
集成测试与系统测试的关系是什么？
集成测试的进入准则和退出准则？
系统测试包含哪些方面？
系统测试的进入和退出准则？
系统测试阶段低级缺陷较多怎么办？
什么是验收测试？Alpha 测试和 Beta 测试有什么区别？
软件验收测试具体包括哪些？
和用户共同测试（UAT 测试）的注意点有哪些？
比较以下测试类型的区别：功能测试、性能测试、压力测试、负载测试、容量测试、强度测试。

缺陷管理

简述一下缺陷（Bug）的生命周期。
一条软件缺陷记录包含了哪些内容？
如何提交高质量的软件缺陷（Bug）记录？
如何定义所提交 Bug 的严重等级和优先等级？
Bug 有哪些等级？
写出 Bug 报告流转的步骤，每步的责任人及主要工作。
缺陷处理流程是什么？
开发人员老是犯一些低级错误怎么解决？
发现的缺陷越多，说明软件缺陷越多吗？
所有的软件缺陷都能修复吗？都要修复吗？
开发人员说不是 Bug 时，你如何应付？
修复一个 Bug 而导致其他 Bug 出现，该如何处理？

测试计划与报告

测试计划工作的目的是什么？内容都包括什么？哪些是最重要的？
测试计划编写的六要素？
怎样做好测试计划、任务跟踪和漏测分析？
项目版本执行过程中，测试人员如何把控测试进度？
测试工作进行到一半发现时间不够，你如何处理？
为什么要有测试报告？日常测试报告通常需要说明哪些内容？
如何编写提交给用户的测试报告？
测试总结报告包括哪些项？
测试结束的标准是什么？
测试出口准则和完成标准分别是什么？

测试方法与策略

测试的策略有哪些？
什么是测试策略？测试策略包括哪些？
系统测试的策略有哪些？
在测试工作中你常使用的测试方法有哪些？分别在什么场景下使用？

测试文档与评审

软件系统的用户文档包括哪些？
文档测试主要包含什么内容？
简述用户文档的测试要点。
软件的评审一般由哪些人参加？目的是什么？
阶段评审与项目评审有什么区别？

测试管理

如果项目周期很短、测试人力不足，你是怎么协调的？
描述下你团队的测试分工。
对于团队成员，你是如何打 KPI 的？
如果你是测试组长，你如何对项目及组员进行管理？
如何减少测试人员跳槽带来的损失？

三、计算机网络与协议

描述 TCP/IP 协议的层次结构，以及每一层中的重要协议。
TCP 和 UDP 有哪些区别？
简述子网掩码的用途。
ISO 模型是什么？HUB、Switch、Router 分别是 ISO 的第几层设备？
DNS 是什么？它是如何工作的？
描述用浏览器访问 www.baidu.com 的过程。
什么是 SQL 注入？什么是跨站脚本（XSS）？什么是跨站请求伪造（CSRF）？
防火墙如何保证安全？主要有哪些？
常用的 HTTP 协议调试代理工具有什么？详细说明抓取 HTTPS 协议的设置过程。
如果模块请求由 http 改为 https，测试方案应如何制定修改？

四、Linux 基础

你常用的 Linux 命令有哪些？
如何查看 CPU 信息？
查看占用 CPU 使用率最高的进程。
查看进程的命令、杀死进程的命令是什么？
如何查看一个文件的末尾 50 行？
如何过滤文件内容中包含 “ERROR” 的行？
查看某端口号？
查看 IP 地址？
创建和删除一个多级目录？
如何查询出 tomcat 的进程并杀掉这个进程？
动态查看日志文件？用什么查看 log？
查看系统硬盘空间的命令？
把一个文件夹打包压缩成 .tar.gz 的命令，以及解压拆包的命令？
在 Linux 中 find 和 grep 的区别？
如何查找一个大小超过 5M 的文件？
在 Linux 系统中，一个文件的访问权限是 755，其含义是什么？
Linux 中一般怎么隐藏文件？

五、数据库（MySQL / SQL）

什么是关系型数据库？主键、外键、索引分别是什么？
表的连接查询方式有哪些？有什么区别？（左连接、右连接、内连接）
SQL 的 select 语句完整的执行顺序？
事务的特性（ACID）？
数据库索引是什么？怎么优化查询效率？
你用的 MySQL 是哪个引擎？各引擎之间有什么区别？
如何对查询命令进行优化？数据库优化怎么做？
SQL 注入是如何产生的？如何防止？
MySQL 中怎么实现分页？
SQL 语句怎么看效率？
存储过程和函数的区别？
什么是存储过程和触发器？
使用 SQL 生成 10 万条数据。
给你一张表，根据要求写 SQL。
提取数据库中倒数 10 条数据？
NoSQL 和关系数据库的区别？MySQL 与 MongoDB 本质差别？

六、Web 测试

描述 Web 测试和移动应用测试的相同点和区别？
基于 Web 信息管理系统测试时应考虑的因素有哪些？
C/S 模式和 B/S 模式的优点和缺点分别是什么？
给你一个网站怎么开展测试？
电商支付模块的测试如何展开？
如何开展兼容性测试？
配置测试和兼容性测试的区别是什么？
什么是兼容性测试？兼容性测试侧重哪些方面？
了解的常用浏览器有哪些？
Nginx、Tomcat、Apache 都是什么？Apache 和 Nginx 的区别？

七、App 测试

App 测试的内容主要包括哪些？如何开展？
简述 Android 四大组件及生命周期。
当点击 App 图标启动程序，说明将要发生哪些过程？
Android 的兼容性测试都考虑哪些内容？
iOS 应用和 Android 应用测试有什么侧重点？
针对 App 的安装功能，写出测试点？
常用的 ADB 命令有哪些？
在查看 logcat 命令日志时怎么把内容保存到本地文件？
App 崩溃（闪退）可能是什么原因导致的？如何抓取日志？
如何测试监测 App 的内存使用、CPU 消耗、流量使用情况？
请简述移动应用在升级安装时应该考虑的场景。
请讲述移动应用的灰度是怎么做的？
客户端下 3 个常用的性能指标的名称与具体含义？
如何测试一个应用的登录场景？
请描述下微信朋友圈发小视频的用例设计？
如果让你来测试扫码支付，你会考虑哪些场景？

八、接口测试

请问你们公司是如何做接口测试的？
接口测试质量评估标准是什么？
接口类型有哪些？
手机短信验证码接口怎么测试？
常用 HTTP 协议调试代理工具有什么？详细说明抓取 HTTPS 协议的设置过程。
什么是 RESTful API？如何测试它？
接口测试中如何验证数据的正确性？

九、性能测试

请问你们公司是如何做性能测试的？请讲述性能测试的相关指标。
压力测试和负载测试的区别是什么？
如何理解强度测试？
什么是系统瓶颈？
服务器中一般要监控哪些数据？如何监控？怎么从监控数据中发现问题？
假设系统 A 调用系统 B，我把系统 B 的接口都 mock 了进行性能测试，有什么好处和坏处？
有一天早上打车高峰，滴滴服务端挂了大概 30 分钟，工程师抢修后马上上线，之后又挂了，请问有哪些原因？
您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
您以往是否从事过性能测试工作？请尽可能详细描述完整过程。
LoadRunner 分哪三部分？进行测试的流程是什么？
用 JMeter 做什么测试？如果有一个登录接口需要服务端返回参数、再带着参数去请求才能完成登录，用 JMeter 怎么做？

十、自动化测试

通用

如何看待自动化和手工测试？怎样的比例才是健康的？
你们公司的自动化投入产出比怎样？效率怎样？
自动化测试用例的覆盖率多少？
完整运行一次自动化用例需要多久时间？
什么是分层自动化？
你的测试数据是怎么准备的？
测试脚本的维护成本是怎样的？
自动化测试并发主要有哪些点？自动化测试分为哪几类？
自动化登录成功如何校验？
谁来进行自动化测试用例的维护？
列举你熟悉的主流自动化测试工具。

Selenium / WebDriver 相关

请问你的定位策略是什么？
请问如何实现用例失败或异常时截图？
请问如何分布式执行 WebDriver 用例？
如何在脚本中执行 JavaScript 代码？

Appium 与移动自动化

Appium 的定位策略有哪些？请简述 Appium 的原理。
iOS 和 Android 的 UI 自动化的原理是什么？
当定位策略都失败的时候，你该怎么做？
请问 Monkey 测试的优缺点？如果使用 Monkey 发现了一个闪退，怎么重现它？
Selenium 和 Appium 是怎么联系的？有什么关系？
对于移动端混合型的元素，你们是怎么抓取的？

QTP 相关

使用 QTP 做功能测试，录制脚本时，要验证多个用户的登录情况/查询情况，如何操作？
QTP 中的 Action 有什么作用？有几种？

十一、安全测试

软件的安全性应从哪几个方面去测试？
什么是 SQL 注入？什么是跨站脚本（XSS）？什么是跨站请求伪造（CSRF）？
防火墙如何保证安全？主要有哪些？
如何测试网络协议？（一致性测试、互操作性测试、性能测试、健壮性测试）
怎么测试一个网络协议是否安全？

十二、编程与算法

Python 基础

斐波那契数列求 N？
字符串反序输出？
判断回文？
统计 Python 源代码文件中代码行数，去除注释、空行后输出。
Python 调用 cmd 并返回结果？
什么是可变、不可变类型？
字典和 JSON 的区别？
写一个列表生成式，产生一个公差为 11 的等差数列。
给定两个列表，怎么找出它们相同的元素和不同的元素？
写一段 Python 代码实现删除一个 list 里面的重复元素。
请按字典中的 value 值进行排序。
range 和 xrange 的区别？

算法题

请写出冒泡排序。
1~9999 数列中数字 3 出现的次数，用递推方法解出。
从一个数组中找出前 4 个最大的数，用最优解。
写一段程序，删除字符串 a 中包含的字符串 b。举例输入 a=”asdw”、b=”sd”，返回 “aw”。
写一个方法，把字符串转为数字，比如 str=”1234″，变成 int 1234。
阶乘（N！）题：10000！末尾有多少个零。
给你几个英文单词（举例 Hello world），设计简单脚本使其反着输出单词（输出 world hello）。

面向对象与多线程

什么是面向对象编程？
讲下 Java 多线程的使用。
有三个线程 T1、T2、T3，怎么确保它们按顺序执行？
Thread 类中的 start() 和 run() 方法有什么区别？
请写一个线程安全的单例模型。
结构化程序设计和面向对象程序设计各自的特点及优缺点。
什么是值传递，什么是地址传递，两者区别？
描述软件产生内存泄露的原因以及检查方式。

十三、测试管理工具

熟悉的软件项目管理工具有哪些？
结合你使用的缺陷管理工具，描述缺陷跟踪管理流程。
描述使用 Bugzilla 缺陷管理工具对软件缺陷跟踪管理的流程。
你觉得 Bugzilla 在使用过程中有什么问题？
TestDirector 有些什么功能？如何对软件测试过程进行管理？
禅道和 QC 的区别？
什么是版本控制？常用的版本控制系统有哪些？
说说你对软件配置管理的理解？

十四、系统与架构

说出 4 种以上常用的操作系统及其主要的应用范围。
Windows 操作系统中 PATH 环境变量的作用是什么？
内存有哪几种存储组织结构？请分别加以说明。
如何将自己的本地磁盘（D）做成 FTP 供远端主机使用？
对 RUP、CMM、CMMI、XP、PSP、TSP 的认识？
目前流行的操作系统有哪些？请举例说明安装操作系统的注意事项。
Ghost 的主要用途和常用方法？

十五、开放性问题与实战场景题

给你一支笔/一个水杯/一部电梯，请你设计测试用例。
手上有这支笔，请你根据这支笔设计测试用例。
一个有广告的纸杯子，请设计测试用例。
一个身份证号码输入框，怎么设计用例？
登录功能怎么设计测试用例？
页面中有一个输入日期的输入框和一个输入身份证号的输入框，如何进行用例设计？
如何测试一个应用的登录场景？
请描述下微信朋友圈发小视频的用例设计？
如果让你来测试扫码支付，你会考虑哪些场景？
给你一个应用，请简述你会从哪些方面去测试？
请描述下你上个公司的测试流程？
在您参与或负责的项目测试中，发生过哪些棘手的问题，最后是如何解决的？
测试过程中你都经常碰到哪些问题？页面报 404/500 怎么处理？
如何验证数据的正确性？怎么确保本次测试符合预期？
需求不懂怎么办？
你觉得软件测试的核心竞争力是什么？
一个测试工程师应该具备哪些素质和技能？
怎样才能成为一个优秀的测试工程师？
你觉得测试在一个公司中扮演什么角色？
测试中你有没有做过风险评估？
你觉得 Web 端和手机端测试有什么不同？
测试计划是哪个开发阶段写的？在编码之前就要把测试计划写好吗？
谈谈软件测试技术，以及如何提高。
谈谈软件测试职业发展，以及个人的打算。
谈谈软件测试在企业的地位，也可以结合软件生命周期来谈。
一般公司里实际的软件测试流程是什么样的？你们公司又是怎样的？
软件工程师要具有哪些素质？
你会哪些测试工具？怎么操作？
你觉得你来应聘有哪些优势？
随便找一件物品让你测试——考查实际测试操作能力。
有一个新的软件，假如你是测试工程师，该如何做？
请就如何在开发中进行软件质量控制说说你的看法。
在搜索引擎中输入汉字就可以解析到对应的域名，请问如何使用 LoadRunner 进行测试？

第三部分面试话术与模拟问答

技术过关只是入场券，能不能把会的东西在有限时间里说清楚，往往才是决定结果的那一环。这一部分把散落各处的答题框架、送命题应对、速记卡和模拟脚本集中到一处。

1. 几个可以套用的答题框架

框架一：六维度万能公式（应对”怎么测一个 XX 功能”）

被问到”怎么测试微信红包/电梯/购物车/某个功能”时，用这个框架分维度说，永远不冷场：外观界面、功能、性能、安全性、易用性、兼容性。举例——测登录功能：界面看按钮排版对不对；功能看输对密码能不能登进去；性能看响应时间是不是在 2 秒内；安全看退出后有没有残留账号信息；易用看操作流程顺不顺手；兼容看换个浏览器/手机能不能正常用。这个框架的好处是结构化、覆盖全，面试官能清楚看到你的测试思维。

框架二：结构化应答的三件套

回答任何技术问题时，用”结论先行 → 展开细节 → 落到项目“的结构：先用一句话给出核心观点，再补充细节（”我们项目里是这么做的……”），最后加一句总结。这样做的好处是不会陷入发散、也不会因为背得太熟而显得空洞。回答前可以稍作停顿组织语言，避免背书感，用自己的话表述。遇到不会的问题，坦诚说明，可以说”这个问题我目前接触不多，不过按我的理解应该是 XXX，后续我会重点学习这块”。

框架三：复盘类问题的四步法

“印象深刻的 Bug””组员漏测””犯错了”这类问题，统一用”场景 → 原因 → 解决 → 复盘“来答。以支付金额算错为例：场景是测支付功能时发现用优惠券后金额少扣了 5 元；原因是开发把”满减”和”折扣”的计算顺序写反了（应先满减再折扣）；解决是提 Bug 并附上订单参数和数据库数据，修复后补充满减临界值、多券叠加的回归用例；复盘是给优惠券模块补了自动化校验脚本。四步齐了，故事就完整了。

2. 面试流程与现场技巧

面试前准备

企业调研：通过官网/天眼查了解业务和资质，通过脉脉/知乎查员工评价，提前试用产品、梳理业务逻辑与竞品差异。面试时能说出”我体验过你们的产品，发现某某流程有个小细节”，比任何自我介绍都加分。
简历优化：用 PDF 格式投递，1–3 页、无封面；工作/项目经历倒序排列；技能用”精通/熟悉/了解”分层描述，与 JD 关键词匹配；盲区知识提前突击；可以附 GitHub 或技术博客（内容要有干货）。
物料准备：多份纸质简历、存有作品和证书扫描件的 U 盘、纸笔、水；提前 10–15 分钟到场，整理仪容。
着装：国企/银行穿正装，互联网公司穿干净的休闲装，避免奇装异服。

面试现场

礼仪心态：眼神直视，语速放缓，保持微笑；不卑不亢，把面试当成双向交流。
自我介绍（3 分钟内）：开场致谢 → 基本信息（姓名/年限/最近任职）→ 核心业绩（项目成果，带数字）→ 技能匹配度 → 表达意愿与感谢。提前演练，控制时长。
通用技巧：回答前稍作停顿组织语言；核心观点后补充细节（”我们项目里是这么做的”），结尾加总结（”以上就是我的做法”）；避免背书感。
被问到项目：准备 1–2 个能讲透的项目，按 STAR 结构说清背景、任务、行动、结果，结果尽量量化（写了多少用例、发现多少 Bug、自动化节省多少时间）。

3. 高频软性问题与”送命题”话术

Q：你为什么转行/做测试？

避坑：别说”开发太难””测试门槛低”。可以说：”我觉得测试是产品质量的守门员，很有成就感；我细心、逻辑能力强，适合做测试；而且现在自动化测试、AI 测试发展空间很大，我想在这个方向深耕。”

Q：你的优点和缺点是什么？

优点要结合实例，比如”我在上个项目负责转账模块，写了 150 条用例，发现了 30 个 Bug，其中 2 个是资金相关的严重问题”。缺点要选非致命项，并说明改进措施，比如”我以前过度追求细节，导致进度偏慢，后来我学会了按优先级分配精力，先保核心流程再抠细节”。

Q：为什么离开上一家公司？

客观表述，比如业务调整、通勤太远、寻求技术挑战。不要抱怨前公司/领导/同事，不提”薪资低””加班多”这类容易被追问的理由。

Q：你能接受加班吗？

标准答法：”项目赶进度的时候我可以配合加班，保证按时完成任务。不过我也会提升自己的测试效率，比如用自动化脚本减少重复工作，尽量避免不必要的加班。”既表明了态度，也体现了效率意识。

Q：AI 会不会取代测试？

加分答法：”AI 能帮我们自动生成用例、写脚本，提高效率，但它很难处理复杂的业务逻辑、挖掘隐藏的深层 Bug，也没法和人沟通推动问题解决。未来我会和 AI 协同工作，让它做重复的事，我做更有价值的分析和决策。”

Q：你的职业规划是什么？

分短期和长期。短期（1–3 年）精通自动化/性能测试，能独立负责项目；长期向测试管理或专项专家发展。回答时把它和这家公司的岗位挂上钩——”我想在这个方向深耕，而贵司的自动化建设正好是我能发挥的地方”。

Q：期望薪资是多少？

提前调研行业水平，给出具体数字，表述为”结合市场水平和我的能力，期望税前 XX k，具体可以协商”。不要给一个模糊区间，也不要一上来就报底线。

Q：你还有什么想问我的？

反问环节是加分位，别浪费。不问薪资加班这类基础信息，问：”咱们团队的测试流程是怎样的？主要用哪些测试工具？这个岗位的晋升路径是什么样的？””测试左移在团队里是怎么落地的？””团队目前的自动化覆盖率大概多少？”这些问题能体现你的专业度和主动性。尽量准备 1–2 个，并且问题要针对这家公司。

4. 面试速记卡（口袋版）

打印出来或存手机里，面试前快速过一遍。

基础速记

关键词	一句话答案
测试用例要素	ID、标题、模块、优先级、前置条件、步骤、数据、预期结果
黑盒 vs 白盒	黑盒看输入输出（用户视角），白盒看代码逻辑（开发视角）
缺陷生命周期	新建 → 指派 → 修复 → 待验证 → 关闭（不合格就重开）
需求评审成员	产品、研发、测试、设计、项目管理（小项目加运维运营）
黑盒/白盒/灰盒	黑盒只看输入输出；白盒只看代码逻辑；灰盒两者结合
GET 和 POST	GET 参数在 URL、明文、有长度限制、用来查数据；POST 参数在请求体、相对安全、无长度限制、用来提交数据
HTTP 和 HTTPS	HTTP 明文、端口 80；HTTPS 加密、端口 443，更安全但稍慢
Cookie/Session/Token	Cookie 浏览器存的小文本；Session 服务器存的会话；Token 加密字符串，服务器不存，更常用
左连接和右连接	左连接：左表全留，右表没匹配填 NULL；右连接反过来
索引的优缺点	优点查得快；缺点占空间、增删改变慢
80/20 原则	80% 的 Bug 在 20% 的复杂模块里，老出 Bug 的模块以后还会出

用例设计速记

场景	核心测试点
登录功能	正例 + 反例（错密/空值）+ 安全（加密/锁定）+ 兼容 + 性能
购物车	增删改查 + 库存 + 优惠计算 + 数据同步 + 性能
等价类	有效（合法）+ 无效（非法/空/超界）

接口速记

概念	核心区别/做法
GET vs POST	GET 查数据（URL 传参，可缓存）；POST 改数据（Body 传参，更安全）
接口关联	前接口返回值 → 提取 → 存变量 → 后接口引用（Postman 用环境变量 {{token}}）
Mock 测试	模拟未开发完成的接口，让测试不被阻塞

自动化/性能速记

概念	一句话
PO 模型	页面元素封装成对象，脚本只调方法，改页面不改脚本
浅拷贝 vs 深拷贝	浅拷只拷表层（子对象共享），深拷全拷（完全独立）
失败重跑	pytest 装 pytest-rerunfailures，加 –reruns 3
CI/CD	代码提交自动构建测试（CI），通过后自动部署（CD），用 Jenkins 实现
JMeter 压测	线程组 → HTTP 请求 → 监听器（看响应时间/吞吐量/错误率）

Linux / SQL 速记

场景	命令 / 语句
Linux 高频命令	cd（切换目录）、ls（看文件）、grep（搜关键词）、tail -f（看实时日志）、ps -ef（看进程）、netstat -nltup（看端口）、systemctl start/stop（启停服务）
查数据	SELECT * FROM 表名 WHERE 条件;
插数据	INSERT INTO 表名 (列1,列2) VALUES (值1,值2);
改数据	UPDATE 表名 SET 列=值 WHERE 条件;
删数据（慎用）	DELETE FROM 表名 WHERE 条件;

实战话术速记

问题	万能话术框架
印象深刻的 Bug	场景 + 原因 + 解决 + 复盘（例：支付金额算错 → 计算顺序反了 → 补用例 + 回归）
组员漏测	私下沟通 → 复现确认 → 补用例 → 同步组长 → 优化评审流程
犯错了	第一时间止损 → 复盘原因 → 定改进措施 → 不隐瞒不推诿

5. 模拟面试问答脚本（实战版）

找个朋友互问，或者自己对着念，练开口的流畅度。下面是几个高频问题的一问一答，注意观察每个回答里的”结构感”和”项目落地”。

面试官：先聊聊一份合格的测试用例应该包含哪些内容？

你：核心包含八个要素：用例 ID、标题、所属模块、优先级、前置条件、测试步骤、测试数据、预期结果。实际工作中我们还会关联需求 ID 方便追溯，执行后补充实际结果和状态。您平时对用例的颗粒度要求会比较细吗，还是更关注核心流程？

面试官：黑盒和白盒测试的区别是什么？分别用在什么场景？

你：简单说，黑盒不考虑内部代码，只关注输入输出，站在用户角度，适合系统测试和验收测试；白盒需要深入代码，检查逻辑分支覆盖，适合单元测试和集成测试。我们项目里功能测试主要用黑盒，单元测试由开发负责，测试组会做接口层的校验。

面试官：设计一个登录功能的测试用例吧。

你：我会从这几个维度覆盖：一是功能正例，正确账号密码登录成功；二是异常校验，错误密码、账号不存在、空值；三是安全，密码加密显示、连续输错 5 次锁定账号；四是兼容性，不同浏览器/手机端适配；五是性能，多用户并发登录的响应速度。如果是 App 登录，还会加第三方登录、手势登录的场景。

面试官：接口测试中 GET 和 POST 有什么区别？

你：主要有四点：数据位置，GET 放在 URL 里，POST 放在请求体；安全性，GET 参数明文暴露，POST 更适合传敏感数据；数据长度，GET 受 URL 长度限制，POST 无限制；缓存，GET 默认被缓存，POST 不缓存。我们项目里查询类接口用 GET，提交数据（如新增订单）用 POST。

面试官：你们做自动化测试用的是什么框架？

你：接口自动化用的是 Python + pytest + requests，用 YAML 管理测试数据，conftest.py 做全局前置（比如登录获取 Token），Allure 生成报告，集成到 Jenkins 做 CI/CD，失败自动重跑 3 次。UI 自动化接触过 Selenium，用 PO 模型封装页面，提高复用性。

面试官：遇到过印象深刻的 Bug 吗？

你：有的。之前测支付功能时，发现用优惠券后金额少扣了 5 元。排查后发现开发把”满减”和”折扣”的计算顺序写反了——应该先满减再折扣，结果先算了折扣。我提 Bug 时附上了具体的订单参数和数据库数据，开发修复后，我补充了满减临界值、多券叠加的回归用例，避免类似问题。后来我们还给优惠券模块加了自动化校验脚本。

面试官：如果组员提前测完，但你觉得还有很多问题，怎么处理？

你：首先不会直接指责，会私下找他一起复现问题，确认是漏测了异常场景，还是对需求理解有偏差。如果是用例遗漏，就一起补充并更新到用例库；如果是需求问题，拉上产品对齐。之后我会同步给测试组长，避免影响上线，后续用例评审时也会重点把关这类场景。

6. 面试小技巧（临场提醒）

遇到不会的题：别直接说”不会”，可以说”这个我目前接触不多，不过按我的理解应该是 XXX，后续我会重点学习这块”。
结合项目说：每个答案尽量加一句”我们项目里 XXX”，显得有实战经验。
反问环节：准备 1–2 个问题，比如”咱们团队目前的自动化覆盖率大概是多少？””测试左移在团队里是怎么落地的？”
控制节奏：技术问题答题时分点说，让面试官跟得上；不会的点坦白承认，把会的讲透，比硬撑着乱答更得分。
主动提问式收尾：回答完技术问题，可以反问一句”这个场景你们团队是怎么处理的”，既显得自信，也能把话题引向你熟悉的方向。

结尾：面试之后，路还长

面试后复盘

面试结束不是终点。趁记忆还热，做三件事。

记录问题：把这一场被问到的所有题目、你答得不好的题、面试官特别关注的追问点记下来。同一类问题连续两场答不好，说明那是真短板，回去补。
优化应答：把当场没说清的点重新组织成结构化的答案，尤其那些卡壳的软性问题——它们往往有可复用的框架。
反思匹配：面试官反复追问的点，通常就是他真正在意的能力点。如果追问集中在接口和自动化，说明这个岗位更看重这两块，后续面试要重点准备。

Offer 的处理

一旦确定入职某一家，尽早、礼貌地拒绝其他 Offer，不要拖到入职日才告知。拖到最后一天才拒，会损害你的职场信用，而测试圈子并不大。拒绝时说明原因、表达感谢即可，不用过度解释。

试用期建议

入职后的头三个月，是别人对你形成印象的关键期。

尽快熟悉业务：主动熟悉业务流程、内部规范、团队分工，多看历史需求文档和 Bug 库，不懂就多向同事请教。业务理解速度，往往决定你多快能独立产出。
把交付做扎实：按要求完成任务，问题及时同步，注重交付质量。试用期最忌讳的不是慢，而是出了问题自己扛着不说。
定期复盘沉淀：每个版本结束后回顾自己的用例设计、缺陷发现和沟通表现，把经验写成可复用的东西（用例模板、常见缺陷清单、脚本片段），既能加速成长，也是给团队的价值。
主动补短板：如果入职时自动化或性能是弱项，就利用版本间隙学起来——把第一部分里的自动化框架思路，落到你们团队的真实项目里跑一遍。

把这份指南当成一张地图：先用开篇的备战地图确定方向，用第一部分把核心考点吃透，用第二部分查漏，用第三部分把话说漂亮，最后用结尾的复盘和试用期建议把面试的成果真正变成职场的起点。面试考的是”你能不能在压力下清晰地表达你知道的东西”，而一个测试工程师真正的底气，永远来自那些你亲手测过、亲手定位过、亲手推动解决过的问题。

遇到与具体公司流程不符之处，以你所在团队的实际实践为准——面试官更在意你的思考过程，而不是你能不能背出一套标准答案。