Chapter 01
ブラックボックステストとは — 中身を信じず、外から確かめる
この章のゴール.
「ソースコードを信じられない組み込み機器」を、外部から観測できる振る舞いだけで検証する——という立場を理解し、 何を観測点にし、何を「正しさの基準（オラクル）」にするかを設計できるようになること。
1. なぜブラックボックスなのか
ブラックボックステスト（black-box testing）とは、中身の作りを一切前提にせず、入力と出力・観測できる振る舞いだけで対象を検証する手法である。 反対語のホワイトボックステストは、ソースコードや内部状態を見ながら「この行が通ったか」を確かめる。
組み込み開発では、次のような理由でブラックボックスが不可欠になる。
| 状況 | なぜ中を信じられないか |
|---|---|
| 生成 AI にコーディングさせた | もっともらしいが検証されていないコードが、実機で本当に仕様どおり動く保証はない。「テストが通る」と AI が言っても、そのテスト自体が正しいとは限らない |
| ソース・ビルド環境が失われた古い製品 | 中身を見られない |
| 他社製モジュール・チップ | データシートと実物が食い違うことがある |
| 認証・受け入れ検査 | 「作った人が正しいと言っている」ではなく、第三者として振る舞いを確認する必要がある |
| セキュリティ評価 | 攻撃者はソースを持たずに外から探る |
本編は特に 1 番目——生成 AI が書いた組み込みファームウェアを、人間が外から検証する——を主眼に置く。 AI 生成コードは、コンパイルが通り、一見動き、簡単なデモも成功する。だが「電波法の規定を守っているか」「電源が切れる瞬間にフラッシュを壊さないか」「無効な BLE パケットで固まらないか」といった実機・実環境でしか露見しない振る舞いは、コードを読むだけでは分からない。動かして、外から測るしかない。
2. 観測点の地図 — どこから見えるか
組み込み機器は「箱」だが、外に向かって多くの観測点を持つ。本編はこの一つ一つを開けていく。
| 観測点 | 何が分かるか | 章 |
|---|---|---|
| 電源・消費電流 | 動作状態、スリープの深さ、処理のタイミング、異常な発熱 | 03 |
| デジタル信号線（ロジックアナライザ） | GPIO・バス・割り込みのやり取り | 04 |
| UART / シリアル | ログ、コマンド、ブートメッセージ | 05 |
| I²C / SPI | センサ・EEPROM・周辺 IC との通信 | 06 |
| アナログ（ADC/DAC/PWM/センサ） | 実世界とのやり取り | 07 |
| デバッグポート（SWD/JTAG） | 半分は中が見える（グレーボックス） | 08 |
| BLE / Wi-Fi / サブGHz 無線 | 通信内容、接続の振る舞い、電波の出方 | 09〜12 |
| USB | 列挙（エニュメレーション）、クラス動作 | 13 |
| タイミング（応答遅延・ジッタ） | リアルタイム性、締め切り違反 | 14 |
これらを「受動的に盗聴する（バスをただ眺める）」と「能動的に刺激を与えて反応を見る」の 2 モードで使い分ける。後者が本当のテストである。
3. オラクル問題 — 「正しい」を誰が決めるか
ブラックボックステストの最大の難所は、観測した振る舞いが正しいかどうかを何で判断するかである。これをテストオラクル（test oracle）と呼ぶ。 中を見ないのだから、「変数 x が 42 になっているべき」とは言えない。代わりに、外から確認できる基準を用意する。
| オラクルの種類 | 例 |
|---|---|
| 仕様書 | 「ボタンを押したら 100 ms 以内に LED が点く」「BLE の広告間隔は 100 ms」 |
| 規格 | Bluetooth Core 仕様、USB クラス仕様、電波法の技術基準 |
| リファレンス実装 | 既知の正しい機器・公式アプリと同じ振る舞いをするか |
| メタモルフィック関係 | 「入力を 2 倍にしたら出力も 2 倍のはず」のような、正解を知らなくても成り立つ関係 |
| 不変条件 | 「どんな入力でもクラッシュしない」「消費電流が常に上限以下」 |
| 差分（回帰） | 前のバージョン・別の個体と比べて変化がないか |
生成 AI のコードを検証するときは、AI が書いたテストをオラクルにしてはいけない。同じ誤解が実装とテストの両方に入るからだ。人間が仕様・規格・独立したリファレンスからオラクルを立てる。
4. 決定性・再現性・記録 — テストの三本柱
外から観測するテストは、放っておくと「たまに失敗する」「昨日は再現したのに」に陥る。三本柱で守る。
- 決定性（determinism）: 同じ入力なら同じ結果になるように、初期状態・タイミング・環境を固定する。組み込みは電源投入直後の状態や無線の混雑に左右されやすいので、毎回リセットから始めるのが基本
- 再現性（reproducibility）: 失敗を再現できる形で記録する。使った機材・配線・コマンド・環境（温度、電波状況）まで
- 記録（logging）: 波形・パケット・ログを生データで保存する。「NG だった」ではなく「この波形で NG だった」。後から別の目で見直せる
5. 安全と法 — 始める前に
- 対象を壊さない: 電圧レベルの不一致（5V と 3.3V）、給電の競合、静電気。プローブを当てる前にレベルとグラウンドを確認する（各章で触れる）
- 電波を出すテストは法律の範囲で: 無線の能動テスト（信号を送る、妨害する）は、電波法上の免許・技術基準適合（技適）や、シールドボックス内での実施が必要になる場合がある（12 章）。受動的な受信・観測は比較的自由だが、他人の通信の内容を扱うことには通信の秘密の問題がある
- 自分の機器を、管理された環境で: 本編は一貫して「自分（自社）の開発・検証対象を、電波暗室やシールド環境・実験机で調べる」前提で書く
6. 本編の構成
| 部 | 章 | 内容 |
|---|---|---|
| I. 土台 | 01〜02 | 立場、オラクル、テスト設計、機材 |
| II. 配線で触れる観測 | 03〜08 | 電源、ロジック、UART、I²C/SPI、アナログ、デバッグポート |
| III. 無線を見る・つつく | 09〜13 | BLE（把握と能動）、Wi-Fi、サブGHz と SDR、USB とその他有線 |
| IV. 質を測る・追い込む | 14〜17 | タイミング、HIL、ファジングと堅牢性、セキュリティ |
| V. 仕組みにする | 18〜20 | テストハーネス、自作ツール、テスト計画とケース |
7. 手を動かす
観測点とオラクルを結びつける
この章のポイント
- ブラックボックステストは中身を前提にせず、外の振る舞いだけで検証する。AI 生成コードは「動くように見える」ので実機で外から測るしかない
- 観測点は電源・デジタル・UART・I²C/SPI・アナログ・無線・USB・タイミング。受動観測と能動刺激を使い分ける
- 最大の難所はオラクル（正しさの基準）。仕様・規格・リファレンス・不変条件から立てる。AI のテストをオラクルにしない
- 三本柱は決定性・再現性・記録。毎回リセットから、生データを保存
- 無線の能動テストは法と環境（技適・シールド）に注意