别再答不上测试基础！面试高频理论一次吃透

（个人见解，仅供参考）

🔥个人主页：寻星探路

🎬作者简介：Java研发方向学习者

📖个人专栏：JAVA（SE）----如此简单从青铜到王者，就差这讲数据结构！！数据库那些事！！JavaEE 初阶启程记：跟我走不踩坑测试开发漫谈

⭐️人生格言：没有人生来就会编程，但我生来倔强！！！

​

目录

1、黑盒测试和白盒测试的概念

2、冒烟测试的作用

3、什么是软件测试

4、软件测试的核心价值（作用）

5、如何制定一个完整的测试计划（软件测试的具体流程）

6、软件测试的生命周期

7、软件测试的测试类型

8、bug的生命周期

9、测试用例是什么？如何提高测试用例的覆盖率？

10、编写测试计划和测试用例的思路？如何确保覆盖核心需求、业务场景及潜在风险？

11、在设计测试用例时，你会优先采用哪些方法（如等价类、边界值等）？请结合一个实际场景说明。

12、测试执行过程中，你如何保证测试步骤的规范性和结果的可追溯性？一份有效的测试报告应包含哪些核心模块，如何让它为项目决策提供有效支撑？

13、请描述你分析并定位一个缺陷的完整过程，在与开发沟通缺陷解决方案时，你会如何确保双方对问题的理解一致？

14、假设开发认为你提交的某个缺陷是 “非必要优化”，你会如何论证其必要性并推动解决？

15、测试模型

16、敏捷测试

17、测试用例需要包含哪些东西

18、为什么要写测试用例

19、你觉得安卓端和ios端测试的时候有什么不同？或者关注侧重点的不同？

20、App 端与 PC 端测试的核心差异

1、黑盒测试和白盒测试的概念

• 黑盒测试：也可以叫做功能测试，不关心其内部代码结构、算法实现和逻辑流程，只关注软件的输入和输出是否符合需求规格说明书。

• 白盒测试：也可以叫做结构测试或逻辑驱动测试，测试人员知晓软件的内部基本结构、代码逻辑和实现细节，基于内部逻辑设计测试用例。

2、冒烟测试的作用

• 目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。

• 如果冒烟测试通过，那么测试人员开始进行正式的系统测试；如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。

3、什么是软件测试

软件测试是验证软件产品是否符合需求规格、是否能正常运行且无缺陷的过程，核心目标是发现软件中的错误（Bug）、评估产品质量，确保交付给用户的软件可靠、易用、性能达标。

简单来说，软件测试就是 “找茬 + 验证”—— 既要找出软件的问题，也要确认它满足设计要求（满足需求文档）。

4、软件测试的核心价值（作用）

1. 发现缺陷：提前排查功能异常、崩溃、逻辑错误等问题，避免用户使用时出现故障（如支付失败、数据丢失）。

2. 保障质量：验证软件是否符合需求文档、行业标准（如兼容性、安全性），提升用户体验。

3. 降低风险：提前识别潜在的问题，降低上线后产生故障的风险。

4. 提供决策依据：通过测试数据（如缺陷率、通过率），帮助团队判断软件是否具备上线资格。

5、如何制定一个完整的测试计划（软件测试的具体流程）

1. 需求分析: 深入理解产品需求文档，明确项目背景、核心功能和验收标准。

2. 测试计划：明确测试范围，测试类型、技术方法，资源规划、人员划分，进度安排，风险应对

3. 测试设计：编写测试用例，设计测试数据

4. 测试执行：搭建测试环境，执行测试，缺陷管理

5. 回归测试：修复缺陷回归验证

6. 测试总结：统计测试数据，分析问题根源，提出优化建议

7. 上线后验证：冒烟测试，监控反馈

