![Ubuntu 团队是如何进行自动化测试的?](https://linux22.com/image/1052639/Ubuntu%20%E5%9B%A2%E9%98%9F%E6%98%AF%E5%A6%82%E4%BD%95%E8%BF%9B%E8%A1%8C%E8%87%AA%E5%8A%A8%E5%8C%96%E6%B5%8B%E8%AF%95%E7%9A%84%EF%BC%9F.png)
Ubuntu 团队如何保证不再出现 Bug?
我已经见过好几次了。安装后,软件包无法使用。
是的,有时候错误会很快被修复。
但我看不到任何改进自动化测试的努力,以便该错误不会再次出现。
以下是过去两周对我影响较大的两个例子:
- https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/1219857
- https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847
还有更多例子,但列举它们并不是问题的一部分。
来自错误页面的一条评论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
有很多种方法。
很多双眼睛。
Ubuntu 是开源的,这意味着任何人都可以查看代码并发现问题所在。有兴趣查看代码的人经常会发现其中的错误,或者在使用它时,在启动板上报告他们和公众甚至可以修复它们。
当您测试并提出修复建议后,您请求将其与 Ubuntu 主软件包合并。其他开发人员会审核此更改,如果获得批准,则会将其添加进去。
因为任何人都可以修复它们,所以它们会很快被发现,并被审查,它们不太可能停留一段时间。这引出了下一点。
这些眼睛还包括电脑眼睛:
上游 QA 流程必须记录/演示,并链接到 SRU 跟踪错误。在其他无法进行此类上游自动测试的情况下...
这表明自动测试通常已经到位。
Beta 版本
在 Ubuntu 正式发布之前,会推出一些测试版本。目前是 15.10 Beta 版,2015 年 10 月 22 日发布。在发布之前,许多人都会使用、审查和修复错误(例如5个月22天在这种情况下)。
这意味着任何错误都会被迅速删除(因为 Many Eyes),并且普通用户不会受到影响,因为它在正式发布之前就被修复了。
代码编写专家
善于编写高质量代码的人就是编写代码的人。并不是只有一个人坐在这里像这样编写 Ubuntu:
这里有来自世界各地的人,也有 Ubuntu 背后的公司 Canonical 的员工。所有这些人都贡献了一些新代码。如果我写了 2000 行代码,就会有很多错误。如果 200 个人只写了 10 行,错误就会少很多。
稳定的基础
据我所知,Ubuntu 每次发布新版本时都不会从头开始重写。相反,下一个版本从当前版本开始(即 2015/04/30 时 15.10 和 15.04 相同),并从那里添加新功能。
如果你有一个良好的基础,那么你需要编写的代码就会少一些,并且可以信任现有的代码。如果你可以依赖现有的代码,那么就会出现更少的错误。
版本控制和记录软件
如果同一个错误出现多次(在不同的版本中,或者修复不起作用,或者由于另一个补丁程序而再次出现该错误),那么他们有文档来解释如何修复它 - 并且他们可以再次修复它。
据我所知,没有自动化测试。但什么是自动化测试?如果它编译通过,那就是自动化测试吗?你不能只说“自动化测试”,而不解释它是什么
答案3
不要写有 bug 的代码。哈哈,好吧。我失去了写详细回应的意愿。这是一篇不错的文章: https://www.iiitd.edu.in/~jalote/papers/CommonBugs.pdf
这是一本关于制作的好书C++中的错误
最好的答案可能是只进行一些软件开发任务,然后亲自查看问题来自何处。根据我的经验,处理意外的输入/结果是一个非常大的问题。然后是下游错误。例如,有人在 iostream.h 中发现了一个漏洞,那么调用该库的每个软件也可能存在该错误,至少需要进行审查。
至于自动化测试,它确实存在,但也有局限性。我不知道有哪一种解决方案适用于每种语言。如果你真的感兴趣,请为我们编写一个带有一些人工智能的遗传密码调试器。据我所知,所有这些都还处于起步阶段,以下是一些博士生的工作: https://www.cs.cmu.edu/~clegoues/docs/legoues-icse09.pdf