# 业务测试面试题

#

# 一.测试基础

#

# 1. 什么是软件测试？软件测试的主要目的是什么？

#

参考答案：

软件测试是通过手动或自动的方式运行系统或系统组件，以验证它是否满足规定需求并识别与实际需求之间的差异的过程。

主要目的：

发现软件中的缺陷和错误

验证软件是否满足业务需求和规格说明

评估软件产品的质量特性

建立对软件质量的信心

预防缺陷，降低软件开发风险

# 2. 黑盒测试和白盒测试有什么区别？

#

参考答案：

特性 黑盒测试 白盒测试 测试依据 需求规格说明书 内部代码结构 测试者角色 模拟最终用户 开发者或专业测试人员 测试范围 功能测试 代码覆盖、路径测试 技术要求 不需要编程知识 需要编程知识 测试层级 主要在系统测试层面 主要在单元测试层面 优点 从用户角度测试 能发现内部逻辑错误 缺点 无法测试内部逻辑 无法测试缺失的功能

特性 黑盒测试 白盒测试

特性

黑盒测试

白盒测试

测试依据 需求规格说明书 内部代码结构

测试依据

需求规格说明书

内部代码结构

测试者角色 模拟最终用户 开发者或专业测试人员

测试者角色

模拟最终用户

开发者或专业测试人员

测试范围 功能测试 代码覆盖、路径测试

测试范围

功能测试

代码覆盖、路径测试

技术要求 不需要编程知识 需要编程知识

技术要求

不需要编程知识

需要编程知识

测试层级 主要在系统测试层面 主要在单元测试层面

测试层级

主要在系统测试层面

主要在单元测试层面

优点 从用户角度测试 能发现内部逻辑错误

优点

从用户角度测试

能发现内部逻辑错误

缺点 无法测试内部逻辑 无法测试缺失的功能

缺点

无法测试内部逻辑

无法测试缺失的功能

# 3. 什么是测试用例？一个好的测试用例应包含哪些元素？

#

参考答案：

测试用例是一组条件或变量，测试人员根据它来确定被测系统或应用程序的某个特性是否正常工作。

一个好的测试用例应包含：

测试用例ID（唯一标识符）

测试用例描述/名称

前置条件

测试步骤（详细操作）

测试数据

预期结果

实际结果（执行后填写）

测试状态（通过/失败/阻塞）

优先级（高/中/低）

所属模块/功能

创建者和创建日期

执行者和执行日期

# 4. 解释等价类划分和边界值分析的概念

#

参考答案： 等价类划分是将输入数据划分为若干个等价类，从每个类中选取少量代表性数据作为测试用例。假设同一等价类中的元素会以相同方式处理。

边界值分析是针对输入和输出范围的边界设计测试用例的方法。经验表明，边界附近的区域最容易出现错误。

示例： 测试一个接受1-100数字的输入框

等价类：有效类(1-100)，无效类(<1，>100)

边界值：0,1,2,99,100,101

# 5. 什么是回归测试？何时进行回归测试？

#

参考答案：

回归测试是验证已修改的软件或环境变更没有对现有功能产生不利影响的测试。

进行回归测试的情况：

添加新功能后

缺陷修复后

代码重构后

性能优化后

环境变更后（如操作系统、数据库升级）

配置文件修改后

# 6. 解释敏捷测试和传统瀑布模型测试的区别

#

参考答案：

特性 传统瀑布模型测试 敏捷测试 测试时间 开发完成后开始 与开发同步进行 测试角色 独立的测试团队 开发与测试紧密合作 文档依赖 高度依赖详细文档 轻量文档，强调沟通 反馈周期 长周期反馈 短周期快速反馈 测试重点 强调过程与文档 强调实际可工作软件 变更响应 变更成本高 欢迎变更，响应快速

特性 传统瀑布模型测试 敏捷测试

特性

传统瀑布模型测试

敏捷测试

测试时间 开发完成后开始 与开发同步进行

测试时间

开发完成后开始

与开发同步进行

测试角色 独立的测试团队 开发与测试紧密合作

测试角色

独立的测试团队

开发与测试紧密合作

文档依赖 高度依赖详细文档 轻量文档，强调沟通

文档依赖

高度依赖详细文档

轻量文档，强调沟通

反馈周期 长周期反馈 短周期快速反馈

反馈周期

长周期反馈

短周期快速反馈

测试重点 强调过程与文档 强调实际可工作软件

测试重点

强调过程与文档

强调实际可工作软件

变更响应 变更成本高 欢迎变更，响应快速

变更响应

变更成本高

欢迎变更，响应快速

# 7. 什么是冒烟测试和健全测试？

#

参考答案： 冒烟测试是在正式测试开始前对软件基本功能进行的初步测试，目的是确认软件基本功能正常，可以开展后续详细测试。

健全测试是在修复缺陷后进行的窄而深的测试，目的是确认特定缺陷已被修复，且修复没有引入新问题。

区别：

冒烟测试：广度测试，覆盖主要功能

健全测试：深度测试，针对特定区域

# 8. 什么是探索性测试？它有什么优点和缺点？

#

参考答案：

探索性测试是一种同时设计测试和执行测试的方法，强调测试人员的自由度和创造力。

优点：

发现计划外缺陷

适合需求不明确或变化快的项目

充分利用测试人员的经验和直觉

快速了解系统功能

缺点：

难以衡量测试覆盖率

依赖测试人员的技能和经验

难以重复和回归

不适合合规性要求高的项目

# 9. 缺陷生命周期包括哪些状态？

#

参考答案：

缺陷生命周期通常包括以下状态：

新建：测试人员发现并报告新缺陷

打开：缺陷被确认并分配给开发人员

修复：开发人员修复缺陷

重新测试：测试人员验证修复

重新打开：如果修复不成功，重新打开缺陷

关闭：缺陷已成功修复

拒绝：开发人员认为不是缺陷

延期：缺陷确认但推迟修复

重复：缺陷已被报告过

# 10. 如何编写有效的缺陷报告？

#

参考答案：

有效的缺陷报告应包含：

清晰标题：简明扼要描述问题

详细描述：准确描述问题现象

重现步骤：详细、准确的重现步骤

预期与实际结果：明确对比

截图/录像：直观展示问题

环境信息：操作系统、浏览器、设备等

严重程度：问题对系统的影响程度

优先级：修复问题的紧急程度

附加信息：日志文件、网络抓包等

# 11. 什么是测试计划？测试计划应包含哪些内容？

#

参考答案：

测试计划是描述测试范围、方法、资源和进度的文档，指导测试活动。

测试计划应包含：

测试目标和范围

测试策略和方法

测试环境和工具

测试进度和里程碑

资源分配和职责

风险和应对措施

可交付成果和验收标准

暂停和恢复标准

# 12. 如何确定测试的优先级？

#

参考答案：

确定测试优先级考虑因素：

风险：功能失败的业务影响

使用频率：常用功能优先测试

可见性：用户直接接触的功能

复杂度：复杂功能更容易出错

依赖性：被其他功能依赖的核心功能

法律法规：合规性要求高的功能

项目进度：根据发布时间表安排

常用方法：风险矩阵，结合可能性和影响评估优先级。

# 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但开发人员无法复现时，你会怎么做？

#

答：

自我审查： 再次确认复现步骤，检查测试环境、测试数据是否准确、唯一。

提供更多信息： 提供更详细的步骤、截图、视频、日志文件、网络抓包数据等。

寻求帮助： 请其他测试同事在自己的环境下尝试复现。

与开发当面沟通： 坐到开发人员旁边，现场演示复现过程。

检查环境差异： 对比测试环境和开发环境（操作系统、浏览器版本、数据库数据、配置等）的差异。

记录并跟踪： 即使无法复现，也应在Bug管理系统中记录，并注明“无法稳定复现”，后续版本持续关注。

# 19. 你如何评估你的测试是否足够充分（Test Coverage）?

#

答： 可以从以下几个维度评估：

需求覆盖率： 是否所有需求项都有对应的测试用例？

代码覆盖率： 通过工具（如JaCoCo， Cobertura）统计语句、分支、条件等覆盖率。

风险覆盖率： 是否对项目识别的关键风险点进行了测试？

用例执行率： 计划的测试用例是否100%被执行？

缺陷发现率： 发现的缺陷趋势是否趋于平稳？

(注意：高覆盖率不代表高质量，但低覆盖率通常意味着测试不充分)

# 20. 测试的准入准则（Entry Criteria）和准出准则（Exit Criteria）是什么？

#

答：

准入准则： 开始执行测试必须满足的条件。如：开发完成并提测、冒烟测试通过、测试环境准备就绪。

准出准则： 结束测试活动必须满足的条件。如：测试用例100%执行、致命/严重缺陷已修复并验证、未修复缺陷有明确处理意见、测试报告已输出。

# 21. 什么是持续集成（CI）？它在测试中有什么好处？

#

答： 持续集成是一种开发实践，要求开发人员频繁地（每天多次）将代码集成到主干，并通过自动化构建和测试来验证。

对测试的好处：

快速反馈： 能够快速发现集成错误和回归缺陷。

提高效率： 自动化测试在CI中自动触发，节省手动 effort。

保证质量： 确保代码库始终处于可测试和可部署的状态。

**

# 22. 你如何保证自动化测试的稳定性和可维护性？

#

答：

使用可靠的定位策略： 优先使用ID等稳定属性，而非XPATH绝对路径。

引入等待机制： 使用显式等待而非固定休眠。

遵循POM设计模式： 将页面元素定位和业务操作分离，便于维护。

代码复用： 封装公共方法和组件。

数据驱动： 将测试数据与脚本分离。

版本控制： 对测试脚本进行版本管理。

定期评审和重构： 定期清理过时脚本，优化代码。

# 23. 除了功能，你认为还可以从哪些角度去测试一个产品？

#

答： 功能、性能、安全、兼容性、易用性、可靠性、可移植性、可维护性、本地化/国际化等。

# 24. 当测试时间非常紧张时，你会如何应对？

#

答：

风险评估： 与项目经理、产品经理沟通，优先测试核心功能和高风险区域。

调整策略： 优先进行冒烟测试和主要流程的正向测试。

利用自动化： 执行已有的自动化回归测试套件，快速获得反馈。

探索性测试： 在重点区域进行时间盒管理的探索性测试，高效发现重要缺陷。

清晰沟通： 及时向团队汇报测试进度和风险，明确告知在有限时间内能覆盖的范围和可能遗留的风险。

# 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： 浏览器兼容性（不同内核：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按钮（如“登录”、“注册”、“购买”）可点击。 搜索框可输入文本并执行搜索。 用户已登录状态下，用户名能正确显示。

