このドキュメントについて
ソフトウェアのテストをするにあたって、そもそもテストってどういった工程・観点・手法があるんだっけと初心に帰る再確認メモ
前提
ソフトウェアのテストはプロジェクトによって、工程の呼び方、テスト範囲が異なってくるので完全なテストの形というのは見えずらいが、何の為にテストをするか？どういうことをしないといけないのか？どのくらいの工数でやるのか？ということを念頭に置いてテストすることが大事
何のためにテストをするか？
- 欠陥やバグを見つけられる
- 仕様通りに実装されていることを担保する
- バグが出やすいポイントがわかったり、想定しなかった挙動を発見したりなど、起こりうるリスクを洗い出すことができる
- システム規模・バグ件数から開発指標を作ったり、自動化・効率化などの課題が見つかり、開発プロセス改善に役立つ etc.
一般的なテストの種類
単体テスト （Unit test, Module test etc.）
最小単位である関数レベルで詳細仕様通りに作られているか確認するテスト
最近はテストコード記述するのが主流で、テスト対象部分以外はStub、Mockを使って外部の要因に影響されないようなテスト構成にする（例えばクラスAのテストコードを作成しているときに、クラスAで使われてるクラスBの処理内容は関係ないのでクラスBを Stub or Mock に置き換える etc.）
-
ホワイトボックステスト
- テスト対象関数の内部構造に着目し、条件分岐や繰り返しなどの各部分を確認する(コードカバレッジの網羅）
- コードカバレッジの網羅は一般の商用ソフトウェアなら70～90%程度で十分と思われる
- 構造の正しさのみをテストするため、ソフトウェアの仕様が間違っていることから起こるバグは発見できない
-
ブラックボックステスト
-
テスト対象関数の内部構造は意識せずに仕様を満たしているかどうかを要点にテストする
-
ソフトウェアの挙動で大事な事は以下の４つなので、それについて確認する
- インプットデータ
- アウトプットデータ
- 業務処理
- データフロー（DBへの登録・変更・削除が正しく行われているか etc.）
-
他にもバグが出やすいところを観点とする
- 境界値を確認する
- 最小値、0、最大値を確認する
- 桁数を確認する
- 空（null）データの確認をする
-
GUI（画面）を伴うソフトウェアの場合は、状態遷移の確認もする
- 画面遷移が正しく制御されているか確認する
- セッションデータ（キャッシュ etc.）の保持が正しく制御されているか確認する
-
※単体テストはホワイトボックステストの観点に注目されがちだが、それだけだと変更に対して弱くなるため、仕様目線でテストケースをつくるブラックボックステストの観点も織り交ぜた方が良いとされている
結合テスト （Integration test, Join test, Interface test etc.）
単体テスト完了後に行うテストで、開発した複数のモジュールなどを組み合わせて動作させたときに正しく動くか確認するテスト（ビジネス的な要因で一連のテストが実施できない場合は工程を前段階「内部結合テスト」、後段階「外部結合テスト」と分ける場合がある）
-
内部結合 （Integration test A, Integration test 1 etc.）
- 画面や複数モジュールに跨った処理が正しく動作しているかを確認する
- 画面や複数モジュールに跨ったデータフローが正しく行われているかを確認する
- 単体テストでは確認できないテスト項目を確認する（例外処理テスト, 業務シナリオテスト etc.）
※GUI（画面）を伴うソフトウェアの場合は、画面単位で結合テストを実施し、単体テストを包含テストする場合もある
※BEで完結するようなAPIテストの場合は、テストコードで内部結合を実施する場合が多い
-
外部結合テスト （Integration test B, Integration test 2 etc.）
- 外部要因（外部システム etc.）との疎通確認をする
- 外部要因（外部システム etc.）とのインターフェイスのインパラメータ、アウトパラメーターの確認をする（インターフェイステスト）
- テスト手法はブラックボックステストで行うことがほとんど
総合テスト （System test, Product test etc.）
開発の最終段階で行われるテストで、製品として完成したものを本番同等の環境で行うテスト
- 以下のような観点でテストすることが多い
- システムが全体として要求された仕様のとおりに動作するか確認する
- 修正・変更を行った後にデグレードしていないか確認する（デグレードテスト）
- 極端に高い負荷をかけた状況下での動作は問題ないか（負荷テスト）
- 処理能力が仕様を満たしているか（パフォーマンステスト）
- 長時間の連続稼働によって処理能力や稼働率に問題が生じないか（ロングランテスト）
- 脆弱性が存在しないか（セキュリティテスト）
ユーザーテスト （User test etc.）
ユーザーが直接触ってみて、システムが全体として要求された仕様のとおりに動作するかはもちろん、操作性、見やすさなどユーザビリティの確認をするテスト
- 開発者や委託された側で実施することは少ない
まとめ
- 工程に囚われず上記観点たちを確認できる場面で確認する、落とせるテストは削ってしまうなど柔軟で効率的なテスト計画をすることは大事だと思う。ただ、機械的なテストに偏る、面倒だからとテスト後回しにしたり、テストを怠ると痛い目をみるのは自分である。柔軟な観点をもつ、スケジュールはどのくらい余裕があるのか、テストすべき部分については相当のコストが掛かるなどの意識は常にもっていなければならない
- また、各種ツール（Selenium：自動打鍵ツール、JMeter：負荷ツール etc.）、テストフレームワーク（JUnit, DJUnit etc.）を駆使して容易に再実施可能なみんなが幸せになるようなテストを心掛けるようにしたい