ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

ドリル勉強会第7回、状態遷移図

 11/21に開催された、第7回ソフトウェアドリル勉強会。テーマは、ドリル第5章「時間を網羅する」で現れる技法・状態遷移図・状態遷移表でした。

 主催者である加瀬さんによるtogetterまとめはコチラにあります。いつもありがとうございます。

togetter.com

 状態遷移は設計段階でも使うもので、割りと慣れ親しんだつもりでおりましたが、自分のルール無視っぷりを改めて知ることができました。そして、後半はまったくついていけない落ちこぼれぶりをアッピール。
 今回の講師は著者ご本人、秋山浩一さんです・・・。何という勉強会。秋山さんは「時間を網羅する」章の執筆で時間との戦いを余儀なくされ、書きたいことを網羅しきれなかったとのこと・・・。

4つの視点 

 状態遷移の話に入る前に、「4つの視点」と称するテストの分類が紹介されました。
 テスト技法の分類としては、秋山さんのWebサイトで紹介されている「テスト技法ポジショニングマップ」がありますね。
 ポジショニングマップは、ブラックボックス/ホワイトボックス という軸と、網羅的/ピンポイント という軸で作った平面に、各種テスト技法をマッピングしたものです。
 一方「4つの視点」とは、テストの対象や技法を、「構造」「機能」「振る舞い」「並行・並列」の4つに分類したもの。テストの視点が、順にズームアウトしていくイメージでしょうか。
 まず、「構造」に対応するテスト技法の代表が、コードカバレッジです。単体テストに対応しますね。
 次に「機能」。「構造」で確認したものを統合してできた、機能の論理を検証します。デシジョンテーブルや原因結果グラフ、HAYST法などが、技法として対応します。
 その機能によって遷移していく状態を確認するのが「振る舞い」。今回の対象である状態遷移表が、その確認のための技法となります。
 さらにその遷移が複数動いているときの挙動を検証するのが「並行・並列」。ハレル図、ペトリネットといった、わたしにとって未知の技法がここにあります。
 この勉強会の中で秋山さんが、Boris Beizer 氏の「グラフを見たら、網羅せよ」という言葉を紹介されていました。『Black-box Testing』にある「テストの一般原則」という章にある言葉みたいですね。
Black Box Testing

Black Box Testing

 

QUSTION: What do you do when you see a graph?
ANSWER: Cover it!

 ポジショニングマップも4つの視点にしても、グラフではありませんが、「こう切ってみたが、当てはまる技法は何だろう」とか、逆に「技法があるが、当てはまる象限がない。なぜだろう」みたいに発想が膨らむんですよね。なので、「集まったら、分類せよ」というのも大事だと思います。

シンガマジックのオーケストラ

まずは状態遷移図
 さて、今回の宿題は、「シンガマジック!」という人形の状態遷移図を描くというもの。なお、以下の図表はastah*を使って描いております。
シンガマジック!という人形は、手をおすと3つのモードに順番に変わり、おなかをおすと、
・モード1 の時には、「ハーモニー!」
・モード2 の時には、「おしゃべり!」
・モード3 の時には、「うたいます!」
上記、シンガマジック!の状態遷移図と状態遷移表を書いてください。
 リンク先に飛ぶとわかりますが、どのモードでも、おなかを押していると音がなって、離すと止まるという動きのようです。
 「3つのモード」という文言を見て、「じゃあ状態はまず3つだね」と脊髄反射的に作ったのが以下の状態遷移図です。

01_5f94d199

 いや、初期はもっとひどい、かつ表記ルールも守っていなかったので、思い出を美化しています。
 「バイバイ」というのは上の説明にはありませんが、あるモードで放置すると、「バイバーイ」といって黙りこむという動作をするので、その状態も追加しています。
状態からして網羅できていない!
 この状態遷移図のダメな点はなんでしょう。・・・ダメな点は複数ありそうなので、「特にダメな点」としておきましょうか。
 モード「ハーモニー」に注目してください。開始直後、シンガマジックの声は出ていません。次に、腹部を圧迫すると、声が出ます。その「声が出ている」状態は何かというと、ぐるっと回ってやっぱり「ハーモニー」としているのが、上の状態遷移図なんですね。
 「声が出ている」と「声が出ていない」とは、別の状態として定義しないといけません。イベントとしては、「押す」に対して「離す」を入れてやるといいですね。で、描いたのがコレ。

02_83d5fad9

 3つのモードからもそれぞれ、電池切れで終了状態に落ちいるようにしました。
「開始状態」「終了状態」とは
 この「開始状態」「終了状態」というちょっと難しい。正しくはこれを「開始擬似状態」「終了擬似状態」と呼ぶそうです。秋山さんにコチラの記事を紹介していただきました。
 状態遷移図の遷移図の「状態」は、オブジェクトが取りうるもの。オブジェクトは時間軸のある時点で生成され、別の時点で消滅します。
 では、生成の前のオブジェクトはどのような状態なのでしょう。答えは、「状態はない」ということになりますね。存在してないのだから、「バイバイ」ですらありません。とはいえ、最初の状態へは、どこからか遷移してこなくてはならない。よって、実際にはオブジェクトがとりえない「開始擬似状態」を定義して、何らかのイベントをトリガーにして最初の状態を取る、ということなんですね。
次に状態遷移表
 さて、astah*を使うと、描いた状態遷移図から、状態遷移表が自動的に生成されます。これは嬉しいよなあ。
 最初はこんな感じで現れます。空白のセルが多いですね。

03_db6a55f3

 状態遷移表のメリットは、このように、考慮されていない状態×イベントが可視化できる点ですね。
 たとえば、「バイバイ」で「腹を押す」とどうなるかが、遷移図にないことがわかりますね。実際には、このアクションでも「モード1」に遷移するとのことです。また、「腹を離す」を定義したのに、「手を離す」って不要なの?とも思い当たります。
 たとえ「ありえない」遷移であっても、空白で残すのではなく「N/A」と明示的に判断しておくことが必要になります。
 なお、astah*では「N/A」にあたるものとして、「cannot happen」と「ignore」の2つから選べるようです。「cannot happen」は原理的に起こりえない、たとえば「押した状態で、押す」といったもの。「ignore」は、起こりうるけど、考慮しない。というものと捉えています(未確認)。「ignore」を選ぶのは勇気がいるな。

04_03aaf879

 「開始状態」は、表にいらない気がするんだけどなあ・・・。
網羅性
 状態遷移の網羅の考え方として、n-switchカバレッジがあります。n-switchとは、遷移後n回スイッチすることを意味しています。上の状態遷移図でいうと、「モード1→モード2→モード3」は、1-switchの遷移ということになりますね。
 遷移する回数nを決めると、状態から状態へn回のスイッチで到達するためのルートは、行列計算で求めることができます。手順的には難しくありませんが、面倒です。
 今回の勉強会では、遷移をツリー状に展開することでスイッチパターンを洗い出す方法を教えていただきました。Togetterには、参加者の方の結果の画像もアップされているので、ご覧ください。

さらに話は続く!

 さて、この後、直交表を使った状態遷移テストの考え方と、さらにはシーケンスカバリングアレイという、テストパターン削減のための技法についてお話いただいたのですが、全然咀嚼できておらず・・・。
 とりあえず書けるのはこんなところです。シーケンスカバリングアレイは、某MLのやりとりを一度じっくり読んだので、もしかすると、いつか・・・いつか・・・書けるかもしれない。
 ともあれ、いつも充実した内容の本勉強会、主催者・講師のみなさまには感謝でございます・・。