Тестирование с testrunner-lite

Для автоматизации выполнения модульного тестирования используется testrunner-lite.

testrunner-lite — это инструмент для выполнения тестов, который считывает XML-файлы в качестве входных данных и создаёт файл результатов теста общего формата. С testrunner-lite можно:

• выполнять автоматические, полуавтоматические и ручные тесты;
• выполнять тесты локально или в режиме хоста самостоятельно или в составе системы автоматизации тестирования;
• использовать параметры и фильтры, чтобы выбрать отдельные тесты для выполнения;
• проверить автоматически используемый файл плана тестирования.

Содержание:

• Опции
• Запуск
  • Выполнение с помощью chroot
  • Выполнение по SSH на хосте
  • Выполнение с помощью Libssh2
• Параметры фильтрации
• Тестирование вручную
• Вердикты тестов
• Управление процессом
• Выполнение на хосте
• Описание тестов в формате XML
• Создание XML-файла с описанием тестов
  • Тесты
  • Группировка тестов: наборы и комплекты
  • Тайм-аут
  • Основная часть тестов
• Контроль среды для выполнения
  • Настройка и очистка
  • Фильтрация на основе идентификатора оборудования
  • Извлечение дополнительных файлов
  • Данные измерений
• Неавтоматические, автоматические и полуавтоматические тесты
• Об атрибуте name

Опции

Программа запускается из командной строки:

/usr/bin/testrunner-lite [options]

Опции testrunner-lite:

