測試Windows Subsystem for Linux

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的未來感到興奮。 敬請關注！

英文原文：https://blogs.msdn.microsoft.com/wsl/2017/04/11/testing-the-windows-subsystem-for-linux/
譯者：大嘴

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！