Microsoft PowerPoint - VSTeP ppt [互換モード]

Size: px

Start display at page:

Download "Microsoft PowerPoint - VSTeP ppt [互換モード]"

いぶきいせき
5 years ago
Views:

1 テスト観点に基づくテスト開発方法論 VSTeP の概要 2013/4/3( 水 ) WARAI( 関西テスト勉強会 ) スペシャル電気通信大学大学院情報理工学研究科総合情報学専攻経営情報学コース西康晴 (Yasuharu.Nishi@uec.ac.jp)

2 本日のポイント理解すべきポイントテスト観点とは何かテスト開発プロセスの考え方» 特にテストアーキテクチャ設計の考え方ツリー状のテスト観点図の描き方» 詳細化と関連テスト観点のモデリング» リファインのためのモデリングパターン剪定と確定テストアーキテクチャ設計の考え方» テストコンテナ分割テストフレーム構築テストスイートの品質特性テスト詳細設計テスト実装の考え方進んだ話題» Reverse VSTeP テストのプロダクトライン今日はここまで 2

3 テスト設計には実に多くの観点が必要 : 組込みの例機能 : テスト項目のトリガソフトとしての機能» 音楽を再生する製品全体としての機能» 走るパラメータ明示的パラメータ» 入力された緯度と経度暗黙的パラメータ» ヘッドの位置メタパラメータ» ファイルの大きさファイルの内容» ファイルの構成内容信号の電気的ふるまい» チャタリングなまりプラットフォーム構成チップの種類ファミリメモリや FS の種類速度信頼性 OS やミドルウェアメディア» HDD か DVD かネットワークと状態» 種類» 何といくつつながっているか周辺機器とその状態外部環境比較的変化しない環境» 場所コースの素材比較的変化しやすい環境» 温度湿度光量電源 3

4 テスト設計には実に多くの観点が必要 : 組込みの例状態ソフトウェアの内部状態» 初期化処理中か安定動作中かハードウェアの状態» ヘッドの位置タイミング機能同士のタイミング機能とハードウェアのタイミング組み合わせ同じ機能をいくつカブせるか異なる機能を何種類組み合わせるか性能最も遅そうな条件は何か信頼性要求連続稼働時間 GUI 操作性操作パスショートカット操作が禁止される状況は何かユーザシナリオ 10 モード操作ミス初心者操作子供出荷先電源電圧気温ユーザの使い方言語規格法規障害対応性対応すべき障害の種類» 水没対応動作の種類セキュリティ扱う情報の種類や重要度守るべきセキュリティ要件非常に多くの観点を網羅的に設計する必要がある 4

5 よくある大中小項目型テスト設計の書き方大項目中項目小項目テストケース機能レベル1 機能レベル2 機能レベル3 機能レベル10 機能レベル1 機能レベル8 機能レベル9 機能レベル10 機能環境データ機能 + 環境 +データ機能データ GUI 機能 +データ+GUI 機能データ前提条件機能 +データ機能状態イベント状態 +イベントテストカテゴリ機能データ機能 +データ組み合わせ機能 1 機能 2 機能 1 機能 2 5

6 丁寧に詳細化しないと漏れが発生する大項目中項目小項目サウンド設定ボリュームテストケースボタンを 25 回押すサウンド設定ボリューム大中小項目型テスト設計の場合ボリュームとボタンを 25 回押すとの間に抽象度の差があるため列挙する際に漏れが発生しやすいボリュームの下側内部最大値が漏れる他のウィンドウでのボリューム増加が漏れる何も見ずに都道府県の名前を漏れなく思い出せますか? 地方を列挙し地方ごとに思い出すと網羅が簡単 6 ボリュームの境界値ボリュームの上側内部最大値ボリューム増加ボタンを上側内部最大値まで押すボタンを 25 回押す

