オープンソース時代のテスト手法、そのノウハウ ――Part3：ロードマップのしめくくり：The Rational Edge

編集局より：前回「オープンソース時代のテスト手法、そのノウハウ――Part2：テストのロードマップ」では、「スモークテスト」から「モニタリングとロギングテスト」までを解説した。今回は、「セキュリティテスト」から「メンテナンス性と拡張テスト」まで説明し、オープンソース時代のテスト手法におけるロードマップのまとめを行う。

●セキュリティテスト

　2001年9月11日以降、“セキュリティ”は多くの人々にとっての重要な関心事であり、現実の問題となった。

　インターネットアプリケーションおよびサービスのセキュリティ面に関するテストで最も重要なことは、セキュリティホールのテストを行う「手順」にあるわけではない。そのような手順の構築はしょせん、セキュリティについての、積極的な態度の発展形にすぎない。

　インターネットセキュリティに対して過度に恐慌的な反応を示す人々がいる。彼らは、恐怖によるまひ状態に陥ることで、インターネットが破壊されるという風聞に過敏に反応し、問題がどこかに霧散してしまうことをただ待ち望んでいるだけである。不幸なことだが、われわれがいくら脅威に対し、どこかに消えてほしいと願っても実現されることはない。インターネットの用途は年々拡大傾向にあり、同時にネット上の“海賊”も増え続けているのである。400年前、地球上を航海する冒険者や旅行者は、海賊対策を行わなければならなかった。今日、われわれはそれをサイバースペースという海の上でやらなければならないのである。

　では、どうすればいいのだろう。

• 1回だけでは無理
• あなたが（インターネットに張り巡らされた）リンクの中で最も弱い部分であることを常に覚えておく

<<1回だけでは無理>>

　たった1回の防御で自分のプロダクトを守ることはできない。継続しなければ意味はないのである。開発環境およびテスト環境の一部として、毎日セキュリティ対策を行っていかなくてはならない。あなたの製品のセキュリティは、新たな脅威に対し、常に進化し続けなければならない。ちょうど敵が製品の技術的な優位に常に反応し、進化し続けているのと同じように。

<<あなたが（インターネットに張り巡らされた）リンクの中で最も弱い部分であることを常に覚えておく>>

　あなたが設計し、構築する統合システムのセキュリティテストにおいて、コンポーネントのサブシステムだけではなく、サブシステム間のインターフェイスのセキュリティに対しても注意を払い続けなければならない。サブシステム間のどんなささいな非セキュア要素でも、すべての（コンポーネント間の）つながりを破壊できる構成要素となり得る。（サブシステム間に脆弱性を残しておくことは）統合されたシステム全体が妥協の産物と成り果てる、といいかえることもできる。（妥協の産物であるかないかを）正確に確かめるには、どうすべきなのか？

• Access（アクセス）

　対象となるシステムを許可されたユーザーだけ（この場合は人だけではなく、プログラムあるいはシステムも含む）が実際に使用できるかを確認する。

• Authentication（認証）

　システムがユーザーを認証できるかを確認する。そのユーザーたちが本物なのか、ユーザーがアクセスしたシステムが、本当にアクセスすべきシステムなのかどうか。

• Encryption（暗号化）

　暗号化が行われているかを確認するとき、そのデータストリームが暗号化されていないことを保証することはできない。しかし、それはまた一定のレベルの暗号が用いられている、ということも保証しない。

• Configuration（コンフィグレーション）

　コンフィグレーションが正しいかを確認すること、これは、セキュリティテストの中でかなり微妙な部分だ。多くの場合、コンフィグレーションは不正確に行われるため、システム全体のセキュリティは妥協されがちになる。これは、デフォルトでセットされているコンフィグレーション・パラメータがセキュアではないために引き起こされる、あるいは単にユーザーに提供するコンフィグレーション・ツールがあまりにも難しくて使えないということも考えられる。後者の状況は、仮にあなたがユーザーに多様でレベルの一定ではないコンフィグレーション・ツールを使うよう要求することで引き起こされる。私が最も好きなコンフィグレーション・ツール“foible”は、電話のボイスメールを、“Don't Not Verify Source（ソースを確認してはいけません）”と名付けられたGUIでコンフィグレーションするパラメータだった。冗談じゃない。そのパラメータは最初の名前こそ“Don't Not Verify Source”だったが、その後変更され“Cleaner”となった。

