ソフトウェアテスト

目次

1. このページは
2. テスト手法
   1. ソフトウェア開発管理手法
3. バグに関して
4. テスト種類
   1. ホワイトボックステスト
      1. 制御パステスト
      2. データフローパステスト
   2. ブラックボックステスト
      1. 同値分割法
      2. 境界値分析法
         1. Jorgensen の境界値分析テスト法
         2. 具体的なテスト例
      3. ディシジョンテーブル
      4. 状態遷移テスト
      5. ランダムテスト
      6. エラー推測
         1. 仮説的推論
         2. エラー発見の技法
   3. システムテスト
      1. 構成テスト
      2. 負荷テスト
      3. 負荷テスト
      4. ユーザビリティテスト
   4. セキュリティテスト
   5. スモークテスト
   6. 回帰テスト
5. 運用
6. 計画
   1. テストプランニング
7. 品質管理
8. 自動化
9. 用語
10. 参考文献・参考ウェブページ
11. 履歴

このページは

ソフトウェアテストについてのメモ。
ドラフト版。

テスト手法

テスト手法には以下のような種類がある。

• カジュアルデザインレビュー(informal design review)
• フォーマルデザインレビュー(formal design inspection)
• インフォーマルなコードレビュー(informal code reviews)
• フォーマルコードインスペクション(formal code inspection)
• モデル化・プロトタイプ作成(modeling and prototyping)
• 個人コードチェック(personal code review)
• ユニットテスト(unit test)
• 新機能テスト(new function test)
• 統合テスト(integration test)
• 回帰テスト(regression test)
• システムテスト(system test)
• 小規模(10サイト以下)ベータテスト(low volume beta test)
• 大規模(1000サイト以上)ベータテスト(high volume beta test)

ソフトウェア開発管理手法

• 要求管理
• 構成管理
• 変更管理
• バグ管理
• etc.

バグに関して

• 場合によっては億の規模で損害が出る。
  
• すべてのバグは取れない。
• エラーは見つかるもの。
• 開発者はテストしてはならない。
• バグは特定の箇所に集中する。
• コードレビューとマトリックス網羅法が効果的。
• テストケースの数は膨れ上がるもの

テストパターン

ホワイトボックステスト

ホワイトボックステストとは、プログラムの論理構造が正しいかを解析するテスト。
論理構造のみを見るために、ソフトウェアの仕様のミスは発見できない。
時間がかかるためホワイトボックステストを行わず、ブラックボックステストのみ行われるプロダクトもある。

メモ
• マイクロソフトではホワイトボックステストを行っていないらしい。
• ホワイトボックステストとブラックボックステストは次元が異なり、優劣がつけられるものではない。
  ホワイトボックステストだけではテストは終了できない。
  
• 演繹法的。

制御パステスト

コントロールパステストとは、プログラムの振る舞いを解析しどう制御され実行されてゆくか、を見るテスト。
フローチャートをカバーすることが目的。

コードカバレッジテスト

コードカバレッジテストには以下の種類がある。

• ステートメントカバレッジ
  
• ブランチカバレッジ
  
• その他
  

バグの出やすい部分だけにブランチカバレッジテストを行うことも良い戦略。コードの一部を切り出してブランチカバレッジテストをすればプログラム全体の品質をある程度想像できる。

プログラムのループ・仕様と機能・データ・タイミングに関するバグはカバレッジテストでは検出できない。
エラー処理と使われていないコードはカバレッジテストではカバーされない。
カバレッジデータを取ることはテストの基本である。

ループの制御パステスト

ループのバグの対処方法には以下のようなテストの方法がある。

• ループをしない場合
  
• ループが1回
  
• もっとも典型的なループの回数
  
• 最大ループより1少ない数
  
• 最大ループの数
  
• 最大ループ＋１
  

マルチタスク・割り込み

マルチタスク・割り込みに関するバグは困難。対策としては以下が考えられる。
・データがプロセス間で共有されているか。共有されていたらそのデータのアクセスパターンを分析し、テストケースを作成する。
・すべてのプロセスについて生成と消滅のテストをする。
・出来るだけたくさんのプロセスを立ち上げてテストを行う。プロセスの突然死と終了不可能の状態が発生しやすくなる。

ツール

制御パステストを実行するツールは以下のようなものがある。

• Rational PureCoverage
  
• gcov
  

メモ