7 大中小項目型テスト設計では問題が多い詳細化のレベルが揃わない偏った詳細化をしてしまうテストケース群ごとに詳細化の偏りにばらつきがある異なるテスト観点の組み合わせを詳細化だと考えてしまう機能 + 環境 + データ機能 + データ +GUI テスト設計で考慮する必要の無いものが入ってしまう機能 + データ + 前提条件異なるテスト観点にぶら下げているので網羅できない機能 + 状態 + イベント» 本来は状態遷移網羅をすべきであり機能網羅で代用すべきではないテスト観点の詳細化を行わないテストカテゴリ + 機能 + データ» 負荷にも色々あるはず... 組み合わせテストを押し込んでしまう n 元表を使うべきであるどんな観点に着目しているのかを俯瞰できない非常に多くの観点を網羅的に設計できる記法ではない 7

テスト計画やテスト戦略をどうやって立てる? テストの専門書を開いてみるといろいろなテスト設計の技法が書いてある» 境界値テスト制御パステスト状態遷移テスト... 言っていることは分かるし正しいと思うのだがどう使ってよいのやらよく分からない» 果たしてどの技法をいつ使えばよいのだろう?

8 テスト計画やテスト戦略をどうやって立てる? テストの専門書を開いてみるといろいろなテスト設計の技法が書いてある» 境界値テスト制御パステスト状態遷移テスト... 言っていることは分かるし正しいと思うのだがどう使ってよいのやらよく分からない» 果たしてどの技法をいつ使えばよいのだろう? だから適切なテスト計画やテスト戦略を立てなければいけないテストの観点はテスト計画やテスト戦略の構成要素である機能の網羅はちゃんと出来たけど動作環境が色々あるのは気づかなかった境界値テストを設計したけどそもそも同値クラスが浮かばなかった直交表を使ってテストを設計したけど因子が抜けてしまったテスト観点に着目したテスト計画やテスト戦略立案が必要 8

9 ソフトウェアテスト開発プロセスが必要であるソフトウェアの高品質化大規模化複雑化に伴いソフトウェアテストの高品質化大規模化複雑化も急務である 10 万件を超える様々な観点による質の高いテストケースをいかに体系的に開発するかが課題であるしかしテスト計画やテスト戦略立案という工程は未成熟であるテストケースという成果物の開発とテストのマネジメントとが混同されている» テスト計画書にテストケースもスケジュールも人員アサインも全て記載されるテストケースの開発という工程が見えにくくなっておりそこで必要となる様々な工程が混沌として一体的に扱われている» テスト ( ケース ) 開発という用語はほとんど使われずテスト計画テスト仕様書作成テスト実施準備といった用語が使われている» テスト戦略という用語もイマイチよく分からないそこでソフトウェアテスト開発プロセスという概念が必要となるテストケースを開発成果物と捉え開発プロセスを整備する必要がある» 高品質大規模複雑なテストケースを開発するために必要な作業を明らかにする» 本来はテスト実施以降やテスト管理のプロセスも必要だが今回は省略する ASTER/ 智美塾でエキスパートが議論している» 我々はを提案している 9

10 ソフトウェアテスト開発プロセスの基本的考え方テストケースを開発成果物と捉えソフトウェア開発プロセスとソフトウェアテスト開発プロセスを対応させようソフト要求分析ソフトアーキテクチャ設計ソフト詳細設計ソフト実装 = テスト要求分析 = テストアーキテクチャ設計 = テスト詳細設計 = テスト実装テストケースがどの工程の成果物かを考えるために各プロセスの成果物を対応させようソフト要求仕様 ( 要求モデル ) = テスト要求仕様 ( 要求モデル ) ソフトアーキテクチャモデル = テストアーキテクチャモデルソフトモジュール設計 = テストケースプログラム = 手動 / 自動化テストスクリプト ( テスト手順 ) 10

11 旧来のテストプロセスでは粗すぎるテスト設計 (or テスト計画 or テスト実施準備 ) テスト実施テスト項目の抽出テスト要求分析テストアーキテクチャ設計テスト詳細設計テスト実装テスト実施テスト要求の獲得と整理テスト要求モデリングテストアーキテクチャモデリングテスト技法の適用によるテストケースの列挙手動 / 自動化テストスクリプト ( テスト手順 ) の記述 11

