非機能試験で実施するべき内容をまとめましたので利用してください。
この記事は企業向けのシステム構築時に私ならこの項目は試験するな～という項目をまとめたものです。
元の考え方は、「IPAのエンタプライズ系事業/非機能要求グレード」、
「RASIS」を私なりに解釈し、まとめたものです。
要件定義に合わせて、試験項目の追加・削除を行ってください。
この記事は随時更新されていきますので、コメント頂ければ幸いです。
非機能試験とは何か？
非機能試験とは、信頼性や可用性などなど，機能要件以外のものを指します。
信頼性やセキュリティのように要件定義の中に入っているものもありますが、
運用要件などが無い場合も多いです。
非機能試験は、ざっくりプロジェクトのスコープに入っていることがあり、プロジェクト工数がないと真っ先に切り落とされるだろう。
しかしそこはエンジニアの腕の見せところです。
しっかりと非機能試験も実施したいです。
非機能要件＝非機能試験とかんがえてよいが、意外と非機能要件は要件定義されていないケースがほとんどです。
私個人の意見だが、機能要件から非機能要件をすくい出す必要があると考えています。
ここら辺は経験値的なところが求められるかと思いますので、とにかく数をこなすことがよいと思います。
信頼性試験
まずは信頼性試験です。アプリ開発者には馴染みはあまりないと思いますが、インフラエンジニアはマストな知識でしょう。
バックアップ&リカバリー試験
最も基本であるバックアップとリカバリー試験です。
バックアップだけして満足せず、リカバリーできるかも試験する必要があります。
また「バックアップまでにかかる時間」と「リカバリーに掛かる時間」もしっかりと試験することをお勧めします。
監視試験
監視がしっかりと行われているかの確認するのが、監視試験です。
まず要件定義で定義されていないのが監視要件です。
監視が行われているかの確認だけでなく、異常検知の時間も試験する必要があります。
異常検知が異常に遅いと、それだけ2重、3重障害につながります。
性能試験
性能試験もとても重要な試験です。そのため要件定義の中に記載されていることがほとんどです。
例として、「○秒以内にリクエストが返ってくること」、「△△ユーザ同時に利用できること」などが要件定義書には書いてあるでしょう。
さて性能試験ですが、2つの観点があります。
それは「レスポンス」と「スループット」です。 必ず2つの観点で試験をすることを強くオススメします。
負荷(ストレス)試験
負荷試験も要件定義書の中に記載されていないことがほとんどです。
システムが予想外に高負荷になった場合に、
システムとして要件を担保できるか？、高負荷時にどのような挙動になるか？
普通のエンジニアは気にしません。
出来るエンジニアになるために頭の片隅に負荷試験のことを置いておきましょう。
可用性試験
可用性とはシステムがどれだけ正常に使えるかを現した指標になります。
重要なシステム・大規模なシステムほど可用性の要件があります。
可用性はMTTR（平均故障間隔：Mean Time Between Failure）とMTBF（平均修理時間：Mean Time To Recovery）で稼働率を出し、
明確に指標が決まっていますので、それを実現するためにどのようなアーキテクチャを採用するかがエンジニアの腕の見せ所になります。
高可用性試験
高可用性試験とは、冗長化したシステムの1つが停止しても正常にシステム稼働を継続できるか？
を確認する試験になります。
コールドスタンバイ、ホットスタンバイ、Actiove/Active（複数で負荷分散した）などシステム構成によって試験する観点は違ってきます。
基本はシステムが継続できることを試験することがメインになります。
要件の中に正常な状態に残るまでの時間を定義されている場合は、高可用性試験の中に復旧時間がクリアできていることの試験も必要になります。
耐障害試験
耐障害試験とは、各障害発生ポイントに障害が発生した場合に、その他の機能でシステムが稼働できるかを確認する試験です。
耐障害試験ですが、高可用性試験と棲み分けが難しいですので、しっかり定義する必要があります。
私のイメージですが、
- 高可用性試験はシステム全体が正常に稼働し続けること、直ぐに復旧するかを確認する試験
- 耐障害試験は1つ1つの機器・コンポーネントが故障時に正常に動作するかを確認する試験
だと考えています。
災害対策試験
災害対策試験とは、災害時に対策サイトにシステムが切り替わること、災害対策だけになってもシステムが継続できることを確認する試験です。
大規模かつ重要度が高いシステムでは、災害対策サイトとして別の地域にシステムを構成するケースがあります。
仮にメインサイトが全損したとしてもシステムが継続できることが災害対策の重要性になります。
ただ災害対策試験は2サイト用意して試験をするためコストもかかります。
またサイト全体をダウンさせるため事前の調整が必要なります。
運用試験
運用試験とはシステム完成後に正常な使い方が出来るのか？を確認する試験になります。
運用試験は最終試験の位置づけも強いので試験仕様はきちんと固めて実施すべき試験です。
通常運用試験
通常運用試験とは、通常の業務や運用が正常に行ることを確認する試験になります。
- アプリ担当であればエンドユーザが使用する以外の機能の試験
- インフラ担当であれば運用フローや運用手順が正常に行えることを試験
と観点が微妙に違うため、しっかりと試験仕様を見極める必要があります。
障害時運用試験
障害時運用試験は、障害発生時にどのような報告フローを行うか、一時切り分けを行うかを試験します。
障害対応は、一時切り分けと恒久対策にわかれますので、必要に応じで障害シナリオを作成して、
正常に障害時に業務がまわるかを確認するのも試験になります。
ユーザビリティ試験
ユーザビリティ試験とは、実際にユーザーにシステムを試してもらう試験になります。
ユーザーたちが実際にどのようにシステムを扱うか」という直接的な知見が得られる。
この試験はプロトタイプを何度もぶつけて、手戻りを少なくすることをオススメします。
試験を最後の一回だけしてユーザビリティ試験実施者が、「使いにくい」と言われるとやり直しになる影響が大きくなります。
セキュリティ試験
昨今は要件の中にも明確にセキュリティ要件が入ってきています。
セキュリティ試験はとっつきにくい部分がありますが、しっかりと説明していきたいと思います。
セキュリティ機能試験
セキュリティ機能が正常に使用出来ていることを確認する試験になります。
非機能試験なのに機能試験？と思う人もいると思いますが、大きいシステム試験全体の中で考えれば、
セキュリティは非機能試験部分になります。
セキュリティの小項目は、「データが暗号化されていること」、
「正しいアクセスパスが利用できること」、「不正検知、監査ができること」など多岐にわたるため注意が必要です。
セキュリティリスク管理試験
脅威やセキュリティインシデントは年々進化しています。
セキュリティリスク管理を確認するためには、
- セキュリティインシデントが発生したらどのようなフローで報告するか
- セキュリティインシデントが発生しないようにどのようにサイクルを回していくか
をしっかり確認し試験してみることは重要になります。
まとめ
非機能試験は機能要件と違いユーザーから明確に要件が出てこない場合がほとんどです。
そこはプロなのでユーザーから明示的な要求がなくても、非機能要件について達成水準を定義して（承認を得たうえで）テストを行いましょう。