输入URL，页面能正常打开，不报404/500错误。

页面核心布局（Header， Footer， 主导航）加载完整。

页面核心内容（如Banner、主要商品列表、新闻头条）数据能正确展示。

首页Logo点击能正确跳转到首页。

主要CTA按钮（如“登录”、“注册”、“购买”）可点击。

搜索框可输入文本并执行搜索。

用户已登录状态下，用户名能正确显示。

# 4. 什么是回归测试？如何确定Web项目的回归测试范围？

#

答： 回归测试是验证代码修改没有破坏现有功能。

确定范围： 核心功能： 所有核心业务流程（如电商的购物流程、支付的流程）。 修改模块关联区域： 本次开发修改的模块及其上下游关联模块。 缺陷相关区域： 本轮修复的Bug所涉及的功能点。 通用功能： 登录、注册、搜索、导航等全站通用功能。 高风险区域： 历史上Bug高发、逻辑复杂的模块。 自动化测试套件： 利用已有的自动化脚本进行快速回归。

核心功能： 所有核心业务流程（如电商的购物流程、支付的流程）。

修改模块关联区域： 本次开发修改的模块及其上下游关联模块。

缺陷相关区域： 本轮修复的Bug所涉及的功能点。

通用功能： 登录、注册、搜索、导航等全站通用功能。

高风险区域： 历史上Bug高发、逻辑复杂的模块。

自动化测试套件： 利用已有的自动化脚本进行快速回归。

# 5. 什么是探索性测试？它在Web测试中如何应用？

#

答： 探索性测试是同时进行测试设计、测试执行、学习产品并给出反馈的测试方法。它强调测试者的自由、思维和实时学习。

在Web中的应用： 新功能探索： 不依赖用例，快速探索新上线的功能，发现明显的逻辑或UI问题。 用户场景模拟： 扮演不同类型的用户（如新手、专家、恶意用户），模拟他们的操作路径。 边界和异常探索： 在输入框尝试各种极端数据，尝试中断网络、回退、刷新等操作。 与脚本化测试互补： 在自动化脚本覆盖之外，发现那些难以预料的、隐蔽的缺陷。

新功能探索： 不依赖用例，快速探索新上线的功能，发现明显的逻辑或UI问题。

用户场景模拟： 扮演不同类型的用户（如新手、专家、恶意用户），模拟他们的操作路径。

边界和异常探索： 在输入框尝试各种极端数据，尝试中断网络、回退、刷新等操作。

与脚本化测试互补： 在自动化脚本覆盖之外，发现那些难以预料的、隐蔽的缺陷。

# 6. 如何对一个用户登录功能进行测试？

#

答： 这是一个经典问题，考察测试用例设计的全面性。

功能测试： 输入正确的用户名和密码，成功登录并跳转。 输入正确的用户名、错误的密码，提示错误信息。 输入错误的用户名、任何密码，提示错误信息（不明确提示是用户名还是密码错误，以防信息泄露）。 用户名/密码为空，提示错误。 密码是否以密文（星号/圆点）显示？ 是否支持键盘操作（回车键触发登录）？ 登录成功后，Session/Cookie是否正确设置？ 登录成功后，点击浏览器回退按钮，是否安全？（不应退回到登录页且显示已登录信息）

输入正确的用户名和密码，成功登录并跳转。

输入正确的用户名、错误的密码，提示错误信息。

输入错误的用户名、任何密码，提示错误信息（不明确提示是用户名还是密码错误，以防信息泄露）。

用户名/密码为空，提示错误。

密码是否以密文（星号/圆点）显示？

是否支持键盘操作（回车键触发登录）？

登录成功后，Session/Cookie是否正确设置？

登录成功后，点击浏览器回退按钮，是否安全？（不应退回到登录页且显示已登录信息）

安全测试： SQL注入： 在用户名输入 ' or '1'='1 --` 等。 暴力破解： 连续输错多次密码，账户是否被锁定或需要验证码？ 错误信息： 错误提示是否模糊化？（不提示“用户名不存在”或“密码错误”） 记住我： “记住我”功能是否安全地存储凭证？ URL参数： 登录后URL中的Session ID是否暴露？是否使用HTTPS传输？

SQL注入： 在用户名输入 ' or '1'='1 --` 等。

' or '1'='1

暴力破解： 连续输错多次密码，账户是否被锁定或需要验证码？

错误信息： 错误提示是否模糊化？（不提示“用户名不存在”或“密码错误”）

记住我： “记住我”功能是否安全地存储凭证？

URL参数： 登录后URL中的Session ID是否暴露？是否使用HTTPS传输？

可用性测试： Tab键切换顺序是否正常？ 是否有忘记密码的入口？

Tab键切换顺序是否正常？

是否有忘记密码的入口？

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

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

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

#

答：

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

商品成功加入购物车，页面有添加成功的提示（Toast/Modal）。

购物车图标上的数量计数器实时更新。

从不同页面（商品列表页、商品详情页）添加同一商品，数量应累加。

添加不同商品，购物车应展示所有商品。

检查购物车页面：商品信息（名称、图片、价格、SKU）、数量、总价计算是否正确。

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

添加商品数量为0、负数、极大值、小数、非数字，系统如何处理？

库存不足时添加商品，是否有提示？

商品下架或删除后，在购物车中如何显示？

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

登录前后，购物车内容是否合并？（未登录时添加，登录后仍存在）

关闭浏览器再打开，未登录状态下购物车内容是否丢失（依赖Cookie）？登录后是否持久化？

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

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

#

答：

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

输入存在的关键字，能返回正确结果。

输入不存在的关键字，显示“无结果”或友好提示。

搜索框为空直接搜索，如何处理？（通常显示所有结果或提示输入）

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

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

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

%

_

#

<script>

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

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

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

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

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

#

答：

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

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

格式： 上传不符合规定的格式（如只允许图片却上传.exe），应有友好错误提示。

大小： 上传超过大小限制的文件，应有明确提示。

重名文件： 上传与服务器上同名的文件，测试覆盖策略。

0字节文件： 上传空文件。

特殊文件名： 上传文件名包含特殊字符（如 中文#!$%.exe）或超长文件名的文件。

中文#!$%.exe

UI与交互： 上传过程中是否有进度条？ 能否取消上传？ 是否支持拖拽上传？ 上传后是否有预览功能？

上传过程中是否有进度条？

能否取消上传？

是否支持拖拽上传？

上传后是否有预览功能？

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

尝试上传包含恶意脚本的文件（如将 .jpg 文件后缀改为 .php 但内容不变），验证服务器是否仅根据文件内容而非后缀名判断类型（MIME Type验证）。

.jpg

.php

上传成功后，检查文件在服务器上的存储路径和访问权限是否正确（防止通过URL直接访问执行脚本）。

# 11. 如何测试支付流程？

#

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

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

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

支付中断： 在支付过程中关闭页面、断开网络，检查订单状态（应为“待支付”），并支持重新支付。

支付失败： 模拟支付失败（如余额不足、银行卡号错误），检查失败提示和订单状态。

重复支付： 对同一订单发起两次支付请求，系统应正确处理（防止重复扣款）。

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

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

金额篡改：在提交支付请求前，通过抓包工具（如Fiddler）尝试修改支付金额，后端必须重新校验金额，绝不允许前端传值决定。

防重放攻击： 相同的支付请求被重复提交，应被拒绝。

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

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

#

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

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

功能一致性： 核心业务流程在所有目标浏览器中必须工作正常。

布局和样式（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）到浏览器实际响应的延迟。（衡量交互体验）

首次内容绘制（FCP）： 页面首次有任何内容（文本、图像等）渲染的时间。

最大内容绘制（LCP）： 页面中最大可见元素渲染完成的时间。（衡量加载体验）

首次输入延迟（FID）： 用户首次与页面交互（点击、 taps）到浏览器实际响应的延迟。（衡量交互体验）

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

页面加载总时间（Load Time）

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

业务指标： 事务响应时间： 如“登录”、“搜索”等关键操作的完成时间。

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

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

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

#

答：

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

Network面板： 查看所有资源的加载瀑布图（Waterfall），找出加载慢的资源（大的图片、JS、CSS文件）或TTFB长的API请求。

Performance面板： 录制页面活动，分析详细的加载、脚本执行、渲染、绘制时间线，找到耗时的JavaScript函数或布局重排（Reflow）。

Lighthouse/Audits面板： 生成综合性能报告，提供优化建议（如压缩资源、启用缓存、减少未使用的CSS/JS）。

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

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

#

答： (这是一个行为面试题，需根据自身经历准备一个故事) 回答结构（STAR原则）：

Situation（情境）： 描述项目背景和功能（如“在一个电商平台的促销折扣计算模块”）。

Task（任务）： 你需要测试什么（如“测试多种优惠券叠加使用的场景”）。

Action（行动）： 你做了什么来发现和排查。

复现： 如何稳定复现这个偶现的Bug。 隔离： 如何通过改变测试数据、步骤来缩小问题范围。 调查： 如何查看前端Console错误、网络请求Payload和Response、与后端同事联查日志、检查数据库数据。 定位： 最终发现是前端传递参数格式错误/后端计算逻辑边界条件遗漏/缓存数据未及时更新等。

复现： 如何稳定复现这个偶现的Bug。

隔离： 如何通过改变测试数据、步骤来缩小问题范围。

调查： 如何查看前端Console错误、网络请求Payload和Response、与后端同事联查日志、检查数据库数据。

定位： 最终发现是前端传递参数格式错误/后端计算逻辑边界条件遗漏/缓存数据未及时更新等。

Result（结果）： Bug被成功修复，并且你总结了经验，为类似场景增加了更多测试用例。

# 三.App测试

#

# 1. APP测试与Web测试的主要区别是什么？

#

答： 主要区别在于技术架构、测试重点和测试环境。

技术架构： APP属于C/S架构，需要安装客户端；Web属于B/S架构，通过浏览器访问。

测试重点： APP： 安装、卸载、升级、中断测试（来电、消息）、手势操作、网络切换（2G/3G/4G/5G/Wi-Fi)、设备兼容性（分辨率、厂商OS定制）、功耗（电量、流量、CPU占用）。 Web： 浏览器兼容性（不同内核）、页面加载性能、缓存。

APP： 安装、卸载、升级、中断测试（来电、消息）、手势操作、网络切换（2G/3G/4G/5G/Wi-Fi)、设备兼容性（分辨率、厂商OS定制）、功耗（电量、流量、CPU占用）。

Web： 浏览器兼容性（不同内核）、页面加载性能、缓存。

