Готовим Docker для Автоматизации
Тестирования
Вадим Гущенсков
Немного о себе
● Lead software test automation
engineer в Epam Systems
● 7 лет в IT и автоматизации
тестирования
● Основной фокус работы -
автоматизация Web-сервисов
Немного о проекте
Microservices
Cutting-edge
technologies
● Микро-сервис архитектура
● Заказчик технологически
подкован, любит строить
инфраструктуру используя
последние технологии.
● Весь деплой, куда-бы то ни было
происходит в Docker-контейнерах
Преимущества Docker
● Нетребовательность
к окружению
● Относительная
лёгкость установки
● Docker-образ - это
полноценный
артефакт
Developer VM
Local Server Data Center
Основные вызовы
● Каким образом встроить тестирование в
проект?
● Можем ли мы как-то улучшить
тестирование с помощью Docker?
● Как запускать наши тесты и использовать
одну и ту же версию тестов для
соответствующей версии web-сервиса.
● Как мониторить продакшен?
Окружение по-старинке
Идеальная ситуация
Стратегия тестирования
Ввести следующие уровни
тестирования:
● Изолированные
функциональные тесты
● Тесты верификации
установки - Deployment
verification test (DVT)
● Периодические “Canary”-
тесты
Подготовка артефактов
● Executable uber-jar с тестами
размещается в docker-образе с web-
сервисом
● В артефакт добавляется entrypoint.sh,
который понимает команды ‘start’ и ‘test’
● Артефакт отправляется в собственный
docker registry
Isolated testing
● Мы используем Docker-
in-Docker
● У нас есть образ со
всеми зависимостями,
которые тяжело
замокать: базы данных
(Postgres, MongoDB,
Redis), очередь
сообщений (RabbitMQ)
и другие зависимости.
● Контейнером с
изолированной средой
можно делиться
Deployment
Deployment Verification Tests
● Ноды последовательно
выводятся из кластера,
на них запускается
деплой и тесты
● Тесты запускаются на
той же ноде, что и
сервис в отдельном
docker-контейнере
● Можно ограничивать
ресурсы тестов
флагами: --memory, --
cpu-shares
Canary testing
● Всегда можно зайти на любую продакш-ноду и запустить
self-test
● При помощи Google Cloud Platform и Amazon Web
Services можно арендовать сервера в разных зонах и
запускать тесты по cron
Grafana widget для Canary
Questions

Готовим Docker для Автоматизации Тестирования

  • 1.
    Готовим Docker дляАвтоматизации Тестирования Вадим Гущенсков
  • 2.
    Немного о себе ●Lead software test automation engineer в Epam Systems ● 7 лет в IT и автоматизации тестирования ● Основной фокус работы - автоматизация Web-сервисов
  • 3.
    Немного о проекте Microservices Cutting-edge technologies ●Микро-сервис архитектура ● Заказчик технологически подкован, любит строить инфраструктуру используя последние технологии. ● Весь деплой, куда-бы то ни было происходит в Docker-контейнерах
  • 4.
    Преимущества Docker ● Нетребовательность кокружению ● Относительная лёгкость установки ● Docker-образ - это полноценный артефакт Developer VM Local Server Data Center
  • 5.
    Основные вызовы ● Какимобразом встроить тестирование в проект? ● Можем ли мы как-то улучшить тестирование с помощью Docker? ● Как запускать наши тесты и использовать одну и ту же версию тестов для соответствующей версии web-сервиса. ● Как мониторить продакшен?
  • 6.
  • 7.
  • 8.
    Стратегия тестирования Ввести следующиеуровни тестирования: ● Изолированные функциональные тесты ● Тесты верификации установки - Deployment verification test (DVT) ● Периодические “Canary”- тесты
  • 9.
    Подготовка артефактов ● Executableuber-jar с тестами размещается в docker-образе с web- сервисом ● В артефакт добавляется entrypoint.sh, который понимает команды ‘start’ и ‘test’ ● Артефакт отправляется в собственный docker registry
  • 10.
    Isolated testing ● Мыиспользуем Docker- in-Docker ● У нас есть образ со всеми зависимостями, которые тяжело замокать: базы данных (Postgres, MongoDB, Redis), очередь сообщений (RabbitMQ) и другие зависимости. ● Контейнером с изолированной средой можно делиться
  • 11.
  • 12.
    Deployment Verification Tests ●Ноды последовательно выводятся из кластера, на них запускается деплой и тесты ● Тесты запускаются на той же ноде, что и сервис в отдельном docker-контейнере ● Можно ограничивать ресурсы тестов флагами: --memory, -- cpu-shares
  • 13.
    Canary testing ● Всегдаможно зайти на любую продакш-ноду и запустить self-test ● При помощи Google Cloud Platform и Amazon Web Services можно арендовать сервера в разных зонах и запускать тесты по cron
  • 14.
  • 15.