WSLで行われているテスト
現在「WSL」の目標は、仮想マシンなしに*nixで使われているCUIの開発環境をそのまま提供することです。
公式ブログにて、WSLで行われているテスト内容が紹介されています。
「WSL」では、コマンドラインユーティリティーへのアクセス、ELF64バイナリーの実行、MEANやLAMPウェブサーバースタックのようなよく利用される開発者向けフレームワークのサポートを主軸として開発が行われています。
加えて可能な限り「Ubuntu」環境をそのまま利用できるよう開発が行われ、「WSL」はWindowsのファイルシステムやネットワークスタックを「Ubuntu」環境に提供しています。
これら目標を実現するため「WSL」は、カーネルレベルのエミュレーションレイヤーを実装し、Linuxからのシステムコールをそれに対応するNTのシステムコールへと変換しています。
WSLのテスト
「WSL」は開発過程において 、「WSL」の不具合や未実装の機能を定量化し、欠けている機能の実装ロードマップ（大まかなスケジュール）を作成しています。この定量化は、以下の4つの柱を軸として実施されています。
- Linux Test Project
- シナリオテスト
- ストレステストとファズテスト
- コミュニティーからのフィードバック
1.Linux Test Project（LTP）
「Linux Test Project」は、「WSL」が実装しているLinuxシステムコール及びファイルシステムのインターフェスに関するテストに利用されています。「LTP」の標準化されたリグレッションチェックにより、「WSL」の頑健性と安定性を定量化しています。
1-1.Windows 10 Anniversary Updateの結果
「Windows 10 Anniversary Update」の「LTP（ver.20150420）」の結果は以下のようになっています。システムコール
| 項目 | 結果 |
|---|---|
| Passing | 637 |
| Failing | 280 |
| Skipped | 144 |
| 総項目数 | 1061 |
| Pass | 69.45% |
ファイルシステム
| 項目 | 結果 |
|---|---|
| Passing | 20 |
| Failing | 41 |
| 総項目数 | 61 |
| Pass | 32.8% |
この頃はPassの改善に十分な時間を割けなかったとのことです。
1-2.Windows 10 Creators Updateの結果
「Windows 10 Creators Update」の「LTP（ver.20160510）」の結果は以下のようになっています。システムコール
| 項目 | 結果 |
|---|---|
| Passing | 744 |
| Failing | 93 |
| Unimplemented | 171 |
| Skipped | 102 |
| 総項目数 | 1110 |
| Pass（not including unimplemented） | 88.88% |
| Pass（including unimplemented） | 73.81% |
ファイルシステム
| 項目 | 結果 |
|---|---|
| Passing | 52 |
| Failing | 9 |
| 総項目数 | 61 |
| Pass（%） | 85.24% |
unimplementedについて
「unimplemented」の項目は、「WSL」においてシステムコールが実装されていないことを意味します。「WSL」で実装されていないシステムコールの多くは、使われていないシステムコールや、一部のアプリでのみ使われるような使用頻度の低いシステムコールです。
またこの項目には、まだ実装されていない「/dev/loop device」に関するテストが33項目が含まれているとのことです。
Skippedについて
「Skipped」に含まれる項目のほとんどは、16bit版のシステムコールに関するテストであり、Ubuntu 64bit版でもこの項目は「Skipped」になるため、項目の再分類を行ったとのことです。LTPでWSLを完全にテストすることは出来ない
テスト結果で「Pass」の項目が100%になっても、全システムコールの実装が完了したことにはなりません。特に新規に出てきたシステムコールなど、LTPではテストできないシステムコールが多くあります。
またLTPで行われるテストのほとんどは基本的なテストであり、実装内部の整合性やシステムコールがサポートするパラメーターの完全なテストは行いません。
システムコールに無効なパラメーターが指定された際、システムコールが正しいエラーコードを返すかテストすることとほとんど大差がないテスト項目ばかりです。
WSLチームによるテスト項目の作成
そのためWSLチームでは、15万行を超えるユニットテストを作成し、システムコールや仮想ファイル（/procや/sysなど）のテストを行っています。加えて、もっと実際的なテスト手法が必要になります。
2.シナリオテスト
シナリオテストでは、オープンソースプロジェクトが自身のソフトウェアをテストする時に利用するユニットテストを利用し、「WSL」のテストを行います。「WSL」上の「Ubuntu 16.04」でパスしたテスト項目の中に、実機上の「Ubuntu 16.04」でパスできなかった項目があったとのことです。（赤字の項目）
| テスト名 | バージョン | 失敗 （WSL） |
成功率 （WSL） |
失敗 （Native） |
成功率 （Native） |
総項目数 | 備考 |
|---|---|---|---|---|---|---|---|
| Nginx | Nginx 1.4.6 | 0 | 100.00% | 0 | 100.00% | 99 | |
| Django | 1.10x(master) | 4 | 99.97% | 4 | 99.97% | 11776 | |
| Flask | 0.11(master) | 1 | 99.69% | 1 | 99.69% | 327 | |
| PIP (python 2.7) | Master | 3 | 99.57% | 3 | 99.57% | 700 | 11 skipped on both |
| Grunt | Master | 0 | 100.00% | 0 | 100.00% | 390 | |
| Gulp | Master | 0 | 100.00% | 0 | 100.00% | 31 | |
| Express.js | 4.x(master) | 0 | 100.00% | 0 | 100.00% | 799 | |
| Bower | V1.8(master) | 0 | 100.00% | 0 | 100.00% | 539 | 17 skipped on both |
| Json-server | Master | 0 | 100.00% | 0 | 100.00% | 77 | |
| Coffescript | Master | 0 | 100.00% | 1 | 99.88% | 822 | |
| Ember.js | Master | 0 | 100.00% | 0 | 100.00% | 20642 | |
| Typescript | Master | 0 | 100.00% | 0 | 100.00% | 52976 | |
| NVM | Master | 1 | 99.01% | 1 | 99.01% | 101 | |
| Phantom.js | Master | 12 | 94.50% | 12 | 94.50% | 218 | |
| Rails | Rails 5.0.0.1 | 0 | 100.00% | 2 | 99.99% | 14056 | |
| Rake | Master | 0 | 100.00% | 0 | 100.00% | 573 | 1 skipped on WSL |
| RVM | V1.27.0 | 37 | 93.03% | 37 | 93.03% | 531 | |
| Sinatra | Master | 0 | 100.00% | 0 | 100.00% | 2365 | |
| Sinatra | Stable | 0 | 100.00% | 0 | 100.00% | 2354 | |
| JUNIT | Master | 0 | 100.00% | 0 | 100.00% | 985 | 4 skipped on both |
| MAVEN | Master | 0 | 100.00% | 0 | 100.00% | 494 | |
| STRUTS | Master | 0 | 100.00% | 0 | 100.00% | 317 | |
| R | R-3.3.2 | 0 | 100.00% | 0 | 100.00% | 1088 | |
| PostgreSQL | postgresql-9.5.3 | 0 | 100.00% | 0 | 100.00% | 157 | |
| Cassandra | Master | 0 | 100.00% | 12 | 96.20% | 316 |
すべてのテスト項目は100%ではありませんが一番低いものでも93%を超えており、「WSL」の改善や改良の進み具合が分かります。
ただし100%の項目でも、ユーザーが絶対に致命的な問題に遭遇しないとは限りません。
将来さらにテスト項目を増やしていくとのことです。
3.ストレステストとファズテスト
ストレステストとは、「WSL」に高い負荷をかけても問題なく動作するかチェックするテストです。ストレステストは、「stress-ng」を利用して行われています。
ファズテストとは、意図しない・想定していないデータをシステムコールに指定し、意図的に例外を発生させ、システムコールの挙動をチェックするテストです。
ファズテストは、「Trinity」を利用して行われています。
いずれのテストも見つけにくい致命的な不具合の発見に役立っているとのことです。
4.コミュニティーからのフィードバック
ユーザーからの不具合報告や提案のことですね。不具合は、「Microsoft/BashOnWindows」で管理されています。
ユーザーからのフィードバックは2000件近い件数があり、その内容含めコミュニティーからのフィードバックは方針決定の一基軸となっています。
