mhlyc -presentation

僕が書きたいことをひたすらに書き綴る、自己満足のブログです。

テスト技術者 Foundation Levelシラバス 4章について(3)

アドベントカレンダー17日目 4章:テスト設計技法

こんにちは。リリカルです。

次回WACATEの必須予習項目である、テスト技術者のFoundation Levelシラバスをまとめています。今日もその続きです。

WACATE2016 夏 満員御礼!と 予習内容について - WACATEブログ

前回は4章の前半を説明しました。続いて、仕様ベースのテスト技法の詳細な説明に入っていきます。

4.3 仕様ベース/ブラックボックスのテスト技法

ここだけ別にしてマインドマップ描いてみたのがこれです。

f:id:mhlyc:20160602003455j:plain

テスト技法については、こちらの資料が多少参考になるかもしれません。

www.slideshare.net

※デザインなどシンプルすぎるきらいがありますよね。すみません。このスライド作った頃はまだMacの使い方に慣れていなくて… けっこうな人数の方に見ていただいているようなので、後で手直しする予定です。

一つずつ技法の紹介をしていきます。

同値分割法

同値分割法は、ソフトウェアやシステムへの入力を同じ処理をする(であろう)グループに分割する技法です。同値分割によって、グループ内の入力は同等に扱えるようになります。この同値分割のグループは有効データだけでなく、無効データにもあります。同値分割したグループは、出力や内部変数、イベントの発生前と発生後などにも存在します。インタフェースパラメータにも同値分割を適用することができます。非常に適用範囲の広い技法です。当然、あらゆるレベルのテストで適用することができます。

同値分割、境界値分析についてはこちらの資料にも解説を載せています。(p.7〜p.16あたり)

www.slideshare.net

境界値分析

同値分割したグループの境界上の動作は、 グループ内部の境界ではない値に比べ欠陥が埋め込まれることが多いです。ある領域において最大値・最小値も境界値であるといえます。同値分割した時に有効な領域側の境界値は「有効な境界値」といい、無効な領域側の境界値は「無効な境界値」といいます。テストケースを作る際はこの両方の領域から値を選ぶことになります。

境界値分析もあらゆるテストレベルで適用することができ、また欠陥の摘出能力も高いです。詳細化された仕様があれば、境界値を決定するのに役立ちます。

デシジョンテーブルテスト

論理的な条件、内部設計のドキュメント化、複雑なビジネスルールの表現などに使われます。よくある例題としては、「遊園地の入場料割引」があります。(子ども料金、学割、シニア料金など)

入力条件や動作はだいたい真偽(ブール値)で表現します。先の例で言えば、入力条件の一つは「学生である/学生でない」のようになります。そしてその入力条件の組み合わせと、各組み合わせにおける処理がどうなるかというのを表形式で表現します。

とは言っても文章じゃよくわからないと思うので、先のテストアナリスト3章のスライドp.13の図を見てくださると「なるほど」となると思います。

デシジョンテーブルテストは、ソフトウェアの動作がいくつかの論理的な判定に依存する限り、全ての状況において適用可能な技法です。

状態遷移テスト

テストアナリスト3章スライドのp.17, 18に図があります。

現在の条件や前の条件、システムの状態によってシステムは全く異なる動作をすることがあります。このシステムの動作を図で表したものが状態遷移図です。状態遷移図を作成することで、テスト担当者は現在の状態や状態間の遷移、状態を遷移する入力やイベントなどからソフトウェアをとらえられるようになります。

この図を表形式で表したものが状態遷移表です。状態遷移表は状態と入力の関係を洗い出し、不正な遷移がないか確認するのに有効です。

状態遷移を用いることで、状態の網羅や状態遷移の網羅、不正な遷移がないかといった方針を立ててテストを設計できるようになります。状態遷移テストは、一般的に組み込み系ソフトウェアやブラウザで動作するWebアプリケーションをテストする際に有効です。

ユースケーステスト

 ユースケースはアクターとシステムの相互作用を表したもので、ユーザや顧客にとって価値のある結果を示します。ユースケースはビジネスフローであるとか、システムレベルなど抽象的なレベルで説明されることが多いです。各ユースケースには事前条件があり、ユースケースが完了した後の出力結果は事後条件ということになります。ユースケーステストは、ビジネスフローの欠陥を摘出することに役立ちます。またその性質上、顧客やユーザが参画する受け入れテストを設計するときにも有効です。

次回予告と感想

Foundation Levelで扱われるテスト技法を紹介しましたが、このあたりの技法はかなり知名度も高く実業務で使ったことのある方も多いのではないでしょうか。今一度見直してみることで新たな発見があるかもしれません。

それではまた次回よろしくお願いします。