• -h, --help — показать справочное сообщение и выйти;
• -V, --version — отобразить версию и выйти;
• -f FILE, --file=FILE — входной файл с описаниями тестов в формате XML (обязательно);
• -o FILE, --output=FILE — выходной файл для результатов теста (обязательно);
• -r FORMAT, --format=FORMAT — формат выходного файла. FORMAT может быть xml или text. По умолчанию xml;
• -e ENVIRONMENT, --environment=ENVIRONMENT — целевая тестовая среда. По умолчанию: аппаратное обеспечение;
• -v, -vv, --verbose[={INFO|DEBUG}] — включить режим подробного описания; -v и --verbose=INFO эквивалентны выводу сообщений INFO, ERROR и WARNING. Аналогично -vv и --verbose=DEBUG эквивалентны, выводят также сообщения отладки. Поведение по умолчанию — тихий режим.
• -L, --logger=URL — удалённый HTTP logger для сообщений журнала. Сообщения журнала отправляются на указанный URL в сообщении HTTP POST. Формат URL-адреса: [http://]host[:port][/path/], где host может быть именем хоста или адресом IPv4.
• -a, --automatic — разрешить выполнение только автоматических тестов;
• -m, --manual — разрешить выполнение только неавтоматических тестов;
• -l FILTER, --filter=FILTER — параметр фильтрации для выбора тестов (не) для выполнения. Например, -testcase=bad_test -type=unknown сначала отключает тест с именем bad_test. Далее все тесты с типом unknown отключены. Остальные тесты будут выполнены. (В настоящее время поддерживаются следующие типы фильтров: testset, testcase, requirement, feature и type).
• -c, --ci — отключить проверку описания теста по схеме;
• -s, --semantic — включить проверку описания теста по более строгой (семантической) схеме;
• -A, --validate-only — провести только проверку XML, не выполнять тесты;
• -H, --no-hwinfo — пропустить получение hwinfo;
• -P, --print-step-output — вывод стандартных потоков из программ, запущенных пошагово;
• -S, --syslog — писать сообщения журнала также в системный журнал;
• -M, --disable-measurement-verdict — не проваливать тесты, основанные на данных измерений;
• --measure-power — выполнить текущее измерение с помощью инструмента hat_ctrl во время выполнения тестов;
• -u URL, --vcs-url=URL — записать указанный URL VCS в результаты;
• -U URL, --package-url=URL — записать указанный URL-адрес пакета в результаты;
• --logid=ID — определяемый пользователем идентификатор для сообщений журнала HTTP;
• -d PATH, --rich-core-dumps=PATH — сохранять rich-core дампы. PATH — это место, где на устройстве создаются дампы. Создаёт UUID-сопоставления между выполненными тестами и сгенерированными дампами. Это позволяет связывать каждый rich-core и тест в отчётах о тестировании. Для этой функции требуется, чтобы на тестируемом устройстве был установлен рабочий пакет sp-rich-core.

Запуск

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

Выполнение с помощью chroot

-C PATH, --chroot=PATH

Данные опции запускают тесты в среде chroot. Следует обратить внимание, что это не меняет корень самого testrunner, только для тестов будет установлен ​​новый корневой каталог.

Выполнение по SSH на хосте

-t [USER@]ADDRESS[:PORT], --target=[USER@]ADDRESS[:PORT]

Включает тестирование на хосте. Команды выполняются со стороны управляющего ПК (хоста), если они даны. ADDRESS — это адрес IPv4 тестируемой системы. При тестировании на хосте используется внешнее выполнение, описанное ниже с SSH и SCP.

-R[ACTION], --resume[=ACTION]

Возобновляет testrun, когда произойдет сбой соединения ssh. Возможные ACTION после возобновления:

• exit — выйти после текущего набора тестов (по умолчанию);
• continue — продолжить в обычном режиме до следующего набора тестов.

-i [USER@]ADDRESS[:PORT], --hwinfo-target=[USER@]ADDRESS[:PORT]

Позволяет получить hwinfo удалённо. Hwinfo обычно получается локально или в случае тестирования на хосте с целевого адреса. Эта опция переопределяет целевой адрес при получении hwinfo. Использование аналогично опции -t.

-k KEY, --ssh-key=KEY

Позволяет указать путь к файлу закрытого ключа SSH.

Выполнение с помощью Libssh2

-n [USER@]ADDRESS, --libssh2=[USER@]ADDRESS

Запускает тестирование на хосте с нативным ssh (libssh2). Экспериментальная функция.

Внешнее исполнение:

-E EXECUTOR, --executor=EXECUTOR

Использует внешнюю команду для выполнения тестовых команд в тестируемой системе. Внешняя команда должна принять тестовую команду в качестве одного дополнительного аргумента и выйти со статусом тестовой команды. Например, внешний исполнитель, который использует SSH для выполнения тестовых команд, может быть /usr/bin/ssh user@target.

-G GETTER, --getter=GETTER

Можно использовать внешнюю команду для получения файлов из тестируемой системы. Внешний метод получения должен содержать <FILE> и <DEST> (с квадратными скобками), где <FILE> будет заменён путем к файлу в тестируемой системе, а <DEST> будет заменён каталогом назначения на хосте. Если <FILE> и <DEST> не указаны, они будут добавлены автоматически. Например, внешний получатель, который использует SCP для извлечения файлов, может быть /usr/bin/scp target:'<FILE>' '<DEST>'.

Параметры фильтрации

Параметры фильтрации позволяют выбрать, какие тесты должны быть выполнены. Они приводятся в виде строки. Строка может содержать одну или несколько записей фильтра. Формат каждой записи filtername=values, где filtername обычно соответствует атрибуту в XML-описании теста, а values — строка, которой должен соответствовать фильтр. Можно указать несколько значений, если они разделены запятой (без дополнительного пробела). Значение, содержащее пробел, должно быть заключено в двойные кавычки (""). Текущий список запрещённых символов в значениях выглядит следующим образом: одинарные кавычки ('), двойные кавычки ("), знак равенства (=), запятая (,).

Как выполняется фильтрация: перед обработкой параметров фильтра все тесты активны по умолчанию. Фильтры могут только деактивировать тесты: если значение фильтра не совпадает со значением соответствующего атрибута, тест отключается. Каждая запись фильтра применяется ко всем активным тестам в тестовом пакете, один за другим, в указанном порядке. Фильтрация всегда выполняется на самом низком уровне иерархии suite-set-case-step, где может быть определён соответствующий атрибут. Следует обратить внимание, что некоторые атрибуты могут наследовать значение от верхнего уровня.

Если перед filtername ставится префикс (-), поведение фильтра меняется на противоположное: те тесты, для которых значение фильтра совпадает, отключаются.

filtername может быть любым из следующих:

• feature;
• requirement;
• testset;
• type;
• testcase.

В следующем примере сначала отключаются все тестовые случаи, кроме тех, которые имеют атрибут type='Integration'. Затем тест с именем Bad Test отключается. Тесты, оставленные активными, будут выполнены.

testrunner-lite -f tests.xml -o ~/results -l 'type=Integration -testcase="Bad Test"'

В следующем примере выполняются тесты, в которых указан атрибут requirement со значением, содержащим хотя бы одну из следующих строк: '50001', '50002', '50003'.

testrunner-lite -f tests.xml -o ~/results -l 'requirement=50001,50002,50003'

Следует обратить внимание, что каждый key=values обрабатывается как отдельный фильтр при проверке необходимости фильтрации тестового примера. В следующем примере будут отфильтрованы все тесты:

testrunner-lite -f tests.xml -o ~/results -l 'testset=set1 testset=set2'

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

testrunner-lite -f tests.xml -o ~/results -l 'testset=set1,set2'

Тестирование вручную

Можно выполнить тесты вручную, используя testrunner-lite.

В случае, если во время выполнения будет обнаружен неавтоматический тест, testrunner-lite пройдёт через описанные тестовые шаги и спросит пользователя, пройден шаг или нет. Тест завершится при первом сбое, в противном случае будет выполнен каждый описанный шаг. После того, как тестовый пример завершен, у пользователя есть возможность ввести дополнительные комментарии.

Пример вывода при запуске вручную:

[INFO] 15:15:53 Starting test case: ExampleTestCase
--- Execute test step ---
Description:
Open calculator. Expected result: calculator opens up.

Please enter the result ([P/p]ass or [F/f]ail):
P

--- Execute test step ---
Description:
Stop calculator

Please enter the result ([P/p]ass or [F/f]ail):
P

--- Test steps executed, case is PASSED ---
Please enter additional comments (ENTER to finish):
Execution was slow.

[INFO] 15:16:41 Finished test case. Result: PASS

Вердикты тестов

Для автоматических тестов результат устанавливается следующим образом:

• PASS — все шаги теста завершены с ожидаемыми результатами;
• FAIL — шаг теста имеет неожиданное возвращаемое значение, тайм-аут теста или провалены предварительные шаги;
• N/A — тест содержит state=Design в tests.xml или тест не содержит шагов.

Если тест фильтруется, он не даёт никакого результата; то есть он вообще не записывается в файл результатов.

Управление процессом

Каждый шаг теста выполняется в отдельной оболочке. testrunner-lite запускает новый процесс для выполнения и ожидает завершения шага (или тайм-аута). Если шаг теста содержит команду, которая запускается в фоновом режиме, этот шаг возвращается немедленно. После завершения тестового примера выполняется процедура очистки, при которой testrunner-lite пытается завершить все процессы, которые, возможно, были оставлены работающими при выполнении шагов теста. Очистка для предварительных шагов и последующих шагов выполняется после выполнения последующих шагов (т. е. после выполнения тестового набора).

Выполнение на хосте

testrunner-lite поддерживает выполнение на хосте, где testrunner-lite выполняется на ПК, а тестирование выполняется по ssh на хосте. Для этого необходимо, чтобы между устройством и хостом была включена ssh-аутентификация на основе ключей.

Следует иметь в виду, что каждый отдельный шаг в pre_steps, post_steps или внутри тестов выполняется в отдельном сеансе SSH. Поэтому нужно убедиться, что если шаги оставят некоторые процессы, работающие в фоновом режиме, которые наследуют свои каналы прямо от родительской оболочки, соединение SSH будет зависать до тех пор, пока эти процессы не будут завершены (или пока они не закроют свои каналы). Следовательно, всегда нужно перенаправлять потоки stdout, stderr и stdin фоновых процессов, чтобы для шагов теста, пред- или постобработки не вышел тайм-аут при выполнении на хосте.

Можно обратиться к FAQ для SSH, чтобы узнать больше деталей.

Описание тестов в формате XML

Основной принцип описания тестов XML и поддержки инструментов заключается в том, что для тестирования можно использовать «любой» исполняемый файл. Результаты теста проверяются по кодам выхода (автоматическое тестирование) или по сообщению от пользователя (тестирование вручную). Выполненный план тестирования XML даёт результаты XML, заключая в себе различные методы тестирования в едином формате, необходимом для автоматизации тестирования и обработки данных.

Основные компоненты информации о плане тестирования, хранящемся в файлах XML:

• suite, set, case — иерархическая структура тестов;
• feature, subfeature, requirement — информация о том, почему тестируемое программное обеспечение было реализовано в первую очередь (и поэтому оно тестируется);
• type — информация о точке зрения тестов (какой аспект качества программного обеспечения они тестируют);
• level — информация о том, к какому уровню относятся тесты;
• domain — информация о том, на каких архитектурных доменах сосредоточены тесты;
• description — описание тестов (что представляет собой каждый тест и что он должен делать);
• step — инструкции по выполнению (для автоматических тестов), которые определяют фактические команды, которые нужно выполнить для запуска каждого теста.

Все вышеперечисленное не является обязательным. Обязательные поля для выполнения тестов определяются с помощью схемы проверки XML для плана тестирования.

Создание XML-файла с описанием тестов

Есть определённые обязательные вещи, которые необходимо предоставить в определении тестов XML.

Структура XML и возможные атрибуты/значения определены в XML-схеме описания теста. Важно проверить XML на соответствие современной схеме.

Планы тестирования могут быть созданы с помощью инструмента Testplanner или вручную.

Тесты

Главное в плане тестирования — это контрольные примеры, которые определяют, что выполнять (этапы тестирования), что ожидать от выполнения (ожидаемые результаты), а также некоторую дополнительную информацию для целей отчётности. Примером теста может быть:

<case name="my-first-case">
   <description>Creating my very first test case</description>
   <step>ls</step>
   <step>uname -r</step>
</case>

Этот код создаёт простой тестовый пример с именем my-first-test-case, который выполняет два шага и ожидает, что они возвращают общее «возвращаемое значение успеха» 0. Если требуется проверить наличие другого возвращаемого значения, можно использовать атрибут expected_result:

<step expected_result="-1">ls</step>

Если известно, что некоторые тесты незначительны, т. е. их не следует принимать во внимание при выборе того, пройден ли набор тестов в целом или нет, можно использовать атрибут insignificant (по умолчанию false, т. е. каждый тест считается значительным):

<case name="not-so-important-test" insignificant="true">
...
</case>

В дополнение к выполнению теста также должна быть дана метаинформация тестового примера, для которой имеются поля для типа теста (какие характеристики качества тестируются) и уровня теста (какой уровень системы используется). Можно добавить уровень и тип в тестовый пример:

<case name="my-first-case" level="Product" type="Functional">
   <description>Creating my very first test case</description>
   <step expected_result="-1">ls</step>
   <step>uname -r</step>
</case>

Первый тестовый пример готов.

Группировка тестов: наборы и комплекты

Группировка тестов в наборы и комплекты делает тестирование проще и организованнее. Хорошая идея — сгруппировать тесты, которые тестируют одни и те же функции, в одни и те же наборы, и наборы, которые тестируют один и тот же архитектурный домен, в одни и те же комплекты. Например:

<suite name="my-multimedia-tests" domain="Multimedia">
   <set name="video-playback-tests" feature="Video Playback">
       <description>Video</description>
       <case ...
       <case ...
   </set>
</suite>

Таким образом, наборы содержат тесты, а также могут содержать описание (так же, как и отдельные тесты).

Тайм-аут

По умолчанию время выполнения шагов теста истечет через 90 секунд. Можно изменить время ожидания по умолчанию, добавив атрибут timeout в тестовый пример. Например:

<case name="my-test-case" timeout="120">

Следует обратить внимание, что это время ожидания для одного шага, а не для всего теста.

Для шагов до и после тестов время ожидания по умолчанию составляет 180 секунд, его также можно изменить:

<pre_steps timeout="600">

Основная часть тестов

Перед разбором примера основной части тестов важно отметить, что все упомянутые атрибуты регистра (например, уровень, тип) являются наследуемыми. Итак, если имеется, например, набор, который содержит только определённые типы тестов, можно определить тип на уровне набора вместо того, чтобы записывать его отдельно в каждом случае.

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

 <?xml version="1.0" encoding="UTF-8"?>
 <testdefinition version="1.0">
 </testdefinition>

Это обязательная часть; определён XML-документ, и именно этот документ является тестовым описанием версии 1.0. Можно добавить один комплект с несколькими наборами:

<?xml version="1.0" encoding="UTF-8"?>
<testdefinition version="1.0">
   <suite name="my-multimedia-tests" domain="Multimedia">
       <description>Testing AF stuff</description>
       <set name="video-playback-tests" feature="Video Playback">
           <description>Video playback tests</description>
       </set>
       <set name="video-recording-tests" feature="Video Recording">
           <description>Video recording tests</description>
       </set>
   </suite>
</testdefinition>

Таким образом, для тестирования имеется один комплект под названием my-multimedia-tests с двумя наборами, тестирующий воспроизведение видео и функции записи. Нужно добавить конкретные тесты:

<?xml version="1.0" encoding="UTF-8"?>
<testdefinition version="1.0">
   <suite name="my-multimedia-tests" domain="Multimedia">
       <description>Video playback tests</description>
       <set name="video-playback-tests" feature="Video Playback">
           <description>Video playback tests</description>
           <case name="playback1" type="Functional" level="Component">
               <step>execute_playback_test</step>
           </case>
       </set>
       <set name="video-recording-tests" feature="Video Recording">
           <description>Video playback tests</description>
           <case ...
       </set>
   </suite>
</testdefinition>

Описание тестов готово.

Контроль среды для выполнения

Настройка и очистка

Если нужно выполнить некоторые настройки и очистку до и после выполнения тестов, в наборах могут быть пред- и постобработка:

<set ...>
   <pre_steps>
       <step>do_some_setup</step>
   </pre_steps>
   <case ...
   <post_steps>
       <step>clean_up</step>
   </post_steps>
</set>

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

<pre_steps>
   <step expected_result="1">do_some_setup_that_may_fail</step>
   ...

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

Фильтрация на основе идентификатора оборудования

Если для разных аппаратных средств требуются разные наборы тестов, можно использовать функцию hwiddetect. Пользователь может определить команду, используемую для получения идентификатора оборудования в теге hwiddetect. Аппаратный идентификатор, возвращаемый командой, сопоставляется с необязательным атрибутом hwid тестового набора. Если они не равны, контрольные примеры в наборе пропускаются и не записываются в файл результатов. Тестовый набор никогда не будет пропущен, если для него не был определен атрибут hwid. Также можно определить несколько значений hwid, разделённых запятой для набора.

Команда, определённая hwiddetect, может быть командой оболочки или отдельным исполняемым файлом. Исполняемый файл должен быть включён в тестовый пакет. testrunner-lite удаляет лишние пробелы и переводы строк из выходных данных команды hwiddetect, поэтому разработчику теста не нужно об этом заботиться.

Пример использования hwiddetect:

<?xml version="1.0" encoding="UTF-8"?>
<testdefinition version="1.0">
  <hwiddetect>/usr/bin/getmyhwid</hwiddetect>
  <suite name="suite1">
    <set name="test_feature_X_on_hw_bar" hwid="bar">
    <case name="test_X_1">
      <step>echo "hwid is bar"</step>
    </case>
    </set>
    <set name="test_feature_X_on_hw_foo" hwid="foo">
      <case name="test_X_1">
        <step>echo "hwid is foo"</step>
    </case>
    </set>
    <set name="test_feature_X_on_hw_foo_or_bar" hwid="foo,bar">
      <case name="test_X_1">
        <step>echo "hwid is foo or bar"</step>
    </case>
    </set>
  </suite>
</testdefinition>

Извлечение дополнительных файлов

В дополнение к обычному файлу результатов также можно получить все нужные файлы с помощью тега get:

<set ...>
   ...
   <get>
       <file>/tmp/myadditionalresult.1</file>
       <file delete_after="true">/tmp/myadditionalresult.2</file>
   </get>
</set>

В приведённом выше примере файл additionalresult.2 удаляется после извлечения.

Данные измерений

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

<case ...>
   ...
   <get>
       <file measurement="true">/path/to/measurement/measurement.txt</file>
   </get>
</case>

Данные измерений имеют следующий формат CSV:

name;value;unit;
name;value;unit;target;failure;
name;value;unit;target;failure;

Где name и unit — строки; value, target и failure — числа с плавающей точкой. Пример:

bt.upload;1.4123432;MB/s;
cpu.load;23.41;%;5;90;
mem.load;80.16;%;80;99;

Если target и failure заданы, измерение может повлиять (провалиться) на результат теста. Когда target больше, чем failure, value должно быть меньше, чем failure, и наоборот.

Когда измерения состоят из серии данных, атрибут элемента можно использовать в элементе файла:

<file measurement="true" series="true">/path/to/measurement/series.txt</file>

Формат файла CSV серии измерений отличается от формата, состоящего из отдельных значений измерения (необязательные части заключены в квадратные скобки):

name;unit[;target;failure]
[yyyy-mm-ddThh:mm:ss[.ssssss];]value
[yyyy-mm-ddThh:mm:ss[.ssssss];]value
[yyyy-mm-ddThh:mm:ss[.ssssss];]value
...

Первая строка указывает название серии и единицы измерения. Кроме того, могут быть указаны цели и пределы отказа. В следующих строках перечислены все значения измерений с дополнительной меткой времени (в соответствии с ISO 8601). Файл CSV может содержать только одну серию измерений.

Неавтоматические, автоматические и полуавтоматические тесты

Если не указан атрибут manual, все тесты являются автоматическими. Значение атрибута унаследовано от более высокого объекта иерархии (set-> case-> step). Под полуавтоматическим тестом подразумевается тест для обработки вручную, который имеет несколько автоматических частей. Следует обратить внимание, что это не работает наоборот, не может быть автоматического теста с шагами для обработки вручную (это было бы семантически странно, поэтому инструменты не поддерживают его).

Пример с Example_set показывает неавтоматический, автоматический и полуавтоматический случай. Пример работает с testrunner-lite/testrunner-ui, можно использовать: File:Example Definition.xml.

<?xml version="1.0" encoding="UTF-8"?>
<testdefinition version="1.0">
  <suite name="example_suite">
  <set name="example_set">
    <description>Example test set with manual, automatic and semi-automatic case.</description>
    <case manual="true" name="manual_case">
      <description>Manual test case with three steps inside one step tag.</description>
      <step>Step 1: execute command ttt on shell.
            Step 2: write something into edit box.
            Step 3: press ok button.
            Expected: Text should be updated into label.
      </step>
    </case>
    <case timeout="96" name="automatic_case">
      <description>Automatic test case that executes some shell commands.</description>
      <step>ls /tmp</step>
      <step expected_result="2">ls /nosuchfile</step>
      <step>pwd</step>
    </case>
    <case manual="true" name="semi_automatic_case">
      <description>A case with two automatic and two manual steps.</description>
      <step manual="false">xcalc &amp;</step>
      <step>Step: Type in 2 + 2 =. Expected: 4 is displayed </step>
      <step>Press x² button. Expected: 16 is displayed.</step>
      <step manual="false">killall xcalc</step>
    </case>
  </set>
 </suite>
</testdefinition>

Об атрибуте name

Следует обратить внимание, что атрибут name имеет тип anyURI. Нельзя использовать следующие символы в именах наборов, наборов или регистров.

; / ? : @ & = + $ , (зарезервировано)

или

{ } | \ ^ [ ] ` (неразумно)

Также не рекомендуется использование пробела, так как некоторые валидаторы его не допускают. Можно использовать вместо него _ или -.