教訓：セキュリティはシステム設計やテストのいずれでも結果論でしか語れないものである。あなたは、ステップごとにセキュリティに配慮しながらソフトウェアを構築していかなくてはならない。

●パフォーマンスとスループットテスト

　（大リーグの）ボストンのレッドソックスファンになることは、フラストレーションの研究をすることと同じなのではなかろうか。このチームがよくやるパターンは、“グリーン・モンスター”と呼ばれるホーム・プレートから315フィートしか離れていないレフト側のフェンスを有効に利用することである。チーム（の面々）は、パワフルな重量級の体格を持っているが、動きが遅く、右利きが多い。さて、このようなアプローチの結果は何をもたらすのだろうか？ レッドソックスは一般的に驚くほどの数のホームランを打つ。しかし、ランニングスピードが遅く、ほかのチームが速い動きをするのと相まって、1918年以来ワールドシリーズで勝つことができない。当時、ベーブ・ルースはまだピッチャーだった。

　この話のポイントはどこだろう。格言「speed kills」（この場合、あなたの競争相手のスピードがあなたを滅ぼすという意味である）は、スポーツ同様、ソフトウェアの統合でも同じ真実を示している。これは、あなたが構築し、テストを行うどんな種類のシステムでも変わることはない。あなたは、システムのパフォーマンスとスループット向上を目指してテストをしなければならないのである。

　では、あなたはどのような種類のテストを計画しなければならないのだろうか？

• レスポンス・タイム／スループットテスト
• バックログの取り扱い
• ソフトウェアのパフォーマンス要求

　以下、この3つの種類のテストを見ていく。

<<レスポンス・タイム／スループットテスト>>

　これらのテストは、特定のレベルの（ある特定の使用による）トラフィックの集まりを含み、そのシステムがうまくトラフィックを処理することができるのかを測定する。私は、これらのテストを定数と変数で構成される代数の等式のようだと考えるようにしている。このアプローチは、パフォーマンスのベースラインを定めるために行う。それから、それぞれのタイミングで変数を変化させていきながら調整を行っていく。例えば、もしデーモンがメモリに多大な負荷をかけた場合、システムにおける物理的なメモリ容量の割り当てを変更する。このようなタイプのテストのためには、メモリ使用をダイナミックに計測するためのユーティリティプログラムを使うべきである。このようなユーティリティはUNIXのユーティリティ（sarやvmstat）とは異なる。IBM Rationalの「PurifyPlus」はこのような用途に特化したユーティリティであることを添えておく。

<<バックログの取り扱い>>

　OK。ここでシステムの潜在的な問題について考えてみよう。もし、入力されたある情報の流れがシャットオフされて処理が中断、それから突然フローが再開された場合、システムのコンポーネントでは何が起こったといえるだろう？ デーモンは入力されたデータやリクエストの津波をハンドリングできるのだろうか？ リクエストを取りこぼさないだろうか？ あるいはまるで回復不能に見えるほど鈍重な反応しかできないのではないだろうか？ 例を示そう。Webの閲覧や電子メールのデータ処理をハンドリングするファイアウォールがあるとする。もし、中東地域の開発が進み、あらゆる人々がCNNを見ることで膨大なトラフィックのハンドリングをする必要が起こった場合、何が起こるだろうか？ あなたは全部の電子メールを（ファイアウォールより内側に）通過させるだろうか？

<<ソフトウェアのパフォーマンス要求：何でも好きなものを食べて、それでも体重を減らす>>

　あなたはどうだか知らないが、私は常にマーケティングサイドの要求というものには懐疑心を持っている。不幸なことに、コンピュータのハードウェアやソフトウェアに対するパフォーマンス要求は頻繁にあり、“装飾的”（注2）と形容することもできる。もし、統合するシステムのいくつかのサブシステムがサードパーティから供給されているなら、若干のリサーチを行うことは有益である。注意深くそれらのサブシステムをチェックすべきだ。サードパーティが使用しているベンチマークが、あなたのシステムのコンフィグレーションにまったく関係がない程度で能率的に動作するかどうかを確かめる必要がある。また、サードパーティが使っているベンチマークが“自社開発”のものなのか、e-Testing Lab（注3）が開発しているようなよく知られているベンチマークかどうかも確かめる必要がある。このような作業は前もってやればやるほど、後々システムのパフォーマンスに関する“驚き”に遭遇することも少なくなるはずだ。

