☰

Ubuntu 团队是如何进行自动化测试的？

tag-icon • tag-icon canonical quality
Ubuntu 团队是如何进行自动化测试的？

Ubuntu 团队如何保证不再出现 Bug？

我已经见过好几次了。安装后，软件包无法使用。

是的，有时候错误会很快被修复。

但我看不到任何改进自动化测试的努力，以便该错误不会再次出现。

以下是过去两周对我影响较大的两个例子：

还有更多例子，但列举它们并不是问题的一部分。

来自错误页面的一条评论vsftp：

请帮助我们测试这个新包。请参阅https://wiki.ubuntu.com/Testing/EnableProposed有关如何启用和使用 -proposed 的文档。您的反馈将有助于我们将此更新推送给其他 Ubuntu 用户。

好的，但是上面引用中的“测试”是手动的测试。

确保质量自动化需要进行测试。

对我来说，手动测试很浪费时间。另一方面，构建自动化测试确实可以确保质量。

这里又出现了一个问题：

Ubuntu 团队如何确保 Bug 不再出现？

这个问题的历史

最初的标题是“Ubuntu 团队如何确保错误不再出现？”。现在的标题是“Ubuntu 团队如何进行自动化测试？”。之所以这样做，是因为我认为手动测试不是解决方案。请不要对仅解释手动测试方式的答案投反对票。

答案1

Ubuntu 确实有自动测试。例如，自动测试用于防止您的第一个错误示例再次发生。我就是那个修复您提到的第一个 vsftpd 错误的人，在修复过程中，我还添加了一个自动测试，以防止同样的事情再次发生。您可以在发布到错误本身的更改日志条目中看到这一点：

vsftpd (3.0.2-1ubuntu2.14.04.1) trusty; urgency=medium

  * d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging
    calls (LP: #1219857).
  * Add dep8 smoke test.
 -- Robie Basak <[email protected]> Tue, 29 Apr 2014 15:33:07 +0000

我不知道您为什么认为该错误是缺乏自动化测试的一个例子，因为我在该错误中多次提到这一点。例如，我在摘要中说“添加了 dep8 测试以在将来检测此问题”和“包含的 dep8 测试会自动验证此错误的修复”。

请记住，Ubuntu 是一个发行版：它是许多外部项目的集成集合，我们称之为上游。如果没有更广泛的自由软件生态系统中其他人的努力，Ubuntu 就不可能实现，同样，我们经常依赖上游作者提供测试，因为他们是其软件方面的专家。

此外，由于我们是不同项目的集合，因此单一的自动测试基础设施是没有意义的。不同领域有不同的需求。因此，我们的测试策略非常广泛，可以满足这些需求，通过多种不同的基础设施涵盖手动和自动测试。

如果上游项目提供自动化测试，我们会将其作为软件包构建的一部分运行。如果测试未通过，软件包构建将失败。确保以这种方式启用任何可用的自动化测试是我们主要纳入要求：如果软件包附带测试套件，并且没有明显的原因导致它无法在构建期间工作（例如，它需要 root 权限或网络访问），则应在软件包构建期间运行它，并且失败的测试套件应该导致构建失败。

此外，我们根据名为dep8，用于测试软件包之间的集成是否正常工作。回归 dep8 测试的软件包更新在修复之前不会进入开发版本。

我对桌面和手机团队所做的自动化测试不太熟悉，但我知道存在更多机制，因为多年来我看到过对它们的引用，其中包括自动化 GUI 测试，我认为这非常令人印象深刻。我欢迎另一个涵盖自动化桌面和手机测试的答案。

答案2

有很多种方法。

  1. 很多双眼睛。

    Ubuntu 是开源的，这意味着任何人都可以查看代码并发现问题所在。有兴趣查看代码的人经​​常会发现其中的错误，或者在使用它时，在启动板上报告他们和公众甚至可以修复它们。

    当您测试并提出修复建议后，您请求将其与 Ubuntu 主软件包合并。其他开发人员会审核此更改，如果获得批准，则会将其添加进去。

    因为任何人都可以修复它们，所以它们会很快被发现，并被审查，它们不太可能停留一段时间。这引出了下一点。

    这些眼睛还包括电脑眼睛：

    上游 QA 流程必须记录/演示，并链接到 SRU 跟踪错误。在其他无法进行此类上游自动测试的情况下...

    这表明自动测试通常已经到位。

  2. Beta 版本

    在 Ubuntu 正式发布之前，会推出一些测试版本。目前是 15.10 Beta 版，2015 年 10 月 22 日发布。在发布之前，许多人都会使用、审查和修复错误（例如5个月22天在这种情况下）。

    这意味着任何错误都会被迅速删除（因为 Many Eyes），并且普通用户不会受到影响，因为它在正式发布之前就被修复了。

  3. 代码编写专家

    善于编写高质量代码的人就是编写代码的人。并不是只有一个人坐在这里像这样编写 Ubuntu：

    这里有来自世界各地的人，也有 Ubuntu 背后的公司 Canonical 的员工。所有这些人都贡献了一些新代码。如果我写了 2000 行代码，就会有很多错误。如果 200 个人只写了 10 行，错误就会少很多。

  4. 稳定的基础

    据我所知，Ubuntu 每次发布新版本时都不会从头开始重写。相反，下一个版本从当前版本开始（即 2015/04/30 时 15.10 和 15.04 相同），并从那里添加新功能。

    如果你有一个良好的基础，那么你需要编写的代码就会少一些，并且可以信任现有的代码。如果你可以依赖现有的代码，那么就会出现更少的错误。

  5. 版本控制和记录软件

    如果同一个错误出现多次（在不同的版本中，或者修复不起作用，或者由于另一个补丁程序而再次出现该错误），那么他们有文档来解释如何修复它 - 并且他们可以再次修复它。

据我所知，没有自动化测试。但什么是自动化测试？如果它编译通过，那就是自动化测试吗？你不能只说“自动化测试”，而不解释它是什么

答案3

不要写有 bug 的代码。哈哈，好吧。我失去了写详细回应的意愿。这是一篇不错的文章： https://www.iiitd.edu.in/~jalote/papers/CommonBugs.pdf

这是一本关于制作的好书C++中的错误

最好的答案可能是只进行一些软件开发任务，然后亲自查看问题来自何处。根据我的经验，处理意外的输入/结果是一个非常大的问题。然后是下游错误。例如，有人在 iostream.h 中发现了一个漏洞，那么调用该库的每个软件也可能存在该错误，至少需要进行审查。

至于自动化测试，它确实存在，但也有局限性。我不知道有哪一种解决方案适用于每种语言。如果你真的感兴趣，请为我们编写一个带有一些人工智能的遗传密码调试器。据我所知，所有这些都还处于起步阶段，以下是一些博士生的工作： https://www.cs.cmu.edu/~clegoues/docs/legoues-icse09.pdf

相关内容