测试Windows Subsystem for Linux

2017 年 9 月 17 日 Python程序员

Python部落(python.freelycode.com)组织翻译，禁止转载，欢迎转发。

随着Windows Subsystem for Linux的发布，开发团队已经创建并发布了一系列技术深度分析的博客文章。为了更好地了解WSL基础，请查看WSL概述文章。

感谢Ben Hillis，Vikas Agrawal和Sunil Muthuswamy提供内容和评论。

概述

Windows Subsystem for Linux（WSL）的目标是提供与* nix系统相同的命令行开发环境，而不需要虚拟机。这主要包括访问命令行实用程序，执行原生的ELF64二进制文件，以及支持开发人员常用的框架（如MEAN和LAMP Web服务器堆栈）。此外，为了让系统尽可能原生，WSL自动公开Windows文件系统和网络堆栈。所有这一切都是通过内核级仿真层实现的，该层将系统调用从Linux转换为相应的NT副本。而WSL没有直接的NT副本来填补这些差距。

最初WSL于一年前的//Build2016 中发布给一群热心的用户使用。此后，活跃用户数继续攀升。在撰写本文时，每个月超过50万人使用WSL。对于这样一个规模庞大的社区，我们希望预期的质量对大家透明。发布有beta标签的WSL对我们来说是没有意义的事情。我们知道子系统不适合生产环境，并希望弄清楚用户的期望是什么。对我们来说，beta标签传达了一个信息：“有些事情会破裂，会有差距。”

随着开发的进展，我们已经找出了量化WSL缺陷的方法，并为实现裸机Linux平台所需的缺失功能制定了实施路线图。这些努力集中在四个主要支柱：Linux测试项目，基于场景的测试，模糊测试和社区反馈。

LTP

改进兼容性的一个重要工具是Linux测试项目（LTP）。LTP是联合创建的单元测试库，旨在验证Linux内核的系统调用和文件系统接口。 LTP通过提供标准化回归检查和未来开发的路线图，帮助我们验证实现的稳健性和稳定性，这是非常宝贵的。LTP向我们介绍了WSL系统调用实现的完整性。我们还在Github上公布了LTP的结果。

LTP周年更新

当周年更新发布时，我们的LTP合格率是体面的，但不是最好的。我们在开发周期中开始使用LTP相对较晚，并没有太多时间调整系统调用实现来提高合格率。下面的结果是使用LTP版本20150420

系统调用

文件系统

LTP创作者更新

在创作者更新中，WSL记录了Linux内核版本是4.4。我们已经将LTP版本与20160510相匹配。在下表中，你会发现周年更新的LTP结果中不存在一行。未实现的指定意味着测试失败，但系统调用未在WSL中实现。这个区别很重要，因为我们根据用户输入和遥测实现了所需的系统调用。我们尚未实现的许多系统调用未被使用或被很少的应用程序所使用。未实现的集合中还包含33个我们还没有支持的/ dev / loop设备的测试。

我们还重新分类了跳过测试的意思。现在，跳过的类别中的每个测试也在本机64位Ubuntu上跳过。这些测试的大多数是针对16位版本的系统调用。

以下结果使用LTP版本20160510。

系统调用

文件系统

在失败的文件系统测试中，多数是由于缺少对rt_sigqueueinfo系统调用的支持。

LTP的缺点

不幸的是，LTP不是一站式商店。即使我们可以通过合适的测试达到100％的合格率，但是这也不能说明WSL没有问题了。还有许多LTP中没有覆盖的系统调用（主要是新的）。大多数LTP测试是基本的，不测试有趣的竞争条件或系统调用支持的全部参数。很大百分比的LTP测试是负变差测试，只是确保给定的系统在提供无效输入时返回正确的错误代码。在这些情况下，WSL团队通过编写自己的单元测试来覆盖测试差距。在撰写本文时，团队已经为系统调用和虚拟文件（/ proc / sys）编写了超过15万行的单元测试代码。

重要的是，100％的LTP合格率不是黄金标准。LTP覆盖的许多系统调用在实践中很少使用，不会影响大多数用户。这使得我们进行情景测试。

情景测试

为了提高我们测试的覆盖面，我们需要专门测试一些我们重点关注的使用场景。为此，我们转而使用几个开源项目用于验证自己的产品的单元测试。发现我们关心的许多框架都有广泛的单元测试套件。有趣的是，甚至还有少量测试在WSL中通过了，而在原生Ubuntu中没有通过。

虽然这些测试给了我们一个很好的想法，但是他们没有说出测试情况的全貌。只是因为框架的单元测试的100％通过并不能保证用户永远不会在该框架中遇到bug。

将来，我们将继续以更自动化的方式构建运行这些测试的基础设施。此外，我们将在此列表中添加更多测试，因为我们确定了顶级框架和工具。如果在这里看不到你最喜欢的框架的话，别担心！一定会有的。

压力测试和模糊测试

WSL测试故事的另一个重要部分是压力测试和模糊测试。我们已经利用Trinity进行系统调用模糊测试，并将测试纳入了我们的自动测试过程。对于压力测试，我们依赖于stress-ng。这两种工具都帮助我们在驱动程序难以覆盖的领域找到严重的错误。

社区／GitHub

我们改进WSL方法的最后一部分是GitHub和令人难以置信的Windows Insider用户，在过去6个月中，成千上万的用户预览“创建者更新”并且已经提出了近2000个问题，这些问题的跨度从网络连接问题到控制台中的更多颜色支持请求。我们会查看提交的每个问题，并确保我们有一个计划来解决那些可行的和适用的问题。这有助于我们与社区保持紧密的同步，偶尔会在几个星期内对修复做出回应。如果你有兴趣在公开发布之前几个月收到最新的WSL，请务必加入Windows Insider预览计划。

结论

我们对WSL在过去一年取得的进步感到兴奋。我们还看到了同样有影响力的功能和修复的路径，这将增加WSL的兼容性，并使WSL成为更具吸引力的开发工具。但是，如果没有你，我们不能做到这一点。继续向希望我们能够集中精力的地方提供反馈意见吧。在WSL上尝试开发堆栈。让我们知道你遇到的问题，并帮助我们了解你的情况。在Github上加入我们的Windows Insider程序和文件问题。

感谢你的使用和你的bug报告对于我们的支持。我们对WSL的未来感到兴奋。敬请关注！