Android与iOS平台测试的差异解析：从架构到发布审核

做APP测试这行当久了，你会发现「Android和iOS平台测试的区别」不只是换个手机跑一遍那么简单。同样是点一个按钮、发一个请求，两边的行为可能千差万别——Android后台杀得一干二净，iOS还能把你从崩溃现场拉回来；Android上一个Toast就过去了，iOS可能直接弹个权限框卡住整个自动化脚本。我从系统架构、设备碎片化、工具链、UI自动化、网络抓包、性能测试一直写到发布审核，把这几年踩过的坑和验证过的方案统一梳理一遍，希望能帮正准备入行平台测试、或者正在为两端兼容性问题上火的同学省点时间。

1. 两个平台的底层差异：测试思维的分水岭

1.1 系统架构与生态定位：开放与封闭的取舍

Android基于Linux内核，源代码开源，于是三星、小米、OPPO、vivo、华为这些厂商可以任意定制系统框架。iOS基于Darwin（BSD分支），闭源且苹果长期软硬一体，第三方几乎没有系统级的定制空间。这个差异决定了测试的视野完全不同。

从测试维度看，Android平台要覆盖“同一App在不同厂商定制系统上的行为差异”。MIUI/HyperOS的杀后台策略、华为的纯净模式、ColorOS的智能后台管理逻辑都不一样，直接影响通知、保活、权限弹窗和自启动行为。我实测下来，同一个App在MIUI上被杀后台的频率远高于原生Android，而且华为类机型对应用自启动的管制更严格，稍不留神App就在后台消失了。

iOS相对可控，机型有限、系统版本相对集中、权限机制统一，但苹果对隐私权限、推送、后台模式设有严格限制。所以测试的重心不是碎片化，而是“合规性”和“系统限制下的功能表现”。我最初带团队时，很多人拿同一套用例在两端直接跑，结果Android全绿、iOS一堆Fail，原因就是用例没有针对平台特性设计。

1.2 生命周期与后台机制：杀进程、切前台、锁屏唤醒

Android的Activity有一套完整的生命周期：onCreate、onStart、onResume、onPause、onStop、onDestroy。iOS的App生命周期由AppDelegate和SceneDelegate管理，核心回调是didFinishLaunchingWithOptions、applicationDidEnterBackground、applicationWillEnterForeground。两边的状态机不同，测试场景自然也不同。

Android上切到后台，Activity可能被系统回收，恢复时触发onSaveInstanceState/onRestoreInstanceState，所以必须测试“状态一致性”：填写了一半的表单切后台再回来是否还在，WebView滚动位置有没有跳回顶部。iOS后台执行时间有限，App通常几十秒后被挂起，测试重点是“挂起后在通知栏点击恢复”“从App切换器回来”这些路径。

推送测试的差异也很突出。Android推送大多走厂商PushSDK，比如小米推送、华为推送，断网、重启、清后台之后推送到达率差异很大，需要分厂商验证。iOS推送走APNs系统级通道，到达率稳定，但要重点验证前台、后台、锁屏三个状态的展示差异，以及推送点击后是否深入跳转对应页面。

锁屏、来电、闹钟、分屏、画中画这类系统事件，Android端权限开放可以自由模拟，iOS端因为系统权限限制，只能尽量用系统自带能力模拟真实场景。实测Android分屏模式下App的UI会重新布局，而iOS的iPad Split View逻辑与iPhone完全不同，需要单独设计用例。

注意：Android上按Home键和按返回键退出，App的恢复逻辑不一样。我习惯把“Home键退出后点击通知栏恢复”和“返回键退出后从图标重新进入”分成两类用例。iOS没有返回键，只有Home条手势和App切换器，恢复路径相对简单，但要注意“从App切换器杀掉再打开”和“左滑返回上一页”的处理差异。

2. 设备碎片化：Android的噩梦与iOS的福音

2.1 屏幕尺寸、分辨率与适配测试

Android阵营的屏幕尺寸覆盖范围极其宽泛，从早期320x480的机型，到主流1080x1920、1440x3200的旗舰，再到折叠屏的展开态，物理分辨率和逻辑分辨率的关系五花八门。iOS目前主流的逻辑分辨率相对固定：iPhone SE 3是375x667，iPhone 14/15是390x844，iPhone 15 Pro Max是430x932，虽然物理像素不同，但逻辑分辨率苹果卡得很死。

