ソフトウェア・テスト入門6

第6回「上級テスト」
2011年7月15日（金）
服部健太
ソフトウェア・テスト入門

上級テストの必要な理由
 ソフトウェア・エラーの定義：
 この定義からいうと，完全なモジュールテストが
実行されたとしても，すべてのソフトウェア・エ
ラーが発見されていると保障することはできない
2011/7/152 ソフトウェア・テスト入門６
ソフトウェアのエラーは，プログラムをつかう
ユーザが当然のこととして期待していることを
実行しない場合にあらわれる

ソフトウェアの開発過程
2011/7/15ソフトウェア・テスト入門６3
1. プログラムの最終ユーザの要求を要求仕様書の
形に変換する
2. 実行できるかどうかをしらべ，コストをみつも
ることによって，要求の矛盾を解決し，優先順
位とバランスを調整して，要求仕様書を目的仕
様書に変換していく
3. その製品をブラックボックスと見て，外部世界
とのあいだの単なるインタフェースという捉え
方をしながら目的仕様書を製品の正確な仕様書
に変換する
4. この製品が1つのプログラムでなく，1つのシス
テムの場合，つぎの過程はシステム設計になる．
この段階では，システムを個々のプログラム，
構成要素，サブシステムに分解し，それらの間
のインタフェースを定義する
5. そのプログラムの構造は，各モジュールの機能，
モジュールの階層構造，モジュール間のインタ
フェースを指定することで設計される
6. 各モジュールのインタフェースと機能を決定し
ながら正確な仕様書を作成する
7. モジュールインタフェースの仕様をモジュール
のソースコードによるアルゴリズム記述に変換
する
最終
ユーザ
要求仕様
目的仕様
外部仕様
システム設計
プログラム構造設計
モジュール・
インタフェース設計
コード

開発過程とテスト過程の一致
最終
ユーザ
要求仕様
目的仕様
外部仕様
システム設計
プログラム構造設計
モジュール・
インタフェース設計
コード
検証
検証
検証
検証
検証
検証
検証
認可テスト
システム・テスト
機能テスト
統合テスト
モジュール・テスト
導入テスト

機能テスト
 プログラムと外部仕様との相違点を発見する過程
 ブラックボックス指向
 テスト・ケースを得るために仕様を分析する
 同値分割，限界値分析，原因－結果グラフ作成，エ
ラー推測手法が適している
 無効な，また意図しない入力条件に十分な注意を
はらうこと

システム・テスト
 システム，またはプログラムをもとの目的仕様書
と比較すること
 システムの機能をテストする過程ではない
 目的仕様書から外部仕様を設計する過程でおきる変
換エラーを見つける
 システム・テストは「システム」にかぎらない．
製品がプログラムの場合は，システム・テストは，
いかにプログラムが目的仕様書の内容とあわない
かをしめそうとする過程である
 プロジェクトがその製品について評価できる目的
仕様書を作成しなければ，システム・テストは不
可能である

システム・テスト・ケースの設計
 機能部分テスト(facility testing)
 目的仕様書に書かれている機能部分が実際にみたされて
いるかどうかを判定する
 目的仕様書を1文ごとにしらべて文が「何々」を指定している
とき，そのプログラムがその「何々」を満たしているかどうか
を判定する
 目的仕様書とユーザ文書を比較するだけで十分なことも
多い
 大容量テスト(volume testing)
 プログラムに大量のデータをあつかわせる
 コンパイラに大きなソース・プログラムをコンパイルさせたり，
電子回路のシミュレータに多数のモジュールをもつプログラム
をあたえたりするなど．
 プログラムがその目的仕様書で指定されたデータ量をあ
つかうことができないことをしめすのが目的

システム・テスト・ケースの設計(2)
 ストレステスト(stress testing)
 プログラムに重い負荷をかけること
 短い時間に最大容量のデータを与える
 会話型やリアル・タイムのプロセス制御プログラムに適
用可能
 有用度テスト(usability testing)
 人間的要因または有用度の問題を見つける
 チェックポイント：
 ユーザーインタフェースはユーザの知識にあわせているか．プ
ログラムの出力が適切か．エラーメッセージは単刀直入で理解
可能か．ユーザーインタフェースの全セットは統一性，一貫性
をもっているか．正確さが重要なところで，入力に十分な冗長
性をもたせてあるか．すべての入力に対してある種の即答をか
えしているか．プログラムは使いやすいか．

 秘密保護テスト(security testing)
 プログラムの秘密保護にたいするチェックをくつが
えすテスト・ケースを準備する過程
 よく似たシステムの知られている秘密保護問題につ
いて研究し，自分がしようとするシステムについて
おなじような問題を明らかにできるテスト・ケース
を作成する．
 効率テスト(performance testing)
 効率または能力の目的仕様をみたさないことをしめ
すようなテストケースを作成する
 ある実働負荷と構成条件のもとでの応答時間や処理出力

 記憶域テスト(storage testing)
 記憶域についての目的仕様がみたされていないよう
なテストケースを作成する
 プログラムで仕様する主記憶域と２次記憶域の量と，必要
な一時ファイルの大きさなど．
 構成テスト(configuration testing)
 可能な構成の組合せがあまりにも多くて，それぞれ
についてプログラムをテストすることができないこ
とはよくあるが，少なくとも各型式のハードウェア
機器と最小・最大の構成でプログラムをテストしな
ければならない

 互換性／変換テスト(compatibility/conversion testing)
 既存のシステムとの互換性と変換手順にかんする目的仕
様をもつ場合，それらの目標がみたされないことを示せ
るようなテストケースを作成する
 設置テスト(installability testing)
 ある種のソフトウェアシステムでは，システムを設置す