测试环境： APP测试需要大量真机或模拟器；Web测试环境相对统一。

# 2. 描述一下APP的测试流程。

#

答： 遵循敏捷迭代流程，每个版本循环如下：

需求分析： 参与评审，理解PRD，编写测试点（Checklist）。

测试计划： 确定测试范围、策略、资源（设备池）、进度、风险。

测试设计： 设计测试用例（功能、兼容、性能等），编写自动化脚本。

测试执行： 提测验证： 开发提测后，先进行冒烟测试，通过后方可进入详细测试。 详细测试： 执行测试用例，提交Bug并跟踪回归。 回归测试： Bug修复后，进行验证并执行关联用例。 验收测试： 产品经理或业务方进行最终确认。

提测验证： 开发提测后，先进行冒烟测试，通过后方可进入详细测试。

详细测试： 执行测试用例，提交Bug并跟踪回归。

回归测试： Bug修复后，进行验证并执行关联用例。

验收测试： 产品经理或业务方进行最终确认。

上线与线上监控： 配合上线，监控线上日志、崩溃率、用户反馈。

# 3. 什么是冒烟测试？针对一个APP新版本，你的冒烟测试用例会包含哪些？

#

答： 冒烟测试是对软件核心功能进行初步验证，确保主要流程畅通，Build可测。

APP冒烟用例： APP能够成功安装/覆盖安装。 APP能够正常启动，无崩溃（Crash）。 用户能成功登录/登出。 核心业务流程畅通（如电商APP：首页加载 -> 搜索商品 -> 加入购物车 -> 下单）。 主要Tab页切换正常。 网络切换后，APP数据能正常加载和刷新。

APP能够成功安装/覆盖安装。

APP能够正常启动，无崩溃（Crash）。

用户能成功登录/登出。

核心业务流程畅通（如电商APP：首页加载 -> 搜索商品 -> 加入购物车 -> 下单）。

主要Tab页切换正常。

网络切换后，APP数据能正常加载和刷新。

# 4. 如何制定APP的兼容性测试策略？

#

答： 采用“主流机型全覆盖，长尾机型抽样”的策略。

操作系统： 覆盖主流iOS和Android版本（如iOS 15-17， Android 11-13）。

设备厂商： 覆盖主流品牌（华为、小米、OPPO、vivo、三星、荣耀）及原生Android（如Pixel）。

屏幕分辨率： 覆盖主流分辨率（如全面屏、刘海屏、折叠屏）。

网络运营商： 移动、联通、电信。

优先级： 优先覆盖用户量最大的Top 20机型，其余利用云测平台进行覆盖。

# 5. APP的灰度发布（Gray Release）是什么？测试如何配合？

#

答： 灰度发布是指先让一部分用户（如5%）使用新版本，逐步扩大范围，平滑过渡的上线方式。

测试配合： 准备阶段： 确保灰度包是经过全面测试的稳定版本。 发布阶段： 密切监控灰度用户的崩溃率（Crash Rate）、异常退出率、关键业务指标（如下单成功率）。 问题响应： 一旦发现严重问题，立即上报，推动回滚（Rollback）或发布热修复（Hotfix）。 扩大范围： 确认无问题后，逐步扩大灰度用户比例，直至全量。

准备阶段： 确保灰度包是经过全面测试的稳定版本。

发布阶段： 密切监控灰度用户的崩溃率（Crash Rate）、异常退出率、关键业务指标（如下单成功率）。

问题响应： 一旦发现严重问题，立即上报，推动回滚（Rollback）或发布热修复（Hotfix）。

扩大范围： 确认无问题后，逐步扩大灰度用户比例，直至全量。

# 6. 什么是Monkey测试？它在APP测试中有什么作用？

#

答： Monkey测试是向APP发送随机的用户事件流（如触摸、手势、按键），用来压力测试APP的稳定性和健壮性。

作用： 发现隐藏的Crash/ANR： 通过随机操作发现一些极端情况下才会出现的崩溃。 压力测试： 检验APP在长时间、高频率操作下的性能表现（内存泄漏等）。 快速验证： 在测试初期快速验证版本的稳定性。

发现隐藏的Crash/ANR： 通过随机操作发现一些极端情况下才会出现的崩溃。

压力测试： 检验APP在长时间、高频率操作下的性能表现（内存泄漏等）。

快速验证： 在测试初期快速验证版本的稳定性。

# 7. 如何查看和分析Android设备的日志？

#

答： 使用Android SDK提供的 adb logcat 命令。

adb logcat

查看全部日志： adb logcat

adb logcat

过滤特定Tag/级别： adb logcat -s "TAG名:I" 或 adb logcat *:E (只看Error日志)

adb logcat -s "TAG名:I"

adb logcat *:E

将日志输出到文件： adb logcat > log.txt

adb logcat > log.txt

分析： 在日志中搜索关键词如 Exception, Fatal, Crash, ANR 来定位问题。

Exception

Fatal

Crash

ANR

# 8. 什么是ANR？导致ANR的原因有哪些？

#

答： ANR（Application Not Responding）是指应用程序无响应。

原因： 主线程被阻塞： 在主线程中执行了耗时操作（如网络请求、大量数据库读写、复杂计算）。 死锁（Deadlock）： 线程间相互等待资源。 BroadcastReceiver超时： 在onReceive()方法中执行了过多操作。 Service处理超时。

主线程被阻塞： 在主线程中执行了耗时操作（如网络请求、大量数据库读写、复杂计算）。

死锁（Deadlock）： 线程间相互等待资源。

BroadcastReceiver超时： 在onReceive()方法中执行了过多操作。

onReceive()

Service处理超时。

# 9. 什么是Crash？如何收集和分析Crash信息？

#

答： Crash是指应用程序发生了未捕获的异常而导致的意外终止。

收集： 集成第三方SDK，如 Firebase Crashlytics、Bugly、Sentry。它们能自动捕获崩溃堆栈信息、设备信息、操作系统版本等，并上报到平台。

分析： 在Crash管理平台查看堆栈跟踪（Stack Trace），定位到出错的代码行、方法和线程，结合日志分析原因。

# 10. 如何测试APP的安装、卸载和升级？

#

答：

安装： 全新安装（首次安装）。 覆盖安装（旧版本覆盖）。 较低版本覆盖更高版本（应失败）。 安装中断（如断电、拔数据线）。

全新安装（首次安装）。

覆盖安装（旧版本覆盖）。

较低版本覆盖更高版本（应失败）。

安装中断（如断电、拔数据线）。

卸载： 卸载后，文件、缓存、数据库是否全部清除。 卸载中断。

卸载后，文件、缓存、数据库是否全部清除。

卸载中断。

升级： 跨版本升级（如v1.0 -> v3.0）。 相邻版本升级（v1.0 -> v1.1）。 升级后，用户数据、配置、状态是否保留正确。 升级中断后的恢复情况。

跨版本升级（如v1.0 -> v3.0）。

相邻版本升级（v1.0 -> v1.1）。

升级后，用户数据、配置、状态是否保留正确。

升级中断后的恢复情况。

# 11. 如何测试APP的中断事件？

#

答： 在APP不同操作场景下，模拟：

来电/短信中断： 检查中断后APP能否正常暂停和恢复。

通知中心消息： 下拉通知栏点击消息，APP能否正确跳转。

锁屏/解锁： 锁屏后恢复，APP状态是否保持。

低电量提醒/关机。

插拔USB数据线、耳机。

切换网络（Wi-Fi <-> 移动数据）： 检查网络切换时数据是否重连、是否有提示、是否会Crash。

前后台切换： 按Home键切到后台，再重新打开。

# 12. APP的性能测试主要关注哪些指标？

#

答：

客户端性能： 启动时间： 冷启动、热启动时间。 CPU占用率： 在关键操作下，CPU占用不应过高。 内存占用： 检查是否存在内存泄漏（内存使用量持续增长不释放）。 流量消耗： 统计特定场景下的上行/下行流量。 电量消耗： APP对电池电量的影响。 帧率（FPS）： 页面滑动、动画是否流畅（通常应≥55fps）。

启动时间： 冷启动、热启动时间。

CPU占用率： 在关键操作下，CPU占用不应过高。

内存占用： 检查是否存在内存泄漏（内存使用量持续增长不释放）。

流量消耗： 统计特定场景下的上行/下行流量。

电量消耗： APP对电池电量的影响。

帧率（FPS）： 页面滑动、动画是否流畅（通常应≥55fps）。

服务器端性能： 通过API压测，关注响应时间、吞吐量、错误率。

# 13. 如何测试APP的耗电量？

#

答：

硬件工具： 使用专业功耗仪，数据最准确。

软件工具： iOS： 使用Xcode的Energy Organizer。 Android： 使用Battery Historian（需要Android 5.0+）分析 adb bugreport 文件，查看各组件的耗电详情。

iOS： 使用Xcode的Energy Organizer。

Android： 使用Battery Historian（需要Android 5.0+）分析 adb bugreport 文件，查看各组件的耗电详情。

adb bugreport

测试场景： 在待机、轻度使用（浏览）、重度使用（看视频、玩游戏）等场景下进行测试。

# 14. 如何测试APP的流量消耗？

#

答：

Android： 使用 adb shell dumpsys package <package_name> | grep Uid 查看UID，然后通过 adb shell cat /proc/uid_stat/<UID>/tcp_rcv 和 tcp_snd 查看接收和发送的流量字节数。或使用网络抓包工具（如Charles）统计。

adb shell dumpsys package <package_name> | grep Uid

adb shell cat /proc/uid_stat/<UID>/tcp_rcv

tcp_snd

iOS： 使用Xcode的Network工具监控流量。

第三方工具： 如腾讯GT、iTest等。

测试点： 关注应用在静止后台、频繁操作、大图加载、视频播放、断线重连等场景下的流量使用是否合理，是否有冗余请求、数据包过大等问题。

# 15. 如何测试APP的启动时间？

#

答：

冷启动（Cold Launch）： 进程不存在，从头启动APP。时间最长。

热启动（Warm Launch）： APP还在后台，将其唤醒到前台。时间较短。

测量方法： adb命令（Android）： adb shell am start -W -n package_name/activity_name 查看 TotalTime。 代码埋点： 在Application的onCreate()开始和第一个Activity的onWindowFocusChanged()时记录时间差。 工具： 使用Android Studio Profiler或Xcode Instruments的Time Profiler进行更精确的分析。

adb命令（Android）： adb shell am start -W -n package_name/activity_name 查看 TotalTime。

adb shell am start -W -n package_name/activity_name

TotalTime

代码埋点： 在Application的onCreate()开始和第一个Activity的onWindowFocusChanged()时记录时间差。

