一种用于蓝牙TX和RX吞吐性能产线测试的方法及装置与流程

本发明涉及性能测试领域，具体涉及一种用于蓝牙tx和rx吞吐性能产线测试的方法及装置。

背景技术

蓝牙技术目前在消费类电子产品已经得到广泛的应用，随着低功耗蓝牙技术的推进，蓝牙技术将会在更广泛的领域应用。蓝牙音频作为蓝牙技术应用最重要的一个领域，随着人们对音频音质追求的提升，对无线音频设备的传输带宽要求也越来越高，android8.0系统对蓝牙数据传输的速率高达990kbps，相比android7.0系统蓝牙传输速率提升了3倍。

目前对于蓝牙产品的生产测试，分为半成品测试和成品测试。半成品测试一般集中在rf测试方面，需要专业的测试仪器(如综测仪)连接设备进行测试，但是存在测试仪器昂贵、测试步骤复杂的问题；成品测试一般集中在蓝牙连接测试、距离测试等方面，这种测试不能对蓝牙的天线性能、天线功率、蓝牙控制器的处理性能进行测试，进而无法确认这些因素在蓝牙成品组装过程中是否对蓝牙性能造成影响。蓝牙吞吐测试和丢包测试能间接快速得到蓝牙天线性能、蓝牙控制器性能对实际产品的影响，是蓝牙成品测试中的一个重要步骤。

在已有方案中，还未提出应用在蓝牙工厂测试中的吞吐性能评估方法，部分方案提出利用蓝牙信号强度rssi值获取蓝牙天线的输出功率和灵敏度，但缺少对蓝牙吞吐和丢包性能评估的方法。

技术实现要素：

本发明提供了一种可以在工厂生产中快速评估蓝牙成品性能好坏的方法，提高生产效率，降低生产成本。

为实现上述技术效果，本发明公开了一种用于蓝牙tx吞吐性能的产线测试方法，其特征在于，包括：

步骤1：启动server端程序，读取蓝牙适配器的蓝牙mac地址；

步骤2：启动client端程序，获取所述蓝牙适配器的蓝牙mac地址；

步骤3：待测蓝牙设备与所述蓝牙适配器根据所述蓝牙mac地址建立连接；

步骤4：所述待测蓝牙设备向所述蓝牙适配器发送用于测试的数据包；

步骤5：测试结束后，输出tx吞吐率测试结果。

优选的，所述方法还包括：

在启动server端程序之前，还可包括下述设置操作：主机上的测试脚本读取测试用例，解析待测数据包类型，以及设置统计次数。

优选的，所述步骤1还包括：

控制单元1中的server端程序开始执行后，首先读出连接在控制单元1上的蓝牙适配器的本地mac地址，然后通过adb命令传输给主机上的测试脚本；

所述控制单元1位于所述蓝牙适配器一侧。

优选的，所述步骤2还包括：

通过主机上的测试脚本将在所述步骤1中获取的所述蓝牙适配器的蓝牙mac地址传送给控制单元2；

所述控制单元2位于所述待测蓝牙设备一侧。

优选的，所述步骤3包括：

所述待测蓝牙设备一侧的client端程序启动后，根据主机传输过来的所述蓝牙mac地址，通过hci指令直接与所述蓝牙适配器建立蓝牙连接。

优选的，所述方法还包括：

所述待测蓝牙设备与所述蓝牙适配器建立连接之后，测试吞吐性能之前，通过控制单元1和控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的packetmask属性。

优选的，所述方法还包括：

所述待测蓝牙设备与所述蓝牙适配器建立连接之后，测试吞吐性能之前，通过控制单元1和控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的auto-flush机制。

优选的，所述方法还包括：

以固定时长作为预设的统计周期来计算所述预设的统计周期内所述待测蓝牙设备的吞吐方差值和平均吞吐速率。

优选的，所述方法还包括：

在测试开始之前，为client端的每包测试数据中加入crc校验信息和发送序号信息；

server端根据crc校验信息判断接收数据的完整性。

相应的，本发明还提出了一种用于蓝牙tx吞吐性能的产线测试装置，其特征在于，包括：

server端蓝牙mac地址获取模块，用于启动server端程序，读取蓝牙适配器的蓝牙mac地址；

client端蓝牙mac地址获取模块，用于启动client端程序，获取所述蓝牙适配器的蓝牙mac地址；

连接创建模块，用于控制所述待测蓝牙设备与所述蓝牙适配器根据所述蓝牙mac地址建立连接；

数据交互模块，用于所述待测蓝牙设备向所述蓝牙适配器发送用于测试的数据包控制；

测试结果输出模块，用于在测试结束后，输出tx吞吐率测试结果。

优选的，所述装置还包括：

配置模块，用于在启动server端程序之前，控制主机上的测试脚本读取测试用例，解析待测数据包类型，以及设置统计次数。

优选的，所述装置还包括：

控制单元1内的server端蓝牙mac地址获取模块开始执行后，首先读出连接在控制单元1上的蓝牙适配器的本地mac地址，然后通过adb命令传输给主机上的测试脚本；

所述控制单元1位于所述蓝牙适配器一侧。

优选的，所述连接创建模块还包括：

控制主机上的测试脚本将获取的所述蓝牙适配器的蓝牙mac地址传送给控制单元2；

所述控制单元2位于所述待测蓝牙设备一侧。

优选的，所述连接创建模块还包括：

根据主机传输过来的所述蓝牙mac地址，通过hci指令控制所述蓝牙适配器与所述待测蓝牙设备建立连接。

优选的，所述控制单元1和2还包括：

在所述待测蓝牙设备与所述蓝牙适配器建立连接之后，测试吞吐性能之前，设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的packetmask属性。

优选的，所述控制单元1和2还包括：

在所述待测蓝牙设备与所述蓝牙适配器建立连接之后，测试吞吐性能之前，通过控制单元1和控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的auto-flush机制。

优选的，所述控制单元1和2还包括：

以固定时长作为预设的统计周期来计算所述预设的统计周期内所述待测蓝牙设备的吞吐方差值和平均吞吐速率。

优选的，所述控制单元1和2还包括：

在测试开始之前，为client端的每包测试数据中加入crc校验信息和发送序号信息；

server端根据crc校验信息判断接收数据的完整性。

本发明还提出了一种用于蓝牙rx吞吐性能的产线测试方法，其特征在于，包括：

步骤1：启动client端程序，读取蓝牙适配器的蓝牙mac地址；

步骤2：启动server端程序，获取所述蓝牙适配器的蓝牙mac地址；

步骤3：待测蓝牙设备与所述蓝牙适配器根据所述蓝牙mac地址建立连接；

步骤4：所述蓝牙适配器向所述待测蓝牙设备发送用于测试的数据包；

步骤5：测试结束后，输出rx吞吐率测试结果。

优选的，所述步骤4还包括：

所述待测蓝牙设备与所述蓝牙适配器建立无线连接之后，通过控制单元1和控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的packetmask属性。

优选的，所述步骤4还包括：

通过控制单元1和控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的auto-flush机制。

优选的，所述步骤4包括：

client端程序以理论最大吞吐速率控制所述蓝牙适配器向所述待测蓝牙设备发送测试数据，所述理论最大吞吐速率由测试脚本根据测试用例进行指定；

其中，在计算待测设备rx吞吐速率时以server端的所述待测蓝牙设备成功接收到的吞吐速率作为实际测得的吞吐速率。

优选的，所述步骤5包括：

计算所述待测蓝牙设备的rx吞吐速率以1秒为统计周期，每1秒更新这时间段内的瞬时吞吐速率，根据所述瞬时吞吐速率计算所述统计周期内所述待测蓝牙设备的吞吐方差值和平均吞吐速率；

其中，在进行测试最大吞吐率时，client端在每包测试数据中加入crc校验信息和发送序号信息rx_count，server端根据crc校验信息判断接收数据的完整性，当判断出接收数据的crc校验信息与发送数据的crc校验信息一致时，则认为数据被成功接收，所述rx_count用于在统计时表征丢包信息；

在测试结束后，输出记载有所述待测蓝牙设备rx吞吐方差值和平均吞吐速率值的测试报告。

相应的，本发明还提出了一种用于蓝牙rx吞吐性能的产线测试装置，其特征在于，包括：

client端蓝牙mac地址获取模块，用于启动client端程序，读取蓝牙适配器的蓝牙mac地址；

server端蓝牙mac地址获取模块，用于启动server端程序，获取所述蓝牙适配器的蓝牙mac地址；

