非機能テストとは？テストの観点や目的、必要性について解説
システムやソフトウェアのテスト段階において、仕様書通りに動作するか、未発見のバグや課題はないかをテストすることは非常に重要です。
このテストにおいて、
「開発段階から仕様書などで明確に定義されている機能要件」
についてはテストを進めやすいです。
しかし、それ以外の部分、つまり非機能要件のテストは実行しにくいのが現実です。
非機能要件をテストすることを「非機能テスト」と呼び、製品のユーザーレビューに大きく作用する大切な要素です。
現在ではISOが非機能要件の国際規格として「ISO/IEC9126」を発表したこともあり、非機能テストの内容が明確になり、重要性の認知も進んでいます。
この記事では、そもそも非機能テストが何か、なぜテストを実行する必要があるのかなどを解説します。
また、非機能テストの観点や、非機能テストの具体例についても、合わせて紹介しています。
非機能テストとは
まずは、非機能テストについて、理解のために重要な「非機能要件」と、機能要件との違いも合わせて解説します。
「非機能要件」とは
ソフトウェアのコアとして、動作を定義するものを「機能要件」と呼びます。
例えば
・ユーザー認証：ユーザーがアカウントにログインし、個人情報やプライバシーを保護するための認証機能
・データベース管理：システムが大量のデータを処理し、効率的に管理するためのデータベース管理機能
・検索機能：ユーザーが特定の情報を簡単に見つけるための検索機能
等が挙げられます。
本来そのシステムで必要とされる機能と、その詳細な仕様についての内容が主です。
それに対して非機能要件は、ソフトウェアにおける機能要件以外のすべてを指します。
システム構築やソフトウェア開発において、「どのように動作するか」を決めるのが、非機能要件です。
具体的には、
「多数のユーザーが同時にアクセスしても正常に動作するか」
「情報漏洩などの脆弱性はないか」
といった、システムやソフトウェアの動作に関する要望が該当します。
非機能要件は、機能要件のように仕様書に明記されているものではないことが多いため、開発の際にはテスト観点の洗い出しをはじめ、入念なテストを実施するなどの注意が必要です。
機能要件と非機能要件との違い
ここで、機能要件と非機能要件の違いをもう少しみていきましょう。
一言でいうと、機能要件は「何をするか」で、非機能要件は「どう動くか」という違いがあります。
機能要件は、システムやソフトウェアの開発において、盛り込むべき機能をまとめたものです。
具体的には
「IDと情報を紐付けて検索できるように」
「必要な画像を画面に並べて表示したい」
など、開発のコアとなる部分です。
対して非機能要件は、システムやソフトウェアの利便性や安全性に関わる部分です。
以前は機能要件が開発における最重要のトピックでしたが、システムやソフトウェアの需要が変化したことによって、非機能要件の重要性がより注目されるようになりました。
非機能テスト
「非機能テスト」とは、その名の通り、開発におけるテスト段階において、非機能要件を満たしているかをテストすることです。
仕様書などで明確な要件定義がなされている機能テストとは異なり、非機能テストは、ソフトウェアに求められるさまざまな非機能要件をひとつひとつ決めて、手だてを考えなければなりません。
一般的に、非機能テストの対象となるのは、システムテストと受け入れテストですが、場合によっては、単体テストや結合テストをおこなうこともあります。
非機能テストの具体的な項目は、国際規格であるISO/IEC9126が定めており、そこには
「機能性・信頼性・使用性・効率性・保守性・移植性」
の6項目があります。
これらの要素を満たすため、ストレステストや性能テストなどの手法を用いて、ソフトウェアの非機能要件をテストしていきます。
非機能テストはなぜ必要？
これまでは機能テストほど重視されなかった非機能テストですが、なぜその必要性が注目されるようになったのでしょうか。
従来は、テストといえばバグの修正などにフォーカスした機能テストが主で、ユーザーの使いやすさについてはそれほど注目されていませんでした。
この傾向は、企業どうしの開発競争によるテストの圧迫でさらに極端になりました。
また非機能要件の軽視は、ユーザーの利便性を損なうだけでなく、思わぬバグの発生にも繋がります。
その結果として、ユーザーからのクレームやクライアントとのトラブルに発展してしまいます。
こうした背景を受け、ISOが国際規格である「ISO/IEC9126」を発表し、これをきっかけに、多くの開発現場で非機能要件および非機能テストの重要性に注目されるようになりました。
非機能テストの観点
非機能テストは、ISOが定める6項目の非機能要件から、さまざまな視点を立てて実施します。
実際の非機能テストは、ソフトウェアの動作以外のすべてを対象とするため、実行されるテストは多岐にわたります。
ここでは、主要な非機能テストの手法・観点を解説します。
ストレステスト
ストレステストでは、システムやソフトウェアが、想定される負荷に耐えられるのかを確かめます。
集中的なアクセスや大量のデータ量が発生しても、ソフトウェアが仕様書通りに動作するか、システムがダウンしないかどうかをチェックします。
ここでテストされる過剰負荷は、実際には起こりにくいがゆえに、バッファオーバーフローなどのバグが隠されていることが多く、専用のソフトウェアを用いて入念にテストする必要があります。
ストレステストと関連して、製品に大容量データを付加した上で動作を確かめる
「ボリュームテスト」
や、短時間で大量の処理を受け付けた場合の動作を検証する
「高頻度テスト」、
システムを長時間稼働させた際に障害が発生しないかをテストする
「累積稼働テスト」
なども、想定される環境によって、非機能テストでおこなわれます。
性能テスト
性能テストは、システムやソフトウェアを、想定される環境で実際に使用することで、仕様書通りに動作するかチェックします。
ここでは、ソフトウェアの応答速度やデータ消費量などが仕様書通りであるか、ユーザーが快適に利用できるかといった、製品のパフォーマンスをテストします。
この工程でストレステストも合わせておこなうこともあります。
特に近年は、データベースで扱うデータ量も増えてきていますし、様々なサードパーティ製品を活用するシステムも増えています。
多機能・高機能にも関わらず、処理が遅いなどになれば、ユーザー満足度が下がってしまう危険性があるため、こういった性能テストも重要なのです。
ユーザビリティテスト
ソフトウェアがユーザーにとって利用しやすいデザインになっているかをチェックすることを、ユーザビリティテストと呼びます。
ユーザーの立場に立って、直観的に操作できるか、やりたい操作をスムーズにおこなえるかといった視点でテストを進めます。
単純なアイコンの配置から、画面遷移の順番など、非常に幅広い内容が該当します。
保守性テスト
保守性テストでは、ソフトウェアを長期的に稼働していくことを想定したテストをおこないます。
ここでは、運用・保守をするうえで、不具合が発生した際に発見できるか、修復作業が容易におこなえるかなどをテストします。
また、ソフトウェアの性質によっては、追加機能などの拡張性についても合わせてチェックします。
障害対応テスト
実際に稼働を続けるシステムやソフトウェアは、どこかで障害が発生します。
そのため、システムトラブルによる影響についても注目する必要があります。
「障害対応テスト」では、システムに障害が発生した際、その影響を最小限に留めることができるか、適切な対応がとれるかをチェックします。
セキュリティテスト
セキュリティテストでは、外部からの攻撃に対して、システムやソフトウェアが十分なセキュリティを維持できるかをテストします。
サイバー攻撃に対する脆弱性がないか、保護すべき情報が流出する危険性がないかなどを、想定されるサイバー攻撃を実際におこなうことでチェックします。
ソフトウェアの安定性を保ちつつ、情報を守るセキュリティ対策が求められます。
非機能テストの具体例
ここからは、非機能テストの具体例として、実際におこなわれた非機能テストの事例を紹介します。
なお、通常これらの非機能テストは、仕様書によって定義された非機能要件が満たされているかを、専門のソフトウェアを活用しておこないます。
メッセージ通知システムへのストレステスト
配信サービスにおいて、ユーザーへのメッセージ通知をおこなうシステムに対して、ユーザー数に応じたストレステストをおこないました。
ここでは、システムが通知を送る対象となるユーザーの規模が広がるにつれて、どれくらいのタイムラグが生じるのかが焦点となります。
テストはブラックボックスでキャッシュの状態を見ながら、運用が想定される環境でおこなわれました。
その結果、システムの耐久負荷が仕様書で定められた指標を満たしていないことが判明し、システム修正が必要と判断されたのです。
流通業界におけるPOSシステムの累積稼働テスト
製品の販売情報をリアルタイムで記録する大規模なPOSシステムは、実際にシステムを運用する環境上、長時間動作させ続ける必要があります。
そこで、システムを長時間稼働しても問題がないか、システムの安定性の観点から累積稼働テストを中心に、デモ環境において非機能テストが実施されました。
その結果、プログラムがリソースを開放しない、データベースがデッドロックされるなどといった問題が判明。
対策を施すことで、システムの安定性を向上し、また運用コストを削減することができたのです。
専門機器のユーザビリティテスト
専門性が高いゆえにこれまでユーザビリティを考慮してこなかった計測機器メーカーが、競合他社との差別化を図るために、自社製品のユーザビリティテストを実施しました。
これによって計器の視認性の低さをはじめとする、システム上の利用効率を下げる要因が多数発見されました。
外部企業に委託した非機能テストであったため、ユーザーインターフェースについて多くの指摘が集まり、それらを開発に盛り込むことで、高いユーザビリティを持つ製品を実現したのです。
安全性の高いシステム開発はAMELAに
今回は、非機能テストについて見てきました。
様々なシステムが開発されていますが、その品質は開発する企業によって様々です。
特に、ただ安いだけの企業の場合には、人件費を削って、無理な納期での開発が行われることがあります。
そうなると、実際の開発以外の部分の
・設計書の作成
・テスト項目の作成
・ドキュメント類の作成
などの工数を減らす必要性が出てきます。
結果、開発時点では安かったとしても、その後大きなバグが見つかるなど、運用保守で大きな費用がかかる可能性があります。
そうならないためにも、安いだけではなく「妥当性のある工数」の企業に依頼する必要性があるのです。
AMELAでは、オフショア開発によって
「金額的には一般的な開発よりも安いけれど、しっかりと工数を取って安全な開発を行う」
ことが可能です。
是非一度、現在のビジネスの悩みなどを相談いただければと思います。
