※2023/5/19 一部内容更新
ソフトウェア開発では、開発フェーズによって単体テスト、結合テスト、システムテストなどタイプの異なるテストが実施されます。今回は、その中からシステムテストについて、その目的や観点、具体的な手法などをご紹介します。
システムテスト・総合テストとは？
システムテスト（ST：System Test）は、「総合テスト」と呼ばれることもあり、ソフトウェアシステム開発の終盤で行われるテストです。モジュールやコンポーネントの単体テストを行い、それらを結合して結合テストを行った後にすべてを結合して行うため、「システム結合テスト」と表現される場合もあります。
システムテストは、ウォーターフォール型ソフトウェア開発のV字モデルでみると「要件定義」に対して行われるテストで、システムに要求された機能を満たしているかという観点でテストを実施します。システムテストの次のフェーズに「受け入れテスト（UAT）」がありますが、不具合の大半はシステムテストまでに対応されます。
システムテストの目的
システムテストの目的について、以下の4点に分けて解説いたします。
- 機能の確認
システムテストでは、開発されたシステムが設計通りに正常に動作し、すべての機能が予定通りの振る舞いをするかどうかを確認します。これには、機能要件やユーザーストーリーが正確かつ完全に実装されていることを確認する作業が含まれます。
例: ログイン機能、データの登録・検索・更新・削除、入力チェックなど - 性能・セキュリティの検証
システムテストでは、システムが性能要件を満たしているかどうかも検証します。これには、応答時間、最大同時アクセス数、スケーラビリティ、セキュリティなどが含まれます。
例: 1秒以内にページ表示、1000人同時アクセス、データの暗号化 - 互換性の確認
さまざまなデバイス、ブラウザ、OS、ネットワーク機能に対応しているかどうかを確認します。システムが、対象となるプラットフォームや環境で問題なく動作するかどうかを検証することが重要です。
例: Chrome, Firefox, Safariでの動作確認、スマホ・タブレット対応 - 運用・保守性の評価
システムが運用や保守に耐えられるかどうかを評価します。例えば、システムのログ機能や、バックアップ・復旧性を確認することが含まれます。
例: ログの取得・解析、バックアップの実施、バージョンアップ対応
これらの目的を達成することで、品質の高いシステムの実現と、継続的な運用・保守をサポートすることがシステムテストの目的です。
システムテストフェーズにおける違いや種類ついては「ONETECH」でも発信しているので、良ければ参考にしてください。
システムテストの種類
システムテストは、すべての機能群やユーザーインターフェース（UI）が統合された状態でテストを行うため、機能テストに加えてユーザビリティや信頼性といった非機能要件に対するテストも行います。結合テストフェーズで非機能テストを実施するプロダクトもありますが、システムテストでは特にその重要度が増します。システムテストで行う主なテストについては、以降で解説します。
機能要件のテスト
システムが要求仕様に沿って正常に動作するかどうかを確認するために機能要件のテストが行われます。これには、個々の機能やモジュールをテストすることから、システム全体の機能をテストすることまで、幅広い範囲のテストが含まれます。
機能要件に対する「ブラックボックステスト」は、単体テストや結合テストと同様のテスト技法を用います。
テスト技法1：同値分割（同値クラス）
同値分割（同値クラス）テストは、入力・選択対象を同じ動作をする条件の集まりとしてクラス化（パーティション化）し、それぞれのクラスに対してテストを行う技法です。
例えば、以下の判定式があった場合、
- 0～19歳：未成年
- 20～64歳：現役
- 65歳～：高齢者（前期後期高齢者）
対象を「未成年」「現役」「高齢者」という3つにクラス化し、それぞれの有功値内から任意の値を1つ選択してテストを行います。各クラスの代表値でテストして欠陥が見つかれば同値クラス内の他の値でも同じ欠陥が見つかり、欠陥が見つからない場合は同値クラス内ではその欠陥は見つからないだろうという考え方で行われるテストで、テストを効率的に実施する代表的な技法のひとつです。
テスト技法2：境界値分析
境界値分析は、判定の境界値に注目して行うテスト技法です。プログラムでは、「＞」と「＝＞」を間違えるというケアレスミスは起こりやすく、このミスが発生しした場合の影響は大です。
コードの記述にケアレスミスがなかったとしても、仕様の記述にある「以上」「以下」「未満」「より小さい」「より大きい」などの表現が間違って解釈されると、仕様にはない動作をするソフトウェアが作られてしまうことになります。このように境界値には間違いが混入しやすく、境界値をテストすれば、このような間違いがないことが確認できます。
先程の同値分割で示した「未成年」「現役」「高齢者」についての判定式の場合は、0、19、20、64、65
の5種類を境界値としてテストします。
テスト技法3：デシジョンテーブル
例えば、以下のように複数の条件の組合せでソフトウェアの動作が決まるシステムがあるとします。
- 会員であるか非会員であるか
- 割引クーポンを所持しているか
- 利用日が割引デーか
これらの条件の組合せで割引率が変わる場合、その条件をデシジョンテーブルという表を使ってもれなく洗い出し、テスト条件を整理するテスト技法がデシジョンテーブルテストです。デシジョンテーブルを使うことで、組合せが整理できるだけではなく、仕様上ありえない組合せを見つけることもできます。
テスト技法4：状態遷移テスト
デシジョンテーブルと同様に、テスト条件を整理するために用いられる技法です。起点となるポイントからどのような状態遷移があるかを可視化し、それをもとにテストケースを作成します。
状態遷移を整理する方法として、下図の2つの方法があります。
- 状態遷移図：グラフィカルで、ひとめで全容が把握しやすい
- 状態遷移表：状態遷移を抜けもれなく体系的に整理するのに有効
テスト技法5：ユースケーステスト
個別の機能に焦点を当てるのではなく、利用開始から終了までに焦点を当てたテスト方法。
テスト対象ソフトウェアに対して「アクター」（人、もしくはシステム/機能）がどのように関与するかをユースケースとして定義し、そこからテストシナリオを作成してテストを行います。
ユースケースは、以下のような項目で定義されます。
| ID ユースケース名 | UC-001 |
| 目的 | 好きな音楽をアラーム音としてセットしたい |
| アクター | ユーザー |
| 事前条件 | アラーム音にセットできる音楽がある |
| 事後条件（成功/失敗） | アラーム音に音楽をセットできる |
| 基本フロー | ステップ1：時間をセットする ステップ2：アラーム音を選択する ステップ3：設定を保存する |
| 代替フロー | ステップ3.1：設定した音楽の設定を解除する ステップ3.2：ステップ2に戻る |
| 例外フロー | ステップ1 … |
テスト技法6：組合せテスト
複数ある条件を組合わせてテストする際、すべての組合せをテストすることが非現実的なほど組合せ数が膨大になることが多々あります。そういった場合に、効果的にテストケースを削減するのが組合せテストです。
■ペアワイズによる組合せ数の削減例
ある小売り販売システムにおいて、
- 製品カラー：赤、青、緑、黄色（4色）
- 製品サイズ：S、M、L（3サイズ）
という項目の組合せは全部で「4×3=12パターン」となります。この程度の数なら、全パターンの組合せテストが行える範囲でしょう。
しかし、ここにさらに
- 決済方法：クレジットカード、銀行振込、コンビニ後払い（3種）
という条件が加わった場合、テストケース数は「4×3×3=36パターン」。さらに、
- 配送方法：宅配便、郵送、店頭受け取り（3種）
- 会員割引：有り、無し（2種）
と組み合わせの条件（因子）が増えると、「4×3×3×3×2=216パターン」と組合せ数が増加し、すべての組合せをテストするのは工数の問題から非現実的となっていきます。
これに対して、組み合わせテストは「多くの不具合は2つの要素の組合せで発見される」という前提のもと、テストする組合せ数を削減していきます。上記事例の場合は、2つの因子間の組合せがすべて網羅されるように5つの因子を組合わせていくことで、「216パターン」あった組合せを「12パターン」まで減らすことができます。
非機能要件のテスト
非機能要件には以下のような観点があります。
- 操作性
ユーザビリティともいわれ、受け入れテスト（UAT）で重視されることが多いテスト観点です。しかし、ユーザビリティに問題があった場合に受け入れテスト段階では変更が難しく、修正できたとしても修正コストが大きくなるため、システムテスト段階で重きを置いてテストしておきたい内容です。ユーザビリティは要求仕様ベースの機能テストでは網羅が難しく、ユーザーストーリーを充実させる、第三者テストを活用するといった対応も視野に入れたほうが良いでしょう。 - 性能効率性
システムが要求される性能を満たしているかどうかを確認するために、性能テストが行われます。これには、システムの負荷耐性、応答時間、処理能力、スループットなどのテストが含まれます。 - セキュリティ
システムがセキュリティ要件を満たしているかどうかを確認するために、セキュリティテストが行われます。これには、システムの脆弱性テスト、セキュリティ機能テスト、アクセス制御テストなどが含まれます。 - 信頼性
壊れにくさ、壊れてもすぐ復旧するか、どれだけ障害がおきないかシステムが正常に動作し続けることができるかどうかを確認するために、信頼性テストが行われます。これには、システムの故障復旧能力、耐久性、信頼性、回復力などのテストが含まれます。 - 可用性
システムが継続して稼働できる能力要求される可用性を満たしているかどうかを確認するために、可用性テストが行われます。これには、システムの稼働時間、再起動時間、メンテナンス時間などのテストが含まれます。
非機能要件に対するテストは、いずれのテストも通常のソフトウェアテストとは切り離され、専門部署が対応するケースも少なくありません。そのため、早期に非機能テストを計画し、関係部署と連携する、場合によっては外部発注するなどの対応が必要となってきます。
さいごに
システムテストは、開発したソフトウェアシステムを顧客に引き渡す前のとても重要なテストです。そのテスト計画は結合テスト終了後に始めるのでは遅く、開発初期段階の要件定義が完了した時点から準備を進められるように意識してみてください。
