🦁

テスト技法 ブラックボックステストの概要と設計手法について

4 min read

はじめに

この記事は「フィヨルドブートキャンプ Part 2 Advent Calendar 2021 - Adventar」 13日目の記事です。
昨日はsasaboさんの「私なりの OSS 活動」でした。

現在、会社の研修の一環としてフィヨルドブートキャンプを受講させていただいています。

今回はソフトウェアテストのブラックボックステストについて書いていければと思います。

ソフトウェアテストとは

ソフトウェアテストとは、開発中のソフトウェアが意図した通りに動作するか求められている仕様を満たしているかを検証すること作業のことです。

ソフトウェアの品質特性は以下のようなものがあります。

  • 機能適合性
  • 性能効率性
  • 互換性
  • 使用性
  • 信頼性
  • セキュリティ
  • 保守性
  • 移植性

ブラックボックステストとは

ブラックボックステストではソフトウェアの内部構造や実装に関する知識を必要とせず、入力した内容に対して期待した出力があるかを確認します。
ブラックボックステストとは、テスト対象の要件や仕様にに基づいたテストケースの作成技法です。
全てのテストパターンを網羅する必要がない為、テストに対する投資から最大の効果を引き出すことができますが、テスト対象のソフトウェアの内部のどれだけの部分をテストできているのかを明確に知ることが難しいといったデメリットもあります。

ブラックボックステストとは別にテスト対象の構造、実装内容に対してテストケースを作成するホワイトボックステストというものがあります。
ホワイトボックステストはプログラミングに関するスキルが必要になりますが、ブラックボックステストではテスト対象ソフトウェアの構造、実装に関する知識を必要としません。(今回はホワイトボックステストの詳細については触れません。)

テストのレベル

ソフトウェアテストテストは4つの異なるレベルで実施されます。単体テスト、結合テスト、システムテスト、受け入れテストです。
ホワイトボックステストは単体テストで、ブラックボックステストは結合テスト以降で実施されることがほとんどです。

単体テスト

開発者が作成するソフトウェアの最も小さい部品を指します。関数やクラス等。

統合テスト

単体のものを組み合わせてテストをします。単体のものをテストした際には正しく機能していたかもしれませんが、単体のものを結合した際に欠陥が出るケースもあったりします。

システムテスト

顧客に届ける全てのソフトウェアから構成されます。機能性やユーザビリティ、セキュリティ、国際化、信頼性、可用性等、多くの種類を扱うテストです。

受け入れテスト

顧客がソフトウェアを受け入れて、代金を支払うテストとして定義されています。

ブラックボックステストの設計手法

では、実際にどのようなブラックボックステストの設計手法があるのか例も入れながら見ていきます。

同値クラステスト

仕様からデータを意味のあるグループ⁠(同値クラス)に分類し,各グループから代表値を選ぶ技法です。

年齢を入力するシステムで、その値の入力について考えてみます。

そのシステムでは入力の制限がかかっており、以下の制約があります。

  • 1歳以上20歳未満までが有効
  • 1歳未満は無効
  • 20歳以上は無効

これをグループ分けすると

年齢 判定
1歳未満 無効
1歳以上20歳未満 有効
20歳以上 無効

このようなグループ⁠(同値クラス) に分類することができました。0歳から順に1,2,3とテストをしていく必要がなく、分別したグループごとにテストをすることで、十分なテストカバレッジを保ちつつ、テストケースの数を管理可能な数まで減らすことができます。

境界値分析

データの境界値部分の値で試験を行う方法です。境界には問題が潜んでいる可能性が高いため、境界付近の値を選んでテストケースを作ります。

同値クラスと同じものを使います。

年齢 判定
1歳未満 無効
1以上20歳未満 有効
20歳以上 無効

1歳未満と1歳以上20歳未満の境界値にあたるものは、1歳が境界値となります。
また1歳以上20歳未満と20歳以上の境界値にあたるものは、20歳が境界値となり、これらの境界値をテストしていきます。
同値クラステストと同じで、十分なテストカバレッジを保ちつつ、テストケースの数を管理可能な数まで減らすことができる技法です。

状態遷移テスト

状態遷移図とは、ソフトウェアやシステムの状態がさまざまな条件やイベントによって変化することを、図や矢印を使って表現したものです。
この状態遷移図を用いて全ての状態、イベント、また全ての遷移をテストすることが状態遷移テストです。

用語の説明、図での表され方

  • 状態

システムが1つまたは複数のイベント待っている状態を表す。円で表される。

  • イベント

状態を変化させる出来事のこと。矢印に付随して表される。

  • 遷移

イベントによってある状態から別の状態になること。矢印で表される。

  • アクション

状態の変化によって引き起こされる。"/~"で表される。

書籍で使われていた図を引用させていただきました。
これは航空券の予約の様子を状態遷移図で表しています。

状態遷移図

引用文献
1)リー・コープランド. ソフトウェアのテスト技法.日経BP, 2013, p.97

下記のテーブルは
なし⇨成立⇨入金済⇨発券済⇨使用済の遷移のパターンで作成したテストケースです。

現在の状態 イベント アクション 次の状態
なし 情報提示 支払いタイマー始動 成立
成立 入金 入金済
入金済 印刷 発券 発券済
発券済 航空券回収 使用済

これ以外の遷移のパターン、状態はあるので全ての遷移を少なくとも1回は実行するようなテストケースを作成していく必要があります。

デシジョンテーブル

デシジョンテーブルとはさまざまな条件に対して,どのようにソフトウェアが動作するのかを決定する表のことです。
システムが実装しなければいけない複雑なビジネスルールを記録するために用いられ、テストケースを作成する際の指針としても役立ちます。

レストランの食事を想定しています。レストランで食事をする際に以下の条件に当てはまるものがあれば適応されるものとします。

  • 祝日の利用で10%OFF
  • クーポンの利用で20%OFF
  • 両方の条件に当てはまる場合は、高い方の割引が適用される

これらの条件から考えられるパターンを表で表すとこのようなテーブルになります。

パターン 1 2 3 4ー
条件 祝日 Y Y N N
クーポン利用 Y N Y N
結果 10%OFF - X - -
20%OFF X - X -
割引無し - - - X

条件の値

  • Yが条件成立
  • Nが条件不成立
  • -が結果に無関係

結果の値

  • Xが動作・結果が生じる
  • -が動作・結果が生じない

このように各条件に対して、テストケースを最低でも1つは作成する必要があり、条件が2値であれば、各組み合わせに対して1つのテストケース用意する必要があります。

最後に

簡単にですがブラックボックステストについてまとめてみました。
紹介したもの以外にも手法はまだあるので、学びつつ実践で手を動かしながら活かせるようにしていきたいですね。
ホワイトボックステストやグレーボックステスト等なるものもあって、テストはまだまだ奥が深いので、引き続き色々と学んでいければと思います。

参考資料

https://www.amazon.co.jp/dp/4822282511/
https://service.shiftinc.jp/column/4960/
https://service.shiftinc.jp/column/3621/

Discussion

ログインするとコメントできます