テストスイートアーキテクチャへのアーキテクチャ検証手法ATAMの 適用

テストスイートアーキテクチャへのアーキテクチャ検証手法ATAMの 適用

Transcript

1. スマートエスイー修了制作成果物 テストスイートアーキテクチャへの アーキテクチャ検証手法ATAM の 適用 番号 sse02-27 名前 大段 智広 1
2. スマートエスイー修了制作成果物 目次 • 背景 ・ ・ ・・・・・・・・・・ 3 • 課題 ・ ・ ・・・・・・・・・・ 5 • 仮説 ・ ・ ・・・・・・・・・・ 6 • 解決手法 ・ ・ ・・・・・・・・・・10 • モデル化 ・ ・ ・・・・・・・・・・12 • 評価 ・ ・ ・・・・・・・・・・13 • 考察 ・ ・ ・・・・・・・・・・16 • 結論 ・ ・・・・・・・・・・ ・17 • 今後の課題 ・ ・・・・・・・・・・ ・18 • APPENDIX ・ ・・・・・・・・・・ ・20 sse02-27 大段 智広 2
3. スマートエスイー修了制作成果物 背景 • ASTERテスト設計コンテスト • 与えられた製品の機能仕様書やユースケース仕様書などのテスト ベースから、テスト設計における成果物を提示し、その成果をプレ ゼンテーションし、競い合う • 目的 • ソフトウェアテストを分析設計から行うことを周知し、ソフトウェ アテストエンジニアに対する教育の機会を提供する • コンテストという形式をとることにより、ソフトウェアテストが創 造的な作業であり、楽しいということを経験してもらい、若年層及 び初級テストエンジニアからベテランテストエンジニアまでテスト への興味を高める • ソフトウェアテスト業界における技術開発を競技を通じ、促進する sse02-27 大段 智広 3
4. スマートエスイー修了制作成果物 背景 • テストアーキテクチャとは • テストアーキテクチャは主に2種類あるとされています。 • テストスイートアーキテクチャ • 主にテストレベルやテストタイプなどのテストケースのグループで 構成されているもの。テストスイートは、特定のテストサイクルで 実行されるテストケースやテスト手順のセット。 • テストシステムアーキテクチャ • テストシステム、テスト対象のシステム/ソフトウェア（SUT）、 SUTが実行されるプラットフォーム、テストケースのジェネレー ターなどで構成されているもの。 sse02-27 大段 智広 4 テスト アーキテクチャ テストスイート アーキテクチャ テストシステム アーキテクチャ テスト環境対象 テスト仕様対象 コンテスト 対象
5. スマートエスイー修了制作成果物 課題 • コンテスト審査員の審査コメントのばらつき • 審査員A：テストすべきことが考慮されていない。 • 審査員B：クリティカルバグの検出という限定的なテスト設計の範囲 では、よくまとまっています。 • コンテスト参加者の困惑 • テストアーキテクチャ構築の際に、より良い洗練のために気付きを 得たい。 sse02-27 大段 智広 5 テストアーキテクチャ設計の 適切なフィードバックを行うための手法を構築したい
6. スマートエスイー修了制作成果物 仮説 • アーキテクチャと品質要求とのトレードオフ関係を 分析するための手法である“ATAM”をテストスイー トアーキテクチャに適用し、ATAMの適用可能性を 評価する。 • 目論見 1. 統一的な手法を提示し、審査者同士の評価のばらつきを抑える 2. 適切な気づき(フィードバック)を得る a. アーキテクチャ上のリスクを発見する b. センシティビティーポイントを発見する c. 設計手法間のトレードオフポイントを発見する sse02-27 大段 智広 6
7. スマートエスイー修了制作成果物 仮説: （例）センシティビティーポイント を発見する 7 凡例) Next test Import test case アーキテクチャ的手法 • A1: インテークテストを追加する センシティビティーポイント • SE2: 品質が想定以上に悪い場合、無駄なテストを実施させないようにで きる A1
8. スマートエスイー修了制作成果物 仮説: （例）リスクを発見する 8 アーキテクチャ的手法 • A1: インテークテストを追加する リスク • R1: インテークテストに合格しない場合、その他のテストを実行されず、 埋め込まれた欠陥を見つける時間が+1回サイクル分遅れる可能性がある 凡例) Next test Import test case A1 R1 【気づき】 インテークテストと回帰テストのテストケースを分けずに実施 すべきではないか。 STOP R1 R1
9. スマートエスイー修了制作成果物 A1: インテークテストを追加する 仮説: （例）トレードオフポイントを発見 する 9 A2: 回帰テストを追加する 凡例) Next test Import test case 時間効率 故障の影響度 テスト有効性 アーキテクチャ的手法 A1 効率 A2
10. スマートエスイー修了制作成果物 解決手法:評価プロセス全体像 sse02-27 大段 智広 10
11. スマートエスイー修了制作成果物 解決手法:Architecture Trade-off Analysis Method(ATAM) • CMU/SEIが提唱するアーキテクチャ設計手法 • 設計計上の判断/選択/決定が品質要求を⼗分に扱うかを評価 • 品質特性を予測する試みではない • ⽐較的軽量: 通常3⽇程度で実施 • 事例多数: ⽶ボーイング, 国内システム [⽯⽥06],Netflix[Toth] • 特徴 •リスクの発見 • 品質特性について将来問題を⽣じる可能性のある選択肢 •センシティビティーポイントの発見: • 僅かな変化が品質特性に有意な差をもたらす選択肢 •トレードオフの発見: • 複数の品質特性に影響する決定 11 sse02-27 大段 智広
12. スマートエスイー修了制作成果物 モデル化 • テスト対象 • スマートエスイーの共通例題とした • SSEで学んだ対象物のテスト設計を行うことでIoTシステムにおけるテストスイー トアークテクチャに対する新たな知見を得たい • コンテストが提示するテスト開発プロセス（要求分析→アーキ設計）に沿ってテ ストスイートアークテクチャを作成した • 評価プロセス、手法 • 実際のコンテストで利用されるプロセスや評価観点に合わせるようにプ ロセスと記述方法を定義した • シナリオ評価 • 汎用的なやり方として例示するため、テスト仕様品質の品質特性を参照 し、シナリオを作成した sse02-27 大段 智広 12 テスト対象 評価プロセス、手法 コンテスト 評価観点 ATAM ユーティリティツリー シナリオ評価 Test Specification Quality model [Schiefedecter 2007]
13. スマートエスイー修了制作成果物 評価:適用の流れ 1. 審査員のFBとの対応がとれるテストアーキテク チャに関連する評価観点を抽出する 2. 過去のコンテストにおけるアーキテクチャ的手法 を抽出する 3. テスト対象に対し、サンプルとなるテストスイー トアーキテクチャ案を設計する 4. アーキテクチャ的手法のリスク、センシティビ ティポイント、トレードオフポイントを評価、考 察する sse02-27 大段 智広 13
14. スマートエスイー修了制作成果物 評価:ATAMの適用 ATAM利点の評価 考慮すべき点 • アーキテクチャ的手法と適用のノウハウが必要 • テストスイート構築のための手法と適用ノウハウ • テストスイート品質モデル、シナリオ定義が必要 • 一般的な事例は存在しないため、独自の定義が必要 • 1つのシナリオに関して発見できないことがあった sse02-27 大段 智広 14 No. 評価項目 結果 補足 1 審査者同士の評価のばらつき を抑える - 個人での適用可能性評価のため 対象外とした 2 リスクを発見する 〇 4件 3 センシティビティーポイント を発見する 〇 10件 4 トレードオフポイントを発見 する △ 1件 凡例) 〇：効果あり ×：効果なし △：限定的 - ：対象外
15. スマートエスイー修了制作成果物 評価:コンテストへの適用 • 利点 • 参加者、審査員:評価コストが軽量であるため適用しやすい • 審査員:コンテスト参加者が提示したビジネスドライバから、 設計が妥当かを審査するため評価しやすい • 欠点 • 参加者、審査員:実際のステークホルダーがいないため、ビジ ネスドライバを明確にしにくい(いままと同じような想定が必 要) • 審査員:評価対象がアーキテクチャ以外も含まれるので評価方 法の統一が一部分に留まる sse02-27 大段 智広 15
16. スマートエスイー修了制作成果物 考察 sse02-27 大段 智広 16 No. 目論見 内容 1 統一的な手法を提示し、審 査者同士の評価のばらつき を抑える (検討外) 2-a アーキテクチャ上の リスクを発見する • 発見には、事前にリスクのパターンを想定できるスキルや ノウハウがある必要がある • テスト要求分析が不⼗分な状態では詳細なものは発見しに くいが発見できないことで、設計が不⼗分であることがわ かる。 2-b センシティビティー ポイントを発見する • 発見には、事前にセンシティビティーポイントのパターン を想定できるスキルやノウハウがある必要がある • テスト要求分析が不⼗分な状態では詳細なものは発見しに くい、設計が不⼗分であることがわかる。 3-c 設計手法間の トレードオフポイントを発 見する • テストスイートアーキテクチャ適用だけでは、テスト時間 効率や資源効率のようなテスト環境に起因する品質特性は 評価しにくい。 • テストシステムアーキテクチャと合わせた多面的な評価が 必要。 例) • テストが有効か VS 効率が良いか • テスト仕様数 VS テストの実行速度
17. スマートエスイー修了制作成果物 結論 • 個人の適用性評価では有用性あり • アーキテクチャ的手法に対して気づきが得られた • しかし、アーキテクチャ的手法の抽出には洗練が必要 • 今回抽出したものは複数セットで考えることでリスクやセンシ ティビティポイントなどを発見することが多かった。 • 適用目的と利用パターンの整理→可視化・蓄積が必要 sse02-27 大段 智広 17
18. スマートエスイー修了制作成果物 今後の課題 1. コンテスト審査員を対象とした評価 • 統一的な手法を提示することで、審査者同士の評価のば らつきを抑えられるか • 今回は個人での適用可能性評価のため 2. テストアーキテクトノウハウの可視化と蓄積 • テストスイート/システムアーキテクチャ構築手法およびノウハウ • テスト対象のドメイン特性に合わせたテストアーキテクチャ 3. スマートクラウド・IoTシステムのテストアーキテクチャに 対する適用評価 • 対象システム・ドメイン非依存の手法である • スマートクラウド・IoTシステムにも適用可能の見込み sse02-27 大段 智広 18
19. スマートエスイー修了制作成果物 以上で発表は終わります。 ご審査のほど、よろしくお願いいたします。 19
20. スマートエスイー修了制作成果物 APPENDIX 成果物 コンテストにおける審査員の審査方法 参照資料 20
21. スマートエスイー修了制作成果物 成果物 • 前提条件など • 開発対象のアプリケーション • （スマホ）ＭＥＭＥデータ中継アプリ • （Ｗｅｂ）集中度改善アプリ • 制約 • システム統合テストが実施対象とする • ビジネスゴール/コンテキスト • IoTヘルスケア製品のプラットフォームとして開発されている • スマートエスイーの共通例題として利用される • アーキテクチャドライバ • 無駄なテストを実施したくない • テストが継続的に実施できそうか • テストを追加や変更する際に煩雑にならないか 21 テストレベル テストスコープ 例 今回の対象 システム統合テスト アプリ＆サーバ全体 （全体システム） 全体もしくは全体で機能する一 部 〇 システムテスト アプリ＆サーバ （単一or複数システム） 資料のオレンジ枠の範囲 ＩｏＴデバイス管理、センサ データ管理 - コンポーネント統合テスト アプリ (Android App) MEMEデータ中継アプリ - コンポーネントテスト モジュール、クラス (Android App) SocketClientクラス -
22. スマートエスイー修了制作成果物 成果物 • テスト要求モデル(機能) 22
23. スマートエスイー修了制作成果物 成果物 • テスト要求モデル(テスト目的) 23
24. スマートエスイー修了制作成果物 成果物 • テストスイートアーキテクチャ(概要) 24
25. スマートエスイー修了制作成果物 成果物 • テストスイートアーキテクチャ(ユースケース) 25
26. スマートエスイー修了制作成果物 成果物 • テストスイートアーキテクチャ(機能) 26
27. スマートエスイー修了制作成果物 成果物 • テストスイートアーキテクチャ(非機能) 27
28. スマートエスイー修了制作成果物 成果物 • テストスイートアーキテクチャ（デバイス） 28
29. スマートエスイー修了制作成果物 成果物 • ユーティリティツリー 29
30. スマートエスイー修了制作成果物 成果物 • シナリオ評価結果 30 シナリオ S1.テストを継続するか/中断するか決定する情報を提供する 品質特性 テスト有効性 環境 システムテスト 刺激 欠陥が見つかる 応答 テスト結果と発見された不具合情報 アーキテクチャ上の決定 肯定的作用（センシティビティ） 否定的作用（トレードオフ） リスク A1: インテークテストを 追加する SE1: A5,A7と併用することでシステム統合 テスト実施前に、各システムコンポーネン トで実装済みのユースケースが動作する ことを確実にする SE2: 品質が想定以上に悪い場合、無駄 なテストを実施させないようにできる T1:提供した情報により実行を中断した場 合、以降に実施するテストがすべて実施 されない（S2に影響） R1: インテークテストに合格しない場合、 その他のテストを実行されず、機能上で 埋め込まれた欠陥を見つける時間が+1回 サイクル分遅れる可能性がある A2: 回帰テストを追加する SE3:機能上のデグレード影響を列挙する ことができる - R2: 回帰テストが膨大な場合、終了まで時 間がかかる可能性がある A3: フィルタ構造にする SE4: A1と併用することで、無駄なテストを 実施させないようにできる - R3: フィルタ構造の配置順番によって、重 要な不具合が後になって発覚する可能性 がある A4: 機能、非機能でテストを分割する - - - A5: ビジネスステークホルダーが(ユーザー) が直に行うテストを追加する SE5：ビジネスステークホルダーそのもの の判断結果が得られる - - A6: 使用デバイスのテストを追加する A7: インテークテストと回帰テストは、作成済 みの既存テストをそのまま利用する （ユースケーステスト、機能テスト） - - -
31. スマートエスイー修了制作成果物 成果物 31 • シナリオ評価結果 シナリオ S2.以降に実施するテストので影響が出そうなものが列挙できる 品質特性 テスト有効性 環境 システムテスト 刺激 故障の影響度を確認する 応答 失敗するテストケース アーキテクチャ上の決定 肯定的作用（センシティビティ） 否定的作用（トレードオフ） リスク A1: インテークテストを 追加する SE6:A5のテストケースを利用しており、ユーザー への影響する情報が検出できる T1:提供した情報により実行を中断した場合、以 降に実施するテストがすべて実施されない（S1に 影響） - A2: 回帰テストを追加する SE7:機能を網羅的に実施するため、機能単位で 影響が列挙できる - - A3: フィルタ構造にする - - R3: フィルタ構造の配置順番によって、重要な不 具合が後になって発覚する可能性がある A4: 機能、非機能でテストを分割する - - - A5: ビジネスステークホルダーが(ユーザー)が直に 行うテストを追加する - - - A6: 使用デバイスのテストを追加する - - - A7: インテークテストと回帰テストは、作成済みの既 存テストをそのまま利用する （ユースケーステスト、機能テスト） - - -
32. スマートエスイー修了制作成果物 成果物 32 • シナリオ評価結果 シナリオ S3.新しい機能などが追加された場合、関連するテストグループにテストケースを追加しなければならない 品質特性 保守性 環境 システムテスト 刺激 テストケースの追加 応答 変更されたテストセット アーキテクチャ上の決定 肯定的作用（センシティビティ） 否定的作用（トレードオフ） リスク A1: インテークテストを 追加する - - - A2: 回帰テストを追加する - - - A3: フィルタ構造にする - - - A4: 機能、非機能でテストを分割する SE8:機能/非機能で分かれている要求に対して、 テストケース変更を管理することができる - R4:異なる分割形式同士のつながりが見えないた め、変更ミスが発生する可能性がある A5: ビジネスステークホルダーが(ユーザー)が直に 行うテストを追加する SE9:顧客要求に対して、テストケース変更を管理 することができる - R4:異なる分割形式同士のつながりが見えないた め、変更ミスが発生する可能性がある A6: 使用デバイスのテストを追加する SE10:デバイスに関する要求に対して、テスト ケースの変更を管理することができる - R4:異なる分割形式同士のつながりが見えないた め、変更ミスが発生する可能性がある A7: インテークテストと回帰テストは、作成済みの既 存テストをそのまま利用する （ユースケーステスト、機能テスト） - - -
33. スマートエスイー修了制作成果物 成果物 33 • シナリオ評価結果 シナリオ S4.新しい機能などが追加された場合、関連する既存のテストを実行しなければならない 品質特性 再利用性 環境 システムテスト 刺激 テストケースの実行 応答 テスト結果と発見された不具合情報 アーキテクチャ上の決定 肯定的作用（センシティビティ） 否定的作用（トレードオフ） リスク A1: インテークテストを 追加する - - - A2: 回帰テストを追加する - - - A3: フィルタ構造にする - - - A4: 機能、非機能でテストを分割する - - - A5: ビジネスステークホルダーが (ユーザー)が直に行うテストを追加す る - - - A6: 使用デバイスのテストを追加する - - - A7: インテークテストと回帰テストは、 作成済みの既存テストをそのまま利 用する （ユースケーステスト、機能テスト） - - -
34. スマートエスイー修了制作成果物 参照情報 • テスト設計コンテスト'18 OPENクラス 決勝戦レポート • http://aster.or.jp/business/contest/contest2018.html • CMU/SEI, The Architecture Tradeoff Analysis Method (ATAM) • https://www.sei.cmu.edu/education- outreach/credentials/credential.cfm?customel_datapageid_14047=15185 • Applying the ISO 9126 Quality Model to Test Specifications – Exemplified for TTCN-3 Test Specifications • https://www.researchgate.net/publication/221232402_Applying_the_ISO_9126_ Quality_Model_to_Test_Specifications_-_Exemplified_for_TTCN- 3_Test_Specifications • VIEWPOINT-BASED TEST ARCHITECTURE DESIGN • http://qualab.jp/research/ • UML Testing Profile 2.0 • https://www.omg.org/spec/UTP2/About-UTP2/ 35