Android平台我建议建立“测试设备矩阵”，至少覆盖三类：主流竖屏比例（19.5:9）、一台中低端机（验证性能和渲染）、一台大屏旗舰（验证UI适配）。重点看布局有没有顶到刘海/挖孔，底部安全区有没有被手势条遮挡，横屏时字体缩放是否正确，还有深色模式下的适配。Android的“最小宽度独立像素”（sw360dp/sw400dp）这个概念值得单独提，不同机型的最小宽度不同，同一dp值在不同屏幕上显示效果差异非常大。我遇到过在红米上正常、在三星S24上布局错乱的问题，排查半天发现是sw值不同触发了不同的资源目录，所以适配测试一定要关注项目里的res/values-swXXXdp目录。

iOS平台逻辑分辨率就那几档，我一般用“小屏+大屏”两头验证，中间的用模拟器补。iPhone SE这类小屏容易暴露文案截断问题，Pro Max大屏容易暴露间距过大或元素拉伸问题。iOS的Auto Layout和SwiftUI适配相对统一，但刘海屏的safe area、灵动岛的交互区域、底部Home Indicator，都是iOS特有的适配点，稍有疏漏就会在真机上翻车。

2.2 系统版本与厂商定制ROM的差异化验证

Android版本分布极其分散，中低端机还停留在Android 11、12甚至更低。iOS的系统更新率很高，我一般只测最新系统加前一个大版本就能覆盖绝大多数用户。

厂商定制ROM是Android测试最大的变量。MIUI/HyperOS的“神隐模式”、ColorOS的“智能后台管理”、OriginOS的“轻应用”、MagicOS的“纯净模式”，这些系统的省电策略、自启动管理、通知权限逻辑都不同。App保活测试在原生Android上能通过，在MIUI上可能直接被杀。我现在的做法是准备好各厂商的权限管理入口手册，测试前先把App的自启动、后台运行、通知权限都手动打开，然后分别跑“熄屏5分钟”“锁屏清理”“一键清理”三种场景，保活问题基本都能暴露。

各厂商对权限的定义也不统一。Android 6.0之后有运行时权限，原生系统是弹窗，但部分定制ROM会直接静默拒绝，或者弹窗样式和文案完全不同。自动化脚本里处理“允许/拒绝”按钮时，这些差异都是坑：这台手机上写“始终允许”，另一台写“仅在使用时允许”，脚本匹配错一个词就挂了。

iOS相对省心，但权限弹窗一旦点了不允许，只能去“设置 > 隐私”手动开。自动化测试时iOS权限弹窗是重灾区，我通常在每条用例前用xcrun simctl privacy reset命令重置隐私权限，或者真机上预先打开所有权限再跑。iOS不同版本弹窗样式有细微变化，所以即便系统更新周期集中，也不能完全跳过版本回归。

3. 测试工具链：从命令行到可视化面板

3.1 Android的六大件：ADB、Logcat、Monkey、UIAutomator2、Profiler、Battery Historian

Android测试最强大的地方是ADB（Android Debug Bridge），它给测试带来的便利是iOS完全比不了的。下面是我几乎每天都用的命令：

# 抓取App运行日志 adb logcat -v time > app.log # 查看当前Activity adb shell dumpsys activity top | grep ACTIVITY # 查看App内存占用 adb shell dumpsys meminfo <package_name> # 模拟点击、滑动、输入 adb shell input tap 500 1200 adb shell input swipe 500 1500 500 300 adb shell input text "hello" # 启动App并测量冷启动时间 adb shell am start -W -n <package>/<activity> # 查看CPU和功耗相关信息 adb shell dumpsys cpuinfo adb shell dumpsys batterystats

Monkey用来做压力测试和稳定性测试，虽然原始但非常好用，可以通过--pct-touch、--pct-motion、--pct-appswitch调整事件比例：

adb shell monkey -p <package_name> --throttle 400 --pct-touch 50 --pct-motion 20 --pct-appswitch 10 -s 12345 10000

UI自动化的基础是UIAutomator2或UIAutomatorViewer，通过resource-id、text、className定位元素。Appium在Android端默认驱动就是UIAutomator2，所以了解它的工作逻辑对调脚本很有帮助。Android Studio内置的Profiler可以实时查看CPU、内存、能耗、网络，配合LeakCanary做内存泄漏检测，基本覆盖日常性能测试需求。Battery Historian分析耗电曲线是Android的独门绝技，iOS想拿到同等粒度的电池数据非常难。

