« 2008年10月 | トップページ | 2009年1月 »

状態遷移表と論理決定表で機能図式

状態遷移図を工夫してみるの続き。

コメント欄にて教えていただいた「機能図式」を自分なりに少しまとめてみて、そのあとで例題に適用してみようと思います。

機能図式とは、ソフトウェア機能仕様を

  • 「入力データ」と「入力順序」を状態遷移モデル

  • 「入力データ」と「出力データ」と「遷移先状態」を論理モデル

  • を使って表現することを指しています。
    機能図式の記法については、論文を参照してください。基本的には状態遷移図、原因結果グラフ、デシジョンテーブルの記法の組み合わせ。

    では、メール一覧のアプリを例にとって実際に機能図式を作ってみる。

    1

    仕様を箇条書きでまとめると、以下のようなアプリケーションです。


    1. デスクトップのアイコンをダブルクリックして、アプリが起動

    2. メールが1通もない場合は、メールがない旨の表示

    3. メールがあればメール一覧をリスト表示。5通ずつのページング表示で、必要に応じて「前リンク」「次リンク」が表示

    4. 前リンクをクリックすると、前のページの5通を表示。次リンクをクリックすると、次のページの5通を表示

    5. (上図にはないが、)右上の[x]をクリックするとアプリ終了

    このメール一覧のアプリを機能図式で表現すると、まずは状態遷移部がこのようなグラフとなる。

    1

    また、論理関係部はこのようなテーブル(決定表)となる。

    2

    決定表の各列にはパス名としてPxxを名付けてみました。
    テスト経路作成基準は論文中では「全遷移を少なくとも1回、ループについては0回と1回の2通りを実現する」とある。論文には具体的なテスト経路作成アルゴリズムも紹介されているが、まだ消化不良なので、今日はここまで。

    | | コメント (0) | トラックバック (0)

    状態遷移図を工夫してみる

    簡単な状態遷移図を作ってみるの続き。

    1

    メールソフトを起動するときに、メールがある場合とない場合で初期画面が異なります。この部分についての状態遷移図はどうやって作るか。僕の場合は観測できない状態を1つ用意して、内部イベントの違いによって遷移を分ける方法をとっている。

    2

    実際には「メールが5通以下」「メールが6通以上(すなわち、次リンクが表示される)」「メールがない」の3パターンが考えられるので、「S1→(S2)→S3」「S1→(S2)→S4」「S1→(S2)→S5」の3パスが表現できる状態遷移図を作成。ここでは観測できない状態S2を終了状態にはできないので、実際のテストケースを作成するときには、少し注意が必要。

    ただし、分岐条件が複雑になった場合はこの手法だけでは難しくなってくる。たとえば、「インストール後最初の起動時にはお知らせ画面を表示する」とか、「未読メールがある場合はその旨を通知するダイアログを出す」とか、そういった仕様があったとすると、どうします?


    そこで「機能図式」という考え方へ進んでいきます。続く~。

    | | コメント (0) | トラックバック (0)

    簡単な状態遷移図を作ってみる

    状態と遷移とイベントとアクションの続き。

    具体的に状態遷移図を作ってみますかね。一つ目は比較的シンプルなもの。

  • 「電源ボタン」と「強さボタン」をもつヒーター

  • 電源ボタンを押すと、電源のON/OFFが切り替わり、強さボタンを押すと、「強」「弱」が切り替わるヒーターです。
    Photo

    状態は「電源OFF」「電源がONで、強さが弱」「電源がONで、強さが強」の3つ。イベントは「電源ボタンを押す」「強さボタンを押す」の2つ。


    では、こちらはどうでしょうか。

  • メールソフトのメール一覧機能

  • デスクトップにアイコンがあって、ダブルクリックすると起動するメールソフトですが、メールが受信箱にある場合とない場合とで、初期画面がが異なります。
    1

    上の図はメールソフトの起動時のみを表現したものです。が、状態遷移図は、状態とイベントが一つ決まれば遷移先の状態とアクションも決まる、はず。でも、この図を単純に状態遷移図にしたら、ちょっとへんですね。左の状態では「次>>」というイベントが可能ですが、左の状態では不可能のようです。みなさんは、どんな状態遷移図を考えますか?

    | | コメント (0) | トラックバック (0)

    状態の洗い出しへHAYST法かpairwise法の適用

    状態遷移モデルを使ったソフトウェアテストを勉強するためのテキストとしてボーリス・バイザーの「ソフトウェアテスト技法」「実戦的プログラムテスト入門」などを読んでみた。手順の最初に出てくるのが、仕様書からの状態とイベントの洗い出し作業。そもそも状態遷移図や状態遷移表を作ることって設計工程のツールなので、上流工程でのこういった作業が作りこみを減らすことにつながる。

    で、ソフトウェアテスト技法のほうで状態の数を探るところ(第11章 4.2)があるのだけれど、具体例としてエンジンを題材にして、

    ギア   (R、N、1速、2速、3速、4速) = 6要素
    進行方向 (全身、後退、停止) = 3要素
    エンジン (動作中、停止) = 2要素
    トランスミッション (正常、異常) = 2要素
    エンジン (正常、異常) = 2要素

    合計 = 144要素

    という記述がある。ここでいっている不可能な状態への考察って、禁則の考え方じゃないのかしら?だとすると、HAYST法を使って状態を絞り込むことができるのかな。ただ、本質的には同じことだけどHAYST法(=直交表)の特徴である、「どの条件も同じ程度出現する」というのはいらないので、pairwise法のほうが状態数が少なくなるのかな。


    | | コメント (2) | トラックバック (1)

    状態と遷移とイベントとアクション

    状態遷移図や状態遷移表を使う場合(ここでは状態遷移モデルを扱う、と同義)に、まずは構成要素である「状態」「遷移」「イベント」「アクション」を確認しておこう。

    • 状態
    • 遷移
    • イベント(入力)
    • アクション(出力)

    状態とは、状態遷移モデルでも通常の言葉と同様の意味で使われ、「システムの当分の間の状況と特性」というとらえ方をする。基本的な考え方としては状態は同時にはただ一つしかありえない。排他型と並列型という状態のとらえ方もあるが、ここでは割愛する。たとえば、「電源がOFFである/ONである」「インターネットが切断状態である/接続状態である」「検索状態である/検索結果表示状態である」など。

    遷移とは、ある状態からある状態へ状態が移り変わることを表す。たとえば、「電源が(電源ボタンを押したことで)OFF状態へ遷移する」「インターネットが(認証成功によって)接続状態へ遷移する」「(検索結果が確定して)検索結果を表示する」など。

    イベントとは、遷移をもたらす外的刺激や内的変化などを表し、入力とも事象とも表現される。ひとつのイベントは一つの遷移を決定するが、それらはイベント発生時の状態によって変化する。場合によっては、イベントはシステムに関するものではなく、システムのユーザへの刺激で表現される。たとえば、「電源ボタンを押す」「接続の認証が成功する」「検索クエリーのレスポンスが確定する」「○○さんに連絡する用事が発生する」など。

    アクションとは、遷移の結果生じる分析が可能な対象物を意味し、入力と対照的に出力とも表現される。混同されやすいが、アクションと遷移後の状態は区別される。ただし、出力も遷移後の状態も同じ名称で表現されることが多いのは確か。たとえば、「(電源がONに遷移して)ディスプレイが点灯する」「(接続の認証が成功して)アイコンが点滅する」「(検索結果が確定して)検索結果が表示される」などである。


    さて、これらのうち「状態」「遷移」「イベント」を使って、状態遷移図と呼ばれるグラフを作成してみる。

    Photo

    1

    一般的には、状態はマルで表現して、中に状態名を記述する。ただし、必要なのはモデルであるため便宜上はS1,S2などと記載される。遷移は矢印で表現され、始点は遷移前の状態と、終点は遷移後の状態と接している。イベントは状態同様にE1,E2などで省略され、対応する遷移(矢印)のそばに記述する。

    あれ、アクションがでてきません。アクションは状態遷移表で記述しましょう。今日はここまで。


    | | コメント (0) | トラックバック (0)

    [サイト]SEのためのソフトウェアテスト再入門

    SEのためのソフトウェアテスト再入門 第1回「あなたのテスト、単なる動作確認になっていませんか?」

    「どんなテストケースを書いたらよいか分からない」「自分のやっているテストに自信が持てない」そんな悩みをお持ちの方は多いのではないでしょうか。テストは、技術や経験を必要とするたいへん奥の深い世界です。この連載では、皆さんが今後開発を行っていく上での、ヒントや指針となる「テストのマインド」を紹介していきます。

    こんなサイトができていました。テストの意図は明確に。僕の中では「動作確認」と「テスト」は包含関係かなあ。

    | | コメント (0) | トラックバック (0)

    スイッチカバレッジのまとめ

    WACATE 2008 冬も無事終了したので、ここらへんで状態遷移テストについてちょこちょこ書いていこうっと。

    ということで状態遷移テストで登場するカバレッジ基準をまとめてみる。具体例や図はのちほど。

  • ノード網羅

  • システムの仕様書から「状態」を洗い出して、その状態をすべて確認すること。たとえば、バスのボタンを例に取ると「消灯」状態、「点灯」状態が考えられ、それらの状態自体を確認すること。もっともレベルの低いカバレッジ基準。

  • リンク網羅(0スイッチカバレッジ)

  • システムの仕様書から「状態」と「イベント」を洗い出して、そのイベントの表す遷移をすべて確認すること。たとえば、バスのボタンを例に取れば、イベントとして「ボタンを押す」、「点灯をリセットする」などが考えられ、状態遷移図の中の→をすべて網羅することになる。このカバレッジ基準を確認するとともに、状態遷移図から状態遷移表への変換を行い、「無効な遷移(=N/A)」の確認をあわせて行うべし。仕様書のままではもちろんのこと、状態遷移図の形でも無効な遷移は網羅しにくい。0スイッチカバレッジともいう。状態遷移図も状態遷移表も視覚的にも仕様が直感的に確認できるので、動的テストではなく設計時の検証方法でも利用される。

  • 1スイッチカバレッジ

  • 0スイッチカバレッジの上位のカバレッジ基準。合計3つの状態を2回のイベントで遷移する経路をすべて網羅するカバレッジ基準の名称。0スイッチカバレッジでは、状態遷移表を作成することで、登場するマス目を網羅すればよいのだが、1スイッチカバレッジは組み合わせを考慮する必要がある。一般的には行列の積(累乗)で計算可能。1スイッチカバレッジまでは最低限確認したいところ。

  • 2スイッチカバレッジ

  • 1スイッチカバレッジの上位のカバレッジ基準。合計4つの状態を3回のイベントで遷移する経路をすべて網羅するカバレッジ基準の名称。こちらも行列計算で全パスを抽出可能だが、対角線上のマス目に注目して、遷移ループを優先的にテストを実施するなどの工夫が考えられる。


    | | コメント (0) | トラックバック (0)

    « 2008年10月 | トップページ | 2009年1月 »