onCreate()

onWindowFocusChanged()

工具： 使用Android Studio Profiler或Xcode Instruments的Time Profiler进行更精确的分析。

# 16. 如何测试APP在不同网络环境下的表现？

#

答： 模拟各种网络场景：

网络制式： 2G、3G、4G、5G、Wi-Fi。

网络质量： 弱网（高延迟、高丢包、低带宽）、断网、网络切换（Wi-Fi和移动数据切换）。

测试工具： 硬件： 网络衰减仪（如Spirent C50）。 软件： Charles、Fiddler（弱网模拟功能），Facebook ATC（Augmented Traffic Control）。

硬件： 网络衰减仪（如Spirent C50）。

软件： Charles、Fiddler（弱网模拟功能），Facebook ATC（Augmented Traffic Control）。

测试点： APP是否会发生Crash、ANR；是否有超时机制和友好提示；数据是否正确加载；重连机制是否有效。

# 17. 弱网测试的关注点是什么？

#

答：

功能性： 请求超时后，APP是否处理得当（如提示“网络不佳”），而不仅仅是卡死或Crash。

用户体验： 是否有加载中的动画（Loading），是否支持手动重试。

数据一致性： 在弱网下提交表单（如付款），要防止重复提交，保证数据最终一致性。

性能： 页面加载时间，操作响应时间。

# 18. 如何模拟弱网环境进行测试？

#

答： 以Charles为例：

打开Charles，选择 Proxy -> Throttle Settings。

Proxy

Throttle Settings

勾选 Enable Throttling。

Enable Throttling

选择预设的网络条件（如3G）或自定义带宽（Bandwidth）、延迟（Latency）、丢包率（Packet Loss）。

设置完成后，手机上所有的网络请求都将经过Charles的弱网模拟。

# 19. APP的权限测试主要测试哪些内容？

#

答：

权限申请时机： 是否在需要使用时才申请（遵循最小化原则），而非一启动就申请所有权限。

授权结果处理： 用户允许权限后，功能是否正常。 用户拒绝权限后，APP是否正常处理（功能不可用，但有友好提示，且不会Crash）。 用户勾选“不再询问”并拒绝后，APP能否引导用户去系统设置页手动开启权限。

用户允许权限后，功能是否正常。

用户拒绝权限后，APP是否正常处理（功能不可用，但有友好提示，且不会Crash）。

用户勾选“不再询问”并拒绝后，APP能否引导用户去系统设置页手动开启权限。

iOS与Android差异： Android权限分为普通权限（安装时授予）和危险权限（运行时申请）；iOS所有隐私权限都需要运行时申请。

# 20. 如何测试APP的推送通知（Push Notification）？

#

答：

接收测试： APP在前台：通知是否展示，点击后是否正确跳转。 APP在后台：通知是否展示，点击后是否唤醒APP并跳转到指定页面。 APP进程被杀掉：通知是否展示，点击后是否能重新启动APP并跳转。

APP在前台：通知是否展示，点击后是否正确跳转。

APP在后台：通知是否展示，点击后是否唤醒APP并跳转到指定页面。

APP进程被杀掉：通知是否展示，点击后是否能重新启动APP并跳转。

功能开关： 测试在APP内和系统设置中关闭推送后，是否还能收到推送。

推送内容： 推送的标题、内容、跳转链接（Deep Link）是否正确。

# 21. APP的升级测试有哪些测试点？

#

答：

升级方式： 应用内更新、应用市场更新。

版本路径： 相邻版本升级、跨版本升级、低版本覆盖高版本（应提示失败）。

数据继承： 升级后，用户的登录状态、本地缓存、数据库、设置项等数据必须正确保留。

强制升级： 对于不支持的老版本，是否有强制升级提示和逻辑。

更新内容： 更新提示文案是否正确。

# 22. 如何对APP进行安全测试？

#

答：

数据存储安全： 检查敏感数据（密码、token）是否明文存储在本地（SharedPreferences、数据库、文件中）。

传输安全： 网络请求是否使用HTTPS，且证书校验是否严格（防止中间人攻击）。

代码混淆： 是否开启了Proguard（Android）或代码混淆，增加反编译难度。

日志泄露： 发布版本是否关闭了Debug日志，防止敏感信息通过logcat泄露。

组件暴露： Android的Activity、Service等组件是否被不必要的导出。

WebView漏洞： 是否忽略了SSL证书错误、是否允许执行JavaScript等。

# 23. 如何抓取和分析APP的网络数据包？

#

答：

工具： Charles 和 Fiddler 是最常用的抓包代理工具。

设置步骤： PC和手机连接到同一Wi-Fi。 在PC上设置代理工具的代理端口（如8888）。 在手机Wi-Fi设置中，手动配置代理服务器为PC的IP地址和端口。 在手机上安装并信任代理工具的CA证书（否则无法抓取HTTPS请求）。

PC和手机连接到同一Wi-Fi。

在PC上设置代理工具的代理端口（如8888）。

在手机Wi-Fi设置中，手动配置代理服务器为PC的IP地址和端口。

在手机上安装并信任代理工具的CA证书（否则无法抓取HTTPS请求）。

分析： 可以查看请求URL、方法、请求头、请求参数、响应状态码、响应头和响应体，用于调试接口、排查问题、模拟弱网和Mock数据。

# 24. 除了Charles，你还了解哪些移动端测试工具？

#

答：

性能监控： Android Studio Profiler (CPU, Memory, Network), Xcode Instruments, PerfDog (腾讯，跨平台)。

UI自动化： Appium (跨平台), Android UIAutomator (Android), Espresso (Android), XCUITest (iOS)。

云测平台： Testin, WeTest, Firebase Test Lab, AWS Device Farm。

专项测试： GT (腾讯)， iTest。

# 25. 什么是Monkey和MonkeyRunner？它们有什么区别？

#

答：

Monkey： 是一个命令行工具，向设备发送随机的用户事件流，用于进行压力测试。adb shell monkey -p your.package.name 500

adb shell monkey -p your.package.name 500

MonkeyRunner： 是一个API工具包，用于编写Python脚本在PC端控制Android设备或模拟器，完成自动化测试（如安装APP、运行测试、截图）。它比Monkey更可控。

区别： Monkey是随机的，用于稳定性；MonkeyRunner是可控的，用于自动化。

# 26. 如何测试APP的离线功能？

#

答： 测试APP在无网络情况下是否能提供基本服务。

有缓存内容： 如新闻APP，之前加载的文章、图片能否离线浏览。

无缓存内容： 页面是否有明确的“无网络”提示，而不是一直Loading或白屏。

操作队列： 对于表单提交等操作，在离线时操作是否被保存在本地，待有网络后自动同步提交（如邮箱的草稿箱）。

# 27. 如何测试APP与手机其他应用的交互？

#

答：

分享功能： 测试APP能否调起系统分享菜单，分享内容到其他App（微信、微博），并且分享的内容正确。

第三方登录： 测试微信、QQ等第三方登录能否正常调起和回调，并成功登录。

支付： 测试调起支付宝、微信支付等SDK是否正常。

地图： 测试调起高德、百度地图并定位是否正确。

文件选择： 测试从相册选择图片、从文件管理器选择文件等功能。

# 28. 描述一个你遇到的最复杂的APP Bug及其排查过程。

#

答： (这是一个行为面试题，需根据STAR原则准备)

情境(Situation)： 例如“在电商APP的支付环节，偶现性支付成功后订单状态未更新”。

任务(Task)： 需要稳定复现并定位这个严重Bug。

行动(Action)： 复现： 尝试在不同设备、网络下操作，最终发现只在弱网下特定操作时序下复现。 抓包： 使用Charles抓取支付成功前后的所有API请求，发现支付成功后，客户端有时收不到服务端的成功回调通知。 查日志： 结合客户端日志（Logcat）和服务端日志，发现是弱网导致客户端发出的确认接收回调（ACK）包丢失，服务端认为客户端未成功，故未更新订单状态。 定位： 根本原因是客户端对关键网络请求缺乏重试机制，服务端状态机设计不够健壮。

复现： 尝试在不同设备、网络下操作，最终发现只在弱网下特定操作时序下复现。

抓包： 使用Charles抓取支付成功前后的所有API请求，发现支付成功后，客户端有时收不到服务端的成功回调通知。

查日志： 结合客户端日志（Logcat）和服务端日志，发现是弱网导致客户端发出的确认接收回调（ACK）包丢失，服务端认为客户端未成功，故未更新订单状态。

定位： 根本原因是客户端对关键网络请求缺乏重试机制，服务端状态机设计不够健壮。

结果(Result)： 推动开发增加了请求重试机制和服务端超时补偿逻辑，修复了Bug，并为此类场景补充了测试用例。

# 29. APP上线后，如何进行质量监控？

#

答：

崩溃监控： 集成Crashlytics/Bugly，实时监控崩溃率和TOP崩溃栈，快速响应。

性能监控： 监控APP启动时间、页面加载耗时、卡顿率等关键性能指标。

业务监控： 监控核心业务转化率（如下单成功率、支付成功率）是否有异常下跌。

用户反馈： 密切关注应用商店评论、客服反馈渠道。

日志分析： 建立日志平台，对关键错误进行监控和告警。

# 四.H5测试

#

# 1. H5页面测试与Native App页面测试的主要区别是什么？

#

答： 主要区别在于技术本质、发布方式和测试重心。

技术本质： H5基于Web技术（HTML5, CSS3, JavaScript），运行在浏览器或WebView中；Native App基于原生技术（Java/Kotlin, Objective-C/Swift），直接运行在操作系统上。

发布方式： H5页面更新只需部署服务器端，用户无感知；Native App更新需要发版到应用市场，并需用户手动下载安装。

测试重心： H5： 更侧重浏览器兼容性（不同厂商、不同内核的浏览器）、网络性能（加载、缓存、弱网）、WebView兼容性及与Native的交互通信。 Native： 更侧重设备兼容性（分辨率、OS版本、厂商ROM）、安装/卸载/升级、性能（CPU、内存、电量、流量）及系统交互（权限、通知、深层链接）。

H5： 更侧重浏览器兼容性（不同厂商、不同内核的浏览器）、网络性能（加载、缓存、弱网）、WebView兼容性及与Native的交互通信。

Native： 更侧重设备兼容性（分辨率、OS版本、厂商ROM）、安装/卸载/升级、性能（CPU、内存、电量、流量）及系统交互（权限、通知、深层链接）。

# 2. 什么是Hybrid App？如何对它进行测试？

#

答： Hybrid App（混合模式应用）是兼具Native和H5特点的应用，外壳是Native，内部部分内容由H5页面承载。

测试方法： 需要从Native和H5两个维度进行测试：

Native部分： 按Native App方法测试安装、卸载、权限、性能、系统交互等。 H5部分： 按Web方法测试页面功能、UI、兼容性。 混合核心： 交互桥梁： 测试JS Bridge（JavaScript与Native代码通信）是否稳定可靠。 页面切换： 测试Native页面与H5页面之间的跳转是否流畅，导航栏、返回键行为是否正确。 资源加载： 测试H5页面的加载速度及离线资源包机制（如果有）。

Native部分： 按Native App方法测试安装、卸载、权限、性能、系统交互等。

H5部分： 按Web方法测试页面功能、UI、兼容性。

混合核心： 交互桥梁： 测试JS Bridge（JavaScript与Native代码通信）是否稳定可靠。 页面切换： 测试Native页面与H5页面之间的跳转是否流畅，导航栏、返回键行为是否正确。 资源加载： 测试H5页面的加载速度及离线资源包机制（如果有）。

交互桥梁： 测试JS Bridge（JavaScript与Native代码通信）是否稳定可靠。

页面切换： 测试Native页面与H5页面之间的跳转是否流畅，导航栏、返回键行为是否正确。

资源加载： 测试H5页面的加载速度及离线资源包机制（如果有）。

# 3. 在Hybrid App中，如何测试H5页面与Native之间的交互（JS Bridge）？

#

答： 这是Hybrid App测试的核心。

功能测试： 覆盖所有JS Bridge提供的API调用场景。例如：

调用Native的分享、支付、获取用户信息、扫描二维码等功能。 验证Native调用H5的回调函数（如将扫描结果回传给H5页面）。

调用Native的分享、支付、获取用户信息、扫描二维码等功能。

验证Native调用H5的回调函数（如将扫描结果回传给H5页面）。

异常测试： 模拟Native方法不存在或失败时，H5页面是否有降级方案或友好提示。 网络异常时，通信是否稳定。

模拟Native方法不存在或失败时，H5页面是否有降级方案或友好提示。

网络异常时，通信是否稳定。

安全测试： 验证Native端对H5调用的来源是否有安全校验，防止恶意页面调用。

# 4. H5页面性能测试关注哪些核心指标？

#

答： 关注Web标准的核心用户体验指标（Core Web Vitals）：

LCP (Largest Contentful Paint)： 最大内容绘制时间，衡量加载速度。应小于2.5秒。

FID (First Input Delay)： 首次输入延迟，衡量交互响应度。应小于100毫秒。

CLS (Cumulative Layout Shift)： 累计布局偏移，衡量视觉稳定性。应小于0.1。

此外，还包括FCP (First Contentful Paint)、TTI (Time to Interactive) 等传统指标。

# 5. 如何分析并优化一个加载缓慢的H5页面？

#

答： 这是一个考察实战经验的问题。

定位瓶颈： 使用Chrome DevTools的 Network 面板查看资源加载瀑布图（Waterfall），找出加载耗时最长的资源（大的图片、JS、CSS文件）或TTFB（Time to First Byte）过长的API请求。

使用Lighthouse/Audits面板： 生成性能报告，它会直接给出优化建议，例如：

优化资源： 压缩图片（WebP格式）、启用Brotli/Gzip压缩、代码分割（Code Splitting）、移除未使用的CSS/JS。 减少请求： 合并小文件、使用HTTP/2、合理配置缓存策略（Cache-Control, ETag）。 优化加载顺序： 延迟加载非关键资源（懒加载）、异步加载JavaScript（async/defer）、优化关键渲染路径。

优化资源： 压缩图片（WebP格式）、启用Brotli/Gzip压缩、代码分割（Code Splitting）、移除未使用的CSS/JS。

减少请求： 合并小文件、使用HTTP/2、合理配置缓存策略（Cache-Control, ETag）。

优化加载顺序： 延迟加载非关键资源（懒加载）、异步加载JavaScript（async/defer）、优化关键渲染路径。

性能打分： 根据Lighthouse的建议逐一优化，直到性能评分达到预期。

# 6. H5兼容性测试主要覆盖哪些方面？

#

答：

浏览器内核： 主要覆盖 WebKit (iOS Safari、老版本Android浏览器)、Blink (Chrome、新版Edge、大多数Android手机内置浏览器)、Gecko (Firefox)。

操作系统： iOS和Android的不同版本。

屏幕尺寸与分辨率： 测试页面在不同尺寸的手机、平板上的响应式布局是否正常。

微信/支付宝等内置浏览器： 这些超级App的内置浏览器（X5内核等）可能存在特殊兼容性问题，必须重点测试。

# 7. 如何高效地进行H5页面的兼容性测试？

#

答：

云测试平台： 使用 BrowserStack、Sauce Labs、LambdaTest 等平台，可以快速在大量真实浏览器和移动设备上运行测试。

开发者工具模拟： 使用Chrome DevTools的设备模式（Device Mode）模拟不同设备型号和分辨率，进行初步验证。

真机测试： 覆盖团队持有的主流iOS和Android真机。

聚焦重点： 根据用户数据分析，优先测试用户量最大的浏览器和机型。

# 8. 如何测试H5页面的离线功能？

#

答： 离线功能通常通过Service Worker和Cache API实现。

测试策略： 在网络正常的情况下首次访问页面，加载资源。 在开发者工具的 Application -> Service Workers 中查看SW是否成功注册和激活。 在 Application -> Cache Storage 中查看所需资源是否已被缓存。 关闭网络（模拟离线），刷新页面或进行跳转。 验证：之前访问过的页面是否能正常显示和操作；未访问过的页面或API请求是否有合理的“无网络”提示。

在网络正常的情况下首次访问页面，加载资源。

在开发者工具的 Application -> Service Workers 中查看SW是否成功注册和激活。

在 Application -> Cache Storage 中查看所需资源是否已被缓存。

关闭网络（模拟离线），刷新页面或进行跳转。

验证：之前访问过的页面是否能正常显示和操作；未访问过的页面或API请求是否有合理的“无网络”提示。

# 9. 在移动端测试H5页面，有哪些特有的测试点？

#

答：

手势操作： 测试单指/多指触摸、滑动、长按、双击缩放等手势是否响应正确且流畅。

滚动性能： 测试页面滚动是否跟手，有无白屏、卡顿现象。

键盘交互： 输入框聚焦时，键盘弹出是否会遮挡输入区域；收起键盘后，页面布局是否正确恢复。

状态栏与安全区域： 在全面屏设备上，页面内容是否避开了刘海和底部Home条指示器（Safe Area）。

微信等环境： 在微信内打开时，需测试分享卡片、JSSDK授权等功能是否正常。

# 10. 如何抓取和分析H5页面的网络请求？

#

答： 方法与Web测试相同。

工具： Charles 或 Fiddler 是最常用的抓包代理工具。

步骤： 确保PC和手机在同一局域网。 在PC上设置代理工具并开启代理（如端口8888）。 在手机Wi-Fi设置中手动配置代理服务器为PC的IP和端口。 在手机上安装并信任Charles/Fiddler的CA证书（以解密HTTPS流量）。

确保PC和手机在同一局域网。

在PC上设置代理工具并开启代理（如端口8888）。

在手机Wi-Fi设置中手动配置代理服务器为PC的IP和端口。

在手机上安装并信任Charles/Fiddler的CA证书（以解密HTTPS流量）。

分析： 可以查看所有HTTP/HTTPS请求的URL、方法、请求头、请求体、响应状态码、响应头和响应体，用于调试接口、模拟慢网络、Mock数据。

# 11. 什么是PWA（渐进式Web应用）？它的测试重点是什么？

#

答： PWA是一种可以提供类似Native App体验的Web应用。

测试重点： 核心PWA特性： Service Worker（离线、后台同步）、Web App Manifest（添加至桌面、启动动画、主题色）。 可安装性： 是否满足可安装条件，并能成功“添加至主屏幕”。 离线体验： 测试其在离线状态下的功能完备性。 推送通知（Push Notification）： 如果支持，需测试通知的接收和点击跳转。

核心PWA特性： Service Worker（离线、后台同步）、Web App Manifest（添加至桌面、启动动画、主题色）。

可安装性： 是否满足可安装条件，并能成功“添加至主屏幕”。

离线体验： 测试其在离线状态下的功能完备性。

推送通知（Push Notification）： 如果支持，需测试通知的接收和点击跳转。

# 12. H5安全测试需要关注哪些常见漏洞？

#

答：

跨站脚本（XSS）： 最常见。在输入框等地方尝试注入 <script>alert('XSS')</script> 等脚本，看是否会执行。

<script>alert('XSS')</script>

跨站请求伪造（CSRF）： 诱使用户在不知情时执行非本意的操作。测试关键操作（如修改密码）是否有CSRF Token等防护机制。

第三方依赖风险： 引用的第三方JS库可能存在已知安全漏洞，需定期扫描。

数据泄露： 确保敏感信息（token、用户数据）不会通过前端代码、日志、缓存等方式泄露。

# 13. 如何测试H5页面的响应式布局？

#

答：

工具模拟： 使用Chrome DevTools的设备工具栏（Device Toolbar），选择预设设备型号或自定义分辨率、像素密度（DPR）、旋转屏幕，观察布局变化。

真机测试： 在多种不同尺寸的真实手机和平板上进行测试，这是最可靠的方式。

测试点： 布局是否根据屏幕宽度自适应（如单列变多列）？ 文字大小、间距是否仍然可读？ 图片是否按比例缩放，会不会失真？ 导航栏（如是否变为汉堡菜单）、按钮等交互元素是否易于点击？

布局是否根据屏幕宽度自适应（如单列变多列）？

文字大小、间距是否仍然可读？

图片是否按比例缩放，会不会失真？

导航栏（如是否变为汉堡菜单）、按钮等交互元素是否易于点击？

# 14. 解释一下WebView，并说明测试时需要注意什么？

#

答： WebView是一个嵌入在Native App中的浏览器组件，用于渲染H5页面。

测试注意： 版本差异： 不同Android系统版本、不同厂商ROM的WebView内核版本和性能可能不同，是兼容性问题的重灾区。 缓存机制： WebView有独立的缓存，测试时需注意清理，或验证缓存策略是否正确。 与Native的通信： 如前所述，重点测试JS Bridge。 硬件加速： 是否开启会影响H5页面的渲染性能，需关注。

版本差异： 不同Android系统版本、不同厂商ROM的WebView内核版本和性能可能不同，是兼容性问题的重灾区。

缓存机制： WebView有独立的缓存，测试时需注意清理，或验证缓存策略是否正确。