连接创建模块，用于控制所述待测蓝牙设备与所述蓝牙适配器根据所述蓝牙mac地址建立连接；

数据交互模块，用于所述待测蓝牙设备向所述蓝牙适配器发送用于测试的数据包控制；

测试结果输出模块，用于在测试结束后，输出rx吞吐率测试结果。

优选的，所述数据交互模块还包括如下功能：

所述待测蓝牙设备与所述蓝牙适配器建立无线连接之后，通过控制单元1和控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的packetmask属性。

优选的，所述数据交互模块还包括如下功能：

通过控制单元1和控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的auto-flush机制。

优选的，所述数据交互模块还包括如下功能：

client端程序以理论最大吞吐速率控制所述蓝牙适配器向所述待测蓝牙设备发送测试数据，所述理论最大吞吐速率由测试脚本根据测试用例进行指定；

其中，在计算待测设备rx吞吐速率时以server端的所述待测蓝牙设备成功接收到的吞吐速率作为实际测得的吞吐速率。

优选的，所述测试结果输出模块还包括如下功能：

计算所述待测蓝牙设备的rx吞吐速率以1秒为统计周期，每1秒更新这时间段内的瞬时吞吐速率，根据所述瞬时吞吐速率计算所述统计周期内所述待测蓝牙设备的吞吐方差值和平均吞吐速率；

其中，在进行测试最大吞吐率时，client端在每包测试数据中加入crc校验信息和发送序号信息rx_count，server端根据crc校验信息判断接收数据的完整性，当判断出接收数据的crc校验信息与发送数据的crc校验信息一致时，则认为数据被成功接收，所述rx_count用于在统计时表征丢包信息；

在测试结束后，输出记载有所述待测蓝牙设备rx吞吐方差值和平均吞吐速率值的测试报告。

本发明公开了一种用于蓝牙tx和rx吞吐性能产线测试的方法及装置，适用于但不限于使用蓝牙适配器作为辅助测试设备与待测设备建立连接数据传输测试，利用packetmask属性和auto-flush机制，精确控制蓝牙物理层传输使用的包类型，设计一套应用在工厂生产中的吞吐率、丢包率测试方法，利用统计方法，得出对蓝牙产品性能好坏的评估，其特点在于测试平台方便搭建，测试过程无须人工参与，提高了生产效率。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1为本发明实施例一中一种进行蓝牙吞吐性能测试方法的系统框架图；

图2为本发明实施例二中一种用于蓝牙tx吞吐性能产线测试的方法流程图；

图3为本发明实施例二中一种用于蓝牙tx吞吐性能产线测试的详细流程图；

图4为本发明实施例四中一种用于蓝牙吞吐性能产线测试的软件实现流程图；

图5为本发明实施例三中一种用于蓝牙rx吞吐性能产线测试的方法流程图；

图6为本发明实施例四中一种用于蓝牙吞吐性能产线测试的方法流程图；

图7为本发明实施例五～七中一种用于蓝牙吞吐性能产线测试的装置模块图。

具体实施方式

为使本发明的目的、技术方案及效果更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例一

图1所示为实施本发明中一种进行蓝牙吞吐性能测试方法的系统框架图，整个系统结构分为五个子模块：蓝牙适配器、待测蓝牙设备、控制单元、主机、无线干扰源。其中，控制单元是集成处理芯片和显示器的测试设备，要求具有usb和uart扩展接口，包括控制单元1和控制单元2，主机通过两条usb数据线分别与控制单元1和控制单元2相连，控制单元1与控制单元2分别与所述蓝牙适配器和所述待测蓝牙设备通过usb或uart接口相连。

为尽可能模拟真实使用环境，测试中待测蓝牙设备与蓝牙适配器之间采用无线传输，通过wifi路由器的布置人为制造无线干扰环境，具体布置数量和位置要求根据实际测试需求指定。

为了屏蔽人为制造的无线干扰信号对蓝牙适配器信噪比的影响，将蓝牙适配器和控制单元1置于屏蔽箱内，在具体实施时屏蔽箱可固定在产线工装上。

主机采用习见的上位机，通过usb数据线与控制单元1和控制单元2连接。用于执行本发明中蓝牙吞吐性能测试方法的程序运行在控制单元1和控制单元2上，主机通过adb命令控制控制单元上的程序运行和测试结果抓取，整个测试过程通过自动化脚本执行，中间无须人工手动参与。