先是去理解我们的需求文档，明确项目背景、核心功能以及验收标准；了解之后我们要制定测试计划（一般应该是测试组长的活）（如测试范围，测试类型、技术方法，资源规划、人员划分，进度安排，风险应对）；制定完计划之后就要去编写测试用例，设计我们的测试数据；有了测试用例之后我们就要去搭建相关的测试环境，去执行测试以及bug管理；在bug管理过程中要去对被修复的bug进行回归测试验证，知道bug被完全修复且没有引出新的bug；测试结束后我们要去进行测试的总结，统计测试的数据并提出优化建议；最后在软件上线之后要去进行冒烟测试以及监控反馈。

6、软件测试的生命周期

1. 需求分析：理解需求、明确范围、识别漏洞

2. 测试计划：定策略、分资源、明标准

3. 测试设计：设计用例、备数据、评审用例

4. 环境搭建：搭环境、部署软件、验可用

5. 测试执行：执行用例、提bug、回归验证

6. 缺陷管理：跟踪缺陷、推闭环

7. 测试总结：汇数据、评风险、给上线建议

8. 上线后维护：监控状态、收反馈、修紧急缺陷

最重要的两个点：需求分析 + 测试执行 & 缺陷闭环

1. 软件测试生命周期主要是 “需求分析→测试计划→测试设计→环境搭建→测试执行→缺陷管理→测试总结→上线后维护” 的闭环，在需求分析阶段我们要去理解需求文档，明确测试的范围；明确范围之后去制定测试计划，制定测试策略呀，人员分配呀，明确测试的标准等等；在这之后去进行测试用例的设计，去准备数据以及用例的评审；有了测试用例之后我们就可以去搭建环境，部署软件，为后面的测试的执行做准备；万事俱备，我们就要去执行测试用例，提出bug，给出建议；找到bug之后我们要去对bug进行追踪，主动推进问题的解决，进行回归验证；测试全部完成之后我们要去对本次测试进行测试的总结并产出测试报告（根据公司要求的格式去弄）；最后要在产品上线后去进行软件状态的监护，收集反馈，有bug及时修复。

7、软件测试的测试类型

冒烟测试：上线前（测试之前也要来一遍）快速验证核心流程，判断是否可继续深入测试

功能测试：测功能是否符合需求

性能测试：测系统的抗压能力，根据聚合报告、TPS可视化、响应时间可视化去进行进一步的分析

兼容性测试：测不同环境下的功能一致性，避免适配问题

安全性测试：测数据加密

接口测试：测接口正确性

易用性测试：测操作便捷性、界面友好度（如按钮位置、提示清晰、流程简洁）；

回归测试：功能迭代，验证旧功能是否受影响

8、bug的生命周期

bug生命周期是 “从发现到最终闭环” 的全流程管理，核心是规范bug处理流程、明确责任分工、确保缺陷被有效修复

1. 发现：发现缺陷，记录核心信息（现象，复现步骤，环境严重程度等等）

2. 提交：审核缺陷，纳入处理流程

3. 指派：将缺陷指派给对应的开发工程师

4. 修复：开发工程师复现缺陷，确定原因并进行修复，提交代码标记已修复

5. 复测：测试人员在修复环境中，复现步骤检查缺陷是否解决

6. 关闭：复测确认修复，无其它问题后关闭缺陷

先是由我们测试人员发现bug并记录奇其核心的信息（环境，步骤，预计结果，实际结果，bug评级等等）；记录好之后要去提交bug，将其纳入我们的处理流程；在这之后要去指派开发人员去修复bug；在bug修复之后测试人员要去测试这个bug有没有得到解决，是否引出了新的bug；确认无误后关闭bug。

9、测试用例是什么？如何提高测试用例的覆盖率？

测试用例是为验证软件某一功能或特性而设计的一组可执行的操作步骤和预期结果的集合，是软件测试执行的核心依据。 简单来说，测试用例就是 “在什么环境下，做出了怎样的操作，应该得到怎样的结果” 的标准化文档

就我自己而言更倾向于去以具体的页面或者功能为一个单位去进行测试，这样可以保证不落下任何一个页面或功能，在一定程度上可以保证测试的覆盖率较高。

10、编写测试计划和测试用例的思路？如何确保覆盖核心需求、业务场景及潜在风险？

测试计划思路：全局把控，明确 “测什么、怎么测、如何保障”

