The Rational Edge

オープンソース時代のテスト手法、そのノウハウ
――Part1：どこから始めるか

by Len DiMaggio
Software Quality
Engineer
Rational Software
IBM Software Group

翻訳：編集局 谷古宇浩司

2003/5/9

　実際、いまではもう、すべてのプログラミング作業を1人で行う人はいない。続々と増産されるアプリケーション群は、少なくとも部分的には、サードパーティが開発したコンポーネントで組み立てられているようだ。

　このような状況は、ある場合にはオープンソースやフリーウェア（の制作過程）を意味するし、時には他社との“連携作業”を意味する。いずれにせよ、サーバやシステム、コンポーネントなどバラバラの部品を統合する場合のテスト作業は頻繁に行われるようになる。つまり、開発工程におけるテストというカテゴリの重要性はさらに高まりつつあるのである。

　マルチ環境のシステムを構築する際、個々のシステムを束ねるために、基本的にはそれぞれのシステムに共通するプログラミング言語を活用して構築する。このプログラミング言語という要素には、（構築すべき）ソフトウェアそのものの属性が含まれる。つまり、「コンフィグレーション・データ」「（システムの）内部および外部手続きの調整」「データフロー」などだ。そしてもちろん、イベントのレポーティングやセキュリティという要素も含まれるだろう。「統合テスト（Integration testing）」（おそらく「結合テスト（Aggregation testing）」の方が適切な術語かもしれない）は、このようなプログラミング言語の各要素の働きやシステム全体の中での動きを実証するために行われる。そして、同時にそれらの要素が衝突する際のポイントを把握するためという意味でも行われるのである。

　機能テストやシステムテスト、ストレステストあるいはそのほか多くのテストを扱った素晴らしい文献は確かにある。しかし、統合テストに関する文献はどうだろう。統合テストの最適なアプローチとは？ 統合テストにおいて、あなたが探すべきなのはどんなタイプの問題なのか？ そして、そもそもどのように始めたらいいのだろうか？

　2回連続でお送りする今回のテーマで目指すゴールは、サードパーティの部品を使いながら構築したソフトウェア群を統合した結果、その“境界”で起こる問題を解決するための“レシピ”をステップ・バイ・ステップで示すことだ。ところで、この議論を始める前に、ソフトウェア間の“境界”には、統合作業を失敗に導く3つの「落とし穴」が潜んでいることをあらかじめいっておく。
　
　どこから始めたらいいのか、そしてどのように始めたらいいのか。まずはここから議論を始めよう。そして来月公開予定の次回では、テスト作業の簡単なロードマップをご紹介する。

■何をどのように、どこから始めるか

　わたしは伝統的な考え方に立脚した哲学というものに関心を払ったことはない。とはいえ、わたしはテスト技法の哲学というものを持っている。テストを成功させるために、あなたはプログラムが何をしようとしているのかという点について、まずは正確に理解していなくてはいけない。つまり、プログラムは、要件を完全に満たすように書かれなければならないのである。

　しかし、それはただの始まりにすぎない。あなたは、プログラムの動作を把握するだけではなく、それがどのように動作するのか、という点も把握しておかなくてはならない（注1）。

　まずは、テストエンジニア向けの成熟したテストプロセスを眺めてみよう。このようなプロセスでは、プログラムの外部的な振る舞いを分析することから始める。ファイルのインプット、アウトプットやエラー・メッセージの生成といった機能を含むユーザーインターフェイスの検証である。別のいい方をすれば、そのようなテストプロセスは、プログラムが“何”なのかを調べようとしているということだ。

　そして、その後にプログラムが“どのように”動作するかという点を調べ始める。つまり、そのプログラムの振る舞いはどんなタスクによって可能なのか、それはどのような感じに見えるのか、使うデータは何かといったことを調べ始めるのである。それから彼ら（テストエンジニア）は、ユーザーインターフェイスはどのように構築されたのか、異なった環境やデータの価値の違いによってプログラムはどのような反応を示すのか、どのようなアウトプットを吐き出すのか、エラー状態のときにプログラムをどのようにハンドリングするか、といった“どのような“を調べる段階に移行していく。