教訓：もし、（構築、統合した）システムのレスポンス・タイムがあまりにも遅いと、顧客はすぐさまどこかへ行ってしまうだろう。ベースボールファンなら、贔屓（ひいき）のチームが弱くてもそう簡単にファンをやめないのだろうが、あなたの顧客（をはじめとした利害関係者すべて）は、「来年まで待ってください」などという将来の希望観測的ないい訳に納得することはない。

●信頼性テスト

　私がかつて働いたことのあるISPのトップは、インターネットの未来に対し、興味深い予測を持っていた。彼はある日いった。「インターネットはいつも使える状態になっているさ」。彼の予言は現実のものとなった。われわれが企業の支社を設置するとき、われわれはいつでもすぐに使えるという予測のもとにそのようなユーティリティサービスの契約をする。つまり、電話、空調、電気、水道などである。なぜなら、文字どおりそのようなサービスがなければ、支社そのものが存在し得ないからである。われわれはまた、このようなサービスはどんなときでも実際に利用可能であるとの予測を持っている。

　今日、われわれはインターネットを水や電気などといったものと同じような基準でとらえている。そして、われわれの顧客は、インターネットと同様、われわれが統合したシステムも同じような基準でとらえているはずである。つまり、1日24時間、1週間のうち7日利用可能だということだ。このようなことを実現するには、アイダホ州ボイジーからバングラデシュに至るまで（！）に広がる顧客の要求（もちろん不平もだが）に対応する必要がある。たとえ、あなたやあなたの同僚の開発者、テスター、サポートスタッフが寝ていようとも、だ。

　では、このような状況に対して、テストを行ううえであなたはどのような対処をするべきなのだろうか。

• 問題は“何も起こらないとき”という観念の間隙を突いて生じる
• 多様な負荷
• 自分で長く使う−βテストが進行中であるかのように扱う

　人々が1日8時間、1週間で5日きっちりと時間を守って働いていたのはいつだったか思い出してほしい。あるいはランチタイムの1時間の間に銀行でお金をおろそうと列をつくって並んでいたときもあったし、心臓外科医が常にポケットベルを持ち歩いていた時代もあった。かつてはそれが当たり前のことだったはずだが、はるか昔のように感じられはしないだろうか？

　あなたが統合するシステムは、1年365日、1週7日、1日24時間、中断なしに動き続けなければならない。問題はないかね？ よし。では、あなたは、サブシステムのコンポーネントに搭載されている機能が1日の間で“タイムオフ”の機能に頼らないでも動作することを確認した方がいい。私は2〜3年前、まさにこのような状況に遭遇した。問題の製品は、ボイスメールのスイッチングやロギング、レポーティングを行うマルチコンポーネントだった。そのソフトウェアは、完全に自社開発の製品だったのだが、統合の段階で問題を抱えていた。最悪なのは、まさに“何も起こらないとき”に、サブシステム間のコンフリクトに関係する問題が生じたことだ。毎日午前2時にスタートするメンテナンスタスクが起動するとき、サブシステム同士に何かが起こったのだ。問題は、システムが“off hours”の間に、日次のシステム使用量レポートを生成するタスクが偶然ぶち当たり、そして同時に時間単位でのレポート生成タスクが動き始めたことで生じた。最終的には、そのレポート生成コードをより効率的にかつより細かい範囲でレポート生成が行えるように作り替え、動作するようになったが。

<<多様な負荷>>

　ストレステストというのは、重負荷をかけたときに、システムが使用不能の反応を返すか、クラッシュするかどうかを判断するために行う“spikes”と同等レベルの負荷をコンスタントにかけることも含まれる。忘れてはいけないのは、重負荷はシステムをクラッシュさせるものではなく、例えば、システムのモニタリング・ユーティリティをレポーティング機能の破壊から回避させる目的のものであるかもしれない、と思うことだ。

<<自分で長く使う−βテストが進行中であるかのように扱う>>

