Создаем облако для тестирования ПО

Пока компании вроде Google и Microsoft активно рассказывают простому пользователю о счастье, которое ожидает их на облачных сервисах, я хочу поделиться другой стороной облаков — счастьем для разработчиков и тестировщиков ПО. За те несколько лет, в течение которых я руковожу группой тестирования Parallels Plesk Panel, была собрана неплохая коллекция лайфхаков по использованию облака для наших целей.

Я уверен в том, что изложенный опыт будет полезен подавляющему большинству компаний и стартапов. Во-первых, тестовое облако можно создать самостоятельно. Это важно, когда ваш бюджет ограничен. Во-вторых, тестовое облако в его самом начальном варианте можно развернуть на 2-3 серверах. В-третьих, все хлопоты, связанные с созданием тестового облака, с лихвой окупаются автоматизацией процесса тестирования. Это особенно критично, если вы регулярно выпускаете обновления и если код вашего проекта довольно объемный.

С преамбулой вроде всё. Любопытных приглашаю под кат.

Зачем нам облако?

Панель Parallels Plesk стоит примерно на 50% всех серверов, используемых для хостинга ^[1] в мире. Это миллионы «железок» и VPSов, на которых крутятся сотни миллионов клиентских сайтов. Цена багов в ПО огромная, мелочей не бывает. В этом отношении «Плеск» — очень сложный продукт для QA-инженеров. В сутки для него нам необходимо прогонять около 2000 p0 и p1 регрессионных автотестов (из них около 700 тестов посвящено пользовательскому интерфейсу) на 60 конфигурациях. За 24 часа получается более 120000 запусков автотестов. Кроме этого минимум раз в неделю подваливает ещё работы — обязательно инициируются тесты для проверки upgrade/backup/restore/migration с семи поддерживаемых версий «Плеска» на десятках конфигураций. Раз в месяц QA-инженеры проводят performance-, density- и load-тестирование. Ну и совсем жарко бывает в канун релиза. Тогда ко всем вышеперечисленным операциям добавляется необходимость проверять интеграцию с десятками продуктов.

Очевидно, что делать это всё руками, подготавливать окружение, устанавливать продукты, заливать фреймворки и тесты, запускать на отдельных серверах, собирать и анализировать логи и результаты даже не то, чтобы сложно – невозможно в принципе. Именно поэтому мы решили скормить эти задачи облаку.

Каким оно будет?

«Хотелки» QA-команды «Плеска» (да и вообще новосибирского центра разработки Parallels, где создается ряд других продуктов для сервис-провайдеров) сформировались в 2008 году и были уложены в четыре лаконичных пункта:

• Надёжность и отказоустойчивость. Как показала дальнейшая практика, аптайм облака для QA оказался чуть ли не таким же важным критерием, как аптайм для публичных cloud-сервисов.
• Высокая производительность. Критерии здесь — возможность осуществлять полный объём тестирования за требуемое время, скорость создания виртуальной машины (читай, VPS ^[1]).
• Масштабируемость. Возможность в любой момент выделить нужное количество ресурсов, исходя из сложности задачи. Например, для решения простой задачи мы выделим одну машину и получим результат за час, а для решения сложной задачи выделим 20 машин, чтобы так же получить результат за час. Плюс к этому – расширяемость. Новый полностью сконфигурированный сервер готовится не более чем за один час.
• Поддержка изменения требований. Наличие возможности быстро адаптировать облако к изменениям требований (изменение типов виртуализации, возможность приоретизации задач между проектами и т.д.).

Спустя год «облако», позволяющее выполнять основные задачи (разворачивание машины, запуск автотестов), было готово. Над его созданием трудилось 2-3 человека. Практически все программное обеспечение для облака – самописное, за исключением пары продуктов «из коробки». Это Munin (мониторинг доступности ресурсов) и Nagios (мониторинг использования ресурсов). А вот TestLink (хранение словесных описаний тест-кейсов, формирование результатов ручного и автоматического исполнения тест-кейсов) пришлось серьезно перелопатить. Были модифицированы ядро и система формирования отчётов. Например, последнее нам дало ускорение генерации репорта на два порядка: было 5 минут, стало 5 секунд.

Грамотный читатель спросит, почему мы не использовали облако Amazon и не наклепали в нем инстансов под свои цели и задачи. Отвечу тезисно:

• У нас нет недостатка в «железе». Оно копилось долгие годы, логично было его нагрузить по полной программе.
• Внешние клауды даже сейчас не полностью подходят под наши требования, среди которых — множество специфических конфигураций и типов виртуализации.
• Дорого. Ежедневный объём потребляемых ресурсов при выполнении наших задач в пересчёте на денежные знаки будет просто астрономическим.

Момент истины: как облако изменило жизнь тестировщиков?

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

Как стало? Облако избавило QA-команду от рутинных задач. Тестировщик перестал быть «немножко админом» и больше не занимается самостоятельным «раскатыванием» ОС, билдов продуктов и тест-планов по серверам. Сейчас этим занимается робот, командовать которым можно через GUI или API интерфейсы.

Вот как это выглядит:

Выбираем продукт и версию (1), название тест-плана (2), билд (3), список конфигураций (4), нажимаем кнопку ‘Run’ (5) и понеслась. Развертывание десятков и сотен машин, установка на них продукта, запуск авто-тестов происходит фактически за пару кликов.

Во вкладке Scheduled tasks есть возможность добавлять задачи для регулярного автоматического тестирования, используя наш таск-менеджер, позволяющий добавлять задачи с учётом нагрузки на облако.

А во вкладке Mass execution есть возможность запускать группы тест-планов. Пара кликов — и вы запускаете полмиллиона автотестов. Можно вдоволь поупиваться собственным величием.

