ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

软件测试20个基础面试题拆解:用测试思维答出层次感

软件测试20个基础面试题拆解:用测试思维答出层次感 上周帮一个准备入行的朋友做模拟面试二十个“基础题”问下来他前面十题还能接住后面越答越虚。尤其是被问到“你们项目里的自动化用例怎么选”“如果线上漏了一个bug你怎么办”这类题目的时候明显开始绕圈子。这其实就是很多新手投软件测试简历、刷软件测试面试题时最容易踩的坑基础题背得滚瓜烂熟一到追问和场景就露馅。我做了这么多年测试面试过的人没有一百也有大几十说句实在话面试官心里那杆秤从来不是“你背没背过标准答案”而是你有没有测试思维。今天这篇我就把这组软件测试20个基础面试题及答案重新拆一遍。不是给你一份标准八股文而是告诉你每个题目背后的考点、怎么答才算答到点子上、以及这些问题怎么延伸到物联网设备、自动化软件测试、Python、项目实战这些热门追问里。无论你是零基础刚完成软件测试基础培训还是已经投了一轮简历没回响这篇文章都值得你静下心看两遍。1. 基础面试题不是背书素材是筛人的第一道滤网1.1 为什么面试官放着项目不问先追着基础题打很多候选人觉得委屈我项目做得挺多你怎么净问些名词解释实际上基础题是最低成本的“逻辑扫描器”。举个例子你问“黑盒测试和白盒测试的区别”一个背过八股的人大概率能答出“黑盒不考虑内部结构白盒考虑内部逻辑”。但如果你追问一句“那你觉得接口自动化测试算黑盒还是白盒”很多人会卡住因为他的知识是点状的不是网状的。面试官真正想看的是你能不能把不同知识串起来。另外一个现实原因是测试行业的流动率摆在那里面试官一天可能要面五六个人用一套稳定的基础题库能在短时间内筛掉一大批只会背不会用的人。所以别嫌弃这些题“太入门”能把它答出层次感才是真本事。1.2 用“三步法”拆解每一道题而不是死记标准答案我建议你把基础面试题当成一个小型测试用例来准备。拿到一道题先问自己三个问题它考察的是什么知识点比如“等价类划分”考的是测试设计方法不是单纯术语。面试官为什么要问他想知道你能不能把方法落到项目里而不是只会列定义。我能不能举一个自己项目的实例哪怕是一个很小的例子也能立刻让你和背题库的人拉开差距。用这个思路去准备软件测试20个基础面试题你会发现真正需要背的很少需要理解的东西很多。这也是后面几个部分我要带着你做的事。2. 20个基础面试题及答案按主题拆解法不背也能答先放一张总览表把20个问题按能力域分组你在准备的时候可以对照着检查自己哪里是薄弱项。这张表不是拿来死记的是让你建立整体地图。能力域题号核心考点面试官潜台词测试基础1-5定义、原则、分类、静态动态你有没有入行基本概念流程与用例设计6-9STLC、测试用例、等价类边界值、计划策略你会不会干分析这摊活缺陷管理10-13缺陷生命周期、严重级别优先级、回归、冒烟你懂不懂跟开发怎么协作自动化与项目14-20手动自动化取舍、金字塔、Python、物联网、复盘你能不能把理论落进真实项目2.1 第一组测试定义、原则与分类第1-4题1. 什么是软件测试软件测试的目标是什么这是标准开胃菜但别答得太空。你可以这样回答软件测试是验证软件实际行为与预期行为是否一致的过程同时通过发现缺陷、验证功能、评估质量给系统上线提供决策依据。注意这里要说“质量评估”和“提供决策依据”这会让面试官觉得你有全局视角而不只是“点鼠标找bug的”。加分回答可以补一句测试的目标不是证明软件没有缺陷而是尽可能找出缺陷并推动修复同时评估当前质量是否达到发布标准。这个思路直接呼应了后面很多延伸题。2. 为什么软件测试不能穷尽所有用例这道题考的是对测试本质的理解。标准答法是输入数据的组合、执行路径的组合、运行环境的差异几乎无穷多不可能全部覆盖所以我们要用风险驱动的方法优先测试最核心、最容易出问题的场景。我建议你加一个生活化类比就像不可能把全世界每一条路都试一遍才敢开车一样我们测的是高频路线和事故高发路段。面试官听到这种类比会记住你因为很多人只会说“因为组合很多”说不出后面那句“所以要基于风险做取舍”。3. 软件测试的基本原则有哪些基础版是“测试显示缺陷存在、穷尽测试不可能、尽早测试、缺陷集群性、杀虫剂悖论、测试依赖上下文、无缺陷未必可用”这七条。但你要用每条一句话解释否则就是背名词。例如缺陷集群性可以解释为二八原则绝大多数问题集中在少数模块里所以当某个模块出现多个缺陷时一定要加深对这个模块的测试。而杀虫剂悖论指的是同一批用例反复跑缺陷检出率会越来越低需要不断更新测试用例。4. 黑盒测试、白盒测试和灰盒测试的区别核心区别是看测试时是否关注内部逻辑。黑盒只看输入输出是否符合需求白盒要理解代码路径、条件分支灰盒介于两者之间常用于接口测试和集成测试。这里我建议你主动提接口自动化接口测试关注的是请求参数、响应数据和数据库状态变化可以算灰盒测试。面试官听到你会主动关联就会认为你对测试分类是真的理解而不是背定义。2.2 第二组测试流程、计划与用例设计第5-8题5. 静态测试和动态测试有什么区别静态测试不运行程序包括代码走查、静态代码分析工具、文档评审动态测试需要运行程序并观察行为比如跑一条测试用例验证登录功能。一个经典追问是“代码评审发现空指针算测试吗”明明是静态测试很多人会答错。6. 软件测试生命周期STLC包含哪些阶段每个阶段的核心产物是什么STLC通常包含需求分析、测试计划、测试设计、测试执行、缺陷跟踪、测试报告六个阶段。每个阶段的产物分别是需求测试点、测试计划文档、测试用例、缺陷报告、测试总结报告。你要特别注意把“需求分析”放在第一位。很多刚入行的人以为测试是从写用例开始的实际上需求分析阶段就要做可测试性分析找出需求里的二义性和缺失点。这一点在软件测试项目实战中是重中之重。7. 测试计划的组成部分有哪些测试策略和测试计划的区别是什么测试计划包含测试范围、测试策略、资源安排、环境准备、进度计划、风险应对、退出标准。测试策略是计划中的核心部分它回答“怎么测”的问题测试分几个层次、用哪些工具、自动化程度多高、测试数据怎么准备。你可以把测试计划理解成一张作战地图而测试策略是地图上标注的主力方向。面试官会接着问“你们项目的测试策略怎么定的”这个时候只要说清楚“先在接口层做自动化覆盖主要业务链路再用UI自动化覆盖核心用户流程最后用少量端到端用例验证跨系统场景”基本就能过关。8. 等价类划分和边界值分析请结合一个具体场景说明。这是测试用例设计的黄金组合。以登录密码长度6到18位为例有效等价类是6到18位的字符串无效等价类包括小于6位和大于18位边界值则要测6位、5位、18位、19位再加一个空字符串。我强烈建议你准备一个自己项目里的例子比如下单金额、优惠券门槛、分页条数都可以。面试官极喜欢追问“边界值为什么最容易出错”答案是开发者在判断边界条件时最容易出现“大于等于还是大于”的逻辑错误。2.3 第三组缺陷管理、测试类型与回归策略第9-13题9. 缺陷的生命周期是什么什么情况下缺陷会被关闭缺陷生命周期可以走流程发现缺陷提交缺陷报告状态为New开发确认后为Open或Assigned修复完成为Fixed测试在最新版本上验证通过后关闭Closed。如果验证不通过则重新打开Reopen也可以因为产品决策被拒绝Rejected或延迟处理Deferred。这里要展示对协作的理解光背状态没有用。你可以说我会在提缺陷时把复现步骤、日志、预期结果、实际结果、截图一次写全减少开发和测试来回拉锯。这句话很容易让面试官点头。10. 严重级别和优先级有什么区别请举例。Severity是缺陷对功能的破坏程度Priority是修复的时间紧急程度。典型例子一个登录按钮文案写错了Severity低但Priority高因为它影响重要用户流程需要尽快改一个极端数据下出现的罕见崩溃Severity高但Priority可能低因为触发条件极少。这种题目对业务Sense的要求很高所以答完例子之后最好补一句实际工作中需要结合用户场景和版本计划来判断不能只看Severity。11. 冒烟测试和健全性测试的区别是什么冒烟测试是每次新版本出来后跑核心链路验证“能不能继续往下测”比如登录、首页、支付成功路径。健全性测试则是针对某次修复的验证检查这次改动是否真的修复了问题同时没有破坏相关功能。很多人会在这两个概念里翻车因为平时没用到健全性这个词。你只要记住一个核心区分冒烟测试面向整个版本的主流程健全性测试面向具体修复点。12. 什么时候执行回归测试如何保证回归测试不遗漏代码修改、环境配置变化、数据迁移、第三方依赖升级这些场景都要回归。保证不遗漏的关键是需求变更或代码修复时先做影响分析理清涉及的功能模块和上下游链路再从已有用例库里选择对应级别用例执行。面试官特别吃“影响分析”这四个字。你还可以细说自己会做一张业务链路图标出被修改模块的上下游节点然后围绕节点选用例。这个回答比“把用例全部跑一遍”靠谱得多也真实得多。13. 单元测试、集成测试、系统测试和验收测试的区别单元测试测函数或模块内部逻辑一般由开发完成集成测试测模块与模块之间的交互比如接口调用是否成功系统测试在整个系统层面验证功能、性能、兼容性验收测试由业务方或用户主导确认满足实际业务需求。回答这类题目的秘诀是举一个真实功能比如“订单提交”单元测试是测计算总价的函数返回值集成测试是测订单系统和库存系统的接口系统测试是测用户从下单到出库的完整流程验收测试是业务方确认整个流程符合业务规则。2.4 第四组手动测试与自动化软件测试的取舍第14-16题14. 手动测试会被自动化测试完全替代吗目前为止不会也不应该。请注意这个“也不应该”很重要。只要产品追求用户体验就需要探索性测试来发现那些自动化脚本写不出的奇怪问题只要业务逻辑高频变化脚本维护成本就会高到让人怀疑人生。自动化测试的价值是替代重复、可回归、数据确定性高的劳动而不是替代人的判断。你应该在结尾说手动测试和自动化软件测试是互补关系好的测试团队是把两者按比例搭起来。15. 如何选择自动化测试用例哪些用例不适合自动化适合自动化的用例有几个特点执行频率高、回归价值大、输入输出稳定、运行环境相对稳定、预期结果可精确断言。不适合自动化的包括一次性探索用例、视觉交互复杂且频繁变动的页面、依赖大量外部真实数据并且难以Mock的场景。这里可以主动暴露一个坑我以前曾经试图把某个多浏览器兼容的用例全部做成UI自动化结果光修脚本的时间超过了手动执行的时间后来果断砍掉一部分只保留覆盖率最高的三个浏览器主流程。16. 什么是测试金字塔你如何设计自动化用例的分层结构测试金字塔自下而上分为单元测试、接口测试、端到端测试越往上数量越少、成本越高、运行越慢。理想的自动化策略是底层大量单元测试中间层接口测试做主力顶层端到端测试只覆盖关键业务链路。你要接着说自己在实际项目中怎么应用用pytest写接口自动化覆盖大部分业务接口用少量UI自动化覆盖登录、注册、下单这种核心流程。如果面试官追问理由就说因为端到端用例每多一条稳定性风险和执行时间都成倍增加。2.5 第五组Python、物联网、项目复盘场景题第17-20题17. 用Python写自动化测试脚本时你的基本代码结构是什么这道题在软件测试面试python相关岗位时几乎是必考的。代码结构至少要包含导入依赖、准备测试数据、执行被测对象、断言结果。我可以很直接告诉你开场别写复杂框架先写一个精干函数式测试再升级到pytest的fixture机制。比如测一个极简登录接口逻辑你可以这样展示思路先request返回token再断言HTTP状态码、业务状态码和登录接口的关键字段。面试官听完会马上觉得你是真写过脚本的人不是只会在简历上写“熟悉pytest”。18. 给你一个涉及物联网设备的软件测试项目你怎么测这是近期非常热门的考点因为物联网设备越来越多传统软件测试方法要升级。你千万不要一上来就只说“测功能”要按“端-边-云-管”四个维度拆端设备端功能、按键交互、显示、异常断电、弱网下的表现边边缘网关的数据采集、本地规则引擎云云端设备管理、告警、设备影子、固件升级管设备与云端通信协议MQTT消息质量、断线重连然后补上兼容性、安全、性能维度不同型号设备兼容、数据加密传输、大量设备接入时的并发压力。如果你能现场给出一个“智能门锁断网后本地状态和云端状态最终一致”的测试设计思路这道题基本就稳了。19. 如果上线后发现线上漏测了一个bug你作为测试人员怎么处理这道题考的是职业素养和处理问题框架完全没有标准八股。你要讲的步骤是先评估影响范围和紧急程度推动产品决定快速修复或降级方案再补回归用例验证修复情况最后做根因分析为什么用例没覆盖到是需求理解偏差、测试数据问题还是分析遗漏。如果你在答案里强调“主动复盘补充测试用例到回归集而不是先甩锅开发或产品”面试官就会认为你是可托付上线质量的人。20. 你最近做的测试项目里最有成就感的用例是什么这道题表面是问项目实际是投简历之后的第一轮软性考核。你选择的故事要么能体现技术深度比如定位了一个隐蔽的性能瓶颈要么能体现业务理解比如发现了一个订单状态流转的极敏感缺陷。按“背景-动作-结果”三段式讲2分钟内讲完别拖。举个例子我之前测一个库存同步功能普通用例都通过了后来我变化场景模拟三台设备同时上报库存发现云端最终数据差了1件。原因是一个并发更新没有加版本号校验开发确认后修复了。这个故事短、有细节、能体现测试设计能力比“我执行了很多用例”强太多。3. 延伸题涉及物联网设备的软件测试怎么测别被新名词吓住3.1 物联网测试和传统Web测试的根本差异传统Web测试关注的是页面、接口、数据库状态而物联网测试要关注“物理世界和数字世界的映射”。一个传感器上报的温度如果网络断开了一段时间云端应该显示什么设备本地应该缓存多少条数据恢复之后怎么补传这些都是传统图层面板没有的测试点。我建议你用“设备是大脑云端是后台链路是神经”这个类比去理解。测试时不能只盯设备App和后台管理还要把“异常网络、异常数据、异常时序”这三类场景当作测试重点。3.2 设计一个“从设备到云端”的测试方案如果你在面试里碰到这个题目直接按下面这个框架走很实用功能测试设备入网配置、固件升级、数据上报、远程控制、告警推送兼容性测试不同品牌路由器、不同手机操作系统版本、不同硬件批次设备通讯协议测试MQTT订阅和发布是否符合预期QoS0/1/2是否有区别断线重连时能不能恢复订阅异常测试断网、弱网、高延迟、设备断电、云端宕机、时间跳变性能与容量测试大量设备同时上线平台是否能承受告警风暴是否会被抑制安全测试设备认证、通信加密、权限校验、固件包签名最后再加一句我在测试时会把云端日志和设备端日志时间戳对齐这样定位端到端问题会非常高效。这句话很专业面试官会记住。3.3 在面试现场怎么把物联网题答成项目题很多新手的问题是我知道框架但我没有物联网实际经验心里发虚。我的建议是用一个你真实接触过的智能设备做影子项目比如家里的智能插电板、智能灯、或者一部智能门锁。把它当成测试对象按照刚才的框架梳理一遍测试点写进你的软件测试简历里标注为“个人动手项目”。面试时被问到你怎么说把它当成一次真实测试项目来答说明你测了哪些场景、发现了什么问题、怎么和环境交互。只要讲得清楚、有细节没有企业经验也可以打动人。因为面试官更在意你的分析框架而不是你到底在哪个公司搬过砖。4. 面试中的Python和自动化测试题到底会怎么考4.1 简历写“熟悉Python”面试官大概率会追问这三个点很多人的简历写“掌握自动化软件测试”但被问到Python细节时就露怯。最常见的是这三个追问pytest的fixture是干什么用的怎么共享参数化怎么用一对数据和多组数据如何组织断言失败了怎么定位是代码问题还是数据问题我这几年面自动化软件测试岗发现80%的候选人栽在fixture上。他们知道conftest.py这个名词却说不清楚fixture的作用域、返回值和yield的作用。4.2 pytest脚本的骨架面试现场就能写出来不必写特别复杂的框架下面这个就是我最常推荐的面试版示例# test_user_api.py import pytest import requests pytest.fixture def user_token(): # 构造测试数据 payload {username: testuser, password: 123456} resp requests.post(https://api.example.com/login, jsonpayload) token resp.json().get(token) yield token # 测试用例执行前返回数据 # 用例结束后的清理比如登出 requests.post(https://api.example.com/logout, json{token: token}) def test_get_user_info(user_token): headers {Authorization: fBearer {user_token}} resp requests.get(https://api.example.com/user/info, headersheaders) assert resp.status_code 200 data resp.json() assert data[code] 0 assert data[data][username] testuser这个脚本看起来简单但包含三个核心逻辑测试数据准备、接口调用、断言校验。你在面试时把这个结构讲清楚比背一个大型框架更让人觉得你扎实。4.3 自动化用例的执行策略和前置条件还有一个高频追问是“你跑自动化测试前会做哪些准备”。你要回答先确认测试环境版本确保被测接口或页面可以正常访问再准备基础测试数据比如登录账号、订单数据、权限配置接着检查外部依赖比如Redis、数据库、Mock服务是否OK。个人的经验是给自动化用例设置一个“环境预检”步骤可以避免90%的假性失败。假性失败指的不是程序bug而是环境被人改过、数据被污染、网络不通导致的大片报错。你要让面试官知道你有处理“脏环境”的意识这才是真正干活的经验。5. 软件测试简历怎么写才能配得上你答出来的这些题5.1 测试项目模块怎么写才不像“编简历”我见过太多简历写“负责XX系统测试编写XX条测试用例”。这种话等于没说。好的写法是写清楚项目背景、你负责的模块、你用的测试方法、你发现的最有价值的问题。比如“负责智能门锁App兼容性测试覆盖Android和iOS 200设备组合设计了弱网和断网场景用例发现设备状态在弱网下不同步问题推动开发增加状态重推机制。”这就有画面感了。把你准备过的项目尤其是那个物联网影子项目写成这种风格大概率能多拿几个面试机会。5.2 面试时最不该犯的三个错第一个是抢答而不听问题。面试官问“测试计划包含什么”你上来就说“我做过接口自动化”跑题了。基本题就是考框架答框架就行项目细节等追问再讲。第二个是只给定义不给例子。定义是知识例子是能力。答完“等价类划分”一定要跟一个业务例子否则面试官没有任何证据相信你会用。第三个是贬低手动测试。有人为了显得“高级”会说“我现在主要做自动化手动测试很少做”。但你想想一个不会手动测试的人怎么判断什么该自动化手动测试是根自动化是叶这个逻辑要摆正。5.3 把基础题变成“可追问点”反而更容易通过最后说一个我面试别人时也会观察的点如果你在回答基础题时主动给出了具体场景比如“这个我在项目中遇到过”那么面试官大概率会顺着你的场景往下问。这其实是你自己在主导面试方向。所以别怕被追问反而要主动埋设“追问点”。比如回答完缺陷生命周期后加一句“我最近正好遇到一个因为复现不了被开发挂起的缺陷后来靠加日志在特定网络条件下复现了”面试官一听就会沿着这个方向深聊你就有机会把你准备过的项目经验讲出来。我个人带过的很多新人最后能通过面试的往往不是背题最熟的那个而是能把20个基础题答出自己的项目味道、把冷冰冰的名词解释变成活生生工作场景的那个。所以建议你不光要把这20个题过一遍还要给每个题配一个小例子哪怕只有一个面试的效果都会完全不同。后面如果时间宽裕还可以沿着物联网、自动化、Python这几个方向把自己准备的例子再打磨一轮。基础够牢延伸题自然就顺了。
返回列表