　さて、あなたが統合テストをデザインし、計画するときに求めているのはどんなタイプの情報だろうか。おそらくあなたは、以下のような領域における“何”と“どのように”の両方の情報を求めているのではないだろうか。

　インストールとコンフィグレーション：（パートナー企業やほかの部署から）配布されたプログラムを、さまざまなプログラムが混在する統合システムに移行させるには、まだまだ遠い道のりであると、おぼろげながらも考えているだろう。そして、ライブラリや定義ファイルが異なる環境で衝突しあえば、統合作業の完了はさらに遠のくに違いない

　データの互換性：どんなプログラムでも、異なる階層間をまたがるデータの記述や変換作業を行うことは可能だ。しかし、もしあなたがそのような作業を、勤務時間中続ければ、どこかでパフォーマンスの障害にぶち当たる。もし、微妙なデータパターンの作成をミスった場合、あなたはシステムに潜む時限爆弾のスイッチを押してしまうことになる

　プログラム間の連携テスト：それぞれのサーバ上でそれぞれのソフトウェアが動作している状況であれば、個々のシステムのオペレーションが衝突することもない。そのような環境の“統合システム”であれば、うまく動くだろう。しかし、完全に統合してしまった場合、片方のシステムが正常に動くのは、もう片方のシステムが動き始める前までだということにあなたは気が付くに違いない。

　モニタリングとロギング：もし、プログラムが深い森の奥でダウンし、そのことにだれも気が付かなかった場合、システムはダウンしたといえるだろうか。どんなにうまく設計され、上手に構築されたシステムでも、いつかはマズイ状況に出くわすことがある。そして、あなたはそんなプログラムのデバッグ作業を行うために必要なあらゆる情報を求めるだろう。このような仕事は、異なるシステムを統合するときには、さらに複雑で面倒な作業になる。なぜなら、あなたはまったく異なる形式と異なる場所からデバッグに必要な情報を取るためにアクセスしなければいけないからだ

　セキュリティ：この領域において、テストは最初と最後だけではなく、いつも行うべきである。あなたがつなげたシステムは、その最も弱いつながりと同じ程度の強度しかない

　パフォーマンスとスループット：（この領域でテストをおろそかにすることは）スポーツでいうところの“秒殺”の憂き目に遭う。エンドトゥエンドのスループットスピードの遅延は、システム統合の成功というチャンスを即座に潰す。ユーザーにレスポンス遅延のフラストレーションがたまる前に、ボトルネックの解消あるいはボトルネックそのものを把握しておかなければならない

　信頼性：もし問題が起こったら、システムの電源を落とすことを回避できるだろうか？ もし回避できないのなら、せめてサブシステムでのリカバーを装うくらいのことはできるか？

　メンテナンス性と拡張性：遅かれ早かれ、どんなシステムでもパッチやサービスパック、hot fixなどを必要とするだろう。そのようなソフトウェア・アップデートは、一定の仕方でインストールできるだろうか？ そして、アップデートが行われている間、システムを動かし続けることができるだろうか？ サポートスタッフは、（統合システムによく見られる）さまざまなアップデートソフトウェアの異なるインストール手段を学ばなければならないのだろうか？ もし、あなたが、自分が携わるビジネスをさらに拡大していきたいと望んでいるなら、自分で構築した統合システムの拡張性を確認しておいた方がいい

　このような機能面を実証するテストタイプの詳細は、次回紹介する。

■いつ始めるか（そしていつ終了するか）

　統合するソフトウェア・サブシステムにおける“境界”の動作を実証するパフォーマンス・テストはいつ行うべきか？ （個々の）ユニット・テストが完了した後か、（全体的な）システム・テストを始める前か？

　このような質問に対する正確な答えは「ちょっと待て。あなたはそもそも間違った質問をしている」である。（統合システムのテストでは）われわれは、通常行うような、“時間軸”に沿ったソフトウェア・コンポーネントのテストサイクルと同様に内部システムのテストを取り扱うべきではない。逆に、“境界”テストは必要に応じて、適切なスタッフなら誰でも、ソフトウェアの開発作業全体を通じて行われるべきものだ。これは、反復型開発の基本的な原則である。

