ソフトウェアテストの基礎

Version:1.0 of 2011/05/08
Author:SUZUKI Masashi / masasuzu
Mail:m15.suzuki.masashi@gmail.com

始めに

ほんとうにいっぱんてきな用語と概念を話すので、ここの詳細に関しては ぐぐるか参考文献を読み込んでください。

Agenda

  1. テストの基礎
  2. テストプロセス
  3. テスト設計技法

テストの基礎

テストの必要性

なぜテストをするのか

ソフトウェアが正しく動作しないと、経済的な損失、時間の浪費、信用の失墜など、いろいろな問題が発生し、時には傷害や死亡事故になることもあります。それらを回避するためにソフトウェアが正しく動作することを保証するためにテストを行います。

一般的に、欠陥を検出して修正するコストは、時間の経過とともに高くなっていきます。早期に欠陥をつぶすことが肝要となります。

テストをすることによりソフトウェアの品質を測ることができます。ソフトウェアにおける品質とは、コンポーネントやシステムが指定された要求、ユーザ、顧客のニーズ、期待を満たす度合いをいいます。テストを十分に行うことによってソフトウェアにおける品質に対する確信を与えることができます。

誤り、欠陥、故障

誤り(エラー)
間違った結果を生み出す人間の行為。 ユーザの誤った使用に限らず、設計中や実装中に行う誤りも含む。
欠陥(バグ、フォールト)
要求された機能をコンポーネントまたはシステムが果たせなくするシステムまたはコンポーネント中の不備。 たとえば、不正な命令やデータ定義。 中性子によるメモリ反転などがフォールトに分類されます。 cf) はやぶさ
故障
コンポーネントやシステムが期待した機能、サービス、結果を提供できないこと。

人間は誤り(エラー)を起こします。その結果それが、ドキュメントやソースコードの欠陥となります。ソースコードの欠陥を実行するとシステムが正しく実行されず、故障が起きます。ただし、すべての欠陥が故障となるわけではありません。

欠陥と故障の原因

  • ソフトウェアとシステムの仕様、設計、実装における誤り
  • システムの使用における誤り
  • 環境条件
  • 故意による損害

テストの7原則

テストは欠陥があることしか示せない
テストによって欠陥があることを示すことができるが、欠陥が無いことをしめることはできません。 テストによって欠陥が摘出できない状態でも、正しさの証明にはなりません。
全数テストは不可能
すべての入力条件のテストを行うことは非現実です。 全数テストの代わりにリスクや優先順位に基づくテストの焦点をしぼるべきです。
初期テスト
テストはなるべくソフトウェア開発のライフサイクルの早い時期から開始し、 あらかじめ定義し目的に集中すべきです。
欠陥の偏在
リリース前のテストで見つかる欠陥や運用時の故障の大部分は、ある特定のモジュールに集中します。
殺虫剤のパラドックス
同じテストを何度も繰り返すと、最終的にはそのテストでは新しいバグを見つけることができなくなります。 テストケースを定期的に見直す必要があります。
テストは条件次第
条件が異なれば、テストの方法も異なる。 エンタープライズとWEBアプリでは必要なテストは異なる。
「バグゼロ」の落とし穴
欠陥を見つけて修正しても、構築したシステムが使えなかったり、 ユーザの要件や期待を満足しなければ役に立たない。

基本的なテストプロセス

一般的なソフトウェア開発プロセスと同様にテストにもPDCA的なサイクルを行います。

  • 計画とコントロール
  • 分析と設計
  • 実装と実行

テストプロセス

ソフトウェア開発モデル

ソフトウェアテストのライフサイクルモデルには以下のものがある。

  • V字モデル(W字モデル)
  • 反復型モデル
    • RAD開発
    • アジャイル開発

いずれのライフサイクルモデルを用いるにしても以下の特性を守ることで良いテストができます。

  • すべての開発作業に対応するテスト作業がある
  • それぞれのテストモデルには、そのレベルに固有のテスト目的がある
  • 所定の鉄とレベルのためのテスト分析・設計は対応する開発作業中に始めるべきである
  • ドラフトが開発サイクルで利用可能になったらただちに、テスト担当者は文書のレビューに関与すべき

テストレベル

  • コンポーネントテスト (実装)
  • 結合テスト (詳細設計)
  • システムテスト (外部設計)
  • 受け入れテスト (要求)

テストタイプ

  • 機能テスト
  • 非機能テスト
  • 構造テスト
  • 変更にともなうテスト
    • 確認テスト
    • 回帰テスト

テスト設計技法

テストのアプローチとして静的テストと動的テストがあります。 静的テストと動的テストは補間関係にあり、ことなるタイプの欠陥を検出できる傾向にあります。

静的テスト

レビュー

公式レビューのフェーズ

  1. 計画
  2. キックオフ
  3. 個々の準備
  4. レビューミーティング
  5. 再作業
  6. フォローアップ

レビューの種類

  • ウォークスルー
  • テクニカルレビュー
  • インスペクション

ツールによる静的解析

主な観点

  • コーディング規約
  • コードメトリクス
  • コード構造

動的テスト

動的テストの分類

  • 構造ベース(ブラックボックステスト)
    • ステートメント
    • デシジョン
    • 条件
    • 複数条件
  • 経験ベース
    • エラー推測
    • 探索的テスト
  • 仕様ベース(ホワイトボックステスト)
    • 同値分割
    • 境界値分析
    • デシジョンテーブル
    • 状態遷移
    • ユースケーステスト

参考文献