Как использовать Docker в тестировании. Окружение в тестировании что это?

Обратите внимание, что Win и Mac - это не настоящий Docker, а виртуальные машины Linux под управлением Docker.

Почему стоит использовать docker в тестах

1. Проблема запуска тестов в команде без установки стека тестовых технологий (solenoid, браузеры и др.)
2. Менее требовательный, чем виртуальная машина по ресурсам (масштабирование ограничивается только ресурсами памяти и процессора на узлах с docker)
3. Проблема с инсталляцией дополнительного софта в разных контурах т.к. имеются ограничения
4. Использование TestContainers решает многие проблемы. Например, запуск kafka в docker для работы приложения или интеграционных сервисов.

4.0.0

com.testit.rest.assured

Сборка docker image, запуск docker контейнера, запуск тестов в контейнере

1.0-SNAPSHOT

Кувшин

Установите docker desktop

Создайте проект с пакетным менеджером maven в intellij idea

Вставьте следующие зависимости в pom файл

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">rest-assured-samplehttp://maven.apache.orgrest-assuredUTF-8UTF-81.7.05.7.04.2.04.2.03.8.1org.junit.platformorg.junit.jupiterio.rest-assuredустановитьorg.apache.maven.pluginsjunit-platform-launcher$UTF-8junit-jupiter$правдаrest-assured$org.apache.maven.pluginsДавайте создадим класс UserDTO с моделью для выполнения запросов GET, POST, PUT и DELETE в каталоге src/test/java/com/model:maven-compiler-plugin$4.2.01.81.8maven-surefire-pluginИспользуется для "мягкой" остановки контейнера. Пример: docker stop test-docker:1.0. Можно остановить все запущенные контейнеры вместо конкретного контейнера - docker stop $(docker p s-a -q).Давайте создадим класс UserDTO с моделью для выполнения запросов GET, POST, PUT и DELETE в каталоге src/test/java/com/model:$

4. Создайте структуру папок

5. Создайте модели (DTO)

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

public class UserDTO public String name; public String job; public UserDTO(String name, String job) this.name = name; this.job = job;>>

6. Напишем простой автотест для сайта https://reqres.in для запросов GET, POST, PUT, DELETE с разным способом валидации Response:

• Тестирование запроса Get c проверкой status code = 200. Создайте класс GetRequestTest в каталоге src/test/java/com/apiTests с тестом getRequestCheckStatusCode:

public class GetRequestTest @Test @DisplayName("Тестирование запроса Get c проверкой status code = 200") public void getRequestCheckStatusCode() RestAssured.given() .baseUri("https://reqres.in/")//--->Cтартовая URL .relaxedHTTPSValidation() .get("/api/users/2")//--->Endpoint для выполнения запроса GET .then() .statusCode(HttpStatus.SC_OK);//--->Проверка статус код>>

• Тестирование тестового запроса Put c обновлением данных Users по полю job. Создайте класс PostRequestTest в каталоге src/test/java/com/apiTests с тестом postRequestCheckStatusCode:

public class PostRequestTest @Test @DisplayName("Тестирование тестового запроса Post с проверкой status code = 201") public void postRequestCheckStatusCode() RestAssured.given() .baseUri("https://reqres.in/")//--->Cтартовая URL .relaxedHTTPSValidation() .body(new UserDTO("morpheus", "leader"))//--->body для запроса с методом POST .post("/api/users")//--->Endpoint для выполнения запроса GET .then() .statusCode(HttpStatus.SC_CREATED);//--->Проверка статус код>>

• Тестирование тестового запроса Put c обновлением данных Users по полю job. Создайте класс PutRequestTestкаталог src/test/java/com/apiTests с тестом putRequestCheckStatusCodeAndJsonBody:

Основные команды docker:

1. docker ps — просмотр списка запущенных контейнеров
2. docker pull — загрузка образа.

В следующей статье мы представим Docker compose, мы создадим образ Docker с автоматизированными UI-тестами, запущенными с помощью Maven.

Автор.

Мы склонны разделять наши тесты на различные этапы в зависимости от охвата функций и времени выполнения. Первый этап называется BAT(P1) - тесты, охватывающие основные критические функции, без которых продукт даже не должен быть запущен: резервное копирование системы, последующее восстановление и т.д. Следующий этап называется Общий (P2-P3); он включает тестирование функций, без которых продукт достаточно пригоден для использования: резервное копирование дисков с различными файловыми системами, восстановление на диски, размер которых не совпадает с размером резервной копии, планировщик. BAT и Common должны работать преимущественно в чистой среде. Поскольку эти наборы тестов запускаются во время активной разработки продукта, важно, чтобы они выполнялись регулярно и чтобы ошибки, если они обнаружены, можно было легко отследить.

1. docker run — запускаем контейнер на основе указанного образа.
2. docker stop — останавливает контейнер.

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

1. docker kill — «убивает» контейнер.

Грязь - это не всегда плохо....

1. docker rm — удаляет контейнер.
2. docker rmi — удаляет образ.
3. docker volume ls — список томов. Данная команда показывает список томов, которые являются основным механизмом для хранения данных, генерируемых контейнерами Docker.

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

