テストスイートを使用して Linux カーネルの有効性を確認

Michael D. Crawford
GoingWare Inc.

Copyright (C) 2001 Michael D. Crawford.

Free Software Foundation によって発行された GNU Free Documentation License バージョン 1.1 またはそれ以降のバージョンの条件に基づき、本ドキュメントをコピー、配布、および/または変更する許可が与えられています。条件は、セクションが変更されていないこと、表紙のテキストがないこと、裏表紙のテキストがないことです。断り書きとして次のことを記載します。「This contains material from the Linux Quality Database at http://linuxquality.sunsite.dk（本ドキュメントには、http://linuxquality.sunsite.dk にある Linux Quality Database からの資料が含まれています」。ライセンスのコピーが「GNU Free Documentation License」というタイトルのドキュメントに含まれています。

この記事に関する人々の発言

神様があなたに送った？ :） この線に沿って何かを期待しています。

-- linux-kernelのメーリングリストの David D.W. Downey

改訂履歴

2001/1/21

ハイパーリンクのチェックと更新（多くのページが移動していたため）、Charles Cazabon 氏の Memtester の追加、上品なグリーンのスタイルシートの使用

2001/2/22

綴り、文法、HTML エラーの修正、PostgreSQL、VA Linux Cerberus、Mauve、cpuburn、Luciferの追加。コメントや修正、テストスイートの提案などを寄せて頂いた方々にお礼申し上げます。

はじめに

新しい Linux カーネルをテストする最も簡単な方法は、カーネルをインストールし、コンピュータをリブートして、通常実行しているソフトウェアを十分に試してみることです。

これは重要なテストです。と言うのは、皆さんにとって非常に関わりのある事項を迅速にテストするからです。そして、皆さんの通常の作業からするとかけ離れた結果に気付く可能性が高いと言えます。

しかし、この方法は広くテスト範囲をカバーするわけではありません。私たちは、GNU/Linux システムが提供する機能のうち非常に限られた範囲でのみ、そのシステムを使用する傾向があります。

数多くのいろいろなソフトウェアパッケージをダウンロードして試すことがもっと良いテスト方法だと思う人がいるかもしれません。しかし、これは多くの作業を伴うわりに結果は限定的なものになる可能性があります。例えば、それぞれのソフトウェアパッケージを構築して使用する方法を学ぶのに多くの時間を割かなければなりません。また、そのエキスパートではないので、些細なことで上手く行かなくても気付かないことがあります。

別の方法として、テストスイートを実行することがあります。これらのスイートは、テスト目的のためだけに作成されたソフトウェアパッケージで、広範囲にわたる機能が対象にされており、上手行かなくなりそうな個所を高い頻度で明らかにするように作られています。

これらのテストスイートが役に立つのは、単にカーネルのテストをするだけでなく、共通に使用されるシステムライブラリを、開発中であってもテスト出来るようにすることです。新しいバージョンの Linux ディストリビューションの構築に取り組んでいる場合、テストスイートは Linux カーネルとシステムライブラリのどのバージョンの組合せが上手く動作して信頼性のあるパフォーマンスを発揮するかを決定するのに役立てることが出来ます。

検討すべき主要なテストスイートとして、以下の 2 種類があります。

私が「アプリケーション・テストスイート」と呼んでいるものは、元来はシステム自体をテストする目的で作成されたものではなく、付属のプログラムが正しく機能することをテストするためのものでした。これらの例として、一部のプログラミング言語と共に配布されたテスト用プログラムがあります。そのプログラミング言語で記述された数多くのプログラムを実行し、エラーという結果が出れば、何か上手行っていない所があるということが分かるのです。

「システム・テストスイート」と呼ぶものもあります。これらは、当初から Linux そのものをテストするという目的で作成されたテストツールです。

それぞれに利点があります。システム・テストスイートはおそらくシステム全体の機能をより広範囲にカバーし、そしてより厳密に個々のシステムコールが正しく機能するかをチェックします。アプリケーション・テストスイートは、さらに複雑な機能を実行してシステムのより狭い部分を、より深くテストします。

テストの実行に手がかからない場合、負荷が重いシステムの機能をテストするのに、複数のテストを同時に実行してみることも出来ます。しかし、最初に各テストを実行した時に、それぞれのテストが問題ないかをチェックする必要があります。

私は、このリストに含めることが可能な新しいテストスイートを積極的に探しています。皆さんが新しいテストスイートをご存知でしたら、どこで見つけることができるか、私（Michael Crawford）宛てに電子メール（アドレス：）で知らせてください。

すべてのテストにパスすべきですか？

おそらく違うでしょう。

