機能テストとは？種類や実施手順、非機能テストとの違いを解説

ソフトウェアが仕様通りに動作するかを検証する機能テスト。品質保証の重要な工程である一方で、種類や実施方法について体系的に理解できていないという方も多いのではないでしょうか。

本記事では、機能テストの定義や種類、実施手順、非機能テストとの違いなどを解説します。

第三者検証の重要性｜資料ダウンロード

機能テストとは

ソフトウェアの品質を確保するうえで基礎となる機能テスト。まずは、その定義や目的について解説します。

定義と目的

機能テストとは、ソフトウェアが仕様通りに動作するかを検証するテストです。このテストでは、実際の利用シーンにおける操作や処理を想定し、入力に対して期待通りの出力が得られるかを確認します。

例えば、ECサイトであれば「商品をカートに追加できるか」「決済処理が正常に完了するか」、業務システムであれば「顧客情報を正しく登録できるか」「売り上げデータが正確に集計されるか」といった内容が検証の対象となります。

プログラムの内部構造を意識せず、仕様書や要件定義に基づいて実施されるため、ブラックボックステストの一種として位置付けられます。

機能テストと非機能テストの違い

機能テストの対となる概念が「非機能テスト」です。両者の違いは以下のように整理できます。

機能テスト

機能そのもの（機能要件）を検証するテスト。システムが正しく機能するかを確かめる

非機能テスト

性能、セキュリティ、使いやすさなどの非機能要件を検証するテスト。システムの質が十分かを確かめる

機能テストで「正しく動くか」を、非機能テストで「快適かつ安全に使えるか」をそれぞれ検証することで、総合的に品質の高いプロダクトを実現できます。

項目	機能テスト	非機能テスト
検証対象	機能要件（入出力の正しさ）	非機能要件（性能、セキュリティ、使いやすさなど）
テストの目的	「正しく動くか」を検証	「快適かつ安全に使えるか」を検証
検証内容の例	・ログイン機能が動作するか ・検索機能で正しい結果が返されるか ・決済機能が正常に処理されるか	・1,000人が同時アクセスしても応答速度が遅くならないか（負荷テスト） ・不正アクセスやサイバー攻撃に対する脆弱性がないか（セキュリティテスト） ・ユーザーが迷わず操作できるか（ユーザビリティテスト）

工程ごとの機能テストの実施内容

機能テストは、テストの各工程で段階的に行われます。ここでは、工程別の機能テストの実施内容について解説します。

単体テスト

「単体テスト」は、個々の関数やモジュール単位での動作確認を行うテストです。すべてのテストのなかで最も基礎となる工程で、主に開発者自身によって実施されます。

【検証内容の例】

• 金額計算関数に正しい数値を入力したときに、期待通りの計算結果が返されるか
• 入力バリデーション関数に不正な形式のメールアドレスを渡したときに、エラーが返されるか

関連記事：単体テスト・ユニットテストとは｜その目的や手法を解説

結合テスト

「結合テスト」は、複数モジュールが連携したときの動作を検証するテストです。

単体テストでは問題なく動作した機能でも、ほかの機能と組み合わせたときに不具合が発生する場合は少なくありません。そのため、プロダクトの実用性を保証するためには、結合テストの実施が不可欠となります。

【検証内容の例】

• 会員登録を行ったときに、自動送信メールが送信されるか
• 決済を実行した際に、データベース上で在庫の残数が変動するか

関連記事：結合テストとは｜その意味や目的、種類、実施方式などを紹介

システムテスト／受け入れテスト

「システムテスト」は本番環境に近い状態でシステム全体の動作を検証するテスト、一方の「受け入れテスト」は顧客環境での最終確認を行い、ユーザー視点での要件充足を検証するテストです。

いずれも開発終盤に実施する“仕上げ”のようなテストであり、リリース後の不具合発覚を防止するための重要な工程です。なお、システムテスト（場合によって受け入れテストも）には、非機能テストの側面もあり、性能や可用性といった非機能要件も検証対象となります。

関連記事：システムテスト・総合テストとは｜目的や観点、手法を紹介

機能テストとして実施される主な手法・テストタイプ

ここでは、機能テストとして実施されることの多い主なテスト手法・テストタイプを解説します。プログラムの追加・修正があるたびに変更部分や関連部分をテストすることで、問題の早期発見につながります。

※以下のテストは、非機能テストとして実施される場合もあります。

スモークテスト

「スモークテスト」はプログラムの追加・修正後に行う動作確認であり、主要機能に致命的な不具合がないかを簡易的にチェックします。テストチームの作業に移る前の最低限の確認として、開発チームで行われることが一般的です。

特にDevOpsなどのサイクルの早い開発手法では、頻繁な更新で生じる不具合を速やかに発見してテストを効率化するため、スモークテストが重視されます。

【検証内容の例】

• アプリケーションが起動するか
• ログイン画面が表示されるか
• 主要な画面遷移が実行されるか

健全性テスト

「健全性テスト」は、特定の変更箇所とその周辺機能に焦点を当てたテストです。バグ修正や新機能追加後に、関連機能に悪影響がないかを確認します。スモークテストがシステム全体を浅く広くチェックするのに対し、健全性テストは特定範囲を狭く深く検証するのが特徴です。

