ITが社会の維持に欠かせない日本にとって、ソフトウェアと「信頼性」は切り離せません。ソフトウェアには、異常な状況であっても故障することなく適切に振る舞うことが求められます。しかしながら、ソフトウェアの多機能化やサイバー攻撃の増加によって、その信頼性は揺らいでいるのが現実です。

マイナンバーカード関連システムの不具合など、ソフトウェアの品質問題が取り上げられることは今や珍しくありません。品質問題は日本社会の混乱を招くばかりか、開発者の信頼性を損なう重大なリスクとなります。こうした中で、ソフトウェア開発における「異常系テスト」の重要性が高まっています。

ただし、異常系テストの実施には課題が少なくありません。信頼のおけるソフトウェアを開発するためには、異常系テストに関する理解を深め、実現に向けた解決策を知ることが肝要です。そこで今回のADOC TESLABブログでは、異常系テストに関してシリーズで分かりやすく解説。第1回となる本記事では、異常系テストの基礎知識と重要性について整理します。

異常系テストとは

まず、異常系テストの基礎知識について解説します。異常系テストとは何か、その定義や目的を明確にすることが最初のステップとして不可欠です。

異常系テストの定義

異常系テストとは、本来の仕様から外れた状況や正常に処理が完了しない条件下におけるソフトウェアの動作や性能を検証するテストです。不正な入力データを与える、動作条件を満たさない環境を作り出すなど、文字通り「異常」な状況に焦点を当ててテストを行います。

ただし、ソフトウェアが本来持つ機能を提供できるかどうかを検証するわけではありません。異常系テストでは、ソフトウェアが異常な状況においても致命的な挙動（システムダウンや情報漏洩など）を起こさず、適切に振る舞うことを検証します。

異常系テストの目的

異常系テストの大きな目的は、ソフトウェアの信頼性を保証することにあります。異常な状況において甚大な被害をもたらすようなソフトウェアは、信頼性が高いとは言えません。通常機能の提供が不可能な状況下でも適切に振る舞うかどうかを検証することが、ソフトウェアの信頼性向上につながります。

仕様通りの機能を提供することは、ソフトウェアにとって「義務」とも言える品質要求です。一方で、仕様から外れた環境下における動作や性能は「努力目標」のように扱われることが少なくありません。しかし現実として、品質問題の多くは仕様から逸脱した状況において発生しています。

ソフトウェアの信頼を低下させる、こうしたリスクを検出する役割を果たすものが異常系テストです。異常な状況をテストケースに落とし込むことで、品質問題により生じるさまざまな問題を防ぐことができます。

正常系・準正常系・異常系の違い

異常系テストのほかに、「正常系テスト」「準正常系テスト」が存在します。これらの大まかな違いは下表の通りです。なお、「入力金額の税込価格を表示する」という機能を例に記載しています。

正常系テストは、本来の機能が正しく提供できる正常な状況における振る舞いを検証するものです。一方、準正常系テストおよび異常系テストは、本来の機能が提供できない異常な状況における振る舞いを検証します。

「数値以外が入力された際にはエラーメッセージを表示する」など、仕様で異常処理が規定されている場合、それは準正常系テストです。こうした異常処理が規定されないものが異常系テストとなります。

ただし、いずれも異常な状況における振る舞いを検証するという点は変わりません。そのため本記事では、準正常系テスト・異常系テストを総称して「異常系テスト」として論じます。

異常系テストケースの実施漏れによるリスク：4事例に学ぶ重要性

冒頭で述べた通り、昨今では異常系テストの重要性が高まっています。異常系テストケースの実施漏れにより、さまざまなリスクが現実に顕在化しているためです。ここでは4事例とともに、十分な異常系テストを実施することの重要性をお伝えします。

情報漏えい：申請システムの表示不具合

助成金の申請システムにおいて表示不具合があり、企業や個人の情報漏えいを引き起こしました。申請途中でブラウザ機能により前のページへ戻った場合、特定事業者の情報が表示されてしまうのです。不意のページ遷移をともなう異常系テストケースを実施していれば、事前に検出できた可能性があります。

この不具合によって、申請を実施した1社の申請情報が他企業10社から見られてしまう事態が発生。役員や労働者の氏名、銀行口座といったプライベートな情報が流出しました。本事例では政府が謝罪や対応に追われる結果となりましたが、民間の企業であれば訴訟に発展していたことも考えられます。

ユーザー体験の低下：通信サービスの大規模障害

大手キャリアにおいて通信障害があり、多くのユーザーの通話・データ通信に影響を及ぼしました。原因は、ネットワーク設備の再起動による通信トラフィックの輻輳（1箇所への集中による混雑）です。設備の再起動や輻輳発生時の異常系テストケースを実施していれば、事前に検出できた可能性があります。

この不具合によって、100万回線を超えるユーザーの通信品質が3時間弱にわたり低下しました。負荷軽減などにより復旧はしたものの、規模が大きいこともあり各メディアでも取り上げられ、キャリアの信頼性低下を招く結果になりました。

製品の大量リコール：車載システムにおける安全機能の誤作動

大手自動車メーカーのある車種において横滑り防止機能の誤作動が判明し、3,000台を超えるリコールが必要となりました。走行開始直後に当該機能を用いた場合、システム内部で故障と誤認識してしまい、速度計の停止やブレーキの遅延が生じてしまうためです。

走行開始直後の異常系テストケースを十分に実施していれば、事前に検出できた可能性があります。本事例ではプログラムの書き換えで対処できたものの、ハードウェアの交換が必要なケースも少なくありません。

多大な対応コストの発生：金融システムの大規模障害

ある金融システムにおいて大規模障害が発生し、復旧作業のために多大な対応コストを費やす事態となりました。原因は、1日に処理可能な上限件数を超えた振込みの集中です。上限件数自体は想定通りに設定していたものの、実運用上の妥当性や上限超過時のシステムへの影響は検証が不十分でした。

本事例では、上限件数超過によって想定しない周辺システムにまで影響が生じ、100万件を超える振込みが未処理状態となったのです。システムの整合性を維持しながら膨大な振込みジョブを再実行する作業は、運用・保守担当者の多大な人件費へと変わることになりました。

異常系テストの実施方法や課題とは？

今回は異常系テストの基礎知識や、4事例から学ぶ重要性についてお伝えしました。

異常系テストの実施が不十分だった場合、顧客・エンドユーザーはもちろん、開発者にとっても多くの問題が生じます。品質問題による信頼の失墜やブランドイメージの低下を避けるうえでは、高品質な異常系テストの実施が欠かせません。

異常系テストの品質向上にあたっては、下記事項への理解も重要となります。

• 異常系テストの実施方法
• 異常系テストの実施における課題
• 異常系テストの課題解決に向けたポイント
• 異常系テストへの具体的な施策

次回は、異常系テストの実施方法や課題について解説します。

• 異常系テストへのEggplantの適用