12 テスト観点に基づくテスト開発方法論 :VSTeP の概要 VSTeP(Viewpoint-based Software Test Engineering Process) とはテスト観点のモデリングを核としたテスト開発方法論であるテスト観点を核にしてテストの要求からテストケーステスト手順までをシームレスに開発していく方法論である» テスト要求分析やテストアーキテクチャ設計など軽視しがちなテストの上流工程に力を入れることができ質の高いテスト設計やレビュー経験の蓄積が可能になる» ソフトウェア開発と同様にモデリングスキルを求められるがパターンや SPLE モデル駆動開発などソフトウェアエンジニアリング的な技術をテストに応用しやすい» 既存のテストをリバースエンジニアリングできるのでテストの再利用や改善もしやすい VSTeP の流れテスト要求分析テストアーキテクチャ設計テスト詳細設計テスト実装テスト実施テスト要求の獲得と整理テスト観点によるテスト要求モデリングテストコンテナ分割によるテストアーキテクチャモデリングテスト技法の適用によるテストケースの列挙手動 / 自動化テストスクリプト ( テスト手順 ) の記述 12

13 一般的なテスト要求 / アーキテクチャモデルの例一般的なテスト要求モデルテストアーキテクチャモデルの例仕様と同じ構造なのでモデルは不要» もしくは仕様書の章立てそのまま機能の一覧品質特性や非機能特性の一覧自然言語によるテストの概要記述経験的なテスト項目表の大項目の一覧テストタイプやテストカテゴリの一覧テストフェーズやテストレベルの一覧テスト詳細設計技法の一覧» もしくはテスト詳細設計モデルの一覧 ( 制御パスモデルや状態遷移モデルなど ) ホントにこれでよいのかな? 13

14 テスト要求 / アーキテクチャモデルの例 : ゆもつよメソッド HP の湯本さんが使っている手法 14

15 テスト要求 / アーキテクチャモデルの例 :HAYST 法 -FV 表 FV 表 :Function Verification Table ソフトウェアテスト HAYST 法入門より» 吉澤正孝 / 秋山浩一 / 仙石太郎, 日科技連出版社, ISBN

16 テスト要求 / アーキテクチャモデルの例 :NGT NGT: Notation for Generic Testing テスト観点をベースにモデリングする 16

17 テスト観点とは何かテストには様々な観点が必要だと言われている例 )Ostrand の 4 つのビュー» ユーザビュー仕様ビュー設計実装ビューバグビュー例 )Myers の 14 のシステムテストカテゴリ» ボリュームストレス効率ストレージ信頼性構成互換性設置回復操作性セキュリティサービス性文書手続き例 )ISO/IEC 9126(ISO/IEC 25000s) の品質特性» 機能性信頼性使用性効率性保守性移植性テスト観点とはテスト対象のテストすべき側面やテスト対象が達成すべき性質であり階層構造を持つある側面から抽象化されたテストケースと言うこともできる» 網羅すべきもの仕様機能データユーザの使い方など» 達成すべき特性» テストアイテム ( テスト対象 ) の一部機能サブシステムモジュール H/W など» バグ ( のパターン )» テストタイプや技法をヒントにすることもできる» テストレベルをヒントにすることもできる» ソフトウェア開発時に記述する図表をヒントにすることもできる具体化してテストケースにならないものは基本的にテスト観点ではない 17

18 なぜテスト観点と呼ぶのか? テスト観点という用語はロールに依存しないからである要求でしょ! テスト条件だよ SE( 要求担当 ) テストエンジニアテスト目的じゃないか? テストマネジャーテスト環境な気がするテストオペレータ 18 因子だよ因子組み合わせテスト設計者

19 Ostrand の 4 つの主なテスト観点 User-view ユーザが何をするかを考える Fault-view 起こしたいバグを考える Spec-view 仕様を考える Design-view 設計やソースコードを考える User-view White-box testng Spec-view Design-view Black-box testing Fault-view バランスが重要 19

