2024.11.07

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

著者株式会社SHIFT　マーケティンググループ

Introduction

ITシステムやソフトウェアを開発する際に、機能テストを十分に行って品質を担保する必要があります。そのためには、機能テストとはどのようなものなのか、どのような流れで行うのかなどを知っておく必要があるでしょう。

この記事では、機能テストの種類や作業の流れ、機能テストの自動化について解説します。

機能テストとは

機能テストとは、ITシステム開発やソフトウェア開発などで、機能が正常に動作することを確認するために必要な工程です。

ここでは、機能テストについて詳しくご説明します。

ある機能の実装が正しく動作することを検証するテスト

機能テストとは、ITシステムやソフトウェアなどを開発した際に、機能が正しく動作することを検証するためのテストです。

情報処理推進機構セキュリティーセンターの『暗号化鍵管理システム設計指針（基本編）』によると、以下のように定義されています。

機能テスト

機能テストとはある機能の実装が正しく動作することを検証するテスト

ECサイトを開発した際に、開発が終わってできあがったサイトをそのままリリースすることはありません。必ず実装した機能をすべて検証し、正しく動作することを機能テストで確認してから、リリースします。

画面が正しく表示されること、ログインできること、サイト内で正しく画面遷移すること、買い物を実行できることなど、すべての機能を確認していきます。どのような動作が行われても問題ないことを確認する必要があるため、網羅的なテストを行うことも重要です。

たとえば、一つの入力項目に対して、未入力、最大文字数の入力、すべての文字種の組み合わせを入力するといった網羅テストを行います。

このように機能テストでは、実装したすべての機能が正しく動作することを検証します。そうすることで品質を担保して、ユーザーのもとに届けることが可能です。

システム開発における機能テストの位置づけ

システム開発は、一般的に以下のような流れで進みます。

・要求分析
・要件定義
・基本設計
・詳細設計
・実装（コーディング）
・コンポーネントテスト（単体テスト）
・統合テスト（結合テスト）
・システムテスト（総合テスト）
・受け入れテスト（運用テスト）

テスト工程は、モジュールごとの単体テスト、モジュールを結合させた結合テスト、システム全体の総合テスト、顧客環境などでの受け入れテストと進んでいきます。その際に、テスト工程ごとの観点にあった機能テストを行っていきます。

非機能テストとの違い

機能テストとは別に、非機能テストがあります。

機能テストでは実装した機能をテストしますが、機能以外にもテストすべきことがあります。それは、パフォーマンス、負荷耐性、ユーザビリティ、セキュリティなどの非機能要件です。

たとえば「画面を表示してユーザーが文字を入力したら、データベースを検索してその結果を画面に表示する」というのは機能です。しかし、これらの機能が正しく動作するだけでは、不十分といえます。

以下のような不具合がある場合、リリースはできません。

・画面表示や検索結果までの時間がかかる
・大量のユーザーが使用したらシステムが落ちる
・画面が見づらくユーザーが使いづらい
・入力欄にSQL文を入力したらデータベースに不正にアクセスできてしまう

このような非機能要件をテストするのが、非機能テストです。機能として実装したものではないが、非機能要件として必要な基準を満たしているかを、非機能テストでテストします。

機能テストの種類

機能テストには、いくつかの種類があります。ここでは、機能テストの種類についてご説明します。

コンポーネントテスト

コンポーネントテストとは、単体テストとも呼ばれ、モジュール単体のテストを行うものです。実装後、最初に行うことが多く、モジュール単位で機能確認を行います。

コンポーネントテストについてはこちらもご覧ください。
＞＞コンポーネントテスト（単体テスト、ユニットテスト）とは？実施方法や重要性をわかりやすく解説のページへ

統合テスト

モジュール同士を結合させて、モジュールの連携テストを行うのが統合テスト（結合テスト）です。モジュール単体では不具合がなくても、モジュール連携部分がうまく機能していない場合、統合テストで不具合が見つかることがあります。

