Pragmatic Perl

Выпуск 23. Январь 2015

Tapper — система тестирования ПО полного цикла

Рассмотрена экосистема для автоматического тестирования

В мире открытого ПО не так уж и много систем для организации тестирования ПО в промышленных масштабах, которые бы охватывали полный цикл автоматического тестирования: планирование тестирования, подготовка тестовых окружений, запуск тестов, анализ тестовых данных и т.д. Если бы меня попросили перечислить такие системы, то я бы вспомнил проект autotest, разрабатываемый компаниями RedHat, Google, IBM и проект Tapper.

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

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

Проект был создан двумя разработчиками из Центра исследования операционных систем компании AMD для тестирования систем виртуализации. В 2011 году исходный код системы был опубликован под лицензией BSD. Проект разрабатывается до сих пор и используется для тестирования программного обеспечения в компании Amazon.

Что внутри

Архитектура Tapper состоит из нескольких сервисов. Каждый сервис реализован в виде набора CPAN-модулей. И это даёт гибкость в настройке всей системы: если какой-то компонент не нужен, то его можно и не устанавливать. Некоторые сервисы являются общими для всей системы и запускаются в одном экземпляре, а некоторые запускаются в нескольких экземплярах, по одному на каждом сервере. Поэтому потенциально система может неплохо масштабироваться.

Основные сервисы:

• Master Control Program — это центральный сервис, контролирующий запуск всех тестов в инфраструктуре. Может запускаться в единственном экземпляре для всей инфраструктуры;
• Program Run Control — процесс, с помощью которого тесты запускаются непосредственно на серверах. Необходим на каждом сервере, где будут запускаться тесты;
• Reports Receiver — сервис, принимающий отчёты о тестировании;
• Reports API — сервис для приёма дополнительной информации к отчётам о тестировании и формирования отчётов с результатами;
• Reports Web — веб-интерфейс для отображения результатов и запуска новых тестов, RSS-оповещения о результатах и т.д.

Все данные хранятся в базе данных, в роли которой может выступат как MySQL, так и sqlite.

Больше подробностей — докладах автора Tapper с конференций YAPC::EU 2009, YAPC:EU 2011 и LinuxCon EU 2011.

Как это работает

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

Перед началом тестирования все серверы должны быть зарегистрированы в Tapper. Каждому серверу можно назначить набор свойств (имя, количество оперативной памяти, производитель, количество процессорных ядер и т.д.). Тогда появится возможность запускать тесты только на тех машинах, которые обладают нужным тесту набором параметров.

Тестирование на голом железе имеет один недостаток - в случае багов в ПО вы можете остаться без доступа к ОС на сервере. Во избежание этого Tapper поддерживает интеграцию Power Distribution Unit. Но на данный момент поддерживается только одна модель, хотя поддержка других моделей не должна быть сложной. Это всего лишь небольшой модуль, который обращается к PDU удалённо. Поэтому если вы хотите построить тестирование, минимально зависимое от ручного вмешательства, то это ваш выбор.

Итак, добавляем новый сервер pragmatic-perl, делаем его активным и добавляем его в очередь update8:

$ tapper-testrun newhost --name pragmatic-perl --active --queue update8

Посмотрим список всех серверов:

$ tapper-testrun listhost --verbose

ID |      Name      | Active | TestrunID |                Comment | Queues
===========================================================================
30 | pragmatic-perl | active |     24976 |                        | update8
31 | ps18           | active |     24962 |                        | update7
27 | ps17           | active |     24929 |  testplanexperimenting | update7
22 | ts49           | active |      free |                        | update7

После добавления серверов нужно для каждого теста подготовить сценарий подготовки сервера. В терминах Tapper это называется precondition. Это может быть установка операционной системы, копирование архива с тестом на сервер, монтирование удалённой файловой системы и т.д.

В простейшем случае precondition может выглядеть так:

# tapper-mandatory-fields: kernel_version
# tapper-optional-fields: kernelpkg
---
precondition_type: image
arch: linux64
image: suse/suse_sles10_64b_smp_raw.tar.gz
mount: /
partition: vz
---
precondition_type: copyfile

Для тестирования в промышленных масштабах подготовка тестовых окружений — обязательное требование. Tapper позволяет автоматически разворачивать ОС на сервере, подготавливать ОС к запуску тестов и осуществлять непосредственный их запуск. Установка ОС реализована за счёт интеграции с сервисами NFS, TFTP, PXE, DHCP.

Установка ОС может происходить как с использованием готовых образов установленной системы, так и штатными средствами с задействованием таких технологий, как RHEL Kickstart, Debian Preseed или OpenSUSE AutoYast.

Добавляем precondition:

$ tapper-testrun new [all usual options] \
    --macroprecond=FILENAME \
     -Did=value1 \
     -Dkernel=2.6.37

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

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

