测试¶

在测试拉取请求（PR）时，如果遇到意外行为，重要的是确定该问题是由 PR 引入的，还是本来就存在于基础代码中。为此，请将行为与基准 master 分支进行比较。

即使在问题发生之前，最佳实践也是保持相同的设置并删除着色器缓存。使用已有的着色器缓存可能会在极少数情况下让 PR 看起来像是出现了回归。

尽量不测试针对文档或极其琐碎变更（例如更改应用图标的 PR）的 PR，除非你确实想测；通常应避免任何标记为 [docs] 的 PR。

如果 PR 指明针对特定平台（即 linux），那么只需在 Linux 上测试。如果它写明 NCE，则在 Android 和 Linux ARM64（树莓派等）上测试。macOS 修复也可能影响 Asahi，如果可以的话也测试一下。

你也可以自行构建产物，但要注意，由于软件包版本和构建环境的差异，生成的构建与 CI 的构建并不相同。一个著名的例子是 FFmpeg 由于打包差异而在许多 Arch 发行版上随机损坏。

快速入门¶

可以把源代码想象成一棵“树”，这棵树的“树干”是我们的 master 分支，任何其他分支都是 PR 或独立的开发分支；只有我们的稳定版本会从 master 拉取——所有其他分支都被视为不稳定版本，不建议拉取，除非你同时测试多个分支。

这里有一些你可能需要熟悉的术语：

• PR：拉取请求，即代码库中的一项更改；该更改的作者（程序员）请求将该分支拉入 master（基本上是让新代码进入某个版本）。
• Bisect：搜索回归的二分查找方法；有些回归可能是偶发的，无法进行二分，但绝大多数回归都可以。
• WIP：进行中的工作（Work-in-progress）。
• Regression：由新代码导致的新 bug 或故障，例如“在提交 xyz 之后，Zelda 在 Android 上出问题了”。
• Master：“根”分支，所有合并后的代码都会进入这里，传统上称为 main、trunk 或简称为 master，它包含最终进入稳定版本的所有代码。
• HEAD：给定分支中的最新提交；master 的 HEAD 即 master 分支上的最新提交。
• origin：默认的“远程（remote）”，基本上就是 git 所在的 URL；大多数时候该位置是 https://git.eden-emu.dev/eden-emu/eden。

测试清单¶

针对 PR 或提交中的回归/bug：

• [ ] 是否出现在 master 中？
  • 如果出现在 master 中：
    • [ ] 是否出现在上一个稳定版本中？（在该特定 PR 之前）。
      • 如果出现在上一个稳定版本中：
        • [ ] 是否出现在上上一个稳定版本中？
          • 依此类推……有些 bug 早在 Eden 诞生之前就存在了。
      • 否则，尝试在上一个稳定版本与 master 的最新 HEAD 之间进行二分
        • [ ] 是否出现在给定提交中？
• [ ] 是否出现在 PR 中？
  • 如果出现在 PR 中：
    • [ ] 是否对 PR 进行了二分？（如果它有多个提交）
    • [ ] 是否找到了二分出来的提交？

如果某个问题偶发出现，请尝试多次运行；如果可能，请统计它失败的次数和“正常运行”的次数。假设它正常了 3 次但失败了 1 次，那么每次运行有 1/4 的概率复现该问题——因此每个二分查找步骤都需要运行 4 次，以确保至少有可能触发该 bug。

当出现异常时该怎么办¶

如果在测试过程中注意到异常：

• 使用基准 master 分支复现该问题。
• 观察相同的行为是否出现。

由此可能出现两种结果：

• 如果问题存在于基准 master 中：这意味着该问题在 PR 之前就已经存在。PR 很可能没有引入回归。
• 如果问题不存在于基准 master 中：这表明 PR 很可能引入了回归，需要进一步调查。

报告你的发现¶

当你报告结果时：

• 清楚说明该行为是否在基准 master 中观察到。
• 说明结果是良好（预期行为）还是不良（意外或损坏行为）。如果不说明你的帖子/报告/日志是良好还是不良，可能会让 PR 的开发人员感到困惑。

例如：

1. “PR 结果不良：已在基准 master 上测试——问题不存在。很可能引入了回归。”
2. “PR 结果良好：已在基准 master 上测试——问题已经存在。不是回归。”

这种方法有助于在测试过程中保持清晰度和责任感，并确保回归能被高效地发现和处理。

如果某个游戏/功能的行为看起来正常，那么不一定每次都需要对照基准 master 进行检查。

这种方法有助于在测试过程中保持清晰度和责任感，并确保回归能被高效地发现和处理。如果某个游戏/功能的行为看起来正常，那么不一定每次都需要对照基准 master 进行检查。

如果不存在针对 PR 所基于的 master 的构建，那么测试附近过去和未来的构建会很有帮助。这将有助于收集更多关于问题的信息。

根据需要始终包含 调试信息。

二分查找¶

一个温馨提示：测试时，要会二分查找！

假设你想找出 1 月 1 日到 1 月 8 日之间的问题，你可以通过将每次提交之间的时间“对半”划分来搜索：

• 检查 1 月 4 日
• 如果 1 月 4 日“正常”，那么问题一定在之后
• 于是检查 1 月 6 日
• 如果 1 月 6 日不正常，那么问题一定在之前
• 于是检查 1 月 5 日
• 如果 1 月 5 日正常，那么问题始于 1 月 6 日

那么有问题的提交就是 1 月 6 日。这叫做二分查找 https://git-scm.com/docs/git-bisect

备注¶

• 标有 WIP 的 PR 无需测试，除非被明确要求（如有疑问，请查看 git）。
• 有时许可证检查可能会失败，请将鼠标悬停在构建图标上，查看构建是否确实成功，因为 CI 即使在许可证检查失败时也会推送构建。
• 所有开放的 PR 均可在此查看。
• 如果站点无法访问，请使用其中一个镜像。