テストしているカーネルでだけすべてのテストを構築して実行するのが、おそらく最も早道でしょうが、予期しなかった結果が出た場合、これが本当に新しいバグなのかどうかを判断する必要があります。これがいわゆる「回帰テスト」または「バグ回帰」の一形態です。

テスト中のソフトウェアのある機能が正常に実行された場合、パスするような方法でテストは作成されたかもしれませんが、それではまだ十分ではありません。あるいは、テストが失敗するのは、カーネルとのやりとりが原因というよりは、使用している Linux ディストリビューション上でのシステムライブラリとのやりとりが原因かもしれません。

したがって、予期しない障害にあったら、少なくとも、安定したカーネルのもとで実行しながら、カーネルの他はテストしようとしているのと同じ仕組みでテストを構築、実行します。その環境でも依然としてテストが失敗する場合は、まず問題のソフトウェアパッケージのことを知っている人と相談すべきでしょう。そのパッケージのメーリングリストが、質問するところとしては適当ですが、そのテストスイートの保守担当者に質問する方法もあります。

あるカーネルのバージョンで、テストが失敗に終わっても、他のカーネルのバージョンでは上手く行く場合、またはスイート保守担当者がテストは安定したカーネルではいつも上手く行くはずだと言った場合に限って、そのバグを に報告します。

テストをしようとした両方のカーネルでテストが失敗したけれども、保守担当者が上手く行くはずだと言った場合も、使用している Linux ディストリビューションを担当するテクニカルサポートまたは開発者に報告してください。彼らは、その問題が glibc などのシステムライブラリにあるのかどうかを判断する態勢を十分に整えています。ライブラリの動作が全般に上手く機能しても、コンピュータに構築したものにバグが多い場合があります。

使用しているシステムの基本的な健全度をテストする

これらのテストは、Linux そのものをテストするのではなく、使用しているハードウェアが基本的に正しく動作していることをテストするためのものです。x86 コンピュータを使用している場合、おそらく memtest86 から始めるのがいいでしょう。

memtest86

memtest86 は厳格な、低レベルメモリ用のテスタです。Linux の下で動作するのではなく、むしろ、LILO、Grub の下で、ないしはフロッピーにインストール出来るブートセクタやカーネルです。メモリテストを起動すると、それ自体が小さなオペレーティングシステムのように機能します。

memtest86 は、スタートアップ BIOS テストよりもメモリをテストするのに、はるかに多くの時間を使い、さまざまな手法でメモリエラーを刺激して検出し、コンピュータの起動ごとに実行されると、かなりの時間を要するテストを行います。そして、実際に、私の PC のメモリで、コンピュータ自体の BIOS テストではない 1 つのテストで繰り返し起こる問題が見つかるのですが、現実にトラブルを起こすようには見えないのです。

このテストは、業界標準 BIOS を搭載した x86 PC 上で実行されるかなり固有なハードウェア寄りのものなので、他のプラットフォーム上で作成されたもののようには機能しません。しかし、画面表示の処理のためだけでなく、インストールされている物理 RAM のサイズと場所などを見つけるために新しいコードを記述する場合、テストは簡単に新しいプラットフォームに移植出来ると思います。

Charles Cazabon 氏の memtester - ここからダウンロード

memtester は、ほとんどの UNIX 互換のシステムでユーザモード・プロセスとして実行する点を除き、memtest86 と同様の目的に使用されます。これは、可能な限り多くの仮想 RAM のページを物理 RAM に割り当てて、ロックし、そのメモリをテストします。（ロッキングをするために、特権システムコールを用いるので、root で実行しなければなりません。）

Linux では、単一のプロセスは物理メモリ量の半分を超えてロックすることが出来ないため、memtest の単一のインスタンスでテストすることが可能な容量と同じになります。同時に複数のインスタンスを実行し、おそらくより多くの容量をロックすることが出来るように、カーネルにパッチを当てることによって、より多くの容量をテストすることが可能かもしれません。他のプロセスに RAM が使われないよう、memtester を init プログラムとして用いることは、カーネルの性能を確かめるのに役立つのかもしれません。

リブートせずに、RAM をテストしたり、PC-clone x86 以外のアーキテクチャ上で実行させたいと思うのであれば、memtester を使って下さい（memtest86 は PC BIOS を使用するため、エンベデッドシステムのような PC x86 でないハードウェア上で実行することが出来ないのです）。私は、Mac 8500 の Debian PowerPC 上で実行して、十分な結果を手に入れています。

Doug Ledford 氏の メモリ・テスト・スクリプト - 危険、 Will Robinson!

