2010-06-29 :-(
_ 朝ッ
0520 起床
_ 通勤
汗だく
_ [ipython][python]いつもの
% wget http://peak.telecommunity.com/dist/ez_setup.py % python ez_setup.py % easy_install ipython
_ ,
ドラッカーが売れてるならそのぶんだけ状況がよくなるとお思いで
_ [NetBSD][テスティング][翻訳][ATF]NetBSD Blog - Testing NetBSD: Easy Does It
NetBSD をテストするのは簡単にできる
June 24, 2010 posted by Antti Kantee
In a software project as large as NetBSD the interactions between different software components are not always immediately obvious to even the most skilled programmers. Tests help ensure that the system functions according to the desired criteria. Periodic automated runs of these tests with results visible on the web ensures both that tests are run in a regular fashion and that the results are available to all interested parties.
NetBSD ほどの規模のソフトウェアプロジェクトにおいて、異なるソフトウェアコンポーネント間の関連は最上級プログラマであってもすぐに把握できるようなものではない。the desired criteria によれば( 訳: 要求仕様???? )、システム関数はテスト可能である必要がある( 訳: ううむ.... )。テストを定期的に実行し、テストとテスト結果をウェブに表示するというやり方はよくやるし、すべての当事者にとって有効である。
This short article explains the NetBSD test strategies and provides a brief overview of the enabling technologies. It also details how effortless it is to run the test suite and why doing so is in every developer's, patch submitter's and system administrator's best interest. The intended audience is people with a keen interest in testing and quality assurance, and a desire to reduce personal headache. The article is written against NetBSD-current as of June 2010 and applies to what will eventually become NetBSD 6.
ここでは、NetBSD のテスト方針を説明し、テストの実現方法の概要を説明する。また、いかに手間をかけずにテストスイートを実行するか、なぜテストがすべての開発者、パッチ提供者、そして管理者にとって有益なのかを説明する。対象とする読者は、テストや品質保証に強い関心があるひと、頭痛の種を減らしたいひとである。この文章は 2010 年 6 月の時点での NetBSD-current で書き直したものであり、いずれ NetBSD 6 にも反映されるだろう。
Automated Testing Framework (ATF)
Automated Testing Framework (ATF)
Julio Merino's Automated Testing Framework (ATF) unifies the interface for running tests, enables customizable test report formats and provides a standard interface for implementing tests. ATF also provides a mechanism for tests to determine if the feature under test, such as hardware, is present in the system and skip the test instead of incorrectly failing it. The goal is to make the tests run conveniently in batch mode without human supervision -- hence the name automated. ATF is shipped with NetBSD and all new NetBSD tests should be written against ATF.
Julio Merino による Automated Testing Framework (ATF) はテストを実行するためのインターフェースを統合したものである。テスト結果をカスタマイズして整形し、テストを実装する標準インターフェースを提供する。ATF はまた、システムに搭載されているようなハードウェアテストのように、テストが失敗した原因を究明するためのテストの仕組みや、誤っていたときにテストを失敗する代わりにスキップする機能も提供する。( 訳: ????? )
ATF tests are found under /usr/tests in a standard NetBSD installation. As pointed out on the ATF website, this is done to enable a system administrator to run the NetBSD test suite for the specific hardware/software setup with minimal effort. Executing the tests should be viewed as insurance for a particular installation and reporting any test failures immediately may save a lot of head scratching down the road.
ATF テストは NetBSD を標準インストールでは /usr/tests にある。ATF ウェブサイトで指摘しているように、システム管理者が最小の労力でハードウェア/ソフトウェアの NetBSD テストスイートを実行できるようにしてある。テストを実行すると、インストール時の insurance を見ることができ、どんなテストが失敗したらすぐに将来頭を抱えることになるものを保存する( 訳: なんのこと????? )
The tests can be run with the atf-run command in the appropriate subdirectory for a partial set of tests or on the top level of /usr/tests for the entire NetBSD test suite. Since the output of atf-run is meant to be post-processed by other tools, the idiomatic command for creating a human-readable report includes a pipe to the report generator:
テストを実行するには、tests set 内の適切なサブディレクトリか、または /usr/tests で atf-run コマンドを実行すれば、NetBSD の test 一式を実行できる。atf-run の出力は、パイプなどを介し、レポート可視化ツールによって post-processed しやすい出力になっている:
atf-run | atf-report
This gives a verdict for all the tests. Also, a summary like the following one is presented:
これによりすべてのテストを評価され、以下のような出力を得られる:
Summary for 25 test programs:
83 passed test cases.
0 failed test cases.
0 expected failures.
2 skipped test cases.
Further documentation for running the tests and controlling the report format is available from the ATF manual pages, specifically atf-run and atf-report.
テストの制御や、出力形式について詳しいことは、 ATF の atf-run や atf-report のマニュアルページに詳細が書いてある。
Automated NetBSD Installation and Test Application (anita)
( 訳: Automated NetBSD Installation and Test Application 自体が固有名詞なのでこれは訳す意味ないよね )
The Automated NetBSD Installation and Test Application (anita) is a tool written by Andreas Gustafsson. When anita is run, a URL to release set binaries is given as an argument. Anita downloads the release sets, creates a disk image, boots the downloaded release in a virtual machine and installs the release. For example, the following command will download and install NetBSD/i386 5.0.2, and boot the resulting installation to a command prompt:
The Automated NetBSD Installation and Test Application (anita)は、Andreas Gustafsson によって書かれたツールである。anita を実行するとき、引数として release set の URL を受け取る。Anita は release sets をダウンロードし、ディスクイメージを作成し、ダウンロードした release を仮想マシン上で起動し、インストールする。たとえば、次のコマンドは、NetBSD/i386 5.0.2 ダウンロードし、インストールし、起動し、実行結果をコマンドプロンプトへ表示する:
anita interact ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.0.2/i386/
Currently, anita supports only QEMU and the i386 port, although there has been interest in adding support for other virtual containers and NetBSD ports. Since installation is done in a virtual machine, the environment is theoretically the same regardless of the host the command is run on. This is both a blessing and a curse: different anita runs are comparable regardless of where they are executed, but features specific to certain machine configurations are not exercised. Nevertheless, if an anita install is successful, there is reasonably high confidence that the release it was executed for works.
現在は anita は QEMU と i386 port のみをサポートしているけど、他の virtual containers や NetBSD port をサポートすることに興味はある。仮想マシンへのインストールが完了したら、その環境は、理論的には anita interact を実行したホストと同じ環境になる。これは幸福でもあり災いでもある: 異なる anita を実行すると、実行された anita と比較的無頓着である ?????????? のだが、あるマシンのための設定をする詳細の機能は動作しない ??????????。それにもかかわらず、anita のインストールが成功したならば、anita の実行結果はそれなりに信用していいだろう。
What makes anita especially effective for testing installation is that it uses "screen scrape" with the sysinst installer. This means the display output of sysinst is read and interpreted by anita, and commands are given as response to the output. This tests that the installation works like a human would be doing it and sets it apart from testers which use various machine scripts to perform test installations.
anita の何がインストールテストにとくに効果的なのかというと、sysinst インストーラーと一緒に screen scrape を使うことだ。sysinst の出力は、anita に読まれ、解釈され、コマンドはその出力への応答として与えられる。このテストは人間のようにインストールをテストし、様々なプラットホームのマシンでのインストールをテストするスクリプトを実行するテスターのためにある。
Test Reports On The Web
ウェブでテストレポートを見る
In addition to anita, Andreas has written a set of tools which fetch the current sources from cvs, build a release, and use anita to install the release and run the ATF tests. The results are currently available on his website. The source revisions committed between each build/install/test run are available behind the "Details" links on the page. Furthermore, if the system build is broken, the tools make an effort to hunt down the exact guilty commit before publishing the result as to when the build was broken.
さらに anita には、Andreas が書いた current ソースを cvs から取得したり、release ビルドしたり、anita でrelease をインストールして ATF テストを実行する、というツール群がある。その成果は彼のウェブサイトで見ることができる。コミット済みのリビジョンのソースでは、build/instlal/test のいずれも実行でき、"Details" リンクを辿ればそのソースを見ることができる。さらに、システムビルドが失敗する場合、そのツールはビルドの失敗を報告する前に失敗する原因を特定しようと試みる。
If despite testing efforts a regression does slip through, the logs from the runs make it easy to track down which commit introduced the regression, even days after it was introduced -- although hopefully it will not take so long to correct things. Once enough logs have been accumulated, they can also provide a source to figure out what breaks often, due to what, and for how long. This information can be used to prevent similar problems for occurring in the future.
レグレッション( テスト? )でもまだ解決しない場合( 訳: ???? )、レグレッション( テスト? )が失敗する原因を追求するためにレグレッション( テスト? )を実行したあとの数日間は実行結果のログが役立つ( 訳: ???? )。けどあまり長期間それが有効であることは期待できない。じゅうぶんなログが蓄積されたのならば、失敗したときになぜそうなり、どのくらいの間そうなっていたのかを解明するための材料となる。この情報により、今後似たような状況になることを防ぐことができる。
Running The Test Suite With Anita
Anita によるテストスイート実行
The results mentioned in the previous section are used as a reference point to determine the current health of NetBSD. Developers and users submitting patches are encouraged to repeat the anita test run to make sure changes do not have unwanted side-effects. Additionally, developers are committed to not causing long-term regressions in the anita test runs -- a clean test report for a submitted patch may further convince that the patch was sufficiently tested and should be included in NetBSD. Nevertheless, common sense is allowed as to when this is necessary.
前節でのテスト結果は、NetBSD の状態を診断するための基準となる。開発者や利用者からパッチが提供されれば、望まぬ副作用が発生していないか確認するために anita でのテストを繰り返して実行することができる。そして、開発者は anita テストを実行し、 long-term レグレッションさせずにコミットできる。提供されたパッチへの全テスト( 訳: clean test ???? )のレポートは、パッチはじゅうぶんにテストされ、NetBSD に入れることについてさらに確信をもてるだろう。とはいうものの、NetBSD 界隈では( 訳: common sense )テストが必須であることを認めるだろう( 訳: ???? )。
Although writing tests is not covered in this article, it is also highly recommended that new features are submitted with the relevant tests in the same package. This is also to the advantage of the submitter since, as mentioned above, developers are required to make sure [future] changes do not cause existing tests to fail.
ただし、テストを書くことについてはこの文書の範囲外であり、新しい機能は関連するテストも一緒にパッケージとすることをお勧めする。( 訳: 前半と後半がうまくつながらない )。これは、提供者の強みである。上述のとおり、開発者は、変更があったとき既存のテストが失敗しないことを要求するからである。
Anita can be found in pkgsrc under misc/py-anita. As of writing this, pkgsrc-current (and what will become pkgsrc-2010Q2) is required. Also, QEMU version 0.12nb3 or later is required due to a bugfix in the CPU emulation -- test runs will hang indefinitely without this bugfix.
Anita は pkgsrc の misc/py-anita にある。この文書が書かれた時点では、pkgsrc-current ( そしてもうすぐ pkgsrc-2010Q2 も ) が必要になる。そして CPU エミュレーションについて bugfix されている QEMU version 0.12nb3 またはそれ以降が必要になる -- bugfix されてないとテストがハングする。
A full anita install/boot/test cycle including the ATF test report is accomplished by using the test option. For example, when build.sh is used to build release sets into /objs/obj.i386/releasedir/i386, the following command would be used to run an install/boot/test cycle:
ATF テストレポートを含めた anita による install/boot/test の全工程は、テストオプションを使うことで完遂できる。たとえば、build.sh は、/objs/obj.i386/releasedir/i386 で release sets をビルドすればいい。install/boot/test をおこなうそのコマンドはこう:
aanita test /objs/obj.i386/releasedir/i386/
If the development host runs NetBSD and is sufficiently up-to-date, it is possible to simply run the ATF tests there. However, due to reasons already mentioned, the results might or might not reflect the anita run. The recommended "no brains necessary" method to make sure that a change does not cause a regression in the anita run is to do an anita run. Since it does not require additional hardware or even disrupting current work due to having to reboot, there is little excuse for not doing so. On the flip-side, the anita run does not test the system configuration of the development host, so ultimately the best choice is to run the tests in both environments. This arguably doubles the amount of necessary command lines from one to two, but still leaves little excuse for not executing both.
開発マシンで NetBSD が動作していて最新に保っているならば、ATF テストを実行するのは簡単だ。しかし、すでに原因が追求されているならば、anita の実行結果については熟慮したほうがいいかもしれない。"no brains necessary" された場合、変更されていても anita を実行したときにレグレッションは発生しない( 訳: ???? )。よって、ハードウェアを追加したり、または reboot によって作業を中断させる必要がない ようにするためにほんの少し作業するだけでいい。その反面、開発マシンのシステム設定のテストを anita で実行することはできない。結局、最善の選択は、両方の環境でテストが走ることだ。この 2 つを間違いなくおこなう( 訳: ???? )ためには 1, 2 行のコマンドラインが必要になるのだけど、まだ両方を実行することはいくつかの理由により出来ない( 訳: ???? )。
Conclusions
おわりに
This short article presented NetBSD testing options and provided a brief introduction to the tools to make it happen. NetBSD testing is done periodically with results available from a web page, but manual execution, either piecemeal or wholesale, is possible and highly recommended. Ultimately tests help ensure the quality of NetBSD, and it is in everyone's personal interest to run tests on their local machines and to include test cases along code submissions.
この文書では NetBSD テストのオプションと、テストツールで何が出来るかをいつくか紹介した。NetBSD テストの結果は定期的に更新され、ウェブページから確認することができるのだけど、とくに、一部分や全体( 訳: ???? )をテストする場合は手動で実行するといい( 訳: ???? )。結局テストは NetBSD の品質を保証できるし、誰でも自分のマシンでテストできるし、コードを配布するとき( 訳: ???? )に含めることも出来る。
Acknowledgments
謝辞
Thanks to Andreas and Julio for their work on these awesome tools and for comments on a draft of this article.
Andreas と Julio の素晴らしいツールとその仕事に敬意を表し、この文書へコメントしてくれたことに感謝する。
