ソフトウェアを多くの人に使ってもらうためには、不具合のないことが重要です。そのため、不具合ソフトウェアをテストすることで不具合を見つけて修正することが求められます。
そこで本記事では、テストの種類や重要な原則などを詳しく説明します。ソフトウェアテストを行う場合はぜひ参考にしてください。
ソフトウェアテストとは？
ソフトウェアテストは、プログラムを進める上でまた出来上がったあとにバグや不具合などを探して修正する作業です。この修正をする動きをデバッグといいます。
テストをすることにより不具合が見つかったりあらかじめ設定されている品質目標に到達すること、さらに試験項目に合格することがテストの目的です。ソフトウェアテストは不具合があることは証明できないので、注意が必要です。
ソフトウェアテストを実施する目的
ソフトウェアテストを実施する目的は、不具合を見つけて修正することです。ソフトウェアをリリースするためには、不具合のないものである必要があり、不具合が多い製品は悪い品質といった判断をされます。
ソフトウェアテストは、テストの対象となるものの特徴を把握し適切なテストケースを組むことが重要です。そのため、不具合を見つけるためにはさまざまなテストを試すことが求められます。不具合をなくすことによって、ユーザビリティの高いソフトウェアを作成しましょう。
【分類別】ソフトウェアテストの種類
ソフトウェアテストはそれぞれの分類ごとに種類が挙げられます。
- ソフトウェアテスト工程における種類
- 品質特性（テストタイプ）における種類
- 実行方法における種類
- テスト技法における種類
1.ソフトウェアテスト工程における種類
ソフトウェアテスト工程には次のような種類が挙げられます。
- 単体テスト
- 統合テスト
- システムテスト
- 受け入れテスト
単体テスト
単体テストとは開発フェーズにおいてはじめにするそれぞれのユニットやパーツに重点をおいているテストです。
SDLCの始めの段階ですることが特徴であり、メソッドや関数、モジュール、プロシージャなどにおいて正確性を確認します。さらに、それぞれがどのような動作をするのか予測することも必要です。
統合テスト
統合（結合）テストは、個々の機能を複数組み合わせて動作を確認するテストです。ユニットテストで検証したモジュールを複数組み合わせて動作させ、不具合がないかを確認します。
ユニットテストでは正常に動いていたモジュールも複数組み合わされると動作しない可能性もあるため、統合テストの段階で出てきた不具合も適宜デバッグしてます。統合（結合）テストについては、次の記事でも詳しく紹介しているのでぜひご確認ください。
【結合テストとは？】具体的な内容や種類、実施方式ついて解説します！
システムテスト
システム（総合）テストは、一通りのテスト工程が終わった後に行うテストです。機能要件を満たすシステムとなっているかを確認するために、本番と同じ環境を用意して、実際のユーザーの利用方法を想定しながらテストを進めます。
ユニットテストや統合テストで検出されなかった不具合を発見するとともに、仕様書で定める機能が正しく実装されているかの最終確認を本番環境さながらのデータを利用して検証します。システムテストでは全体的な機能テストだけでなく「ユーザビリティテスト」や「セキュリティテスト」といった非機能テストも併せて行います。
受け入れテスト
ユーザー受入テストは、実際の利用者にシステムを操作してもらい、機能要件を満たしているかを確認するテストです。
製品版のリリースに先立ったテスト版を外部へ公開して実際に利用してもらうことで、使用感やバグの発生などについてレビューをもとに製品版の完成度を高める目的で行います。
テスト工程で十分なテストを行っていても、実際のシステムが稼働する本番環境のサーバーやデータで検証を行わなければ、リリース後に予期せぬ不具合が発生する可能性もあります。
本番環境、および実データ、そして実際のユーザーによるシステムのテストは重要であり、本番環境での動作が正しく保証されると、機能要件も正しく満たされているといえます。
ユーザー受入テストは、開発側でのシステムテストが終わり、テスト工程で起こりうる不具合を一通り解消した後、つまりリリース直前のタイミングで行われるのが一般的です。
2.品質特性（テストタイプ）における種類
品質特性（テストタイプ）には次のような種類が挙げられます。
- 機能テスト
- 非機能テスト
- 負荷テスト
- 性能テスト
- 信頼性テスト
- 移植性テスト
- ユーザビリティテスト
- 相互運用性テスト
- セキュリティテスト
機能テスト
機能テストとは、システムが機能要件を満たしているかを確認するためのテストです。機能要件とは、クライアントと打ち合わせて決めたシステムに実装する機能や挙動を指します。
一般的に機能要件はシステム開発工程の要件定義フェーズで予算や開発スケジュール、開発手法とともに定義するものです。クライアントがシステムに求める機能が定義通り過不足なく実装されているか、システム利用における目的を果たしているかを機能テストにて確認します。
非機能テスト
非機能テストとは、ストレステストや信頼性テスト、保守性テスト、性能テスト、パフォーマンステスト、ユーザビリティテストなど機能としては必要であるわけではなくても、エンドユーザーのエクスペリエンスの向上に関わる部分においてのテストです。
直接不具合につながらなくても非機能テストの対象が正常の動きをしないことで、システム内に問題がある可能性があります。
負荷テスト
負荷テストとは、大きな負荷をかけることによってソフトウェアの課題や瑕疵があるかどうかの確認をするテストです。課題があった場合どのような条件で発生するのか試験することも重要です。
発生する可能性が高い状況や負荷をかけないと発生しない問題など、さまざまな不具合の出方を確認します。負荷テストは非機能テストの1つであり、リソースが十分でないときに適切なエラー処理がされるかどうかの検証もします。
性能テスト
性能テストとは、性能が設定したレベルに達しているのか性能によって問題がでないかといった点を見極めるテストです。スループットや占有、応答時間（レスポンスタイム）、使われるリソースなどが要件要素となることが一般的です。
負担を増やすことによってどのような動きをするのか、要件に達する性能であるかボトルネックの確認などが必要です。
信頼性テスト
信頼性テストとは、あらかじめ機能が想定通りに実行できているかどうかを確認するテストです。例えば、ソフトウェアにおいて障害許容性や故障から復活する速度、故障が発生する頻度などの確認をします。
移植性テスト
移植性テストとは、複数の環境やハードウェアにおいて従来通りの動きをするかどうかを確認するテストです。ソフトウェアをハードウェアや環境に移行する場合においてスムーズにできるかどうかを確認する場合もあります。
ユーザビリティテスト
ユーザビリティテストとは、ユーザーがシステムを使いやすいかどうか試してもらうテストです。システムのインタラクティブなデザインが主な対象であり、ユーザーが使いやすいかどうかが重要なポイントです。
実際にユーザーに使ってもらうことで、使い勝手など意見やコメントをもらうことが一般的です。ユーザビリティ検証法とはまた別であり区別が必要です。
相互運用性テスト
相互運用性テストとは、共通している情報交換の規則やプロトコルを使ってファイルの読み書きやデータのやりとり、要求の送信などが従来通りに動くかどうかを確認するテストです。
セキュリティテスト
セキュリティテストとは、システムに対して外部からの攻撃に対しての脆弱性を把握するテストです。近年マルウエアをはじめさまざまな攻撃による被害が増えており、重要なテストです。
3.実行方法における種類
実行方法には次の2種類が挙げられます。
- 動的テスト
- 静的テスト
動的テスト
動的テストとは、テスト対象を動かすことが特徴です。動かした結果をテストしていきます。
静的テスト
静的テストとは、ソフトウェアを構成しているソースコードを確認することによって記述パターンをテストしていきます。
4.テスト技法における種類
テスト技法には次の2種類あります。
- ブラックボックステスト
- ホワイトボックステスト
ブラックボックステスト
ブラックボックステストとは、テスト対象の仕様をベースとしたテストです。仕様書をはじめとしたドキュメト群の分析を進めてテストケースを作成していきます。そのため内部構造に着目するホワイトボックスとは大きく異なります。
ブラックボックステストにはさまざまな技法があり、デンジョンテーブル、境界値分析、ユースケース、同値分割法などが挙げられます。
ホワイトボックステスト
ホワイトボックステストとは、内部の構造に着目しておりデータフローや制御フローなど倫理構造を基準としたテストです。そのため、外部仕様はテスト基準に含めません。
テストをして命令することで、倫理に直結するかどうかの確認をすることが目的です。テストの種類が多いことから、適切なテストをするために管理が求められます。
ソフトウェアテストで重要な7つの原則
ソフトウェアテストには次のように重要な7つの原則があります。
- 不具合がないことを証明できない
- 全てのパターンをテストできない
- 初期テストが特に重要である
- 具合は特定の箇所に集中している
- 同じテストを繰り返すと不具合を発見しづらくなる
- 不具合の修正による影響にも考慮が必要
- 全く同じテストを適用できるソフトウェアは存在しない
1.不具合がないことを証明できない
ソフトウェアテストは不具合がないことを証明できません。ソフトウェアテストは不具合を見つけ出し修正することができますが、たまたまのテストや修正が終わった段階においても不具合がないといった正面にはありません。
テストを行った時点でたまたま不具合が出なかった可能性や実行したテストにおいては不具合を発見できなかった場合などの可能性があるためです。ソフトウェアテストを進めるにあたって、不具合は必ずあるものといった考えが必要です。
2.全てのパターンをテストできない
ソフトウェアテストは全てのパターンをテストできるわけではありません。従来の四角形であれば2通りであってもマス目が増えると同じ場所を捕まえて言ったら条件を設定した場合でも12通りになります。
このように条件によって組み合わせの種類は増えることがあるため、すべてのパターンをテストすることは不可能です。ソフトウェアのテストを行うにあたって優先順位を設定することが重要です。
3.初期テストが特に重要である
ソフトウェアテストは初期テストが特に重要です。不具合はできるだけ早期で発見することによって対処がしやすくなります。逆に不具合を見つけるのが遅くなればなるほど、影響範囲が広まってしまい不具合の対応が遅くなります。
4.不具合は特定の箇所に集中している
ソフトウェアテストでは不具合は特定の箇所に集中しています。ソフトウェアの不具合は一般的に様々な場所に散らばっているわけではありません。
そのためこれまでテストを行ってきたデータを分析することによって、不具合が起こりやすい場所を予測することによりテストを進めやすくなります。
5.同じテストを繰り返すと不具合を発見しづらくなる
ソフトウェアテストは同じテストを繰り返すと不具合を発見しづらくなる点が特徴です。不具合を発見して修正することによって開発を始めた段階で不具合を出しにくくなるようにできます。
そのため同じような性質を持つソフトウェアで同じテストをし続けることによって不具合が発見しにくくなるようになります。
6.不具合の修正による影響にも考慮が必要
ソフトウェアテストでは不具合の修正による影響にも考慮が必要です。テストにより不具合がない状態だったとしても、テストをしたことによって他の部分に影響が出る可能性があります不具合を修正する場合、修正したことによって他に影響が出る可能性があることを考慮することが必要です。
7. 全く同じテストを適用できるソフトウェアは存在しない
ソフトウェアテストには、全く同じテストを適用できるソフトウェアは存在しません。ソフトウェアは状況や使用目的、設計またテストをする目的などによりテストケースを変えることが必要です。そのため全く同じテストが他で適用されることはありません。
【まとめ】機能テストについて正しく理解しよう
ソフトウェアテストには手法や品質特性（テストタイプ）における種類、工程における種類などによりさまざまな種類があります。
それぞれのテストを適切に分けることが必要であるため、テストの特徴を正しく理解することが重要です。また、ソフトウェアテストには原則があるため把握しておくようにしましょう。