3.2 iOS的Xcode全家桶：XCTest、Simulator、Instruments、simctl

iOS测试的核心工具链围绕Xcode展开。XCTest是苹果自家的单元测试和UI测试框架，XCUITest用来写UI自动化。Appium在iOS端的底层驱动就是XCUITest，所以本质上两端自动化最终都落到系统原生框架上。

iOS模拟器（Simulator）对日常功能测试很友好，尤其在网络、转发、键盘等场景下比真机稳定。但注意，iOS模拟器不是“手机模拟”，它是运行在Mac上的一个App进程，CPU、GPU、推送、传感器行为都依赖Mac硬件，所以绝不能替代真机做耗电、发热、相机、定位相关测试。

xcrun simctl是命令行管理模拟器的利器，我常用的命令：

# 列出所有模拟器 xcrun simctl list devices # 启动模拟器 open -a Simulator --args -CurrentDeviceUDID <UDID> # 安装App到模拟器 xcrun simctl install booted <path_to_.app> # 启动App并传入URL Scheme xcrun simctl openurl booted "myapp://home" # 重置隐私权限 xcrun simctl privacy booted reset all # 模拟推送 xcrun simctl push booted <payload.json>

Instruments是iOS性能测试的主力，Core Animation工具看FPS和图层合成，Leaks工具查内存泄漏，Energy Log看耗电，网络工具看流量。但说实话Instruments的学习曲线比Android Profiler陡得多，数据导出和二次处理也没那么方便。如果你只是要快速定位问题，优先用Xcode的Debug Gauges或者第三方工具PerfDog，效率会高很多。

3.3 崩溃日志的两个世界：tombstone和symbolicatecrash

Android崩溃日志可以通过Logcat或DropBox拿到，关键堆栈在AndroidRuntime的异常输出里。如果是系统级native崩溃，还要看tombstone文件。iOS崩溃日志有两种获取方式：Xcode的Devices窗口直接导出.crash文件，或者用户设备上的“隐私 > 分析与改进 > 分析数据”里找到崩溃记录。拿到.crash文件后，需要用symbolicatecrash工具把十六进制地址符号化：

# 找到symbolicatecrash工具 find /Applications/Xcode.app -name symbolicatecrash # 符号化崩溃日志 ./symbolicatecrash -o symbolicated.crash raw.crash app.dSYM

我的体会是：Android的崩溃堆栈即使没有符号化也经常能直接看到原因，iOS的崩溃日志很多时候地址居多，不符号化基本没法看。所以iOS每个正式版本打包时一定要保留dSYM文件并做好归档管理，否则过两个月去翻崩溃日志，根本对不上是哪个版本的堆栈。

4. UI自动化测试：同样的脚本，不同的世界

4.1 元素定位：resource-id、text与accessibility id

Android的UI自动化核心定位方式是resource-id、text、content-desc、className、xpath。特别方便的一点是，Android的TextView直接暴露text属性，Appium里用text("登录")就能定位，还可以通过"//*[@text='登录']"写XPath。

iOS的元素定位主要依赖accessibility id、label、value、name这些辅助功能属性。iOS的控件原生没有一个统一的text属性，很多时候label就是开发者设置的accessibilityLabel，Appium里要用name或label来定位。如果开发没设置好accessibility标识，iOS自动化脚本写起来非常痛苦，基本只能靠XPath硬解析控件树，嵌套几百层的情况我都见过。

所以两端自动化有一个重要前置动作完全不同：Android端可以让测试人员直接看控件树，iOS端务必在开发排期里加一条“完善accessibilityLabel”，否则脚本质量直接打折。真实案例：我们曾把一个自动化脚本从Android迁到iOS，同样的“点击登录”动作，Android脚本5分钟跑通，iOS脚本改了整整一天，原因就是所有按钮都没设置accessibilityLabel，最后用坐标点击临时垫上去，但脚本非常脆，换一个机型就废。

4.2 弹窗、权限与手势处理：两端测试的“重灾区”

弹窗处理两端逻辑完全不一样。Android端弹窗风格多样，厂商ROM还会替换系统弹窗样式，匹配“允许”文本时，可能这台手机上显示“始终允许”，另一台显示“仅在使用时允许”。iOS端的权限弹窗统一，但问题是一旦出现就会中断自动化序列，每次弹窗都只能响应一次，频繁误触还会吞掉真实告警。

