★ FEATURED ARTICLE 先说我最近带新人的一个感受。组里有位做了三年 Web 测试的同事上个月第一次接手 App 项目用的还是那套看接口、查页面、回归业务的老思路。结果版本上线前被用户反馈砸了个大跟头——App 切到后台再切回来页面直接白屏代码层面什么问题都没有纯粹是生命周期状态没处理好。这个例子基本能回答标题的问题Web 端测试和 App 端测试的区别远不止“一个在浏览器、一个在 App”这么简单它是一整套由运行环境、交付形态、系统权限模型共同决定的测试策略差异。本文就基于我自己两条线都带队测过的经验把两端测试从用例如设计到工具选型再到专项测试的差异系统性地拆开讲清楚。1. 一切差异的源头运行环境与交付形态很多测试新人会从“操作的终端不同”来理解 Web 和 App 的区别这个角度太浅了。真正影响你测试策略的是背后两套完全不同的运行环境和交付链路。搞不清这两个基础问题后面所有用例设计都会想当然。1.1 Web 端测试的前提服务端可控客户端失控Web 应用跑在浏览器里代码和服务都在服务器上。对测试来说这是个“半可控”环境服务端版本、接口返回、页面资源你是可控的但用户那一端的浏览器版本、屏幕分辨率、操作系统、甚至浏览器里装了什么插件你基本管不着。最典型的就是浏览器自动更新和版本混杂的问题。Chrome 每六周一个大版本但用户不一定都跟着升国内还有一堆双核浏览器Chromium 内核套壳Windows 版的 Chrome 和老版本之间有各种渲染差异。我见过一个后台管理系统在 Chrome 120 上一切正常到了某个用户还在用的 Chrome 90 上表格组件的滚动条样式直接错乱虽然不影响功能但看起来就是“坏的”。这种问题 Web 端很常见因为浏览器本身会约束页面的表现逻辑。另一个问题是浏览器缓存和本地存储。Web 端测试必须反复验证强缓存、协商缓存、Cookie 过期、LocalStorage 被手动清理这些场景。发布新版本后用户浏览器如果没有刷新可能还加载着旧 JS 文件于是就出现“接口已经返新数据了页面还是老交互”的错位现象。这些都是 Web 端特有的“用户侧环境失控”带来的测试点。1.2 App 端的常态版本碎片化与有限的发布窗口App 的处境恰好反过来代码打包进了安装包用户设备上是什么版本就是什么版本你能不能快速修复问题要看应用商店的审核速度。iOS 的 App Store 审核现在快一些但遇到紧急 Bug 想发紧急更新仍然可能被审核流程卡住这是没法绕过的。Android 更麻烦国内各厂商商店的审核标准、上架速度都不一样有些机型还预装了自家的应用商店发布策略很难统一。结果就是你永远处于“线上同时跑着三四个老版本”的状态。测 Web 的时候发版后你只要回归主流程就可以放心但测 App你不得不维护一套存量版本兼容矩阵新版上线后那些没升级的老版本用户还在用他们遇到问题后反馈过来你还得能在旧代码上复现。更麻烦的是灰度发布和分阶段放量。iOS 通过 TestFlight、Android 通过各渠道的分发平台你可以先放 10% 的用户没问题再逐渐放开。但这个策略给测试增加了一个维度不仅要测“新版本本身”还要测“新旧版本数据共存”。比如一个字段之前叫mobile新版本改成了phone旧版本用户提交的数据到新逻辑里会不会解析失败这类字段漂移问题在 App 端比 Web 端更常见因为 Web 端几乎不存在“离线数据”的概念而 App 端本地数据库、本地缓存里全是旧结构的脏数据。两个环境一对比核心结论就出来了Web 端测试重“覆盖浏览器环境的广度”App 端测试重“覆盖存量版本和设备的深度”。后者的复杂度通常比前者高一个量级。2. 功能测试用例设计同一个功能两套完全不同的用例我见过不少从 Web 转过来的测试工程师拿到 App 需求后第一反应是“照着 Web 的用例改一改”改完就以为行了。真到了回归阶段才发现漏掉的全是系统层面的交互场景。同一个按钮、同一个输入框在 Web 端和 App 端要验证的东西差异大到你难以想象。2.1 App 端必须先补“系统交互”用例App 是活在操作系统里的系统任何时候都可能打断它。所以测试用例必须覆盖这些场景来电、短信、闹钟通知弹出时App 的界面会不会被顶掉顶掉后再切回来输入框里的内容还在不在正在上传图片时切到后台五分钟再回来是继续上传还是提示失败前置摄像头和麦克风权限弹窗、定位权限弹窗、相册权限弹窗这些在 Web 端虽然也有浏览器权限询问但 App 的权限模型更严格。用户首次启动 App 时系统会依次弹窗询问各种权限而这个弹窗的时序直接决定你的功能能不能走通。Android 从 6.0 开始引入运行时权限即使你在 Manifast 里声明了也必须在运行时机向用户申请用户拒绝之后 App 的行为逻辑要和首次申请完全不一样。iOS 更狠用户第一次拒绝后下次再弹之前应用系统默认只会在设置里出现“灰色不可点”的输入框。这些差异都要写进用例。触屏交互也一样左滑删除、右滑返回、双指缩放、长按呼出快捷菜单、键盘弹起遮住输入框这些都是 App 端才有的用例维度。如果你的应用支持横竖屏旋转那么旋转后的布局、数据保持、输入焦点这些都是专项。Web 端测试几乎不需要考虑这些因为浏览器在 PC 上没有物理旋转触屏手势也不适用于鼠标键盘场景——现在的响应式 Web 版本也能在手机上用但它依然是浏览器上面的网页跟原生 App 的手势是两码事。2.2 Web 端要关注“浏览器行为”用例反过来Web 端也有一堆 App 端没有的浏览器行为。最常见的三个刷新、前进后退、多标签页。刷新这个动作 App 端基本不存在你可不能像电脑一样把 App 页面“刷新”一下只能杀掉进程重开但对 Web 来说这是最常规的用户行为。刷新之后页面状态会不会回到初始表单填写到一半刷新草稿内容有没有被恢复如果页面里有分页组件刷新之后能不能回到之前的页码浏览器前进后退按钮则是另一个高频坑。页面里搞了 SPA单页应用路由是自己控制的这时候用户点浏览器后退URL 变了但页面内容没变或者页面内容变了但组件状态没变这类问题在 Web 端回归里几乎每周都能遇到。对测试来说不仅要验证路由跳转还要注意不要被浏览器缓存“骗了”——有时后退之后页面显示的是浏览器缓存里的旧快照逻辑其实已经走了新代码这就是个鉴别 WebView 还是原生页面的好机会。多标签页的影响也不能忽略。用户在一个标签页登录另一个标签页也打开了同一个系统两边同时操作会不会出现会话冲突关闭标签页时有没有“未保存内容”的提示这些都是浏览器特有的场景。2.3 以“登录功能”为例两端用例的差异用最典型的登录功能来对比一下你就能直观感受到两端的用例差多远了测试场景Web 端App 端正常输入账密登录要测要测密码错误提示文案要测要测密码自动填充浏览器/系统浏览器自动填充表单要验证填充值是否被表单校验正确识别系统键盘自动填充、密码管理器保存后的填充登录后刷新页面要验证登录态是否保持杀进程重开后要验证登录态是否保持登录后切后台再回来不太涉及必须验证 Session 不被系统回收记住密码存 Cookie / LocalStorage存 KeychainiOS或本地加密存储Android多设备登录互踢同一浏览器多标签页同会话多个 App 设备之间、App 与 Web 之间的会话互踢验证码短信等待短信到达期间切走页面再回来等待短信期间 App 被系统回收回来后要恢复状态这样一列就清楚了同一个登录功能Web 端的测试重点在“浏览器页面状态”App 端的测试重点在“系统生命周期和本地状态”。这两套用例必须分开设计用一套模板套两遍只会两头都漏。3. 兼容性测试App 端工作量通常是 Web 端的几倍兼容性测试是两端差距最夸张的地方。Web 端你最多做到“主流浏览器 主流分辨率”覆盖App 端却要面对几十个 Android 品牌、近万个机型以及 iOS 这边数量不等的 iPhone 型号。这不是测试态度问题是资源分配的现实问题。3.1 浏览器兼容矩阵怎么定Web 端的兼容性测试核心是定好浏览器矩阵。我的建议是看自己的访问统计而不是盲目堆浏览器。如果后台数据显示 98% 的用户是 Chrome 和 Edge那 Firefox 和 Safari 就没必要每个版本都全量回归只做模块级抽查即可。比较常见的做法是主测浏览器Chrome、Edge最新版 前一个大版本常规兼容Firefox 最新版、Safari 最新版抽查保底:若干台老设备上的旧浏览器如 Chrome 90 左右同时还要关注浏览器内置的“模拟移动端”模式大部分页面表现问题都能在 DevTools 的设备模拟里提前发现不用真的拿一堆手机去测 Web 页面。3.2 设备兼容矩阵怎么定碎片化的 Android 是重头App 端就完全不是这个量级了。Android 的碎片化用一句话形容你根本没法保证用户用的是什么。高通、联发科、海思、麒麟各种 CPU 平台、各家 ROM 定制系统MIUI、ColorOS、OriginOS、Flyme 等、从 Android 9 到 Android 15 的版本跨度还有刘海屏、挖孔屏、折叠屏这些形态差异。每个要素都可能引发问题折叠屏的 App 在展开状态下布局会崩刘海屏的适配会遮住按钮个别 ROM 的后台管理策略会把 App 杀掉导致推送收不到。我的设备矩阵策略是三步走第一步选主力机型覆盖当前市场上的 Top 20 机型这基本能覆盖 60% 的用户第二步按 OS 版本分层每个大版本至少保一台真机第三步盯住特殊形态——折叠屏、大屏 Pad、带不在常规适配的国产 ROM 机型遇到问题再加。3.3 真机与云真机的成本平衡对很多团队来说自建真机池不现实我建议用“真机保底 云真机覆盖”的组合。主力功能的深度回归放真机上跑保证稳定性和手感整包冒烟和机型覆盖用云真机平台按需购买时长成本可控。真机池里的设备也不能只堆“最新旗舰”旧的、低端的、低速存储的设备反而更容易暴露问题。我踩过一次坑某功能在最新款旗舰机上跑得飞快到了两年前的一台中端机上图片列表加载直接卡到白屏 3 秒原因就是内存占用和文件解压速度都顶满。测试设备矩阵里务必加入一两台“中低端机型”当底线测试不然你测出来的是“天花板体验”不是真实用户体验。4. 专项测试App 端真正的分水岭如果说功能测试和兼容性测试是两端共有的那专项测试就是 App 端明显拉开差距的地方。Web 端有性能测试和安全测试但 App 端除了这些还有一大堆 Web 端根本不存在的东西耗电、冷启动、弱网切换、后台保活、推送抵达率。这些专项不测线上问题迟早会教做人。4.1 性能与流畅度Web 看 LighthouseApp 看 FPS 与启动速度Web 端性能测试其实挺成熟Chrome DevTools 里的 Lighthouse、Performance 面板、Network 面板可以对页面加载时间、资源体积、首屏耗时做量化。Web 端真正难的是“百毫秒级卡顿”的定位尤其是滚动、点击反馈这些交互掉帧问题用 Performance 面板录制倒是能看但终究是“一帧一帧盯”效率低。App 端性能测试维度更多冷启动时间用户点击 icon 到进入可交互界面的耗时、热启动时间、页面滑动流畅度FPS、CPU 占用、内存占用、磁盘占用。我常用的工具是 PerfDog它可以一边操作一边实时采集 CPU、FPS、内存曲线定位某个操作瞬间的掉帧点。一个常见场景某个页面滚动时掉帧严重。Web 端你大概率会怀疑 DOM 节点太多App 端则要先确认是主线程拥堵还是 GPU 渲染问题。比如 Android 端常见的原因是图片加载没有做子线程化UI 主线程被大量 bitmap 解码卡住了这种问题用 FPS 曲线能立刻看出来但光看接口调用和日志是看不出来的。4.2 弱网测试Web 和 App 的做法各不相同弱网测试是移动 App 测试里的必选项。Web 端可以用 Chrome DevTools 的 Network 面板模拟慢速网络比如慢 3G、慢 4G但它的模拟只是简单地延迟网络请求App 端的弱网环境更复杂信号强弱波动、Wi-Fi 与蜂窝网络切换、离线和重连这些真实场景Chrome 那个模拟器并不完全能覆盖。App 端我常用的办法是 Charles 的 Throttle 功能它可以设置上行/下行带宽、丢包率、延迟效果比模拟器里的网络切换靠谱。更真实的做法是用服务商提供的网络损伤仪但那设备贵一般团队用不上。实际工作中我最常测的弱网场景是弱网下点击提交按钮接口超时或返回错误App 会不会一直转圈不提示弱网断掉后再恢复页面的数据加载能不能自动继续Wi-Fi 切到 4G/5G 时当前页面会不会因为网络变化而报错这些场景在 Web 端几乎不需要测因为浏览器在弱网下直接转圈等响应不会出现“网络切换后的状态保持”这种问题但对 App 来说这些都是崩溃高发区。4.3 耗电、存储、后台保活Web 端不存在的专项这几个专项常常被 Web 转岗的测试忽略但它们才是线上问题的重灾区。App 长时间挂后台系统可能有内存回收机制把它清掉也可能让它继续占用 CPU 和 GPS导致手机异常发热。测这类问题用真机最靠谱开了定位服务隔半小时看温度和电量曲线,同时检查 App 的后台 CPU 占用。后台保活更隐蔽。用户把 App 切到后台半小时再回来页面是滑到原来的位置还是被系统回收重新重建重建后数据还在不在如果用户从通知栏点击一条推送跳转进 App是停留在当前页还是直接进推送详情页这些场景 Web 端几乎没有对应物但线上每天都有大量用户遇到。存储方面App 长期使用会累积缓存和日志文件所以专项里一定要有“App 长时间使用后的存储占用”测试连续操作账号、浏览大量图片视频然后查看本地缓存目录有没有指数级膨胀。我处理过一次线上问题某版本日志文件没做清理策略一个月多占用户 500MB 空间这属于专项测试不彻底导致的。4.4 安全层面的差异Web 端的安全测试重点在 Web 漏洞XSS、CSRF、SQL 注入、越权访问这些本质是“服务端接受不可信输入”的风险。App 端则多了一层设备端风险本地存储有没有明文保存账号密码或 TokenRoot/越狱环境下 App 的防护会不会失效界面截图后敏感信息会不会泄露在相册缓存里Web 端受害的群体是“所有访问页面的用户”App 端受害的群体是“单个安装了这个 App 的设备用户”攻击面完全不同。5. 自动化测试工具、脚本与稳定性难题自动化测试是两端差距非常直观的地方。Web 端自动化已经非常成熟App 端自动化的复杂度和稳定性挑战则要大得多。这里不是说工具谁好谁坏而是两端的自动化基础完全不同。5.1 Web 自动化的根基是 DOMApp 自动化的根基是控件树Web 自动化最大的优势是 DOM 树的存在。页面上任何元素都是可以定位的id、class、xpath、text定位简单可靠页面结构清晰。但 Web 自动化也有自己的坑弹窗、iframe、懒加载、异步渲染定位一个元素往往要配合显式等待。App 自动化则是基于控件树。Android 有 UIAutomator 控件树iOS 有 XCUITest 的 accessibility 层级元素定位方式类似但没有 Web 端那么“标准”。App 上很多元素会根据主题切换显示不同的文本或者控件树里根本看不到某些自定义 View 的文本只能靠坐标定位。坐标定位最不稳定屏幕尺寸一变、头部栏高度一变、键盘弹出收起坐标就可能偏移脚本就会一夜之间全红。5.2 工具选型对比各家方案没有通吃我实际评估下来主流的工具组合大概是这个情况工具适用端优点明显短板SeleniumWeb生态最成熟资料最多需自行封装等待机制跨浏览器支持需要 WebDriverPlaywrightWebAPI 简洁自带自动等待截图/录制都好用相对较新部分小众浏览器支持不够及时CypressWeb调试体验极佳交互直观不支持多标签页、对原生 iframe 支持比较弱AppiumApp跨平台一套代码跑 iOS/Android依赖 WebDriverAgent 和 UIAutomator稳定性取决于环境MaestroApp上手极快支持手势和相对坐标较新的工具断言能力相对弱一些原生框架XCUITest/UIAutomatorApp与系统集成度高、运行稳定各写各的不能一套代码跨两端选型的核心逻辑不是“哪个最好用”而是“你团队的维护能力”。Web 端我建议优先 Playwright因为它的自动等待机制能节省大量调试时间而且自带截图对比。App 端如果只是做冒烟回归、轻量自动化Maestro 上手最快如果要做完整的 UI 自动化回归Appium 仍然是最稳妥的选择但你要接受它的环境和依赖复杂度。5.3 影响自动化稳定性的细节才是关键工具选型其实不是最大的坑真正让自动化脚本“一夜全红”的都是些不起眼的细节。App 端最常见的是权限弹窗时序第一次启动 App系统弹“允许通知”的弹窗是异步的有的测试机上比页面元素晚 1 秒弹出脚本已经开始点页面了结果点到弹窗上导致断言失败。这种问题只能通过 setup 阶段统一处理权限弹窗比如通过 ADB 命令预先授予权限或者脚本里做等待。Web 端同样有类似的坑浏览器自动填充密码弹窗、Cookie 弹出的 GDPR 提示、系统自带的“翻译成中文”提示条都可能挡住页面元素。我用 Playwright 时会在 fixture 里统一拦截这些提示条不然每次跑都看运气。还有一类 App 端特有的稳定性问题Toast 提示。Toast 是一个短暂的控件通常只存在 2 秒你要断言 Toast 内容就必须在它出现的瞬间去抓取自动化框架经常因为时序问题抓不到。另一种是 WebView 嵌套页面混合 App 里 H5 页面能通过 WebView 展示自动化的处理逻辑和原生页面完全不同Web 端的 Selenium 逻辑不能直接用需要切换到 WebView 上下文去定位 HTML 元素。5.4 回归策略两端完全不同的组合逻辑即使自动化框架搭好了回归策略也必须分开。Web 端你可以按功能模块划分回归用例因为同一套代码、同一套版本跑一次即可App 端就复杂了你得按“版本 机型 渠道”组合回归。同样一套功能不同 Android 版本上控件树可能不一样不同渠道包的启动流程可能不一样渠道包可能嵌入不同的 SDK、推广参数所以回归策略不能只跑一遍。实际操作上我会把 App 端自动化分成两层第一层是全量的核心功能冒烟测试跑在少数几台主力真机上第二层是关键模块的深度回归跑在云测平台的十几台机器上。第二层的成功率通常只有 70%-80%因为真机环境五花八门每次跑完都要挨个分析失败原因这已经算自动化圈内公认的常态不用自我怀疑。6. 从一端到另一端需要补的短板看到这里你应该已经明白了结论不是“Web 测试和 App 测试谁更难”而是它们各自的难点不一样。对个人来说真正致命的是拿一套思路去硬套另一端的项目。我最后把两端转岗时最该补的短板列一下。6.1 Web 转 App最容易忽略的是“系统层”从 Web 转 App 的测试工程师功能用例设计、接口测试、自动化脚本这些基础都顺手但一到系统层就容易露怯。你需要补的是App 生命周期前台、后台、挂起、终止、事件中断来电、锁屏、通知、权限模型运行时权限、拒绝后的行为、多任务切换App 间跳转、系统返回、以及键盘、存储、相册相机等系统能力。这些领域不在页面上而是在 OS 行为里必须靠真机反复体验才能建立感觉。6.2 App 转 Web最容易忽略的是“浏览器一致性”反过来资深 App 测试转 Web最容易漏的是浏览器行为和网络特征。你要开始关心同一个页面在不同浏览器内核下的渲染差异刷新/前进/后退带来的状态问题Cookie 的失效和跨域限制是否影响登录态。另外一个高频问题Web 页面强缓存导致新样式不生效这类问题在 App 端发版逻辑里根本不存在但在 Web 端是非常典型的“用户侧脏环境”。6.3 两端都做的团队如何平衡测试资源一个团队如果同时维护 Web 端和 App 端资源分配的建议是优先保证 App 端专项测试的投入因为它是线上问题的主要来源Web 端回归可以依赖更多自动化但要在兼容性矩阵里保留“存量浏览器”的抽查别因为主线浏览器测得好就忽略老版本。我见过不少团队因为 Web 端自动化率高就裁掉了手工浏览器矩阵回归结果在某个老浏览器的兼容问题上市后被骂惨。我个人实际带团队的经验是两端的测试设计文档完全分开写用例库分开维护但公共的接口测试、性能基线可以共享。每个迭代开始时花半天时间把两端特性差异的风险点过一遍问一句“这个需求在另一端会不会有不同行为”往往能提前堵住一大半线上问题。说到底Web 端测试和 App 端测试的区别不是一个“测试技巧”问题而是对两种不同产品形态的理解问题。把运行环境、交付节奏、系统能力这些基础逻辑吃透了无论是测 Web 还是测 App你都不会被表象的“操作步骤”困住。
阅读完成 · 觉得有帮助？
