はじめに

はじめまして。開発エンジニアのamdaba_sk（ペンネーム未定）です。 ラクスに新卒で入社し、今年で３年目になります。

先日ラクスオフィス内にあります共用本棚に「知識ゼロから学ぶソフトウェアテスト 【改訂版】」を見つけました。

ちょうどテストコードの書き方に悩んでいたところで勝手に自主的にこれを読みましたので、少し内容をまとめてみようと思います。

少しネットで「ソフトウェアテスト」検索するとたくさんの記事がヒットしますが、めげずに書きます。

目次

• はじめに
• • 目次
• ソフトウェアのテストを分類してみる
• • 工程による分類
  • • 開発者側の工程に対応するテスト
    • 顧客側の工程に対応するテスト
  • 品質の観点による分類
  • 実行方法による分類
  • 技法による分類
• テストケース作成技法をまとめてみる
• • ホワイトボックステスト（制御パステスト）
  • ブラックボックステスト
  • • 同値分割と境界値分析
    • • 例えば…
    • デシジョンテーブル
    • • 例えば…
    • 状態遷移テスト
    • ランダムテスト
• おわりに
• 参考

ソフトウェアのテストを分類してみる

○○テストという言葉はたくさんありますが、まずは大きく工程・品質の観点・実行方法・技法に区別されます。

工程による分類

開発の工程に対応させた分類です。

開発者側の工程に対応するテスト

• 単体テスト
• • ソフトウェアを構成する最小の要素に対するテスト
  • 言語や開発プロセスによって「単体」の定義が異なる
• 統合（結合）テスト
• • 単体同士を組み合わせた全体に対するテスト
• システムテスト
• • ソフトウェアの全機能に対するテスト
  • 運用時と同じインフラ、ハードウェア、ミドルウェアを用いて行う

顧客側の工程に対応するテスト

• 受入テスト
• • 顧客が納品されたソフトウェアに対して行うテスト
  • 自社開発など、行われない場合も多い

品質の観点による分類

どういった品質を確かめる目的で行われるのかという視点に基づく分類です。

• 機能テスト
• • 機能が正しく実装されているかどうかのテスト
• 性能テスト・負荷テスト
• • ストレスなく使用できる程度の実行速度がでるかどうかのテスト
  • 負荷テストでは必要な性能を満たせる限界を見極める
• ユーザビリティテスト
• • 「使いやすい」かどうかを確認するテスト
• セキュリティテスト
• • 外部からの攻撃に耐えられるかどうかのテスト
• etc...

実行方法による分類

その名の通り、テストの実行方法による分類です。

• 動的テスト
• • テストのためにソフトウェアを実行するテスト方法
• 静的テスト
• • ソフトウェアを実行せずに行うテスト
  • コードレビュー、静的解析、etc...

技法による分類

テストのためにはどのような操作をして何を確認するかを定めた「テストケース」を作成します。テストケース作成に用いる技法による分類です。

• ホワイトボックステスト
• ブラックボックステスト
• （グレーボックステスト）

テストケース作成技法をまとめてみる

ホワイトボックステスト（制御パステスト）

ホワイトボックステストはプログラムの論理構造が正しいかどうかのテストです。デバッガでステップ実行などしながら、それぞれの行、それぞれのブロックで実行される文は正しく書かれているか、if分やswitch文の条件は適切か、きちんと終了まで実行されるかを確認します。

このテストの実行によってカバレッジ率が算出され、プログラムの品質を計る一つの指標となります。

ホワイトボックステストで焦点となるのはあくまでプログラムの論理構造なので、以下のような不具合は見つけられません。

• 要求仕様自体の誤りや不備
• データに関するバグ
• マルチタスクや割込みに関するバグ

ブラックボックステスト

ブラックボックステストは名前の通りプログラムを一種のブラックボックスとして扱うテストで、様々な入力に対して妥当な出力が返されるかどうかを確認します。

ですが多くのプログラムでは可能な入力の組み合わせは膨大で、それらをすべて試すことは不可能です。そこで効果的な入力をもれなく選び取る方法が考案されています。

同値分割と境界値分析

同値分割と境界値分析は、ブラックボックステスト手法の中でも基本的な手法です。

同値分割では入力全体の集合を「同値クラス」という部分集合に分割します。

同値クラスは、同じ同値クラスの入力であればプログラムの動きに本質的な違いが出ないような入力の集合です。多くはプログラムが期待する入力値である「有効同値」、そしてそれ以外のあらゆる入力値である「無効同値」に分けられます。

それぞれの入力項目ですべての同値クラスの入力を行えば、あらゆる入力に対してテストされたことになります。

境界値分析では同値クラス同士の境界に注目します。

同値クラスの境界は条件文によって分けられることが多く、これを書き間違えることでバグになります。

そこで境界をまたぐもっとも近い入力の組を入力とすることで処理の切り替えがきちんとなされていることを確かめます。

例えば…

1から10までの自然数を受け付ける入力項目に対して

1. 0を入力1（無効同値①、境界値）⇒ 入力エラーになる
2. 1を入力（有効同値、境界値）⇒ 正常に処理される2
3. 5を入力（有効同値）⇒ 正常に処理される
4. 10を入力（有効同値、境界値）⇒ 正常に処理される
5. 11を入力（無効同値②、境界値）⇒ 入力エラーになる

デシジョンテーブル

同値分割や境界値分析は、入力項目が複数ありさらにそれらが相関している時には大変ややこしくなります。デシジョンテーブルではそれらの入力の組み合わせを表にして、各組み合わせに対して期待される出力をまとめていく方法です。

複雑な状態が絡み合う機能のテストで有効です。

例えば…

入力項目が2つあって、両方に1から10までの自然数が入力された場合のみ処理がされる場合

状態遷移テスト

ソフトウェアによっては「状態」が複数存在し、操作することでそれらの状態間を行き来する場合があります。状態によって受け付ける入力や出力を変化させています。

状態遷移テストはそういった場合に、入力に対して正しく状態遷移（出力）するかどうかをテストします。

ランダムテスト

ランダムテストはこれまでのブラックボックステスト手法とは毛色が違っていて、事前にテストケースなどを作成せずにやみくもに入力や操作を行うテスト手法です。

結構なバグがこれで見つかるようですが、機能要求に対するテストではあまり有効でないとのことです。ただし、セキュリティに対するファジングテストという形でランダムテストが活用されています。

おわりに

参考図書、参考ページをもとに、ソフトウェアテストの分類と、その中でテストケース作成技法についてまとめてみました。簡単ではありましたが、この記事を読んでくれた方がソフトウェアテストの勉強をするきっかけになれたなら幸いです。

参考

1. 高橋 寿一 (著) 知識ゼロから学ぶソフトウェアテスト 【改訂版】
2. http://gihyo.jp/dev/serial/01/tech_station/0001?page=1
3. http://b.hatena.ne.jp/entry/qiita.com/ktarow/items/8c3d94d6c21a0c86b799

1. 0はいろいろな意味で特別なので、仕様的に境界値でなくともテストした方が良いです。↩
2. 実際はここは仕様に合わせて具体的に書きます。↩