担当:藤井
ソフトウェアテスト第2回
テストの種類と位置付け
ソフトウェア開発段階の概略
製品のライフサイクル
- 計画
- 設計
- コーディング、ドキュメント化
- テストと修正
- 保守
テストは全体のコストの15%em>を占める
バグは早期に発見・修正するほど、安くすむ
次から色々な段階におけるテストを説明します。
色々なテストについて（計画段階）
考え方を検証する
- 「正しい」要求仕様か？
- 要求仕様は完全か？
- 要求仕様間に矛盾はないか？
- 要求仕様は実現可能か？
- 要求仕様は妥当か？
- 要求仕様はテスト可能か？
製品比較評価法
評価対象と市場の既存競合製品の違いを分析する。
競合力を強くするにはどうすればいいかを考える。
フォーカスグループ法
知らない人同士のグループを作り、あるトピックについて議論してもらい、アイディアに対する市場の反応を調べる。
業務分析法
作業を観察したり、インタビューして業務の特徴を調べる設計手法
Q. 井上：「この三つを提示した意図って何?」
A. 藤井：「システムの評価項目が妥当かどうかをみるため」
色々なテストについて（設計段階）
この段階では考え方を検証します。
- 設計は正しいか？
- 設計は要求を満たしているか？
- 設計に漏れはないか？
- 設計は実現可能か？
- エラー処理をどれだけカバーしているか？
藤井：「代表的なレビューの一覧はこちらです。」
レビューミーティング
- ウォークスルー:作成者が作業成果物をレビュアーに説明し、コメントを求める。カジュアルなレビュー形式。
- インスペクション:作成者以外の参加者が会議を主導し、チェックリストと照らし合わせて、設計書の各行をチェックする。厳格な(ウォークスルーより)レビュー。
- 技術レビュー:問題点一覧を持って集まって説明、指摘する。
疑似コードアナライザ
疑似コード：プログラムの構造を英語に結び付ける人工言語
疑似コードで記述したものをプログラム（疑似コードアナライザ）を用いて解析、バグを検出する。
色々なテストについて（実装段階）
ホワイトボックステスト
コーディング段階でのテスト
藤井：「プログラマが内部構造を把握した上で行うテスト」
利点
- 細部までテストできる
- テストした行が明らか
- 制御フローを知っている
- データ操作の期待値が分かっている
- 内部境界値が明らか
パス網羅基準
ホワイトボックステストでどれくらいしっかりテストをするかの基準
if (A < B and C = 5){
do_something();
}
$variable = 5;
- 命令網羅:ソースコード中の命令を最低一回実行する
- 分岐網羅:全ての条件文での真と偽を検証する
- 条件網羅:各条件の全ての真と偽の組み合わせを検証する（一番厳しい）
インクリメンタルテスト
モジュール毎のテスト（単体テスト）を行った後、各モジュールを統合してテスト（統合テスト）する。
すべてのモジュールが統合するまでテストを繰り返す。
ビッグバンテスト
全部ができあがってから一気にテストする。
インクリメンタルテストの特徴
- テストコードが必要になる
- どこにバグがあるか分かりやすい
ビッグバンテストの特徴
- テストコードが不要
- 不具合の原因究明が困難
- テストコードがないため自動化できない
インクリメンタルテストの手法
トップダウンテスト:スタブ（テストする関数から呼ばれるテストプログラム）から始める
ボトムアップテスト:ドライバ（テストする関数を呼ぶテストプログラム）から始める
静的テスト
- プログラムを実行せずにソースコードをチェックする
- コンパイラを使用
- コードレビュー、机上チェックを行う
動的テスト
プログラムを実行するテスト
回帰テスト
1 .バグを修正した後、バグを検出したテストデータを再実行する
2 .バグ修正後に変更が他の機能に悪影響を与えていないか確認するためにテストを実行
ブラックボックステスト
システムの内部構造は考慮せず、仕様を満たしているかどうかのみを検証するテスト
下の二つで使用される
* 機能テスト：外部仕様での機能を満たしているか
* システムテスト：ユーザ要件をみたしているか
テスト例
- 仕様確認テスト
外部仕様書に対してプログラムの動作を比較する - 正確性テスト
プログラム中の計算方法、計算結果の表示が正確か評価する - 操作性テスト
ユーザがどのように使用するか分析する（ベータテスト） - 境界条件テスト⑤
すべての入力に極端な値を設定してプログラムをチェックする - 性能テスト
各タスクの実行時間を測る。 - 状態遷移テスト
プログラムがある状態から別の状態へ正確に移ることをチェックする。各処理を正しい順番で行うか等。 - 日常業務テスト
ユーザの通常の使用法を想定して、製品を使ってみる。 - 負荷テスト
- 大容量テスト（巨大ファイルや空のファイルを読ませる）
- ストレステスト（処理の限界ぎりぎりでテスト）
- 記憶領域テスト（メモリやディスクの限界を超えてテスト）
- バックグラウンドテスト
並列処理で複数ジョブを同時実行してみる。
複数ユーザで処理してみる。 - エラー処理テスト
できるだけ多くのエラーを発生させて全エラーメッセージを表示させる。
エラー処理コードはテストがおろそかになりがち。 - セキュリティテスト
権限のないユーザでシステムのどのデータに何ができるかチェックする。
Q. 「ホワイトボックステストとブラックボックスの違いってわかりました?」
A. 「ホワイトボックステストとブラックボックステストは責任範囲が違う」
コメント
井上:「設計段階のレビューミーティングについては、ウォークスルーとインスペクションの時に観点をまとめておくものなので、重要」
参考書籍
(著)Cem Kaner, Hung Quoc Nguyen, Jack Falk, (翻訳)テスト技術者交流会(2001)『基本から学ぶソフトウェアテスト』日経BP社 488pp.
ISBN4-8222-8113-2
第3章 テストの種類と位置付け(p27-58)