iOS的隐私权限复位是个老大难。真机测试时，如果某轮测试里点了“不允许”，之后同一轮流程里再也不会弹，只能去“设置 > 隐私”手动重置。建议iOS自动化脚本的setup段调用xcrun simctl privacy booted reset all，模拟器上特别好用；真机上则建议测试前让开发提供一个“还原权限”的测试入口，或者测试包预置所有权限。

手势操作方面，Android的input命令和Appium的TouchAction支持坐标点、长按、滑动、多指操作，自由度高。iOS的多点触控模拟要复杂一些，Appium的W3C Actions支持touchAction，但多指手势、特殊交互最好真机手测。我一般把自动化重点放在核心流程，特殊手势比如iOS的上滑关后台、左滑返回、下拉呼出通知中心，不放在脚本里，统一人肉验证。

4.3 等待策略与元素可见性：隐性超时的经典坑

Android和iOS对“元素是否可见”的解释有差异。Android的控件树里元素存在但未显示，通常还留在当前窗口层级；iOS的XCUITest对元素是否hittable的判断更严格。我遇到过这样的Case：iOS上从列表页跳到详情页时，新页面元素已经出现但还没完成动画，立刻点击会报“element is not hittable”；Android端则无感，直接点就行。解法是加显式等待的同时，额外轮询判断点击坐标是否可交互。这类细节是实打实踩过坑才知道的，没趟过的人第一次看到报错往往一脸懵。

另外，Appium在两端首屏加载时对“wait for app ready”的处理节奏也不同，iOS的默认隐式等待往往比Android更敏感。我现在组内自动化规范里就一条硬性要求：所有关键操作前必须写显式等待，不允许裸findElement后直接click，两端共用一套基础封装，再为iOS单独补充hittable检测。

5. 网络抓包与弱网测试：代理、证书、信任链条

5.1 HTTP/HTTPS抓包：Android的证书信任问题 vs iOS的描述文件流程

抓包是测接口、排查线上问题的基础操作，Android和iOS的配置差异非常大。

Android端在Android 7.0之前，把抓包工具的根证书装到用户证书区，Charles/Fiddler就能解密HTTPS。但Android 7.0开始App默认不再信任用户级CA证书，除非App配置了networkSecurityConfig允许用户证书，或者App是debug包并设置了debug-overrides。所以很多App抓包失败，本质上是App自己把用户证书认证关掉了。

实操方案有三条路：

• 用debug包并在networkSecurityConfig里允许用户证书，这是最干净且推荐的方式。
• 把抓包证书装成系统证书，这需要root权限，或用已root设备，还要考虑高版本Android对root的兼容问题。
• 用Frida等工具动态绕过证书校验，但这属于深度调试，不适合日常接口核对。

iOS的流程相对固定：先安装抓包工具的描述文件，再到“设置 > 通用 > 关于本机 > 证书信任设置”里把证书设置为完全信任。iOS 10.3之后必须手动信任，iOS 14以上首次连接还要给抓包工具开“本地网络”权限。我第一次操作iOS抓包时，Charles抓到一大堆CONNECT成功但HTTPS全是乱码，其实就是忘了到证书信任设置里打开开关。

排查思路：抓包出现“SSL handshake failed”或明文是乱码，优先检查证书信任级别；如果只出现CONNECT但没有具体请求，检查iOS本地网络权限；如果完全连不上代理，检查App是否做了代理检测，很多金融类App会检测系统代理并拒绝连接。

5.2 弱网模拟：从ADB命令到Network Link Conditioner

弱网测试的场景很多：电梯、地铁、弱信号小区、跨机房网络。Android上模拟弱网最常用的是Charles的Throttle Setting和Fiddler的模拟调制解调器速度，但这两个工具只对HTTP流量生效，对UDP、WebSocket、DNS解析部分的模拟不彻底。更底层的方式是Linux的netem工具，Android设备如果能root，可以用tc命令直接加延迟和丢包：

# 添加100ms延迟和10%丢包 tc qdisc add dev wlan0 root netem delay 100ms loss 10%

iOS端的标准弱网工具是Xcode自带的Network Link Conditioner，在开发者选项里可以设置高延迟、低带宽、有损网络配置。另外，Proxyman、Charles这类工具也能统一做弱网模拟，但不能完全模拟真实基站的信道拥塞。

我的经验是：弱网测试不必追求极度精确的网络参数，更重要的是覆盖“加载中状态展示”“超时重试机制”“弱网下的数据一致性”这三个场景。两端在弱网下的行为差异值得重点记录：Android端很多App用OkHttp，断网重连时默认有连接池复用和失败重试逻辑；iOS端用URLSession，超时策略和缓存策略更依赖系统默认值，如果不主动设置，很多接口在弱网下会出现“一直转圈不返回”的现象。

6. 性能与兼容性测试：除了跑分，还要看真实体验

6.1 Android与iOS性能监控差异：Profiler、Instruments、Battery Historian

性能测试的指标大同小异：CPU、内存、FPS、启动时间、卡顿率、耗电、流量。但两端的采集手段和准确度差距不小。

Android端用ADB一条命令就能拿到内存和CPU快照，但要注意dumpsys meminfo的数据是Java堆、Native堆加图形内存的综合值，只看total往往掩盖问题。我一般会再拆细看Native Heap和Graphics，图形内存暴涨的场景，通常是Bitmap没释放。Android的FPS测试可以打开“开发者选项 > 调试GPU过度绘制”，或者用PerfDog这类插桩工具采集，启动时间用am start -W可以直接拿到Displayed时间。

iOS端Instruments功能强，但操作门槛高。Core Animation工具看每秒帧数和GPU渲染负载，Leaks工具查循环引用和内存泄漏，Energy Log统计后台耗电。iOS的耗电测试建议真机加Xcode的Energy Log，模拟器的电池数据参考意义不大。冷启动时间建议用Xcode的启动分析工具或Instruments的App Launch模板，真机测试时每次冷启动都要先杀掉App进程再启动。

PerfDog在两端都能用，如果团队没有自建性能监控平台，先用它做外部对比性价比较高。它在抓FPS和CPU数据时的稳定性比很多老工具都好，尤其是游戏类和视频类App。

6.2 模拟器与云真机：覆盖和效率的平衡

模拟器在开发调试阶段效率极高。Android模拟器基于QEMU，可以模拟任意API level和屏幕规格；iOS的Simulator启动快，但和真机的CPU、GPU、推送、传感器行为差异很大。我的原则是“功能用模拟器、核心流程必须上真机”。

Android因为碎片化严重，建议优先使用云真机平台，WeTest、Testin、阿里云移动测试等都有大量机型的真机池，跑兼容性时一键分发几百台。云真机能节省硬件成本，但要注意云真机的网络环境、传感器模拟和真实用户操作仍有差距，性能数据不能完全当基准。

iOS真机选择相对简单：一台iPhone SE或小屏、一台iPhone Pro Max或大屏，再加一台旧系统机型就够了。但如果涉及推送、蓝牙、相机、定位、刘海/灵动岛遮挡这些能力，必须真机验证。一个经典坑是：iOS模拟器不会真正弹出系统级权限管理界面，很多权限相关的UI bug在模拟器上测不出来，比如“首次启动弹出位置权限时，弹窗是否遮挡按钮”这种问题。

7. 发布前的最后一道关：分发、测试与审核

7.1 Android的多渠道分发与灰度测试

Android的发布路径多样，测试也相应复杂。正式发布前通常需要做多渠道打包，常见渠道包括华为、小米、OPPO、vivo、应用宝、360等，每个渠道的包都要验证版本号、渠道号、下载来源统计、SDK初始化是否正常。用Gradle定制好渠道包参数后，测试环境里用“渠道ID=test”区分。

灰度测试方面，Android可以用蒲公英、fir.im这类平台上传测试包，也可以直接在应用市场配置灰度。蒲公英这类平台的优势是扫码安装、线上收集崩溃日志、查看安装量。但要注意，很多平台对安装包的大小和签名有要求，如果你的App做了加固，还要先验证加固后的包是否能在目标机型上正常启动，这个环节经常出问题。

Android还有一个“侧载安装”的问题。测试时从本地直接adb install，从网盘下载APK，这些安装方式覆盖面广，但也容易装到被二次打包的包。建议测试团队固定用官方签名包，并且在测试机上关闭“未知来源”限制，避免测试环境和真实用户的安装源不一致。

7.2 iOS的TestFlight与App Store审核

