业务测试面试题

一.测试基础 1. 什么是软件测试？软件测试的主要目的是什么？ 参考答案： 软件测试是通过手动或自动的方式运行系统或系统组件，以验证它是否满足规定需求并识别与实际需求之间的差异的过程。 主要目的： 发现软件中的缺陷和错误 验证软件是否满足业务需求和规格说明 评估软件产品的质量特性 建立对软件质量的信心 预防缺陷，降低软件开发风险 2. 黑盒测试和白盒测试有什么区别？ 参考答案： | 特性 | 黑盒测试 | 白盒测试 | | | | | | 测试依据 | 需求规格说明书 | 内部代码结构 | | 测试者角色 | 模拟最终用户 | 开发者或专业测试人员 | | 测试范围 | 功能测试 | 代码覆盖、路径测试 | | 技术要求 | 不需要编程知识 | 需要编程知识 | | 测试层级 | 主要在系统测试层面 | 主要在单元测试层面 | | 优点 | 从用户角度测试 | 能发现内部逻辑错误 | | 缺点 | 无法测试内部逻辑 | 无法测试缺失的功能 | 3. 什么是测试用例？一个好的测试用例应包含哪些元素？ 参考答案： 测试用例是一组条件或变量，测试人员根据它来确定被测系统或应用程序的某个特性是否正常工作。 一个好的测试用例应包含： 测试用例ID（唯一标识符） 测试用例描述/名称 前置条件 测试步骤（详细操作） 测试数据 预期结果 实际结果（执行后填写） 测试状态（通过/失败/阻塞） 优先级（高/中/低） 所属模块/功能 创建者和创建日期 执行者和执行日期 4. 解释等价类划分和边界值分析的概念 参考答案： 等价类划分 是将输入数据划分为若干个等价类，从每个类中选取少量代表性数据作为测试用例。假设同一等价类中的元素会以相同方式处理。 边界值分析 是针对输入和输出范围的边界设计测试用例的方法。经验表明，边界附近的区域最容易出现错误。 示例： 测试一个接受1 100数字的输入框 等价类：有效类(1 100)，无效类(<1， 100) 边界值：0,1,2,99,100,101 5. 什么是回归测试？何时进行回归测试？ 参考答案： 回归测试是验证已修改的软件或环境变更没有对现有功能产生不利影响的测试。 进行回归测试的情况： 添加新功能后 缺陷修复后 代码重构后 性能优化后 环境变更后（如操作系统、数据库升级） 配置文件修改后 6. 解释敏捷测试和传统瀑布模型测试的区别 参考答案： | 特性 | 传统瀑布模型测试 | 敏捷测试 | | | | | | 测试时间 | 开发完成后开始 | 与开发同步进行 | | 测试角色 | 独立的测试团队 | 开发与测试紧密合作 | | 文档依赖 | 高度依赖详细文档 | 轻量文档，强调沟通 | | 反馈周期 | 长周期反馈 | 短周期快速反馈 | | 测试重点 | 强调过程与文档 | 强调实际可工作软件 | | 变更响应 | 变更成本高 | 欢迎变更，响应快速 | 7. 什么是冒烟测试和健全测试？ 参考答案： 冒烟测试 是在正式测试开始前对软件基本功能进行的初步测试，目的是确认软件基本功能正常，可以开展后续详细测试。 健全测试 是在修复缺陷后进行的窄而深的测试，目的是确认特定缺陷已被修复，且修复没有引入新问题。 区别： 冒烟测试：广度测试，覆盖主要功能 健全测试：深度测试，针对特定区域 8. 什么是探索性测试？它有什么优点和缺点？ 参考答案： 探索性测试是一种同时设计测试和执行测试的方法，强调测试人员的自由度和创造力。 优点： 发现计划外缺陷 适合需求不明确或变化快的项目 充分利用测试人员的经验和直觉 快速了解系统功能 缺点： 难以衡量测试覆盖率 依赖测试人员的技能和经验 难以重复和回归 不适合合规性要求高的项目 9. 缺陷生命周期包括哪些状态？ 参考答案： 缺陷生命周期通常包括以下状态： 1. 新建 ：测试人员发现并报告新缺陷 2. 打开 ：缺陷被确认并分配给开发人员 3. 修复 ：开发人员修复缺陷 4. 重新测试 ：测试人员验证修复 5. 重新打开 ：如果修复不成功，重新打开缺陷 6. 关闭 ：缺陷已成功修复 7. 拒绝 ：开发人员认为不是缺陷 8. 延期 ：缺陷确认但推迟修复 9. 重复 ：缺陷已被报告过 10. 如何编写有效的缺陷报告？ 参考答案： 有效的缺陷报告应包含： 1. 清晰标题 ：简明扼要描述问题 2. 详细描述 ：准确描述问题现象 3. 重现步骤 ：详细、准确的重现步骤 4. 预期与实际结果 ：明确对比 5. 截图/录像 ：直观展示问题 6. 环境信息 ：操作系统、浏览器、设备等 7. 严重程度 ：问题对系统的影响程度 8. 优先级 ：修复问题的紧急程度 9. 附加信息 ：日志文件、网络抓包等 11. 什么是测试计划？测试计划应包含哪些内容？ 参考答案： 测试计划是描述测试范围、方法、资源和进度的文档，指导测试活动。 测试计划应包含： 测试目标和范围 测试策略和方法 测试环境和工具 测试进度和里程碑 资源分配和职责 风险和应对措施 可交付成果和验收标准 暂停和恢复标准 12. 如何确定测试的优先级？ 参考答案： 确定测试优先级考虑因素： 1. 风险 ：功能失败的业务影响 2. 使用频率 ：常用功能优先测试 3. 可见性 ：用户直接接触的功能 4. 复杂度 ：复杂功能更容易出错 5. 依赖性 ：被其他功能依赖的核心功能 6. 法律法规 ：合规性要求高的功能 7. 项目进度 ：根据发布时间表安排 常用方法：风险矩阵，结合可能性和影响评估优先级。 13. 请解释什么是测试用例的优先级，通常如何划分？ 答： 测试用例优先级是指根据功能的重要性、使用频率、失效后的影响程度等因素，对测试用例执行先后顺序的划分。通常分为： P0（高优先级）： 核心功能、烟雾测试用例，一旦失效会阻塞主要流程，必须优先执行。 P1（中优先级）： 重要功能、常用功能用例，失效会影响大部分用户使用。 P2（低优先级）： 边缘功能、使用频率低的功能用例，失效影响范围小。 14. 什么是冒烟测试（Smoke Test）？它的目的是什么？ 答： 冒烟测试是在软件编译构建完成后，对系统核心功能和主要流程进行的一种初步测试。 目的： 验证软件的基本功能是否正常，确保 build 是否足够稳定，能否进行后续更深入细致的测试。如果冒烟测试失败，则版本会被打回，无需进行下一步测试。 15. 什么是回归测试（Regression Test）？如何确定回归测试的范围？ 答： 回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 确定回归范围通常考虑： 本次开发修改的模块及其关联模块。 缺陷修复相关的功能点。 系统核心功能、主干流程。 历史上容易出问题的薄弱模块。 利用自动化测试脚本进行全量或部分回归。 16. 缺陷报告中应包含哪些关键信息？ 答： 一个清晰的缺陷报告应包含： 缺陷ID（唯一标识） 缺陷标题（摘要） 发现人、发现日期/版本 所属模块 严重程度（Severity） 优先级（Priority） 缺陷状态 详细描述（复现步骤、测试环境、测试数据） 预期结果 vs 实际结果 附件（如错误日志、截图、视频） 17. 缺陷的严重程度（Severity）和优先级（Priority）有什么区别？ 答： 严重程度（Severity）： 指缺陷对软件功能的影响程度，是技术层面的衡量标准。如：崩溃、阻塞、功能失效等。 优先级（Priority）： 指缺陷被修复的紧急程度，是商业和项目层面的衡量标准。 关系： 严重程度高的缺陷优先级通常也高，但并非绝对。一个低严重程度（如UI错别字）但高优先级（出现在公司Logo上）的Bug可能需要立即修复。 18. 当你发现一个Bug但开发人员无法复现时，你会怎么做？ 答： 1. 自我审查： 再次确认复现步骤，检查测试环境、测试数据是否准确、唯一。 2. 提供更多信息： 提供更详细的步骤、截图、视频、日志文件、网络抓包数据等。 3. 寻求帮助： 请其他测试同事在自己的环境下尝试复现。 4. 与开发当面沟通： 坐到开发人员旁边，现场演示复现过程。 5. 检查环境差异： 对比测试环境和开发环境（操作系统、浏览器版本、数据库数据、配置等）的差异。 6. 记录并跟踪： 即使无法复现，也应在Bug管理系统中记录，并注明“无法稳定复现”，后续版本持续关注。 19. 你如何评估你的测试是否足够充分（Test Coverage）? 答： 可以从以下几个维度评估： 需求覆盖率： 是否所有需求项都有对应的测试用例？ 代码覆盖率： 通过工具（如JaCoCo， Cobertura）统计语句、分支、条件等覆盖率。 风险覆盖率： 是否对项目识别的关键风险点进行了测试？ 用例执行率： 计划的测试用例是否100%被执行？ 缺陷发现率： 发现的缺陷趋势是否趋于平稳？ (注意：高覆盖率不代表高质量，但低覆盖率通常意味着测试不充分) 20. 测试的准入准则（Entry Criteria）和准出准则（Exit Criteria）是什么？ 答： 准入准则： 开始执行测试必须满足的条件。如：开发完成并提测、冒烟测试通过、测试环境准备就绪。 准出准则： 结束测试活动必须满足的条件。如：测试用例100%执行、致命/严重缺陷已修复并验证、未修复缺陷有明确处理意见、测试报告已输出。 21. 什么是持续集成（CI）？它在测试中有什么好处？ 答： 持续集成是一种开发实践，要求开发人员频繁地（每天多次）将代码集成到主干，并通过自动化构建和测试来验证。 对测试的好处： 快速反馈： 能够快速发现集成错误和回归缺陷。 提高效率： 自动化测试在CI中自动触发，节省手动 effort。 保证质量： 确保代码库始终处于可测试和可部署的状态。 \ \ 22. 你如何保证自动化测试的稳定性和可维护性？ 答： 使用可靠的定位策略： 优先使用ID等稳定属性，而非XPATH绝对路径。 引入等待机制： 使用显式等待而非固定休眠。 遵循POM设计模式： 将页面元素定位和业务操作分离，便于维护。 代码复用： 封装公共方法和组件。 数据驱动： 将测试数据与脚本分离。 版本控制： 对测试脚本进行版本管理。 定期评审和重构： 定期清理过时脚本，优化代码。 23. 除了功能，你认为还可以从哪些角度去测试一个产品？ 答： 功能、性能、安全、兼容性、易用性、可靠性、可移植性、可维护性、本地化/国际化等。 24. 当测试时间非常紧张时，你会如何应对？ 答： 1. 风险评估： 与项目经理、产品经理沟通，优先测试核心功能和高风险区域。 2. 调整策略： 优先进行冒烟测试和主要流程的正向测试。 3. 利用自动化： 执行已有的自动化回归测试套件，快速获得反馈。 4. 探索性测试： 在重点区域进行时间盒管理的探索性测试，高效发现重要缺陷。 5. 清晰沟通： 及时向团队汇报测试进度和风险，明确告知在有限时间内能覆盖的范围和可能遗留的风险。 25. 你平时如何提升自己的测试技能？ 答： 持续学习： 阅读测试博客、书籍（如《Google软件测试之道》），关注行业动态。 学习新技术： 学习新的测试工具、框架、编程语言（如Python， Java）。 实践： 在个人项目或工作中尝试应用新的测试方法和技术。 交流： 参加测试社区活动、技术分享会，与同行交流。 复盘总结： 对项目进行复盘，总结经验和教训。 26. 你为什么选择软件测试这个职业？ 答： (这是一个开放性问题，结合自身情况真诚回答) 示例： “我性格比较严谨细致，喜欢发现问题、分析问题的过程。软件测试能够让我扮演用户的角色，通过自己的努力保障产品质量，最终带给用户良好的体验，这让我非常有成就感和价值感。同时，这个领域需要不断学习新技术，充满了挑战，让我能持续成长。” 27. 你认为一个好的软件测试工程师最重要的素质是什么？ 答： 好奇心、批判性思维、细致耐心、强大的沟通能力、快速学习的能力和团队合作精神。 28. 你对我们公司有什么了解？为什么想来这里做测试？ 答： (面试前必须做的功课！) 需要提前研究公司的产品、业务、文化和技术栈。将自身的技能和兴趣与公司的需求结合起来回答，表达出真诚和热情。 示例： “我了解到贵公司的主打产品是XXX，在XX领域非常领先。我本人就是这个产品的用户，对其中的XX功能印象深刻。同时我注意到公司技术栈中使用了XXX，这正好与我擅长的XXX测试技术相匹配。我非常希望能加入一个这样优秀的团队，用自己的测试技能为产品的质量保驾护航，并和公司一起成长。” 29. 你有什么问题想问我的吗？ 答： ( Always have questions! 这体现了你的思考和兴趣) 可以问： 团队目前的测试流程和常用的技术工具栈是什么？ 这个岗位目前面临的最大挑战是什么？ 团队如何衡量测试工作的成功？ 公司为测试工程师提供了哪些学习和发展的机会？ 30. 什么是“端到端测试”（End to End Testing）？ 答： 端到端测试是模拟真实用户场景，从头到尾验证整个应用系统及其与外部接口（如数据库、网络、其他微服务）是否按预期工作。它关注整个流程的贯通性，而不仅仅是单个模块的功能。 31. 你如何管理你的测试用例？ 答： 使用专业的测试管理工具，如TestLink， Jira（集成Zephyr或Xray）， TestRail， QC/ALM等。这些工具支持用例的创建、组织、执行、跟踪和报告，方便团队协作和版本管理。 32. 请简述你对“大数据测试”的理解。 答： 大数据测试主要验证海量、多源、高速的数据处理流程的正确性、性能和可靠性。它不仅关注最终输出结果，更关注数据处理过程（如MapReduce作业、Spark Streaming流程）。测试包括：数据质量测试、性能测试、功能测试（验证业务逻辑转换是否正确）等。 33. 你对测试左移和测试右移是怎么理解的？ 答： 测试左移： 将测试活动提前到开发阶段甚至更早。如参与需求评审、设计评审、编写单元测试、进行代码评审、接口测试等，目的是尽早发现和预防缺陷。 测试右移： 将测试活动扩展到生产环境。如线上监控、A/B测试、灰度发布、众测等，目的是快速发现线上问题并获取真实用户反馈。 核心思想： 测试不再是SDLC的一个独立阶段，而是贯穿始终的质量保障活动。 34. 在敏捷开发中，你是如何适应快速迭代的测试节奏的？ 答： 自动化优先： 将回归测试自动化，才能快速验证，适应频繁的发布。 风险驱动： 根据风险优先级决定测试深度和广度，优先测试核心和高风险功能。 持续反馈： 与开发、产品保持密切沟通，及时反馈问题，每日站会同步进度和风险。 简化文档： 用测试点（Checklist）代替部分冗长的测试用例，提高效率。 二.web测试 1. Web测试与App测试、桌面应用测试的主要区别是什么？ 答： 主要区别在于技术架构、测试重点和环境。 技术架构： Web应用基于B/S架构，核心是浏览器和服务器；App是C/S架构，需要安装客户端；桌面应用直接运行于操作系统。 测试重点： Web： 浏览器兼容性（不同内核：Chrome/Blink, Firefox/Gecko, Safari/WebKit）、网络性能（加载、渲染、缓存）、服务器响应、会话管理（Cookie/Session）。 App： 设备兼容性（分辨率、厂商OS定制）、手势操作、中断测试（来电、消息）、安装/卸载/升级、流量消耗、弱网测试。 桌面应用： 与操作系统兼容性、资源占用（CPU、内存）、注册表、文件操作。 环境： Web测试环境相对统一（通过URL访问）；App需要大量真机或模拟器；桌面应用需考虑不同Windows/macOS版本。 2. 描述一下你在Web项目中的测试流程。 答： 遵循标准的软件测试生命周期（STLC），并融入敏捷迭代。 1. 需求分析： 参与需求评审会，理解业务逻辑，确定可测试性，识别潜在风险。 2. 测试计划： 制定测试策略（测试范围、方法、工具、环境、人力、进度）、确定准入/准出标准。 3. 测试设计： 设计测试用例（等价类、边界值、场景法等）、编写自动化脚本、准备测试数据。 4. 测试环境搭建： 配置服务器、数据库、部署测试版本、准备测试客户端（浏览器）。 5. 测试执行： 执行冒烟测试 执行详细测试用例（功能、UI、兼容性） 提交并跟踪缺陷 进行回归测试。 6. 测试报告与闭环： 输出测试报告，评估测试结果， meeting 准出标准后上线，并进行线上验证。 3. 什么是冒烟测试（Smoke Test）？针对一个Web首页，你会设计哪些冒烟测试用例？ 答： 冒烟测试是对软件主要功能进行初步验证，确保基本流程畅通，Build可测。 Web首页冒烟用例： 输入URL，页面能正常打开，不报404/500错误。 页面核心布局（Header， Footer， 主导航）加载完整。 页面核心内容（如Banner、主要商品列表、新闻头条）数据能正确展示。 首页Logo点击能正确跳转到首页。 主要CTA按钮（如“登录”、“注册”、“购买”）可点击。 搜索框可输入文本并执行搜索。 用户已登录状态下，用户名能正确显示。 4. 什么是回归测试？如何确定Web项目的回归测试范围？ 答： 回归测试是验证代码修改没有破坏现有功能。 确定范围： 核心功能： 所有核心业务流程（如电商的购物流程、支付的流程）。 修改模块关联区域： 本次开发修改的模块及其上下游关联模块。 缺陷相关区域： 本轮修复的Bug所涉及的功能点。 通用功能： 登录、注册、搜索、导航等全站通用功能。 高风险区域： 历史上Bug高发、逻辑复杂的模块。 自动化测试套件： 利用已有的自动化脚本进行快速回归。 5. 什么是探索性测试？它在Web测试中如何应用？ 答： 探索性测试是同时进行测试设计、测试执行、学习产品并给出反馈的测试方法。它强调测试者的自由、思维和实时学习。 在Web中的应用： 新功能探索： 不依赖用例，快速探索新上线的功能，发现明显的逻辑或UI问题。 用户场景模拟： 扮演不同类型的用户（如新手、专家、恶意用户），模拟他们的操作路径。 边界和异常探索： 在输入框尝试各种极端数据，尝试中断网络、回退、刷新等操作。 与脚本化测试互补： 在自动化脚本覆盖之外，发现那些难以预料的、隐蔽的缺陷。 6. 如何对一个用户登录功能进行测试？ 答： 这是一个经典问题，考察测试用例设计的全面性。 功能测试： 输入正确的用户名和密码，成功登录并跳转。 输入正确的用户名、错误的密码，提示错误信息。 输入错误的用户名、任何密码，提示错误信息（不明确提示是用户名还是密码错误，以防信息泄露）。 用户名/密码为空，提示错误。 密码是否以密文（星号/圆点）显示？ 是否支持键盘操作（回车键触发登录）？ 登录成功后，Session/Cookie是否正确设置？ 登录成功后，点击浏览器回退按钮，是否安全？（不应退回到登录页且显示已登录信息） 安全测试： SQL注入： 在用户名输入 % <script 中文 !$%.exe .jpg .php adb logcat adb logcat adb logcat s "TAG名:I" adb logcat :E adb logcat log.txt Exception Fatal Crash ANR onReceive() adb bugreport adb shell dumpsys package <package name | grep Uid adb shell cat /proc/uid stat/<UID /tcp rcv tcp snd adb shell am start W n package name/activity name TotalTime onCreate() onWindowFocusChanged() Proxy Throttle Settings Enable Throttling adb shell monkey p your.package.name 500 <script alert('XSS')</script pointer events: none; setData setData App() Page() wx.request app.json preloadRule wx.setStorageSync wx.setStorage onHide onShow wx.getRealtimeLogManager wx.onError project.config.json dev staging prod <view pointer events: none; /users/123 Host User Agent Content Type Authorization Cookie Content Type Content Length Set Cookie Server ? /users?page=1&size=10 /users/{userId} Cookie Authorization: Bearer <token Cookie: sessionid=xxx base url username X POST H d pm.expect tv4 body(matchesJsonSchemaInClasspath("schema.json")) form data File /graphql POST query mutation Authorization: Bearer <your token X API Key: <your key ` 3. 测试 鉴权失败 的场景：不带Token、带错误的Token、带过期的Token，验证是否返回401/403错误。 30. 如何设计用例来测试接口的幂等性？ 答： 针对幂等方法（如PUT, DELETE）： 用例： 使用完全相同的参数，连续发送 两次或多次 请求。 预期： 除第一次请求外，后续所有请求都应返回与第一次 相同的成功状态 （如200），并且对系统资源产生的 副作用应与第一次请求后的状态完全一致 （例如，不会创建出两条重复数据）。 31. 在微服务架构下，接口测试面临哪些挑战？如何应对？ 答： 挑战： 服务依赖： 服务众多，依赖复杂，环境搭建困难。 数据一致性： 测试数据需要在多个服务间保持一致。 版本兼容： 服务独立部署，版本兼容性测试变得重要。 应对： Mock & Stub： 大量使用Mock来隔离被测服务，模拟其依赖的服务。 契约测试（Contract Testing）： 确保消费者和提供者之间的接口契约（如OpenAPI文档）得到遵守，是比集成测试更轻量的选择。 API网关测试： 集中测试网关的路由、认证、限流等策略。 容器化： 使用Docker等容器技术快速搭建和复制测试环境。 🔗测试开发训练营 (opens new window)：针对面试求职的测试开发训练营，大厂导师 1v1 私教，帮助学员从 0 到 1 拿到测开满意的 offer ✅直播授课+实时互动答疑，课程到就业贯穿企业级案例，由测试开发导师全程主讲，绝无其他助理老师代课。 ✅大厂测试开发导师一对一求职陪跑，覆盖课程答疑+简历打磨+面试模拟面试+面试复盘等求职辅导 最新的图解文章都在公众号首发，别忘记关注哦！！如果你想加入百人技术交流群，扫码下方二维码回复「加群」。