LWN: 2019 自动化测试峰会

点击上方蓝色“Linux News搬运工”关注我们~

The 2019 Automated Testing Summit

By Jake Edge
November 13, 2019


ATS

原文来自:https://lwn.net/Articles/804050/

Automated Testing Summit(ATS)今年的会议是第二次,并且是首次对外公开的,去年的ATS只面向邀请者,大概有35位开发者参加。今年的会议则吸引了50位左右的参会者。两次会议都是跟Embedded Linux Conference Europe (ELCE)一起举行的,去年在苏格兰爱丁堡,今年在里昂。基本来说面临的问题还是一样的,需要加强各种kernel testing system的合作,尽管进展缓慢,我们还是已经确定了起始阶段的重点,并且取得了一定的进展。进展缓慢,其中一个原因是因为各种测试系统都有不同的支持者和客户,因此合作的过程中绝对不能损坏这些人的利益。

Setting the stage

同上一次一样,本次的ATS也是由Tim Bird和Kevin Hilman组织的。Bird在致辞欢迎之后就把舞台交给了Hilman进行"kernel testing landscape"的综述。Hilman提到基于此前Linux Plumbers Conference (LPC)时候的很多讨论,他提炼出了一些话题,一句话来说就是“bugs are too fast (and why we can't catch them)”。

Tim Bird

首先他介绍了kernel里新的单元测试(unit-testing)框架。目前kernel test相关的项目包括kselftest,Linux Test Project (LTP),syzbot,还有其他一些。而新加的KUnit框架已经合入了linux-next,这个框架可以采用一种不依赖具体架构(architecture-independent)的方式来在user space测试一些kernel功能,主要利用了user-mode Linux (UML)。此外还有一个Kernel Test Framework (KTF)架构也发出来在征求意见了。因为KUnit已经要进入mainline了,那么KTF需要能阐述清楚它在KUnit的功能之外还能提供什么好处,毕竟不应该在mainline里面包含多个单元测试框架。

接下来他列巨额了目前还活跃着的一些测试服务。其中Intel的0-Day test service可能是目前为止最长寿的一个了,不过主要是关注Intel平台。Linaro的Linux kernel functional testing (LKFT)则提供了不少深入测试,但是支持的硬件比较少。Red Hat的continuous kernel integration (CKI)项目已经上线一段时间了,不过最近才开始被公众所注意到,主要着重测试stable kernel。当然还有Hilman参与创建的KernelCI,本周刚被宣布作为Linux基金会的一个项目。

Kevin Hilman

所以目前已经有很多测试正在进行中了,不过这里还是有不少问题。首先,每个人都是在他们自己的一小块领域做测试,没有合作,因此我们组织了ATS会议。不同角色有不同的测试重点,供应商会专注于测试他们的硬件和软件,开发者则测试他们关心的平台,不过针对kernel的测试则有些国语集中,大多数人都在重复测试kernel里面的同一部分。因此我们需要继续拓宽测试面。

不过,尽管大家合作尚未密切,现在这些分散的测试力量已经不断报出众多bug了。这里带来的问题就是“我们是否能跟上这个速度,在bug报出来的时候尽快fix掉”?Hilman参考了Dmitry Vyukov在LPC上的演讲中的数据,其中提到过去几年合入kernel的patch中,有10%都带着“Fixes:” tag,说明他们是解决了这个tag指向的commit所引入的bug。并且不是所有bug fix都带着这个tag,所以真正引入bug的commit比例会更高。

除此之外,目前发现的bug数量是难以想象的。过去两年里面,syzbot找到了5800个kernel crash bug,主要通过对kernel进行fuzzing测试,这个过程中,它其实只执行了kernel的7%的代码。kernel社区是否真的有能力解决所有这些bug?Vyukvo估计每次kernel新主要版本发布的时候都引入了约2万个新bug。

这些LPC上展示的数据引起当时几天之后召开的Maintainer Summit的热烈讨论。每位kernel开发者都有自己的工作流程来处理patch,这样当新bug数量快速增长的时候无法及时处理。Hilman指出现在有一些工作试图能把这流程中的一部分能自动化管理起来。因此新建了一个workflows mailing list来讨论,已经有很多建议被提出了,不过达成的共识还不算多。

Hilman说,测试领域的碎片化其实也在阻止社区找出这些bug的深层次原因。ATS的举行就是希望改善碎片化问题,我们其实不仅仅可以对别人的架构的存在必要性表示理解甚至跟他们竞争,相反的,也可以合作起来解决一些问题。终极目标是能尽量阻止bug进入kernel的正式发布版本中。测试工作碎片化只是原因之一,kernel的工作流程也需要改进。

一位参会者提醒,除了kernel testing,还有很多其他测试,包括bootloader,user-space程序,以及其他一些模块。这些测试也应该继续进行。Hilman表示赞同,他主要关注kernel测试,因为过去的这几个会议也主要是kernel相关的。其他领域的测试工作也同样有碎片化问题,不过我们只能先从某个领域开始,kernel测试就可以作为这个公共出发点。

Status updates

接下来有若干个"lightning talks",都是一些比较剪短的项目状况总结,其中介绍测试系统的部分特别有帮助。

Milosz Wasilewski

Milosz Wasilewski是第一位,介绍了LKFT。LKFT主要是针对Arm和x86架构的,注重测试stable kernel。LKFT起初建立起来是为了帮助Greg Kroah-Hartman来维护long-term stable (LTS) kernel的,因此它主要测试LTS分支以及最近的stable branch。随着时间推移,也开始扩展了对mainline和linux-next kernel的测试。

LKFT会运行多种测试集合,包括LTP,kselftests,libhugetlbfs的测试,以及各种性能测试。针对每一个发布版本,会完成大概25000项测试,每周会完成大约100万项测试。此外,最近也开始进行Android kernel测试了,不过这部分还没有开始广而告之。

Bird介绍了Fuego test system,主要着重于测试嵌入式设备。Fuego有它自己的Linux发行版,是基于Debian的。它还有Jenkins自动测试否武器,测试执行单元,一组测试集。这些全部都包含在一个Docker容器内,方便在host上运行。

Fuego关注的不是测试upstream kernel,而是进行产品测试(product testing),也就是高级别的集成测试以及性能评测。测试中用到的各种工具(例如netperf服务器)也包含在Fuego发行版内部,还有一个跨平台的编译器可以用来编译源代码生成测试程序。还有一些脚本可以用来控制测试的执行过程,包括结果解析,分析,图形化。可以支持多种通讯方式来跟DUT(device under test)通讯,包括TCP,串口,Andriod adb。

Fuego不处理将测试代码部署到设备上的工作,Bird希望能利用其他工具来完成这个动作。Fuego的用户通常会用另一个Jenkins job来加入test pipeline中实现部署。DUT不需要太多功能就可以跟Fuego配合了,只需要有一个带有若干命令的shell(需要grep,不过不需要awk和sed)。Busybox就足够了有一些测试确实需要DUT这边做一些额外配置才能支持。

Bird之后Hilman上来介绍了KernelCI。这个项目的目标是测试多种硬件平台,这一点是它跟其他测试架构的主要区别。此时已经在进行250多种开发板的测试,包括35家供应商的system-on-chip (SoCs),也包括多种体系架构:x86_64,arm,arm64,mips,arc,riscv。

KernelCI会对多个kernel tree进行测试,包括mainline, linux-next,stable tree(夜包括stable release candidates)。也会测试一些subsystem tree, maintainer and developer tree,Android的common tree,还有chrome-platform tree。它会测试多种kernel config,包括所有upstream中的defconfig,还有利用GCC和Clang来编译多种版本。

大多数时候,KernelCI仅仅做一下启动测试,就是启动到shell然后执行几个简单命令。对一部分开发板,会额外增加一些功能测试。主要原因是KernelCI项目不希望开发、维护自己一套特殊的测试集合。不过现在也在跟子系统维护者合作来把他们自己的测试集合加入KernelCI。

Veronika Kabatova

Veronika Kabatova接下来上台介绍CKI。CKI的目的是希望在bug进入kernel之前第一时间进行阻止。她认为能查出已有bug是不错,不过这不是CKI的目标。当然,达成这个目标很难,因此这个项目建立时就是测试upstream kernel里的testing tree。它着重测试最新的stable branch,stable-next, arm-next, RDMA, rt-devel等。对其他tree也有一些测试,例如net-next和mainline,不过这些测试结果没有发布出来。CKI的测试对象包括x86_64, arm64, ppc64, ppc64le, s390x等架构。总体来说,CKI的目标是希望能对现有的kernel continuous integration (CI)方案进行补充。

CKI还有一点跟其他方案不同,它并没有使用Jenkins,而是使用GitLab CI system。在真正运行测试的时候,使用了Beaker。测试系统可以以多种方式来触发,包括Patchwork的patch,Git commit, Koji build等等。CKI的报告会发送给一个mailing list。

Kcidb

有多个测试框架都提到了kcidb,这是LPC之后矩形的CKI hackfest中想出来的一个东西。Hilman提到,KernelCI生成了大量数据和测试结果,很多都从来没有用到过。如果能把这些数据利用起来就太好了。其他项目也有类似需求。

在hackfest上,KernelCI, LKFT, CKI联合定义了一个简单的JSON schema来描述测试结果。这仅仅是一个开头,希望能把所有这些数据收集到一个公共的未知,这样就能利用公共工具来处理,看是否能发现一些有价值的东西。已经有一些工具可以对kcidb数据进行提交和查询,主要是利用Google cloud上的一个BigQuery instance。这三个测试框架也在把kcidb客户端加到他们的报告里,还有其他一些框架也在做这件事,例如Bird提到的Fuego。

Plenty more

这篇文章仅仅对这一天的会议进行了一些简要的记录,着重于会议开始的1/4部分。ATS后面就分成了两个分支进行讨论。这里还有很多信息交流,希望能推动所有人共同来改善工具、架构、测试硬件等等。不过很显然,要把这些多样化的测试方式统一起来还有很长远的路要走。

kcidb本身其实还只提出不到两个月。有很多人感兴趣来把多种测试架构中的测试定义(test definition)能统一起来。Bird认为,今后可能会有一个test store,就像app store那样,所有用户可以在数千个测试中选择出一些他们需要的。不过目前来说这个还是次要的,首先要能把测试结果统一好,就从kcidb开始吧。

总之,有很多事情要做,但是也只有有限的资源可以参与开发,这是自由软件世界的常见困扰。LPC(还有CKIhackfest)跟ATS的会议时间离得太近,也就分散了一些与会者。在当天最终总结session上,大家决定明年要重点在一个会议上讨论,也就是下一年的LPC,而不是再举行一次ATS。

在总结session中,主要的决定都记录了下来,可以参见elinux.org的页面:https://elinux.org/Automated_Testing_Summit_2019 。此外Pengutronix也进行了会议记录,发布到自动测试的mailing list上去了。

kernel测试显然已经越来越好了,当然还有很长的路要走。合作是将kernel测试推动到下一个水平的关键。在ATS, LPC, CKI hackfest等的碰面也会带来重要影响。

[I would like to thank Linaro for travel assistance to attend the Automated Testing Summit in Lyon, France.]

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议修改再创作~

长按下面二维码关注:Linux News搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值