統合テスト（結合テスト）に関してはこちらもご覧ください。
＞＞結合テストとは？目的や観点・種類・単体テストとの違いを解説のページへ

システムテスト

システムテストは総合テストとも呼ばれ、ユーザーが利用するのと同じ状態でテストするものです。たとえば、ECサイトなら画面を表示してログインして買い物してみる、デスクトップアプリなどならインストールして機能を使ってみるなどがあげられます。

テスト工程でも最終的なテストで、このテストが問題なく終了すれば、機能的な品質が一定のレベルで担保されたと結論づけることが可能です。

システムテストに関してはこちらもご覧ください。
＞＞システムテスト（総合テスト）とは？その目的・観点・種類、実務で使える手順について解説のページへ

回帰テスト

回帰テストとは、リグレッションテストとも呼ばれ、機能追加やバグ修正を行った部分以外の機能が、問題なく動作することを確認するテストです。

たとえば、ある画面に入力項目を増やす機能追加を行ったとします。このとき、その画面の入力項目のテストだけを行えば問題ないとはいいきれません。その画面にあるほかの入力項目に今回の機能追加が影響して、バグが発生する可能性もあります。また、この入力項目を増やしたことで、データベースアクセス時にデータ不整合が起き、次にデータアクセスしたら問題が発生するなどもあり得ます。

このように、機能追加や変更を行った部分以外で発生することもあるため、追加変更部分以外の箇所をテストすることは重要です。ただし、スケジュールの問題で、回帰テストができない場合も多いです。そのため、ほかに影響を与えないことがわかっていれば、全体を通した疎通テストを一度行うだけで、終わりにすることもあります。

回帰テスト（リグレッションテスト）についてはこちらもご覧ください。
＞＞リグレッションテスト（回帰テスト）とは？目的や自動化のメリットを解説のページへ

受け入れテスト

受け入れテストとは、運用テストと呼ばれることもあり、顧客の環境下で行われるテストです。

ここまでのテストは開発環境でテストを行っており、どの環境下でも変わらない機能に関するテストでした。しかし、システムを実際に顧客が使用する商用環境に設定した際に、環境設定作業などにミスが発生することがあります。また、環境特有の違いによって、問題が発生することも考えられます。

顧客環境下でテストを行うことで、商用環境でも問題なく動作することを確認するのが、受け入れテストです。

受け入れテストに関してはこちらもご覧ください。
＞＞受け入れテスト（UAT）とは？実施方法や重要性をわかりやすく解説のページへ

機能テストを実施する流れ

機能テストの方法は、テスト対象や目指す品質、テスト方針や採用しているテストの指針などによって異なります。ここでは、一般的な機能テストの流れについてご説明します。

①テスト計画を立案する

テスト計画を立案し、全体のテスト件数の見積もり、タスクの洗い出し、スケジューリング、メンバーの割り当てなどを行います。

テスト計画についてはこちらもご覧ください。
＞＞テスト計画とは？目的や種類・作り方・注意点をわかりやすく解説のページへ

②テスト観点を抽出する

まずは、機能ごとにテスト観点を抽出します。テストする観点を切りわけて抽出していくことで、膨大な機能テストを漏れなく無駄なく実施することが可能です。

たとえば、ログイン画面にログインIDとパスワードを入力して、ログイン認証する機能を試験するとします。このとき、画面表示、入力項目、ボタン押下、認証の成功・失敗、画面遷移などの観点を抽出できます。このように観点をあげていくことで、確認漏れを防ぐことが可能です。

もし、観点を抽出せずに、ログイン画面でログインする流れを確認するだけで終わると、異なる文字種で入力した場合のエラー処理を確認できないかもしれません。画面表示に着目してテストすることもなく、画面バグを残したままリリースしてしまう可能性もあります。

テスト観点を抽出することで、膨大な数の確認項目を漏れなくあげることが可能です。

