ソフトウェアテストの分類

1. 静的テスト （static testing）  
   　コードを実行せずに、コードをチェックする事で誤りを検出・修正するテスト。
   　ツールを使用した解析を意味することが多い。
   
   　 データフロー・パステスト   では、静的解析ツールが有効。
   　人間が行うコードのチェック作業は、 コードレビュー（Code review） などと呼ぶ。
   
   
2. 動的テスト （dynamic testing）
   　コードを実行して行う一般的なテスト。
   　通常、ソフトウェアテストというと、こちらを指す。

1. ホワイトボックス・テスト （white box test）
   　プログラムの内部構造を理解した上で、意図した通りに動作しているかを コードカバレッジ で管理しながら洩れの無い様に進めていく、ソフトウェアテスト手法。
   
     コードカバレッジ （code coverage ：コード網羅率 ）とは、ソフトウェアテストで用いられる尺度の1つで、ソースコードがテストされた割合を表す。
   
   （参考： ホワイトボックステストとは －[ e-Words ] ）
    
   
   1. 制御パステスト （control path test）  
      　プログラム中のコードがすべて実行されるようにテストデータを与えるテスト。
      　最も有名なホワイトボックスのテスト設計技法で、一般的に単体テストでカバレッジ（網羅率）の確認を求められた場合、制御パス・テストで計測できるカバレッジを指している。
      　大規模なシステムでは、 全てのテスト・ケースを実行するのは現実的でない事もあり、必ず網羅率１００％を目指す訳ではない。
      
      　テストする処理経路の網羅の度合いに応じて、C0網羅、C1網羅、C2網羅などの網羅基準がある。
      
      C0：命令網羅 ・・・ 全てのステートメントを 少なくとも1回は実行
      C1：分岐網羅 ・・・ 全てのブランチを少なくとも1回は実行
      C2：条件網羅 ・・・ コード内のすべての条件を少なくと も1回は実行
      
      　網羅基準は理論的な基準であり、実際にはC0、C1、C2 網羅を満たす網羅方法はそれぞれ幾つかある。
      　以下に代表的な網羅方法を示すが、それぞれの網羅方法が C0、C1、C2 のどの網羅基準に相当するかは、文献によって異なる場合があり、また網羅基準にピッタリとはあてはまらない網羅方法もある。
      
      　　 命令網羅（C0）、 判定条件網羅 、 条件網羅（C1）、 判定条件・条件網羅 、 経路組み合わせ網羅 、 複数条件網羅（C2）
      
      
      • 命令網羅 　　 　 ⊂ 判定条件網羅 　　　　　 ⊂ 判定条件・条件網羅 　 ⊂ 複数条件網羅
        
      • 命令網羅   ⊂ 判定条件網羅 　　　　　 ⊂ 経路組み合わせ網羅 　⊂ 複数条件網羅
      • 　　　　　　　　　 　 条件網羅 　　　　　　　 　⊂ 判定条件 ・条件網羅 　⊂ 複数条件網羅
        
      
      ※ 制御パステストの例 < http://writer.zoho.com/public/maxwelliandemon/control-path-test >
      
      
      1. 命令網羅 ／ 命令文網羅 （statement coverage）
         　コード上のすべての命令を最低一度は実行するようにテストケースを設計する方法。
         
         
      2. 判定条件網羅 ／ 分岐網羅 （branch coverage）
         　コード上のすべての条件判定を一度は実行するようにテストケースを設計する方法。
         
         
      3. 条件網羅 （condition coverage）
         　コード上のすべての条件判定において、１つの条件判定の結果が、真になる場合を最低１回、偽になる場合を最低１回 実行する様にテストケースを設計する方法。
         
         　条件網羅では、複数の条件文がANDやORで結合されている場合、テスト・データの選び方によっては、判定条件網羅でなら満たす分岐の true/falseのテストが十分にできない場合がある。
         
         
      4. 判定条件・条件網羅  
         　条件網羅を行い、さらに判定条件網羅を組み合わせて、通らないパスが無い様にテストケースを設計する方法。
         
         
      5. 経路組み合わせ網羅 ／ 経路網羅 （path coverage）
         　コード上のすべての経路を最低1回は実行する様にテストケースを設計する方法。  
          
         　 経路組み合わせ網羅 を実施すると、最もテスト・ケースの数が多い複数条件網羅に比べれば少ないとはいえ、やはり膨大になる。
         　そのため、全てのテスト・ケースを実行するのは現実的でない事もある。
         
         
      6. 複数条件網羅 ／ 分岐条件網羅 （multiple condition coverage）
         　コード上のすべての条件判定の組み合わせを網羅するようにテストケースを設計する方法。
         　網羅基準の中では最も厳しい基準となる。
         
         　条件式が２つなら条件は４通り、条件式が３つなら条件は８通り、条件式が４つなら条件は１６通りとなり、条件式が多いほどテストケースが指数的に増える ため、全てのテスト・ケースを実行するのは現実的でない事もある。
         
      
      （参考１： 制御パステストとは －[ e-Words ] ）
      （参考２： Code Coverage Analysis 、 Code Coverage Analysi s 機械翻訳による和訳 ）
      （参考３： Part2　ホワイトボックス技法 －[ テストの実践手法を理解する ] －[ITpro] ）
      （参考４： 単体テスト －[ 無駄なく確実にテストする ]－[ITPro] ）
      （参考５： テスト（ソフトウェアテストについて） －[ ＨＩＪＫ'Ｓ ＨＯＭＥ ＰＡＧＥ！！ ] ）
      
      
   2. データフロー・パステスト （data flow path test）
      　データや変数の使用の仕方に矛盾が無いかを調べるためのテスト。
      　プログラム中で扱うデータや変数について、定義→生成→使用→消滅 の各ステップが、この順番通りに行なわれているかが調べられるようにテストケースを設計する。
      　これにより、未定義、未生成、未設定など状態のデータを処理する様な不具合を発見することができる。
      
      　静的解析ツールの利用が効果的。
      （参考： ・ データフローパステストとは －[ e-Words ] 、   データフローパステスト －[ ソフトウェアテスト ]－[KGussan Webpage] ）
      

      Splint ：C言語用コードチェックツール 東陽テクニカ QAC++ ： C++用コードチェックツール Parasoft Codewizard ：C/C++用静的解析ツール 富士通 COReTOOL/PG-Relieh ：C/C++用静的解析ツール Coverity, Inc. coverity ：C/C++、Java用静的解析ツール Jlint ：Java用静的解析ツール Lint4j ：Java用静的解析ツール CheckStyle ： Java用静的解析ツール、コーディング標準に従っているかどうかをチェックすることができる PMD ：Java用静的解析ツール XLsoft VB Compress Pro ：VB用解析/最適化 ツール

         
      
      
   
   
2. ブラックボックス・テスト （black box test）
   　　プログラムの内部構造を考えず、入出力だけに注目して仕様通りにプログラムが動作するか確認していくソフトウェアテスト方法。
   　　テスト項目を導き出す方法には、単一の入力に対して考える場合には同値分割や限界値分析、入力が複数ある場合には原因結果グラフやディシジョンテーブ ルなどを用いる。
   
   （参考： ブラックボックステストとは －[ e-Words ] 、   システムテスト：テクノロジーを身につける（３）　テストの基本を身につける －[Allabout] ）
   
   
1. 入力値と出力値とその組み合わせを確認するテスト手法
   
1. 入力値および出力値の項目を決定する方法
1. 同値分割 （equivalence partitioning）
   　入力値および出力値を、コンポーネントまたはシステムの動作が同じと見なされる値の範囲＝同値領域に分けて、各同値領域を代表する値に対してテストを行 う様にテスト項目を決める方法。
   （参考： 同値分割 －[ 検収用語集 ]－[ （株）ベリサーブ ] 、 Part3　ブラックボックス技法 －[ テストの実践手法を理解する ]－[ITpro] ）
   
   
2. 境界値分析 （boundary value analysis、別名：限界値分析）
   　同値領域の端の値（境界値）をテスト項目とする方法。  
   　エラーは分岐の境界で発生する場が多いため、同値分割だけに基づいたテストに比べて多くの欠陥を発見できる事を期待できる。
   （参考：   境界値分析 －[ 検収用語集 ] －[ （株）ベリサーブ ] 、 Part3　ブラックボックス技法 －[ テストの実践手法を理解する ]－[ITpro] ）
   
   
2. テストケース（テストを行う 入力値と出力値の項目 とその 組み合わせ ）を決定する方法
1. ディシジョンテーブル を使ったテスト （decision table：決定表）
   　機能、データ、状態などの内２要素を組み合わせてマトリックス（デシジョンテーブル）で網羅してテスト項目を作る技法。
   　表にすると、全体の構成を見る事ができ、抜けを発見しやすい。
   　
   　項目が多く網羅が難しい場合 原因結果グラフ 、 原因流れ図 、 実験計画法 などを用いて項目数を減らすという方法もある。
   　 ディシジョンテーブルを使用して行うテストを マトリクス網羅テストと呼ぶ事もある。
   （参考： 決定表（ decision table ）とは －[ のんびりやろう！情報処理試験！ ] ）
   
   
1. 単純なディシジョンテーブルの使用
   　機能、データ、状態などの内２要素を組み合わせてマトリックス（デシジョンテーブル）で網羅してテスト項目を作る技法。
   　項目が多い大きなソフトウェアだと、この表を用いるのは困難だが、項目が少なく複雑な入出力をもつソフトウェアには効果的！ 。
   
   
2. 原因結果グラフ （cause-effect graph、別名：因果グラフ）
   入力と出力の関係を表す表を作成し、テストを行う技法。
   
   　Tech-On!のある記事では、『 ホワイト・ボックス・テストで合理的な手法は「原因結果グラフ」である。ただし，難しすぎてほとんど使われていない。 』とあった。
   　この記事では、その代替として、グレーボックステストの手法の１つである「 原因流れ図 （ ※↓ ）」を勧めている。
   （ 注 ： この記事では、原因結果グラフをホワイトボックステストで使用する技法としているが、 プログラムの内部を考慮してテストする訳ではなく、あくまでもシステムの機能のテストなので、 原因結果グラフはブラックボックステストの１つ 。）
   
   （参考：   原因結果グラフ －[ 検収用語集 ] －[ （株）ベリサーブ ] ）
   
   
3. 原因流れ図 （CFD：case flow diagram）
   グレーボックステストの原因流れ図 （ ※↓ ）を参照。
   
   
4. 実験計画法 （Design of Experiments、別名：タグチメソッド）
   
   （参考： 実験計画法とは －[ Tech-On!用語辞典 ] 、 直交表を利用したソフトウェアテスト-HAYST法- 論文（PDF: 439K） 、 発表用スライド（PDF: 1830K） ）
   
   
2. イベントと イベント発生前の状態 を入力、イベント発生後の状態を出力として とその組み合わせを確認するテスト手法
   
   1. 状態遷移テスト（ 調査・整理中 ）
        ソフトウェアの動作を 状態遷移図 や 状態遷移表 で表し、 そのノード（状態）とリンク（遷移パス）を網羅して、 「イベント発生前の状態」＋「イベント」 ごとの「イベント発生後の状態」が正しい結果になっていることを、 モデルを使って網羅するのが「状態遷移テスト」。
      
      　状態の数が多すぎるとモデルが複雑化し、テスト項目が増えすぎてテストできなくなるので、 ツールを使って作業の効率を上げる必要がある。 下記の文献（参考１）では１００を超えるならツールを使うべきと書かれている。
      
      　GUI のテスト、オブジェクト指向で設計されたソフトのテスト、通信プロトコルのテストなどに向いている。
      （参考１： 状態遷移テスト －[ ソフトウェアテスト ]－[KGussan Webpage] ）
      （参考２： OpenSESSAME 組込みソフトウェア技術者・管理者向けセミナー 初級者向けテキスト Chapter13（PDF:157K） ）
      （参考３： 状態遷移図 状態遷移表 －[Wikipedia] ）
      
      
      1. 状態遷移パステスト
         　状態遷移図で、状態と遷移パスを洗い出し、パスを網羅する経路を求めてテストを行う。
         
         
      2. 状態遷移マトリクステト
         　状態遷移表を用い、各状態でイベントが発生した場合の遷移を、 遷移 , 無視 , ありえない に分類して動作を確認していく。
         
      
   
3. ファズ・テスト （fuzz testing）
   　ソフトウェアにランダムな入力を与えてバグを見つけだすテスト。
   
   （ ファズ（fuzz）は ファジー理論で知られる"fazzy"（ぼやけた; あいまいな）という単語から出来た語で、 "けば", "綿毛", "〈…を〉あいまいなものにする" といった意味をもつ英単語。 ）
   
   （参考１： ファズ・テスト －[IBM Japan] ）
   （参考２： zzuf を使ったファズテスト 2007/07/31 ） －[ Open Tech Press ]   ）
   
   
3. グレーボックステスト
   　ある程度プログラムの中身が判っている事を前提に、インプットとアウトプットに注目するが、プロセスが正しく動いていることも含めて検証するテスト。
   　動作の検証についてはテストツールを用いるなどして、チェック用のコードを埋め込んだり、動作中のメモリ状況のチェックを行うなどする。
   
   
   1. 原因流れ図 （CFD：case flow diagram） （ 調査中 ）
      
      （参考： JaSST'07 Tokyo 「三賢者、テストを語る （DTvsCEGvsCFD）」 講演資料 （PDF: 682K） ）
      
      
   （参考１： 知っておきたいテストの“イロハ”（1） （本文最下部の少し上にグレーボックステストの記述がある） －[ ITPro ] ）
   （参考２： ブラックボックステスト、ホワイトボックステスト 目次 －[ 医療情報用語を覚えよう ] ）

1. 単体テスト （unit testing）  
   　メソッドなどの小さな単位で行うテスト。
   　ホワイトボックステストを利用して行われる場合が多いが、テストケース数が多くホワイトボックステストが困難な場合、ブラックボックステストと組み合わせて行う事も少なくない。
   
   　単体テストのツールとしては、テスティングフレームワーク xUnit が有名。
   　Java用のみだが TestNG も注目されている。
   
   　 Visual Studio の場合、 Visual Studio Team System には、単体テストのための機能（単体テストコードの生成、およびコードカバレッジの測定）やWebテストのための機能など、幾つかのテストのための機能が 含まれている。
   
   （参考： 単体テストとは －[ e-Words ]   ）
   （参考： Visual Studio Team System テストの種類 ）
   
   
2. 結合テスト （integration testing、 join test ）  
   単体テストでテストが完了したプログラムを組み合わせて行うテスト。
   
   参考： 結合テストとは － [ e-Words ]
    
   
   1. インクリメンタルテスト （incremental test、増加テスト）
      　テストの軸となるモジュールを選択して、そのモジュールに徐々にモジュールを追加してテストを進めていく手法。
      　長所は、欠陥のあるモジュールを絞り込むことができる事。
      　短所は、特別なテストコード（ドライバ、スタブ）が必要となる事。
      　（ 参考： 結合テストの手法 －[ITPro] ）
      
      
      1. トップダウン・テスト （top down test）
         　単体テストが完了したモジュールのうち、上位モジュールから順に結合させて行なうテスト。
         下位モジュールをエミュレートするダミー・モジュールである「スタブ」を作成する必要がある。
         参考：   トップダウンテストとは －[ e-Words ]
         
         
      2. ボトムアップ・テスト （bottom up test）
         　単体テストが完了したモジュールのうち、下位モジュールから順に結合させて行なうテスト。
         上位モジュールをエミュレートする「ドライバー」を作成する必要がある。
         　 xUnit や TestNG を用いると、この「ドライバー」の作成が簡単になる。
         
         参考： ボトムアップ・テストとは －[ e-Words ]
         
         
      3. サンドイッチテスト （sandwich test、別名：折衷テスト）  
           単体テストが完了したモジュールのうち、 中間のモジュールからテストを始めて上位、下位のモジュールを結合していく手法。
         
         　中間のモジュールから下位モジュールへ向けて結合していくテストはトップダウンテスト方式、 中間のモジュールから 上位モジュール へ向けて結合していくテストは ボトムアップテスト方式で並行して動作検証していく。
         
         　トップダウンテストと ボトムアップテスト の長所と短所を兼ね備えており、どれくらい有効かはモジュールの構造やテストの起点となる中間モジュールの選び方によって異なってくる。
         
         （参考：   サンドイッチテストとは －[ e-Words ] ）
      
      
   2. ビッグバンテスト （big bang test、一斉テスト）  
      　全てのモジュールを組み合わせてから一気に動作検証するテスト方法で、小規模なシステムや構造の単純なプログラムのテストに用いられる。
      
      　小規模なシステムにおいては、トップダウンテストやボトムアップテストなどの方法に比べて手間が少なく済むという利点がある。
       
      （参考：   ビッグバンテストとは －[ e-Words ] ）
      
      
3. システム・テスト （System testing）・・・システムテストの分類（ ※↓ ）  
   　プログラムを単体（単体テスト）や一部（結合テスト）ではなく、システム全体として実施するテスト。
   　他のプログラムや、他のハードウェア、ネットワーク、データベースなどと組み合わせてテストを行う。
   
   　システム全体のテストであり、機能テストのみではなく、パフォーマン・ステスト、負荷テスト、障害テスト、セキュリティ・テストなども含む。
   
   （参考： システムテストとは －[ e-Words ] ）
   
   
4.   アルファテスト 、 ベータテスト （beta testing）
   　特注でない（レディーメードの）ソフトウェアに対して良く用いられる、 開発の初期段階 にある製品 （アルファバージョン）、または 開発途中の製品 （ ベータバージョン） に対して、 実施するテスト。
   
   
   1.   アルファテスト （alpha testing）・・・ アルファテストとは －[ Insider's Computer Dictionary ]
      　開発の初期段階にある製品（アルファバージョン）に対して、ユーザーを 開発会社内の開発担当でない者か、ごく近しい見込みユーザーだけに限定して実施するテスト。  
      
      　アルファバージョンの製品は、一般的にはまだ不安定なレベルにある。
      
      
   2. ベータテスト （beta testing）・・・ ベータテストとは －[ Insider's Computer Dictionary ]
      　開発途中の製品（ベータバージョン） に対して、開発者達に関係の無い外部の者によるテスト。
      　場合によってはかなり広範囲にわたるユーザーに配布され、テストされることもある。
      
      　通常はベータバージョンの製品は、アルファバージョンでの問題点などがひととおり解消されており、完全ではないがそこそこ安定している。
   
   
5. 受入テスト （Acceptance testing、別名：検収テスト、承認テスト）  
   　ユーザが行う、システムが要求通りの機能や性能を備えているかどうか確認するテスト。
   （ 参考： 受け入れテストとは －[ e-Words ] ）
   
   
6. 回帰テスト （regression testing、別名：復帰テスト、退行テスト、縮退テスト）
   　プログラムを修正・変更した場合に、修正前の他の機能が動作することを確認するために行うテスト。
   （参考：   リグレッションテストとは －[ e-Words ] ）
   

1. 機能テスト／機能網羅テスト （別名：動作テスト）
   　システムが、要求される機能（入出力画面や操作性など）を満たしているかを検証する。
   
   
2. パフォーマンス・テスト （別名：性能テスト）
   　 　負荷を増した時のシステムの挙動やボトルネックを確認することが目的のテスト。
   
     現実に想定できる稼働環境（負荷、連続稼働時間など）の範囲で、 単体では問題が発生しない、通信、データベース、I/O、などが高負荷となった場合や、システムを長時間使用した際に性能が低下することが無いかを調べる。
   
   　フリーなパフォーマンス測定/負荷テストツールとして、JMeter が知られている。
   （参考： パフォーマンステストツール ）
   
   
3. 負荷テスト （stress test、別名：ストレステスト）・・・ 負荷テストとは －[ e-Words ]
   　システムに対して高い負荷を与え、システムがどこまでの負荷に耐えられるか（ハードウェアやソフトウェアが正しく動作するか）を実測確認するテスト。
   　長時間稼動、高負荷といった条件でテストを行う。
   
   　負荷テストツールが有効で、業界標準の負荷・性能検証用テストツールとして Mercury LoadRunner がある。
   　他に、フリーなパフォーマンス測定/負荷テストツールとして、JMeter が知られている。
   
   （参考１： 負荷テストツールとは －[ e-Words ] ）
   （参考２： 負荷テストの基本を学ぶ －[ ITアーキテクト ]－[ IDGジャパン ] ）
   
   
4. 障害テスト
   　設計や要件で想定されている障害に対して、システムが正しく動作し、意図しない動作や新たな障害が発生しないことなどを確認するテスト。
   
   
5. セキュリティ・テスト
   　セキュリティ・ポリシーがシステムに正しく反映されていることを確認するテスト。 　通常は、システム内部の権限や承認のコントロールを中心にテストする。

1. テスト駆動開発 （TDD：Test Driven Development）について
   　プログラム本体よりも先にテストケースを書くプログラム開発手法。
   　これは 設計・製作の手法であり 、テストは二義的。
   　 テストファースト ともいう。
   　多くのアジャイルソフトウェア開発手法で推奨されている。
   
   （参考１： テスト駆動開発 (test-driven development; TDD) とは －[Wikipedia] ）
   （参考２： テスト駆動開発のテストは、テストか？－TDD から BDD（Behavior Driven Development）へ ）
   （参考３： Visual Studio 2005を活用した、テスト駆動開発とソフトウェア品質向上アプローチ －[ThinkIT] ）