大規模ソフトウェアの効率的な理解（その6）、リグレッションテスト

この「大規模ソフトウェアの効率的な理解(その4)」で巨視的理解、微視的理解という視点を紹介した。前者はソフトウェアをマクロから見ていわば俯瞰する。いわば鳥から見た図だ。後者は細部から全体像を把握する。いわば蟻の目である。地面にはいつくばっている。そのどちらの視点も忘れてはならない。Google Earthみたいに、自由に宇宙から眺めた視点からぐんぐんズームアップしていって、一つ一つのビルまではっきりくっきり見えるミクロの視点まで自在に動きまわらなければならない。

また、「大規模ソフトウェアの効率的な理解（その5）」で動的理解、静的理解という視点を紹介した。デバッガで1ステップ1ステップ実行するのは、微視的な動的理解であり、ソースコードを一行一行読むのは微視的な静的理解である。

リグレッションテストというのは、自動化テストの一種で、あらかじめ予想される出力結果を準備して、ソフトウェアを実行し、その実行結果と、予想した出力を比較し、予想どおりならOKそうでないならNGというように報告するものである。

最近ではテスト駆動型開発などのように最初にテストを準備して、その後に実装にはいるというベストプラクティスが広く実用化しているが、継続的な開発の場合、前バージョンで利用したテストがそのままリグレッションテストになる。

リグレッションテストは、巨視的な動的理解と言える。実装の詳細にたちいらないで(ブラックボックスとして)、入力と出力の組でソフトウェアの挙動を理解するという立場である。

大規模ソフトウェアの場合、ソフトウェアの隅々まで詳細に把握しているということは通常ない。大規模ソフトウェアのある機能を変更、追加する場合、自分の意図しない挙動を発生させることがある。いわばバグを作りこんでしまうことがある。リグレッションテストが整備されていれば、それを早期に自動的に発見できるので、大胆にソフトウェアを修正することが可能になる。リグレッションテストが整備されていないと、影響範囲を特定する事が困難なので変更量は可能な限り局所化最小化しなければならない。

リグレッションテストを整備しておけば、自分のソフトウェアの対する理解を仮想的に極大化できるのである。

OSSの実装も単にソースコードやドキュメントを整備するだけではなく、リグレッションテストをどれだけ充実するかという視点で議論、評価される時が来ているように感じる。よりOSSが大規模になり、修正が頻繁に求められるようになるとリグレッションテストが整備されているかいないかで、その変化に対する対応力が全然かわってくるのである。

Test Early Test Offten

Comments

[投稿：]

リグレッションテストという言葉の意味が間違っていませんか？

http://e-words.jp/w/E383AAE382B0E383ACE38383E382B7E383A7E383B3E38386E382B9E38388.html

[投稿： hyoshiok]

コメントありがとうございます。

わたしの説明だと、リグレッションテストの目的「プログラムを変更した際に、その変更によって予想外の影響が現れていないかどうか確認するテスト」というのが明確に伝わらないですね。

リグレッションテストというのは、プログラムを変更した際に、その変更によって予想外の影響が現れていないかどうか確認するテストである。あらかじめ予想される出力結果を準備して、ソフトウェアを実行し、その実行結果と、予想した出力を比較し、予想どおりならOKそうでないならNGというように報告するものである。

という感じですかね。

[投稿： K.Tsuchiya]

僕の場合リグレッションテストというより
リグレッション環境という言葉をよく耳にします.

要はたくさんのデータをプログラムに流して
自動的に期待値と照合していく環境なんですが,
e-wordsの解説だけだとその一部の役割しか
書かれていないようにも思えます.
(プログラム開発の初期段階でも
たくさんのデータでテストするときは
リグレッション環境を構築するので)

でも元の目的は変更の副作用を
見つけるためだけのものだったのでしょうか.
ちょっとわかりません.