　テストの効率性を改善するためにできる最高の方法の1つは、あなた自身が作った製品（product）を使用することである。この方法はあなたに、テスト環境下のシステムに対する新たな“視点”を導入してくれるだろう。おそらく、初期テストにおいてあなたは、システムが故障状態にあるべきだと見る。この視点を導入すると、あなたは頻繁に再インストールやリコンフィグ、スタート、ストップを繰り返し、この短いテストサイクルで起こる一連の出来事に対し、システムをののしることだろう。

　あなたは、自分の仕事に、そのシステムを採用しようとするユーザーの視点を取り入れたとき、問題のしつこさを再認識し始めるはずだ。例えば、そのシステムのメモリマネジメントに何日か後で現れる機能障害のバグが含まれていたら、一定の間隔でテストシステムを動かしたり、ほかのテストを走らせることによって、継続的にシステムに対する“wedge（くさび）”を打ち込んでおいたとしても、あなたはその問題を発見できないかもしれない。私の直接のボスのそのまたボスがこのようなことを「自分で自分の犬のドッグフードを食うことだ」と評している。毎日自分自身が作った製品を使うことによって、あなたは顧客の視点でよりよい評価を行うことができるのである（注4）。バグというのは、長く使うことで現れるため、あらかじめ計画したテストで見逃すかもしれないバグを、顧客の視点を導入することで発見できるようになる。また、自分自身で作った製品を使うことは、製品の内部を熟知するサポートスタッフ的な仕事も行うことにつながるのだ。

教訓：おかしなことだが、あなたがかかわる開発プロジェクトがタイトなスケジュールで進行しているのはよいことである。迫る時間のプレッシャーにもかかわらず、あなたはシステムが末永く正常に稼働するためにテストをどのように行うべきかを（迅速に）決定しなければならないからだ。

●メンテナンス性と拡張性テスト

　あなたがセメントや鉄鋼、シリコンなど物質的な材料を取り扱う仕事をしているなら、あなたの仕事内容はその特定の物質の性質に制約を受ける。だが、ソフトウェアは物質的な材料に比べてとてもロジカルな性質を持っている。物質的な材料にはなく、ソフトウェアにある仕事上の制約は、まさにあなたのスキルとイマジネーションなのである。

　どんなにうまくシステムの設計ができたとしても、設計そのものは常に変化し続けなければならない。“常に変わらないものは変化である”との決まり文句は真理である。顧客はいつも新しい機能の追加を望むし、バグフィックスを望むのである。製品の設計には、製品のライフサイクルを通じてアップデートのメカニズムが組み込まれていなければならない。“Software Testing in the Internet Age”（注5）という記事で私は、アップデートは規則であり、そこに例外は存在しないというソフトウェア開発のモデルについて解説したことがある。例は何か？ マイクロソフトのWebサイトにおけるダウンロードセクションを見てみるとよい。かけてもいいが、そこには、あなたのデスクトップPCで動作しているプログラムのアップデートファイルがある。さらなる証明がほしい？ 最近のセキュリティ・アドバイザリ・リストを見てみるとよい。またかけてもいいが、そこにはsendmailやWebサーバのような、あなたが属する企業がすぐさま必要とするキー・プログラムの最新バージョンがあるのを、あなたは見つけるだろう。

　以上の要件から得られるテストのための課題とは何だろう？

• アップデートの取り扱い
• 拡張性／継続することでシステムの“死”を回避する

　では、上記の課題を検証しよう。

<<アップデートの取り扱い：“そんなの簡単”症候群>>

　あなたは、統合されたシステムが、サービス外の作業を行うことなくアップデートできることをテストを行うことで確実にしたいと思うはずである。つまり、システムコンポーネントのサブシステムがダイナミックにリコンフィグされるが、そのようなリコンフィグレーションは、ほかのサブシステムがリブートされるまで影響を受けない、というたぐいのことを明らかにしたいのかもしれない。あるいは、いくつかのコンポーネントのサブシステムが、意図的にアップデートを伴う設計をされず、完全に変更を反映させるために再インストールしなければならないような仕様となっていることを確認したいのかもしれない。

