业务测试面试题 - 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），并融入敏捷迭代。

• 需求分析：参与需求评审会，理解业务逻辑，确定可测试性，识别潜在风险。
• 测试计划：制定测试策略（测试范围、方法、工具、环境、人力、进度）、确定准入/准出标准。
• 测试设计：设计测试用例（等价类、边界值、场景法等）、编写自动化脚本、准备测试数据。
• 测试环境搭建：配置服务器、数据库、部署测试版本、准备测试客户端（浏览器）。
• 测试执行：执行冒烟测试 -> 执行详细测试用例（功能、UI、兼容性） -> 提交并跟踪缺陷 -> 进行回归测试。
• 测试报告与闭环：输出测试报告，评估测试结果，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注入：在用户名输入 ' or '1'='1 -- 等。
  • 暴力破解：连续输错多次密码，账户是否被锁定或需要验证码？
  • 错误信息：错误提示是否模糊化？（不提示"用户名不存在"或"密码错误"）
  • 记住我："记住我"功能是否安全地存储凭证？
  • URL参数：登录后URL中的Session ID是否暴露？是否使用HTTPS传输？

• 可用性测试：

  • Tab键切换顺序是否正常？
  • 是否有忘记密码的入口？

• 兼容性测试：在不同浏览器、设备上登录功能是否正常。

• 性能测试：登录接口的响应时间。

7. 如何测试一个电子商务网站的"加入购物车"功能？

答：

• 基本功能：

  • 商品成功加入购物车，页面有添加成功的提示（Toast/Modal）。
  • 购物车图标上的数量计数器实时更新。
  • 从不同页面（商品列表页、商品详情页）添加同一商品，数量应累加。
  • 添加不同商品，购物车应展示所有商品。
  • 检查购物车页面：商品信息（名称、图片、价格、SKU）、数量、总价计算是否正确。

• 边界和异常：

  • 添加商品数量为0、负数、极大值、小数、非数字，系统如何处理？
  • 库存不足时添加商品，是否有提示？
  • 商品下架或删除后，在购物车中如何显示？

• 会话和缓存：

  • 登录前后，购物车内容是否合并？（未登录时添加，登录后仍存在）
  • 关闭浏览器再打开，未登录状态下购物车内容是否丢失（依赖Cookie）？登录后是否持久化？

• 并发测试：多个用户同时抢购最后一个库存商品，库存和订单数据是否正确。

8. 如何测试网站的搜索功能？

答：

• 基础搜索：

  • 输入存在的关键字，能返回正确结果。
  • 输入不存在的关键字，显示"无结果"或友好提示。
  • 搜索框为空直接搜索，如何处理？（通常显示所有结果或提示输入）

• 高级搜索：如果支持筛选（如按价格、分类、品牌），测试每个筛选条件及其组合。

• 搜索建议：测试输入时是否出现自动补全的建议下拉框，且建议项可点击。

• 特殊字符：输入特殊字符（如 %, _, #, ），系统应正确处理或转义，不应报错或引发XSS漏洞。

• 长字符串：输入超长的字符串，测试系统响应和UI展示。

• 性能：搜索结果的响应时间，特别是模糊搜索和大数据量下的性能。

• 排序：测试按相关性、价格、销量等排序功能是否正确。

• 分页：搜索结果过多时，分页功能是否正常。

10. 如何测试文件上传功能？

答：

• 有效文件：上传符合要求的文件（格式、大小），成功上传并有正确提示。

• 无效文件：

  • 格式：上传不符合规定的格式（如只允许图片却上传.exe），应有友好错误提示。
  • 大小：上传超过大小限制的文件，应有明确提示。
  • 重名文件：上传与服务器上同名的文件，测试覆盖策略。
  • 0字节文件：上传空文件。
  • 特殊文件名：上传文件名包含特殊字符（如 中文#!$%.exe）或超长文件名的文件。

• UI与交互：

  • 上传过程中是否有进度条？
  • 能否取消上传？
  • 是否支持拖拽上传？
  • 上传后是否有预览功能？

• 安全：

  • 尝试上传包含恶意脚本的文件（如将 .jpg 文件后缀改为 .php 但内容不变），验证服务器是否仅根据文件内容而非后缀名判断类型（MIME Type验证）。
  • 上传成功后，检查文件在服务器上的存储路径和访问权限是否正确（防止通过URL直接访问执行脚本）。

11. 如何测试支付流程？

答：支付流程测试需要极高的严谨性。

• 正向流程：使用测试支付账号（如沙箱环境），完成从下单到支付成功的完整流程。验证订单状态、支付金额、库存扣减、积分增加等是否正确。