　例えば、あなたがシステムの試作品を開発しており、しかも開発の初期段階にあった場合を考えてみよう。開発およびテストスタッフがそれぞれで構築したモデルを合わせようとするとき、あなたは正確には、データの互換性を実証することに関心を寄せなければならない。後に、テストスタッフが、システムに（パフォーマンスの）限界まで負荷をかけようとするとき、あなたはおそらくモニタリングとログ採取に興味が向くことだろう。

■どのように始めるか：オープンソースソフトウェアの場合

　自社でコードを書くときは、自社内で作成されたマニュアルや社外秘のバグレポートなどを参照することが可能である。そして、ほかのスタッフや専門家がサポートや販売活動に協力もしてくれる。しかし、サードパーティが作成したソフトウェアやオープンソースのソフトウェアの場合はどうだろう。オープンソースソフトウェアの利用頻度は、インターネットの普及に従って、近年大幅な拡大傾向にある。実際、Apacheのようなオープンソースソフトウェアは、最新のWebアプリケーションを語るうえで欠かせない存在となっている。

　オープンソースソフトウェアの調査は、熱帯雨林のジャングルを探索、調査することに似ている。オープンソースとは、さまざまな異なる種の集積体であり、単一の種とは対極の位置に属する存在である。そこには、バラエティに富んだインターネットアプリケーション群が、いくつかの“公共的”な特徴を持って共存しており、なおかつあたかも1つのインターネットアプリケーションとして群体のように進化し続けている。まるで生物学的な1つの種として、個別な動きではなく、あくまで中央集権的なある計画に沿って進化するように。そこには、ある1つの基準が存在するが、実際には異なったソースに由来しているのである。

　昔の話だが、わたしはかつて、IBM PC（俗にいうAT互換機）との開発競争を演じたことがある。不幸なことに、わたしの会社は、PCベースのアプリケーションにおいて、（当時）デファクトスタンダードであったIBMのPC規格に従う道を選ばなかった。代わりにわれわれは、IBMのPCよりも“より優れた”マシンを作ったのである。それが何をもたらしたのか？ IBMのPCに搭載されているプロセッサよりも速く動作し、かつ独自のBIOSを搭載したわれわれのPCで動作するアプリケーションを見つけることが非常に困難であることを悟ったのだった。幸運なことに、わが社ではPCと一緒にアプリケーションも提供することができたのだが、それでも自社製のPCはほとんど売れなかった。ほかの企業、例えば、AT互換機を受け入れたコンパックなどは、膨大な量のPCを売ったのだが。

　このように、われわれはまだ、ニッチな市場に懸けている部分がある。しかし、Webアプリケーションの世界はXMLのようなオープンスタンダードのテクノロジが支配的な地位を占めつつある。このようなことは極めて論理的なことである。現在、インターネット上で走るプロトコルは、かつて政府や大学、企業が水面下で協定を結びながら構築したものであることを思い出してほしい（注2）。

　オープンソースソフトウェアとインターネットにはどのような関係があるのだろうか？ インターネットとオープンソースソフトウェアの関係は、鶏と卵の関係に似ている。インターネットはオープンソースによって生まれ、そしていま、オープンなソフトウェアによってさらなる拡大を見込める可能性を有しているのである。

◎内部に踏み込む

　テストの局面から見た場合、オープンソースはソフトウェアのクオリティを高めるポテンシャルを持っていると言える。パッと見には、このことはわれわれの感覚に反するかもしれない（不特定多数の人間が1つのアプリケーション構築に携わることで、果たして万全な品質管理ができるのか）。使用料を払わなければならない（従来型の）ソフトウェアよりも、品質の高いソフトウェアを誰にでも使えるようにするにはどうすればいいのだろう。そんなのは簡単なのである。