テスト観点についてはこちらもご覧ください
＞＞テスト観点とは？必要性や洗い出すための要素、つくり方を解説のページへ

③テスト項目を抽出し、テスト手順を作成する

テスト観点にしたがって、具体的な細かいテスト項目を抽出します。たとえば、○○画面でボタンを押下し、△△画面が表示することを確認、エビデンスは画面のスクリーンショットと操作ログで、確認箇所は○○などです。

テスト項目を抽出できたら、テスト手順を作成します。一連の画面操作を行うことで、いくつかの画面操作や、ボタン入力などに関するテスト項目を消化できることがあります。

たとえば、○○画面で△△を入力して「次画面へ」ボタンを押下、××画面へ遷移するなどのシナリオを作成した場合、○○画面の表示内容や入力項目、ボタン押下など複数のテスト項目を消化することが可能です。

このように、テスト手順を作成して対応するテスト項目を紐づけておくことで、スムーズにテストを消化できます。

④テストデータを作成し、テスト環境を構築する

テストを実施するためには、テストデータとテスト環境が必要です。

テストデータとは、ログインIDとパスワード、名前などを含むユーザーデータ、履歴データ、取引データなどです。テスト観点やテスト項目によって、必要なテストデータが異なります。たとえば、ログインIDが特定の文字種の場合のテストを行う場合、指定された文字種のログインIDで、ユーザーデータを作成しなければなりません。

また、テスト対象のシステムをテスト環境に設定し、適切な設定にしておく必要もあります。

⑤テストを実行する

ここまでの準備が完了したら、テストを実行します。作成したテストシナリオやテストデータを使用して、テストを消化していきます。

⑥結果を確認する

テスト結果が問題ないことを確認します。確認漏れやミスによりバグを見逃さないよう、テスト実施者が確認した後に、別の担当者がクロスチェックを行うことが多いです。

結果を確認してバグが見つかったら、開発担当者へすみやかに連絡します。開発担当者が内容を確認し、バグであることが判明したら、バグ発生箇所の特定、原因の特定、改修方法の検討、影響範囲の特定などを行います。現在、同時進行しているテストへの影響がある場合はストップし、影響がない別モジュールのテストなどはそのまま継続です。

バグ改修時に、テスト担当者は追加のテスト観点や項目を作成することもあります。また、バグ改修後のそのほか箇所への影響テスト、回帰テストについての検討も必要です。

バグ改修が終わったら、再テストします。

⑦データを保管する

テスト実施時の画面スクリーンショットや操作ログなどのエビデンス、チェックし終わったテスト項目表などのデータを適切に保管します。

これらのデータは、リリース後にバグが起こった際の検証などに使用することもあります。また、次の機能追加時や類似システムのテストなどに活用することも可能です。

機能テストの自動化について

機能テストでは、すべての機能を漏れなく確認する必要があるため、量が膨大です。そこで、機能テストを自動化することで、テストの効率化など多くのメリットを得られます。

ここでは、機能テストの自動化について解説します。

自動化のメリット

自動化することで、以下のようなメリットを得られます。

・テストの実行作業効率の向上
・リグレッションテストなど場合には、テストデータやテストシナリオ作成の漏れ・ミスを防止できる
・単純なテスト結果確認の場合には確認漏れ・ミスを防止できる
・単純なテスト結果確認の場合には確認精度のばらつきを防止できる

ただし、自動テストツールを導入することで、テスト作業全体の作業効率があがるとは一概にはいえません。

まず、自動テストツールを導入する際には、テストの実装に手動でテストするよりも3倍以上の工数がかかります。しかし一度実装してしまえば、あとはテストを実行するだけのため、担当者が帰宅後にテストを行うこともできます。テストの結果確認は、単純な確認項目なら自動化することで確認効率があがることもありますが、複雑な確認項目の場合には手動の方がかえって効率がよいでしょう。また、結果がNGだった場合、もう一度手動でテストを実行して確認する手間がかかります。

