カメラ系機能の実機不具合は、録画をフェイクカメラにして本物の実装へ流すブラウザリプレイで検証する
テスト設計
画像処理
デバッグ
運用
カメラ映像を扱う機能の実機不具合を、検出ロジックを別言語・別環境に移植したシミュレータだけで調査すると、2つの盲点が残る。(1) 移植ずれ: 検証しているのは「ロジックの写し」であって本番コードそのものではない。(2) 実レイテンシ: 推論時間やループ周期を仮定値で置くため、速度起因の症状(表示遅延・ゴースト残存)を再現できない。
この盲点は、実機録画をフェイクカメラ入力にして本物の実装をブラウザテストで等速再生することで塞げる。
手順
- 実機の画面録画から UI と描画オーバーレイを除去(クロップ + 近傍色 inpaint)し、動画ファイル化する。
- ブラウザテスト内でその動画を canvas へ描画し、canvas の captureStream を getUserMedia のモック戻り値にして、コンポーネントには本物のカメラと区別させない。
- 検出結果はオーバーレイ canvas の画素から抽出する(描画色のマスク→連結成分で「表示中の枠数と位置」をサンプリング)。タイムライン化すれば「初回表示までの秒数」「枠数の推移」「堆積の有無」が数値で出る。
- 重い推論関数をテスト側でラップ(モジュールモックで実体を呼びつつ計測)し、実レイテンシを実測する。さらに人工遅延を注入すれば低速端末を模擬でき、「遅い端末でも破綳しないか」を手元で検証できる。
適用条件・注意
- 移植シミュレータ(パラメータ探索が速い)とは補完関係。探索は移植側、最終確認とレイテンシ実測は本物リプレイ、と役割分担すると速い。
- 検証マシンの CPU は実端末より速いので、絶対値ではなく「遅延注入あり/なしの振る舞い差」で判断する。フレーム数基準の閾値があると遅延注入で意味が変わる点に注意(閾値は実時間基準にしておく)。
- 録画に個人情報(他人の名刺等)が含まれる場合、動画とテストはリポジトリにコミットせずローカル専用の診断ハーネスとして運用する。
- 重い推論でメインスレッドが飽和するとサンプリングタイマーが間引かれる。サンプルは回数でなくタイムスタンプ付きで記録する。