さらに厳格なメモリテスト（と、Linux プラットフォーム上で実行されるテスト）を使用する場合でも、これを試してみてください。ディスク DMA アクセスと組み合せて CPU メモリアクセスを実行することによって、使用しているメモリをより厳格にテストします。通常、これは純粋に CPU ベースのテストよりも多くのメモリ帯域幅を消費します。

これを使用する場合は注意してください。安手のハードウェアを損傷させたり、出火するほどコンピュータを発熱させたりすると聞いたことがあります。これは、通常仕事で使用するコンピュータ、または個人用途で保有しているコンピュータ上では実行したくないものです。しかし、リスクを取るのを厭わなければ、信頼出来る品質であって欲しいと願う真新しいコンピュータの基本的な健全性をテストするにはいい方法だと思われます。

Cerberus Test Control System ここからダウンロード このことを言いましたか？

調べるには自分のコンピュータから発火させることになるでしょうが、おそらくこれが、安手のハードウェア上では実行が難しいと聞いたテストツールです。README.FIRST ファイルから：

CERBERUS テスト・コントロール・システムは、設定によってはハードウェア、ソフトウェア、またはデータを損傷させるおそれがあります。このソフトウェアを、営利目的で使用するコンピュータ、または壊したくないハードウェア上で実行することは推奨されていません。

しかし重要なことは、このソフトウェアは Linux カーネルの中のバグをすでに明らかにしていることです。

実際、GPL の下でテスト・コントロール・システムのリリースが行われた理由の一つとして、いくつかの重大なファイルシステムを破損させるようなバグが、「不健全なモード」で VA テスト生成プログラムを使用して明らかになったということがあります。

cpuburn

これはCPU チップ負荷テスタで、アセンブリで書かれ、P6 および P5 グレードのインテル・アーキテクチャ・チップ上で最大ヒート出力を発生させます。作者のページから：

冷却が不十分であったり、オーバクロックされていたり、あるいはその他の理由で脆弱なシステムは、データ損失（ファイルシステム破損）ならびに場合によっては恒久的な損傷を電子部品に引き起こすことがあります。

Lucifer は、ページをスクロールダウンして「Linux ソフトウェア」を表示します。

Lucifer の Freshmeat エントリーによると：

Lucifer は、Linux と DOS をサポートしている稼働検査プログラムです。ハードウェアが時間の経過につれて不調にならないようにするために、RAM、ハードディスク、プロセッサ、および浮動小数点プロセッサのストレステストを実行します。 Lucifer は Linux と DOS のみのテストに使用されますが、ポータブルであるはずです。

アプリケーション・テスト・スイート

Python の make check - ここからダウンロードします。

Python プログラミング言語パッケージを構築すると、コマンド make check を入力してテストスイートを実行出来ます。このコマンドは多数のテストプログラムを実行します。これらのテストのほとんどは Python 言語自体ですが、これらの多くはシステムコールすることによって、Linux のテストを行います。

一部のテストは、設定されていないために実行されません。テストで必要とされる Python の機能をユーザが構築しなかったか、Linux プラットフォームには揃えられていない機能をそのテストが必要としているからかもしれません（Python は、Mac OS や Windows など他のプラットフォーム上でサポートされており、実行されるシステムごとに、プラットフォーム固有の拡張部分を備えています）。

make check の使用が終了したら、パスしたテストの数とスキップされた数の一覧が表示されたサマリーを確認します。どのテストも実行されているはずです。

Mesa の make exec - ここからダウンロードします。

Mesa は、3D グラフィックス用の SGI OpenGL 仕様向けに作成されたフリーのソフトウェアです（OpenGL ライセンスの対象でないため、OpenGL 機能とは言えません）。最近のバージョンで、Direct Rendering インフラ（DRI）をサポートするようになりました。これは、最近 Linux カーネルに追加されたソフトウェアならびに XFree86 と連動して動作し、XWindows の下でハードウェア高速 3D グラフィックスを実行します。

DRI を使用するか否かにかかわらず、Mesa の構築後にコマンド make exec を入力すると、多数のグラフィック・デモプログラムを実行出来ます。それぞれのデモプログラムを終了するには、手動で行う必要があります。通常は ESC キーを押しますが、プログラムによっては完全にテストするために、キーボードまたはジョイスティックを使用して操作する必要があるものもあります（たとえば、シーンをナビゲートするなど）。

そのテストにパスしたか失敗したかの表示はありません。実行が出来て、画面上のイメージが適正なように見えたら、テストにパスしたと考えれば良いでしょう。ベンチマークがいくつかあり、ベンチマークの結果を急いで書き留めるのを苦にしなければ、これらのベンチマークを使用して、新しいカーネルのビルドが発表になった際に、パフォーマンスが変わりなく良好な状態であるか否かを確認出来ます。