控制单元1通过usb接口与蓝牙适配器连接，控制单元2通过uart或usb接口与待测蓝牙设备连接，运行在控制单元上的测试程序通过hci接口控制待测蓝牙设备与蓝牙适配器建立连接和数据传输。hci接口是蓝牙协议规定的一种逻辑抽象接口，是所有蓝牙控制器都必须支持的协议接口。

实施例二

基于实施例一中的系统框架图，本实施例提出了一种蓝牙tx(transmit)吞吐性能测试方法，用于执行所述方法的程序分为client端和server端来运行，client端作为数据发送和控制的角色，server端作为数据接收和处理的角色。评估待测蓝牙设备tx吞吐性能时，client端程序运行在控制单元2中，server端程序运行在控制单元1中。其中，在执行所述测试方法之前，将client端程序和server端程序都拷贝在控制单元1和控制单元2上，运行在主机的测试脚本根据测试用例需求在控制单元1和控制单元2上自动选择合适的角色程序(client程序或者server程序)进行执行，其过程流程图如图2所示，详细流程图如图3所示，所述测试方法包括如下步骤：

步骤1：启动server端程序，读取蓝牙适配器的蓝牙mac地址。

具体地，运行在控制单元1中的server端程序比运行在控制单元2中的client端程序先执行。

具体地，控制单元1中的server端程序开始执行后，首先读出连接在控制单元1上的蓝牙适配器的本地mac地址，然后通过adb传输给主机上的测试脚本。

具体地，在启动server端程序之前，还可包括下述设置操作：主机上的测试脚本读取测试用例，解析待测数据包类型，以及设置统计次数。

步骤2：启动client端程序，获取所述蓝牙适配器的蓝牙mac地址。

具体地，通过主机上的测试脚本将在所述步骤1中获取的所述蓝牙适配器的蓝牙mac地址传送给控制单元2。

步骤3：待测蓝牙设备与所述蓝牙适配器根据所述蓝牙mac地址建立连接。

具体地，client端程序启动后，根据主机传输过来的所述蓝牙mac地址，通过hci指令直接与所述蓝牙适配器建立蓝牙连接。通过这一连接方式可以节省待测蓝牙设备扫描查询所述蓝牙适配器的时间，实际蓝牙扫描查询周围蓝牙设备的时间是建立蓝牙连接过程中最耗时的过程，因为空中无线干扰等的影响，有时需要扫描查询多次才能成功，大大降低了生产测试效率。本方法中的server端程序通过hci_read_bd_addrhci指令获取蓝牙适配器的mac地址，通过主机中转传输给待测蓝牙设备，待测蓝牙设备根据蓝牙适配器mac地址直接与蓝牙适配器建立连接。

步骤4：所述待测蓝牙设备向所述蓝牙适配器发送用于测试的数据包。

具体地，所述待测蓝牙设备与所述蓝牙适配器建立无线连接之后，通过所述控制单元1和所述控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的packetmask属性，所述packetmask可以精确蓝牙物理链路使用某种类型的数据包。在对蓝牙进行测试时，数据包的长度影响蓝牙链路物理层传输使用的数据包类型，而不同类型的数据包抗干扰特性又不一样，因此在实施具体测试操作时，要根据需要测试的数据包类型生成对应长度范围的数据包，所述对应长度范围的数据包由控制单元2中的软件程序随机生成，这样就可保证每次传输测试的数据包长度都不一致，但却都可控制在对应数据包类型传输的长度之内。下表示出了数据包长度与物理层使用的数据包类型的对应关系。

值得注意的是，packetmask属性决定物理链路进行数据传输所使用的包类型，由于蓝牙不同包类型的编码方式、抗干扰性、可携带数据量都是不同的，所以packetmask直接影响传输数据量总大小，默认情况下，物理链路进行数据传输所使用的包类型是动态变化的，由携带的数据长度和空中环境干扰决定，这给评估不同包类型传输性能造成影响，而本发明通过packetmask属性控制传输的包类型，优先选择与待传输数据包长最接近的数据包来进行数据传输，从而能够使得蓝牙吞吐率测试更为准确。

具体的，packetmask参数的设置通过标准hci指令changeconnectionpackettypecommand实现。

