4つのテストレベルについては、非常に問題を作りやすいので、確実に覚えておきたいところです。
(1)コンポーネントテスト（ユニットテスト）
・コンポーネントテストは、ソフトウェアを構成する1つの部分を切り出して独立に行うテストです。
・対象のコンポーネントが他のコンポーネント等との通信を行っている場合、コンポーネントを独立してテストできるようにするために、ドライバとスタブを使用できます。
ドライバは、より対象コンポーネントを呼び出す、より上位のコンポーネントの役割を担うものです。対象のコンポーネントがテスト可能だが上位コンポーネントが未完成である場合に、ドライバがその代わりをすることで、対象コンポーネントが上位コンポーネントから呼び出された場合の挙動を確認できます。
スタブはドライバとは逆に、対象コンポーネントから下位のコンポーネントを呼び出す場合に、その下位コンポーネントの代わりをするものです。
※ドライバは上位から対象コンポーネントを扱うイメージ、スタブは「切り株」の意味なので、本体がなく根っこに近い部分だけ作られているというイメージです。
・テストの内容としては機能テスト、非機能テスト、構造テストと多岐にわたります。
※これらテストタイプについては2.3章で扱います。
・テスト作成のベースは、コンポーネントの仕様、ソフトウェアの設計やデータモデル等です。
・ユニットテスト用のフレームワークや、デバッグ用の開発環境で実施されることが多いです
・実施するのは開発担当者/テスト専門のチームのどちらもありえますが、該当のコードの作成者を巻き込んで実施することが多いです。
・発見された欠陥は正式なインシデントレポートを書かずにすぐ修正される場合が多いです。
※テストレベルの中では、コンポーネントテストは「内部的」という性格の強いものですが、一方1.5章では「独立した組織によるテストは、どのテストのレベルでも実施可能」という記述があります。4つのテストレベルの特徴を把握するには「内部」のイメージを持っておくのが良いですが、「外部」にテストを依頼することもありえるということも覚えておきたいです。
・コンポーネントテストの手法の一つとして、テストファースト法(テスト駆動型開発)があります。これはテストケースの開発が主導になり、それに合格するまでコードの作成とテストの実行を繰り返すものです。
(2)統合テスト
・統合テストは、(1)でテストした各コンポーネントに対し、それらのコンポーネント間の相互の処理をテストします。また、他のシステムとの間の相互処理のテストも行います。
・統合のレベルにより、コンポーネント統合テスト（コンポーネント間の相互処理のテスト）、システム統合テスト（システム間の相互処理のテスト）などに分かれます。
・統合の範囲が大きくなるほど、発見された故障の原因が特定しづらくなります。
・どのように統合していくかに関する戦略は様々ありますが、一気に統合するよりも少しずつ統合するのが普通です。
・性能テストなど、特定の非機能的な特性のテストは統合テストに含めることがあります。
・2つのモジュールの統合をテストする場合、個々のモジュールの機能は対象にせず、モジュールの間のインターフェースのみをテストします。構造的アプローチや機能的アプローチが使えます。
・テスト担当者は、統合計画の構造や、インターフェースの影響範囲を理解していることが理想的です。
(3)システムテスト
・システムテストは、システムやソフトウェアプロダクト全体の動作をテストします。
・できるだけ実際の運用と同じ環境でテストします。
・システムテストには、システム全体の挙動として要求される様々な内容のテストが含まれます。(リスク、要件、ビジネスプロセス、ユースケース、その他システム動作を高レベルで記述したもの、オペレーティングシステムとの相互処理、システムリソースなどをベースにしたテストなど。）
・機能と非機能の両方の要件のテストが必要です。要件は十分にドキュメント化されていない場合もあり、そこからテストを作成する必要があります。
・上記のうち、機能のテストにはブラックボックステストを行います。また、メニューの構造などでは構造的技法（ホワイトボックス）も使えます。
※ブラックボックスなどの技法については4章で。
・独立したテストチームが行うことが多いです。
(4)受け入れテスト
・受け入れテストは、システムを使う顧客やユーザーが実施します。
・欠陥を発見することよりも、正しく動作することを確認することが主眼です。
・最終テストである必要はなく、受け入れテストの後に大規模なシステム統合テストを実施する場合もあります。
・受け入れテストにも様々なレベルがあります。市販ソフトウェアの場合はインストールや統合の時点での受け入れテスト。コンポーネントのユーザービリティの受け入れテストはコンポーネントテストで実施。新機能の拡張部分のテストはシステムテスト前に実施するなど。
・受け入れテストには、以下のようにいくつかの形式があります。
(i)ユーザー受け入れテスト：システムを使用するユーザーによるテスト
(ii)運用受け入れテスト：システム管理者によるテスト
(iii)契約および規定による受け入れテスト：契約や法律などに合致しているかのテスト
(iv)アルファ、ベータテスト：将来のユーザーによる、使い勝手などを試してもらうテスト
※(i)(ii)の違いですが、例えばテスト対象がある会社の社員の勤怠を管理するシステムの場合、システムを利用する一般社員の立場が(i)なのに対して、(ii)はそのシステムを管理する立場でのテストです。
※(iv)開発した会社の社内のユーザーで実施するのがアルファ、社外の場合はベータ。「ベータ版」という言葉を思い浮かべてください。
以上、4種類のテストレベルについて、要点を絞って記載しました。
全体的に注意したいところとしては、
・テストタイプやテスト技法に関する言及が随所にあり、それらが解説された章との関連付けを常に意識したい
・各レベルのイメージを把握する意味ではコンポーネント→統合→システム→受け入れという順番を意識すると良いが、実際に行う順番はこのとおりでない場合もある点に注意。また、統合テストに複数のレベルがあるなど、必ずしも単純にコンポーネント→統合→システム→受け入れという並びでの理解が正確というわけではない。
といったところでしょうか。
当ブログでも、これから頻繁にテストレベルに関する記載が出現すると思いますので、その都度思い出し、定着させていってください。
【2章の最新記事】