本主題說明在 JavaScript 延伸模組中使用原生偵錯工具物件的設計和測試考慮。
原生調試程序物件代表調試程式環境的各種建構和行為。 物件可以傳遞至 （或取得） JavaScript 延伸模組，以操作偵錯工具的狀態。
如需偵錯工具物件 JavaScript 延伸模組的相關資訊，請參閱 JavaScript 延伸模組中的原生偵錯工具物件。
如需使用 JavaScript 的一般資訊，請參閱 JavaScript 偵錯工具腳本。
偵錯工具資料模型設計考慮
設計原則
請考慮下列原則，讓您的偵錯工具延伸模組呈現可探索、可查詢和可編寫腳本的資訊。
- 信息位於需要的地方附近。 例如，登錄機碼的資訊應該顯示為包含登錄機碼控制碼的區域變數的一部分。
- 信息是結構化的。 例如，登錄機碼的相關資訊會呈現在個別欄位中，例如金鑰類型、金鑰 ACL、金鑰名稱和值。 這意味著無需解析文字即可存取各個欄位。
- 信息是一致的。 登錄機碼控制碼的相關資訊會以盡可能類似檔案控制碼相關資訊的方式呈現。
避免這些不支持這些原則的方法。
- 不要將您的物品構建成一個扁平的“廚房水槽”。 有組織的階層可讓使用者瀏覽他們正在尋找的資訊，而無需事先了解他們要尋找的內容，並支援可探索性。
- 不要通過簡單地將經典 dbgeng 擴展移動到模型，同時仍輸出原始文本屏幕來轉換它。 這無法與其他延伸模組組合，也無法使用 LINQ 運算式查詢。 相反地，將資料分成個別的、可查詢的欄位。
命名指導方針
- 欄位的大小寫應該是 PascalCase。 可以視為例外的情況包括以另一種大小寫廣為人知的名稱，例如 jQuery。
- 避免使用通常不會在 C++ 識別碼中使用的特殊字元。 例如，避免使用「總長度」（包含空格）或「[size]」（包含方括號）等名稱。 此慣例可讓您更輕鬆地從腳本語言取用，其中不允許這些字元作為識別碼的一部分，也允許從命令視窗更輕鬆地取用。
組織和層次結構準則
- 請勿擴充偵錯工具命名空間的最上層。 相反地，您應該在偵錯工具中擴充現有的節點，讓資訊顯示在最相關的位置。
- 不要重複概念。 如果您要建立資料模型延伸模組，列出偵錯工具中已存在之概念的其他資訊，請擴充現有資訊，而不是嘗試以新資訊取代它。 換句話說，顯示模組詳細資料的延伸模組應該擴充現有的 Module 物件，而不是建立新的模組清單。
- 自由浮動公用程式命令必須是 Debugger.Utility 命名空間的一部分。 它們也應該適當地設定子命名空間 （例如 Debugger.Utility.Collections.FromListEntry）
向後相容性和重大變更
已發佈的腳本不應中斷與相依於它的其他腳本的相容性。 例如，如果將函數發佈至模型，則應盡可能保留在相同的位置並具有相同的參數。
不使用外部資源
- 延伸模組不得產生外部進程。 外部程序可能會干擾偵錯工具的行為，而且會在各種遠端偵錯工具情境中出現異常（例如 dbgsrv 遠端、ntsd 遠端和「ntsd -d 遠端」）
- 延伸模組不得顯示任何使用者介面。 顯示使用者介面元素在遠端偵錯案例中會運作不正確，而且可能會中斷主控台偵錯案例。
- 延伸模組不得透過未記載的方法操作偵錯工具引擎或偵錯工具 UI。 這會導致相容性問題，而且在具有不同 UI 的偵錯工具用戶端上會不正確運作。
- 延伸模組必須只透過記載的偵錯工具 API 來存取目標資訊。 嘗試透過 win32 API 存取目標的相關資訊，對於許多遠端案例，甚至是某些跨安全性界限的本機偵錯案例都會失敗。
不使用 dbgeng 特定功能
要做為延伸模組的腳本不得盡可能依賴 dbgeng 特定功能 （，例如執行「傳統」偵錯工具延伸模組） 。 腳本應該可以在裝載資料模型的任何偵錯工具之上使用。
測試偵錯器擴充功能
擴充功能預計可在各種案例中運作。 雖然某些延伸模組可能特定於案例 （例如核心偵錯案例） ，但大部分的延伸模組應該預期會在所有案例中運作，或具有指出支援案例的中繼資料。
核心模式
- 即時核心偵錯
- 核心轉儲除錯
使用者模式
- 即時使用者模式偵錯
- 使用者模式傾印偵錯
此外，請考慮這些偵錯工具使用案例
- 多進程調試
- 多會話偵錯（例如，單一會話內的傾印 + 即時使用者）
遠端偵錯工具使用方式
測試遠端偵錯工具在各種使用情境下的正確運作。
- dbgsrv 遠端服务
- NTSD 遙控器
- NTSD -d 遙控器
如需詳細資訊，請參閱 使用 CDB 和 NTSD 偵錯 和 啟用進程伺服器。
迴歸測試
調查如何使用測試自動化來驗證延伸模組的功能，特別是在發布新版本的偵錯工具時。