iOS的测试分发主要靠TestFlight。TestFlight分内部测试和外部测试，外部测试还需要经过一次Beta审核。测试人员需要安装TestFlight App，或通过公共链接邀请。TestFlight使用App Store Connect账号体系，无需测试人员注册开发者账号，但外部测试名额有上限、版本有效期90天、新版本需要重新上传和审核。

TestFlight的优势是可以保留崩溃日志、用户反馈、使用情况分析；缺点是版本审核需要时间，不适合快速迭代。实际工作流里，我一般把TestFlight留给“准生产环境”的验收测试，日常开发联调用Xcode本地调试或Ad Hoc分发更高效。

iOS上架前还有一整套合规测试要点：权限描述文案必须和实际使用一致，隐私政策必须明确，推送需说明用途，账户注销流程必须可用。2022年后苹果对注销功能的要求越来越严，没有注销入口的App会被打回。测试阶段就要把这些当成硬性检查项。我的习惯是维护一份“上架自检清单”，每次提审前逐项勾选，比临时翻审核指南靠谱得多。

8. 常见问题与排查技巧实录

8.1 App抓包失败的常见原因速查

抓包失败是测试群里几乎每天都在问的问题，整理一个速查表：

避坑建议：团队内部准备一台专门用于抓包的Android备机（可root或旧机型），再留一台iPhone专门装抓包证书，不要拿日常手机反复折腾证书。否则某天访问公司后台时SSL error，还被拦在客户环境里，那就太尴尬了。

8.2 自动化脚本在两端表现不一致的排查思路

我遇到最多的自动化问题是“同样的脚本Android通过、iOS挂掉”，或者反过来。排查顺序一般是：

• 先看元素定位方式是否适配两端：Android用resource-id/text，iOS要用accessibility id/label。如果一个定位在两端都能写，多半是开发统一做了无障碍适配；如果没有，优先让开发补。
• 再看等待策略：iOS的动画默认时长较高，滑动惯性大，跨页面转场时间更长。Appium在iOS端的隐式等待和Android不完全一致，建议统一用显式wait。
• 然后看系统弹窗：iOS的权限弹窗和系统键盘都会抢占焦点；Android的厂商弹窗（比如华为的“是否允许安装未知应用”）也会打断流程。建议在脚本开局统一处理前置弹窗。
• 最后看坐标与屏幕比例：如果脚本用了绝对坐标点击，在两端设备上完全不可移植，必须改成按屏幕宽高比例计算，或干脆改用元素定位。

还有一个经常被忽略的点：Android和iOS的字体渲染差异导致文本长度不同，造成按钮文案截断、溢出、对齐错乱。同样的中文文案，iOS上因为系统字体的字重和间距，经常比Android上长10%到20%。UI自动化里的“断言文案等于XXX”在两端可能都不成立，建议改成“包含关键文案”而不是“完全相等”。

8.3 时间、网络与系统权限的隐性差异

时间测试：Android上修改系统时间后，App内的时间戳和行为逻辑变化通常能立刻生效；iOS对系统时间变更更敏感，尤其依赖APNs和证书有效期的场景，调时间可能导致App无法启动或证书校验失败。我建议时间相关测试在两端都跑一遍，但注意iOS上不要在真实登录态下乱调时间，可能导致远程会话失效或账号被临时锁定。

网络环境差异：Android更容易被系统或厂商限制后台联网，iOS默认更宽松，但开启低电量模式后很多后台任务会被系统暂停。测试耗电和联网行为时，记得把“低电量模式”作为一个独立测试条件，这个场景在日常测试里最容易被忽略。

权限重置：Android的运行时权限重置方式是adb pm grant/revoke，iOS用xcrun simctl privacy reset。真机上iOS权限无法用命令直接重置，只能手动去设置里操作，所以iOS自动化最好优先在模拟器上跑权限相关用例，真机专注回归不涉及权限的流程。

这些细节，都是我在不同项目里一个个趟出来的。做Android和iOS平台测试，核心不是把两边做得一样，而是把两边的差异变成用例设计的武器。对刚入行的测试新人，我建议先在一台Android中端机和一台iPhone上分别完整走一遍核心流程，记录所有“看起来不对劲”的地方，再回头对比两边的测试方法选择——你会发现，平台的边界就是测试的边界，理解了边界，也就理解了为什么这个行业永远缺不了真正干过平台测试的人。