ももの知恵の樹

ソフトウェアテスト技法

ソフトウェアテストについて

ソフトウェアテストの7原則

ソフトウェアテストの7原則とは、ソフトウェアテスト技術者の国際的な資格認定団体であるISTQBが提唱しているソフトウェアテストの原則です。

原則 説明
テストは欠陥があることは示せるが、欠陥がないことは示せない
Testing shows the presence of defects, not their absence 		そもそもテストで全ての欠陥をみつけられるわけではないことを認識するべきという考え方です。
全数テストは不可能
Exhaustive testing is impossible 		全数テストとは、考えうる全てのパターンでテストを行うことを指します。
予算面や納期を考慮して、重点的に実施するテスト箇所を絞り込むことが必要です。
早期テストで時間とコストを節約
Early testing saves time and money 		早期テストとは、開発の早い段階で行うソフトウェアテストのことです。
開発の早期段階でバグを検出できれば、その修正は容易で低コストです。
欠陥の偏在
Defects cluster together 		欠陥の偏在とは、ソフトウェア品質は全体で均一ではなく、特定の箇所に欠陥が集中することが多いという意味です。
テストの労力を集中させるために欠陥の偏在を予測し、観察結果に基づいてリスク分析を行います。
殺虫剤のパラドックスにご用心
Beware of the pesticide paradox 		殺虫剤のパラドックスとは、同じ殺虫剤を使い続けると害虫が耐性を持ち、いずれ効かなくなることを指します。
テスト項目やテスト方法は定期的に見直し、アップデートすることが大切です。
テストは状況次第
Testing is context-dependent 		ソフトウェアの性質や実行環境などによって、テスト方法を柔軟に変えるべきという考え方です。
「バグゼロ」の落とし穴
Absence-of-errors is a fallacy 		テストで見つけた欠陥を全て修正できたからと言って、必ずしも品質を向上させるとは限らないという考え方です。

ソフトウェアテストの資格

テストエンジニアに求められるスキルを認定する資格試験として、以下のものがあります。


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

実施テストの分類

  • 動的テスト
    • プログラムを実行して行うテスト
  • 静的テスト
    • プログラムを実行せず、第三者によるコードレビューや解析ツールによる分析を行うテスト

開発フェーズによるテストの分類

ソフトウェア開発プロセス（JIS X 0160）には検証プロセスと妥当性確認プロセスがあります。
それぞれのプロセスで実施するテストは検証テストと妥当性確認テストになります。

検証テストは、「製品が正しく作られたこと」を判断するテストとなります。
ソフトウェアが仕様と要件を満足しているか検証（ソフトウェア適格性確認）するために、単体テスト、統合テスト、検証テストを実施します。

妥当性確認テストは、「正しい製品が作られたこと」を判断するテストとなります。
システムが利用に適しており、要件を満足することを確認するために、受入れテスト、妥当性確認テストを実施します。


テスト種別 説明
単体テスト（Unit Test） ソフトウェアユニット（モジュールやコンポーネントなど）の単体の機能単位で確認するテストのこと。
統合テスト（Integration Test / 結合テスト） 2つ以上のソフトウェアコンポーネントやソフトウェアユニットを組み合わせて、機能要件を動作検証するテストのこと。
機能テスト（Function Test）とも呼ばれ、製品要件で定義された機能を動作検証します。
検証テスト（Verification Test） ソフトウェア（システム）が仕様通りに作成され、仕様通りに動作することを確認するテストのこと。
システムテスト（System Test）とも呼ばれ、システム全体で動作検証します。
受入れテスト（Acceptance Test） システムがユーザが設定した受入れ基準を満たしているか確認するテストのこと。
発注者による製品の検収テストとなります。
妥当性確認テスト（Validation Test） ビジネス目標やステークホルダ要件を達成することを確認するテストのこと。
運用を通して行われるテストとなります。

