检查完整动作顺序和最终状态

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

邮件界面的“新邮件”按钮需清空选中会话并打开撰写面板。教学动作selectThread(null)同时把composeOpen设为false；因此先打开再清空会话会使面板重新关闭。

具体做法

找到按钮处理器，按执行顺序列出每个调用读取、设置、重置的状态及异步副作用。对照用户期望的终态：thread=null且composeOpen=true。按实际契约先清空再打开，或用一个一致的状态转移。等待相关异步工作完成后核对状态和可见面板，并测试从已有会话、无会话两种入口。

反例

修复“新邮件”：先setComposeOpen(true)，再selectThread(null)。只要打开setter执行就认为按钮成功。

改进写法

按动作契约检查整个新邮件处理器。selectThread(null)会重置composeOpen，所以先清空会话再打开；执行完整序列后断言thread=null、composeOpen=true，面板可见且焦点落在预期输入。也检查后续异步回调是否又关闭面板。

为什么这样改

局部动作正确不代表完整交互正确。动作效果图能显示后续重置覆盖前面设置的位置；终态与可见行为将验证目标绑定到按钮承诺。

如何验证

教学旧轨迹false→true→false，最终面板关闭；新轨迹先清空再打开，最终true。测试已有会话和空会话，确认均可撰写；人为加入延迟重置时，回归检查应失败并指出后续动作。

适用边界

重新排序可能改变草稿、选中项和焦点等其他效果，应按产品契约一起验证。异步竞态可能需要取消、版本判定或统一转移，单纯调换同步调用不足以修复所有问题。来源动作名仅是示例，先读取目标应用的真实实现。