ソフトウェアテストについて簡単にまとめてみた

はじめに

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

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

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

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

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

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

工程による分類

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

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

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

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

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

品質の観点による分類

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

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

実行方法による分類

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

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

技法による分類

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

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

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

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

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

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

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

ブラックボックステスト

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

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

同値分割と境界値分析

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

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

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

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

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

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

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

例えば…

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

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

デシジョンテーブル

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

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

例えば…

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

条件	組み合わせ
入力項目Aが1-10の範囲内	Yes	Yes	No	No
入力項目Bが1-10の範囲内	Yes	No	Yes	No
動作	処理実行	エラー	エラー	エラー

状態遷移テスト

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

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

ランダムテスト

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

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

おわりに

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

参考

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

エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。

https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.com
ラクスDevelopers登録フォーム

https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！