测试用例思路：分层（页面）设计，覆盖 “正常 + 边界 + 异常” 场景

确保覆盖核心需求、业务场景及潜在风险的 3 个关键动作：

1. 用例评审：借助团队力量查漏补缺

2. 用例与需求的双向追溯：避免需求遗漏

3. 迭代优化：动态补充遗漏场景

11、在设计测试用例时，你会优先采用哪些方法（如等价类、边界值等）？请结合一个实际场景说明。

我会优先用等价类(区分有效无效输入)+边界值(验证临界条件)+场景法(覆盖完整业务流程)

例：测试 “登录功能”，用等价类覆盖 “正确账号密码（有效）、空账号（无效）”，边界值验证 “密码长度 8 位（最小值）、16 位（最大值）”，场景法覆盖 “正常登录→退出→重新登录” 全流程，精准覆盖核心需求。

12、测试执行过程中，你如何保证测试步骤的规范性和结果的可追溯性？一份有效的测试报告应包含哪些核心模块，如何让它为项目决策提供有效支撑？

• 保证规范性：用标准化模板编写测试用例按用例逐步骤执行，明确环境、操作步骤、预期结果

• 可追溯性：记录测试日志，用例结果实时标注

• 有效测试报告包含的4大核心模块：项目概述，用例执行情况，缺陷分析，优化建议；

• 决策支撑：用量化数据反映质量；明确遗留问题的影响以及风险等级；结合需求文档给出建议，为项目决策提供依据。

13、请描述你分析并定位一个缺陷的完整过程，在与开发沟通缺陷解决方案时，你会如何确保双方对问题的理解一致？

• 缺陷定位：

  • 复现问题：明确测试环境，操作步骤以及预计结果和实际结果

  • 初步定位：抓包、查看日志以区分前端问题、后端问题还是环境问题

    • 抓包看请求是否发出（开发者工具有无请求记录）=>未发出=>前端

      • 请求发出后看状态码+返回数据=>4××/5××=>后端；

        200但页面异常=>前端；

    • 跨环境对比+查看环境日志=>环境差异=>环境问题

14、假设开发认为你提交的某个缺陷是 “非必要优化”，你会如何论证其必要性并推动解决？

• 先整理数据支撑（如bug影响用户的范围、违反了哪些需求条款、实际场景中用户会有怎样的体验）

• 再从用户视角：该问题可能导致操作受阻，影响使用

• 若开发仍有异议，找一下有没有折中的方案（比如迭代修复优先级），或者组织评审，明确是否需要修复bug

15、测试模型

1. V 模型：开发与测试呈线性 “V” 形一一对应，遵循 “先开发后测试”，开发阶段（需求分析→编码）分别匹配对应测试阶段（验收测试→单元测试），流程清晰但测试介入晚，前期缺陷易遗留、修复成本高。

2. W 模型：V 模型的升级版本，呈 “双 V” 结构，测试与开发全程并行、从项目初期就介入，每个开发阶段同步开展对应测试活动（如需求阶段同步设计验收测试用例），可提前发现缺陷，但对团队协作要求较高。

V 模型是 “开发完再测” 的线性匹配模型，W 模型是 “开发测试并行” 的前置型模型，后者能降低缺陷修复成本但协作门槛更高。

16、敏捷测试

敏捷开发模式下的测试方法论，核心是“迭代式测试、全程协作、持续反馈”，不等到开发完再执行测试，而是和开发同步推进，适配有“小步快跑、快速迭代”的特点的项目。

核心原则：测试提前介入、迭代式测试（测试，反馈，修复，再测试；不堆积问题）、自动化优先（重复工作用自动化脚本解决）、跨团队协作（不做孤立测试，要同步进度）

四个特点：轻文档，轻流程，重目标，重产出。

17、测试用例需要包含哪些东西

1. 用例ID（唯一标识，如“模块 - 功能 - 序号”）

2. 测试模块/功能点（明确测试对象）

3. 用例标题

（浓缩核心逻辑：‘场景+操作+预期结果’，如“输入正确的账号密码 -> 登陆成功”）