下面以具体实例来说明packetmask机制对蓝牙吞吐率的影响作用，在蓝牙性能测试中，设置包长为350bytes,若packetmask设置支持2-dh3类型的数据包，那么由于2-dh3包负载区间(339,367)正好满足350byte负载，因此，测试设备会优先选择最接近设置包长的2-dh3数据包来传输数据；若packetmask设置不支持2-dh3类型的数据包，则测试设备会根据packetmask限制选择其他类型的数据包，这样传递数据会产生分片或其他开销造成传输效率降低引起吞吐率降低。

具体地，影响丢包率性能的重要因素是外部无线干扰和数据包长度，为尽可能模拟真实使用场景，在测试平台环境周围布置wifi路由器来增加无线干扰。

具体地，所述待测蓝牙设备与所述蓝牙适配器建立无线连接之后，通过所述控制单元1和所述控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的auto-flush机制。所述auto-flush机制是一种软硬件结合的机制，现在蓝牙设备硬件上一般都支持标准auto-flush接口，所述auto-flush机制能有效避免因为数据丢包导致数据包在基带的无限重传，进而影响蓝牙应用数据堵塞无法及时将数据发送出去的问题，使用auto-flush机制需要配合合适的数据包超时时间，如果在规定时间内数据包没有成功发送出去，硬件则自动清除当前发送的数据包并发送下一个待发送的数据包，这样通过合适的软件方法就能在接收端判断丢包率，这种丢包性能对于需保证数据传输的实时性，而对数据的完整性通过其他手段补偿的场景非常重要，例如蓝牙音频应用。优选的，将链路auto-flush的时间设置为1秒，具体软件实施方式为启动一个1秒定时器线程，通过回调函数计算1秒内成功发送数据的字节数。

具体的，auto-flush机制指定待测设备包传输超时时间，由于auto-flush机制的存在，在较差的传输环境应用层不会阻塞，对应传输数据量会提高，吞吐率相对会提高，但存在一定的丢包率。

具体地，client端程序以理论最大吞吐速率控制所述待测蓝牙设备向所述蓝牙适配器发送测试数据，所述理论最大吞吐速率由测试脚本根据测试用例进行指定，在实际测试过程中，由于硬件调度性能、无线干扰丢包的影响，真实的待测设备tx吞吐速率无法达到理论的tx吞吐速率，所以在计算待测设备tx吞吐速率时以server端成功接收到的吞吐速率为准。

具体地，server端程序和client端程序采用双线程实现方法，以clilent端程序为例，其中一个线程负责发送待测蓝牙数据，另一个线程负责计算数据发送的吞吐速率，通过双线程的实现方法提高了程序的可靠性和吞吐丢包性能测试的准确性。

步骤5：测试结束后，输出tx吞吐率测试结果。

具体地，计算待测蓝牙设备的tx吞吐速率是以1秒为统计周期，每1秒更新这时间段内的瞬时吞吐速率，根据这些瞬时吞吐速率利用统计方法可以计算测试时间内待测设备的吞吐方差值和平均吞吐速率。吞吐方差值和平均吞吐速率将作为评估待测蓝牙设备性能的重要指标，吞吐方差值反映待测蓝牙设备吞吐的稳定性，数值越小代表待测蓝牙设备数据传输越稳定；平均吞吐速率反映待测蓝牙设备吞吐最大的速率，数值越大代表待测蓝牙设备单位时间内可传输的数据量越大。

具体的，吞吐率的具体计算方法为：吞吐率(kbps)＝单次性能测试传输数据量总和/单位时间。

具体地，在进行测试最大吞吐率同时，为保证数据的完整性，client端在每包测试数据中加入crc校验信息和发送序号信息tx_count，server端根据crc校验信息判断接收数据的完整性，只有接收数据的crc校验信息与发送数据的crc校验信息一致时，才认为数据被成功接收，tx_count在统计时能清楚反映哪一包数据丢失了。

具体地，在测试结束后，输出记载有所述待测蓝牙设备tx吞吐方差值和平均吞吐速率值的测试报告。

实施例三

基于实施例一中的系统框架图，本实施例提出一种测试蓝牙设备rx吞吐性能的方法，与实施例二中不同的是，在测试蓝牙设备rx吞吐性能时，由待测蓝牙设备充当数据接收端，由蓝牙适配器充当数据发送端，在实施具体操作时，令client端程序运行在控制单元1中，server端程序运行在控制单元2中。

