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

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

More Related Content

What's hot(20)

Kpt×ナース(公開版)Kpt×ナース(公開版)
Kpt×ナース(公開版)
Noriyuki Nemoto7.1K views
概説 テスト分析概説 テスト分析
概説 テスト分析
崇 山﨑31.7K views
例外設計における大罪例外設計における大罪
例外設計における大罪
Takuto Wada68.5K views
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima29.3K views
ソフトウェアテスト入門ソフトウェアテスト入門
ソフトウェアテスト入門
Preferred Networks15.5K views
TDD のこころ @ OSH2014TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
Takuto Wada15.8K views

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

Recently uploaded(8)

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