機能テストとは?定義/種類/事例/方法を紹介
機能テストは、ソフトウェアが事前に定義された要件に従って動作しているかどうかをQAスタッフが評価するプロセスです。この記事では機能テストの定義、種類、事例、および方法を見ていきましょう。
1. 機能テストとは?
機能テストはブラックボックステストの一種で、アプリケーションやシステムの機能が期待通りに動作しているかどうかを確認するために実施されます。このテストでは、テスト対象アプリケーションのユーザーインターフェース、API、データベース、クライアント/サーバー通信、セキュリティ、その他の機能をチェックします。テストは、手動または自動化ツールを使用して実行されます。
2. 機能テストの種類
最も一般的な機能テストの種類を以下で簡単に紹介します。
Functional testing categories | 機能テストカテゴリ |
Unit testing | 単体テスト |
Line coverage | ラインカバレッジ |
Code path coverage | 経路組み合わせカバレッジ |
Method coverage | メソッドカバレッジ |
Sanity testing | 健全性テスト |
Smoke testing | スモークテスト |
Regression testing | 回帰テスト |
Integration testing | 統合テスト |
Usability testing | ユーザビリティテスト |
単体テスト
単体テストとは、ソフトウェア開発プロセスの一つで、アプリケーションのテスト可能な最小の部分(ユニットと呼ばれる)を個別に、独立して、正常に動作をするかテストするものです。このテスト方法は、ソフトウェア開発者またはテスターによって開発プロセス中に実行されます。
コードカバレッジは、単体テストの重要な部分であり、テストケースは以下の3つのタイプをカバーするために必要です。
- i) ラインカバレッジ
- ii) 経路組み合わせカバレッジ
iii) メソッドカバレッジ
健全性テスト
アプリケーション/システムの主要かつ重要な機能がすべて正しく機能していることを確認するために実施するテストです。これは通常、スモークテストの後に行われます。
スモークテスト
実装の安定性を確認するために、実装がリリースされるたびに実施されるテストです。実装検証テストとも呼ばれます。
回帰テスト
新しいコードの追加、拡張、バグの修正が、既存の機能を破壊したり、不安定さを引き起こしたりしていないこと、また、アプリケーションが仕様に従って動作していることを保証するためのテストです。
回帰テストは、実際の機能テストほど広範囲である必要はありませんが、機能が安定していることを確認するために十分なカバレッジを保証する必要があります。
統合テスト
システムが多くの機能モジュールに依存しており、個別には完全に動作したとしても、エンドツーエンドwのシナリオを達成するために一緒に接続した際に同時に動作するのかを検証しなければなりません。統合テストはそのようなシナリオの検証として知られています。
ベータ版/ユーザビリティテスト
製品やサービスをターゲットとしている代表的なユーザーにおいてテストし評価するプロセスは、ユーザビリティテストと呼ばれます。テストでは、多くの場合、参加者は典型的なタスクを完了しようとし、開発者は見たり、聞いたり、メモを取ったりすることを担当します。目的は、ユーザビリティの問題を特定し、定性的および定量的なデータを収集し、ソフトウェアに対する参加者の満足度を評価することです。これは、ユーザー受け入れテストに似ています。
お問い合わせください!
3. 機能テストと非機能テストの違い
機能テスト | 非機能テスト |
機能テストは、お客様から提供された機能仕様書を用いて、機能要件に対するシステムの妥当性を検証するために実施される | 非機能テストは、ソフトウェアシステムのパフォーマンス、信頼性、拡張性などの非機能を検証する |
機能テストは最初に実施される | 非機能テストは、通常、機能テストの後に実施される |
機能テストには、手動テストと自動化ツールの両方が使用できる | このようなテストには、ツールを使用するのが効果的である |
機能テストのインプットは、ビジネス要件である | 非機能テストのインプットは、速度や拡張性などのパフォーマンスパラメータである |
機能テストは、製品が何をするか説明する | 非機能テストは、製品がどのように機能するか説明する |
マニュアルテストが容易である | マニュアルテストが困難である |
機能テストの代表的な例:
|
非機能テストの代表的な例:
|
4. 機能テストの方法
Identify test input (test data) | テストインプット(テストデータ)の確認 |
Compute the expected outcomes with the selected test input values | 選択されたテスト入力値で期待される結果を計算する |
Execute test cases | テストケースの実行 |
Comparison of actual and computed expected result | 実際の結果と計算された期待値の比較 |
以下は、機能テストを実施するための手順です。
①機能要件を理解する
②要件に基づき、テストデータまたはテスト入力を確認する
③選択されたテスト入力値で期待される結果を計算する
④テストケースを実行する
⑤実際の結果と計算された期待値を比較する
5. 機能テストの手法
シナリオに基づき、コード品質の向上、パフォーマンスの最適化、および継続的デリバリーの確保を目的として、さまざまな手法が使用されます。これらは2つのカテゴリーに分けることができます。
Testing strategy and techniques | テストの戦略および手法 |
Positive testing | ポジティブテスト |
End user based tests (system tests) | エンドユーザーベーステスト(システムテスト) |
Decision tables | デシジョンテーブル |
Alternate path tests | オルタネートパステスト |
Negative testing | ネガティブテスト |
Equivalence tests | 同等性テスト |
Boundary value analysis | 境界値分析 |
Ad – hoc tests | アドホックテスト |
ポジティブテスト
ソフトウェアがエンドユーザーの必要最低限のニーズを満たし、正しく動作することを確認するテスト手法です。さらに3つのカテゴリーに分類されます。
- エンドユーザーベースのテスト:テスト対象のシステムは、組み合わせるとユーザーシナリオを実現する多数の構成要素を持っている場合があります。
例えば、顧客シナリオには、HRMSアプリケーションの読み込み、正しい認証情報の入力、ホームページへのアクセス、特定のアクションの実行、システムからのログアウトといったタスクが含まれます。このフローは、基本的なビジネスシナリオのために、エラーなく機能しなければなりません。
- オルタネートパステスト:このテストは、ある機能を達成するためにメインフロー以外に存在しうるすべての方法を検証するために実施されます。
- デシジョンベースのテスト:デシジョンベースのテストは、特定の条件が満たされたときにシステムが取り得る結果に基づき行われます。
与えられた上記のシナリオでは、次のようなデシジョンベースのテストがすぐに導き出されます。
- 不正な認証情報が入力された場合、システムはユーザに通知し、ログインページに再度読み込ませる必要があります。
- ユーザーが正しい認証情報を提供した場合、システムはユーザーを次のUIへと進めます。
- ユーザーが正しい認証情報を入力したが、ログインをキャンセルすることを決定した場合、システムはユーザーを次のUIに移動させず、ログインページを再度読み込む必要があります。
ネガティブテスト
ソースコードが常に変更されていたり、予期せぬデータの急増があっても、プログラムが期待通りに動作するかどうかを判断するテスト形態です。また、以下の3つのサブカテゴリーに分類されます。
- 境界値テスト:境界値テストは、アプリケーションにデータの限界を示し、どのように動作するかを検証します。その結果、境界値を超えて入力された場合、ネガティブテストとみなされます。例えば、ユーザーの最低文字数を6文字と境界の制限を設定した場合、ユーザーIDが6文字未満になるように書かれたテストは、境界値分析テストとなります。
- 同等性テスト:同等性パーティショニングでは、テストデータは同等データクラスと呼ばれる多くのパーティションに分けられます。各パーティションのデータは同じように振る舞う必要があるため、1つの条件のみをテストする必要があります。同様に、パーティション内の1つの条件が失敗すれば、他の条件はどれも動作しません。
たとえば、上記のシナリオでは、ユーザーIDのフィールドは最大10文字なので、10文字以上のデータを入力しても同じように動作するはずです。
- アドホックテスト:上記の手法でバグの大部分が発見されなかった場合、アドホックテストは先に観察されなかった矛盾を発見するための優れたアプローチとなります。これらは、システムを破壊し、それが素直に反応するかどうかを見るという考え方で実行されます。
例えば、次のようなテストケースがあります。あるユーザーがサインインしているが、管理者が何らかの操作を行っている最中にそのユーザーアカウントを削除してしまった場合。このような場合、アプリケーションはどのように対処するのか興味深いです。
6. 機能テストツール
今日のダイナミックなデジタル世界では、クオリティ・アット・スピードが重要であり、それを達成するためには適切なツールを選択することが肝心です。それでは、3つのツールの主な特徴を見ていきましょう。
Selenium(セレニウム)
広く使われている自動テストツールであり、手作業をなくし、フィードバックを加速させ、繰り返しテストを行うのに費やす時間を大幅に節約することができます。同じ前提条件と期待値で一貫性を持たせることができます。
主な特徴:
- マルチブラウザ対応
- マルチプラットフォーム対応
- クロスブラウザのテストに最適
- AppleとAndroidのドライバを使用したモバイルWebアプリケーションのテストに役に立つ
- 複数のプログラミング言語をサポート
- あらゆる種類の機能テストに対応
ユニファイド機能テスト(UFT)
回帰テストの実行に役立ちます。UFTスクリプトの作成に最も手間がかからないという理由で、新規アプリの初回テストに最適です。さらに、ビジネス・アーキテクチャ全体の機能テストを一元化し、手動および自動テストを効率化することができます。
主な特徴:
- 200以上の環境とアプリをサポートする技術スタック
- すべての主要なブラウザで実行可能
- 高速で安全なインストールプロセス
- GUI、API、ビジネスプロセスにおけるテストを1つの共通UIで実施可能
- 内蔵のオブジェクトリポジトリ
- スマートなオブジェクト検出と補正
- 画像ベースのオブジェクト認識
Soap UI
RESTful & SOAP APIの配信を加速するために設計されたこのオープンソースのテストツールは、Webサービステストのための最良の選択肢です。再利用可能なレコードテストにより、負荷テストを迅速かつ容易に行うことができます。機能テスト、パフォーマンステスト、回帰テスト、相互運用性テストなど、さまざまなテストを実行するために役立ちます。
主な特徴:
- ユーザーフレンドリーなGUI
- Groovyによる自動化
- スクリプト不要の機能テスト
- セキュリティおよび負荷テスト
- APIモッキング
- プロトコルサポート
- 活発なコミュニティ・エコシステム
CMC Japanが機能テスト会社として信頼される理由は?
ソフトウェアをテストせずに開発した場合、そのソフトウェアはビジネスの役に立たず、危険なものになる可能性があります。機能テストと非機能テストを組み合わせることで、ソフトウェアの目標達成を支援することができます。CMC Japanは、最新の技術でテストケースを作成し、分析するために、テストプロセス全体を円滑に進めることをお手伝い致します。
CMC Japanは、経験豊富なソフトウェア開発およびテスト会社として、またISTQBのプラチナパートナーとして、自動化ツールとテスト手法を適切に組み合わせた実証済みのフレームワークを活用し、優れたユーザー体験と機能の完全性を保証いたします。最終製品が期待通りの動作をすることをお約束します。