在進行BQB測試時，實驗室會反饋一些fail項，需要我們分析原因。而實驗室提供給我們的信息往往不多，通常只是一個測試case id，外加一句簡單的現(xiàn)象描述。單從這兩點信息來分析，我們完全不知道實驗室是怎么樣去測試這條case，該條case的Pass verdict是什么？
例如：
PAN
TP/PAN/IP/APP/BV-05-I：
提示問題：Wrong ICMP response received
當我們拿到這樣一個fail項時，應(yīng)該怎樣去分析呢？
首先，明確測試步驟和要求
BQB所有測試項，在藍牙開發(fā)者門戶網(wǎng)站上都有測試說明文檔。
https://www.bluetooth.com/zh-cn/specifications/qualification-test-requirements
需要注意的是，一些BT Profile存在多個版本，像上圖的OPP就有3個不同的版本：OPP、OPP 1.2 、OPP 1.2.1。所以，還需要先確認在申請BQB測試時填寫的Profile對應(yīng)支持的是哪一個版本。
要下載這些文檔，必需先使用公司郵箱注冊賬戶加入Bluetooth SIG
注冊成功以后，下載PAN的測試說明文檔，在文檔中搜索case id " TP/PAN/IP/APP/BV-05-I"，可以看到一個詳細的測試步驟說明，Pass verdict和Fail verdict
實際案例分析
BQB測試步驟我們已經(jīng)知道了，接下來以實際的例子，介紹常見的測試失敗的原因，和分析思路。
Case 1. PTS(實驗室測試BQB的工具)本身的Bug
PAN
TP/PAN/IP/APP/BV-05-I：
提示問題：Wrong ICMP response received
Step 1. 首先，你得大概知道這個BT Profile是干嘛的？
PAN(Personal Area Network Profile)和個人局域網(wǎng)相關(guān)的藍牙服務(wù)。根據(jù)PAN測試文檔的描述，看上去是ping不通導致失敗的。
Step 2. 嘗試模擬現(xiàn)象
可以用你進行BQB測試的Android手機，去連下PAN這個Profile，然后再去Ping下，觀察下是什么現(xiàn)象？能否復現(xiàn)Ping不通的情況。
我找了一個藍牙適配器插到電腦上，并安裝了BlueSoleil在我的電腦上，方便連接各種BT profile。
使用測試手機連接上PAN，再電腦上嘗試去Ping 192.168.44.1, 果然是Ping不通。那么問題來了，為什么要去Ping 192.168.44.1呢？因為PanService里面設(shè)置地址就是192.168.44.1。
Step 3. 使用ifconfig查看手機上網(wǎng)絡(luò)設(shè)備的狀態(tài)，發(fā)現(xiàn)沒有192.168.44.1相關(guān)的信息
Step 4 . 檢查手機上和網(wǎng)絡(luò)相關(guān)的設(shè)置菜單，發(fā)現(xiàn)有一個Bluetooth tethering開關(guān)
Step 5. 將Bluetooth tethering開關(guān)打開以后，再次嘗試ping，總算是ping通了。
Step 6. 再次使用ifconfig查看手機上網(wǎng)絡(luò)設(shè)備的狀態(tài)，發(fā)現(xiàn)多了一項bt-pan，里面對應(yīng)的地址正是：192.168.44.1
Step 7 . 請實驗室在測試PAN前，打開Bluetooth tethering開關(guān)，復測還是失敗
Step 8 . 再次分析log
state : 2 ----> CONNECTED = 2 //表示PAN已經(jīng)連接成功
local_role:2 ----> LOCAL_PANU_ROLE = 2 //The local device is acting as a PAN User
remote_role :1 ----> REMOTE_NAP_ROLE = 1 //The local device is acting as a Network Access Point
結(jié)論
根據(jù)local_role和remote_role的值，說明是相機主動發(fā)起的PAN連接，那么在進行PAN測試時，必需保證PTS的bt-pan已經(jīng)激活，并且PTS配置的相機ip是正確的。而我們之前模擬的情況是PTS作為了PAN User，手機作為Network Access Point，和實驗室的剛好相反。
Step 9 . 再次模擬
為了保證和實驗室測試條件一樣，使用兩臺手機進行PAN連接，其中一臺作為Network Access Point，一臺作為PAN User，分別在兩臺手機上嘗試PING，均可以PING通。證明我們的手機上網(wǎng)功能是OK的，怎么在實驗室就PING不通了呢？
Step 10 . 在bluetooth.org官網(wǎng)上搜索PTS issue
bluetooth.org官網(wǎng)上提供了一個平臺用來上報BQB測試中遇到的問題，并提供解決方法，網(wǎng)址如下：
搜到一條：TC_IP_APP_BV_05_I: non-ICMP packets are treated by PTS as "wrong ICMP response". 和我們的現(xiàn)象和類似，PTS從6.0上存在一個issue，會導致TC_IP_APP_BV_05_I測試失敗。
Step 11 . 和實驗室溝通，更換PTS為5.3版本，總算復測通過了。
Case 2. 測試條件不滿足
HID
TP/DAT/BV-02-C：
彈出下面對話框后選Send_report(long)
fail信息提示
提示：Received a report smaller than the MTU, please send a larger report
Step 1. HID(Human Interface Device Profile）可支持鼠標、鍵盤功能，和藍牙鍵盤、鼠標相關(guān)的一個Profile。
Step 2. 在HID測試文檔中搜索case id "TP/DAT/BV-02-C".
大概說的是手機要發(fā)一個超長的report給MTU，并且長度要超過MTU規(guī)定的長度，該項才能pass。
Step 3. 確定我們發(fā)送的report長度，和MTU要求的長度。
實驗室抓取了測試該項fail時的log，在log里面搜索關(guān)鍵字HID，發(fā)現(xiàn)還真有SEND_REPORT_LONG這么一條，看上去和測試文檔說的一樣，是在BluetoothHidActivity里面調(diào)用的。
Step 4. 確認測試方式
搜索了整個工程里面的代碼，沒發(fā)現(xiàn)BluetoothHidActivity相關(guān)的代碼。和實驗室確認，他們使用的是BluetoothHidActivity.apk來進行SEND_REPORT_LONG測試的。
Step 5. 開始模擬現(xiàn)象
找一個藍牙鍵盤連接上手機，并手機上安裝BluetoothHidActivity.apk，點Send_report(long)，可以打印出同樣的SEND_REPORT_LONG相關(guān)log，證明我們的操作是正確的。
Step 6. 反編譯APK & 修改smail代碼
由于沒有apk源碼，只能對BluetoothHidActivity.apk進行反編譯，然后查看點Send_report(long)時，發(fā)送的report是5700，而發(fā)送的“5700”的字符串，對應(yīng)log為：
而實驗室要求的長度為48，明顯長度不夠。
下圖為反編譯出來的smail代碼，增加5700的長度。
Step 7. 重新打包&簽名apk，驗證效果
通過抓取的log分析，report值已經(jīng)改變，證明修改已經(jīng)生效。
Step 8. 將修改后的apk發(fā)給實驗室，復測通過
Case 3. 申請BQB時，PICS填寫不正確
HFP
TP/ECC/BI-03-I
測試過程中出現(xiàn)如下提示，按照提示接通第一個和第二個電話，并點擊OK，測試結(jié)束，錯誤提示如下所示
HFP test fail.png
Step 1. 下載HFP測試文檔
發(fā)現(xiàn)有好幾個版本，我們申請的是1.5版本，所以下載“免提配置文件1.5”就好了。
下載后，發(fā)現(xiàn)文件名稱叫HFP.TS.1.7.1.1.pdf，明明下的是1.5版本，怎么又變成1.7了？打開HFP.TS.1.7.1.1.pdf，從標題可以看出1.5-1.7都通用1.7的測試文檔。
Step 2. 搜索case id "TP/ECC/BI-03-I" ，找到測試步驟描述。
大概的意思是HF發(fā)送一條AT指令給AG(我們的手機)，AG收到指令后，需要回復ERROR，測試才能pass。
乍一看會覺得很奇怪，其他測試項都是回復OK才算pass，怎么回復ERROR才能pass了？
仔細閱讀測試說明，發(fā)現(xiàn)有這么一句：
AG does not support Enhanced Call Control features.
而TP/ECC/BI-03-I測的就是Enhanced Call Control Not Supported-Release Call，既然不支持Enhanced Call Control，那返回ERROR就可以理解了。
Step 3. 分析實驗室提供的HCI log
從實驗室提供的HCI log來看，AG在收到HF發(fā)送的AT+CHLD=12后，返回的是OK，同時check代碼，發(fā)現(xiàn)我們是支持Enhanced Call Control功能的。
Step 4. 確認PICS中Enhanced Call Control的支持情況
和實驗室確認，由于我們填寫的PICS里面Enhanced Call Control寫的是不支持，導致該fail，修改Enhanced Call Control為支持，測試通過。
