ソフトウェアテストの概要

ソフトウェアテストの目的

ソフトウェアテストの目的は、テスト対象の特徴に合わせてテストケースを組み、いろいろなテストを繰り返して不具合を見つけ出し、ユーザーにとって有用なソフトウェアとなること。

有用なソフトウェアは、要は『システムやサービスを使う人の要求をどれだけ満足させられるか』ということで、『お客様の満足度』と言い換えられる。よって、お客様の立場によって、求められる要求や考え方は多々ある。

そこで、一定の基準として、ソフトウェア品質の評価については ISO/IEC 2510:2011 で８つの品質特性が標準化されている。

品質特性	概要
機能適合性	実装された機能がニーズを満たす度合い
性能効率性	システムの実行時の性能や資源効率の度合い
互換性	他製品やシステムと機能や情報を共有・変換できる度合い
使用性	効果的、効率的に利用できる度合い
信頼性	必要時に実行できる度合い
セキュリティ	不正に悪用されることなく、情報やデータが保護される度合い
保守性	効果的、効率的に保守や修正ができる度合い
移植性	効果的、効率的に他のハードウェアや実行環境に移植できる度合い

ソフトウェアテストの種類

上記のソフトウェアの品質特性を測るテストに次のものがある。

テスト名	概要
機能テスト	ソフトウェアの搭載する機能が要求通りかを確認する
性能テスト	ユーザが快適に使用できるかを確認する（レスポンスの早さ等）
負荷テスト	ソフトウェアに負荷をかけて許容限界値を確認する
ユーザビリティテスト	ユーザが使いやすいと感じるかどうかを確認する
セキュリティテスト	サイバーリスクに対するセキュリティ強度を測定する

ホワイトボックステスト

ホワイトボックステストは、テスト対象の構造に着目してテストケースを作成する技法。設計や実装の内容から内部構造（処理経路）を網羅するようにテストケースを作成する。

この時の網羅度合についての基準をカバレッジ（網羅率）といい、ホワイトボックステストでは、目標とするカバレッジを満たすようにテストケースを設計していく。

カバレッジには次のような種類がある。

カバレッジ名	概要
行カバレッジ	全てのコード行のうち、テストで実行された行の割合
ステートメントカバレッジ(C0：命令網羅率)	全ての実行可能命令(ステートメント)のうち、テストで実行された命令の割合
ブロックカバレッジ	全てのブロックのうち、テストで実行されたブロックの割合
パスカバレッジ	全てのパス（処理経路）のうち、テストで実行されたパスの割合
判断文カバレッジ(ブランチカバレッジ、C1：分岐網羅率)	全ての判定条件のうち、テストで実行された判定条件の割合。判断文全体が真と偽の両方の値を取ルようにする。
単純条件カバレッジ(C2：条件網羅率)	全ての条件のうち、テストで実行された条件の割合。C1と違い、個々の条件が真と偽の両方の値を取る必要がある。
Modified Condition/Decision Coverage (MC/DC)カバレッジ	次を満たすようにすると網羅率が100％となる。 a.各「判断文」が、少なくとも1回すべての可能な結果を得ている。 b.1つの「判断文」中の各条件が、少なくとも1回すべての可能な結果を得ている。 c.1つの「判断文」中の個々の条件が、単独で全体の「判断文」の結果を左右する。
関数カバレッジ	全ての関数のうち、テストで最低1回実行された関数の割合
コールカバレッジ	全ての関数呼び出しのうち、テストで呼び出された関数の割合

ブラックボックステスト

ブラックボックステストは、『テスト対象の仕様』に基づいたテストケース作成技法。テスト対象をブラックボックス（中の見えない箱）として捉え、仕様を基にテストケースを作成する。テスト対象の実装には興味がなく、ある入力に対してどのような出力となるかをテストする。

ブラックオックステストでよく使われるのは次の２つ。

技法名	概要
同値分割法	データから仕様を基に意味あるグループ（同値クラス）に分類し、各グループから代表値を選ぶ技法。これにより、似通った意味ばかりのテストケースになることを防いだり、意味あるデータのテスト漏れを予防できる。
境界値分析	同値クラスごとの境界値をテストデータとして選択する技法。

同値分割

同値分割の作業は大きく下記５つの手順。

同値クラスを作る

入力をグループ分けすること。グループ分けは、複数のある基準（観点）によって行う。
同値クラスを分類する

グループ分けされた同値クラスを、有効同値クラスと呼ばれる正常系、無効同値クラスと呼ばれる異常系、準正常系に分類する。
代表値を決定する

それぞれの観点ごとに、具体的な数値であったり文字列等の代表値を決定する。
テスト条件を決定する

観点が１つの場合は、決定した代表値をテスト条件とする。観点が複数のテストケースは、無効同値クラスが重複しないようにテスト条件の組み合わせて、テストケースとする。
テスト条件を見直す

手順1~4で作成したテストケースをセルフレビューやペアレビュー等で見直し、必要なら手順1~4を繰り返す。

境界値分割

同値分割で得られた同値クラスの境界や端に注目してテストケースを考える技法。

デシジョンテーブル

デシジョンテーブルとは論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールの組合せを示す。

デシジョンテーブルは決定表（JIS X 0125）として規格化されている。表形式で表現することで、プログラムの処理条件やポリシーなどがわかりやすしたり、テスト条件を整理する時に利用する。

デシジョンテーブルは、具体例を見た方がわかりやすいので、参考サイトの例を下記に示す。

例：健康ランドの精算システムにおける、「割引サービス」に関する仕様

［既存の仕様］

クーポン持参:10％OFF

平日割引:30％OFF

平日シニア割引（65歳以上）:50％OFF

2つ以上の割引サービスが重なった場合は、割引率が高い方が優先される

現在の仕様をデシジョンテーブルで表すと次のようになる。

［新たに追加される仕様］

土日祝ジュニア割引（15歳以下）:20％OFF

仕様が追加されたデシジョンテーブルを表す。条件が成立しない組み合わせについては、N/Aとする。

第5回　仕様整理に「デシジョンテーブル」を使ってみよう | gihyo.jp