与Native的通信： 如前所述，重点测试JS Bridge。

硬件加速： 是否开启会影响H5页面的渲染性能，需关注。

# 15. 如何模拟H5页面在弱网环境下的表现？

#

答：

浏览器工具： Chrome DevTools的Network面板可以直接设置Online为Slow 3G或Offline。

代理工具： 在Charles或Fiddler中设置Throttling（节流），自定义带宽（Bandwidth）、延迟（Latency）、丢包率（Packet Loss）来模拟各种弱网场景。

测试点： 页面加载时间、超时机制、加载中状态提示、操作响应、断网重连后的恢复能力。

# 16. 什么是“白屏”问题？可能的原因有哪些？如何排查？

#

答： “白屏”是指浏览器或WebView无法正常渲染页面内容。

可能原因： JS错误： 主要的JS文件加载失败或执行报错，阻塞了页面渲染。 资源加载失败： 关键CSS或JS文件因网络等原因未加载。 兼容性问题： 代码使用了当前浏览器/WebView不支持的API。

JS错误： 主要的JS文件加载失败或执行报错，阻塞了页面渲染。

资源加载失败： 关键CSS或JS文件因网络等原因未加载。

兼容性问题： 代码使用了当前浏览器/WebView不支持的API。

排查方法： 打开浏览器/WebView的开发者工具（安卓需要启用WebView调试）。 查看Console面板，寻找红色错误信息，这是最直接的线索。 查看Network面板，确认所有资源是否都返回了200（成功）。

打开浏览器/WebView的开发者工具（安卓需要启用WebView调试）。

查看Console面板，寻找红色错误信息，这是最直接的线索。

查看Network面板，确认所有资源是否都返回了200（成功）。

# 17. H5页面的缓存机制有哪些？测试时如何清理？

#

答：

缓存类型： HTTP缓存： 通过Cache-Control、Expires等HTTP头控制。 Data Storage： LocalStorage, SessionStorage, Cookie, IndexedDB。 Application Cache (已废弃) / Service Worker Cache。

HTTP缓存： 通过Cache-Control、Expires等HTTP头控制。

Data Storage： LocalStorage, SessionStorage, Cookie, IndexedDB。

Application Cache (已废弃) / Service Worker Cache。

清理方法： 浏览器： 开发者工具的Application面板中可以清除各种存储和缓存。 Hybrid App： 需要清除App的缓存数据（iOS卸载重装或设置中清理，Android应用管理中清理缓存）。

浏览器： 开发者工具的Application面板中可以清除各种存储和缓存。

Hybrid App： 需要清除App的缓存数据（iOS卸载重装或设置中清理，Android应用管理中清理缓存）。

# 18. 如何测试H5页面在微信浏览器中的兼容性？

#

答： 微信浏览器（X5内核）是一个必须重点测试的特殊环境。

测试点： 功能正常性： 所有基础功能、交互在微信内是否正常。 授权登录： 微信授权登录流程是否畅通。 JSSDK： 使用微信JSSDK的功能（分享、支付、拍照等）是否正常。 样式兼容： 页面样式在X5内核中是否有错乱。 路由问题： 微信浏览器对SPA（单页应用）的路由History模式支持可能有问题，需注意。

功能正常性： 所有基础功能、交互在微信内是否正常。

授权登录： 微信授权登录流程是否畅通。

JSSDK： 使用微信JSSDK的功能（分享、支付、拍照等）是否正常。

样式兼容： 页面样式在X5内核中是否有错乱。

路由问题： 微信浏览器对SPA（单页应用）的路由History模式支持可能有问题，需注意。

# 19. 在设计H5页面的测试用例时，与Native用例设计最大的不同是什么？

#

答： 最大的不同在于兼容性测试用例的广度和深度。

Native用例更关注功能与系统设备的交互。

H5用例必须在功能的基础上，乘以浏览器环境和网络环境这两个巨大的变量。需要为同一个功能点设计在不同浏览器、不同版本、不同网络条件下的测试场景，用例数量和复杂度呈指数级增长。

# 20. 描述一个你遇到的印象最深刻的H5相关Bug及其排查过程。

#

答： (这是一个行为面试题，请用STAR原则准备你自己的案例)

情境(Situation)： “在某个Hybrid App中，iOS设备上某个H5页面输入框无法聚焦，而Android正常。”

任务(Task)： 需要找出iOS上失效的原因并推动解决。

行动(Action)： 隔离： 编写最简HTML页面复现问题，排除业务代码干扰。 排查： 通过Safari的Web检查器（连接到iPhone）调试，发现页面某个透明遮罩层覆盖在了输入框上方，阻止了点击事件。 深究： 进一步排查CSS，发现这个遮罩层在Android和大部分浏览器上有个pointer-events: none;的属性，使其可被穿透点击。但在iOS老版本Safari的某些环境下，该属性支持不佳。 解决： 提出解决方案：调整图层层级或改用其他方式实现遮罩。

隔离： 编写最简HTML页面复现问题，排除业务代码干扰。

排查： 通过Safari的Web检查器（连接到iPhone）调试，发现页面某个透明遮罩层覆盖在了输入框上方，阻止了点击事件。

深究： 进一步排查CSS，发现这个遮罩层在Android和大部分浏览器上有个pointer-events: none;的属性，使其可被穿透点击。但在iOS老版本Safari的某些环境下，该属性支持不佳。

pointer-events: none;

解决： 提出解决方案：调整图层层级或改用其他方式实现遮罩。

结果(Result)： 问题得以修复，并总结了经验：CSS属性的兼容性需要特别关注，并为此类问题增加了测试用例。

# 五.小程序测试

#

# 1. 小程序测试与原生App测试、H5测试的主要区别是什么？

#

答： 核心区别在于技术架构和运行环境。

与原生App： 技术： 小程序基于Web技术（JS+CSS+WXML+WXSS），但运行在特定容器（如微信）中，而非操作系统原生环境。 分发： 无需安装，即用即走，通过扫码或搜索即可打开。 权限： 能力受限于微信等平台提供的API，系统权限调用需通过平台授权。

技术： 小程序基于Web技术（JS+CSS+WXML+WXSS），但运行在特定容器（如微信）中，而非操作系统原生环境。

分发： 无需安装，即用即走，通过扫码或搜索即可打开。

权限： 能力受限于微信等平台提供的API，系统权限调用需通过平台授权。

与H5： 性能： 小程序体验更接近Native，因UI组件是原生渲染，且资源包本地化，加载更快。 能力： 小程序能调用更多平台原生能力（如微信登录、支付、分享）。 环境： 运行在封闭的沙盒环境中，无法使用浏览器DOM API等。

性能： 小程序体验更接近Native，因UI组件是原生渲染，且资源包本地化，加载更快。

能力： 小程序能调用更多平台原生能力（如微信登录、支付、分享）。

环境： 运行在封闭的沙盒环境中，无法使用浏览器DOM API等。

# 2. 小程序的“双线程架构”是什么？它对测试有什么影响？

#

答： 小程序采用逻辑层（App Service）和视图层（WebView）分离的双线程模型，通过JSBridge进行通信。

影响： 数据驱动： 数据变化需通过 setData 方法从逻辑层异步传递到视图层，测试需关注数据同步的及时性和正确性。 性能瓶颈： setData 传递大量数据是主要性能瓶颈，测试需关注由此引发的页面卡顿。 通信异常： 需测试两线程通信失败时的异常处理（如视图层加载失败）。

数据驱动： 数据变化需通过 setData 方法从逻辑层异步传递到视图层，测试需关注数据同步的及时性和正确性。

setData

性能瓶颈： setData 传递大量数据是主要性能瓶颈，测试需关注由此引发的页面卡顿。

setData

通信异常： 需测试两线程通信失败时的异常处理（如视图层加载失败）。

# 3. 小程序测试需要覆盖哪些主要的业务场景？

#

答：

核心功能： 主业务流程（如电商小程序的浏览-加购-下单-支付）。

平台集成： 授权： 微信登录、用户信息授权、手机号授权。 支付： 微信支付流程。 分享： 分享给好友、分享到朋友圈、分享卡片自定义。 消息： 模板消息下发与点击。

授权： 微信登录、用户信息授权、手机号授权。

支付： 微信支付流程。

分享： 分享给好友、分享到朋友圈、分享卡片自定义。

消息： 模板消息下发与点击。

入口场景： 通过扫码、公众号菜单、聊天会话、搜索等多种入口进入小程序的场景。

生命周期： 前台、后台、销毁等状态切换时的逻辑。

# 4. 如何测试小程序的授权登录功能？

#

答：

首次授权： 测试弹窗提示、允许授权后是否能成功获取用户信息并登录。

拒绝授权： 测试拒绝后小程序是否有友好提示和引导重新授权的路径。

已授权用户： 再次进入小程序时，应实现静默登录，无需重复授权。

清除授权： 在微信设置中“清除授权”，测试再次进入小程序时的表现。

兼容性： 测试在不同微信版本下授权逻辑的一致性。

# 5. 小程序兼容性测试需要关注哪些维度？

#

答：

微信版本： 不同微信版本提供的基础库版本和能力不同，是测试重点。需覆盖主流版本和最低支持版本。

操作系统： iOS和Android的差异，以及不同厂商ROM（如小米、华为）的WebView内核差异。

屏幕尺寸： 适配不同手机尺寸，特别是全面屏、折叠屏等。

小程序基础库版本： 在微信开发者工具中可以设置不同的基础库版本进行测试，确保在小程序设置的最低基础库版本上功能正常。

# 6. 如何测试小程序的网络兼容性与弱网体验？

#

答：

网络切换： 测试Wi-Fi与移动数据切换时，小程序请求能否正常重连。

弱网模拟： 使用Charles、Fiddler等工具模拟高延迟、高丢包、低带宽的网络环境。

测试点： 页面加载是否有明确的Loading提示，而非白屏。 请求超时是否有友好提示，并提供重试机制。 在弱网下进行提交操作（如支付），要防止重复提交。

页面加载是否有明确的Loading提示，而非白屏。

请求超时是否有友好提示，并提供重试机制。

在弱网下进行提交操作（如支付），要防止重复提交。

# 7. 小程序性能测试关注哪些核心指标？

#

答：

启动性能： 首次启动时间： 下载小程序包后第一次启动的耗时。 再次启动时间： 冷启动（小程序已被销毁）和热启动的耗时。

首次启动时间： 下载小程序包后第一次启动的耗时。

再次启动时间： 冷启动（小程序已被销毁）和热启动的耗时。

