Написать средство запуска тестов Tradefed

На этой странице описывается, как написать новую программу запуска тестов в Tradefed.

Фон

Если вам интересно о месте тестирования бегунов в архитектуре Tradefed см Структуры тестового Runner .

Это не является предварительным условием для написания нового средства выполнения тестов; исполнители тестов могут быть написаны изолированно.

Минимум: реализация интерфейса

Голый минимум квалифицировать как тест бегун Tradefed является реализация интерфейса IRemoteTest и более конкретно run(TestInformation testInfo, ITestInvocationListener listener) метод.

Этот метод вызывается жгутом при использовании средства запуска тестов, аналогично Java Runnable.

Каждая часть этого метода считается частью выполнения средства запуска тестов.

Отчет о результатах тестового запуска

run метод базового интерфейса доступа дать слушателю объект типа ITestInvocationListener . Этот объект является ключом к сообщению структурированных результатов от средства выполнения тестов к системе.

Сообщая структурированные результаты, средство выполнения тестов имеет следующие свойства:

  • Сообщите надлежащий список всех выполненных тестов, сколько времени они длились, прошли ли они индивидуально, не прошли ли они или в некоторых других состояниях.
  • Сообщите метрики, связанные с тестами, если применимо, например метрики времени установки.
  • Подходит для большинства инструментов инфраструктуры, например для отображения результатов и показателей и т. Д.
  • Обычно легче отлаживать, так как отслеживание выполнения более детально.

Тем не менее, представление структурированных результатов необязательно; исполнитель тестов может просто захотеть оценить состояние всего прогона как ПРОШЕЛ или НЕ ПРОШЕЛ, без каких-либо подробностей о фактическом выполнении.

ПРИМЕЧАНИЕ. Сложнее реализовать бегуна, который следует последовательности событий, но мы рекомендуем сделать это, учитывая перечисленные выше преимущества.

Следующие события могут быть вызваны на слушателе, чтобы уведомить проводку о текущем ходе выполнения:

  • testRunStarted: уведомляет о начале группы связанных вместе тестовых случаев.
    • testStarted: уведомляет о начале запуска тестового примера.
    • testFailed / testIgnored: Уведомить об изменении состояния выполняемого тестового примера. Тестовый пример без изменения состояния считается пройденным.
    • testEnded: уведомить об окончании тестового примера.
  • testRunFailed: Сообщите, что общий статус выполнения группы тестовых примеров - сбой. Пробный запуск может быть пропуском или неисправность независимо от тестовых случаев приводят в зависимости от того, что исполнение ожидало. Например, двоичный работают несколько тестовых случаев могут сообщать о всех случаях пройти тест , но с кодом выхода ошибок (по каким - либо причинам: утечка файлы и т.д.).
  • testRunEnded: уведомить об окончании группы тестовых случаев.

Поддержание и обеспечение надлежащего порядка обратных вызовов является обязанностью испытательного бегуна реализатору, например , гарантируя , что testRunEnded вызывается в случае исключения , используя , finally , пункт.

Тестовые примеры обратных вызовов ( testStarted , testEnded и т.д.) не являются обязательными. Тестовый запуск может происходить без каких-либо тестовых примеров.

Вы можете заметить , что эта структура событий вдохновило от типичной структуры JUnit . Это сделано специально, чтобы приблизить вещи к чему-то базовому, о чем разработчики обычно знают.

Журналы отчетов от средства запуска тестов

Если вы пишете свой собственный Tradefed тестового класса или бегун, вы будете осуществлять IRemoteTest и получить ITestInvocationListener через run() метод. Этот слушатель можно использовать для журналирования файлов следующим образом:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

Тестирование с устройством

Приведенный выше минимальный интерфейс позволяет запускать очень простые тесты, которые изолированы и не требуют каких-либо конкретных ресурсов, например модульные тесты Java.

Тестовые писатели , которые хотят , чтобы перейти к следующему этапу тестирования устройства потребуется следующие интерфейсы:

  • IDeviceTest позволяет получить ITestDevice объект , который представляет устройство в соответствии с испытанием и обеспечивает API для взаимодействия с ней.
  • IBuildReceiver позволяет тест , чтобы получить IBuildInfo объект , созданный на шаге поставщика сборки , содержащий всю информацию и артефакты , связанные с испытательной установкой.

Участники тестирования обычно интересуются этими интерфейсами, чтобы получить артефакты, связанные с выполнением, например, дополнительные файлы, и получить тестируемое устройство, которое будет использоваться во время выполнения.

Тестирование на нескольких устройствах

Tradefed поддерживает одновременное выполнение тестов на нескольких устройствах. Это полезно при тестировании компонентов, требующих внешнего взаимодействия, таких как соединение телефона и часов.

Для того , чтобы написать тест бегун , который может использовать несколько устройств, вам необходимо будет осуществить IMultiDeviceTest , что позволит получить карту ITestDevice к IBuildInfo , который содержит полный список представлений устройств и связанной с ними информацией сборки.

Сеттер из интерфейса всегда будет вызываться до run метода, так что можно предположить , что структура будет доступна , когда run называется.

Тесты знают о своих настройках

ПРИМЕЧАНИЕ. Это не очень распространенный вариант использования. Он задокументирован для полноты картины, но, как правило, он вам не понадобится.

Некоторые реализации тест бегун может понадобиться информация об общей установке, чтобы работать должным образом, например , некоторые метаданные о вызове, или какой target_preparer забежав вперед, и т.д.

Для того , чтобы достичь этого, тест бегун может получить доступ к IConfiguration объекта он является частью , и что он выполняется в. См объекта конфигурации описания для более подробной информации.

Для выполнения теста бегуна, вам необходимо будет осуществить IConfigurationReceiver на получение IConfiguration объекта.

Гибкий тестовый прогон

Исполнители тестов могут предоставить гибкий способ выполнения своих тестов, если у них есть детальный контроль над ними, например, средство выполнения тестов JUnit может индивидуально запускать каждый модульный тест.

Это позволяет большую жгут и инфраструктуру для рычага управления , которые хорошо и пользователям запускать частично тест бегун с помощью фильтрации.

Фильтрация поддержка описана в интерфейсе ITestFilterReceiver , что позволяет получить наборы include в exclude include и exclude фильтров для испытаний , которые должны или не должны запускать.

Наше соглашение заключается в том, что тест будет запускаться, если он соответствует одному или нескольким включаемым фильтрам И не соответствует ни одному из исключающих фильтров. Если фильтры включения не заданы, следует запускать все тесты до тех пор, пока они не соответствуют ни одному из фильтров исключения.

ПРИМЕЧАНИЕ. Мы рекомендуем, чтобы программы запуска тестов были написаны таким образом, чтобы поддерживать эту фильтрацию, поскольку она обеспечивает огромную добавленную стоимость в более крупной инфраструктуре. Но мы понимаем, что в некоторых случаях это невозможно.