• カバレッジ基準は一般のソフトウェアなら50%-90% 程度か。
• おおくのソフトウェアはカバレッジを図られることも無く、60% 程度で出荷される
• 人命にかかわるソフトウェアはカバレッジは100% 近くが要求される。
• 一週間程度の依頼で、カバレッジを出してくれるコンサルタントもいる。
• カバレッジデータ・手法を信頼しすぎない。
  時間・予算と達成基準のトレードオフ。
• 80% を超えるカバレッジは注意が必要。充分な時間・予算。
• カバレッジを高くするほど費用も飛躍的に伸びてゆく。

データフローパステスト

データフローパステストとは、制御部分でなくプログラム中で使用されるデータに焦点を当ててテストする。

状態

データはおおまかに以下の3つの状態に分けられる

• 定義済(未使用)
  
• 消滅(定義後開放か消滅)
  
• 使用(使用されている
  

組み合わせは以下

• 定義済-定義済： 問題ないかもしれないが多重定義は疑問
  
• 定義済-消滅： バージョンアップ後に良くある。削除対象
  
• 定義済-使用： 通常
  
• 消滅-消滅： 2 回消滅の必要は無い。故にバグ。
  
• 消滅-使用： 未定義か解放後に使用。明らかにバグ
  
• 使用-定義済： バグではないかもしれないが、要注意。修正すべき
  
• 使用-消滅： 通常
  
• 使用-使用： 通常
  

ツール

静的解析ツールの利用が効果的。
ただし、警告が多すぎたり、導入が遅れると慣れるまで時間がかかったり扱いに注意が必要。

• Splint
• 東陽テクニカ：QAC++
  
• Parasoft：Codewizard
  
• 富士通：COReTOOL/PG-Relieh)
  

コードの複雑度を見るツールには以下のものがある。 サイクロマチック数で測ることが一般的か。東陽テクニカ：QAC++ で対応可能。また、McCabe Associates という会社もツールを出しているらしい。

• McCabe: サイクロマチック数
  
• Chen: 最大交差数
  
• Woodward： ノット数
  

メモ

• 全使用法データフローパステスト
  シンプルで使いやすい全使用法。
  データの使用の状態を網羅する。当然テストケースの数が制御パステストよりも多くなり費用が大きくなる。
  対費用効果で考えると制御パステストが多く選択されるようだ。
  

ブラックボックステスト

プログラムを一種のブラックボックスと見立て、さまざまな入力を行うことによってソースコードを利用せず、テストを行う手法。

メモ

• 同値分割法と境界値分析法は常にセットで用いられる。
• 同値分割法と境界値分析法はユーザによるさまざまな入力に対してソフトウェアが十分対応できるかを確認するテスト手法。

同値分割法

同値分割とは入力領域を同値クラスという部分集合に分割し、その部分集合に入る入力値を等価とみなす作業。

境界値分析法

プログラムの境界には常にバグが潜んでいる。境界値近くは詳しくテストする必要がある。

Jorgensen の境界値分析テスト法

最小値よりちょっと下、最小値、最小値のちょっと上、普通の値、最大値よりちょっと下、最大値、最大値よりちょっと上。

具体的なテスト例

• 境界をテストするにはOn-Off ポイント法を用いることが普通。
  異なる処理が行われる一番近い2 地点をテストする。
  
• 入力が1 - 999 までを想定しているプログラムのテスト値例。
  
  • 0： 0 は特別なバグになりやすい値。必ずテストすること。
    
  • 1： 有効な入力下限。
    
  • 499： 有効な入力の真ん中。
    
  • 999： 有効な入力の上限。
    
  • 1000： 無効な入力の下限。
    
• 経験則によるテストケース
  良いデータ
  
  • ユーザが良く使うデータ
    
  • プログラムが許す最小のデータ
    
  • プログラムが許す最大のデータ
    
  • ゼロ
    
  • 日本語入力のテストとして5c (理由十分理解しておらず)
    
  悪いデータ
  
  • 非常に小さいデータ
    
  • 非常に大きいデータ
    
  • 長いデータ
    
  • 無効なデータ
    

ディシジョンテーブル

すべての入力の組み合わせを表にし、その入力に対する動作もしくは出力を明記する。
複雑な状態が絡み合う機能のテストで力を発揮する。見やすくなり把握しやすくし、便利。
大きな問題は手間がかかりすぎるので非常に小さいソフトウェアか、大きなソフトウェアの一部しかテストに向かない。