　私がまだ仕事を始めたころ、アップデートどころか修正さえされないソフトウェアの極端な典型に遭遇したことがある。大学卒業後の最初の職場でのことだ。私の上司は“極めて興味深い”性格の人々が集まっている部署で確固たる地位を築いていた。そこに、勤勉でなければ何の取り柄もないある非常に活動的な若い男性スタッフがいた。彼の、指示（依頼でもいい）に対する反応は「そんなの簡単ですよ」ということだった。彼は2〜3日の間自分のオフィスにこもり、だいたい望むとおりのプログラムを持って現れる。問題は、そのプログラムのロジックがいつも迷路のように入り組んだ複雑なもので、書き換えるどころか修正することさえできないことだった。プログラムを修正するように頼むと、その若者は「そんなの簡単ですよ」といって、最初から書き直すのである！ 私の上司は彼のこの習慣を直すことはできなかった。しかし、上司は彼に非の打ちどころのないほど的確な目標を与えることによってコントロール下に置き、開発作業を続けることができたのである。

<<拡張性／継続することでシステムの“死”を回避する>>

　企業の目標は、ビジネスを成長させることである。これは、あなたが統合するシステムが、増え続けるユーザーの負荷に対し常にスケールアップしなければならないことを指す。つまり、設計段階でそのような状況をサポートしておかなければならないということだ。例えば1000人規模の顧客のデータベースに対応する設計でなければならないし、1万人規模に対応しなければならないかもしれない。もし、増大する顧客情報が複数のテーブルに流れ込むためにスキーマを再設計しなければならないとしたら？ レポート生成のジョブがシャワーのように流れ込んでくるだろうか？ あるいはそのレポートのジョブの洪水はいくつかのテーブルを完全に消し去ってしまうのではないだろうか？

　このようなシナリオを想定したうえでのキャパシティのテストはおそらく“ストレステスト”に分類されるだろう。しかし、私はこのようなテストを“拡張性”のテストに含めたい。なぜなら、このようなタイプのテストを設計する最初のステップには、アプリケーションのトラフィックの生成について書くことは含まれていないからである。むしろ、統合されたシステムが、現在の顧客ベースだけではなく、1年後あるいはその先何年後かの顧客数を想定してうまくハンドリングできるかといったシステム統合の設計段階を焦点にしたテストなのである。私の父親は、自分でビジネスを立ち上げ、経営した。彼は私にいつも「成功を恐れるな」といったものだ。テストを設計するとき、あなたは常に企業の成功を念頭に置いておかなければならない。

教訓：あなたが統合したシステムが常に変化し、成長し続けることができるのなら、あなたは成功したことになる。スペンサー・トレイシー主演の映画“Inherit the Wind”（スコープス裁判を扱った有名な戯曲でもある）で、ある登場人物が、後ろ向きで落ちるのは簡単だ、といった。重要なことは、常に前を見続けなければならないことだ。そして前を見ながら動かなければならないのである（注6）。

【Scopes trial：スコープス裁判】

Tennessee州Daytonの高校の生物教師が州法に反して進化論を教えたことで罪に問われ、裁判（Scopes trial 1925年7月）で有罪となり、100 ドルの罰金を科せられた。しかし州最高裁では州法の合憲性は支持されたものの、罰金の額が不当に高いとの理由で無罪となった。なおこの法律は 1967年に廃止された（リーダースより）。

■結論

　ソフトウェアの統合テストを扱うとき、あなたは、複雑な、変数でいっぱいの非常に難しい代数の等式を解くのと同じ困難さにぶち当たることだろう。あなたが解くたびに変数は増加するが、等式を解く状況はよくなっていく（高校の数学のクラスでは結局問題は全部解けたはずだ！）。

　システムの機能分野におけるさまざまな情報を集めることは、変数の問題を解決に導く第1歩になる。

• インストールとコンフィグレーションテスト
• データの互換性テスト
• プログラム間の連携テスト
• モニタリングとロギングテスト
• セキュリティテスト
• パフォーマンスとスループットテスト
• 信頼性テスト
• メンテナンス性と拡張性テスト

　まず、初期テスト（スモークテスト）を行うことで、統合しようとしているシステムを十分調査し、この記事（オープンソース時代のテスト手法、そのノウハウ）に沿って、さらなるテストに移行していけばいい。ここで紹介しているような統合テストと伝統的なシステムのテスト手法の大きな違いは、システム内部と外部の境界を常に視野に入れ、システム全体の機能の拡張を考慮しているか否かにある。ここでいう境界は、多くの場合、サードパーティが構築したサブシステムにまで影響を及ぼす。いい換えれば、“ギャップを頭に入れておく”ことを忘れるな、ということだ。