20 テスト観点を構成要素としてモデリングを行うテスト観点のモデリングを行ってテストを開発すべきであるモデリングを行うとテストで考慮すべき観点を一覧でき俯瞰的かつビジュアルに整理できる» 10 万件を超えるテストケースなどテスト観点のモデル無しには理解できない» モデルとして図示することで大きな抜けや偏ったバランスに気づきやすくなる» 複数のテストエンジニアでレビューしたり意志を共有しやすくなるテスト要求分析ではテスト要求モデルを作成する» テスト対象ユーザの求める品質使われる世界などをモデリングする» ボトムビューポイントが特定できるまで丁寧に段階的に詳細化するテストアーキテクチャ設計ではテスト設計実装しやすいようにテスト要求モデルをリファインする» 適切なテストタイプやテストレベルそのものを設計する» 見通しのよいテストアーキテクチャを構築する» よいテスト設計のためのテストデザインパターンを蓄積し活用する VSTeP(Viewpoint-based Software Test Engineering Process) では NGT(Notation for Generic Testing) という記法でテスト観点のモデリングを行う» ツリー型の記法を用いるため Excel で表を埋めるよりもエンジニアリングっぽい 20

21 テスト要求分析テスト要求分析のインプットとなる情報を獲得しテスト開発に必要な情報を選り分けるテストマネジメントに必要な要求を選り分ける» 後でリスクとしてまとめていくシステムの完成像への要求とシステムの出来の情報を選り分ける» ピンポイントテストやリスクとしてまとめていく顧客がトップダウンに指定してきた制約 ( テストツールなど ) を選り分ける» その制約が本当に必要なのかを検討し顧客に確認するテスト要求をモデリングする顧客から獲得した要求を顧客が把握しているようにモデルとして記述する顧客の把握が不十分不完全不正確などの部分についてモデルを囲んで顧客と合意を取りながらリファインしていく» あくまで顧客の要求の理解を深めるのがテスト要求モデリングのリファインの主目的でありテストしやすくするのが目的ではないモデルは図であっても表であってもリストであっても構わない» NGT/VSTeP ではテスト観点図というツリー状の図を用いる 21

22 テスト要求分析のインプットとなる情報ソフトウェア開発で達成すべき顧客からの要求システムの完成像への要求» 例 ) 機能要求非機能要求理想的な使い方差別化要因目的機能顧客からの要求をソフトウェア開発で達成するためのテスト開発プロセスへの制約や ( 他から与えられた ) 方針テストプロジェクトへの要求» 例 ) コスト納期人数スキルや経験 ( 顧客から適用を要求された ) テスト手段» 例 ) テスト技法シミュレータテスト環境など顧客からの要求を達成するための前提テスト対象の情報» テスト対象の実現手段例 ) テスト対象のアーキテクチャバグが多そうなところの知識» テスト対象の出来例 ) システムの不安な点弱点バグの多い点過去の類似製品のバグの知識上流のプロジェクトの様子» 例 ) 進捗状況人の入れ替わり 22

23 テスト要求モデリング : 観点の列挙詳細化体系化まず大まかなテスト観点を列挙し階層的に詳細化していく動作環境プラットフォーム OS テスト観点を階層的に詳細化していく» 最も詳細化されたテスト観点はテスト設計で同値クラスになる» 詳細化の作業は近くからモノを見る ( ズームイン ) ようなものである» テスト観点がMECEになっているかや異なるステレオタイプの関係が混ざっていないかどうかに気をつける階層の最上位のテスト観点をビューと呼ぶ» 最上位のテスト観点に代表されるため階層全体をビューと呼ぶこともできる» どのようなビューがどのような関連でモデリングされるかはテストエンジニアによってかなり異なる階層の最下位のテスト観点をボトムビューポイントと呼ぶ» そのテスト観点を見れば何をどのように網羅すればよいかが一目で分かる詳細度がボトムビューポイントである» ボトムビューポイントはテスト詳細設計でのテスト条件となる 23

24 テスト要求モデル作成の 2 つの主なアプローチトップダウン型おもむろにテスト観点を挙げ詳細化していく» 三角形のテストには三角形の構造に関する観点が必要だ» 三角形の構造には成立直線不成立の3つがあるな» 成立する場合には正三角形二等辺三角形不等辺三角形があるな三角形三角形三角形成立直線不成立成立直線不成立正三角形二等辺三角形不等辺三角形 24