• http://sysad.0kara.org/archives/000249.html
• http://fk-plaza.jp/Solution/solu_decide.htm
• http://d.hatena.ne.jp/keyword/%A5%C7%A5%B7%A5%B8%A5%E7%A5%F3%A5%C6%A1%BC%A5%D6%A5%EB

表には

• 状態
  
• ルール(状態の組み合わせ)
  
• 動作
  

がまとめられ、その表通りテストを実行する。

状態遷移テスト

ソフトウェアは一般的に常に同じ状態にあるわけではなく状態を変化させてユーザに対するソフトウェアの操作を容易にしている。
状態遷移テストは、この状態をモデル化してテストを行う手法。
状態遷移は状態(state)と遷移(transition)の2つにより表現される。

状態遷移テストで見つかるバグ

• 期待していない状態に遷移するバグ
  
• 遷移自体が無い場合。
  

問題点

状態の数が多すぎるとモデルが複雑化し、テスト項目が増えすぎてテストできなくなる。
２０－３０が手でテストする最適な値。
１００を超えるなら必ずサポートしているツールを使ってモデリング効率を上げる必要がある。

状態遷移テストが適しているソフトウェアは

状態によって振る舞いが異なるプロトコルテストには必須。

• GUI
  
• オブジェクト指向ソフトウェア
  
• プロトコルテスト
  

ランダムテスト

闇雲なテスト手法。

• 言い換えるとアドホックテスト(ad-hoc)、アドリブテスト、ランダムテスト、モンキーテストなどと呼ばれる。
• かなりの製品がこの手法か
• 見つかるバグは氷山の一角
• 境界値を見つけることが難しい場合など、自動化ツールを使ってランダムテストを走らせることもひとつの手。

エラー推測

与えられたプログラムにおいてもっともありがちな欠陥を想定してテストケースを特別に設計するもの。

仮説的推論

1. データを集めてなぜこういうデータになったか仮説を立てる。
   
2. 個々のデータについてなぜ上記の仮説に当てはめるかという説明付けをする。
   

仮説は以下のように立てる。

1. 以前のバージョンの開発サイクルの中でどのようなバグが発見されたかの傾向を見つける。
   
2. どのような種類のバグが多く発見されているのか、データに関するバグが多いのか、コントロールに関するバグが多く発生したのかを調べる。
   ユーザからのバグ情報も要考慮。
   

エラー発見の技法

• ソフトウェアの4つの処理について適切なテストケースを作る。(入力処理・出力処理・データ処理・計算処理)
  
• 入力部分があればさまざまなデータサイズやデータタイプを入力する。
  
• 入力の制限があれば、他の方法でその制限を越える入力を行う。
  

システムテスト

機能テストでカバーできないテストをするテスト。

構成テスト

• さまざまな条件の下でプログラムが動作するかをチェックする。
  
• マトリクス網羅法は機能テスト・境界値テストに最適であり、マネージャに説明しやすい。
• 構成テストは十分機能テストが終わった後に実行する必要がある。
  構成の問題か、機能の問題か、切り分けが出来なくなるため。
  
• 検証ラボを利用する方法もある。

負荷テスト（ストレステスト）

• 以下の点に注意。
  
  • 想定される最大サイズのデータがシステム上で規定時間内に問題なく処理されるかどうかをテストする。 システムはソフトウェア、ネットワーク、データベースなど、付随するすべて。
  • ユーザもしくはソフトウェアにかかわる人が行う、目的を達成するための操作が十分可能である。
    
• 負荷テストは非機能要求に対するバグを発見すること。
  非機能要求は
  
  • 拡張性
    
  • 再利用性
    
  • パフォーマンス
    
  • 信頼性
    
  機能を実現するために間接的に働く機能。
  
• ストレスツール
  
  • LoadRunner（マーキュリー・インタラクティブ・ジャパン）
  • e-Load（エンピレックス）
• 長時間に及ぶものも含めて負荷テストは必ず自動化するべき。
• 手動で負荷テストを行って問題があった場合、どんな原因によって問題がおきたかわかりにくく、再現性が無いバグになってしまう。
  このため、負荷テストは自動化することが重要。
  

パフォーマンステスト

• ソフトウェアを設計もしくは企画する段階で設定されたソフトウェアの性能が 期待されたとおり出ているかをチェックするためのテスト。
• パフォーマンスの定義は明確に。
• 要求定義どおりのテストケースを書かない。
  バグを見つけるためには要求定義どおりに動かないようなテストケースを設計しなければならない。
  
