Docker для тестировщика: контейнеры и тестовые окружения
Docker для тестировщика: контейнеры и тестовые окружения
Docker даёт QA одну вещь — одинаковое окружение у всех. Не «у меня работает», а «работает на моём ноуте, на CI и у разработчика». Хватит 8 команд: pull, run, ps, exec, logs, stop, rm, build. Плюс docker-compose для связки контейнеров. За неделю осваивается, экономит недели в год.
Сценарий, знакомый каждому QA: автотесты падают только в CI, локально всё зелёное. Полдня ищешь причину — оказывается, в CI Chrome 122, а у тебя 119. Или на сервере PostgreSQL 14, а ты тестируешь на 12. Или у разработчика Node 18, а у тебя 16, и сборка валится.
Docker эту боль убирает. Один раз описал окружение в Dockerfile — везде поднимается одинаковое. На твоём ноуте, на ноуте коллеги, на сервере CI, у бэкенд-разработчика, у фронтендера в Хабаровске.
Я Яна, Senior AQA в Магните. Когда я переходила из ручного тестирования в автоматизацию, Docker казался штукой для DevOps-инженеров. На деле для QA нужна одна десятая того, что умеет Docker. Эта статья — именно про эту десятую.
Зачем QA Docker, если есть виртуалки
Виртуалки делают то же самое — изолируют окружение. Но виртуалка — это полноценная операционная система: Windows или Linux со всеми службами, занимает 8-20 гигабайт, грузится 1-2 минуты. Контейнер — это процессы, упакованные в лёгкую обёртку, занимает 50-500 мегабайт, поднимается за 1-3 секунды.
Что это даёт тебе как QA на практике:
1. Одинаковое окружение для команды. Разработчик кладёт в репозиторий `docker-compose.yml`. Ты делаешь `docker-compose up` — у тебя поднимается приложение, база данных, Redis, всё что нужно. Без танцев с установкой PostgreSQL вручную, настройкой Redis, ловлей версионных конфликтов с другими проектами.
2. Чистая база данных перед каждым тестом. В `tearDown` теста убил контейнер с БД, поднял заново — у тебя пустая БД с правильной схемой. Никаких «вчера тестил, остались левые юзеры в таблице».
3. Параллельный запуск разных версий. Тестируешь на PostgreSQL 12, 14, 15? Поднимаешь три контейнера одновременно, прогоняешь тесты против каждого. На своём ноуте установить три версии Postgres — катастрофа. В Docker — три строчки в команде.
4. Selenium Grid для параллельных тестов. Один контейнер с Hub, 5-10 контейнеров с разными браузерами. Прогон 200 тестов параллельно занимает 8 минут вместо часа. Без Docker такую инфраструктуру поднимать неделю.
5. Один и тот же окружение в CI. Локально пишешь `docker-compose up`, в GitLab CI — те же команды. Никаких «работает локально, падает в CI».
Базовые понятия за 3 минуты
Образ (image) — это шаблон. Например, `postgres:14` — образ с готовым PostgreSQL 14. Лежит в реестре (Docker Hub, GitLab Registry, Yandex Container Registry).
Контейнер (container) — это запущенный экземпляр образа. Из одного образа `postgres:14` можно запустить три контейнера, и это будут три независимые базы.
Dockerfile — это рецепт, как собрать свой образ. Описание шаг за шагом: «возьми Python 3.11, поставь pytest, скопируй мои тесты, запусти их».
docker-compose.yml — это описание группы контейнеров и связей между ними. «Подними приложение, БД, Redis, свяжи их сетью, прокинь порты».
Volume (том) — это папка с данными, которая переживает удаление контейнера. Полезно для БД (не теряем данные при перезапуске) и для отчётов автотестов (нужны после завершения).
Сеть (network) — это виртуальная сеть, через которую контейнеры общаются друг с другом по именам сервисов.
Всё. С этим набором понятий ты разберёшь 90% docker-compose файлов в репозиториях команд.
Минимальный набор команд
Установи Docker Desktop (Win/Mac) или docker engine (Linux), и пробуй прямо сейчас.
```bash
Скачать образ
docker pull postgres:14
Запустить контейнер из образа
docker run -d --name my-pg -e POSTGRES_PASSWORD=test -p 5432:5432 postgres:14
Список запущенных контейнеров
docker ps
Список всех (включая остановленные)
docker ps -a
Посмотреть логи контейнера
docker logs my-pg
Зайти внутрь контейнера в bash
docker exec -it my-pg bash
Остановить контейнер
docker stop my-pg
Удалить остановленный контейнер
docker rm my-pg
Собрать свой образ из Dockerfile
docker build -t my-tests:latest .
```
Что делает первая команда `docker run`:
`-d` — запустить в фоне (detached)
`--name my-pg` — назвать контейнер my-pg
`-e POSTGRES_PASSWORD=test` — передать переменную окружения
`-p 5432:5432` — пробросить порт 5432 контейнера на порт 5432 хоста
`postgres:14` — какой образ использовать
После этого у тебя локально работает PostgreSQL 14, доступный по `localhost:5432` с паролем `test`. Никакой установки Postgres на ноут.
Поднять окружение для тестов: docker-compose
Docker-compose — это удобная обёртка над docker run для нескольких контейнеров. Вместо запуска руками пяти команд — один файл и одна команда.
Пример `docker-compose.yml` для тестов веб-приложения:
docker-compose down -v # выключить и удалить вместе с volumes (полностью чистая БД)
```
Что произошло после `up`:
Поднялся PostgreSQL 14 с инициализационным скриптом
Поднялся Redis 7
Поднялось приложение, подключилось к Postgres и Redis по именам сервисов
Поднялся Selenium Standalone Chrome для UI-тестов
Все контейнеры в одной сети, видят друг друга
Теперь твои pytest-тесты бегут против localhost:8080 (приложение), используют Selenium на localhost:4444. Полностью изолированное окружение, поднимается за 30 секунд.
Свой Dockerfile для запуска автотестов
Иногда нужно упаковать сами тесты в контейнер — чтобы CI мог их запустить без установки Python и зависимостей. Делается через Dockerfile:
```dockerfile
FROM python:3.11-slim
Рабочая директория внутри контейнера
WORKDIR /tests
Копируем requirements и ставим зависимости
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
docker run --network=my-test-network shop-autotests:latest
```
Теперь любой человек с Docker может прогнать твои тесты одной командой. Без установки Python, без виртуальных окружений, без боли с зависимостями.
Selenium Grid для параллельного запуска
Один из самых частых сценариев Docker для QA — поднять Selenium Grid для параллельного запуска UI-тестов.
```yaml
version: "3.8"
services:
selenium-hub:
image: selenium/hub:latest
ports:
- "4442:4442"
- "4443:4443"
- "4444:4444"
chrome:
image: selenium/node-chrome:latest
shm_size: 2gb
depends_on:
- selenium-hub
environment:
SE_EVENT_BUS_HOST: selenium-hub
SE_EVENT_BUS_PUBLISH_PORT: 4442
SE_EVENT_BUS_SUBSCRIBE_PORT: 4443
firefox:
image: selenium/node-firefox:latest
shm_size: 2gb
depends_on:
- selenium-hub
environment:
SE_EVENT_BUS_HOST: selenium-hub
SE_EVENT_BUS_PUBLISH_PORT: 4442
SE_EVENT_BUS_SUBSCRIBE_PORT: 4443
```
Поднять с 5 параллельными нодами Chrome:
```bash
docker-compose up -d --scale chrome=5
```
В тестах подключаешься к `http://localhost:4444/wd/hub` через Remote WebDriver — Hub распределяет тесты по свободным нодам. 50 тестов прогоняются параллельно на 5 нодах за время одного теста.
Это та инфраструктура, которая раньше требовала отдельного DevOps-инженера и недели работы. Сейчас — 20 строк YAML и одна команда.
Тонкие моменты, на которых спотыкаются джуны
Список граблей, которые я собрала на своём опыте и опыте учеников.
`docker-compose down` без `-v` оставляет volumes. Сделал down, поднял up — а в БД остались данные от прошлого прогона. Если нужна чистая БД — `docker-compose down -v` или явное удаление volumes через `docker volume rm`.
Конфликт портов. Запустил `docker run -p 5432:5432 postgres`, получил «port is already allocated». Проверь — у тебя уже что-то висит на 5432 (другой контейнер, локальный Postgres). Либо останови старый, либо пробрось другой порт `-p 5433:5432`.
Нет shared memory для Chrome. Selenium Chrome падает с непонятной ошибкой про shared memory. Решается параметром `shm_size: 2gb` в docker-compose. Без него Chrome крашится на тяжёлых страницах.
Контейнер видит хост по другому адресу. Внутри контейнера `localhost` — это сам контейнер. Чтобы дотянуться до приложения на хосте, на Mac/Win используй `host.docker.internal`, на Linux — `--network=host` или явный IP хоста.
Образы накапливаются. Через месяц активной работы у тебя 30 ГБ образов. Раз в неделю чистка: `docker system prune -a` удаляет неиспользуемые образы, контейнеры, сети. Не пугайся, активные останутся.
Логи не видны после `docker-compose down`. Контейнер удалили — логи ушли. Если нужны постоянные логи — пиши их в volume или подключи внешний логгер. Для разовых разборок: `docker-compose logs > debug.log` до выключения.
Когда Docker нужен джуну, а когда — нет
Нужен:
Команда уже использует Docker, без него ты не сможешь поднять приложение
Пишешь автотесты, и нужны воспроизводимые окружения для CI
Тестируешь backend, нужно поднимать БД с разными версиями и состояниями
Хочешь Selenium Grid для параллельных тестов
Не нужен прямо сейчас:
Тестируешь только UI на готовом тестовом стенде, который уже подняли разработчики
Только начинаешь учить QA, ещё не разобрался с базой ручного тестирования
Команда не использует Docker, в ближайшие месяцы не планирует
Docker — мощная штука, но он не заменяет понимание тестирования. Если ты не пишешь тест-кейсы и не разбираешь баги — Docker сам по себе тебе ничего не даст. Сначала база, потом инструменты.
FAQ
Сколько времени нужно, чтобы освоить Docker для QA?
База — 8 команд и понимание docker-compose — занимает 3-5 дней практики. Уверенное использование на проекте, включая написание своих Dockerfile и compose-файлов — 1-2 месяца. Глубокие темы (Docker Swarm, многостадийные сборки, оптимизация образов) для QA редко нужны, можно отложить.
Чем отличается Docker от виртуальной машины?
Виртуалка — это полноценная ОС поверх вашей: занимает гигабайты, грузится минутами. Docker — это процессы в изолированной обёртке: занимает мегабайты, грузится секундами. Виртуалка — для случаев, когда нужна другая ОС целиком. Docker — для запуска одного приложения или сервиса в изолированном окружении.
Можно ли пройти собеседование на Junior AQA без знания Docker?
В большинство компаний — да, Docker считается приятным бонусом, не требованием для джуна. Но в современных продуктовых командах его спрашивают всё чаще, и базовое знание (поднять контейнер, прочитать docker-compose) выделит тебя из общего потока. На уровне Middle AQA Docker уже обязательное требование почти везде.
Какие альтернативы Docker для тестировщика?
Podman — почти полная замена Docker, открытый и без демона. Testcontainers (для Python, Java, .NET) — библиотеки, которые поднимают контейнеры прямо из тестов программно. Vagrant — старая школа, поднимает виртуалки, не контейнеры. Для джуна правило: учи Docker — на нём построена индустрия, остальное освоишь по мере надобности.
Что делать дальше
Поставь Docker Desktop, открой терминал и сделай за 30 минут:
Подключись к нему через DBeaver или psql, создай таблицу, положи 5 записей
`docker stop` и `docker rm` — почисти
Найди в любом open-source проекте `docker-compose.yml`, прочитай его, попробуй поднять локально
Это первое касание. Дальше — по мере появления реальных задач: своё окружение для тестов, Selenium Grid, упаковка автотестов в контейнер для CI.
В моих группах AQA Python мы добавляем Docker на 4-5 неделе обучения, когда у людей уже есть pytest-тесты, и нужно их прогонять в воспроизводимом окружении. Если хочешь сразу попасть в правильный порядок изучения и не заплутать в DevOps — приходи на бесплатную консультацию, разберём план обучения под твою позицию.