Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

テストの視点からのモデリング(公開用) #wacate

1,413 views

Published on

WACATE 2018 冬の講演資料です。

Published in: Engineering
  • Be the first to comment

テストの視点からのモデリング(公開用) #wacate

  1. 1. テストの視点からの モデリング WACATE実行委員 朱峰 錦司@kjstylepp
  2. 2. 自己紹介 ■ 朱峰錦司(あけみねきんじ)@kjstylepp ■ 本業 – あじゃいるとらんすふぉーめーしょんこんさる – でじたるさーびすすたーとあっぷこんさる ■ 趣味 – テストエンジニアとエンジニアリングの話をすること
  3. 3. 宣伝(1) ■ NaITE #28 7/21(土)午後@川崎らへん ■ アジャイル開発におけるサービス企画の考え方や開発 プロセスとの統合に関するプラクティスについて話しま す ■ タイトル(仮) – 「プロダクトオーナーシップそーゆーことね 完全に理解した←わかってない」
  4. 4. 宣伝(2) ■ twitterで「#きんぢラーメン大賞」で検索
  5. 5. なんでWACATEでモデリング? ■ 仕様書が古い ■ 仕様書が膨大すぎる ■ 仕様書が読みづらい ■ 仕様書がない
  6. 6. ゴール ■ 様々なモデリング観点/記法があることを理解する ■ 汎用的な記法としてUMLがあることを理解する ■ モデルをテストに活用できることを理解する – 仕様理解 – テストケース抽出 ■ モデルをかくためのツールを知る
  7. 7. 目次 1. モデル 2. UML 3. モデルベースドテスト 4. UML記述ツール
  8. 8. 1. モデル
  9. 9. 1.1 モデルとは ■ 対象物の振る舞いや性質を特定の観点で抽象化し、 それを特定の文法で表現したもの ■ ひとつのモデルで全ての振る舞いや性質を表現するこ とは不可能 ■ モデルへ抽象化する作業を「モデリング」と呼ぶ – 「絵を描く」はただの「モデルの記述」 ■ モデリングではない
  10. 10. 1.2 モデルの記法 ■ まずは観点 – 例:対象物の「状態」とその「変化」に着目 ■ それを表現するための言語/文法 – 例:UMLダイアグラム形式 – 例:表形式 – 例:テキスト形式
  11. 11. 1.2 観点 と 文法
  12. 12. 1.2 観点 と 文法
  13. 13. 1.2 観点 と 文法
  14. 14. 1.3 テストエンジニアがふれるモデル記法 ■ 仕様モデル記法 – テスト対象となる仕様を抽象化、整理したもの ■ テスト独自のモデル記法 – テスト観点や、テスト目的等を抽象化、整理したもの ■ 結果として仕様の情報が含まれることも多い
  15. 15. 1.4 仕様モデル記法の例 ■ UML ■ SysML from UML ■ 原因結果グラフ
  16. 16. 1.4.1 SysML ■ Systems Modeling Language ■ UMLから派生したシステム設計用の言語 – 一部のUMLの記法を再利用 – さらに文法を制限することでとっつきやすく
  17. 17. 1.4.2 原因結果グラフ ■ 数理論理モデル ■ 英語ではCEG – cause effect graph
  18. 18. 1.5 テスト独自のモデル記法 ■ NGT@VSTeP ■ FV表/FL表/ラルフチャート@HAYST法 ■ テスト分析マトリクス@ゆもつよメソッド
  19. 19. 1.5.1 NGT ■ Notation for Generic Testing has-a 関係 組み合わせ 出典:Viewpoint-basedTest Architecture Design, MaSST 2012
  20. 20. 1.5.2 FV表 ■ Function Verification表 No. 目的機能 検証内容 テスト技法 4-1 冬の通学路で学生が百人 一首を聞きたい。それは、 ライバルに勝つためだ。 シャッフル機能 早送り 気温/温度 雪 音質 手袋つけて操作 : : 組合せテスト 雪 音質 : シナリオテスト シャッフル 長押し : 出典:ユーザーストーリーとFV表, JaSST’18Tohoku
  21. 21. 1.5.3 テスト分析マトリクス ■ 機能×テストタイプ/カテゴリ 機能テスト ロード テスト 堅牢性 テスト データ互換 テスト ボタン 押下 センサー 反応 内部 メモリ 状態 遷移 外部 メモリ 画面 表示 長時間起動 条件 組合せ メディア 互換 システム 電源管理 ○ ○ ○ ○ ○ ○ リセット ○ ○ ○ ○ ○ 撮影 通常撮影 ○ ○ ○ ズーム撮影 ○ ○ ○ 連続撮影 ○ ○ ○ ○ 再生 通常再生 ○ ○ 設定 撮影設定 ○ ○ ○ 再生モード設定 ○ ○ ○ データ メモリ装着 ○ ○ ○ ○ ○ ファイルコピー ○ ○ ○ ○
  22. 22. モデリングの注意点 ■ 「記法」だけ覚えても効果が薄い – むしろ細かい記法はあとでOK ■ 学習/実践を繰り返して「抽象化」能力を磨く ■ 「方法論」として整理された洗練された様々な抽象化手 順/手法が存在 – 例)RDRA ■ リレーションシップ駆動要求分析 ■ JaSST’18 Hokkaidoのキーノート
  23. 23. 2. UML
  24. 24. 2.1 UMLとは ■ Unified Modeling Language – OMG(Object Management Group)によって策定 – 現在v2.5.1 ■ ISO国際規格にもなっている – ISO/IEC 19505-1:2012 – UML v2.4.1がベース
  25. 25. 2.2 UMLの代表的なモデル 1. 構造モデル – クラス図 2. 振る舞いモデル – ユースケース図 – アクティビティ図 – 状態遷移図 3. 相互作用モデル – シーケンス図 ブラックボックステ スト向き ホワイトボックステ スト向き 静的解析向き
  26. 26. 2.2.1 クラス図
  27. 27. 2.2.2 ユースケース図
  28. 28. 2.2.3 アクティビティ図
  29. 29. 2.2.4 状態遷移図
  30. 30. 2.2.5 シーケンス図
  31. 31. 2.3 UMLをかくときの注意点 ■ [改めて] 細かい文法にとらわれすぎない ■ 多少のカスタマイズもOK – ただしチーム内で合意
  32. 32. 2.4 UMLの文法/メタモデル ■ モデリングにおいて「文法」自体をモデルとして表記す ることが可能である ■ このようなモデル表記された文法を「メタモデル」という ■ たとえば、UMLの全ての図は「構造」をもつため、その 構造のルールを構造の表現が可能な「クラス図」でメタ モデリングできる。
  33. 33. 2.4 UMLの文法/メタモデル ■ 状態遷移図のメタモデル
  34. 34. 3. モデルベースド テスト
  35. 35. 3.1 モデルベースドテストとは ■ モデル変換技術の一種 ■ 仕様モデルから機械的なルールを用いてテストケース モデルを抽出する技術 テストケース モデル 仕様モデル システム テストケース 開発 詳細化 抽出 実行
  36. 36. 3.2 モデルベースドテストの例 ■ ユースケーステスト/シナリオテスト ■ 状態遷移テスト ■ デシジョンテーブル生成
  37. 37. 3.2.1 ユースケーステスト/シナリオテスト ■ ユースケースのインタラクションから、一定のルールに 基づき、テストパターンを抽出 ■ アクティビティ図から、一定のルールに基づき、テスト パターンを抽出
  38. 38. 3.2.2 状態遷移テスト ■ 状態遷移図や遷移表から、一定のルールに基づき、テ ストパータンを抽出
  39. 39. 3.2.3 デシジョンテーブル生成 ■ 原因結果グラフから、一定のルールに基づいて、テス トパターン(デシジョンテーブルのルール)を抽出
  40. 40. 3.3 モデルベースドテストの注意点 ■ そもそも仕様モデルが必要 – いちからモデル描いてまでやるメリットがあるかどうか考え よう ■ 基本、Checkingに該当するテストケースが対象 – 別途、Testingもしっかりやろう
  41. 41. 4. UML記述ツール
  42. 42. 4.1 無料で使える代表的なツール ■ astah* community ■ PlantUML + お好きなエディタ
  43. 43. 4.2 astah* community ■ 日本発のモデル記述ツール astah*シリーズ ■ communityは限定的な機能を無料で利用可能 – v6.9までは商用利用も可 ■ まだちゃんと公式サイトでもダウンロード可能 – v7.0以降は商用利用は不可 ■ 現在の最新版はv7.2 ■ 仕事で使いたい場合は有償版を買いましょう
  44. 44. 4.2 astah* community ■ communityで基本的なUMLは全て記述できる ■ 有償版になると、UML以外にも様々なモデルを記述で きる – SysML – データベース設計 – マインドマップ – 各種業務図
  45. 45. 4.3 PlantUML ■ エンジニアリング業界全体的にきている「プレーンテキスト記述」 の波 – Markdown – Sphinx – Re:VIEW ■ プレーンテキストのメリット – 不要の環境固定化の排除 ■ 好きなサポートツールでレンダリング – 版管理の容易性 ■ ドキュメント自体の版管理が容易 – 容易な差分チェック ■ ソースコード/テストコードの版管理と同期可能
  46. 46. 4.3 PlantUML ■ PlantUML – テキストでUMLを記述可能な”DSL”定義 ■ 記述はお好みのエディタを使う – Emacs – Vim – Atom – Visual Studio Code – 記述されたモデルの文法チェック – 画像出力
  47. 47. 4.3 PlantUML ■ WindowsでVisual Studio Codeにインストール – https://qiita.com/couzie/items/9dedb834c5aff09ea7b2
  48. 48. おわりに
  49. 49. ゴール(再掲) ■ 様々なモデリング観点/記法があることを理解する ■ 汎用的な記法としてUMLがあることを理解する ■ モデルをテストに活用できることを理解する – 仕様理解 – テストケース抽出 ■ モデルをかくためのツールを知る
  50. 50. 今後に向けて ■ WACATE中 – しっかりと手を動かして以下を実践してみてください ■ UMLモデリング ■ モデルベースドテスト ■ WACATE後 – ぜひPlantUMLでUMLを描いてみてください
  51. 51. 今後に向けて @startuml ramen_state [*] --> 生きてる: 産声をあげる state 生きてる { [*] -> ラーメン食べたい ラーメン食べたい --> ラーメンもういい: ラーメン食べる ラーメンもういい --> ラーメン食べたい: 30分たつ } 生きてる --> 死んでる: 生き途絶える @enduml
  52. 52. Let’s modeling!

×