• パフォーマンステストは後回しにしない。
  ある程度動くようになったら定期的にチェックする必要がある。
  
• Shea はパフォーマンステストに以下の5ステップを推奨している。
  
  • アーキテクチャバリデーション（ソフトウェアがアーキテクチャ的に十分なパフォーマンスを発揮しているか。小さなプロトタイプソフトウェアをつくって実際に要求使用で定義されたデータ量を処理できるかを測る）
    
  • パフォーマンスベンチマーク（開発されたソフトのテストを行う）
    
  • パフォーマンス回帰テスト（回帰テストを行う）
    
  • パフォーマンスチューニング、アクセプタンステスト（最終製品が要求定義に定められたパフォーマンスを出しているか）
    
  • 24x7 パフォーマンスモニタ（顧客のデータを利用できないとき、ダミーデータでテストする。）
    
• パフォーマンステストも自動化は必須

ユーザビリティテスト

• ソフトウェアのテストではなく、ユーザの側に立ってその要求を満たしているかを 確認するテスト。システム全般（マニュアル、オンラインヘルプなど）
• アクセサビリティ（簡単に操作可能か）
• 効率性
• 学習性（使えばわかるか）
• 構造の明確さ（構造が明確か。出来ることがわかりやすいか。ヘルプが使えるか。）
• 操作性
• ユニバーサルデザインへの配慮（障害者にも、健常者にも使いやすいか）
• ユーザビリティテストは実際にユーザにテストしてもらうべき

セキュリティテスト

機密性(confidentiality), 完全性(integrity), 可用性(availability) が保たれているか。
狙われる攻撃方法はバッファオーバーフロー・パス・不正入力など。
バッファオーバーフローを検出する静的解析ツール（splint など）が効果的。
システムレベル・機能レベルの両面でセキュリティを確認することが重要。

スモークテスト

スモークテストはビルド確認テストのこと。
ビルド後に単純なテストを流す。

回帰テスト

回帰テスト(regression test) は一度パスしたテストをバージョンアップ時に再度テストすること。
変更により発生するバグをつぶすことに効果がある。
一度行ったテストを記録・再現する、キャプチャーアンドリプレイ機能が効果的。
Mercury WinRunner, IBM Rational Robot など。
回帰テストは時間がかかるため、重要なテストから行う。自動化はせずとも、修正前後に担当者が走らせる程度でよい。

運用

ソフトの種類によってコードカバレッジ率の目的の値が違うので、はじめに設定をよく確認すること。
商用ソフトウェア製品を作るにはテスト費用＋サポート費用＋メンテナンス費用の値が最小でなくてはならない。
回収は最悪の状態で、それを防ぐために、MS など、開発者と同数のテスト担当者がいる企業もある。

計画

テストプランはIEEE829 というテンプレートがある。これをベースにすると説得力がでる。
これに加えて終了基準を追加することと、各項の確認を進めることも重要。
そしてテストケースを書く際にはツールの導入が必要不可欠。すべてワードなど、効率が悪くてとんでもない。

• http://standards.ieee.org/reading/ieee/std_public/description/se/829-1983_desc.html
• http://en.wikipedia.org/wiki/IEEE_829
• http://kazu5.exblog.jp/3014629/

テストプランニング

リスク＝問題のおこる確立x問題が起こった場合のダメージまたはコスト

• IEEE829
  • テストプラン
  • テスト設計仕様書
  • テストケース仕様書
  • テスト手順仕様書
  • テストアイテム送付レポート
  • IEEE829 テストテンプレート
    • テスト計画書識別番号(Test plan identifier)
    • リファレンス(Reference)
    • はじめに(Introduction)：簡単な説明と背景を含むテストされるソフトウェアの概略
    • テスト項目(Test Items)：テスト対象となるソフトウェア項目を記載
    • テストを要する機能：品質属性は機能性、パフォーマンス、セキュリティ、移植性、ユーザビリティ
    • テスト不要機能(Features not to be tested)：理由も必要
    • アプローチ(Approach)
    • テスト項目の合否基準(Item pass/fail criteria)
    • 中止基準と再開要件(Suspension criteria and resumption requirements)
    • テスト成果物(Test deliverables)：テストプロセスの一部として作成されるドキュメントの記載
    • テストタスク(Testing tasks)：テスト実行のために必要なタスク
    • 実行環境(Environmental needs)
    • 責任範囲(Responsibilities)
    • 人員配置、トレーニング計画(Staffing and training needs)
    • スケジュール(Schedule)：鍵となる日付、マイルストーンを定義
    • リスクと対応策(Risks and contingencies)
    • 承認(Approvals)
  • http://standards.ieee.org/reading/ieee/std_public/description/se/829-1983_desc.html
