事例概要
単発の不具合修正で終わらせず、Application Verifier を使って 異常系テスト基盤そのものを整備 した事例です。 目的は「今の障害を見つける」だけでなく、「次に壊れたときも追いやすい状態を先に作る」ことでした。
症状
- 通常系試験だけでは、failure path の問題が表に出にくい
- 低リソース時やハンドル異常は、本番に近い条件でだけ見えやすい
- 調査のたびに手順が属人化しやすい
制約
- 実機で本当に資源を枯渇させるのはコストもリスクも高い
- ネイティブ境界や Win32 まわりの壊れ方を前倒しで表に出したい
- 次回の障害調査にも流用できる形で整える必要がある
何を観測したか
Handles、Heaps、Low Resource Simulationなどの Verifier 設定!htraceや page heap を含む failure path の痕跡- 自前の lifecycle log と Verifier stop 情報の対応
どう切り分けたか
まず通常ログだけで追える範囲と、Verifier を当てないと見えない範囲を分けました。 そのうえで、ハーネス化した実行経路に Verifier を当て、再現しにくい異常を前倒しで表に出す 方針へ寄せました。
どう改善したか
- failure path を意図的に踏ませるテスト基盤を整えた
- ハンドル異常やヒープ異常を、より短いループで観測できるようにした
- 後続の設計レビューや再発防止策へ戻しやすい形で観測点を整理した
この事例がつながるサービス
この事例は、障害の再現と原因特定を進める 不具合調査・原因解析 に直結します。あわせて、異常系試験や観測点をどこまで設計へ織り込むかを整理する 技術相談・設計レビュー にもつながります。