25 テスト要求モデル作成の 2 つの主なアプローチボトムアップ型まず思いつくところからテストケースを具体的に書きいくつか集まったところで抽象化しテスト観点を導き出していく» (1,1,1) なんてテストどうかな» (2,2,2) とか (3,3,3) もあるな» これって要するに正三角形だな» 他に似たようなのあるかなう~ん二等辺三角形とかかな三角形の種類正三角形正三角形二等辺三角形不等辺三角形 (1,1,1) (1,1,1) (2,2,2) (3,3,3) (1,1,1) (2,2,2) (3,3,3) 25

26 テスト要求モデリング : テスト観点間の関係テスト観点は 2 つの基本的な関係を持つ詳細化 (Hierarchy relationships)» テスト観点を階層的に詳細化してテスト条件を導き出し直線の矢印で表す» 継承合成集約 ( 部分 ) 属性化原因 - 結果など詳細化すべき理由をステレオタイプで表すこともできる関連 (Interaction relationships)» 組み合わせてテストすることが必要なテスト観点を示し曲線で表す» 組み合わせるべき理由をステレオタイプで表すこともできる関係の種類を << ステレオタイプ >> を用いて表すと分かりやすい OS << 継承 >> OS のバージョン詳細化 << 部分 >> Internet Explorer 関連 26

27 テスト要求モデリング : 関連の検討複数の観点を組み合わせるテストを関連で示す例 ) 負荷テストでは搭載メモリ量という観点と投入データ量という観点を組み合わせてテスト設計を行う» 搭載メモリ量と投入データ量のバランスによってテスト対象のふるまいが変化するからである観点同士の依存関係を関連と呼ぶ» テスト観点間の矢頭の無い曲線で記す» 関連そのものを観点のように名前を付けて扱った方がよい場合もある» 関連には条件 - 条件組み合わせ (<<combination>>) や条件 - 振る舞い組み合わせ (<<frame>>) がある 27

28 テスト要求モデリング : モデルのリファイン質の高いモデルにするために様々なリファインを行う詳細化整理剪定確定» 段階的かつ MECE に詳細化されていない場合テスト観点の追加削除などを行ったり詳細化のステレオタイプを明示して整理する ( ステレオタイプ分析 )» 読む人によって意味の異なるテスト観点を特定し名前を変更する» テスト観点や関連の移動分割統合名前の変更パターンの適用観点と関連との変換観点と網羅基準との変換などを行う» 本当にその関連が必要なのかどうかの精査を行う必要もある» テスト項目数とリスクとのトレードオフを大まかに行いズームインアウト削除網羅基準や組み合わせ基準の緩和などを行う» 間引いたテスト項目の品質リスクを明らかにしテスト設計全体の品質リスクを把握する 28

29 関連の整理のモデリングパターンの例 : 親観点統合観点 A 観点 B 観点 C 観点 A 観点 D 観点 B 観点 C 29

30 テスト観点と関連の剪定 : 項目数とリスクのトレードオフテスト観点を詳細化しながら品質保証手段 ( 網羅基準 ) とテスト項目数と品質リスクのバランスを取るモデリングが進んできたら品質保証手段 ( 網羅基準 ) とテスト項目数と品質リスクを記述して概算する» モデリングの進み具合に応じてどちらかだけでもよいテスト項目数を概算しやすいようにテスト観点のメンバを記述してもよい親テスト観点のテスト項目数は継承した子テスト観点のテスト項目数を足し合わせる親テスト観点の品質リスクは継承した子テスト観点の品質リスクの高い方を採るテスト要求分析で行うこともテストアーキテクチャ設計で行うこともある» もちろん両方で行ってもよい 30 観点名テスト項目数品質リスク品質保証手段 ( 網羅基準 )

31 テスト観点と関連の剪定 : ズームインズームアウト 3 つの方法でテスト項目数とリスクとのトレードオフ ( 剪定 ) を行いながら計画されたテスト工数に合わせこんでいくテスト観点内の網羅基準の緩和ズームアウト関連の組み合わせ基準の緩和削除 31

32 テスト観点と関連の剪定 : ズームインズームアウト剪定の際にはテスト観点と同じ書式で関連のテスト項目数品質リスク品質保証手段 ( 網羅基準 ) を記述する項目数やリスクを考える段階ではテスト観点のように各関連に品質リスクやテスト項目数を記述していく ( 関連ビューポイント ) 32

