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