　少数の人々によって設計され、構築され、テストされたソフトウェアというのは、しばしば“孤立”してしまうものだ。外部インターフェイス（プログラミングAPIやGUI）は、ドキュメント化されているかもしれない。しかし、内部でどのように動作するかは隠ぺいされている。その結果、リリースされた段階で“ブラック・ボックス”化している。外部からそのアプリケーションにアクセスしたときに、あなたはバグを見つけるかもしれないが、通常われわれは内部の設計やロジック、データフローなどをのぞくことはできないのだ。このようなソフトウェアがどのように動くかを理解するのは非常に困難であり、どのように動作不良に陥っているのかを探ることも難しい。あなたが、自分の会社が作成したソフトウェアの“フードの下”を探り始めようとしたとしよう。あなたは“（限定された）クラブの会員”としての特権をすでに持っているため、非常に容易にそれを行うことができる。ある企業内部の人間になったときから、あなたはさまざまな情報（機能の仕様や設計書、コードそのもの）に直接アクセスできるのである。
　
　幸運なことに、オープンソースソフトウェアの世界では、あなたはすでに“クラブの会員”である。しかも、特権的な資格を持つような会員ではないのだ（誰でもすでに“会員”なのである）。

　オープンソースソフトウェアを扱うとき、あなたはどんな情報を利用できるのだろう？ そして、それをどのように利用することができるのだろう？ 以下、次のようなテーマで議論を展開しよう。

ドキュメント

バグの解決

ユーザーコミュニティ
（アプリケーションの直接の作者、ユーザー、サポートスタッフ）

ファイルのコンフィグレーション

コード

●ドキュメント

　利用できるドキュメント類は大量にあり、しかもオープンソースソフトウェアの種類は多岐にわたる。このようなドキュメントを拡張できるということは一般的に考えても非常に素晴らしいことだといえる。とはいえ、ほとんどのアプリケーションにはすでにインストールガイドやAPIガイドなどがある。オライリー（O'Relly）のような出版社がPerl、Emacs、Tomcatなどのオープンソースソフトウェアに関する書籍やマニュアルを販売しているのである。このようなドキュメントに関する状況から、ドキュメントは利益を生むと考えられるが、（オープンソースソフトウェアの）ドキュメントの作者は自身のソフトウェアにかかわるさまざまな“拘束”に対するインセンティブを受け取ることはないという状況をも示している。ただし、もしそうでなければ、あなたがオープンソースソフトウェアのインプリメンテーションやオペレーションについての情報にアクセスしようとすること自体が限定されることになる。

　OK。ドキュメントを見ることはできた。じゃあ、次は何だ？

●バグの解決

　ソフトウェア・テストの原則（注3）は、誰かがバグを見つけ、修正したとされる同じ場所から、新たなバグを見つけ出すことにある。なぜか？ おそらくコードのオリジナル設計が間違っており、何回もの修正が当たり前のように必要とされるという認識があるからだ。古いテレビコマーシャルにこういうストーリーがある。Xというブランドの車のマフラー製造会社が顧客のマフラーを直すのに18回（いや、19回だ！）も修理をするが、結局、構造的な不良品（注4）であることが判明し、そのマフラーはすでに使えないものになり果てていたという話だ。コードがバグだらけだということもこれと同様である。しかし、プログラムの出来のよさにおける絶対的な基準を、バグの発見回数に置くべきではない。例えば、プログラムBと比較してプログラムAから多くのバグを発見できたとしても、それはプログラムAが（プログラムBと比較して）多くのテストを重ねた結果にすぎないかもしれないのだ。コードの履歴について考えることは、バグフィックスの履歴について調べることと同じであり、たぶんバグデータベースそのもののことでもあるのだが、これは、あなたがシステムの統合を行う際に活用するコードのどこに問題があるのかを調べる際、さまざまな“妙案”をもたらすことだろう。

●ユーザーコミュニティ（アプリケーションの直接の作者、ユーザー、サポートスタッフ）

