• TOP
  • 品質メディア
  • システムテスト・総合テストとは|目的や観点、手法を紹介
品質メディア

システムテスト・総合テストとは|目的や観点、手法を紹介

2021/11/09

ソフトウェア開発では、開発フェーズによって単体テスト、結合テスト、システムテストなどタイプの異なるテストが実施されます。今回は、その中からシステムテストについて、その目的や観点、具体的な手法などをご紹介します。

システムテスト・総合テストとは?

システムテスト(ST)は、「総合テスト」と呼ばれることもあり、ソフトウェアシステム開発の終盤で行われるテストです。モジュールやコンポーネントの単体テストを行い、それらを結合して結合テストを行った後にすべてを結合して行うため、「システム結合テスト」と表現される場合もあります。

システムテストは、ウォーターフォール型ソフトウェア開発のV字モデルでみると「要件定義」に対して行われるテストで、システムに要求された機能を満たしているかという観点でテストを実施します。システムテストの次のフェーズに「受け入れテスト(UAT)」がありますが、不具合の大半はシステムテストまでに対応されます。

Vモデルの概念図

システムテストの種類

システムテストは、すべての機能群やユーザーインターフェース(UI)が統合された状態でテストを行うため、機能テストに加えてユーザビリティや信頼性といった非機能要件に対するテストも行います。結合テストフェーズで非機能テストを実施するプロダクトもありますが、システムテストでは特にその重要度が増します。システムテストで行う主なテストについては、以降で解説します。

非機能要件のテスト

非機能要件には以下のような観点があります。

  • 操作性
  • 信頼性
  • 性能性
  • 移植性
  • 保守性
  • セキュリティ

非機能要件の一つである「操作性」はユーザビリティともいわれ、受け入れテスト(UAT)で重視されることが多いテスト観点です。しかし、ユーザビリティに問題があった場合に受け入れテスト段階では変更が難しく、修正できたとしても修正コストが大きくなるため、システムテスト段階で重きを置いてテストしておきたい内容です。ユーザビリティは要求仕様ベースの機能テストでは網羅が難しく、ユーザーストーリーを充実させる、第三者テストを活用するといった対応も視野に入れたほうが良いでしょう。

非機能要件に対するテストは、いずれのテストも通常のソフトウェアテストとは切り離され、専門部署が対応するケースも少なくありません。そのため、早期に非機能テストを計画し、関係部署と連携する、場合によっては外部発注するなどの対応が必要となってきます。

機能要件のテスト

機能要件に対する「ブラックボックステスト」は、単体テストや結合テストと同様のテスト技法を用います。

テスト技法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パターン」まで減らすことができます。

システムテストや総合的なソフトウェア開発・テスト体制に悩んだら

システムテストは、開発したソフトウェアシステムを顧客に引き渡す前のとても重要なテストです。そのテスト計画は結合テスト終了後に始めるのでは遅く、開発初期段階の要件定義が完了した時点から準備を進めます。

システムテストにはここで解説したように様々なテスト技法が用いられ、非機能テストのように専門的な知識を要するテストも必要です。

AGESTは、豊富なテスト実績を持つとともに、性能テストやセキュリティテストといった非機能テストを行う専門部署も備えています。テスト設計~テスト実施フェーズだけではなく、より上流のテスト工程(計画、分析)から対応することもできますので、システムテストでお困りの方はAGESTにぜひご相談ください。

関連サービス