基本情報 平成31年度 春期 問47:テクノロジ系に関する問題
ブラックボックステストに関する記述として, 最も適切がものはどれか。
- aテストデータの作成基準として, プログラムの命令や分岐に対する網苺率を使 用する。
- b被テストプログラムに冗長なコードがあっても検出できない。正答
- cプログラムの内部構造に着目し, 必要な部分が実行されたかどうかを検証する。
- d分岐命令やモジュールの数が増えると, テストデータが急増する。
AI解説(初心者・標準・上級)
理解度に合わせて3レベルの解説を無料で読めます。
答えは b です。
ブラックボックステストは中身(コード)を見ずに、「入力と出力が仕様通りか」だけをチェックする方法。
なので、もしコードに「使われていない無駄な行(冗長コード)」があっても、外から見たら結果は正しいので見つけられません。
👉 覚え方:中身見ないから、中身の無駄もスルー。
ほかの選択肢:a 命令や分岐の網羅率=ホワイトボックステストの話/c 内部構造に着目=ホワイトボックステスト/d 分岐が増えるとテスト急増=ホワイトボックスの特徴。
なぜこれが正解か
正解は b。ブラックボックステストは仕様に基づき入出力関係のみを検証するため、プログラム内部の冗長コード(使われない命令、デッドコード)を検出できない。これは原理的な限界で、ホワイトボックステスト(カバレッジ分析)で補完する必要がある。
各選択肢の解説
- a 命令・分岐の網羅率:ホワイトボックステスト(カバレッジ基準)の特徴。
- c プログラムの内部構造に着目:ホワイトボックステストの定義。
- d 分岐/モジュール数増加でテストデータ急増:ホワイトボックステストの特徴(パス爆発)。
覚え方・ひっかけ注意
ブラックとホワイトの対比:
| 観点 | ブラック | ホワイト |
|---|---|---|
| 視点 | 仕様(外部) | コード(内部) |
| 手法 | 同値分割、境界値分析 | 命令/分岐/条件網羅 |
| 検出できないもの | 冗長コード、不要処理 | 仕様自体の誤り |
| 実施タイミング | 結合・システム・受入 | 単体・コンポーネント |
両者は補完関係で実務では併用が前提。
理論的背景
テスト技法はISTQB(国際ソフトウェアテスト資格)で仕様ベース技法(ブラック)、構造ベース技法(ホワイト)、経験ベース技法(探索的)に大別される。ブラックは仕様の妥当性を担保するが内部実装の問題(性能、保守性、隠れ機能、デッドコード)を検出できない。ホワイトは内部のカバレッジを担保するが仕様自体の欠陥は検出できない。
ホワイトボックステストのカバレッジ基準
- C0(命令網羅):全命令を1回以上実行
- C1(判定条件網羅/分岐網羅):全判定の真偽双方を実行
- C2(条件網羅):各条件の真偽双方を実行
- 複数条件網羅:全条件の組合せを網羅
- MC/DC(修正条件判定網羅):航空・原子力等の安全クリティカル系で要求
- パス網羅:理論的最強だが現実不可能(指数爆発)
デッドコード問題
冗長コード/デッドコードは保守性・セキュリティリスクを生むため、静的解析ツール(SonarQube、Coverity、ESLint、pylint、mypy)で検出するのが現代的。動的テスト(実行時カバレッジ)はJaCoCo、Istanbul、Coverage.pyで計測。
実務での使われ方
- V字モデル:要件定義↔受入テスト(ブラック)、基本設計↔結合テスト、詳細設計↔単体テスト(ホワイト中心)
- アジャイル/TDD:単体テスト(ホワイト寄り)を先に書き、受入テスト(ブラック)を継続的に追加
- シフトレフト:早期テスト・早期欠陥検出。静的解析、ペアプロ、レビュー、契約による設計
- シフトライト:本番環境でのカナリアリリース、A/Bテスト、カオスエンジニアリング
試験での位置づけ
基本情報・応用情報のソフトウェア工学分野で頻出。直近はテスト自動化(Selenium、Playwright、Cypress)、API契約テスト(Pact)、ミューテーションテストの出題も増加。
選択肢の発展補足
ブラックとホワイトの中間にグレーボックステストがあり、内部構造を一部理解した上で仕様ベーステストを行う(DB状態・API応答の中間検証等)。性能テスト・セキュリティテスト・ユーザビリティテストは機能テスト(ブラック)と並ぶ非機能テスト分野で、ISO/IEC 25010の品質特性に対応している。
出典:IPA(情報処理推進機構)公式 基本情報技術者試験 平成31年度 春期 問47/ 公的機関配布資料につき出典明記の上引用。解説は合格ナビによる独自AI解説です。