　ユーザーコミュニティは“クラブ会員”の中の研究員（必ずしも特別な存在ではないが）ともいえる。もし、あなたが（あるアプリケーションの）ある特定の機能について問題を抱えていたとする（ほかの会員もすでに同様の問題で悩んでいるだろう）。そんなとき、あなたは1つあるいは複数のニュースグループに対して、助けを求めることができる。で、解決策が間違っていた場合は文句をいうことさえでき、さらなる答えを受け取ることもできるのである。そして、もしこの問題が解決されたなら、“ありがとう”とメッセージを送るだけでいいのだ。あなたにとって幸運なことは、おそらくどのようなコミュニティに保存されている情報も電子メールで受け取ることができることだ。

　一方、不幸なこともある。求める情報にたどり着くには、2〜3Mbyte規模のほかの情報の中からそれを探し出さなければならないことだ。そこにこそ、オープンソースソフトウェアの難点がある。多くのソフトウェア開発ビジネスは、インストール前にいろいろな問題が予想されることを知っており、いまだオープンソースソフトウェアの活用に及び腰である。有料のサポート契約を交わすということは上記の問題に対する予防線の意味がある。往々にしてサポート契約を交わす人々というのは、多額の出費なんか気にしない。あえてオープンソースソフトウェアの活用を避けさえするのである。しかし、わたしのアドバイスは「そんなに悲観的になるな」だ。オープンソースソフトウェアを書き、サポートを行い、実際に使用するユーザーコミュニティの会員たちは、自分たちが属するコミュニティを最優先に活動するし、彼らは電子メールでプログラムのアップデートを配信し続けているようである。

●ファイルのコンフィグレーション

　あるアプリケーションのコンフィグレーション・ファイルを時間をかけて読み込み、理解することによって、そのプログラムについて多くを学ぶことができる。これらのファイルは、コンフィグレーションの要件を示してくれるし、利用可能なメソッドや利用できないコアおよびそのアプリケーションによって提供されるオプション機能などを明らかにしてくれる。オープンソースソフトウェアでは、これらのファイルは一般的にASCIIフォーマットである。コンフィグレーション・データがGUIや独自のデータベースの下に隠されていないので、読みやすく、編集しやすいという利点がある。ただ、不幸なことに、このことはまた、編集過程での間違いが残りやすく、コンフィグレーション・エラーを引き起こす原因にもなりやすい。ただ、もしあなたが注意深くバックアップ・ファイルを作成しておけば、コンフィグレーション・オプションがこのアプリケーションでどのような動きをするかの実験を試みることができる。

●コード

　もし、あるプログラムのソースコードに慣れ親しんでいた場合、ソフトウェア・テストのエンジニアは、テストすべき対象に対して、“客観性”を欠いてしまうといわれている。わたしは必ずしもそうは思わない。わたしは常に、経験を積めば積むほど、その人はアプリケーションがどのように不具合を起こすかについてよく知り、うまくテストが行えるようになると信じている。オープンソースソフトウェアの場合、オープンソースという言葉がすべてを物語っているのだが、ソースコードの閲覧は万人に開かれている。（さまざまな人が）ソースコードを読むということはしかし、テストの代替作業ということではない。（ソースコードを読むことで）あなたはそのプログラムにおける内部および外部のロジックの流れを理解できるかもしれないが、そのプログラムがどんな環境でどのように動作するのかを予測することはできないだろう。人工衛星がこつぜんと消えたという2〜3年前のニュースを覚えているだろうか。（あの人工衛星の）ガイダンス・システムを構成するデバイスはオープンソースソフトウェアで構築されてはいなかっただろう。かけてもいいが、開発者やテストエンジニアは「satellite_get_lost_now」という名の機能名を持ったシステムを構築してはいなかったに違いない。

■どのように始めるか：ビジネスパートナーとともに働くとき

　アプリケーション構築を行う場合、（アプリケーションに関する）すべての内部情報は通常、何の障害もなく見ることができる。しかし、（自社以外の）独自仕様のアプリケーションを共同で開発する場合はどうだろう。あなたが取れるアプローチは、あなたと契約を結んだ、アプリケーションの基本設計を行ったビジネスパートナーとの間で決定される。この関係は、彼らのWebサイトからシュリンク・ラップされたソフトウェアを購入することも含まれる。

◎外部から内部に踏み込む