### Allowed params:
###  - -Dqueue=QUEUE
###  - -Dtests=TEST1,TEST2,TEST3
###  - -Dmachines=HOST1,HOST2
[%# define default values %]
[%- IF queue == '' %][% queue = 'update8' %][% END -%]

[%- IF tests == '' %][% tests = 'tcpbench' %][% END -%]
[%- IF machines == '' %][% machines = 'pragmatic-perl' %][% END -%]
[% AllTests = tests.split(',') %]
[% AllDistros = distros.split(',') %]
[% AllMachines = machines.split(',') %]
[%- FOREACH machine = AllMachines %]
[%- FOREACH test = AllTests %]
---
type: multitest
description:
  shortname: [% test %]
  topic: Topic-[% AllTests.join('-') %]
  queue: [% queue %]
  requested_hosts_all:
  - [% machine %]
  preconditions:
  - ...
  -
    precondition_type: testprogram
    program: /opt/tapper/bin/tapper-testsuite-autotest
    parameters:
--test
      - [% test %]
  - ...

После составления тест-плана его нужно добавить в планировщик:

$ tapper-testrun newtestplan --guide --file pragmatic-perl-testplan
  This is an example testplan
  Allowed params:
   - -Dqueue=QUEUE
   - -Dtests=TEST1,TEST2,TEST3
   - -Dmachines=HOST1,HOST2

Просмотр очереди тестов:

$ tapper-testrun listqueue -v
11 | update8    |  1000
17 | update7    |   100
8  | update7_1  |   100
4  | update7_2  |   100

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

Посмотрим детально на нашу новую очередь:

$ tapper-testrun listqueue --name update8

Id: 10
Name: update8
Priority: 1000
Active: yes
Bound hosts: pragmatic-perl
Queued testruns(ids): 146, 138

Детали запланированного теста:

$ tapper-testrun list --id 146
id: 146
topic: track-workload-stress-opensuse_11.4_32
state: schedule
queue: update8
requested hosts: pragmatic-perl
auto rerun: no
precondition_ids: 15

Получили тест, запущенный на машине pragmatic-perl, в очереди update8.

Результаты тестирования

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

Все тестовые результаты сохраняются в стандартном формате TAP (Test Anything Protocol), популярном в Perl-сообществе. Формат очень удобен для понимания даже неподготовленному человеку:

1..15
ok 1  TestSnapshotsCT.hostname_check
ok 2  TestSnapshotsCT.diskspace_check
ok 3  TestSnapshotsCT.veth_IP_check
ok 4  TestSnapshotsCT.veth_MAC_check
ok 5  TestSnapshotsCT.venet_IP_check
ok 6  TestSnapshotsCT.physpages_check
ok 7  TestSnapshotsCT.swappages_check
ok 8  TestSnapshotsCT.cpu_limit_check
ok 9  TestSnapshotsCT.cpu_units_check
ok 10 TestSnapshotsCT.Check_Quotas
ok 11 TestSnapshotsCT.resize_increase_ve_start
ok 12 TestSnapshotsCT.resize_decrease_ve_start
ok 13 TestSnapshotsCT.resize_increase_ve_stop
ok 14 TestSnapshotsCT.resize_decrease_ve_stop
ok 15 TestSnapshotsCT.Leak_checks

Но из-за своей простоты у формата есть недостаток — формат никак не регламентирует поля для дополнительной информации о тестовом окружении. Tapper в этих целях использует комментарии:

1..1
ok 1 - tapper-suite-meta
# Tapper-suite-name:    Pragmatic Perl Testsuite
# Tapper-suite-version: 1.0
# Tapper-machine-name:  pragmatic-perl
# Tapper-uname:         Linux 2.6.32-042stab102.8
# Tapper-osname:        Parallels Cloud Server
# Tapper-cpuinfo:       Intel(R) Xeon(R) CPU E5-2403 0 @ 1.80GHz
# Tapper-ram:           32776

Интеграция с другими сервисами и инструментами

Проект поддерживает интеграцию с другими инструментами для тестирования и анализа результатов:

• запуск тестов в уже упомянутой системе autotest, предназначенной для тестирования ядра Linux;
• выгрузку тестовых данных в Codespeed, веб-приложение для анализа результатов тестирования производительности;
• возможность планировать тесты с помощью TaskJuggler, инструмента для управления проектами;
• возможность установки операционной системы с помощью Cobbler.

Заключение

К сожалению разработка проекта продвигается не так быстро, как хотелось бы. Steffen Schwigon, разработчик Tapper, обещал выложить сделанные в Amazon изменения в репозиторий на Github, но пока этого не случилось. Несмотря на это, существующего функционала уже достаточно для построения рабочей системы тестирования. Если вы заинтересовались проектом, то приглашаю поучаствовать в разработке и тестировании. Исходный код расположен на Github, модули для установки — на CPAN. Если хотите попробовать Tapper в деле, то есть несколько вариантов установки: с помощью CPAN-модулей и с помощью пакетного менеджера в ОС. Установочные пакеты есть для Fedora, ALT Linux, и есть OpenBSD-порт (не добавлены в официальное дерево портов, поэтому пакеты пока не собираются).

■ Сергей Бронников