33 確定によるテスト漏れリスクの軽減剪定には潜在するテスト漏れのリスクが付随してしまう同値分割がきちんと行われていない ( ズームアウトされた ) テスト観点網羅基準が緩いテスト観点や関連削除したり組み合わせ網羅基準を緩めた関連潜在するテスト漏れのリスクを軽減する作業を確定と呼ぶそのテスト観点や関連でテスト漏れが発生しないと言い切れる場合確定する» 特異点も存在せず実行コードまで同値性を確認した同値クラスなどは確定できる» 品質リスクが高いものを暫定テスト観点十分低いものを確定テスト観点と呼ぶ» 子テスト観点と関連が全て確定できたら親テスト観点も確定できる確定によってテスト設計全体の品質リスクを評価する» 全てのテスト観点を確定させることが目的なのではなく品質リスクの高いテスト観点を明示し他の工程で策を講じやすくすることが目的である 33

34 テストアーキテクチャ設計テストアーキテクチャ設計とはテストの全体像をテストタイプやテストレベルで表すとともにテストタイプやテストレベルそのものを ( テスト観点を用いて ) 適切に設計することである 34

35 テストアーキテクチャ設計テスト要求モデリングで得られたモデルをテスト詳細設計実装実行しやすいようにリファインするテストコンテナ分割 : テスト観点群をまとめてテストスイート全体を俯瞰する» テストケース群全体のことをテストスイートと呼ぶ» 複数のテスト観点をテストコンテナ ( テストタイプやテストレベルテストサイクル ) にまとめるすなわちテストスイート全体をテストコンテナに分割することで俯瞰性を高める» 現場では経験的に様々なテストタイプやテストレベルに分割しているが妥当な分割をしているかどうかは分からないテストフレーム構築 : テストコンテナをテストケースの構造に合わせる» テスト観点が多すぎるとテスト条件などが増えてテスト詳細設計が難しくなる» 各テストコンテナがテストケースを詳細設計するのに必要な種類の観点を含むすなわちテストコンテナをテストフレーム ( テストケースの構造 ) に合わせる必要がある剪定と確定も引き続き行う 35

36 テストコンテナ分割テスト要求モデリングで得られたテスト観点モデルをより小さなテストコンテナに分割するテスト観点をまとめたものがテストコンテナであるテストコンテナがテストタイプやテストレベルになる GUI テスト 36 構成テスト

37 テストコンテナ分割テストコンテナ : テストタイプやテストレベルのように複数のテスト観点やテストケースがまとまった塊のことテストタイプ : 負荷テスト構成テスト性能テストなどテストレベル : 単体テスト結合テストシステムテストなどテストコンテナを用いてテストアーキテクチャを表すテストコンテナを用いるとテストアーキテクチャを俯瞰できる» テスト全体をテストタイプやテストレベルの一覧で表すのはよく行われる» 分割しすぎると俯瞰性が低下し分かりにくくなるテストコンテナに含まれるテスト観点を比べるとテストコンテナ間の役割分担を明確に把握できる» 負荷テストと性能テストなど違いがよく分からないテストタイプも区別できる» 単体テストと結合テストなど役割分担がよく分からないテストレベルも区別できるテストコンテナの意味合いを把握できるように分割する必要がある» テストコンテナ間の関連が小さいように分割する ( 結合度を下げる )» テストコンテナの表している意味が明確になるように分割する ( 凝集度を高める ) テストスイート ( テストケース群 ) に求められる性質によって異なるテストアーキテクチャを設計する必要がある» 高い保守性が必要自動化しやすいなど 37

38 コンテナ U コンテナ分割のモデリングパターンの例 : クラスタ分割観点 H 観点 I 観点 J 観点 K 観点 L 観点 M コンテナ V コンテナ W 観点 H 観点 I 観点 J 観点 K 観点 L 観点 M 観点 I 観点 L 38 コンテナ X