　われわれは、オープンソースソフトウェアの議論のときに行ったのと同じ疑問を、独自仕様のソフトウェア開発についても問うことができる。あなたに開放されているのは、どんなソース情報なのか。そして、それらをどのように活用することができるのか。以下、4つの議論を展開する。

ドキュメント

テストの役割分担

バグレポート

セキュリティ・アラート

●ドキュメント

　もし、あなたの会社があるベンダ製品のパッケージ・インテグレーションを行う多くの企業の中の1つでしかなかったとしたら、あなたの（設計）ドキュメントに対するアクセス権限は、ユーザーマニュアルや管理者マニュアル、APIガイドに限定されるかもしれない。これらのドキュメントだけでも、外部インターフェイス画面を構築することはできるかもしれない。依然、アプリケーションそのものの設計やデータフロー、ロジックなどの情報を得ることはできないだろうが。では、このアプリケーションの内部（設計）を見るにはどうすればいいのだろうか。

●テストの役割分担

　あなたの会社があるベンダと交わした“特別な契約”とやらは、サポート電話に連絡を入れたとき、彼らに「お電話ありがとうございます。そのまま少しお待ちください」といわれる程度の関係だということを心得ておいた方がいい。もし、そうであったなら、あなたは結局、公開されているドキュメントで見ることができる以上の情報、例えば設計情報や詳細な機能情報などを得ることはできない。あなたの会社が作成したプログラムと提携企業が作成したプログラム間の相互作用が引き起こした問題を解決しようとするとき、このような事態（やたらと待たされるなど）は大変なフラストレーションを生む。あなたが直接その統合作業に参加していたとしても、お手上げに違いない。フランクリン・ルーズベルトの伝記の中で著者のテッド･モーガンは、その種のフラストレーションを非常に分かりやすく説明している。スターリン時代のソ連では何かの発言が原因で強制収容所送りになる可能性が多々あり、人々はみな余計なことをいわないよう、毎日重苦しいプレッシャーに耐えていた。あるとき、アメリカの政府関係者がソ連の政府関係者に、（ソ連の）最新式戦車の重量を尋ねたところ、「とてもいい戦車ですよ」という答えしか聞くことができなった、という。

　あなたがサポート問題にぶつかったとき、あるいはある企業と提携したときにこのようなことが起こらないよう希望を持とうじゃないか。もし、彼らがそんなことをしたとしても、あなたにはまだほかに試す方法がある。テストグループに接触することだ。怖気づいてはいけない。まず、自分のことを紹介し、彼らがいま、何をしようとしているのかを教えてもらうのだ。彼らはすでにソースコードの問題の個所を見ている、ということを忘れてはいけない。彼らは、パフォーマンス・テストに使ったツールのコピーをあなたに貸してくれることさえあるかもしれない。かけてもいいが、彼らは自分たちの手で、シュリンク・ラップされていない部分のツールセットを作っている。すでにあなたが試したように！

●バグレポート

　時として、人は終わったことを最初からほじくられるのを好まない。例えば、完成したソフトウェアにおける詳細なバグレポートなどは嫌われる。ほとんどのベンダは、プロダクトのリリースノートにいくつかのレベルのバグ情報を盛り込む。しかし、あなたが独自ルートで見つけた追加のバグ情報はどこにもない（それはより客観的で完璧なバグレポートかもしれないのに）。もし、自社の製品、あるいは提携企業の製品のバグを見つけたいなら、BugNetを見るべきだ

　BugNetは、オンライン上で公開されているバグ情報のデータベース・アーカイブで、バグフィックスのサプライヤにとっては問題そのものの検索と解決方法が得られる素晴らしい場所である。あなたは限られた情報なら自由に閲覧することができるし、あるいは情報の定期更新を受けられるように登録することもできる。ほかには、Bugtraqメーリングリストに参加するという手もある。Bugtraqはセキュリティ・システムに対する攻撃情報やサポート情報を提供し合うメーリングリストだ。もしあなたが統合作業を行うプログラムのセキュリティ問題を想定しているとしたら、Bugtraqのアーカイブで検索をかけ、いち早く安心を手に入れておくといいだろう。