4. 前置条件

（执行用例前需满足的条件，如 “已打开浏览器、登录页可正常访问”）

5. 输入数据

（操作所需的具体数据，如账号：zhangsan；密码：123）

6.操作步骤

（分步执行的具体动作，如 “1. 在账号输入框输入 zhangsan；2. 在密码输入框输入 123；3. 点击‘登录’按钮”）

7. 预期结果

（精准的执行结果，如 “页面跳转至首页，顶部显示用户名‘zhangsan’”）

18、为什么要写测试用例

• 对个人：有助于梳理需求的细节，避免遗漏场景（如异常、边界）；明确测试目标，不盲目测试

• 对团队：统一测试标准，便于协作交接

• 对项目：可以量化测试进度，拿数据说话，降低沟通成本

19、你觉得安卓端和ios端测试的时候有什么不同？或者关注侧重点的不同？

1. 兼容性测试的侧重点不同。

安卓这边设备碎片化严重，不仅要覆盖不同品牌（比如华为、小米、OPPO）、不同系统版本，还要适配各种定制系统。

苹果只有苹果官方设备和系统，侧重主流机型（12-15），版本比较集中覆盖2-3个主流版本，系统性能统一。

2. 交互差异。

a.安卓：物理/虚拟返回键、分屏/悬浮窗、下拉通知栏

b. 苹果：无返回键（依赖左上角返回 / 右滑返回）、双击 Home 键 / 上滑切应用、暗黑模式 / 动态岛适配

3.权限与合规性测试的差异

安卓的权限管理比较灵活（用户可以随时开关），且不同厂商的权限弹窗逻辑不一样，所以要重点测试权限缺失时的功能降级容错性，比如没给存储权限，App 能不能正常使用核心功能。

苹果的权限申请规则严格（必须遵循苹果的隐私要求），重点要测权限调用时机的合规性，比如非必要场景调用定位权限会影响 App Store 审核，同时要关注隐私政策的完整性。

4. 性能和自动化测试的侧重点不同。

安卓中低端机型占比高，性能测试要重点看低配机的卡顿、内存泄漏和启动速度；自动化测试要注意厂商系统对控件属性的隐藏差异。

苹果硬件配置统一，性能问题少，重点测电池消耗和后台驻留稳定性；自动化测试的同时要关注系统版本迭代带来的 API 变更影响。

总结来说，安卓测试更侧重兼容性和鲁棒性，iOS 测试更侧重合规性和标准化的用户体验。

（鲁棒性（Robustness）指的是系统在异常、恶劣或非预期条件下，仍能保持稳定运行而不崩溃、不出现严重故障的能力，也可以理解为系统的 “抗干扰能力” 和 “容错能力”。）

20、App 端与 PC 端测试的核心差异

1. 设备与环境

   1. App：需适配多品牌机型、多样屏幕分辨率 / 尺寸及 iOS/Android 不同系统版本，设备硬件配置参差不齐；

   2. PC：设备规格相对统一，主要适配 Windows/macOS 系统版本，硬件差异小。

2. 交互方式

   1. App：需验证触屏（滑动 / 捏合）、陀螺仪 / 定位 / 摄像头等移动专属传感器交互；

   2. PC：聚焦键鼠 / 触控板精准操作，无移动传感器相关测试点。

3. 性能指标

   1. App：重点测启动速度、耗电量、流量消耗、发热及后台驻留稳定性；

   2. PC：侧重 CPU / 内存占用、多任务并发流畅度，基本不关注耗电流量。

4. 兼容性与网络

   1. 兼容性：App 需适配横竖屏切换，PC 只需适配不同分辨率 / 浏览器（桌面应用）；

   2. 网络：App 必测弱网、WiFi / 蜂窝网络切换，PC 网络环境稳定，仅需常规断网恢复测试。

5. 安装与权限

   1. App：需测应用商店安装、增量更新及相机 / 定位等权限申请；

   2. PC：关注安装包部署、注册表影响，权限管理逻辑更简单。