るのに複雑な手続きがいる
 信頼性テスト(reliability testing)
 信頼性についてのテストはむずかしい．
 例：Bell SystemのTSPS交換機システム⇒40年稼働中に2時間
以下の故障時間とする目的仕様
 数学的モデルを使うことで，有効性が推定できる場合もある

 回復テスト(recovery testing)
 プログラミング・エラー，ハードウェア故障，データ・エ
ラーから回復機能が正しく働かないことを示すことが目的
 ハードウェア故障などはシミュレーションをつかう
 サービス性テスト(serviceability testing)
 サービス性つまり保守能力の性質についての目的仕様があれ
ば，これらもすべてテストしなければならない．
 文書テスト(documentation testing)
 ユーザ文書で説明されている例はすべてテスト・ケースとし
てコーディングし，プログラムにあたえなければならない
 手続きテスト(procedure testing)
 システム・オペレータ，データベース管理者，端末のユーザ
による手続きなどは，システム・テスト中にテストする

システム・テストの実行
 だれがするか？
 プログラマはシステム・テストをしてはいけない
 そのプログラムの開発について責任をもつ組織は，
すべてのテスト過程において絶対にシステムテスト
をしてはいけない
 理想的なテストチーム
 少人数のプロのシステムテスト専門家
 エンドユーザの代表者
 人間的要因をあつかえる技術者
 本来の分析者や設計者

認可（受入れ）テスト
 エンドユーザの初期の仕様と現在の要求とについ
てプログラムを比較する過程
 通常，プログラムの依頼客またはエンドユーザに
よっておこなわれ，原則として開発部門の責任と
は考えられない
 契約によってつくったプログラムのばあいは，契
約先の組織がプログラムの機能ともとの契約内容
とを比較することによって，認可テストを行う

導入テスト
 導入のエラーをみつけることが目的
 導入テストは，システムを作成した組織が開発しなければ
ならない
 システムの一部として引き渡し，システムの導入後に実行
すべきもの
 テストケースの役割（以下のようなこと確かめる）：
 互換性のあるオプションが選択されているか
 システムのすべての部分が存在するか
 すべてのファイルが作成され，そのなかに必要な内容がは
いっているか
 ハードウェア構成が適当であるか

テスト計画と制御
 テスト過程を計画するときの大きな誤り
 エラーは見つからないだろうという暗黙の仮定のも
とにスケジュールをたててしまう
 ⇒計画された資源（人，期日）が低く見積もられてしまう
 テスト過程が開発サイクルの終わりに位置するため，資源
の変更は困難である
 良いテスト計画の内容
 目的，終了基準，スケジュール，責任，テストケー
スライブラリと標準，道具，コンピュータハード
ウェア構成，結合，追跡手続き，デバッグ手続き，
回帰テスト

テスト完了基準
 いつテストをやめるか？
 いま発見されたエラーが最後に残っていたエラーで
あるかどうかを知る方法はない．
 実際によくつかわれている完了基準：
 予定したテスト期間がすぎたときに停止する
 ⇒全然なにもしなかったときでもこの基準は満たされてし
まう
 すべてのテスト・ケースを実行しエラーが発見され
ないとき停止する
 ⇒テストケースの品質とは無関係のものになってしまう
 エラー発見率の低いテストケースを書こうとする誘因

より有効なテスト完了基準
 特別なテストケース設計法を基礎にした基準
 モジュールテストの場合：テストケースは，①複数
条件網羅基準を満たすことと②モジュールインタ
フェース仕様の限界値分析から得られる．そして，
そのテストケースがすべて「不成功」に終わる
 機能テストの場合：テストケースが①原因－結果グ
ラフ，②限界値分析，③エラー推測，から得られて
いて，そのテストケースがすべて最後に「不成功」
になる
 ⇒システムテストのように，特別な手法がないよう
なテスト段階では役に立たない

より有効なテスト完了基準(2)
 前もって定めた数のエラーを発見したときを基準とする
 発見すべきエラーの数をどのようにして得るか？
 このプログラムの全エラー数の推定
 そのうち何パーセントがテスト過程でみつけられそうかの推
定
 特定の設計過程で発生するエラーの割合と，このようなエ
ラーがどのテスト段階でみつけられそうなのかの推定
 ⇒産業界全体の平均値は，コーディング終了時点で100ス
テップあたり4～8個のエラー
 予測が高すぎてエラーが見つからなかったら
 テストケースが不十分なためか，テストケースはすぐれてい
るがエラーが少ないためか，を判断する

より有効なテスト完了基準(3)
 単位時間あたりに発見したエラーの数を図にプロットする
 左側のようになっていれば，エラー数が基準に達していたと
しても，機能テストを続けるべきである
 右側のようになっていたら，機能テストをやめて新しい段階
のテストをはじめるのがよい
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8
発見されたエラー
週
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8
発見されたエラー
週

独立したテスト機関の利用
 テストする組織は，できるかぎり企業の構成上，
開発部門と離すべきである
 アメリカ空軍の例：
 ソフトウェア開発のために外部の企業と契約をむす
ぶときには，テストについては別の企業と契約をむ
すぶことになっている．
 長所：
 テスト過程での動機づけの向上
 開発組織との健全な競争
 テスト過程が開発組織の管理制御から切り離される
 専門的知識が導入される

次回予定
 日にち
 ２０１１年７月２２日（金）
 時間
 １０：３０～１２：００
 場所
 ＬＢ／２ＦＡ
 内容
 デバッグ
2011/7/1522 ソフトウェア・テスト入門６

ソフトウェア・テスト入門6

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Semelhante a ソフトウェア・テスト入門6

Semelhante a ソフトウェア・テスト入門6 (20)

Mais de Kenta Hattori

Mais de Kenta Hattori (20)

Último

Último (6)

ソフトウェア・テスト入門6