• マスターテストプラン決定方法
  重要度大
  • テスト範囲
  • テスト仕方/分担
  • テストスケジュール
  • バグ管理やテストケースなどテスト管理インフラ
  • テストリリースや変更管理の通知方法
  • 計画上のリスク
  詳細
  • テストアイテム
  • テスト対象機能/非対象機能
  • 設計技法/実施方法
  • ツール(自動化)プラン
  • テストパスの種類やテストサイクル
  • 開始/終了基準
  • テスト環境
  • テスト実施の詳細スケジュール
  補足
  • テストベース(テストの基にするドキュメント)収集を子ながらテスト アイテムの分析を行う。
  • 大変な場合にはヒアリングを行う。
  • テスト対象の分析・設計の流れ
    1. テスト対象の情報収集を行う。
    2. テスト対象の要求仕様を整理し、一覧にする。
    3. 各要求仕様に適用するテストの種類を具体的にする。
    4. 優先度の高いものを洗い出す。
    5. テストケース作成方針を決める。
• プランニング
  1. テストリーダ任命
  2. テスト範囲、環境、プロセス決定
  3. 見積り
  4. メンバ人選、合流時期決定
  5. マスタテストプラン作成
  6. テスト分析
  7. 詳細テストプラン作成
  8. テストケース作成
  9. テスト実施のスケジュール作成
• テストのやりかた
  1. テスト分析
  2. テストプラン作成
  3. テストケース作成
  4. テスト実施準備
  5. テスト実施
  6. バグ管理
  7. テスト結果の評価・報告

品質管理

ソフトウェアの質を定量的に評価するためにメトリックス(品質の指標)を使う。
バグメトリックスをあらわす表では、縦軸にバグ数、横軸に時間を記載して記録してゆく。 プロジェクトの終わりになると編微分値は小さくなり、結果的にプロジェクトの終わりには横ばいになる。 ならなければ問題があり、出荷不可能。 一様にバグの数を計上せず、重要度でグラフを分けることも質を表すのに効果的。
バグの修正時間はプロジェクトの終わりに近づくと小さくなってゆく。
また、テストはモジュール単位で切り分け、問題のあるブロックを抽出することも可能。
しかしテストグループごとの差が出るので性質を良く見て分割したモジュールを一様に評価してはいけない。

コードカバレッジメトリックスは重要。
ソースコードメトリックスはおかしな変更などに気づくことができる。
複雑度のメトリックスは注意すべき点に気が付くことができる。

自動化

自動化にむくテストとむかないテストがある。
単純なテストは良いが、回帰テストなどはメンテナンスが複雑になりすぎる。またグラフィックス・サウンドは自動化が難しい。

用語

カバレッジ率(coverage rate)

対象に対してカバーしている割合。製品の品質を定量的に表せる。

ステートメントカバレッジ

コードの中の命令文（ステートメント）を少なくとも1 回は実行する。
通らないパスが発生しやすいため、非常に弱いテスト方法。

ブランチカバレッジ

分岐コードに対してそれぞれの判定条件がTRUE, FALSE の結果を少なくとも 1 回ずつ持つようにテストケースを書く。
パスをすべて通るので、ステートメントカバレッジよりも強力。

サイクロマチック数

Cyclomatic。サイクロマチック数が大きいとバグを生みやすい
C(複雑度) = e - n + 2
e: ルートの数、n: 分岐の数
30を超えるとバグ修正が困難。

有効同値

プログラムが期待する入力値。

無効同値

プログラムが期待していない入力値。

有限状態マシン(Finite State Machine)

NA

Not Applicable、 適用不可。

ドメイン

基本的に境界値分析法。詳細は文献等参照。

参考文献・参考ウェブページ

• http://www.amazon.co.jp/gp/product/4774127116/sr=1-2/qid=1162626130/ref=sr_1_2/250-0489491-0835434?ie=UTF8&s=books
• 知識ゼロから学ぶソフトウェアテスト

履歴

• 2007/03/07 更新
• 2006/11/03 更新
• 2006/00/00 作成
  [content]