システムテストの分類

  • 回帰テスト（リグレッションテスト）
    • ソフトウェアに修正や変更が加えられた場合に、既存の機能に悪影響を与えていないことを確認するテスト
  • デグレードテスト（degrade）
    • リグレッションテストと同義。デグレードはIT業界において和製英語のような言葉になっている
  • スモークテスト（Smoke testing）
    • ソフトウェアがテストを行うに値する品質であるかを確認する簡易的なテスト
      元来は、電子回路を組み上げて電源を入れた時に煙が出ないことを確認するテストを指していました。
  • 性能テスト（パフォーマンステスト）
    • ロングランテスト（Soak or endurance testing)
      • 長時間の連続稼働によって処理能力や稼働率に問題が生じないかを確認するテスト
    • 負荷テスト（Load Testing）
      • 極端に高い負荷をかけた状況下での動作を確認するテスト
    • スパイクテスト（Spike testing)
      • 突然のピーク負荷から定常状態に戻るまでの一連の性能を確認するテスト
  • セキュリティテスト（脆弱性検査）
    • ペネトレーションテスト（ペンテスト・侵入テスト）
      • 攻撃者の視点からシステムを攻撃し、脆弱性を検証するテスト
    • 脆弱性スキャン
      • 自動化されたツールを使用して、脆弱性を検証するテスト

ブラックボックステスト

ブラックボックステストとは

ブラックボックステスト技法とは、内部構造を考慮せず、実装された振る舞いを確認するためのテスト技法です。
ソフトウェアの要件仕様や基本設計に基づいてテストを設計します。


ブラックボックステスト技法


ホワイトボックステスト

ホワイトボックステストとは

ホワイトボックステスト技法とは、コンポーネントやシステムの内部構造の分析を基にして動作確認するテスト技法です。
ソフトウェアの設計/実装の詳細仕様に基づいてテストを設計します。


ホワイトボックステスト技法

  • 制御フローテスト
    • カバレッジ基準によって、さまざまな呼ばれ方があります。
      ステートメントカバレッジで実施するテストを「ステートメントテスト」といい、デシジョンカバレッジで実施するテストを「デシジョンテスト」といいます。
  • データフローテスト

経験ベースのテスト

経験ベースのテストとは

経験ベースのテストとは、テスト担当者の知識・経験・勘をベースにテストケースを設計するテスト技法のことです。
過去の同じようなシステムで見つかった欠陥や、過去の事例をテストに反映することで、一般的なテストで見つけられない不具合を検出します。
なお、経験ベースのテストは単体で実施するのではなく、一般テストを補う形で併用して実施すると効果的です。


経験ベースのテスト技法

  • 探索的テスト
    • テスト実行者がテスト内容の作成とテスト実行を同時に並行して行うテスト手法
      アドホックテストやモンキーテストと異なり、ある程度の目的や方針を定めておきます。
  • エラー推測
    • テストケースを作成する人の経験則に基づいてエラーが起きそうな値を決定するテスト手法
  • チェックリストベースドテスト（checklist-based testing）
    • 事前に作成したチェックリスト（組織のノウハウを形式知化した資産）を用いて評価を実施するテスト手法
  • フォールト攻撃（故障利用攻撃）
    • 物理的な欠陥や故障などを起こして、意図的に誤動作を引き起こすテスト手法

その他テスト技法

テスト技法

  • エラー埋め込み法
    • 一定数のバグを意図的に埋め込んだ状態でテストを行い、発見率と本物のバグの比率からバグの数全体を推計する、バグ数推定手法
  • トランザクションフローテスト法
    • １つのトランザクションに対して、開始から終了までの処理が正しく実行されるかを確認するテスト手法
  • ドメインテスト（ドメイン分析テスト）
    • ドメイン分析（入力要因に対して、on、off、in、outの分析）を実施し、関係性がある複数の変数を同時にテストする手法

信頼度成長曲線（Software Reliability Growth Curve）

縦軸にバグの累積発見数、横軸にテスト項目消化数をとったテスト実施予測のためのグラフです。
テスト項目の消化に合わせてS字の成長曲線を描きます。