由于rx吞吐性能测试流程与实施例二中的tx吞吐性能测试流程相似，故在本实施例中仅对二者的不同之处进行说明，相同之处则不再赘述，其测试流程图如图5所示。

在测试准备阶段，先启动所述蓝牙适配器一端的client端程序，读取client端控制单元1连接的蓝牙适配器的mac地址；然后启动所述待测蓝牙设备一端的server端程序，传输client端的所述蓝牙适配器的mac地址给server端程序；从而使所述待测蓝牙设备与所述蓝牙适配器之间建立连接。

在测试过程中以及测试完成后的统计阶段，蓝牙适配器以client端程序运行，向所述待测蓝牙设备以理论最大吞吐速率发送测试数据，所述待测蓝牙设备以server端程序运行，server端计算的rx吞吐率为所述待测蓝牙设备真实的rx吞吐性能。

在测试结束后，输出记载有所述待测蓝牙设备rx吞吐方差值和平均吞吐速率值的测试报告。

实施例四

基于实施例一中的系统框架图，本实施例中的测试方法将实施例二与实施例三中的测试方法进行融合，从而提出一种测试蓝牙设备吞吐率的方法，其中包括tx吞吐性能测试和rx吞吐性能测试。

由于该测试方法中的吞吐性能测试流程与实施例二、三中的tx、rx吞吐性能测试流程相似，故在本实施例中仅对不同之处进行说明，相同之处则不再赘述，其测试流程图如图6所示，其软件实现流程图如图4所示。

其中测试分为两个阶段，第一阶段为对所述待测蓝牙设备进行tx吞吐性能测试，在测试准备阶段，先启动所述蓝牙适配器一端的server端程序，读取server端控制单元1连接的蓝牙适配器的mac地址；然后启动所述待测蓝牙设备一端的client程序，传输server端的所述蓝牙适配器的mac地址给client端程序；从而使所述待测蓝牙设备与所述蓝牙适配器之间建立连接；在建立好连接之后由所述待测蓝牙设备向所述蓝牙适配器发送测试数据，以所述蓝牙适配器实际接收到的tx吞吐率作为实际计算得到的tx吞吐率。

第二阶段为对所述待测蓝牙设备进行rx吞吐性能测试，由于在第一阶段已经建立了所述待测蓝牙设备与所述蓝牙适配器之间的连接关系，因此在所述第二阶段测试时无需再次建立二者之间的连接关系；在这一阶段中对rx吞吐率的测试方法与实施例三中的测试方法相同。

在完成两个阶段的测试后，生成并输出记载有所述tx和rx性能的吞吐率测试报告。

实施例五

参见图7，示出了本申请一种用于蓝牙tx吞吐性能产线测试的装置，具体包括如下模块：

server端蓝牙mac地址获取模块，用于控制：运行在控制单元1中的server端程序比运行在控制单元2中的client端程序先执行；控制单元1中的server端程序开始执行后，首先读出连接在控制单元1上的蓝牙适配器的本地mac地址，然后通过adb传输给主机上的测试脚本；在启动server端程序之前，该模块还可包括下述设置操作：主机上的测试脚本读取测试用例，解析待测数据包类型，以及设置统计次数。

client端蓝牙mac地址获取模块，用于控制：通过主机上的测试脚本将在所述server端蓝牙mac地址获取模块获取的所述蓝牙适配器的蓝牙mac地址传送给控制单元2。

连接创建模块，用于控制所述待测蓝牙设备与所述蓝牙适配器根据获取到的所述蓝牙mac地址建立连接；具体地，client端程序启动后，根据主机传输过来的所述蓝牙mac地址，通过hci指令直接与所述蓝牙适配器建立蓝牙连接。通过这一连接方式可以节省待测蓝牙设备扫描查询所述蓝牙适配器的时间，实际蓝牙扫描查询周围蓝牙设备的时间是建立蓝牙连接过程中最耗时的过程，因为空中无线干扰等的影响，有时需要扫描查询多次才能成功，大大降低了生产测试效率。本方法中的server端程序通过hci_read_bd_addrhci指令获取蓝牙适配器的mac地址，通过主机中转传输给待测蓝牙设备，待测蓝牙设备根据蓝牙适配器mac地址直接与蓝牙适配器建立连接。