このように、テストの自動化で効率がアップするのは主にテストの実行フェーズのみで、実装、確認作業では効率があがるどころか下がるケースも多いです。

一方で、テストを一度自動化しておけば、今後の機能追加時などでリグレッションテストがいつでもできるようになるというメリットもあります。また、開発と並行してテストの自動化の実装を進めておけばテスト開始後のテスト作業効率をあげることも可能です。

自動化の課題

テストを自動化できるのは機械的なテストで、たとえば画面表示確認、入力確認、画面遷移確認などです。特殊な確認観点や操作を行うテストは、人間が行う必要があるでしょう。

また、ツールによるテストに、漏れやミスが絶対にないとはいいきれません。ツールにバグがある場合、エラーが起きて正しく確認できていない場合なども考えられます。

このように、テストの自動化にはさまざまな課題が残されているため、人間の目によるチェックも行う必要があるでしょう。

テスト計画書テンプレート

テスト計画はソフトウェアテストにおける最初の工程にあたり、何をどのようにテストをするかといったソフトウェアテストの全体像を示した全体テスト計画書と、それをインプットにした個別テスト計画書のドキュメントを作成します。

本テンプレートは、全体テスト計画書作成のためのテンプレートです。
SHIFTが実際のプロジェクトで使用している計画書を初心者にも扱いやすいようシンプルな構成にまとめ、各項目に記述すべき内容と補足説明を記載しております。ぜひ、テスト計画書作成業務にご活用ください。

また、下記コラムにて、テスト計画の中でも特にプロジェクトによって内容が大きく変わる、テスト戦略(「テスト対象」「テストの範囲」「アプローチ」)にフォーカスし、記述方法、考え方について詳しく解説していますので、合わせてご覧ください。
（コラム）テスト戦略～テスト計画プロセスにおけるテスト戦略の考え方～

ダウンロード

まとめ

この記事では、機能テストについて、その種類や作業の流れ、機能テストの自動化について解説しました。

機能テストでは、すべての機能を網羅的に確認する必要があり、工数が膨大なものに膨らむことが多いです。そこで、いかに効率よく必要なテストを行って、品質を担保するか検討しなければなりません。

SHIFTでは、豊富なテストに関するノウハウを活かして、高品質なソフトウェアテスト・第三者検証サービスをご提供しています。質の高いテストを実施したい場合は、お気軽にご相談ください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

ソフトウェアテストの悩みはSHIFTが解決できます！

「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」

といった悩みを抱えている企業は多いでしょう。

質の高いソフトウェアテストを効率よく行うためには、多くの知識や経験が必要です。社内に経験豊富なIT人材が不足していると、質の高いテストを実施するのがむずかしく、かといって一からIT人材を集めるためには膨大な時間とコストがかかってしまいます。

そのような悩みは、SHIFTのソフトウェアテスト・第三者検証のサービスを利用いただくことで解決できます。

＼おすすめの資料／　※すべて無料でダウンロードいただけます。
・3分で知るSHIFTのテストサービス
・テスト効率が大幅アップ、人手不足解消の切り札に＜理由＆メリット＞
・ソフトウェアテストを外注すべき5つの理由とは！？
・サービス導入事例集

これまで導入いただいた企業様は3,000社以上。その豊富な専門知識と経験を活かして、高品質のソフトウェアテストを効率よく行い、開発のサポートをいたします。

ぜひSHIFTのソフトウェアテスト・第三者検証をご利用ください。

ご相談はこちらから。
＞＞お問い合わせ
＞＞料金について

引用元：

情報処理推進機構セキュリティーセンター｜暗号化鍵管理システム設計指針（基本編）

監修

株式会社SHIFT
「ヒンシツ大学」クオリティエヴァンジェリスト　永井敏隆

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

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

Introduction