APP 测试与 Web 测试对比

相同点

序号	相同点说明
1	同一项目中，APP 和 Web 使用同一套后端服务器，共享相同的业务逻辑与数据库
2	前后端默认都使用 HTTP 协议进行交互，部分 APP 会补充 Socket 长连接
3	两者都必须开展功能测试，验证业务流程、功能模块的正确性

不同点

对比维度	APP 测试	Web 测试
架构模式	C/S（客户端/服务器）架构，需用户下载安装客户端，更新需发版	B/S（浏览器/服务器）架构，无需安装，通过浏览器访问，服务端更新用户无感知
数据传输格式	前后端交互以纯JSON格式为主，仅传输业务数据，由客户端负责渲染	前后端交互包含JSON、HTML、CSS等多种格式，由浏览器负责页面渲染
测试范围侧重点	功能测试 APP专项测试（安装卸载升级、push推送、交叉事件等） 移动端性能测试（CPU/内存、启动速度、流量/电量、流畅度、稳定性）	功能测试 兼容性测试（浏览器兼容、系统兼容、多终端适配） 易用性/用户体验测试（页面布局、操作便捷性等） 安全性测试 性能测试

1.需求分析与评审

评审目的：理解需求，查漏补缺
评审内容：产品需求文档，UI原型图
评审方式：会议
评审人员：产品、开发、测试、其他
评审结果：评审通过没有异议的需求文档

2.编写测试计划和测试方案

目的：确保测试工作的有序进行

测试计划的核心内容

测试计划是管理型文档，描述“测什么，谁来测？”

• 测试目标：最终要达成的要求
• App测试范围：测什么
  • 功能测试：业务测试、功能模块测试
  • 专项测试：安装卸载升级、push消息推送、交叉事件测试、用户体验测试、兼容性测试
  • 性能测试：CPU、内存占用，启动速度，流量、电量消耗，流畅度，稳定性
• 测试角色与职责：什么人干什么事
• 测试进度和资源：花费多长时间，需要哪些资源
• 风险预估和解决方案：可能遇到的风险以及如何应对
• 测试准入准出标准：什么时候开始，什么时候结束

测试方案的核心内容

测试方案是技术型文档，描述“怎么测”

• 测试策略：具体使用的方法，
• 测试环境准备：具体实施需要的测试环境
• 测试工具选择：具体实施测试工作可能需要的一些工具

AI编写测试计划和测试方案提示词

你以测试leader身份，帮我制定一份xxx项目类型的测试计划与测试方案
要求：
1.包含内容：上述测试计划和测试方案核心内容
2.测试范围：覆盖核心业务+核心功能（非功能）；测试时间：xxx个月；测试资源：xxx个人xxx台电脑….
3.测试环境：本地测试环境、预发布环境
4.核心业务主要：xxx业务、xxx业务、xxx业务、xxx业务
输出一份md格式的测试计划与测试方案

3.测试用例设计和评审

测试用例设计遵循先业务场景、后单功能的思路：先通过业务测试覆盖完整业务流程，保证业务闭环可用；再通过单功能测试覆盖各功能点的等价类、边界值与异常场景，保证功能细节无漏洞。

业务测试用例设计

业务测试是以用户视角出发的端到端流程测试，核心目标是：模拟用户真实操作，验证完整业务流程的可用性、正确性，确保业务链路跑通。

开展业务测试主要遵循以下步骤：
步骤一：根据业务流程梳理路径，梳理测试点
在写用例之前，必须先理清业务的流转逻辑。顺着流程图，找出用户操作的主线和各类异常分支，从而梳理出核心的测试点。
流程图来源：

• 产品提供：直接参考产品经理出具的官方原型图或业务流程图，这是最权威、最标准的路径依据。
• 测试自绘：当产品文档不清晰时，测试工程师需要根据对项目业务的理解，自行绘制业务流程图。

步骤二：根据路径编写测试用例
将梳理好的业务路径，转化为测试人员可执行的用例。每一条清晰的业务路径，都对应一条完整的业务用例。不仅要验证正向流程（上传成功、提现成功），还要覆盖反向流程。

---

业务测试用例的核心是先保证业务能跑通，在此基础上，再针对单个功能点开展单功能测试用例设计，覆盖细节校验。

---

单模块测试用例设计（App功能）

1.分析需求： 测试目的+测试条件（长度、类型、规则）
2.设计测试点，覆盖需求：

• 功能

  • 显示：是否正常
  • 操作（含规则）：能否成功
  • 其他
    3.将测试点转化为可执行的用例文档
    4.测试用例评审
    5.执行测试用例
    6.缺陷管理

App专项

安装升级卸载

安装测试

使用前：确保安装、升级功能正常

