The sensor uses the standard WPA Supplicant provided by Linux, this is the same supplicant that is usually used in Android devices. WPA Supplicant does its BSSID selection using a variety of factors including energy detection and predicted throughput, and not just raw RSSI. It will choose a BSSID if it thinks it has a better chance of getting a packet sent through on it. 

It is important to remember that the sensor disconnects and associates to the Wi-Fi once a test cycle. Often at the time of association the best BSSID to connect to can be a different one because of changes in the network environment. In addition, the sensor will also roam as a normal client will during the test cycle.

Sensors are usually deployed 1 per 5-8 access points or one per retail location or one per small building floors. This is recommended design to validate user experience for that particular area. Like any other client, the sensor connects to the best available AP. This does not necessarily mean best RSSI, it could be a combination of things including client load balancing and other RF metrics. Basically like any other client the sensor connects to whichever AP is available to respond to the probe request. The aim is to simulate client experience rather than test each individual AP in the area.
Also, it's worth noting that if a sensor is deployed with enough coverage (i.e one per 5-8 APs broadcasting the same SSID), and if one of the APs in the area goes down or is not working, it will be transparent to the end user/client. As long as users can connect to the SSID and browse the internet and required resources, they will likely not experience a degradation in user experience.