令和5年度42マネジメント系

ITパスポート 令和5年度 問42:development_managementに関する問題

ソフトウェア開発における,テストに関する記述a~cとテスト工程の適切な組合せはどれか。a 運用予定時間内に処理が終了することを確認する。b ソフトウェア間のインタフェースを確認する。c プログラムの内部パスを網羅的に確認する。[表] 単体テスト/結合テスト/システムテスト: ア a/b/c, イ a/c/b, ウ b/a/c, エ c/b/a

  • a単体テスト: a / 結合テスト: b / システムテスト: c
  • b単体テスト: a / 結合テスト: c / システムテスト: b
  • c単体テスト: b / 結合テスト: a / システムテスト: c
  • d単体テスト: c / 結合テスト: b / システムテスト: a正答
正答:D単体テスト: c / 結合テスト: b / システムテスト: a

AI解説(初心者・標準・上級)

理解度に合わせて3レベルの解説を無料で読めます。

初心者向けまずはここから。やさしく要点を解説

答えは d です。

プログラムのテストは、小さい部分から大きい全体へと段階を上がって確認します。

  • c(内部パスを網羅)=単体テスト:部品1個を細かくチェック。料理でいえば一品ずつ味見する段階。
  • b(つなぎ目を確認)=結合テスト:部品どうしの“つなぎ目”がちゃんと合うか確認。コンセントとプラグが合うか試すイメージ。
  • a(時間内に終わるか)=システムテスト:本番さながらに全部つないで、ちゃんと時間内に動くか最終確認。

👉 覚え方:「小さい部品→つなぎ目→全体」の順。a・b・cを単体・結合・システムに当てはめると d。

組合せが c→b→a の順になっている d が正解です。

標準試験対策の基準レベル

なぜこれが正解か

正解は d(単体: c / 結合: b / システム: a)。テストは小→大へ段階を進める。

  • c プログラムの内部パスを網羅的に確認 → 単体テスト:モジュール単体の論理(分岐・ループ)を検証。ホワイトボックステストの代表。
  • b ソフトウェア間のインタフェースを確認 → 結合テスト:モジュール同士を組み合わせ、受け渡すデータや呼び出しが正しいか検証。
  • a 運用予定時間内に処理が終了することを確認 → システムテスト:本番相当の環境で性能・処理時間など非機能要件まで含め全体を検証。

覚え方・ひっかけ注意

開発はV字モデルで「単体→結合→システム→運用」と上がる。内部パス=単体、つなぎ目=結合、時間/性能など全体=システムと紐づける。aの「運用予定時間内」を運用テストと早合点しないこと。処理時間の確認は本番前のシステムテストで行う非機能テストである。

上級誤答論破・背景理論まで深掘り

理論的背景

テスト工程の段階的構造はV字モデル(Verification & Validation Model)によって説明される。V字モデルはソフトウェア開発の左辺(要件定義→基本設計→詳細設計→実装)と右辺(単体テスト→結合テスト→システムテスト→受入テスト)が鏡像関係にあることを示し、左辺の各工程に対応する検証活動が右辺に配置される。

  • 詳細設計 ⇔ 単体テスト:モジュールの内部ロジック(アルゴリズム・条件分岐・ループ)が設計通りに機能するかを検証。内部パスを網羅するホワイトボックスアプローチが中心。
  • 外部(基本)設計 ⇔ 結合テスト:モジュール間のインターフェース(呼び出し・データの受け渡し・APIの整合性)を検証。ブラックボックスアプローチとホワイトボックスアプローチを組み合わせる。
  • 要件定義 ⇔ システムテスト:要件定義書に記載された機能要件・非機能要件(性能・処理時間・負荷・セキュリティ・信頼性)を本番相当環境で検証。

本問の設問記述aは「運用予定時間内に処理が終了する」という性能・性能テストの確認であり、これは非機能要件の検証としてシステムテストで実施される。設問cは「プログラムの内部パスを網羅的に確認」という典型的なホワイトボックステストの記述で、単体テストの役割そのものである。

実務での使われ方

単体テストの自動化にはxUnitフレームワーク(JUnit・pytest・RSpec・MSTest等)が業界標準として広く普及しており、CI/CDパイプラインに組み込んでコードの変更ごとに自動実行することで回帰(リグレッション)を即座に検出できる。TDD(Test Driven Development=テスト駆動開発)では単体テストを先に書いてからコードを書くアプローチで、テストカバレッジ(網羅率)の維持を保証する。

結合テストでは、開発中の下位モジュールが未完成の場合にスタブ(Stub)(下位モジュールの代替を提供する仮の実装)を、上位モジュールが未完成の場合にドライバ(Driver)(呼び出し元を模擬するプログラム)を使う。トップダウンテスト(上位から開始)とボトムアップテスト(下位から開始)でそれぞれスタブ・ドライバの使われ方が逆になる。

システムテストでは本番環境と同等のテスト環境(ステージング環境)での実施が理想であり、性能テスト(パフォーマンステスト)・負荷テスト(ロードテスト)・障害回復テスト・セキュリティペネトレーションテストなどが含まれる。

試験での位置づけ

テスト工程の役割対応はITパスポートのマネジメント系・開発技術分野で安定して出題される必須知識である。「各テスト工程で何を確認するか」の対応を以下のように整理しておくことが効率的である。

| テスト工程 | 確認対象 | 手法 |

|---|---|---|

| 単体テスト | 内部ロジック・分岐・アルゴリズム | ホワイトボックス(C0/C1網羅) |

| 結合テスト | モジュール間インターフェース | ブラック+ホワイトボックス |

| システムテスト | 機能・性能・セキュリティ(全体) | ブラックボックス |

| 受入テスト | ユーザー要件への適合 | ブラックボックス |

上位資格の基本情報技術者試験ではホワイトボックステストの網羅基準(命令網羅C0・分岐網羅C1・条件網羅)、ブラックボックステストの技法(同値分割・境界値分析)、スタブ・ドライバの役割まで問われる。

選択肢の発展補足

設問aの「運用予定時間内に処理が終了する」確認がシステムテストである根拠をさらに掘り下げると、これはシステム性能テスト(Performance Test)の一形態であり、要件定義段階で「夜間バッチ処理は翌朝8時までに完了すること」のように定義された非機能要件の検証に相当する。単体・結合テストは機能の正確性検証が主目的であり、全システムを統合した状態での時間的性能検証はシステムテストまで待つ必要がある。

設問bの「ソフトウェア間のインタフェース確認」が結合テストである理由は、「ソフトウェア間」という複数モジュールの結合後を前提とした表現にある。単体テストは1モジュールを独立して検証するため、複数モジュールの接続面(API・データ形式・エラーハンドリング)は結合テストに至るまで検証できない。設問cとbとaの3つが「詳細設計⇔外部設計⇔要件定義」という設計工程の詳細度順(細→粗)と逆対応していることを把握すれば、組合せ問題全体に応用できる。

出典・引用について

出典:IPA(情報処理推進機構)公式 ITパスポート試験 令和5年度42/ 公的機関配布資料につき出典明記の上引用。解説は合格ナビによる独自AI解説です。

マネジメント系の他の過去問

35
system_audit
36
project_management
37
project_management
38
development_management
39
project_management

あなたの弱点を診断して、合格までの最短ルートを

この分野を連続演習し、AIがあなたの弱点を分析。合格ナビならITパスポートの過去問を解きながら学べます。