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

Question

Ubuntu 团队如何确保不会再次出现错误？

我已经看过好几次了。安装后包无法使用。

是的，有时错误修复得非常快。

但是我看不到改进自动化测试的努力，因此该错误不会再次出现。

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

• https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/1219857
• https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847

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

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

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

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

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

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

这里又是一个问题：

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

这个问题的历史

首先标题是“Ubuntu 团队如何确保错误不再出现？”。现在是“Ubuntu 团队如何进行自动化测试？”。这样做是因为我相信手动测试不是解决方案。请不要对仅解释手动测试完成方式的答案投反对票。

Answer 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 <robie.basak@ubuntu.com> Tue, 29 Apr 2014 15:33:07 +0000

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

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

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

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

此外，我们根据称为dep8的规范运行“自动安装包测试”，该规范旨在测试包之间的集成是否正常工作。回归 dep8 测试的包更新在修复之前不会进入开发版本。

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

Answer 2

多种方式。

1. 许多眼睛。

   Ubuntu 是开源的，这意味着任何人都可以查看代码并了解问题所在。谁感兴趣的看代码的人常常会发现在它的错误，或者因为他们使用它，并在启动板报告他们与市民甚至可以解决这些问题。

   

   当您测试它并建议修复时，您请求与主 Ubuntu 包合并。其他开发人员审查此更改，如果获得批准，将添加它。

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

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

   必须记录/证明上游 QA 流程，并从 SRU 跟踪错误链接。在这种上游自动测试不可用的其他情况下......

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

2. 测试版

   在 Ubuntu 向公众发布之前，有测试版。目前是 15.10 Beta，将于 2015 年 10 月 22 日发布。很多很多人会在它发布之前使用、审查和修复错误（在这种情况下是5 个月 22 天）。

   这意味着任何错误都会被及时删除（因为众眼），并且典型用户不受影响，因为它在正式发布之前就已修复。

3. 专家代码编写者

   擅长编写高质量代码的人就是编写代码的人。不止一个人像这样坐着写 Ubuntu：

   

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

4. 稳定的基础

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

   如果您有一个良好的工作基础，那么您需要编写的代码就会更少，并且可以信任已经存在的内容。如果你可以依靠那里的东西，那么进入的错误就会更少。

5. 版本控制和记录软件

   如果相同的错误出现不止一次（在不同的版本中，或者修复不起作用，或者由于另一个补丁而导致错误再次出现）那么他们有文档来解释它是如何修复的 - 他们可以再次修复它.

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