Zenn
😇

テスト技法を利用する目的

2022/08/14に公開
ソフトウェアテスト
テスト技法
idea

テスト技法とは？

ソフトウェアテストを効率よく進めるための技法として、テスト技法と呼ばれるものがあります。また、主にテスト技法は以下2点を目的として利用されます。

  • ①不具合を効率よく見つけるため
  • ②仕様を整理するため

①不具合を効率よく見つけるため

ソフトウェアテストの7原則に「全数テストは不可能」という法則があります。（例えばGoogleの検索結果が正しく表示されているか、を確認したいとします。この場合、「文字」、「数字」、「外国語」など、あらゆる入力できるものを確認しなければならないので、テストケース数が実施不可能なほど大きな数になります。）

そのため、テストを効率よく進めるには不具合が多そうなところを重点的にテストすることになります。

不具合が多そうなところとは、

  • 仕様変更が多発している機能
  • 開発者のスキルセットと開発機能のレベルがあっていないところ
  • 仕様が確定していない機能（見切り発車で開発しているところ）
  • 他システムと連携している部分
  • 過去に不具合が多発した機能

などが該当します。そして、それらを確認するテスト技法として以下があります。

ホワイトボックステスト

一度も動かしていないプログラムに不具合があると考え、動かしていないプログラムがないように、網羅性の観点からテストを行う技法です。（一度も動かしていないプログラムとは、例えば本来はいらない例外のデータが出現した場合の処理、などが該当します）

  • 命令網羅 (statement coverage) (C0)
    1度も動かしていない命令文（処理）に問題があると考え、1度は命令文を確認するようにする。

  • 分岐網羅 (branch coverage) (C1)
    1度も動かしていない判定条件の真偽（簡単なif文の分岐）に問題があると考え、1度は判定条件を確認するようにする。

  • 条件網羅 (condition coverage) (C2)
    1度も動かしていない複数の判定条件（if文かつ関係演算子を使って複雑になった分岐等）に問題があると考え、1度は判定条件を確認するようにする。

ペアワイズ法/オールペア法

機能の組み合わせが複雑なところを、2因子（2機能）間の組み合わせをテストすると、約8割ぐらいの組み合わせの不具合が検出できる、という経験側から実施する技法です。

個人的に上記経験側の記事が古いため（2004年ごろ）、2因子のみで本当に問題ないのか、は議論の余地があると思っています。そのため、私が使う場合は、どうしてもテストケースを削れない場合の最後の手段として用います。
2因子に関する参考資料：https://ieeexplore.ieee.org/abstract/document/1321063

HAYST法（直交表と用いたテスト技法）

直交表と呼ばれる表に各機能のパラメータを記載することで、2因子網羅のテストを行うことができます。ペアワイズ法との違いは、

  • 3因子網羅性がペアワイズ法より高い
  • テストケース数はペアワイズ法より多くなる

と言った特徴があります。

同値境界値分析

同値分析は、各入力内容などを同値と呼ばれる1つのくくりにすることで、テストケースの数を減らす技法です。また、境界値分析は条件が変わる部分に不具合があると考え、その部分を集中的にテストする技法になります。

同値分割について

例えば、「20歳以上の人にクーポンを適用する」、という仕様があった場合、

if(age >= 20):
	#クーポンを適用する処理を記載

と記載しますが、「0～19歳」までは、上記条件で変わることがないので、「0～19歳」までは1つのテストでよいと考える手法になります。

境界値について

同値分割と同じ例を利用すると、ここで開発者が間違えやすいのが「>=」、「20」の2か所になります。そのため、この部分が間違えた場合のテストを行おう、というのが境界値分析の考え方になります。

同値境界値は組み合わせてテストすることが多く、同値分割で数を減らし、境界値で不具合をピンポイントに狙います。

②仕様を整理するため

仕様がきちんとまとまっていると有効なテストケースを設計しやすくなります。しかしながら、開発工数の短縮や開発者の案件掛け持ち等で、実際の仕様が不明確なままテストケースを作成しなければならないこともあります。

そのため、以下のようなテスト技法を使うことで、仕様を整理しながらテストケースを作成することができます。

ディシジョンテーブル

ソフトウェアの仕様を表形式で整理することで、機能の組み合わせに漏れがないか、期待結果に問題がないか確認する技法となります。

原因結果グラフ

原因と結果を矢印でつなぐことで、どのような原因がありどんな結果になればいいのか、その状況を整理するための技法です。こちらは、上記のディシジョンテーブルを作成するための、前資料として作成されることがあります。

状態遷移テスト

状態遷移表、もしくは状態遷移図という図に表すことで、ソフトウェアの動作を可視化し仕様を整理する技法。RPGゲームなど、選択肢によってその後の展開が変わるものに対して有効な手法です。

まとめ

テスト技法を学ぶと、その便利さにゆえに闇雲に利用したがることがあります。その結果、何のためにそのテスト技法を利用したのか、の部分が抜けてしまい無意味なテストとなることもあります。

テスト技法はそれぞれ何をテストするための技法なのか、各技法ごとに目的があります。そのため、テストしなければいけない機能とテスト技法の目的を一致させテストを行うことが、効率的なテストへとつながると思います。

Discussion