テスト観点に着目したテスト開発プロセス(VSTeP)の概要

テストの開発方法論を生み出さなくてはならない• テストの専門書を開いてみると– いろいろなテスト設計の技術が書いてある» 境界値テスト、制御パステスト、状態遷移テスト．．．。

– 言っていることは分かるし、正しいと思うのだが、どう使ってよいのやら、よく分からない» 果たして、どの技法をいつ使えばよいのだろう？

• 腕の良いテストエンジニアは、テスト設計の「前に」いろいろと考えているようだ– テスト分析&アーキテクチャ設計、もしくはテスト戦略立案を行っている» お客様はどんな要求を持っているんだろう、このソフトは何を変えられるんだろう、仕様や設計のどの辺にバグがありそうなんだろう» テストの全体像をどうしようか» テスト戦略立案の重要性は強調されているが、具体的な方法論は無い

ソフトウェアテストシンポジウム2009東京
クロージングパネル
2009/1/29（木）電気通信大学 電気通信学部 システム工学科
西 康晴– （テスト実施、）テスト設計からテスト開発へとテストのパラダイムを進化させ、テスト開発方法論を生み出さなくてはならない» テスト実施 → （開発に例えると）いきなりプログラムを書く» テスト設計 → フローチャートやモジュール構造図を書く» テスト開発 → 分析・設計・実装といったライフサイクルに従って「開発」する© NISHI, Yasuharu

テストの「観点」

2© NISHI, Yasuharu

テスト観点図の例：ツリー風の記法• テストには、様々な「観点」が必要だと言われている

電子メール– Ostrandの4つのビュー» ユーザビュー、仕様ビュー、設計・実装ビュー、バグビュー– Myersの14のシステムテスト・カテゴリ» ボリューム、ストレス、効率、ストレージ、信頼性、構成、互換性、設置、回復、操作性、セキュリティ、サービス性、文書、手続き– ISO/IEC 9126の品質特性

GUI

機能

動作環境

データ

» 機能性、信頼性、使用性、効率性、保守性、移植性• テストにおいて重要なのは、全体像を把握しながら、テスト観点を漏れなくムラなく列挙し、きちんと詳細化することである

プラットフォーム

– テスト観点には、お客様の求める品質、テスト対象の変化可能点、テスト対象の弱点などがある– テスト観点は階層構造を持ち、テスト観点同士に関連がある場合がある– 列挙されたテスト観点を用いると、テストの全体像を表すことができるOS

ネットワークハードウェア

ヘッダ
文字コード

本文

ボタン

GUI

データ

添付ファイル

OSの種類

OSのバージョン

メニュー
ショートカットキー

電子メール

IEのバージョン

メール送受信系機能
プラットフォーム
ネットワークメール編集系機能

動作環境

機能

メール管理系機能
アドレス 帳管理系機能

テスト観点を軸にして開発方法論を構築していく
3

マインドマップでも本質的に同じ
4© NISHI, Yasuharu

テスト開発ライフサイクルと VSTeP の範囲© NISHI, Yasuharu

テスト観点に着目したテスト開発プロセス(VSTeP)の概要
VSTeP: Viewpoint-based Software Test Process

テスト設計

テスト実施

• テスト分析フェーズ– テスト観点（ビュー）を列挙・整理・検討・詳細化・体系化する

テスト項目の抽出

テスト
分析

テスト
アーキテクチャ
設計

テスト
詳細設計

テスト
実装

観点の列挙
・整理・検討テスト
アーキテクチャの検討

テスト観点の詳細化・剪定・確定・テスト技術適用

テスト項目の組み合わせと集約・詳細化

テスト実施» 詳細化したビューを「フォーカス・クラス」と呼ぶ– ビュー（フォーカス・クラス）間の関連を検討する• テスト詳細設計フェーズ– 既存の技術でテスト設計を行う» ユースケーステスト、状態遷移テストなど様々な技法がある• テスト実装フェーズ– テスト項目の集約を行う» 組み合わせテストの基になる» 異なるテスト技法から得られた同じ価値のテストケースをまとめる• テストアーキテクチャ
設計フェーズ– テスト項目の組み合わせを行う– テストを設計しやすいように、ビュー全体を整理し分割する» All-pair法や直交配列表などを用いる– テスト項目の詳細な記述を行う• フォーカス・クラス
設計フェーズVSTePの範囲» テストオペレータが実行可能な記述まで詳細化する» 自動実行ツール用スクリプトを作成する– 詳細化 / 剪定 / 確定
5