【検証内容の例】

• 決済機能の修正後、決済プロセスが正常に完了するか
• 商品検索のアルゴリズムを改善後、検索結果の表示、並び替え、フィルタリング機能が期待通りに動作するか

回帰テスト

「回帰テスト」は、機能追加やバグ修正後に、既存機能が正常に動作するかを検証するテストです。変更箇所とは直接関係のない機能も対象に含まれ、健全性テストよりもさらに広範囲をカバーしつつ、スモークテストよりも詳細な確認を行います。

【検証内容の例】

• ログイン機能の改修後、会員登録、パスワードリセット、ログアウトなどの関連機能が正常に動作するか
• 新しい決済方法を追加した後、既存の決済方法（クレジットカード、銀行振込など）が引き続き正常に動作するか

実行するテストケース数が多く、頻度も高くなる傾向があるため、自動化が推進されやすい領域です。

機能テストの実施手順

機能テストを首尾よく実施するためには、優先順位に基づいた計画や実運用に近い条件の整備が重要です。

ここでは、機能テストの実施手順を6つのステップに分けて解説します。

1. テスト計画の立案

はじめに、テスト計画として次のような項目を検討します。

• テスト範囲・優先順位
• 実施期間
• 担当者
• 使用するツール・環境

限られたリソースのなかですべての機能をテストすることは現実的ではないため、ユーザーへの影響度やビジネス上の重要度などに基づき、テストの優先順位を定めます。ユーザーの金銭や生命に関わる処理や利用頻度の高い基幹機能を優先するなど、リスクベースで優先順位付けしていく手法が一般的です。

2. テスト観点・項目の抽出

テスト計画に基づき、具体的に「何を確認すべきか」を洗い出します。仕様書・要件定義を読み込み、「この機能はどのような入力を受け付けるべきか」「どのような条件でエラーになるべきか」といった観点を整理します。

開発者の意図通りの入出力が動作するか（正常系）だけでなく、不正な入力や異常な環境下での操作を受けて適切なエラーハンドリングが行われるか（異常系）の確認も重要です。仕様書に明記された事項だけでなく、ユーザーの操作内容や利用シーンを多様な角度から検討することで、テストの網羅性を高めることができます。

3. テストケースの作成

抽出したテスト観点をもとに、テストケースを作成します。誰が実行しても同じ結果が得られるように、入力内容や期待される結果、操作手順を明確に記述することがポイントです。

例えば、ECサイトのログイン機能のケースは次のように作成します。

• テスト対象：ログイン機能
• テスト観点：正常系（正しい認証情報）
• 実行手順
  • 1. ログイン画面を開く
  • 2. 正しいIDとパスワードを入力
  • 3. ログインボタンをクリック
• 期待結果：ログインに成功し、マイページが表示される

テストケースの作成後は、別のテストエンジニアや開発チームなどの第三者によるレビューを行うことで、抜け漏れや曖昧さのない設計につながります。

4. テスト環境の構築・データ準備

テストの精度を高めるためには、可能な限り実運用に近い条件下でテストを実行することが重要です。OSやミドルウェア、ネットワーク環境などを本番環境に近づけることで、「テストでは問題なく動いたが、本番稼働時に応答速度が極端に遅くなった」といったトラブルの回避につながります。

また、実際の利用イメージに近いテストデータの用意も重要です。例として、人名データを用意する際は「漢字2文字+漢字2文字」「漢字2文字+平仮名3文字」のように実際の人名でありうるパターンを網羅することで、文字種類や文字数によってエラーが起こらないかなどを厳密に検証できます。

5. テストの実行と結果確認

準備が整ったら、計画に沿ってテストを実行します。

仕様通りの結果が得られたかを確認し、問題を発見した際は、その際の手順や処理のログ、影響範囲、重要度を記録します。開発チームの円滑な修正を助けるため、客観性の高い記述を意識するとよいでしょう。

6. テストデータの保管と次回の準備

テスト終了後は、実施日時、担当者、合否判定などを記録し、品質保証プロセスの可視化やプロジェクトの振り返りに活かします。

また、次回以降のテスト設計に向けて、テストケースやスクリプトを再利用可能な形で保管することも重要です。特に回帰テストなどでは同じテストケースを繰り返し実施することが多いため、次も使いやすいように整理しておくことで、品質保証体制の長期的な強化につながります。

機能テストで品質を確保するために

「入出力が正しく動作するか」を検証するテストは、品質保証の基礎となる工程です。適切な機能テストを実施することで、リリース前に不具合を発見し、満足度の高いプロダクトを提供できます。

効果的な機能テストの実施には、実運用を想定したテスト観点の洗い出しや、有限なリソースを有効活用するテスト計画が欠かせません。計画・設計のプロセスに不安がある場合は、専門的な知見を持つ第三者機関との協業も有効な選択肢となります。

AGESTのソフトウェアテストサービスでは、機能テストの設計から実施、改善計画まで一気通貫でサポートを提供しています。豊富な実績を持つテストエンジニアが、お客様の状況や課題に適切な助言を行い、長期的な内製化の支援まで行います。

品質保証体制の見直しを検討されている方は、ぜひ一度ご相談ください。

ソフトウェアテスト サービス詳細ページ

TFACT (AIテストツール)

関連コンテンツ