运行时性能： 页面渲染时间： 页面主要内容渲染完成的时间。 CPU/内存占用： 避免长时间操作导致卡顿或客户端崩溃。 setData效率： 避免一次传递过大或过频繁的数据。

页面渲染时间： 页面主要内容渲染完成的时间。

CPU/内存占用： 避免长时间操作导致卡顿或客户端崩溃。

setData效率： 避免一次传递过大或过频繁的数据。

包体积： 主包和子包的大小是否超出平台限制（主包目前限制为2M）。

# 8. 如何分析并优化小程序的启动速度？

#

答：

定位瓶颈： 使用微信开发者工具的“Audits”或“性能”面板监控启动过程。

优化手段： 减少包体积： 压缩代码和图片、移除未使用的代码和库、使用分包加载。 优化代码执行： 减少 App() 和 Page() 生命周期函数中的同步逻辑，延迟执行非必要操作。 预加载策略： 合理使用预下载子包策略。 缓存策略： 利用本地缓存减少首次加载的请求数。

减少包体积： 压缩代码和图片、移除未使用的代码和库、使用分包加载。

优化代码执行： 减少 App() 和 Page() 生命周期函数中的同步逻辑，延迟执行非必要操作。

App()

Page()

预加载策略： 合理使用预下载子包策略。

缓存策略： 利用本地缓存减少首次加载的请求数。

# 9. 小程序的安全测试需要关注哪些方面？

#

答：

越权操作： 前端校验不可信，后端必须对每个请求进行用户身份和权限校验。

敏感信息泄露： 检查是否在前端代码、存储或通信中硬编码或泄露了AppSecret、API密钥等。

HTTPS： 确保所有网络请求使用HTTPS。

平台API滥用： 如对 wx.request 请求的URL未做严格校验，可能导致SSRF（服务器端请求伪造）。

wx.request

WebView漏洞： 若内嵌WebView，需注意XSS、URL校验等问题。

反编译： 小程序包可被反编译，需避免在代码中存储核心业务逻辑和敏感数据。

# 10. 如何测试小程序与微信原生功能的交互？例如分享功能。

#

答：

分享功能测试点： 自定义分享内容： 测试分享卡片上的标题、图片、路径是否设置正确。 分享路径： 分享出去的卡片被点击后，能否正确跳转到指定页面并携带预期参数。 不同分享目标： 分享给好友、群聊、朋友圈的表现是否一致。 回调函数： 测试成功和失败的回调处理。

自定义分享内容： 测试分享卡片上的标题、图片、路径是否设置正确。

分享路径： 分享出去的卡片被点击后，能否正确跳转到指定页面并携带预期参数。

不同分享目标： 分享给好友、群聊、朋友圈的表现是否一致。

回调函数： 测试成功和失败的回调处理。

# 11. 解释一下小程序的分包加载机制，测试时需要注意什么？

#

答： 分包加载允许将小程序分成一个主包和多个子包，按需加载，优化首次启动速度。

测试注意： 功能正确性： 进入子包页面时，功能是否正常，资源是否加载正确。 依赖关系： 主包与子包、子包与子包之间的公共JS模块引用是否正确。 预加载配置： 在 app.json 中配置的 preloadRule 是否生效，预加载时机是否合理，是否会影响主包性能。 包大小限制： 每个子包的大小限制（目前为2M）。

功能正确性： 进入子包页面时，功能是否正常，资源是否加载正确。

依赖关系： 主包与子包、子包与子包之间的公共JS模块引用是否正确。

预加载配置： 在 app.json 中配置的 preloadRule 是否生效，预加载时机是否合理，是否会影响主包性能。

app.json

preloadRule

包大小限制： 每个子包的大小限制（目前为2M）。

# 12. 小程序有哪些常见的数据存储方式？如何测试？

#

答：

同步/异步存储： wx.setStorageSync / wx.setStorage 测试： 存储后立即读取、重启小程序后读取、清除微信缓存后读取（数据应被清除）、存储不同数据类型、存储空间不足时的处理。

wx.setStorageSync

wx.setStorage

测试： 存储后立即读取、重启小程序后读取、清除微信缓存后读取（数据应被清除）、存储不同数据类型、存储空间不足时的处理。

云开发数据库： 对于使用云开发的小程序。

测试： 增删改查权限设置（安全规则）是否正确，数据一致性。

测试： 增删改查权限设置（安全规则）是否正确，数据一致性。

# 13. 如何测试小程序的后台运行和前台唤醒？

#

答：

切到后台： 按Home键或切换到其他应用，测试小程序是否执行了 onHide 生命周期，定时器等是否暂停。

onHide

唤醒到前台： 重新打开小程序，测试是否触发 onShow，页面状态和数据是否正确恢复。

onShow

长时间后台： 将小程序置于后台较长时间（如30分钟），再唤醒，测试是否可能被系统销毁并重新加载。

# 14. 小程序云开发（TCB）测试与传统后端测试有何不同？

#

答：

焦点转移： 测试重点从服务器运维和接口测试，转移到云函数的业务逻辑测试和数据库安全规则的测试上。

安全规则测试： 这是重中之重。需模拟不同用户身份，测试其是否只能读写权限允许的数据（如：用户只能读写自己的数据）。

云函数测试： 可以在云端和本地测试云函数的逻辑、输入和输出。

# 15. 你使用哪些工具进行小程序测试和调试？

#

答：

官方工具： 微信开发者工具：用于开发、调试、预览、真机调试、性能分析、Audits体验评分。

抓包工具： Charles / Fiddler：用于抓取和分析小程序网络请求，模拟弱网，Mock数据。

云测平台： WeTest（腾讯质量开放平台）：提供大量真机兼容性测试服务。

自动化工具： Minium：微信官方提供的小程序自动化测试框架。

# 16. 什么是Minium？它有什么特点？

#

答： Minium是微信官方提供的小程序自动化测试框架。

特点： 支持Python和JavaScript。 支持多种驱动模式（IDE、HTTP、云测），可在Windows、Mac、Linux上运行。 提供丰富的API（Mock、断言、元素操作、模拟用户输入）。 可以直接操作小程序的页面和组件，比纯UI自动化更稳定。

支持Python和JavaScript。

支持多种驱动模式（IDE、HTTP、云测），可在Windows、Mac、Linux上运行。

提供丰富的API（Mock、断言、元素操作、模拟用户输入）。

可以直接操作小程序的页面和组件，比纯UI自动化更稳定。

# 17. 如何对小程序进行线上监控与异常排查？

#

答：

后台监控： 使用小程序管理后台查看“运营数据”和“实时日志”。

运营数据： 监控UV、PV、停留时长、页面路径等，发现异常下跌。 实时日志： 通过 wx.getRealtimeLogManager 输出日志，排查线上问题。

运营数据： 监控UV、PV、停留时长、页面路径等，发现异常下跌。

实时日志： 通过 wx.getRealtimeLogManager 输出日志，排查线上问题。

wx.getRealtimeLogManager

异常监控： 性能监控： 监控启动耗时、页面渲染耗时、请求成功率等（需自行埋点或使用第三方服务）。 错误监控： 使用 wx.onError 捕获JS错误，并上报到监控平台。

性能监控： 监控启动耗时、页面渲染耗时、请求成功率等（需自行埋点或使用第三方服务）。

错误监控： 使用 wx.onError 捕获JS错误，并上报到监控平台。

wx.onError

用户反馈： 鼓励用户通过小程序内置反馈入口提交问题，并附上联系方式和截图。

# 18. 测试小程序时，如何管理多个测试环境（开发/测试/生产）？

#

答：

小程序配置： 在微信开发者工具和 project.config.json 中配置不同的环境（如：dev, staging, prod）。

project.config.json

dev

staging

prod

API域名： 根据编译环境，动态设置请求的API域名（通常通过环境变量或自定义编译条件实现）。

测试数据： 为不同环境准备独立的测试数据库，避免数据污染。

二维码： 为每个环境生成独立的体验版二维码，并清晰标记，避免测试人员扫错。

# 19. 小程序提审和发布前，需要进行哪些检查？

#

答： （可称为发布Checklist）

[ ] 核心功能流程测试通过。

[ ] 体验版在iOS和Android真机上全面测试通过。

[ ] 页面在不同尺寸屏幕上的UI适配正常。

[ ] 所有文本内容无错别字。

[ ] 导航栏、TabBar等配置正确。

[ ] 分享功能配置正确。

[ ] 已设置最低基础库版本，并已兼容。

[ ] 服务类目选择正确。

[ ] 隐私政策弹窗（如有收集用户信息）已配置。

[ ] 已清理所有测试代码和调试日志。

# 20. 描述一个你在小程序测试中遇到的最复杂/最有成就感的Bug。

#

答： (这是一个行为面试题，请用STAR原则准备你自己的案例)

情境(Situation)： “在某个电商小程序的商品详情页，iOS用户偶现点击‘立即购买’无反应，Android正常。”

任务(Task)： 需要定位这个难以复现的iOS特定Bug。

行动(Action)： 复现： 使用多台iOS设备尝试，最终在某台设备上稳定复现。 排查： 使用微信开发者工具的真机调试功能，在复现的手机上实时查看Console日志和WXML元素。 定位： 发现点击事件被一个透明的、用于实现某种动画效果的<view>组件拦截了。这个组件在Android上 pointer-events: none; 属性生效，可穿透点击；但在iOS特定版本下，该属性失效。 解决： 提出修改方案：调整图层层级或改用其他CSS属性实现。

复现： 使用多台iOS设备尝试，最终在某台设备上稳定复现。

排查： 使用微信开发者工具的真机调试功能，在复现的手机上实时查看Console日志和WXML元素。

定位： 发现点击事件被一个透明的、用于实现某种动画效果的<view>组件拦截了。这个组件在Android上 pointer-events: none; 属性生效，可穿透点击；但在iOS特定版本下，该属性失效。

<view>

pointer-events: none;

解决： 提出修改方案：调整图层层级或改用其他CSS属性实现。

结果(Result)： Bug得以修复，并总结了iOS与Android在CSS属性支持上的差异经验，为团队积累了知识库。

# 六.接口测试

#

# 1. 什么是接口测试？为什么要做接口测试？

#

答： 接口测试是测试系统组件间接口的一种测试，主要用于验证不同系统模块或服务之间的数据交换、传递和控制管理过程。

重要性： 早期介入： 可在UI未开发完成时进行，缩短项目周期。 高性价比： 接口Bug修复成本远低于后期UI层修复的成本。 定位精准： 能更快速、准确地定位是前端还是后端问题。 覆盖全面： 可覆盖一些UI测试无法覆盖的场景（如异常参数、性能瓶颈）。 系统安全： 是保障系统安全的第一道重要防线。

