1、软件测试基本流程测试左移、测试右移理解软件测试基本流程需求分析阶段研读PRD、原型理解业务识别需求模糊点、矛盾点输出测试要点参与需求评审。测试计划确定测试范围、资源、排期、风险、测试策略、准入准出标准。测试设计设计测试用例、准备测试数据用例评审。测试执行版本接收冒烟测试通过后执行用例提交缺陷跟踪缺陷。缺陷回归开发修复bug后回归验证关闭或重开缺陷。测试总结达到准出标准输出测试报告版本上线上线后线上监控。测试左移核心把测试活动往研发前期移动尽早发现问题不等到开发写完代码才测在需求、设计、编码阶段就介入。活动需求评审、用例评审、单元测试、代码CR、静态代码扫描、接口文档评审。收益需求阶段发现缺陷成本最低减少后期大量bug降低返工。测试右移核心测试活动延伸到线上生产环境上线之后持续监控、采集线上数据发现线下环境难以复现的真实用户问题。活动线上监控、灰度发布、日志分析、用户反馈收集、线上压测、混沌工程。收益发现环境、真实流量、兼容性、性能类线下复现不了的问题。左移重在预防缺陷右移重在发现线上真实缺陷两者结合。2、黑盒、白盒、灰盒测试定义适用场景类型定义适用场景黑盒测试不关心内部代码实现只看输入输出验证功能是否符合需求把程序当作黑盒子功能测试、系统测试、UAT验收测试业务功能、页面交互不需要懂代码的测试人员执行白盒测试透明盒子看内部代码逻辑、分支、路径检查代码逻辑是否正确单元测试、模块内部逻辑测试开发自测测试开发做底层逻辑校验需要懂代码灰盒测试介于两者之间关注功能输出同时简单查看接口、数据库、日志等内部信息不完全深挖代码实现接口测试、服务端模块测试现在互联网项目最常用测试人员看接口返回、数据库数据不读完整源码3、常用黑盒用例设计方法用法举例示例业务用户登录手机号密码登录手机号11位密码6‑16位字符①等价类划分思路把输入划分为有效等价类合法输入、无效等价类非法输入每类选取代表性数据避免重复。有效等价类手机号11位密码6‑16位例手机号13800138000密码Abc12345→登录成功无效等价类手机号10位手机号12位密码5位密码17位空手机号空密码。②边界值分析法思路重点测等价类的边界临界点bug往往出现在边界上取刚好等于、刚好大于、刚好小于边界。业务边界手机号长度11密码6~16位手机号10位、11位、12位密码5位、6位、16位、17位等价类划分划分集合边界值抓集合边缘点两者经常搭配使用。③判定表法思路多个输入条件组合不同条件组合产生不同输出结果把条件全部排列适合多条件耦合场景。登录例子条件A(手机号是否正确)条件B(密码是否正确)条件结果手机号正确密码正确登录成功手机号正确密码错误提示密码错误手机号错误密码正确提示账号不存在手机号错误密码错误提示账号不存在适合权限、表单多条件校验。④因果图法思路分析输入条件因和输出结果果之间的逻辑关系与、或、非画出因果图再转判定表。和判定表很像适合条件之间存在约束关系条件数量不多的场景。登录因1手机号合法因2密码合法果登录成功。只有因1 AND 因2成立才登录成功。⑤正交实验法思路输入参数很多全部组合数量爆炸挑选代表性组合用正交表减少用例数量保证每个参数的各个取值都出现。举例登录页面浏览器Chrome、Edge、Firefox、操作系统Win、Mac、网络4G、WiFi。全部组合32212种正交可以精简为4组用例覆盖各维度取值。适用多参数组合场景兼容性测试。4、如何设计一条好的测试用例用例质量评价标准一条好的测试用例要素清晰用例标题、前置条件、测试步骤、测试输入、预期结果、优先级。标题简洁描述场景不是描述操作步骤粒度适中一步一个动作预期结果明确可校验不写“看效果”有明确前置条件独立一条用例测一个点不耦合多个场景。测试用例质量评价标准覆盖度覆盖全部需求点正常、异常、边界场景无遗漏。可执行性任何人拿到用例都可以复现步骤、预期清晰无歧义。独立性用例之间尽量不依赖一条失败不影响其他执行。简洁性不冗余不重复不把多个场景揉在一条用例。可追溯可以关联到对应的需求点。粒度合理不要太粗也不要过度细碎。5、测试用例优先级划分 P0/P1/P2 定义行业通用定义P0核心冒烟用例最高优先级主流程、核心业务路径阻塞版本发布。版本必须跑通P0否则直接打回开发。例用户登录、下单支付核心通路。P1重要功能用例主要业务功能大部分用户高频使用的场景。迭代必须全部执行。功能异常会严重影响用户使用。例登录密码错误提示、修改密码。P2次要、边缘场景低频、边界、异常、交互细节不阻塞主流程。迭代资源紧张时可适当裁剪回归周期拉长。例超长密码输入、特殊符号用户名、极少使用的UI细节。补充部分团队有P3极低优先级罕见场景一般不执行。6、缺陷生命周期开发认为bug不是问题如何处理缺陷常见状态新建 → 指派给开发 → 开发打开 → 修复 → 待回归 → 测试回归回归通过关闭回归失败重开。额外状态拒绝、暂缓、重复。开发认为bug不是问题的处理步骤先核对需求文档PRD确认需求是否明确复现bug确认复现步骤、环境、版本附上日志截图录屏。和开发对齐询问开发拒绝理由。情况1需求未定义该行为找产品确认产品判定是预期行为则关闭bug产品确认是缺陷打回开发。情况2开发理解偏差拉产品一起三方对齐。情况3属于设计问题但不改产品评估改为暂缓记录风险。无法达成一致升级产品经理做最终决策bug记录会议结论保留证据不私自关闭。不跟开发争吵以需求、复现证据、产品决策为准。7、测试计划内容测试报告关键信息测试计划项目背景、版本目标测试范围要测什么不测什么测试资源人员、环境、设备测试策略测试类型功能、接口、性能等左移右移策略排期各阶段时间节点测试准入标准、测试准出标准风险点与应对方案交付物用例、报告等测试报告版本信息版本号、测试周期测试范围用例执行统计总用例数、执行数、通过/失败/阻塞数量缺陷统计缺陷数量按优先级P0/P1/P2分布缺陷趋势遗留缺陷清单风险遗留风险、未测点测试结论是否可以上线后续建议8、敏捷开发测试如何开展Scrum中测试人员如何介入敏捷特点短迭代Sprint需求经常变化持续交付没有完整大段测试周期。敏捷测试开展方式测试左移Sprint前期参与需求故事评审细化用户故事提前识别风险开发开发用户故事的同时测试同步写用例开发完成Story后提测测试快速验证每轮迭代持续做冒烟、回归自动化脚本持续维护持续右移关注线上反馈。Scrum中测试人员介入Sprint规划会参与理解用户故事评估工作量识别测试风险每日站会同步测试进度、阻塞问题Sprint开发中需求评审、故事点评审提前设计用例开发完成story就测试不是等到迭代末尾集中测Sprint评审会演示验证功能Sprint回顾会复盘迭代质量问题优化流程。传统瀑布测试在编码之后敏捷测试贯穿整个Sprint全周期。9、冒烟、回归、验收、探索式测试定义区别冒烟测试版本提测后先跑核心主流程P0用例。目的验证版本是否可用主流程不OK直接打回开发不进入完整测试。准入环节。回归测试代码修改/修复bug之后重新执行原有用例确认修改没有引入新bug。分为全量回归、部分回归、自动化回归。验收测试UAT产品/业务方/用户验证业务功能是否满足业务需求偏向业务视角。探索式测试没有预先写好完整用例测试人员依靠经验、业务知识边思考边测自由发散挖掘隐性bug。用来补充脚本用例覆盖不到的场景。区别总结冒烟判断版本能不能测回归防止改代码带出旧功能bug验收业务确认是否满足业务诉求探索式自由探索挖掘遗漏场景。10、测试覆盖率代码覆盖率工具覆盖率低代表什么测试覆盖率分为需求覆盖率用例覆盖需求点、代码覆盖率代码层面。代码覆盖率常见指标行覆盖率多少行代码被执行分支覆盖率if‑else各个分支是否都走到条件覆盖率判断条件每一个真假都执行路径覆盖率代码不同执行路径。代码覆盖率工具JavaJaCoCoPythonpytest‑covGogo test cover前端Istanbul。覆盖率低说明什么覆盖率低≠一定有bug覆盖率高≠没有bug覆盖率低可能测试没有覆盖足够的代码分支、异常分支大量异常处理逻辑没被测试执行到存在死代码废弃代码没有删除单元测试写得少。⚠️误区不要盲目追求100%行覆盖率业务异常场景很难全部覆盖重点关注分支覆盖率。11、用户登录功能测试用例设计维度正常功能场景正确账号密码登录成功。输入校验手机号格式、密码长度、特殊字符、空输入。错误场景密码错误、账号不存在、账号锁定。状态场景未注册账号、已注销账号。权限/会话登录成功会话退出登录多端同时登录token过期。UI交互提示文案、输入框限制、按钮置灰。兼容性浏览器、不同客户端。接口层参数篡改、重复提交。安全维度密码明文传输暴力破解、SQL注入。异常环境弱网、断网登录中切后台。12、如何测试接口接口测试关注点接口测试流程阅读接口文档理清入参、出参、错误码设计用例正常参数、异常参数、边界、空值使用工具Postman/JMeter/MeterSphere发起请求校验响应码、响应体、数据库数据异常场景超时、重试。接口测试关注维度请求报文请求方法GET/POST请求头header入参必填、选填、参数类型、边界值响应响应码、返回字段、错误码数据是否和数据库一致异常场景参数缺失、非法参数、空参数权限未传token、非法token越权访问性能响应时间安全参数注入业务逻辑接口调用后业务数据状态变化。13、测试金字塔 vs 冰淇淋模型测试金字塔底层单元测试数量最多开发写成本低速度快中层集成测试/接口测试顶层UI自动化/手工端到端E2E测试数量最少成本高维护成本高。思想把大量测试下沉到底层单元、接口减少上层笨重UI自动化。冰淇淋模型反模式也叫雪糕甜筒模型底层单元测试很少大量测试集中在顶层UI E2E自动化。缺点执行慢、不稳定维护成本极高bug定位困难。对比金字塔是推荐模型冰淇淋是反模式需要尽量避免。14、如何评估测试工作量测试排期怎么制定评估测试工作量故事点/需求复杂度评估简单、中等、复杂需求拆解工作项需求评审、用例设计、用例评审、执行、回归、bug沟通历史项目类比参考过往同类需求工时考虑额外开销环境不稳定、需求变更、bug反复回归预留缓冲时间。不能只算执行时间评审、沟通、回归都要算进去。测试排期制定对齐开发提测时间点拆分阶段用例设计周期、测试执行周期、回归周期P0/P1优先保障P2优先级低可以压缩设置缓冲时间应对延期提测、需求变更明确版本准入准出开发延期提测要同步风险。15、项目中怎么做风险评估测试范围变更如何处理风险评估识别风险评估风险发生概率、影响程度给出应对措施。常见风险需求频繁变更开发延期提测测试时间压缩环境不稳定第三方接口依赖未就绪新模块无历史经验。应对风险登记同步给项目组高风险提前预警调整测试策略优先保障核心P0/P1增加自动化、灰度等手段。测试范围变更处理需求变更必须更新测试范围更新测试用例评估变更带来的工作量、风险评估对排期影响判断新增/修改的功能点补充对应用例评估受影响旧模块确定回归范围同步项目、产品若工作量增加申请调整排期或者裁剪次要P2记录变更点更新测试计划、测试报告。 
长河君 · 2026/11/4 6:48:41 · 阅读 1.2k 【面试题】测开基础面试题
1、软件测试基本流程测试左移、测试右移理解软件测试基本流程需求分析阶段研读PRD、原型理解业务识别需求模糊点、矛盾点输出测试要点参与需求评审。测试计划确定测试范围、资源、排期、风险、测试策略、准入准出标准。测试设计设计测试用例、准备测试数据用例评审。测试执行版本接收冒烟测试通过后执行用例提交缺陷跟踪缺陷。缺陷回归开发修复bug后回归验证关闭或重开缺陷。测试总结达到准出标准输出测试报告版本上线上线后线上监控。测试左移核心把测试活动往研发前期移动尽早发现问题不等到开发写完代码才测在需求、设计、编码阶段就介入。活动需求评审、用例评审、单元测试、代码CR、静态代码扫描、接口文档评审。收益需求阶段发现缺陷成本最低减少后期大量bug降低返工。测试右移核心测试活动延伸到线上生产环境上线之后持续监控、采集线上数据发现线下环境难以复现的真实用户问题。活动线上监控、灰度发布、日志分析、用户反馈收集、线上压测、混沌工程。收益发现环境、真实流量、兼容性、性能类线下复现不了的问题。左移重在预防缺陷右移重在发现线上真实缺陷两者结合。2、黑盒、白盒、灰盒测试定义适用场景类型定义适用场景黑盒测试不关心内部代码实现只看输入输出验证功能是否符合需求把程序当作黑盒子功能测试、系统测试、UAT验收测试业务功能、页面交互不需要懂代码的测试人员执行白盒测试透明盒子看内部代码逻辑、分支、路径检查代码逻辑是否正确单元测试、模块内部逻辑测试开发自测测试开发做底层逻辑校验需要懂代码灰盒测试介于两者之间关注功能输出同时简单查看接口、数据库、日志等内部信息不完全深挖代码实现接口测试、服务端模块测试现在互联网项目最常用测试人员看接口返回、数据库数据不读完整源码3、常用黑盒用例设计方法用法举例示例业务用户登录手机号密码登录手机号11位密码6‑16位字符①等价类划分思路把输入划分为有效等价类合法输入、无效等价类非法输入每类选取代表性数据避免重复。有效等价类手机号11位密码6‑16位例手机号13800138000密码Abc12345→登录成功无效等价类手机号10位手机号12位密码5位密码17位空手机号空密码。②边界值分析法思路重点测等价类的边界临界点bug往往出现在边界上取刚好等于、刚好大于、刚好小于边界。业务边界手机号长度11密码6~16位手机号10位、11位、12位密码5位、6位、16位、17位等价类划分划分集合边界值抓集合边缘点两者经常搭配使用。③判定表法思路多个输入条件组合不同条件组合产生不同输出结果把条件全部排列适合多条件耦合场景。登录例子条件A(手机号是否正确)条件B(密码是否正确)条件结果手机号正确密码正确登录成功手机号正确密码错误提示密码错误手机号错误密码正确提示账号不存在手机号错误密码错误提示账号不存在适合权限、表单多条件校验。④因果图法思路分析输入条件因和输出结果果之间的逻辑关系与、或、非画出因果图再转判定表。和判定表很像适合条件之间存在约束关系条件数量不多的场景。登录因1手机号合法因2密码合法果登录成功。只有因1 AND 因2成立才登录成功。⑤正交实验法思路输入参数很多全部组合数量爆炸挑选代表性组合用正交表减少用例数量保证每个参数的各个取值都出现。举例登录页面浏览器Chrome、Edge、Firefox、操作系统Win、Mac、网络4G、WiFi。全部组合32212种正交可以精简为4组用例覆盖各维度取值。适用多参数组合场景兼容性测试。4、如何设计一条好的测试用例用例质量评价标准一条好的测试用例要素清晰用例标题、前置条件、测试步骤、测试输入、预期结果、优先级。标题简洁描述场景不是描述操作步骤粒度适中一步一个动作预期结果明确可校验不写“看效果”有明确前置条件独立一条用例测一个点不耦合多个场景。测试用例质量评价标准覆盖度覆盖全部需求点正常、异常、边界场景无遗漏。可执行性任何人拿到用例都可以复现步骤、预期清晰无歧义。独立性用例之间尽量不依赖一条失败不影响其他执行。简洁性不冗余不重复不把多个场景揉在一条用例。可追溯可以关联到对应的需求点。粒度合理不要太粗也不要过度细碎。5、测试用例优先级划分 P0/P1/P2 定义行业通用定义P0核心冒烟用例最高优先级主流程、核心业务路径阻塞版本发布。版本必须跑通P0否则直接打回开发。例用户登录、下单支付核心通路。P1重要功能用例主要业务功能大部分用户高频使用的场景。迭代必须全部执行。功能异常会严重影响用户使用。例登录密码错误提示、修改密码。P2次要、边缘场景低频、边界、异常、交互细节不阻塞主流程。迭代资源紧张时可适当裁剪回归周期拉长。例超长密码输入、特殊符号用户名、极少使用的UI细节。补充部分团队有P3极低优先级罕见场景一般不执行。6、缺陷生命周期开发认为bug不是问题如何处理缺陷常见状态新建 → 指派给开发 → 开发打开 → 修复 → 待回归 → 测试回归回归通过关闭回归失败重开。额外状态拒绝、暂缓、重复。开发认为bug不是问题的处理步骤先核对需求文档PRD确认需求是否明确复现bug确认复现步骤、环境、版本附上日志截图录屏。和开发对齐询问开发拒绝理由。情况1需求未定义该行为找产品确认产品判定是预期行为则关闭bug产品确认是缺陷打回开发。情况2开发理解偏差拉产品一起三方对齐。情况3属于设计问题但不改产品评估改为暂缓记录风险。无法达成一致升级产品经理做最终决策bug记录会议结论保留证据不私自关闭。不跟开发争吵以需求、复现证据、产品决策为准。7、测试计划内容测试报告关键信息测试计划项目背景、版本目标测试范围要测什么不测什么测试资源人员、环境、设备测试策略测试类型功能、接口、性能等左移右移策略排期各阶段时间节点测试准入标准、测试准出标准风险点与应对方案交付物用例、报告等测试报告版本信息版本号、测试周期测试范围用例执行统计总用例数、执行数、通过/失败/阻塞数量缺陷统计缺陷数量按优先级P0/P1/P2分布缺陷趋势遗留缺陷清单风险遗留风险、未测点测试结论是否可以上线后续建议8、敏捷开发测试如何开展Scrum中测试人员如何介入敏捷特点短迭代Sprint需求经常变化持续交付没有完整大段测试周期。敏捷测试开展方式测试左移Sprint前期参与需求故事评审细化用户故事提前识别风险开发开发用户故事的同时测试同步写用例开发完成Story后提测测试快速验证每轮迭代持续做冒烟、回归自动化脚本持续维护持续右移关注线上反馈。Scrum中测试人员介入Sprint规划会参与理解用户故事评估工作量识别测试风险每日站会同步测试进度、阻塞问题Sprint开发中需求评审、故事点评审提前设计用例开发完成story就测试不是等到迭代末尾集中测Sprint评审会演示验证功能Sprint回顾会复盘迭代质量问题优化流程。传统瀑布测试在编码之后敏捷测试贯穿整个Sprint全周期。9、冒烟、回归、验收、探索式测试定义区别冒烟测试版本提测后先跑核心主流程P0用例。目的验证版本是否可用主流程不OK直接打回开发不进入完整测试。准入环节。回归测试代码修改/修复bug之后重新执行原有用例确认修改没有引入新bug。分为全量回归、部分回归、自动化回归。验收测试UAT产品/业务方/用户验证业务功能是否满足业务需求偏向业务视角。探索式测试没有预先写好完整用例测试人员依靠经验、业务知识边思考边测自由发散挖掘隐性bug。用来补充脚本用例覆盖不到的场景。区别总结冒烟判断版本能不能测回归防止改代码带出旧功能bug验收业务确认是否满足业务诉求探索式自由探索挖掘遗漏场景。10、测试覆盖率代码覆盖率工具覆盖率低代表什么测试覆盖率分为需求覆盖率用例覆盖需求点、代码覆盖率代码层面。代码覆盖率常见指标行覆盖率多少行代码被执行分支覆盖率if‑else各个分支是否都走到条件覆盖率判断条件每一个真假都执行路径覆盖率代码不同执行路径。代码覆盖率工具JavaJaCoCoPythonpytest‑covGogo test cover前端Istanbul。覆盖率低说明什么覆盖率低≠一定有bug覆盖率高≠没有bug覆盖率低可能测试没有覆盖足够的代码分支、异常分支大量异常处理逻辑没被测试执行到存在死代码废弃代码没有删除单元测试写得少。⚠️误区不要盲目追求100%行覆盖率业务异常场景很难全部覆盖重点关注分支覆盖率。11、用户登录功能测试用例设计维度正常功能场景正确账号密码登录成功。输入校验手机号格式、密码长度、特殊字符、空输入。错误场景密码错误、账号不存在、账号锁定。状态场景未注册账号、已注销账号。权限/会话登录成功会话退出登录多端同时登录token过期。UI交互提示文案、输入框限制、按钮置灰。兼容性浏览器、不同客户端。接口层参数篡改、重复提交。安全维度密码明文传输暴力破解、SQL注入。异常环境弱网、断网登录中切后台。12、如何测试接口接口测试关注点接口测试流程阅读接口文档理清入参、出参、错误码设计用例正常参数、异常参数、边界、空值使用工具Postman/JMeter/MeterSphere发起请求校验响应码、响应体、数据库数据异常场景超时、重试。接口测试关注维度请求报文请求方法GET/POST请求头header入参必填、选填、参数类型、边界值响应响应码、返回字段、错误码数据是否和数据库一致异常场景参数缺失、非法参数、空参数权限未传token、非法token越权访问性能响应时间安全参数注入业务逻辑接口调用后业务数据状态变化。13、测试金字塔 vs 冰淇淋模型测试金字塔底层单元测试数量最多开发写成本低速度快中层集成测试/接口测试顶层UI自动化/手工端到端E2E测试数量最少成本高维护成本高。思想把大量测试下沉到底层单元、接口减少上层笨重UI自动化。冰淇淋模型反模式也叫雪糕甜筒模型底层单元测试很少大量测试集中在顶层UI E2E自动化。缺点执行慢、不稳定维护成本极高bug定位困难。对比金字塔是推荐模型冰淇淋是反模式需要尽量避免。14、如何评估测试工作量测试排期怎么制定评估测试工作量故事点/需求复杂度评估简单、中等、复杂需求拆解工作项需求评审、用例设计、用例评审、执行、回归、bug沟通历史项目类比参考过往同类需求工时考虑额外开销环境不稳定、需求变更、bug反复回归预留缓冲时间。不能只算执行时间评审、沟通、回归都要算进去。测试排期制定对齐开发提测时间点拆分阶段用例设计周期、测试执行周期、回归周期P0/P1优先保障P2优先级低可以压缩设置缓冲时间应对延期提测、需求变更明确版本准入准出开发延期提测要同步风险。15、项目中怎么做风险评估测试范围变更如何处理风险评估识别风险评估风险发生概率、影响程度给出应对措施。常见风险需求频繁变更开发延期提测测试时间压缩环境不稳定第三方接口依赖未就绪新模块无历史经验。应对风险登记同步给项目组高风险提前预警调整测试策略优先保障核心P0/P1增加自动化、灰度等手段。测试范围变更处理需求变更必须更新测试范围更新测试用例评估变更带来的工作量、风险评估对排期影响判断新增/修改的功能点补充对应用例评估受影响旧模块确定回归范围同步项目、产品若工作量增加申请调整排期或者裁剪次要P2记录变更点更新测试计划、测试报告。