• 安装方式测试
  • 应用商店安装：官方商店、第三方应用市场
  • 手动安装：APK/IPA 本地安装
  • 特殊方式：电脑工具辅助、浏览器下载安装
• 安装位置测试
  手机内部存储、SD 卡安装
  默认位置、用户自定义位置安装
• 核心异常场景
  • 过程中断：关机 / 断网 / 手动取消
  • 环境异常：空间不足、低版本覆盖高版本
  • 兼容异常：不兼容系统 / 设备架构

升级测试

• 升级场景测试
  • 版本升级路径：临近版本升级（V1.0→V1.1、V1.1→V1.2）、跨版本升级（V1.0→V2.0、V1.5→V3.0）
  • 升级方式测试：应用商店升级（手动触发、后台自动）、应用内升级（检测新版本、下载升级包）、手动升级（下载安装包覆盖安装）
• 升级提醒策略
  • 提醒类型：不提醒升级、可选提醒升级、强制升级
  • 网络环境提醒：WiFi 环境静默下载 / 提醒、非 WiFi 环境提醒流量消耗、提供仅 WiFi 下载选项
• 升级过程异常测试
  • 网络异常：断网恢复、网络切换（WiFi↔移动数据）、弱网环境下载
  • 设备异常：升级时设备重启、存储空间不足、升级时接听电话
  • 升级中断恢复：下载中断断点续传、安装中断恢复重试
• 升级后验证
  • 基础功能：应用正常启动、用户登录状态保持
  • 数据兼容性：本地数据完整、旧版本数据迁移成功、数据库 / 配置文件升级兼容

卸载测试

• 卸载方式测试
  桌面 / 设置常规卸载、应用商店卸载、第三方工具卸载
• 核心异常场景
  卸载过程中断（关机 / 取消）、特殊状态卸载（运行中 / 无响应）
• 卸载后验证
  数据残留检查、系统残留检查，彻底清除无残留
• 卸载后重装验证
  立即重装、重启后重装、无旧数据残留

兼容性

手机型号兼容性测试

主流品牌覆盖：Android（华为 / 小米 / OPPO/vivo/ 三星）、iOS（iPhone/iPad 全系列）
市场占有率考量：按用户群体选机型、目标用户机型优先、跟进新上市热门机型

系统版本兼容性测试

Android 系统版本：主流版本、历史版本、最低支持版本、品牌定制系统
iOS 系统版本：主流版本、历史版本、最低支持版本、测试版系统适配

分辨率与屏幕尺寸测试

分辨率适配：主流分辨率、特殊分辨率（折叠屏 / 平板 / 异形屏）
屏幕尺寸适配：小屏 / 主流 / 大屏 / 平板 / 折叠屏不同状态
显示验证：界面布局、文字大小、图片无拉伸、图标清晰

网路环境兼容性测试

移动网络：5G/4G/3G/2G（弱网）
WiFi 网络：不同标准 / 信号强度 / 公共 WiFi
网络切换：WiFi↔移动数据、运营商切换、断网重连、飞行模式
弱网与无网：功能响应、无网提示、数据缓存、网络恢复同步

应用兼容性测试

手机硬件兼容：电源键、音量调节等
外部硬件兼容：耳机、蓝牙
操作系统交互：权限 / 通知 / 多任务 / 深色模式 / 字体 / 多语言
与其他 APP 交互：分享 / 跳转 / 数据传递 / 后台共存

特殊场景兼容性测试

多任务处理：后台 / 分屏 / 画中画 / 小窗模式
系统设置影响：省电 / 性能模式、字体 / 显示大小、权限管理
安全与隐私：安全策略、VPN / 代理环境、企业设备管理

push消息推送

交叉事件

用户体验

4.测试执行并提交缺陷

核心目标：按照用例执行测试，发现缺陷、跟踪缺陷，保障产品质量符合上线标准。
核心工作流程

测试执行

执行前置条件

正式执行测试前，需满足以下条件，确保测试可顺利开展：

• 冒烟测试通过（核心主流程可正常跑通，无严重阻塞问题）
• 严格按照测试计划约定的时间启动执行
• 测试用例、测试环境、测试数据已全部准备就绪

用例执行原则与顺序

• 执行顺序：先业务测试，后单功能测试（先跑通主流程，再测细节）
• 用例执行方式：
  • 按优先级执行：主业务正向为P0，逆向为P1，单功能正向P2，逆向为P3。先执行 P0 核心用例，再执行 P1、P2、P3 用例
  • 按模块重要性逐一执行：优先覆盖核心业务模块，再验证边缘功能
  • 逐条执行：严格对照用例步骤操作，避免漏测、跳测

执行结果记录

执行用例后，需按标准标记结果，并留存测试截图、日志等佐证材料，常见执行结果如下。