私は、システム上で DRI を初めて動作させる時に助言出来るとは言えません。しかし、敢えてそうするならば、Linux カーネルのバージョンを 2.4.0 以降、XFree86 4.0.2 以降で、使用しているカーネルで /dev/agpgart と drm のサポートを選択する必要があります（これらはモジュールとして設定されなければならないと言う人もいれば、そうではないと言う人もいます。私には何とも言えません）。また、dri-users と メーリングリストに加入すると役立ちます。

Kaffe の make check

Kaffe は Java 仮想マシンで、GNU General Public ライセンスの下で利用可能なクラスライブラリのセットです。サンの Java とは独立して開発されており、私の意見では、Java 言語の有効性と Java 仮想マシンの仕様要件を確認する重要なチェック機能を提供します（利用可能な他のほとんどの Java 関係のソフトはサンの製品です。Kaffe のような独立した競合製品やサービスがないと、Java の設計にバグがあったかどうかを判断するのは難しくなります。当該バグが、出回っているすべてのバージョンに存在している場合、それらのバグは同じコードベースから生じているためです）。

Kaffe を構築してインストールすると、コマンド make check を入力します。すると、PASS、FAIL、または XPASS（これは、障害が起きると予期されていた場所でテストにパスしたことを意味すると思われます）という字が前に付けられたさまざまなテスト名が表示されます。最後にサマリーが表示されます。

Kaffe のいくつかのバージョンを私は経験しましたが、予想外の結果が安定したカーネルでも起こることがあるので、警告を Linux カーネル開発者に上げる前に Kaffe 開発者と一緒に調べる必要があります。

Mauve Java テストスイート - ここからダウンロードします

「Mauve プロジェクトは、Java クラスライブラリ向けにフリーのテストスイートを作成する共同作業です。現在の共同作業者は、Kaffe プロジェクト、GNU Classpath プロジェクト、および Cygnus Java プロジェクトの参加者から構成されています」。

ヒューレット・パッカードがコード作成に貢献しました。これに関しては CNET 記事を参照してください。

PostgreSQL の回帰テスト - ここからダウンロードします

以下は、回帰テストページから

回帰テストは、PostgreSQL における SQL 実装のための包括的な一連のテストです。PostgreSQL の拡張機能と共に標準 SQL の動作をテストします。このテストスイートは、元々、Jolly Chen 氏と Andrew Yu 氏によって開発され、Marc Fournier 氏と Thomas Lockhart 氏によって幅広く改訂され再パッケージされました。PostgreSQL 6.1 以降、回帰テストはあらゆる公式リリースで利用可能です。

回帰テストは、すでにインストールされ稼働しているサーバに対して、またはビルドツリー内に一時的にインストールされているものを使用して実行できます。テストを実行する場合、「パラレル」と「シーケンシャル」という 2 つのモードがあります。シーケンシャルな方法では、各テストスクリプトを順次実行します。他方、パラレルな方法では複数のサーバプロセスを起動してテスト群を並行して実行します。パラレルテストでは、プロセス間通信とロッキングが正常に動作していることを確認出来ます。歴史的な経緯で、通常、シーケンシャルテストはすでにインストールされているものに対して実行され、パラレル方法は一時的にインストールされているものに対して実行されます。しかし、この使い分けには技術的な理由はありません。

システムテストスイート

Linux 標準ベースのテストスイート

これらは、Linux OS がさまざまな標準に対応しているかどうかをテストするために使用する公式のテストスイートです。これまでに提供されたテストは、Linux Filesystem Heirarchy 標準からコア POSIX.1 標準までをカバーします。

使用するディストリビューションがファイルシステムの標準に準拠していると、任意の場所に存在するシステムファイルに依存する場合でも、インストールするソフトウェアは正常に動作出来ます（例えば、「/etc」という名のディレクトリ内に、「passwd」という名のファイルが、パースしてユーザのアカウント情報を取得できる形式で存在する場合）。

POSIX.1 仕様に準拠すると、POSIX 仕様に準拠する他の各種の UNIX や同じように動作する製品用に書かれたプログラムを、ソースコードで Linux と互換性があるようにすることが出来ます。また、POSIX の一部でこれらの Linux システムコールをテストするのは非常に困難な作業になります。

Linux テストプロジェクト - ここからダウンロード

このページによると、Linux テストプロジェクトは、私がこの「Linux 用のテストにはどのようなものがあるか？」という記事に取り組み始めた時に抱いたまさにその疑問に答えるために立ち上げられました。

これまでに約 550 のテスト、テストドライバ、および結果スキャンツールがあります。複数のテストを並行して実行することが出来ます（したがって、より負荷が重いシステムをテストします）。