使用 Application Verifier 建置異常情境測試基礎的案例

案例概要

這是一個不以單次故障修正作結，而是使用 Application Verifier 建置異常情境測試基礎本身的案例。 目的不只是「找出目前的故障」，而是「先打造出下次壞掉時也容易追查的狀態」。

症狀

• 只靠正常情境測試，failure path 的問題不容易浮現
• 低資源狀態或控制代碼異常，只有在接近正式環境的條件下才容易看見
• 每次調查時，步驟都容易變成只有特定人才會的作業

限制

• 在實機上真的把資源耗盡，成本與風險都很高
• 希望提前讓原生邊界與 Win32 相關的壞法浮現
• 必須整理成下次故障調查也能沿用的形式

觀測了什麼

• Handles、Heaps、Low Resource Simulation 等 Verifier 設定
• 含 !htrace 與 page heap 在內的 failure path 痕跡
• 自製 lifecycle log 與 Verifier stop 資訊之間的對應

如何釐清問題

首先區分只靠一般日誌就能追查的範圍，以及不套用 Verifier 就看不見的範圍。 在此基礎上，對 harness 化的執行路徑套用 Verifier，把方針收斂到提前讓難以重現的異常浮現。

如何改善

• 建置了能刻意踩進 failure path 的測試基礎
• 讓控制代碼異常與 heap 異常能在更短的循環內觀測到
• 將觀測點整理成容易回饋給後續設計審查與防止再發對策的形式

本案例連結的服務

本案例直接連結到推進故障重現與原因鎖定的故障調查・根本原因分析。同時也連結到整理「異常情境測試與觀測點要納入設計到什麼程度」的技術諮詢・設計審查。

相關文章

聯絡我們

如果您遇到的課題與本頁內容相近，歡迎附上目前狀況與所需支援的形式與我們聯絡。