進入了智能語音時代，我們都已經熟悉瞭如何在DuerOS 上開發一個智能語音技能應用，典型的流程如下：
在完成代碼之後，在上線商用之前，就是我們的日常——技能的調試。對於SaaS或者類AI中臺之類的服務，聯合調試並不是一件輕而易舉的事。
在DBP平臺上，提供了多種調試的方式，這裏簡要介紹意圖調試，模擬器調試，真機調試，團隊調試，還有不可或缺的日誌調試。
意圖調試
意圖調試是對交互模型的部分調試。意圖代表用戶想要達到的目的，常用表達是一系列與意圖相對應的常用口語化表達，常用表達可以包含槽位的信息。
在我們創建交互模型之後，可以對所創建的意圖進行調試，以判斷語音的交互是否可以被DuerOS系統識別爲我們定義的意圖。
意圖測試的侷限是沒有攜帶任何設備端的上下文信息，對於媒體播放以及多輪對話等存在着較多的侷限，比較適合於相對獨立的話術意圖測試。
模擬器調試
模擬器調試是對業務邏輯的模擬測試，是基於DBP 控制檯的simulator 進行的調試。
鑑於概念的區分，有必要比較一下仿真器（Emulator ）和模擬器（Simulator）的區別。
模擬器（Simulator），又稱模擬程序，是指完全基於主機程序並模擬了目標處理器的功能和指令系統的程序。模擬器是用於分析研究目標系統本身，模擬器系統本身跟目標系統保持一致。好的模擬器本身也可以仿真其目標系統，但不是所有模擬器都有這個特性。
仿真器（Emulator），又稱仿真程序，在軟件工程中指可以使計算機或者其他多媒體平臺（掌上電腦，手機）能夠運行其他平臺上的程序，目的是作爲目標系統的替代品，可以完全替代目標系統，完成其對外的功能，即仿真器系統只需要保證呈現給外部的行爲跟目標系統一致（不需要保證內部運行原理一致）。
顯然，DBP 提供的是模擬器，通過控制檯模擬器，開發者輸入用戶的語音query，途徑DuerOS 操作系統，轉換成意圖等信息送達技能服務的Bot，並將從Bot返回的結果呈現在控制檯和模擬器上。
模擬器調試有着自身的侷限，當前的限制包括：
1.渲染的圖形、佈局與真機有差異，比如元素在模擬器上佔據的區域、寬高、間隔和真機上相比有細微差異。這種差異在某種具體的組件下可能會很大，但是大部分都能較好模擬。
2.模擬器上報的端狀態沒有真機那麼全。但是上報的端狀態包含了基本的必須的端狀態，比如tts播報開始/結束，當前渲染的是哪一屏數據。
3.模擬器不支持動畫，不支持異步指令，比如在DPL頁面渲染之後，在不刷新頁面的前提下操作頁面內的元素，這在模擬器上是不支持的。
4.模擬器還不支持點擊事件，在模擬器上點擊時不會上報事件到雲端。
5.模擬器現在還不能返回homecard等等。
真機調試
在真實設備上的調試纔是確保智能語音技能正常工作的前提。無論是有屏設備，還是無屏設備，都要在控制檯勾選“技能調試模式”才能進行真機調試。
需要注意的是，在真機調試的時候，要保證技能的開發者賬號要與設備的登陸賬號一致。
對設備說，“小度小度，打開技能調試模式”即可啓用真機調試，在真實設備上來調試/測試我們開發的技能了。對個人開發者而言，同一時間僅支持一個技能的調試。
團隊調試
對於企業開發者而言， 往往需要在多個設備上由多個開發者同時調試技能，這就需要用到Team Debug 的功能。
企業開發者可創建團隊，邀請其他開發者加入團隊，團隊創建者審覈確認後成爲團隊成員。團隊創建者可以將自己的技能授權給團隊進行技能調試，團隊成員可在【團隊技能】中打開相應的技能調試開關，然後在使用綁定了自己賬號的設備上進行技能的調試。
首先，開發者點擊【創建團隊】，跳轉到團隊信息頁面。
然後，填寫團隊名稱和簡介，點擊【保存】。
在團隊信息頁面點擊【邀請加入】，或者在【控制檯】頁面將光標移動到團隊名稱上方，點擊【邀請】。
在彈出的對話框裏點擊【複製】將邀請鏈接複製下來，發送給其他要加入團隊的開發者，其他開發者點擊後即可申請加入。
對於成員的審覈，在【控制檯】我的團隊列表中，將光標移動到團隊名稱上方，點擊【管理】，進入團隊信息頁面。
點擊左側【成員審覈】，進入審覈頁面，點擊【同意】即可審覈通過，被邀請的開發者成爲團隊正式成員。
團隊創建人進入【團隊技能】頁面，在【我的技能】列表中選擇要授權給團隊的技能，開啓開關即可將該技能的調試權限授權給團隊。
普通團隊成員進入【團隊技能】頁面，選擇要調試的技能，開啓右側【技能調試】開關，然後可以在綁定自己賬號的設備上調試該技能。
團隊調試的方式與iOS的企業開發者類似， 爲大型團隊或大型技能應用的開發調試提供了便利。
日誌調試
以上的諸多調試方式，都是通過交互測試的手段來對智能語音技能的輸入輸出進行驗證，並進行進一步的調試。
對於技能的業務邏輯而言， 儘管可以通過ngrok建立內網穿透的方式實現單步調試，但是由於各種網絡超時的限制，導致效果不佳。
日誌調試是大多數基於雲服務應用調試的不二法門，關於日誌的用途可以參見《全棧必備 Log日誌》。
技能Bot的日誌記錄要儘量完整，最好保存完整的request 和response信息。對DBP 協議的深入理解，可以在很大程度上幫助開發者發現技能Bot 中的問題，模擬器調試中的Request/Response信息爲日誌的記錄提高了可參考的模式。其中，RequestID，DialogRequestID，設備ID，用戶ID 以及時間戳是每一條日誌的重要標識，也是DuerOS 與開發者之間溝通排查的主要依據。
對於基於Web Service 部署的技能服務，日誌的記錄以及基於日誌的調試取決於具體的技能實現編程語言，日誌的記錄方式與一般的Web服務日誌沒有太多的差異。對於基於CFC開發的應用，可以將日誌存儲在指定的BOS上，並注意一下定期清理。對於基於在線編輯器實現的技能，面向在線編輯器的日誌記錄還在DBP 平臺的開發規劃中，很快就可以上線應用了。
小結
調試對於創作出深受用戶喜愛的語音技能意義重大，目前，DuerOS Bot Platform （DBP）提供了意圖調試、模擬器調試、真機調試、團隊真機調試以及日誌追蹤調試等多種方式，但距離DBP 平臺高效開發與高效調試的目標還有較大差距，DBP正在積極地進行平臺演進，會陸續爲開發者提供更多穩定易用且功能強大的平臺工具。
關聯閱讀：
-
https://dueros.baidu.com/dbp
