はじめに
この記事は実務経験8ヶ月のフロントエンドエンジニアが、
- 自分の書いたコードに考慮漏れとかねぇかな
- 不安だからセルフデバッグでポチポチしまくってるけど面倒くせぇなあ
- デグレしてたら嫌だなぁ
- こういうのってテストコード書いたらか解消されるんかなぁ
- テストコードを書いたことないから、ひとまず「ソフトウェアテスト全般」の内容について勉強してみるかぁ
といった経緯で書きました。
具体的なテストツールやコードの書き方というよりは「ソフトウェアテストの基礎的な内容」について自分なりにまとめた記事になります。
ソフトウェアテストってなんぞや
ソフトウェアテストとは、ソフトウェアが意図した通りに動作するかを検証すること
テストの実行方法
意図した通りに動作するかを検証するのは決して手動で画面を1つずつぽちぽちするだけではありません。テスト手法には静的テストと動的テストがあります。
静的テスト
プログラムのソースコードを人間による目視や専用のソフトウェアによって解析し、誤っている箇所を見つけること。手でポチポチやるのが静的テスト。
動的テスト
実際にプログラムを実行してみて意図した通りに動作するかを確かめること。テストコード書いて実行するのが動的テスト。
テスト工程
テストを行う際にどのような手順でやればいいのでしょうか？
基本的には「小さい範囲から大きい範囲」へと移行していきます。
単体テスト
部品単位の信頼性を担保する。各モジュールごとにテストを行い、誤りがないかテストを行う。
特定の1つの機能単位や関数単位でテストを行う。後述するブラックボックステストやホワイトボックステストがよく用いられる。
結合テスト
複数のモジュールを組み合わせて、モジュール間のインターフェースがちゃんと動いてるか確認する。後述するトップダウンテストやボトムアップテストがよく用いられる。
システムテスト
単体テストや結合テストよりも検証の範囲が広い。システム全体のテストを行う。
- 要求された機能が仕様通りに動くかを確認する機能テスト
- 処理能力を確認する性能テスト
- 負荷がかかった時にちゃんと動くかを確認する負荷テスト
などがある。
テスト手法
ブラックボックステスト
モジュールの内部構造は意識せず、入力に大して仕様通りの結果が得られているかを確認する。
ただし、入力内容として用いるテストデータは適当に選んでいいわけではないらしい、、
テストデータを作成する基準として用いられるのが、同値分割と限界値分割というもの。
同値分割
データ範囲を種類ごとのグループに分けて、それぞれのグループから代表的な値を抜き出してテストデータとして使用する。
限界値分析
データ範囲を種類ごとのグループに分けて、境目部分を重点的にチェックする方法。境界付近の値をデータに用いる。
ホワイトボックステスト
ブラックボックステストと違い、モジュールの内部構造が正しく作られているかをテストする。ホワイトボックステストを行うには、「テストパターンをどこまでカバーするか」を決めてからテストケースを設計する。網羅基準には「命令網羅」「判定条件網羅」「条件網羅」「複数条件網羅」がある。
命令網羅
全ての命令を最低１回は通すようにするテスト
下記の図だと、赤のルートだけ通っておけばOK
判定条件網羅
全ての分岐は最低１回は通すようにするテスト。
赤と青のルート両方通って全ての分岐を試す。
条件網羅
個々の条件が真と偽の値を最低１回は満たすようにするテスト
以下のテストケース① or テストケース② のどちらかを試せればOK
複数条件網羅
複数条件がとりうる真偽値全ての組み合わせを網羅するテスト
トップダウンテスト
上位モジュールから先にテストを済ませていく。
下位モジュールはテストがまだだったりするので、スタブと言う仮のモジュールをくっつける。
ボトムアップテスト
下位モジュールからテストを行う。
上位モジュールはテストがまだだったりするので、ドライバと言う仮のモジュールをくっつける。
