Автоматическое тестирование Parallels Cloud Server

Я хочу рассказать как тестируется один из продуктов компании Parallels Inc., в которой я работаю,
— Parallels Cloud Server. Думаю некоторым хабрачитателям этот продукт уже знаком по статьям Parallels рассекретила Cloud Server ^[1], FastVPS: Как мы меняли платформы виртуализации ^[2] и Собери сам: как мы сделали хранилище Amazon-style для небольших хостеров ^[3]. Если нет, то рекомендую статьи выше к прочтению :)

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

Если у меня получилось вас заинтересовать — добро пожаловать под кат :)

Сам по себе Parallels Cloud Server ^[4] является bare metal продуктом, то есть он устанавливается на голое железо. Он является RHEL-based Linux дистрибутивом (мы используем Cloud Linux) с интегрированными компонентами: Linux ядро с нашими патчами, гипервизор ^[5], компоненты Parallels Cloud Storage ^[6], переработанный установщик на базе Anaconda, удобная веб панель для управления контейнерами и виртуальными машинами Parallels Virtual Automation ^[7] и множество консольных утилит для управления и мониторинга Cloud Server. Наше тестирование покрывает каждый из этих компонентов.

Предисловие

Сейчас 98% функционала Parallels Cloud Server тестируется автотестами. И если для тестирования Parallels Server Bare Metal 4.0 (предшественник PCS 6.0) мы запускали 180 разных тестов, то в PCS 6.0 их уже стало 600. Сразу оговорюсь, что специфика самого продукта наложила свой отпечаток и на само тестирование: мы запускаем автотесты только на физических серверах и наши тесты отличаются от каких-нибудь тестов для сайтов на Selenium сложностью самих тестов, изощрённостью их конфигураций и длительностью (тесты могут длиться от 1 часа до 1 недели).

Чтобы вы могли себе представить объемы нашего тестирования приведу немного цифр: в PCS 6.0 RTM мы использовали 572 теста и сделали за 2.5 месяца 2959 запусков тестов, это примерно 294 машинных дня. А одно из последних обновлений мы тестировали с помощью 260 уникальных тестов и сделали 4800 запусков.

Но так было не всегда. Совсем недавно, примерно несколько лет назад, у нас было не так много автотестов и серверов для их запуска. Мы устанавливали продукты на каждую машину вручную, вручную запускали каждый автотест, вручную создавали баги в баг-трекере. Но со временем количество машин выросло c 20 до 100, количество тестов c 180 до 600, которые нужно запускать не время от времени, а на каждом билде. И со временем мы пришли к такой системе тестирования, которая есть.

Общая схема автотестирования

Основная инфраструктура запуска автоматических тестов достаточно простая и состоит из нескольких сервисов:

• builds — портал, на котором собрана информация о всех билдах, статусе валидации и т.д.
• bug tracker (у нас это Atlassian Jira)
• test report system — сервис, который хранит все тестовые результаты. Мы используем самописный портал.
• deployment system — наш 'in house' сервис для инвентаризации серверов, автоматической установки ОС на голое железо, автоматической установки всех продуктов Parallels, установки обновлений Windows, бекапа жесткого диска, управление активностями на ноде (QA investigation, Developer investigation, Test execution etc) и многого другого.
• планировщик тестов

Каждый билд после сборки проходит несколько стадий тестирования:

• базовая проверка работоспособности билда (Basic Validation Test)
• запуск continuous, регулярных тестов, тестов для измерения производительности и стресс тестов

По расписанию билдовой системы собирается билд Parallels Cloud Server и нотификация об успешном завершении сборки появляется на сервере builds. После этого автоматически запускается BVT (basic validation test). Наш BVT фактически состоит из двух частей: тест на валидацию самого Parallels Cloud Server (это проверка базовой функциональности контейнеров и виртуальных машин) и проверка Parallels Cloud Storage (тот же самый тест, но в качестве стораджа выступает не локальный диск, а Parallels Cloud Storage). При успешном исходе обоих тестов планировщик BVT посылает нотификацию на сервер builds и там билд помечается как валидный. После этого планировщик тестов запускает все остальные запланированные тесты. В случае если валидация прошла не успешно, то на этом тестирование заканчивается пока не будет собран новый билд с исправленной проблемой.

Планировщик тестов это один из ключевых компонентов автоматического тестирования. И если иногда можно обойтись одной из популярных Continuous Integration систем для запуска тестов (как например Яндекс использует Jenkins ^[8]), то нам такие решения не подошли из-за необходимости использовать свою логику запуска тестов.

Планировщик получая информацию с других сервисов может:

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

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

Для каждого из тайтлов в тестплане есть так называемый «джоб» — описание тестового окружения для запуска теста и его опций: сколько серверов нужно для запуска, какие требования к этим серверам, где будет запускаться тест (на самом сервере, в контейнере или в виртуальной машине и т.д.). Робот периодически просматривает тестплан, берёт каждый тайтл и, если тайтл не заблокирован тестовыми или продуктовыми багами, то пытается этот тайтл поставить в очередь на запуск: он пытается найти сервера, соответствующие требованиям в джобе для этого тайтла. Если необходимые ноды найдены, то робот создает активности по установке операционной системы и продукта на эти ноды в deployment system и активность по запуску теста по окончанию всех инсталляций.

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

На скриншоте выше показано, что тест был запущен на пяти нодах, тест был запущен с клиента (pclin-c19), а не на самих нодах, на двух нодах был установлен Parallels Cloud Server, на каждой из нод был зарезервирован пул IP адресов для использования IP адресов для контейнеров и виртуальных машин.

При успешном завершении теста deployment system экспортирует результаты на test report system, активности уничтожаются и сервера используются для запуска других тестов.

В случае же возникновения проблем при запуске теста заводится баг в Jira. Каждый баг от автотестов содержит: версии продуктов, участвующих в тесте, ссылку на результаты теста, описание теста, бэктрейс теста, описание как перезапустить тест, проблем репорт для виртуальной машины и ссылка на предыдущие результаты этого тайтла (вы же еще не забыли что такое тайтл?). К каждому багу прикреплены машины, на которых баг был найден (на скриншоте это mccp46, ts49 и svvpamd).

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

Чтобы видеть в динамике что происходит со всем тестовым пулом нод у нас есть график.

Поэтому мы всегда знаем чем занимаются наши сервера :)

Как я уже написал выше помимо непосредственного запуска тестов робот может автоматически валидировать продуктовые баги. Как это работает? Каждый коммит в продукт содержит ссылку на тикет в джире. После успешной сборки билда запускается скрипт, который в закрытые баги из чейнджлога добавляет номер билда.

Робот при планировании тестов учитывает эту информацию и перезапускает тесты с багами только на том билде, где есть фикс. Если перезапущенный тест прошел успешно, то робот автоматически валидирует баг в Jira и в комментарий добавляет номер билда и ссылку на успешный прогон теста.

Автоматика автоматикой, но как бы мы не хотели нельзя сделать так, чтобы продукт тестировался без участия людей. За прогоном тестов в таких промышленных масштабах стоит один человек, в обязанности которого входит создание новых конфигураций тестов («джобов»), создание тест планов с необходимым набором тестов для каждого обновления продукта, поддержка серверов (иногда они ломаются, иногда нужно добавить специфическое оборудование как SSD, устройство для эмуляции USB bulk device), добавление нового функционала в планировщик тестов и т.д.

А что у вас интересного в автоматическом тестировании?

Автор: estet

Источник ^[9]