システムアーキテクト 2010年 午前2 問07

静的テスト【午前2解説】

正解の理由

解法ステップ

1. 各選択肢のキーワード（静的テスト、単体テスト、トップダウンテスト、ブラックボックス）を確認する。
2. 用語の定義を思い出す（静的＝実行しない、単体＝モジュール単位、トップダウン＝上位から統合、ブラックボックス＝内部構造を見ない）。
3. 各選択肢と定義を照合して矛盾を検出する。
   • 例えば、単体テストでの「スタブ／ドライバ」の役割が逆になっていないか確認する。
   • トップダウンの利点・欠点が実際の欠陥検出時期と合っているか評価する。
4. 定義に合致する選択肢（実行せずに行う手法）を正解とする。

選択肢別の誤答解説

• ア（正）: 静的テストの定義として正確です。実行を伴わない点と、コード検査や静的解析の例示は適切です。
• イ（誤）: 単体テストにおけるスタブとドライバの役割が逆に記述されています。正しくは、単体テストで被検査モジュールを呼び出す「ドライバ（テストハーネス）」を作成し、被検査モジュールが呼び出す下位モジュールの代わりに「スタブ」を用いる、です。例：モジュールAを単体テストする際に、Aを呼ぶテストドライバを用意し、Aが呼ぶBをスタブ化します。
• ウ（誤）: 「トップダウンテストでは全体に関係する欠陥が発見されにくい」との記述は不正確です。トップダウン統合では上位モジュール（制御や大枠の振る舞いを担う部分）を早期に結合してテストするため、設計上の制御フローやインタフェースの不整合、システム全体に影響するような振る舞いの欠陥はむしろ早期に発見されやすくなります。一方で、下位モジュール固有の詳細なロジックや数値処理といった欠陥は、スタブで代替している間は検出されにくく、後段で発覚する傾向があります。したがって「全体に関係する欠陥が発見されにくい」という断定は誤りです。
• エ（誤）: ブラックボックステストは仕様や外部から見た振る舞いに基づいてテストケースを設計する手法であり、内部の分岐やすべての経路を通すこと（経路網羅）はホワイトボックス（構造ベース）テストの目的です。ブラックボックスでは等価クラステストや境界値分析、決定表などが中心で、内部経路を直接検証することは想定していません。

よくある誤解

• スタブとドライバを混同する：単体テストで呼び出す側（上位）を模擬するのがドライバ、呼び出される側（下位）を模擬するのがスタブです。役割を逆に覚えるミスが多いです。
• 静的テストで実行上のバグも全部見つかると思う：静的解析は多くの欠陥（型ミス、ヌル参照の可能性、一貫性違反など）を早期に発見できますが、実行時の性能問題やランタイム条件依存のバグは動的テストでしか検出できません。
• トップダウンは「全体の欠陥を見つけにくい」と短絡判断する：トップダウンは上位構造や制御の欠陥を早く検出できる長所がある一方、下位詳細の欠陥は遅れて出るという整理が正確です。

補足コラム

• 静的テストの利点と限界
  • 利点：実行環境不要で早期に欠陥を発見でき、修正コストを低減できる。自動静的解析ツールで大規模コードの定常チェックが可能。
  • 限界：実行時の状態依存の欠陥（リソース競合、性能劣化、実行時例外、環境依存）は検出できないため、動的テストと併用する必要があります。
• 統合テスト戦略の対比（簡易）
  • トップダウン：上位→下位。上位制御の妥当性や主要インタフェースを早期検証可能。
  • ボトムアップ：下位→上位。下位の詳細ロジックを早期に検証可能。
  • サンドイッチ（混合）：両者の利点を組み合わせる方式。
• よく使われる静的解析ツール例（言語別）
  • Java: SpotBugs, Checkstyle, SonarQube
  • Python: pylint, mypy（型チェック）
  • C/C++: cppcheck, Clang-Tidy

# sample.py
def add(a, b):
    return a + b

# 使われていない変数や型の問題は静的解析で指摘されることがある

FAQ