На этой странице описывается, как настроить тесты ACTS.
Источники конфигурации
Android Comms Test Suite (ACTS) имеет три основных источника конфигурации:
- Интерфейс командной строки (CLI)
- Конфигурационный файл ACTS
- Переменные среды
Значения из этих источников объединяются в единую конфигурацию, которая используется для запуска теста ACTS. Если значения указаны в нескольких местах, значения перезаписываются в порядке, указанном выше (где CLI имеет приоритет).
Примечание о переменных окружения
Будьте осторожны при использовании переменных среды для тестов ACTS. Эти значения наименее заметны пользователю, и их не рекомендуется использовать за пределами рабочей станции разработчика. Переменные среды отключаются во время автоматических тестов ACTS, чтобы предотвратить отравление среды.
Обязательные переменные конфигурации
Каждый тест ACTS требует установки следующих переменных.
Пути тестирования ACTS
ACTS запускается из одного основного места входа. В результате местонахождение тестового пути неизвестно бегуну.
Задайте местоположение тестового пути с помощью переменной среды ACTS_TESTPATH или флага -tp / --testpaths в командной строке. Значение может быть списком каталогов.
Тестовые классы ACTS
ACTS должен знать, какие тестовые классы запускать. Это может быть регулярное выражение или список имен тестовых классов.
Чтобы установить это значение, используйте флаг -tc / --test_class в командной строке. Обратите внимание, что этот флаг также принимает список имен классов. Имена классов должны совпадать с соответствующими именами файлов, например, SampleTest должен находиться в SampleTest.py .
Путь к журналу ACTS
У ACTS должно быть место для записи журналов, отличное от STDOUT. ACTS ведет полные журналы отладки, содержащие данные, которые могут помочь определить, почему некоторые тесты не пройдены. Во избежание беспорядка ACTS не записывает эти журналы в STDOUT.
Чтобы задать путь журнала, используйте переменную среды ACTS_LOGPATH или флаг -lp / --logpath в командной строке.
Путь конфигурации ACTS
Чтобы запустить тест, ACTS должен знать, какой тестовый стенд существует. Конфигурация ACTS содержит все устройства на испытательном стенде, а также любые специальные параметры тестирования или среды, которые могут потребоваться. Установите это значение в командной строке, используя -c / --config .
Если в конфигурации есть несколько тестовых стендов, ACTS запускает тесты для каждого тестового стенда. Чтобы запустить тест только для одного тестового стенда в списке, используйте аргумент командной строки -tb/--testbed <NAME> .
Пример локальной рабочей станции
Большинство пользователей ACTS разрабатывают в одной ветке репозитория Android и имеют настройку, аналогичную этой:
# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='~/android/<REPO_BRANCH>/tools/test/connectivity/acts_tests/'
# On cmdline
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin
Если пользователи ACTS работают в нескольких ветвях, они часто запускают ACTS из каталога act acts/framework и используют относительный путь для ACTS_TESTPATH :
# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='../acts_tests/'
# On cmdline
$ cd ~/android/master/tools/test/connectivity/acts_tests/acts_contrib/
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin
Настройка ваших тестовых стендов
Файл конфигурации ACTS предоставляет всю необходимую информацию для запуска тестов на аппаратных устройствах:
{
"testbed": {
"my_testbed": {
"my_testbed_value": "value"
},
"another_testbed": {
"AndroidDevice": [
"53R147"
]
}
},
"user_parameter_1": "special environment value",
"user_parameter_2": "other special value"
}
Базовым блоком этой конфигурации является испытательный стенд. В приведенном выше примере конфигурации тестовый стенд my_testbed создается с одним значением тестового стенда. Второй тестовый стенд, another_testbed , имеет специальную конфигурацию контроллера, которая содержит информацию для списка Android-устройств. Эти устройства хранятся в списке устройств в разделе self.android_devices . Обратите внимание, что если испытательный стенд не указывает объект AndroidDevice , тестовый класс, который ожидает объект AndroidDevice , вызывает исключение. Полный список поддерживаемых конфигураций контроллеров, поставляемых с ACTS, см. в списке по адресу /acts/framework/acts/controllers/ .
Все остальные значения (которые не являются специальными значениями, упомянутыми в разделе выше) хранятся в self.user_params в виде словаря. Это хорошее место для хранения информации о среде или тестировании, например о том, находятся ли телефоны в среде измеряемых данных или как долго нужно собирать данные для теста.
Особые случаи для Android-устройства
Для удобства разработки, когда вы хотите иметь несколько устройств с разными свойствами, AndroidDevice имеет несколько особых случаев.
Формат конфигурации JSON
Все пары ключ/значение в приведенном ниже JSON установлены для соответствующего объекта AndroidDevice . Если конфигурация пытается перезаписать параметр, определенный в атрибуте AndroidDevice , выдается ControllerError .
"AndroidDevice": [{"serial": "XXXXXX", "label": "publisher"},
{"serial": "YYYYYY", "label": "subscriber", "user_parameter_1": "anything"}]
Затем в тестовом сценарии вы можете использовать функцию фильтра, чтобы получить правильное устройство и получить доступ к дополнительным параметрам из объекта устройства:
def setup_class(self):
self.pub = next(filter(lambda ad: ad.label == 'publisher',
self.android_devices))
self.sub = next(filter(lambda ad: ad.label == 'user_parameter_1',
self.android_devices))
Необязательный параметр
Ниже приведен необязательный параметр:
-
adb_logcat_param: строка, добавляемая к командеadb logcatдля сбора журналов adb. По умолчанию используетсяadb logcat -v threadtime -b all. Еслиadb_logcat_param, раздел-b allперезаписывается. Например, установка для параметраadb_logcat_param-b radioизменяет команду наadb logcat -v threadtime -b radio.