作为普通用户，为什么以及如何有效地测试 R 的 beta 发行版？

Question

这个问题的灵感来自于 Duncan Murdoch 在 r-devel 邮件列表上回应有关 Sweave 的错误报告时的评论：

这已在 R 补丁中修复。 （这会 已在 2.12.0 中修复（如果更多） 人们测试了测试版...）。

老实说，出于多种原因，我一直远离测试版（又名开发版），这些是我从更多人那里听到的原因：

1. 我有点害怕它会 不知何故与我发生冲突 当前 R 分布。当我需要的时候 对于工作来说，必须定期修理它会造成损失 有时我无法向老板解释，
2. 我不知道如何测试 高效。我认为我的每一次测试 可以想出已经 由开发团队运行。
3. 我还是觉得很难弄清楚 当出现错误时，并且 当（大多数情况下）是我自己的时候 但据我了解，这将是对 R 社区的宝贵贡献，如果我能以某种方式将其融入我自己的工作中，

我也愿意做我的测试。我正在考虑保留测试版并通过它运行我的脚本并进行检查。保存构造的对象可以快速轻松地使用 all.equal() 来查看是否有问题。

有人对我如何以最小的努力和最大的效率帮助测试有更多/更好的想法吗？

我也想在我们部门多宣传一下这一点。除了“是时候回馈社区了”之外，还有其他充分的理由说明测试 Beta 版值得付出努力吗？我该如何反驳上面给出的论点？

编辑：

正如 Dirk Eddelbuettel 在评论中指出的那样，部分原因是防止 Windows 中的路径变量。我对此有一些想法，但也非常感谢有关如何实际组织计算机来测试 R-devel 版本的指导。

Answer 1

我怕你误会了。一开始这可能并不简单或明显，所以也许这会有所帮助：

• “修补”不是“测试版”。修补了 R 2.12.1。

• 没有冲突。它在 2.12.0 中下降。

• 它是一个单独的下载，并且是夜间构建可从此处获取< /a>.

• 这不是 r-devel，而是 r-patched。

• 作为用户，测试预发布版本也是我们的责任。因此，如果有的话，理想的情况是，您将安装 R 补丁 --- 以及 R-devel！

• 测试可以像安装另一个版本一样简单，将其保留在路径之外，然后从脚本动态调整 PATH 和 R_HOME。测试意味着在您的代码和数据上运行它，以防止您在新代码发布后被错误困扰。

Answer 2

我不知道如何有效地进行测试。我认为我能想到的每一个测试都已经由开发团队运行过。

我仍然发现很难弄清楚什么时候某件事是一个错误，什么时候（大多数情况下）这是我自己的愚蠢行为。

问题是，软件不会（或不仅仅是）被开发人员使用。它将由可能根本没有编程知识的人使用（我一般来说，这对于 R 以及任何其他软件都有效）。

如果帮助或界面或软件构建的一般方式没有为您提供有关如何做某事的足够信息，那么，这可能不是一个错误，但它是可以改进的（并向开发人员指出） ）。

另外，请记住，软件是由开发人员编写的。他们知道如何使用它，并且通常他们在测试它时会有偏见，主要是通过正确使用它来查看它是否给出了良好的结果，而不是“试图破坏它”。

通过以您自己的方式使用它（这可能是“不正确的”），您可以有效地运行可能逃脱开发人员的测试，只是因为他们没有考虑像您一样使用它。