●セキュリティ・アラート

　セキュリティについて語るとき、常に考えておかなければならないことがある。オープンソースソフトウェアを活用しているのか、独自にアプリケーション構築を行うのか、という点だ。もしシステムのどんな部分もインターネットに接続することがないのならば、ウイルスや不正侵入、ネット攻撃の心配をする必要はないだろう。ただし、あなたはとても危険な状態にある。インターネットに接続しないというこの事実から、あなたは目をそむけることができないし、システムからプラグを引き抜かない限り、インターネットから孤立した存在であることはできないのだ。

　決め打ちのセキュリティ対策だけでシステムのセキュリティ強度を保つことはできない。セキュリティというのは常に考え続けなければならない問題だ。あるシステムに搭載したセキュリティ・システムは、新たな脅威が現れるごとに進化していかなければならない。新たな技術が登場すれば、脅威の質も進化するのと同じように、セキュリティ対策も常に進化し続ける必要があるのである。

　インターネットやWebに関連するセキュリティ警告情報を探すにはどこに行けばいいのか。それこそ、まさに、インターネットやWebで探せばいいのである。インターネット上には悪人がたくさんいるかもしれないが、同時に善い人々もたくさんいる。1998年は、（いまでは）“worm”と名付けられたコンピュータウイルスがインターネットのネットワークを脅かした“記念すべき年”だ。この危機に対し、DARPA（Defense Advanced Research Projects Agency）は、緊急対策チームを設置した。このチームは後に、CERTSM（Computer Emergency Response Team）となった。そして、いまではCERTコーディネーション・センターと呼ばれ、インターネットのセキュリティ対策に関するあらゆるレポートを発行している。例えば、セキュリティ・ホールやウイルスが、ある特定のプログラムで発見された場合、彼らは調査をし、ドキュメント化し、リスク回避のための推奨方法などを作成し、公開する。あなたはアドバイザリーのメーリングリストに名を連ねることができ、常に最新のセキュリティ情報を保つことができる。そして、それは全部タダなのだ！

◆

　ソフトウェアの統合テストというのは、ある1つの明確な解を導くことができない「x」が含まれる複雑な等号式を解こうとするのと同じである。xにはどんな値も代入できるが、解は1つではない（中学の数学の授業のときのようにひたすら長い時間をかけて代入し続ければ、最後にはすべての解を得ることができるが！）。

　さて、どこから始めようか？

　ではまず、システムの機能的な側面のテストを構築するのに必要な情報を列記しよう。

インストールとコンフィグレーション

データの互換性

プログラム間の連携テスト

モニタリングとログ採取

セキュリティ

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

信頼性

メンテナンスと拡張性

　統合テストに必要なものと探索場所について、あなたはいま十分な知識を持っているはずだ。パート2では、“境界”のすき間に横断する統合テストを行ううえでの正確なロードマップの構築方法を紹介しよう。

【Notes】

1.DiMaggio, Len. “Looking Under the Hood.” STQE, January 2000.

2.For a great history of the early days of the Internet, find the book by Katie Hafner and Matthew Lyon, 「Where Wizards Stay Up Late: The Origins of the Internet」 (Simon & Schuster, 1997).

3.First defined by Glenford Myers in his classic book, 「The Art of Software Testing」(Wiley, 1979).：「ソフトウェア･テストの技法」、G. J.マイヤーズ著、長尾真監訳、近代科学社刊）

4.I can't take credit for this phrase; it was first applied to software by Fredrick P. Brooks, Jr. in 「The Mythical Man-Month: Essays on Software Engineering, second edition」 (Addison Wesley, 1995).：「人月の神話」、フレデリック・Ｐ・ブルックス，Jr.著、滝沢徹・牧野祐子・富澤昇訳、ピアソン・エデュケーション刊

本記事は「The Rational Edge」に掲載された「Testing at the Boundaries Between Integrated Software Systems Part I Where to Begin」をアットマーク・アイティが翻訳したものです。

IT Architect 連載記事一覧