数据交互模块，用于控制待测蓝牙设备向蓝牙适配器发送用于测试的数据包；具体地，所述待测蓝牙设备与所述蓝牙适配器建立无线连接之后，通过所述控制单元1和所述控制单元2设置所述待测蓝牙设备与所述蓝牙适配器的连接链路之间的packetmask属性，所述packetmask可以精确蓝牙物理链路使用某种类型的数据包。在对蓝牙进行测试时，数据包的长度影响蓝牙链路物理层传输使用的数据包类型，而不同类型的数据包抗干扰特性又不一样，因此在实施具体测试操作时，要根据需要测试的数据包类型生成对应长度范围的数据包，所述对应长度范围的数据包由控制单元2中的软件程序随机生成，这样就可保证每次传输测试的数据包长度都不一致，但却都可控制在对应数据包类型传输的长度之内。下表示出了数据包长度与物理层使用的数据包类型的对应关系。

测试结果输出模块，用于在测试结束后，输入tx吞吐测试结果。计算待测蓝牙设备的tx吞吐速率是以1秒为统计周期，每1秒更新这时间段内的瞬时吞吐速率，根据这些瞬时吞吐速率利用统计方法可以计算测试时间内待测设备的吞吐方差值和平均吞吐速率。吞吐方差值和平均吞吐速率将作为评估待测蓝牙设备性能的重要指标，吞吐方差值反映待测蓝牙设备吞吐的稳定性，数值越小代表待测蓝牙设备数据传输越稳定；平均吞吐速率反映待测蓝牙设备吞吐最大的速率，数值越大代表待测蓝牙设备单位时间内可传输的数据量越大；在进行测试最大吞吐率同时，为保证数据的完整性，client端在每包测试数据中加入crc校验信息和发送序号信息tx_count，server端根据crc校验信息判断接收数据的完整性，只有接收数据的crc校验信息与发送数据的crc校验信息一致时，才认为数据被成功接收，tx_count在统计时能清楚反映哪一包数据丢失了；在测试结束后，输出记载有所述待测蓝牙设备tx吞吐方差值和平均吞吐速率值的测试报告。

实施例六

参见图7，示出了本申请一种用于蓝牙rx吞吐性能产线测试的装置，与实施例五中不同的是，在测试蓝牙设备rx吞吐性能时，由待测蓝牙设备充当数据接收端，由蓝牙适配器充当数据发送端，在实施具体操作时，令client端程序运行在控制单元1中，server端程序运行在控制单元2中。该装置具体包括如下模块：

client端蓝牙mac地址获取模块，用于获取所述蓝牙适配器的蓝牙mac地址。

server端蓝牙mac地址获取模块，用于通过主机接收从所述client端传送过来的所述蓝牙适配器的所述蓝牙mac地址。

连接创建模块、数据交互模块和测试结果输出模块与实施例五中类似，相似之处在此不再赘述，区别在于利用所述待测蓝牙设备上server端程序成功接收到的rx吞吐率作为实际计算得到的rx吞吐率。

实施例七

基于实施例一中的系统框架图，本实施例中的测试方法将实施例五与实施例六中的测试方法进行融合，从而提出一种用于蓝牙设备性能产线测试的装置，该装置可同时实现tx吞吐性能测试和rx吞吐性能测试。

由于该测试装置中的吞吐性能测试装置与实施例五、六中的tx、rx吞吐性能测试装置相似，故在本实施例中仅对不同之处进行说明，相同之处则不再赘述，其测试装置如图7所示，利用该测试装置进行tx和rx吞吐率测试的过程参见图4所示。

本发明公开了一种用于蓝牙tx吞吐性能产线测试的方法、装置及系统，适用于但不限于使用蓝牙适配器作为辅助测试设备与待测设备建立连接数据传输测试，利用packetmask属性和auto-flush机制，精确控制蓝牙物理层传输使用的包类型，设计一套应用在工厂生产中的吞吐率、丢包率测试方法，利用统计方法，得出对蓝牙产品性能好坏的评估，其特点在于测试平台方便搭建，测试过程无须人工参与，提高了生产效率。

在本发明所提供的几个实施例中，应该理解到，所揭露的方法和终端，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

另外，在不发生矛盾的情况下，上述几个实施例中的技术方案可以相互组合和替换。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附关联图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。系统权利要求中陈述的多个模块或装置也可以由一个模块或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神和范围。