在进行BQB测试时，实验室会反馈一些fail项，需要我们分析原因。而实验室提供给我们的信息往往不多，通常只是一个测试case id，外加一句简单的现象描述。单从这两点信息来分析，我们完全不知道实验室是怎么样去测试这条case，该条case的Pass verdict是什么？
例如：
PAN
TP/PAN/IP/APP/BV-05-I：
提示问题：Wrong ICMP response received
当我们拿到这样一个fail项时，应该怎样去分析呢？
首先，明确测试步骤和要求
BQB所有测试项，在蓝牙开发者门户网站上都有测试说明文档。
https://www.bluetooth.com/zh-cn/specifications/qualification-test-requirements
需要注意的是，一些BT Profile存在多个版本，像上图的OPP就有3个不同的版本：OPP、OPP 1.2 、OPP 1.2.1。所以，还需要先确认在申请BQB测试时填写的Profile对应支持的是哪一个版本。
要下载这些文档，必需先使用公司邮箱注册账户加入Bluetooth SIG
注册成功以后，下载PAN的测试说明文档，在文档中搜索case id " TP/PAN/IP/APP/BV-05-I"，可以看到一个详细的测试步骤说明，Pass verdict和Fail verdict
实际案例分析
BQB测试步骤我们已经知道了，接下来以实际的例子，介绍常见的测试失败的原因，和分析思路。
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)和个人局域网相关的蓝牙服务。根据PAN测试文档的描述，看上去是ping不通导致失败的。
Step 2. 尝试模拟现象
可以用你进行BQB测试的Android手机，去连下PAN这个Profile，然后再去Ping下，观察下是什么现象？能否复现Ping不通的情况。
我找了一个蓝牙适配器插到电脑上，并安装了BlueSoleil在我的电脑上，方便连接各种BT profile。
使用测试手机连接上PAN，再电脑上尝试去Ping 192.168.44.1, 果然是Ping不通。那么问题来了，为什么要去Ping 192.168.44.1呢？因为PanService里面设置地址就是192.168.44.1。
Step 3. 使用ifconfig查看手机上网络设备的状态，发现没有192.168.44.1相关的信息
Step 4 . 检查手机上和网络相关的设置菜单，发现有一个Bluetooth tethering开关
Step 5. 将Bluetooth tethering开关打开以后，再次尝试ping，总算是ping通了。
Step 6. 再次使用ifconfig查看手机上网络设备的状态，发现多了一项bt-pan，里面对应的地址正是：192.168.44.1
Step 7 . 请实验室在测试PAN前，打开Bluetooth tethering开关，复测还是失败
Step 8 . 再次分析log
state : 2 ----> CONNECTED = 2 //表示PAN已经连接成功
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
结论
根据local_role和remote_role的值，说明是相机主动发起的PAN连接，那么在进行PAN测试时，必需保证PTS的bt-pan已经激活，并且PTS配置的相机ip是正确的。而我们之前模拟的情况是PTS作为了PAN User，手机作为Network Access Point，和实验室的刚好相反。
Step 9 . 再次模拟
为了保证和实验室测试条件一样，使用两台手机进行PAN连接，其中一台作为Network Access Point，一台作为PAN User，分别在两台手机上尝试PING，均可以PING通。证明我们的手机上网功能是OK的，怎么在实验室就PING不通了呢？
Step 10 . 在bluetooth.org官网上搜索PTS issue
bluetooth.org官网上提供了一个平台用来上报BQB测试中遇到的问题，并提供解决方法，网址如下：
搜到一条：TC_IP_APP_BV_05_I: non-ICMP packets are treated by PTS as "wrong ICMP response". 和我们的现象和类似，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）可支持鼠标、键盘功能，和蓝牙键盘、鼠标相关的一个Profile。
Step 2. 在HID测试文档中搜索case id "TP/DAT/BV-02-C".
大概说的是手机要发一个超长的report给MTU，并且长度要超过MTU规定的长度，该项才能pass。
Step 3. 确定我们发送的report长度，和MTU要求的长度。
实验室抓取了测试该项fail时的log，在log里面搜索关键字HID，发现还真有SEND_REPORT_LONG这么一条，看上去和测试文档说的一样，是在BluetoothHidActivity里面调用的。
Step 4. 确认测试方式
搜索了整个工程里面的代码，没发现BluetoothHidActivity相关的代码。和实验室确认，他们使用的是BluetoothHidActivity.apk来进行SEND_REPORT_LONG测试的。
Step 5. 开始模拟现象
找一个蓝牙键盘连接上手机，并手机上安装BluetoothHidActivity.apk，点Send_report(long)，可以打印出同样的SEND_REPORT_LONG相关log，证明我们的操作是正确的。
Step 6. 反编译APK & 修改smail代码
由于没有apk源码，只能对BluetoothHidActivity.apk进行反编译，然后查看点Send_report(long)时，发送的report是5700，而发送的“5700”的字符串，对应log为：
而实验室要求的长度为48，明显长度不够。
下图为反编译出来的smail代码，增加5700的长度。
Step 7. 重新打包&签名apk，验证效果
通过抓取的log分析，report值已经改变，证明修改已经生效。
Step 8. 将修改后的apk发给实验室，复测通过
Case 3. 申请BQB时，PICS填写不正确
HFP
TP/ECC/BI-03-I
测试过程中出现如下提示，按照提示接通第一个和第二个电话，并点击OK，测试结束，错误提示如下所示
HFP test fail.png
Step 1. 下载HFP测试文档
发现有好几个版本，我们申请的是1.5版本，所以下载“免提配置文件1.5”就好了。
下载后，发现文件名称叫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发送一条AT指令给AG(我们的手机)，AG收到指令后，需要回复ERROR，测试才能pass。
乍一看会觉得很奇怪，其他测试项都是回复OK才算pass，怎么回复ERROR才能pass了？
仔细阅读测试说明，发现有这么一句：
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发送的AT+CHLD=12后，返回的是OK，同时check代码，发现我们是支持Enhanced Call Control功能的。
Step 4. 确认PICS中Enhanced Call Control的支持情况
和实验室确认，由于我们填写的PICS里面Enhanced Call Control写的是不支持，导致该fail，修改Enhanced Call Control为支持，测试通过。