© NISHI, Yasuharu

6© NISHI, Yasuharu

テスト観点（フォーカス・クラス）の列挙と詳細化• まず大まかなテスト観点を列挙し、階層的に詳細化（ズームイン）していく– 各レイヤーの観点を「フォーカス・クラス」と呼ぶ» 一番下のフォーカス・クラスは、同値クラスのようなものになる– フォーカス・クラスは階層構造を持つ

テスト観点間の関連の検討

クラス名• テストでは、複数の観点を組み合わせる必要がある

網羅基準とテスト項目数– 例）負荷テストでは、搭載メモリ量という観点と、投入データ量という観点を組み合わせてテスト設計を行う» 搭載メモリ量と投入データ量のバランスによって、テスト対象のふるまいが変化するからである

クラスメンバ» 詳細化には、継承、合成集約、属性化、因果関係などがある» MECE分析、詳細化タイプ分析により漏れを防ぐ» 多段階の詳細化によって再利用しやすい設計となる– すなわち、観点同士は依存関係を持つ場合がある» フォーカス・クラス間の「関連」として表現する– 階層の最上位のフォーカス・クラスを「ビュー」と呼ぶ» 矢頭の無い線で記す» 最上位のフォーカス・クラスに代表されるため、階層全体をビューと呼ぶこともできる– 詳細化しながら網羅基準を定めテスト項目数を概算する» 網羅基準とテスト項目数を記述して概算する» 下位のフォーカス・クラスのテスト項目数から上位のテスト項目数を算出する» 比較的詳細な見積もりと考えることもできる
78© NISHI, Yasuharu

テストアーキテクチャの設計© NISHI, Yasuharu

フォーカス・クラスと関連の剪定• 可能な条件を全て同時にテスト設計時に考慮するのは煩雑であり現実的でない• 3つの方法でテスト項目数とリスクとのトレードオフ（剪定）を行いながら、計画されたテスト工数に合わせこんでいく– テスト設計しやすいまとまりや、重視するテスト観点のまとまりにテスト観点群を分割する必要がある– 例）カテゴリ型テストアーキテクチャ– クラス内の網羅基準の緩和– ズームアウト– 関連の組み合わせ基準の緩和・削除» 関連の少ないフォーカス・クラスのグループをテストカテゴリとしてまとめ分割していく

GUIテスト構成テスト
9© NISHI, Yasuharu

VSTePの効果「確定」によるテスト漏れリスクの軽減• 剪定には、潜在するテスト漏れのリスクが付随してしまう– 同値分割がきちんと行われていない（ズームアウトされた）フォーカス・クラス– 網羅基準が緩いフォーカス・クラス– 削除したり組み合わせ網羅基準を緩めた関連• 潜在するテスト漏れのリスクを軽減する作業を「確定」と呼ぶ– 「確定」によって、各フォーカス・クラスやテスト設計全体のリスクを評価する» ソフトウェア設計のレビューや発生頻度の予想など• 質の高いテスト開発–––––• テスト漏れの原因の例

テストのモデリングの質の向上
説明責任の確保
テストモデルのレビューの促進
テクニカルコミュニケーションの容易化
テストデザインパターンの抽出・再利用• テスト開発の改善– リスクの小さい確定フォーカス・クラスと、リスクの大きい暫定フォーカス・クラスを区別して記す– テスト漏れの原因追及と改善– テストケースのリバースエンジニアリングによる十分性評価» 子クラスが全て確定できたら、親クラスも確定できる
OSの種類• 上流の改善

継承:2
Win95系:1, WinNT系:1

確定

1110

© NISHI, Yasuharu

Win95系

WinNT系

最新:WinMe:1

最新:WinXP:1

Win95, Win98, WinMe

WinNT, Win2K, WinXP© NISHI, Yasuharu– テストとの一体化によるレビューの強化– バグの作り込まれやすい箇所の反映– Wモデルによる開発の見通しの向上と上流の分析・設計の質の向上
12– テストのモデリングの失敗» ビューのモレ／関連のモレ» 不適切／曖昧なビューの解釈– 剪定の失敗» クラス内の網羅基準の過度の緩和» 過度のズームアウト» 過度の組み合わせ基準の緩和・削除– 確定の失敗» ソフトウェア設計の内部まで突っ込んで確定しなかった» ソフトウェア設計を基に確定したのに、設計どおり実装されていなかった» 利用頻度の見積もりを誤った– それ以外の失敗» 不具合が作り込まれる原因にさかのぼって分析しパターン化する© NISHI, Yasuharu