面试过程中，发现一个很值得思考的问题，测试经验及技能提升点区别在哪里？
7年前初级测试的时候，关于app与pc测试的区别，我当时回答的特别全面：涉及到功能、接口、兼容性、性能、安全性、界面、安装卸载等方面。
而如今测试多年，目前关于app与pc端测试的区别，深入理解技术细节和测试策略的差异，有了不一样的思考。
一、app与pc端测试的十一点不同特性
1、运行环境与部署
Web 端：
环境： 运行于各种浏览器中。
部署： 服务器端部署和更新。用户只需刷新浏览器即可获取最新版本。一次部署，全局生效。
访问： 通过 URL 访问。
App 端：
环境： 运行于移动操作系统中。
部署： 需要通过应用商店审核、用户下载、安装、手动更新。版本碎片化严重（用户可能使用不同版本）。
访问： 通过设备上的图标启动。
2、架构与技术栈：
Web 端： 基于 B/S 架构。前端技术（HTML, CSS, JavaScript, React, Vue, Angular 等），后端技术。测试主要关注浏览器渲染、网络交互、前后端接口。
App 端： 包含原生、混合、Web App 等多种形式。
原生： 使用平台特定语言（Java/Kotlin for Android, Swift/Objective-C for iOS）。性能最佳，访问设备功能最全。
混合： 使用 Web 技术（HTML5, CSS, JS）开发核心，封装在原生容器中（如 Cordova, Ionic, React Native）。依赖 WebView。
Web App： 本质上是一个针对移动浏览器优化的网站。测试需关注特定框架、原生桥接、WebView 兼容性、设备 API 调用。
3、兼容性
Web 端：
核心挑战： 浏览器兼容性（Chrome, Firefox, Safari, Edge 及其不同版本）。
次要挑战： 操作系统、屏幕分辨率、缩放比例。
App 端：
核心挑战： 设备碎片化（Android 设备品牌、型号、屏幕尺寸/分辨率/密度极其繁多）。
核心挑战： 操作系统版本碎片化（用户升级缓慢，大量旧版本并存，iOS 相对较好但仍有差异）。
挑战： 设备硬件差异（CPU, GPU, 内存, 传感器）。
挑战： 操作系统兼容性（iOS, Android 及其不同版本的行为差异）。
4、安装、更新与发布：
Web 端： 无安装过程。更新在服务器端完成，用户下次访问即生效。发布速度快，成本低。
App 端： 必须安装。更新需要用户手动操作（或启用自动更新）。发布流程复杂、耗时长（需打包、提交应用商店审核）。审核不通过需重新提交。热更新（绕过商店）通常有限制或风险。
5、性能关注点：
Web 端：
1.页面加载时间（首字节、首屏、可交互时间）。
2.资源加载优化（图片、脚本、样式）。
3.浏览器渲染性能。
4.网络延迟影响显著。
App 端：
1.启动时间（冷启动、热启动、温启动）。
2.UI 流畅度（帧率 FPS）。
3.内存占用与泄漏（影响设备整体性能，易被系统终止）。
4.CPU 占用率（影响耗电量和发热）。
5.电池消耗（后台活动、网络请求、定位、传感器使用不当是主因）。
6.网络状况模拟（弱网、断网、网络切换）下的行为更重要。
7.安装包大小（影响下载意愿和存储占用）。
6、用户交互与设备功能：
Web 端：
1.主要通过鼠标、键盘交互。
2.访问设备能力受限（需浏览器 API 支持，如地理位置、摄像头、麦克风、通知等，用户授权流程复杂）。
App 端：
1.丰富的移动交互方式：触摸（单点、多点、手势）、滑动、长按、陀螺仪、加速度计、指纹/面容识别、NFC、蓝牙等。
2.深度集成设备功能：摄像头、麦克风、GPS、通讯录、传感器、通知、后台运行等。
3.离线功能：更易实现本地数据存储和离线操作。
7、安全测试侧重点
Web 端：
1.传统 Web 安全漏洞是核心（OWASP Top 10）：注入、XSS、CSRF、认证失效、敏感数据泄露、配置错误等。
2.浏览器沙箱限制。
App 端：
1.包含 Web 端安全风险（尤其 Hybrid 和 WebView）。
2.特有风险： 不安全的本地存储、不安全的通信、反编译/逆向工程、代码篡改、证书固定、越狱/ROOT 检测、API Key 硬编码、不安全的权限申请与使用、后台服务安全、设备数据安全（通讯录、位置等）。
8、测试工具与框架
Web 端：
1.自动化： Selenium WebDriver (核心), Cypress, Playwright, Puppeteer, WebdriverIO, TestCafe 等。
2.性能： Lighthouse, WebPageTest, Chrome DevTools。
3.兼容性： BrowserStack, Sauce Labs, LambdaTest 等云测试平台。
App 端：
1.自动化：
2.原生/混合： Appium (核心，跨平台), Espresso (Android), XCUITest (iOS), Detox (React Native)。
3.WebView： 通常可借助 Web 端工具或 Appium。
4.性能： Android Profiler, Xcode Instruments, Perfetto, Firebase Performance Monitoring, GT。
5.兼容性： App Center, Firebase Test Lab, BrowserStack App Live, Sauce Labs Real Device Cloud。
6.其他： ADB (Android Debug Bridge), Charles/Fiddler (抓包), Burp Suite (安全)。
9、网络依赖与离线场景
Web 端： 高度依赖网络连接。离线功能实现复杂，通常通过 Service Workers 等实现，能力有限。
App 端： 更容易设计和测试离线功能（本地数据库、文件存储）。网络切换（WiFi/蜂窝数据）、弱网/断网场景下的健壮性和数据同步策略是重点测试项。
10、用户体验与设计
Web 端： 遵循 Web 设计规范，相对灵活。跨设备一致性有一定挑战。
App 端： 严格遵循平台设计规范（Material Design / Human Interface Guidelines）。对交互流畅度、手势反馈、触摸热区大小、屏幕空间利用、移动场景适应性要求极高。
11、后台行为与通知
Web 端： 浏览器标签页非激活或关闭后，能力受限。推送通知依赖浏览器支持和服务。
App 端： 可以运行后台服务/任务（如音乐播放、位置追踪、数据同步）。
推送通知是核心功能，测试其到达率、展示、点击行为至关重要。
二、重点关注代码特性
Hybrid App 测试： 需要结合 Web 端和 Native 端的测试策略和工具。特别关注 WebView 的兼容性、性能以及 Native Bridge 的交互。
H5 页面测试： 当 App 中嵌入 H5 页面时，其测试既属于 Web 端范畴（兼容性、性能），也受 App 环境约束（WebView 版本、Native 交互）。
用户体验： 移动端对流畅度、响应速度、触摸反馈、中断处理（来电、弹窗）的要求通常比 Web 端更严格。
测试环境： App 测试对真机设备的需求远高于 Web 测试。模拟器/仿真器是补充，但无法完全替代真机测试，尤其对于性能、传感器、特定硬件问题。
持续集成/持续交付： Web 端的 CI/CD 通常更简单直接。App 端的 CI/CD 需要考虑打包、签名、分发到测试设备或测试平台、处理应用商店审核等额外步骤。
三、测试策略的资源分配
资源分配： App 端兼容性测试通常需要更多设备和时间投入。
风险优先级： Web 端安全漏洞可能导致大规模数据泄露；App 端的性能问题（内存泄漏、耗电）可能导致用户卸载和差评。
工具选型： 根据项目类型（纯 Web、Native App、Hybrid App）选择最合适的工具链。
测试计划制定： 针对不同端的特性设计有针对性的测试用例和场景（如 App 的弱网测试、后台服务测试、权限测试；Web 的浏览器兼容矩阵测试）。
沟通协作： 向开发、产品、管理层清晰解释不同端测试的复杂性、挑战和所需资源。
