Android蓝牙BQB测试fail项分析

来源:转载



Bluetooth

在进行BQB测试时,实验室会反馈一些fail项,需要我们分析原因。而实验室提供给我们的信息往往不多,通常只是一个测试case id,外加一句简单的现象描述。单从这两点信息来分析,我们完全不知道实验室是怎么样去测试这条case,该条case的Pass verdict是什么?


例如:
PAN
TP/PAN/IP/APP/BV-05-I:
提示问题:Wrong ICMP response received


当我们拿到这样一个fail项时,应该怎样去分析呢?


首先,明确测试步骤和要求

BQB所有测试项,在蓝牙开发者门户网站上都有测试说明文档。


http://developer.bluetooth.cn/Resources/TestTools/QTR



资格认证测试规范列表

需要注意的是,一些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



PAN TP/PAN/IP/APP/BV-05-I
实际案例分析

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。



PanService.java中设置IP为192.168.44.1

Step 3. 使用ifconfig查看手机上网络设备的状态,发现没有192.168.44.1相关的信息



使用ifconfig查看手机上网络设备的状态

Step 4 . 检查手机上和网络相关的设置菜单,发现有一个Bluetooth tethering开关



Bluetooth tethering

Step 5. 将Bluetooth tethering开关打开以后,再次尝试ping,总算是ping通了。



ping 192.168.44.1

Step 6. 再次使用ifconfig查看手机上网络设备的状态,发现多了一项bt-pan,里面对应的地址正是:192.168.44.1



再次使用ifconfig查看手机上网络设备的状态

Step 7 . 请实验室在测试PAN前,打开Bluetooth tethering开关,复测还是失败


Step 8 . 再次分析log



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测试中遇到的问题,并提供解决方法,网址如下:


https://www.bluetooth.org/pts/issues/


搜到一条: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测试失败。



TC_IP_APP_BV_05_I: non-ICMP packets are treated by PTS as "wrong ICMP response"

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。



HID TP/DAT/BV-02-C

Step 3. 确定我们发送的report长度,和MTU要求的长度。


实验室抓取了测试该项fail时的log,在log里面搜索关键字HID,发现还真有SEND_REPORT_LONG这么一条,看上去和测试文档说的一样,是在BluetoothHidActivity里面调用的。



实验室提供的log

Step 4. 确认测试方式


搜索了整个工程里面的代码,没发现BluetoothHidActivity相关的代码。和实验室确认,他们使用的是BluetoothHidActivity.apk来进行SEND_REPORT_LONG测试的。


Step 5. 开始模拟现象


找一个蓝牙键盘连接上手机,并手机上安装BluetoothHidActivity.apk,点Send_report(long),可以打印出同样的SEND_REPORT_LONG相关log,证明我们的操作是正确的。



BluetoothHidActivity APP测试HID的选项

Step 6. 反编译APK & 修改smail代码


由于没有apk源码,只能对BluetoothHidActivity.apk进行反编译,然后查看点Send_report(long)时,发送的report是5700,而发送的“5700”的字符串,对应log为:



report的值表示设置的字符串

而实验室要求的长度为48,明显长度不够。


下图为反编译出来的smail代码,增加5700的长度。



反编译后得到的smail代码

Step 7. 重新打包&签名apk,验证效果。


通过抓取的log分析,report值已经改变,证明修改已经生效。



修改后抓取的log

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测试规范

下载后,发现文件名称叫HFP.TS.1.7.1.1.pdf,明明下的是1.5版本,怎么又变成1.7了?打开HFP.TS.1.7.1.1.pdf,从标题可以看出1.5-1.7都通用1.7的测试文档。



HFP.TS.1.7.1.1

Step 2. 搜索case id "TP/ECC/BI-03-I" ,找到测试步骤描述。


大概的意思是HF发送一条AT指令给AG(我们的手机),AG收到指令后,需要回复ERROR,测试才能pass。



HFP TP/ECC/BI-03-I

乍一看会觉得很奇怪,其他测试项都是回复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功能的。



HCI log

Step 4. 确认PICS中Enhanced Call Control的支持情况


和实验室确认,由于我们填写的PICS里面Enhanced Call Control写的是不支持,导致该fail,修改Enhanced Call Control为支持,测试通过。




分享给朋友:
您可能感兴趣的文章:
随机阅读: