[例題]同値分割・境界値分析観点でテスト設計する

携帯の充電池が膨らんじゃって、ドコモショップに持っていったら、無料交換してくれた!やった!

==

初心にもどって、同値分割、同値クラスを調べてみる。


同値分割とは、入力データを「同じ出力結果が得られるグループ」に分割することをいいます。このグループのことを「同値クラス」と言います。また、正常処理を行う同値クラスを「有効同値クラス」と言い、エラー処理を行う同値クラスを「無効同値クラス」と言います。

同値分割とは何か? - たまゆら雑記



起こりうるすべての事象をいくつかのグループに分け、各グループから 代表値を選ぶ方法です。 このグループを「同値クラス」といい、同様の出力結果が得られる 入力値の集合です。 ・境界値分析 同値クラスの境界値付近を入力値として選んでテストする方法です。

同値分割、境界値分析



同値分割(equivalence partition): 仕様上、コンポーネントやシステムの動作が同じと見なせる入力定義域や出力定義域の部分。

JSTQB ソフトウェアテスト標準用語集 日本語版Ver 1.1 PDFファイル


事象をグループ分けして代表元のみテストを実施する。なのでグループ分けは結果が同じになるような入力集合になる。電源ボタン、リセットボタンについては、すでに単機能テストで結果について網羅できそうなので、ここではポイント(上)ボタンについて考えてみる。ポイント(上)ボタンを押すことでスコアボードはどんな結果を生じるか。

  • 上のプレイヤーのポイントが15増える

  • 上のプレイヤーのポイントが10増える

  • 上のプレイヤーのポイントが増える ※タイブレーク時

  • 上のプレイヤー側のアドバンテージ表示となる

  • DEUCE表示となる

  • 上のプレイヤーの勝利でゲームが終了する(ポイント欄がリセットされる
  • これら6つの同値クラスが考えられるため、各同値クラスの代表元を選択して、テストケースとする。

    Photo_6

    ポイント(下)ボタンについては上下を逆にしたテストケースを考えればよい。番号B-01-03がテストしにくいな。


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

    [例題]単機能テストを設計する

    1. [例題]テニスのスコアボード
    2. [例題]分析する - 3色ボールペン版
    3. [例題]分析する - マインドマップ版

    仕様分析からテスト設計へ。まずは、単機能テストの設計をしてみる。
    ・・・
    ・・・
    ふと、単機能テストを検索してみると、けっこう「単機能テスト単体テスト、コンポーネントテスト」という記述があったりする。単なる用語の使い方の違い、という考え方もあるけれど、僕の認識では、単機能テストと単体テストは違うテストと思う。単体テストの目的は、「関数・メソッドといった”システムの一部”が正しく実装されているか」であり、やり方によっては組み合わせテストも含まれるし、主にホワイトボックステスト(あるいはグレーボックステスト)で設計されることが多い。一方、単機能テストの目的は「機能が単独で正しい動作をするかどうか」であり、組み合わせテストを含まず、実行結果が注目されるテスト。ブラックボックス的。

    # 当然、後者の意味で「単体テスト」と表現する場合もありました。

    などと思いをめぐらしながら、例題の単機能テストへ。



    1. 電源ボタン
    2. 仕様をみてみると、
      Photo
      電源の切り替えができるかどうかが単機能テストであろう。
      Photo


    3. リセットボタン
    4. 仕様より、
      Photo_2
      電源ONの状態で、画面がリセットされるかどうかが単機能テスト。
      Photo_3


    5. ポイント(上)ボタン
    6. ポイントボタンは仕様がやや複雑であるが、ここではもっとも基本的な動作である、電源ONの状態で、上のプレイヤーのPOINTSが追加されるかどうかを単機能テストとする。GAMESおよびSETSへの反映パターンはここでは考慮しない。という方針。
      Photo_4


    7. ポイント(下)ボタン
    8. ポイント(上)ボタンと同様。
      Photo_5

    こんな感じ。このスコアボードはボタンが4つしかなく、減点機能がないため、これらのテストケースの実施順序は最終的に変更する予定。


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

    [例題]分析する - マインドマップ版

    例題を作って、テスト設計をしてみる。

  • [例題]テニスのスコアボード

  • [例題]分析する - 3色ボールペン版
  • ==

    Tennisscoreboardmm_2

    マインドマップから始めるソフトウェアテストでは、仕様分析~テスト計画~テスト設計~といった流れで、マインドマップをツールとして利用している。ここでは仕様分析+アプローチといったニュアンスでマインドマップを使ってみた。各メインブランチにふれてみると、

  • 単機能テスト
  • ここでは、ボタンを押すと仕様どおり(電源が切り替わったり、ポイントが増えたり)動作することを確認すること。スモークテスト的なテストでもいいかも。

  • 同値・境界値テスト
  • ポイント数、ゲーム数、セット数。ゲームが終わるとき、セットが終わるとき、試合が終わるとき。表示の桁数などなど。

  • 状態遷移テスト
  • 業務シナリオテストに近いイメージ。実際の試合を想定した利用。効果的、効率的なテストを目指す。

  • 組み合わせテスト
  • この状況でこのボタンを押したら、こうなる。

  • テストしない
  • ソフトウェアテストの例題なので、外部環境はできないですね。あと、数字がちゃんと表示されるか。とか。

  • テニスのルール
  • スコアのつけかたって、意外に複雑なのだよ。15ずつ増えたり、増えなかったり。タイブレークがあったり、なかったり。

    こういうのって数をこなしていくことも重要なのかな。ここ何日かは通勤バスの中でテキストを読んで復習してます。


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

    [例題]テニスのスコアボード

    原因結果グラフをデシジョンテーブルにするツールを作ったら、理解が進むかなあ。

    ==

    テスト設計の例題。自分で出して、自分で考える。
    Tennisscoreboard_2

    テニスのスコアボードのテスト

    1. 電源でON/OFF切り替え
    2. 電源をONにすると初期状態で起動
    3. 電源OFF状態ではどのボタンも無効
    4. リセットを押すと初期状態
    5. ポイント(上)を押すと上のプレイヤーにポイント
    6. ポイント(下)を押すと下のプレーヤーにポイント
    7. デュースは「40-40」と表示
    8. アドバンテージはリード側に「AD」と表示し、反対側は無表示
    9. ゲーム終了時に「0-0」に戻る
    10. 5セットマッチ、最終セット以外はタイブレーク
    11. 3セット取った状態でポイントを押すと初期状態
    12. ポイント減点機能はない
    13. 2つ以上のボタンを押したら、後から押したボタンは無効
    14. 2つ以上のボタンを同時に押したら、1ボタンだけが有効で、優先順位は、電源>リセットボタン>ポイント(上)>ポイント(下)

    まずは、3色ボールペンとかで仕様チェーック、かな。

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