Apple 发布首款可折叠 iPhone 后，移动端测试矩阵里出现了一个需要单独管理的变量：设备形态。
从官方信息看，iPhone Duo 包含 5.4 英寸外屏和 7.6 英寸内屏，支持闭合、展开、旋转和分屏等使用方式，并将搭载 iOS 27.1。对测试团队来说，关注点不应停留在两个 viewport 是否分别显示正常，而应转向形态变化过程中的业务状态、生命周期和资源恢复。
本文只讨论测试设计方法，不包含真机实测结论。
1. 先区分三类问题
静态布局问题
分别在内屏、外屏和不同方向上检查裁切、遮挡、缩放、弹窗、键盘与安全区域。
状态迁移问题
业务进行中改变设备形态，检查页面重建、导航栈、输入数据、请求状态和媒体进度。
多任务与资源问题
进入分屏、后台或再次回到全屏，观察焦点、音视频、网络连接、内存占用和任务恢复。
三类问题不能混为一组 “UI 兼容用例”。静态截图正常，只能说明某个时刻的布局没有明显异常，无法证明切换过程可靠。
2. 用状态迁移代替页面枚举
可以把一个测试节点表示为：
业务状态 + 显示形态 + 屏幕方向 + 窗口状态 + 系统版本
例如：
支付确认中 + 外屏 + 竖屏 + 单窗口 + iOS 27.1
触发 “展开设备” 后，检查目标状态是否满足：
- 当前业务步骤未回退；
- 表单和会话数据未丢失；
- 请求未被意外重复提交；
- 系统认证回调仍回到正确页面；
- 页面布局与焦点恢复正常。
这类用例适合优先覆盖长链路、不可逆操作、媒体任务和实时连接，而不是对所有页面做笛卡尔积。
3. 建议采用风险分层矩阵
| 优先级 | 场景 | 原因 |
|---|---|---|
| P0 | 登录、支付、交易提交、身份认证 | 状态丢失或重复请求可能直接影响业务结果 |
| P1 | 表单编辑、上传下载、音视频、实时对战 | 流程持续时间长，容易跨越形态切换 |
| P2 | 列表浏览、内容阅读、普通查询 | 主要验证布局、位置与返回状态 |
矩阵至少包含：
- 外屏启动后展开；
- 内屏使用中闭合；
- 展开状态旋转设备；
- 单窗口进入分屏再恢复；
- 前后台切换后改变形态；
- 低网速或请求处理中改变形态。
4. 金融和游戏可以怎样取样
金融 App 可以选择 “登录—查询—输入—认证—提交—结果” 作为主链路，重点观察安全键盘、生物认证、验证码、会话与幂等控制。这里的验证目标不是证明交易系统绝对安全，而是确认客户端在状态切换时没有引入明显的流程与数据风险。
游戏 App 可以选择 “启动—登录—进入场景—战斗或操作—切换形态—恢复” 作为主链路，检查画面比例、触控映射、音频焦点、网络重连、资源加载和帧率变化。性能结论需要明确设备、版本、场景、时长和指标，不能只凭主观流畅度判断。
5. 自动化放在哪一段更合适
自动化适合承担稳定、重复、判定明确的部分，例如：
- 多形态下的启动与核心流程冒烟；
- 固定页面的布局基线和关键控件检查；
- 形态切换前后的业务状态断言；
- 多版本、多轮次回归执行。
探索性测试仍然必要，特别是半展开、连续快速切换、手势冲突、触控舒适度和复杂多任务组合。现阶段还要根据开发工具实际开放的能力，评估哪些形态事件能够稳定驱动与观测。
在设备资源和执行层面，可以关注无缺智测 / Suprall 这类 “真机平台加兼容测试服务” 的方案，但选型时应重点确认：目标设备何时可用、是否支持所需形态操作、能否保留执行证据，以及自动化接口是否覆盖关键事件。
6. 上市前后的执行节奏
- iOS 27 推出后，先在现有机型上完成风险回归。
- 基于官方交互说明补充状态迁移用例。
- 工具支持到位后完成布局与生命周期预验证。
- 真机可用后执行触控、性能、认证、网络与探索性测试。
- 根据首轮缺陷更新回归集，而不是永久保留所有组合。
折叠态测试真正增加的不是一批截图，而是一套状态模型。把这个模型建好，后续面对更多形态设备时才有复用价值。
大家在可变窗口、分屏或折叠设备测试中，通常怎样触发状态变化、保留执行证据？欢迎分享现有方案和踩过的坑。