执行结果	含义说明
PASS	测试通过（实际结果与预期结果完全一致）
FAIL	测试不通过（实际结果与预期结果不一致，需提交缺陷）
BLOCK	阻塞（依赖功能未完成 / 环境异常，导致用例无法执行下去
N/A	不适用（当前用例因需求变更等原因，暂时无需执行）

为保障测试追溯性，执行用例时建议同步记录以下信息。

字段名称	填写要求	作用说明
测试（执行）结果	必填	明确用例执行状态，是测试报告的核心数据
测试版本号	建议填写	方便后续回归测试，明确缺陷修复的版本范围
测试人员	建议填写	明确测试责任主体，避免问题追溯时权责不清
备注（关联 bug）	建议填写	关联对应缺陷 ID，清晰掌握用例对应的 bug 状态

缺陷提交

缺陷提交规范

缺陷核心描述要素

提交缺陷时，需完整覆盖以下核心内容，确保开发能快速定位问题：

• 缺陷的标题：描述缺陷的核心问题，简洁清晰
• 缺陷的预置条件：缺陷产生的前提（如登录状态、商品库存等）
• 缺陷的复现步骤：复现缺陷的完整操作过程，保证可复现
• 缺陷的预期结果：希望得到的正常结果
• 缺陷的实际结果：实际得到的错误结果
• 缺陷的必要附件：图片、日志等证据信息（附件可按需补充）

缺陷提交管理要素

在缺陷管理工具中，需补充以下维度信息，用于缺陷分级与跟踪：

• 缺陷报告编号：缺陷的唯一性标志，用于缺陷追溯
• 严重程度：严格按标准标注
  • 严重（S1）：主功能异常，阻塞核心业务
  • 一般（S2）：次要功能异常，不影响主流程
  • 微小（S3）：易用性、界面类问题
  • 建议（S4）：优化建议类问题
• 缺陷优先级：明确修复时效要求
  • Priority 0：24小时之内解决
  • Priority 1：发布前必须修复
  • Priority 2：可在下一个版本中修复
• Bug类型：标注缺陷所属类别（代码错误、兼容性问题、设计缺陷、性能问题等）
• 缺陷状态：跟踪缺陷生命周期（New:新建、Open:打开、Closed:关闭、Postponed:延期等）

缺陷报告示例

以下为标准缺陷报告模板，可直接参考编写：
以下是生成的表格格式（Markdown）：

缺陷 ID	缺陷标题	缺陷状态	严重程度	优先级	所属模块	缺陷描述	附件
bug1	订单支付时，点击去付款无响应，未唤起支付渠道	new	P0	P0	购买核心业务	打开购物网页； 选择商品并加入购物车，完成下单流程； 进入订单详情页，点击「去付款」按钮。 预期结果:页面能够正常唤起支付宝 / 微信 / 银行卡等支付渠道。 实际结果:页面无响应	问题截图、操作日志

缺陷跟踪管理

• 跟进缺陷：
  • 每日跟进缺陷管理工具上的缺陷情况
  • 优先级较高的缺陷要及时驱动开发进行修复，同步修复进度
• 回归缺陷（回归测试）：
  • 对于BUG状态为「已解决」的问题，及时执行回归测试
  • 回归测试时，需保障测试环境已更新修复bug的版本
  • 回归范围：覆盖修复的缺陷 + 关联功能，避免修复引入新问题
  • 全量回归：版本迭代、重大缺陷修复后，执行全量用例回归，保障整体质量

5.编写测试报告

核心目标：总结测试全过程，评估产品质量，为上线决策提供依据。
核心内容：

• 测试概述：测试范围、测试环境、测试时间、测试人员
• 测试执行情况：用例执行率、通过率、未执行用例原因
• 缺陷统计分析：缺陷总数、缺陷分级占比、缺陷修复率、遗留缺陷说明
• 质量评估：是否符合上线准出标准、产品质量风险评估
• 测试总结与建议：本次测试的经验、后续优化建议、上线建议

AI编写测试报告提示词

你以软件测试工程师身份，帮我编写xxx项目的测试报告
要求：
1.覆盖核心内容：项目概述、测试概述、测试执行情况、缺陷统计分析、质量评估、总结改进
2.项目概述：要求介绍项目类型、核心业务（xx业务、xx业务…）、核心功能（xxx、xxx…）等
3.过程回顾：项目周期xxx个月，测试人员xxx人，电脑和手机、服务器若干，测试环境两套：本地测试环境、预发布测试环境
4.统计分析：用例数xxx条左右，bug数xxx个左右，其中致命bugxxx个，严重bugxxx个，其他中等bug占比约xxx%，剩余其他为轻微bug
5.结果确认中：需要描述能上线的标准，确认能否上线发布
输出：md格式的文档