В компании Acronis этой функции уделяется большое внимание. Существует один вид тестирования, который охватывает весь жизненный цикл продукта - LifeCycle. Эти тесты состоят из таких этапов, как: Установка, деинсталляция, переустановка, обновление и т.д. Кроме того, цепочки учитывают богатую историю наших продуктов: 10 основных версий - обновлений (но в тестах участвуют только последние 5 версий, включая новые версии продукта: TrueImage 2013, TrueImage 2014), каждая из которых имеет от 2 до 5 минорных версий - обновлений продукта. И весь этот зоопарк должен быть проверен. Будет ли установлен TrueImage 2014 Update2, если на компьютере уже был установлен TrueImage 2013 Update1? И будет ли TrueImage 2013 RTM обновляться до TrueImage 2014 update1? Ответы на эти вопросы дают упомянутые выше тесты LifeCycle. Но даже этого было недостаточно. Недостаточно просто представить продукт. Хорошо бы убедиться в том, что это работает. Поэтому между установками, модернизациями, обновлениями и новыми установками проводится проверка базовой функциональности BAT.

Талисман компании TrueImage. Он называется "Хомяк". После прежнего названия TrueImage Home.

…и с чем это чистое окружение едят

Другой тип испытаний, которые проводятся в грязной среде, - это так называемые испытания на дальность или стабильность. Они проводятся для оценки стабильности продукта во времени. Их суть заключается в запуске основных функций BAT, которые выполняются в автоматическом цикле в течение длительного периода времени. Для нас этот период составляет 7-14 дней, затем сборка обновляется и цикл тестирования повторяется. Таким образом, предыдущий цикл тестирования влияет на следующий. Резервное копирование и восстановление больших объемов данных иногда занимает день, особенно через облако и особенно при медленном канале. Такие тесты также выявляют ошибки, связанные с длительным выполнением, например, утечки памяти, заполненные жесткие диски и т.д.

Но это еще не все. А как насчет влияния сторонних программ на продукт? К сожалению, автоматизированное тестирование в этом случае неэффективно. Компьютер не может полностью оценить, правильно ли работают вместе продукт и сторонние программы.

Наиболее серьезные проблемы возникают с программным обеспечением для контроля доступа: Антивирусы и брандмауэры. В этом случае полезны ручные тесты. Например, позволяет ли стандартный брандмауэр Windows восстановить ранее созданную резервную копию в облаке?

Три года назад мы решили использовать типовые тестовые среды. Тестовые среды Docker идеально соответствуют нашим критериям.

Если вы решили использовать контейнеры, вам нужно решить, подойдет ли чистый Docker или вам нужно включить систему оркестровки. Выбор зависит от ваших потребностей и ресурсов.

А зачем нам грязнули?

На рынке есть несколько крупных поставщиков (Kubernetes, Docker Swarm, Apache Mesos) и еще больше мелких. В будущем я буду ссылаться на Kubernetes, когда буду лучше с ним знаком.

Когда мы начали переносить базы данных в контейнеры для автоматизированного тестирования, никто из команды Fiji не умел пользоваться K8. К счастью, три года назад у 2ГИС уже было несколько кластеров K8 и команда по инфраструктуре и эксплуатации, которая заботилась о техническом обслуживании и поддержке

Однажды мы заметили, что наши тесты стали красными. Каждая сборка начиналась хорошо, но после момента X все становилось плохо. Тесты рушились и разбивались странным образом. Зеленая часть была запущена на реальной базе данных со всеми миграциями, красная часть - на всем остальном. Мы начали копать и - о ужас - увидели, что K8s перезапускает контейнер базы данных. Мы загрузили контейнер один раз в начале пробега и даже не подумали о его перезапуске. Оказалось, что контейнер MS SQL постоянно превышал лимит памяти, и K8s решил, что его можно нейтрализовать. И количество лимитов было воспринято с долей соли. Мы наложили реалистичную форму на конфигурацию, и наши тесты волшебным образом стали зелеными.

Для автоматизированных тестов наши службы продолжают работать локально, но используют тестовые данные, хранящиеся в K8s. Изначально мы не рассматривали возможность упаковки самих тестируемых сервисов в Docker.

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

Мир, дружба, жвачка

Итак, мы находимся в начале пути и приобрели песочницу. Какой вопрос они нам зададут? Возможно, "где и в каком масштабе?". Когда мы вместе с инженерами инфраструктуры 2ГИС продумывали будущую систему, мы рассчитали количество стручков, необходимых в тестовом цикле, примерное количество окружений, которые будут создаваться одновременно, и потребление памяти/процессоров на одно окружение. При разумном умножении у нас есть квоты ресурсов для пространства имен Fiji.

Мы используем два типа ресурсов Kubernetes - для разработки и для обслуживания. В развертывании размещается приложение, а служба предоставляет к нему доступ.

. Docker, Kubernetes?

Чтобы отправить запрос из внешнего мира в конкретный pod, мы отправляем его на hostIp:nodePort (hostIp - это параметр serve, а nodePort - параметр service; оба параметра можно определить, например, с помощью команды kubectl describe).

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

Схематично это можно представить следующим образом:

Подбираем ключи к Kubernetes