• 异常流程：

  • 支付中断：在支付过程中关闭页面、断开网络，检查订单状态（应为"待支付"），并支持重新支付。
  • 支付失败：模拟支付失败（如余额不足、银行卡号错误），检查失败提示和订单状态。
  • 重复支付：对同一订单发起两次支付请求，系统应正确处理（防止重复扣款）。

• 数据一致性：支付成功后，检查订单库、支付库、会计库等之间的数据是否一致。

• 安全：

  • 金额篡改：在提交支付请求前，通过抓包工具（如Fiddler）尝试修改支付金额，后端必须重新校验金额，绝不允许前端传值决定。
  • 防重放攻击：相同的支付请求被重复提交，应被拒绝。

• 对账：如果有，测试与第三方支付渠道的对账功能。

12. 什么是跨浏览器测试？你最关注哪些方面？

答：跨浏览器测试是确保网站在不同浏览器（Chrome, Firefox, Safari, Edge等）及其不同版本上功能正常、布局一致、体验良好。

• 关注方面：
  • 功能一致性：核心业务流程在所有目标浏览器中必须工作正常。
  • 布局和样式（UI）：字体、颜色、间距、元素位置、响应式布局（在不同分辨率下）是否一致。CSS和HTML在不同浏览器内核下的渲染差异是重点。
  • JavaScript兼容性：页面交互、动态效果、Ajax请求等是否正常。老版本IE是重灾区。
  • 性能：页面在不同浏览器中的加载和渲染速度可能有差异。

13. 你使用哪些工具进行跨浏览器测试？

答：

• 本地工具：在不同机器或虚拟机上安装不同浏览器进行测试。
• 云测试平台：BrowserStack, Sauce Labs, LambdaTest。它们提供大量真实浏览器和移动设备的云虚拟机，无需本地配置，高效但付费。
• 浏览器开发者工具：使用Chrome DevTools的设备模拟功能（Device Mode）初步测试不同屏幕尺寸和User-Agent，但不能完全替代真机测试。
• 自动化框架：Selenium WebDriver 可以配置在不同浏览器的Driver上运行脚本，实现跨浏览器自动化测试。

14. Web性能测试关注哪些核心指标？

答：

• 页面加载指标：

  • 首次内容绘制（FCP）：页面首次有任何内容（文本、图像等）渲染的时间。
  • 最大内容绘制（LCP）：页面中最大可见元素渲染完成的时间。（衡量加载体验）
  • 首次输入延迟（FID）：用户首次与页面交互（点击、taps）到浏览器实际响应的延迟。（衡量交互体验）

• 网络指标：

  • 页面加载总时间（Load Time）
  • TTFB（Time to First Byte）：从请求发出到收到服务器第一个字节响应的时间，反映服务器处理速度。

• 业务指标：

  • 事务响应时间：如"登录"、"搜索"等关键操作的完成时间。

• 资源指标：CPU占用率、内存占用率、网络带宽。

15. 你如何分析一个Web页面的性能瓶颈？

答：

• 使用浏览器DevTools：

  • Network面板：查看所有资源的加载瀑布图（Waterfall），找出加载慢的资源（大的图片、JS、CSS文件）或TTFB长的API请求。
  • Performance面板：录制页面活动，分析详细的加载、脚本执行、渲染、绘制时间线，找到耗时的JavaScript函数或布局重排（Reflow）。
  • Lighthouse/Audits面板：生成综合性能报告，提供优化建议（如压缩资源、启用缓存、减少未使用的CSS/JS）。

• 关注建议：报告会直接指出问题，如"消除阻塞渲染的资源"、"提供尺寸正确的图像"、"减少主线程工作"。

17. 描述一个你发现的最复杂的Web Bug，以及你是如何排查定位的。

答：（这是一个行为面试题，需根据自身经历准备一个故事）

回答结构（STAR原则）：

• Situation（情境）：描述项目背景和功能（如"在一个电商平台的促销折扣计算模块"）。
• Task（任务）：你需要测试什么（如"测试多种优惠券叠加使用的场景"）。
• Action（行动）：你做了什么来发现和排查。
  • 复现：如何稳定复现这个偶现的Bug。
  • 隔离：如何通过改变测试数据、步骤来缩小问题范围。
  • 调查：如何查看前端Console错误、网络请求Payload和Response、与后端同事联查日志、检查数据库数据。
  • 定位：最终发现是前端传递参数格式错误/后端计算逻辑边界条件遗漏/缓存数据未及时更新等。
• Result（结果）：Bug被成功修复，并且你总结了经验，为类似场景增加了更多测试用例。