39 コンテナ分割のモデリングパターンの例 : 子観点分割コンテナ R 観点 E(5 項目 ) 観点 F(6 項目 ) 観点 G(4 項目 ) 30 項目 24 項目計 :69 項目コンテナ S 観点 E(5 項目 ) 観点 F(6 項目 ) F1(3 項目 ) F2(3 項目 ) コンテナ T 観点 G(4 項目 ) 15 項目 12 項目 39 計 :42 項目

40 テストアーキテクチャ設計のリファインの例いくつかのモデリングパターンを用いてリファインを行った左右の図は両者とも準ミッションクリティカルシステムのソフトウェアである左図のテストアーキテクチャをリファインして右図のテストアーキテクチャにした右図のテストアーキテクチャはテスト詳細設計しやすくなっていると感じられるリファイン 40

41 テストスイートの品質特性テストスイートにも品質特性が考えられるアーキテクチャを検討するほど大規模で複雑なテストスイートにはテストスイート自身の品質特性を考慮しなければならないしかしテストスイートの品質特性についてはほとんど議論されていないソフトウェアの品質特性は十分議論されている» ISO/IEC9126sの品質特性 : 機能性信頼性使用性効率性保守性移植性など» ソフトウェアの品質特性はテストスイートの品質特性と同じではないが参考程度にはできるかもしれないテストスイートの品質特性の違いによって異なるテストアーキテクチャを設計する必要が生じる保守性派生容易性自動化容易性網羅保証性ピンポイント性などがあるかもしれない 41

42 テストスイートに求められる品質特性によって異なるテストアーキテクチャの例テスト要求分析モデル単純に分割国際化重視保守性重視 42

43 テストフレーム構築テスト観点を十分に詳細化していてもテスト観点によってはそのままテスト詳細設計に移行できない場合があるこの条件のテストはテスト対象のどの部分に行うんだろう? この部分に対するテストではどの品質特性を確認するんだろう? この品質特性をテストするにはどの操作を行えばいいんだろう? テスト詳細設計が容易になるようテストコンテナにテストケース構造 ( テストフレーム ) を反映させるテストフレームとはテストケース構造に合わせたテスト観点の組み合わせであるテストフレームの例» テスト条件 + テスト対象» テスト条件 + 振る舞い» テスト条件 + テスト対象 + 振る舞い» テスト条件 + 狙っているバグ» テスト条件 + テスト対象 + 振る舞い + 狙っているバグテストコンテナ内のテスト観点にテスト条件系観点テスト対象系観点振る舞い系観点バグ系観点などが含まれているようにする» 1 つのテストコンテナに複数のフレームが含まれることもある» テスト詳細設計やテスト実装で自明に分かる場合はテストフレームを組まなくてもよい 43

44 テスト詳細設計テスト実装テスト観点をボトムビューポイントまで詳細化しテストフレームを組んだらテスト詳細設計を行っていくボトムビューポイントに対応するテスト詳細設計モデルを定め網羅アルゴリズムと網羅基準にしたがってテストケースを生成していく» 例 ) 状態モデルに対して C0 の遷移網羅基準で深さ優先探索法を用いて生成する» この 3 者が明確であればモデルベースドテストとしてテストケース生成を自動化できる可能性が高いテストケースに対応するテスト観点を常に明確にすることができる» 目的のよく分からない漫然と設計されるテストケースを撲滅できるテストケースが生成できたらテスト実装を行っていくテスト対象のシステムやソフトウェアの仕様テストツールなどに合わせてテストケースをテストスクリプトに具体化していく» 手動テストスクリプトの場合もあるし自動化テストスクリプトの場合もある複数のテストケースを 1 つのテストスクリプトに集約して効率化を行う» 同じ事前条件やテスト条件テストトリガのテストケースを集約していく 44