早期介入： 可在UI未开发完成时进行，缩短项目周期。

高性价比： 接口Bug修复成本远低于后期UI层修复的成本。

定位精准： 能更快速、准确地定位是前端还是后端问题。

覆盖全面： 可覆盖一些UI测试无法覆盖的场景（如异常参数、性能瓶颈）。

系统安全： 是保障系统安全的第一道重要防线。

# 2. 请列举常见的接口类型。

#

答：

HTTP/HTTPS API (RESTful / RESTless)： 最常见的基于Web的接口。

RPC (Remote Procedure Call)： 如 gRPC, Dubbo， 性能更高，常用于微服务内部调用。

WebService (SOAP)： 基于XML，协议较重，常见于传统企业级应用。

GraphQL： 一种查询语言，允许客户端精确指定需要的数据，避免了Over-fetching和Under-fetching。

# 3. 什么是RESTful API？它的核心原则是什么？

#

答： RESTful API是一种基于HTTP协议，遵循REST（Representational State Transfer）架构风格的API设计规范。

核心原则： 无状态（Stateless）： 每次请求都必须包含处理该请求所需的所有信息。 统一接口（Uniform Interface）： 使用标准的HTTP方法（GET, POST, PUT, DELETE等）对资源进行操作。 资源导向（Resource-Based）： 将数据或服务抽象为资源，每个资源有唯一的URI（如 /users/123）。 可缓存（Cachable）： 响应应明确表明是否可缓存，以提高性能。 分层系统（Layered System）： 客户端无需关心是否直接连接最终服务器。

无状态（Stateless）： 每次请求都必须包含处理该请求所需的所有信息。

统一接口（Uniform Interface）： 使用标准的HTTP方法（GET, POST, PUT, DELETE等）对资源进行操作。

资源导向（Resource-Based）： 将数据或服务抽象为资源，每个资源有唯一的URI（如 /users/123）。

/users/123

可缓存（Cachable）： 响应应明确表明是否可缓存，以提高性能。

分层系统（Layered System）： 客户端无需关心是否直接连接最终服务器。

# 4. 请解释HTTP请求的组成。

#

答： 一个HTTP请求包含：

请求行（Request Line）： 包含请求方法（GET/POST等）、请求的URI、HTTP协议版本。

请求头（Request Headers）： 包含关于请求的元信息，如 Host, User-Agent, Content-Type, Authorization, Cookie。

Host

User-Agent

Content-Type

Authorization

Cookie

请求体（Request Body）： 可选，通常在POST、PUT等方法中携带发送给服务器的数据。

# 5. 请解释HTTP响应的组成。

#

答： 一个HTTP响应包含：

状态行（Status Line）： 包含HTTP协议版本、状态码（如200, 404）、状态消息（如OK, Not Found）。

响应头（Response Headers）： 包含关于响应的元信息，如 Content-Type, Content-Length, Set-Cookie, Server。

Content-Type

Content-Length

Set-Cookie

Server

响应体（Response Body）： 服务器返回的实际数据，如HTML、JSON、XML等。

# 6. 请列出常见的HTTP方法及其用途。

#

答：

GET： 请求获取指定的资源。应是幂等的（多次调用效果相同）。

POST： 向指定资源提交数据，请求服务器处理（例如创建新资源）。通常不是幂等的。

PUT： 向指定资源位置上传其最新内容（用于更新整个资源）。应是幂等的。

DELETE： 请求服务器删除指定的资源。

PATCH： 对资源进行局部更新（而非PUT的整体更新）。

# 7. 什么是幂等性（Idempotence）？哪些HTTP方法是幂等的？

#

答： 幂等性是指一次和多次请求某一个资源应该具有同样的副作用。

幂等方法： GET, PUT, DELETE, HEAD, OPTIONS。

非幂等方法： POST, PATCH。

测试意义： 测试幂等方法时，可以放心地重试请求而不用担心产生重复数据等意外后果。

# 8. 请解释常见的HTTP状态码及其含义。

#

答：

1xx (信息性)： 请求已被接收，继续处理。

2xx (成功)： 200 OK： 请求成功。 201 Created： 资源创建成功。 204 No Content： 请求成功，但无返回内容。

200 OK： 请求成功。

201 Created： 资源创建成功。

204 No Content： 请求成功，但无返回内容。

3xx (重定向)： 301 Moved Permanently： 资源被永久移动。 302 Found： 资源被临时移动。

301 Moved Permanently： 资源被永久移动。

302 Found： 资源被临时移动。

4xx (客户端错误)： 400 Bad Request： 请求语法错误。 401 Unauthorized： 需要身份验证。 403 Forbidden： 服务器理解请求但拒绝执行（无权限）。 404 Not Found： 资源不存在。

400 Bad Request： 请求语法错误。

401 Unauthorized： 需要身份验证。

403 Forbidden： 服务器理解请求但拒绝执行（无权限）。

404 Not Found： 资源不存在。

5xx (服务器错误)： 500 Internal Server Error： 服务器内部错误。 502 Bad Gateway： 网关或代理服务器从上游服务器收到无效响应。 503 Service Unavailable： 服务暂时不可用。

500 Internal Server Error： 服务器内部错误。

502 Bad Gateway： 网关或代理服务器从上游服务器收到无效响应。

503 Service Unavailable： 服务暂时不可用。

# 9. 请列举常见的接口参数类型。

#

答：

Query Parameters (查询参数)： 出现在URL ? 之后，如 /users?page=1&size=10。

?

/users?page=1&size=10

Path Parameters (路径参数)： 作为URL路径的一部分，如 /users/{userId}。

/users/{userId}

Request Body (请求体)： 通常在POST/PUT请求中，格式可以是JSON、XML、form-data等。

Headers (请求头)： 用于传递认证信息（如Token）、内容类型等。

# 10. 什么是Cookie和Session？它们在接口测试中如何体现？

#

答：

Cookie： 一小段存储在客户端的文本信息，每次请求时会自动携带。接口测试中，可通过抓包工具查看 Cookie 请求头，或使用工具管理Cookie。

Cookie

Session： 存储在服务器端的用户状态信息，通过一个唯一的Session ID来标识，该ID通常通过Cookie传递。

测试体现： 测试需要登录的接口时，通常先调用登录接口，获取服务器返回的Cookie/Session ID（或在响应头中以Token形式返回），然后在后续请求的Header中带上它（如 Authorization: Bearer <token> 或 Cookie: sessionid=xxx）。

Authorization: Bearer <token>

Cookie: sessionid=xxx

# 11. 什么是Token（常用于JWT）？它与Session的区别是什么？

#

答：

Token (如JWT)： 一个自包含的令牌，其中编码了用户身份等信息，通常由服务器签发，客户端保存并在后续请求中携带。服务器无需保存会话状态，仅需验证Token的有效性即可。

区别： 存储位置： Session存储在服务器端，Token存储在客户端。 扩展性： Token更适合分布式架构，因为它是无状态的；Session在集群环境下需要做共享。 安全性： Token一旦签发，在有效期内无法废止（除非服务器增加黑名单机制）。

存储位置： Session存储在服务器端，Token存储在客户端。

扩展性： Token更适合分布式架构，因为它是无状态的；Session在集群环境下需要做共享。

安全性： Token一旦签发，在有效期内无法废止（除非服务器增加黑名单机制）。

# 12. 接口测试的常用工具有哪些？

#

答：

图形化工具： Postman, Insomnia (用于功能测试、调试、Mock)。

命令行工具： cURL (强大的命令行HTTP客户端)。

性能测试工具： JMeter, LoadRunner, Gatling, k6。

自动化测试框架： RestAssured (Java), Requests + Pytest (Python), HttpClient (Java)。

# 13. 你更倾向于用Postman还是代码做接口测试？为什么？

#

答： 这是一个没有标准答案的问题，考察对工具的理解和应用场景的判断。

Postman： 适合快速单次请求调试、接口文档编写、协作分享、简单的自动化流程（Collection Runner）和Mock Server。优点是上手快，可视化好。

代码（如RestAssured）： 适合复杂的逻辑测试、数据驱动测试、集成到CI/CD流程、性能测试和大型自动化测试项目。优点是更灵活、强大，易于版本控制和持续集成。

结论： 两者互补。前期探索和调试用Postman，后期系统化、自动化的测试用例用代码实现。

# 14. 什么是Mock？它在接口测试中有什么作用？

#

答： Mock是指模拟一个对象或服务的行为，返回预定义的响应。

作用： 解耦依赖： 当被测接口依赖的第三方服务或下游服务未开发完成、不稳定、有调用限制或费用时，可用Mock替代。 模拟异常： 轻松模拟各种异常响应（如超时、5xx错误），测试被测系统的容错能力。 提高效率： 避免搭建复杂的测试环境，加速测试执行。

解耦依赖： 当被测接口依赖的第三方服务或下游服务未开发完成、不稳定、有调用限制或费用时，可用Mock替代。

模拟异常： 轻松模拟各种异常响应（如超时、5xx错误），测试被测系统的容错能力。

提高效率： 避免搭建复杂的测试环境，加速测试执行。

# 15. 如何设计一个好的接口测试用例？

#

答： 应从以下方面考虑：

功能验证： 正向用例（参数正确，验证功能正常）。

参数验证： 必填字段： 缺失必填参数。 参数类型： 参数类型错误（如数字传字符串）。 参数边界： 参数长度、大小、范围的边界值。 非法参数： 传入非法值、特殊字符、SQL注入字符串等。

必填字段： 缺失必填参数。

参数类型： 参数类型错误（如数字传字符串）。

参数边界： 参数长度、大小、范围的边界值。

非法参数： 传入非法值、特殊字符、SQL注入字符串等。

业务逻辑验证： 验证业务规则和状态跃迁（如订单状态从“未支付”到“已支付”）。

错误码验证： 验证各种异常情况下返回的错误码和消息是否正确、友好。

安全验证： 权限控制、敏感信息加密、SQL注入等。

性能验证： 接口响应时间是否符合要求。

# 16. 在Postman中，如何管理测试环境变量和环境？

#

答：

环境（Environments）： 可以创建多个环境（如dev, staging, prod），每个环境包含一组变量（如 base_url, username）。

base_url

username

变量使用： 在请求的URL、Header、Body中使用 语法引用变量。

优势： 只需切换环境，即可快速在不同测试环境之间切换，无需修改每个请求。

# 17. 在Postman中，如何编写自动化测试脚本？

#

答： 在请求的 Tests 标签页中，使用JavaScript编写。

示例脚本：// 检查状态码是否为200

pm.tes