Под капотом тестового облака

Эта мудреная движущаяся картинка иллюстрирует работу нашего облака и дает представление о его архитектуре:

Давайте посмотрим, как крутятся шестерёнки внутри на примере схемы continuous integration.

1. Инициатором запуска процесса являются разработчики. После того, как они сваяли очередную фичу, они осуществляют коммит в систему контроля версий.
2. После этого происходит запуск процесса сборки билдов из исходников.
3. Как только собирается билд для одной из конфигураций, сразу же отправляется запрос к Test executor на запуск Build Verification Test (BVT) — тест-плана, содержащего 10-20 автотестов, проверяющих основную функциональность продукта и позволяющих убедиться в отсутствии блокирующих проблем.
4. Test executor отправляет запрос к Deployment server на создание соответствующего окружения.
5. Deployment server выбирает на OS dump storage заранее подготовленный образ операционной системы...
6. …и разворачивает его на наиболее подходящем сервере или группе серверов, которые выбираются Load balancer’ом по определённым правилам (часть из них мы расмотрим чуть позже). После этого происходит установка собранного билда на всех созданных машинках.
7. Как только Deployment server подготавливает всё необходимое окружение, управление возвращается к Test executor, который осуществляет запуск BVT тест-плана на подготовленных машинках, распределяя автотесты по ним.
8. В зависимости от характера автотестов могут использоваться сервера с внешними сервисами: например, Selenium, внешняя почта или базы данных.
9. Если тест-план выполнился с ошибками, то разработчик, сделавший неудачный коммит, получает соответствующее уведомление о том, что всё пропало и надо быстро-быстро чинить. Если же тест-план выполнился без ошибок, то происходит перекладывание собранных билдов на специальный сервер Product builds storage, откуда уже билды становятся доступны для ручного и полномасштабного автоматического тестирования.

На схеме есть ещё несколько узлов, которые я не упомянул. Внутри облака находится Tests storage, на котором хранятся тестовые фрэймворки и автотесты, и Test specification system, на котором расположен TestLink. Снаружи расположены Tools management server, предоставляющий интерфейсы для работы с облаком (например, форма запуска тест-планов, упомянутая выше), и Infrastructure monitoring сервер, позволяющий контроллировать работу облака, оперативно обнаруживать проблемы в нём, находить узкие места в работе облака и т.д.

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

Лайфхаки и доработки

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

80 падений – это 80 багов в продукте? Это 80 проблем в тестах? Это один баг в продукте, из-за которого падает 80 тестов? В каком состоянии продукт? Что именно сломалось? Где посмотреть логи? Много вопросов и мало ответов.

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

В верхней левой части наглядно показывается статистика по каждой из конфигураций, число успешно и неуспешно пройденных автотестов, число известных ошибок. Кликнув на конфигурацию, можно получить информацию о каждом из автотестов, логи разного уровня детализации, скриншоты, привязку к известным багам в системе баг-трэкинга и многое другое.
Вверху справа выводится список автотестов, отсортированный по количеству падений на разных конфигурациях. В условиях ограниченности ресурсов это позволяет инженерам фокусироваться на «правильных» проблемах (более вероятный баг в продукте или проблема в устаревшем автотесте, вызванная изменениями в продукте).
Внизу слева выводится информация об известных ошибках, числе падений и привязка к сущностям в нашей системе баг-трэкинга (туда попадают и баги в продукте и баги в тестах).
Внизу справа показана общая статистика по этому тест-плану и билду, в том числе информация о неизвестных ошибках и ошибках, вылеченных «карантином». «Карантином» мы называем автоматический перезапуск упавших тестов на абсолютно свежем окружении. Это позволяет нам отсеивать «ложные» падения автотестов, вызванные нестабильностью работы сети или проблемами с работой selenium-серверов под большими нагрузками.

Обратите внимание: весь массив данных, с которыми предстоит работать QA-инженеру, собирается и формируется автоматически.

Заключение

Если вы добрались до заключения, вас можно поздравить. Вам действительно интересна тема использования облака в QA и вы, вполне возможно, захотите построить собственный тестовый клауд – хотя бы на двух-трех серверах. Вот мои рекомендации тем, кто будет это делать в первый раз:

1. Четко формулируйте требования к облаку. Поймите, какие задачи облако должно помогать решать, каким критериям производительности и стабильности оно должно удовлетворять и т.д.
2. Определитесь с необходимыми ресурсами, основываясь на требованиях к производительности и стабильности: каким должно быть «железо» и устройство сети, какое программное обеспечение, средства виртуализации, ну и какие человеческие ресурсы вам потребуются
3. Разработайте систему распределения нагрузки между серверами и определитесь с критериями, по которой будет происходить выбор подходящего сервера. Скажу честно: главу про load balancer я не стал включать в пост сознательно, чтобы окончательно не распугать читателей размерами публикации. Если будет интересно почитать про балансировщик – пишите в комментах, сделаю отдельный пост
4. Создайте систему мониторинга работы облака, позволяющую оперативно находить проблемы и узкие места в работе облака
5. Создайте систему управления облаком (первоначально это может быть просто API, а потом вам потребуется и GUI, который позволит пользоваться облаком быстрее и будет требовать меньше технических знаний)
6. Выберите систему управления тестами и при необходимости измените ее – как сделали мы с TestLink’ом.
7. Определитесь с тестовым фреймворком. Его выбор будет в большей степени зависеть от технологий, на которых базируется ваш продукт, и языков программирования, на которых он написан.

После всех этих действий вам и самим станет понятно, в каком именно направлении развивать ваше личное облако.

Автор: kriogen