45 Reverse VSTeP によるテストの改善 Reverse VSTeP: テスト設計をリバースモデリングする手法既存の ( 十分設計されていない ) テストケース群からテスト観点を読み取って VSTeP のテスト観点モデルをリバースモデリングして改善する手法群テスト観点モデルのリバースモデリングによる改善実際のテストケースを分析してどういうテスト観点や関連でテストしようとしているかを列挙整理し改善する実際に見逃したバグや検出されたバグテストケース外で検出されたバグを分析してどういうテスト観点や関連が足りなかったかを列挙整理し改善する» テスト観点を網羅したつもりでも解釈が曖昧だったり不適切な場合や剪定に失敗してしまった場合もあるカバレッジ分析による改善見逃したバグや検出できたバグ実際のテストケースなどを分析してテスト観点は特定できているのにカバレッジ基準達成率が低すぎた場合や特異点が存在してしまった場合不適切なリスク値 ( 工数不足 ) の場合といった原因を明らかにしカバレッジ基準目標率不足した誤った前提リスク値判定基準などを改善したりテスト観点や関連を改善する» 仕様で示された同値クラスが必ずしも設計実装上の同値クラスと一致するとは限らないためテスト設計時の前提が重要となる» 関連よりもテスト観点として取り扱う方がよい場合もある 45

46 Reverse VSTeP によるテストの改善ステレオタイプ分析による改善テスト観点モデルの各詳細化関係の種類や MECE 性を分析しテスト観点が適切かつ網羅的に詳細化されるように子テスト観点を追加したりモデルをリファクタリングして改善する不具合モード分析による改善見逃したバグや検出されたバグをパターン化してピンポイント型のテスト観点を追加整理し改善するディレイ分析によるテストアーキテクチャの改善見逃したバグや検出されたバグを分析して実際のテストレベルやテストタイプをリバースされたテスト観点モデルにマッピングしテストアーキテクチャ設計 ( テストレベルの設計 ) をレビューし改善する傾向分析によるリスク値の改善見逃したバグや検出されたバグを分析して各テスト観点のリスク値 ( 利用頻度致命度欠陥混入確率など ) を改善する 46

47 テスト観点をリバースすると技術力も分かってしまうテスト観点をリバースするとテスト設計者の意図が透けて見えてしまうので技術力が分かってしまう仕様境界様々な負荷のかけ方が漏れる性能負荷境界性能仕様負荷境界技術力が必要負荷に弱い設計様々な状況で測るべき性能が漏れる 47

48 モデリングしないとテストケースを効率的に再利用できない大項目中項目小項目サウンド設定ボリュームテストケースボタンを 25 回押すボリュームアップボタンを 25 回押すというテストケースを効率的に再利用できるだろうか? 次の製品では以下の仕様変更が起こる可能性がある» ボリューム調整の UI の変更» ボリューム調整の手段の増加» ボリューム範囲の変更» デフォルトのボリューム値の変更 25 回の意味が記述されていないので意味不明のままテストケースを再利用する羽目になる» 仕様変更に追従できずテストケースを再設計せざるを得ない» 仕様変更に追従できず新たに増えた仕様のテストが漏れてしまう» テストケースが本来の狙いを果たさなくなるためバグを検出できない» 意味不明のテストケースが増えていき保守 ( 削除 ) できなくなってしまう 48

49 モデリングによってテストのプロダクトラインを目指すサウンド設定 VP ボリュームボリュームボリュームの最大値ボリュームの上側内部最大値ボリューム増加ボタンを上側内部最大値まで押すボタンを 25 回押す V ハードボタンテストモデルにテスト設計意図やテスト設計理由を入れ込むことでテストケースを再利用しやすくなる上流のモデルにテストのモデルを対応させておくとそもそも再利用しやすいテストを設計しておくことができる上流からテストをモデリングするとテスト容易性を考慮するようになり分析や設計がスッキリしていく 49 V GUI ボタン V GUI スライダ

50 まずは使ってみて下さいな電気通信大学西康晴

Microsoft PowerPoint - VSTeP ppt [互換モード]

Microsoft PowerPoint - VSTeP ppt [互換モード] テスト観点に基づくテスト開発方法論 VSTeP の概要 2013/5/10( 金 ) 電気通信大学大学院情報理工学研究科総合情報学専攻経営情報学コース西康晴 (Yasuharu.Nishi@uec.ac.jp) 自己紹介身分ソフトウェア工学の研究者» 電気通信大学大学院情報理工学研究科総合情報学専攻経営情報学コース» ちょっと生臭い研究 / ソフトウェアテストやプロセス改善など先日までソフトウェアのよろず品質コンサルタント