Как должно выглядеть автоматизированное тестирование приложений Kubernetes?
12 апреля 2022 г.Приложения «программное обеспечение как услуга» (SaaS) сегодня экспоненциально масштабируются, поскольку стартапы стремятся соответствовать потребительскому спросу с предоставлением услуг. Чтобы соответствовать потребностям больших и сложных кодовых баз, настройки тестирования должны масштабироваться вместе с ними, особенно с ростом числа контейнерных приложений, развертываемых во все более крупных кластерах Kubernetes. Тестирование этих приложений требует автоматизированных процессов и реальных требований и может быть объединено с существующими рабочими процессами разработки и поставки.
Другими словами, тестирование кода приложения с самого начала производственного цикла, проходящего через CI/CD, должно выполняться в тестовой среде, которая воссоздает — или имитирует — рабочую производственную среду в Kubernetes. Команды DevOps должны сделать это приоритетом, потому что отсутствие тестирования CI, среди прочего, почти всегда приведет к выпуску большего количества ошибок в рабочей среде и необходимости тратить больше времени на их исправление позже.
Автоматизированное тестирование (r)эволюция
Между тем, много времени, усилий и размышлений было посвящено выяснению того, как эффективно тестировать приложения SaaS. Однако ориентированные на производство приоритеты большинства инженерных отделов означают, что инженерные группы часто масштабируются намного быстрее, чем роли обеспечения качества (QA) или группы тестирования. [Опрос, проведенный JetBrains в 2020 году] (https://www.jetbrains.com/lp/devecosystem-2020/testing/) показал, что в командах разработчиков программного обеспечения в подавляющем большинстве случаев соотношение QA-инженер/разработчик составляет один к трем или меньше.
Это увеличение масштаба связано не только с размером. По мере роста кодового решения увеличивается его сложность и снижается прозрачность решения для разработчика. Изменения в инфраструктуре, например при переходе на среды Docker или Kubernetes, позволяют легче масштабировать инфраструктуру приложения в соответствии с потребностями клиентов. Однако с этим переходом к контейнерным средам возникают проблемы, связанные с тестированием, поскольку функциональность кодового решения становится более непрозрачной. Именно здесь зависимость отрасли от модульного тестирования достигает своего предела.
Хотя модульное тестирование является полезным и необходимым компонентом, предыдущее исследование показало, что производственные системы часто вызваны взаимодействиями между компонентами, которые модульные тесты не предназначены для обнаружения. Вместо того, чтобы полагаться исключительно на модульные тесты на уровне кода, предприятиям следует создать комплексный автоматизированный набор тестов с тщательно написанными интеграционными тестами. Проверка правильности совместной работы компонентов и модулей приложения обеспечивает уровень стабильности, с которым чистое модульное тестирование не может сравниться. Автоматизированное тестирование является стандартной практикой в отрасли — большинство технических организаций уже включают ту или иную форму автоматизированного интеграционного тестирования в свои планы контроля качества.
Тем не менее, настройка автоматизации таким образом, чтобы он включал точки данных, такие как исторический трафик, может значительно увеличить преимущества набора тестов и снизить нагрузку на группы контроля качества. По мере того, как кодовые базы становятся все более сложными для удовлетворения новых требований к функциям, инженеры по обеспечению качества и разработчики должны сосредоточиться на улучшении самой автоматизации, а не тратить большую часть своего времени на имитацию источников данных и ручное создание тестовых стендов.
Реалистичное тестирование имеет решающее значение
В дополнение к проверке правильности ответов API и функций, наборы автоматизированных тестов должны проверять производительность и безопасность, особенно для контейнерных приложений, которые могут быть более открытыми или ограниченными. Именно здесь исторические данные об использовании могут помочь разработчикам и QA-инженерам в написании тестовых случаев. Структурирование тестов производительности с использованием регулярных шаблонов использования в качестве входных данных может предоставить важные данные о том, как приложение будет вести себя во время постоянно высокой нагрузки. Точно так же тесты безопасности, которые учитывают распространенные эксплойты, могут гарантировать, что кодовая база не пронизана такими проблемами, как уязвимости SQL-инъекций. Отражение регулярных шаблонов использования может позволить разработчикам понять, как их изменения повлияют как на точность ответов, так и на производительность других связанных систем.
Это особенно важно для приложений, развернутых в кластерах Kubernetes, поскольку они могут иметь зависимости от API или служб в других кластерах и сами могут быть зависимостями для других служб. Для этого типа тестирования рассмотрение предыдущего трафика и истории использования может дать информацию, которую не может дать обычное нагрузочное тестирование.
Надежда на чистое нагрузочное тестирование может слишком легко превратиться в грубую передачу большого количества запросов или огромных объемов данных службам, плохо оборудованным для их обработки. Этот профиль запроса явно не соответствует тому, что система увидит при повседневных нагрузках, и может даже вводить в заблуждение. Тестирование запросов грубой силой часто дает больше информации о способности инфраструктуры прослушивать эти запросы и отвечать на них, чем о способности службы обслуживать данные.
Профили нагрузки также меняются в зависимости от типа и назначения приложения, что группы контроля качества должны учитывать при настройке наборов тестов. Например, API проверки подлинности, испытывающий высокую постоянную нагрузку, будет иметь профиль производительности, отличный от профиля производительности приложения метрик, которое обслуживает большие объемы данных, но делает это периодически. Включение этих данных о трафике в автоматический тест может дать разработчикам значительную информацию не только об изменениях кода, которые они вносят, но и о необходимых изменениях в подготовке инфраструктуры, таких как масштабирование кластеров Kubernetes. Отсутствие их в наборе тестов может привести к тому, что разработчики будут вносить изменения, которые нарушат производительность или доступность, и приведут к невыполнению соглашений об уровне обслуживания (SLA).
CI/CD для автоматизации и масштабирования
Еще одной важной особенностью современного автоматизированного тестирования является необходимость тщательной интеграции с непрерывной интеграцией и инфраструктурой CI/CD. Приложения SaaS почти всегда имеют постоянно развивающиеся наборы функций, а это означает, что ни одна система никогда не была полностью развернута или полностью протестирована. Решения для развертывания и тестирования всегда должны учитывать следующую итерацию приложения.
Новые требования и текущие инженерные инициативы означают, что автоматизированное тестирование должно вписываться в конвейер разработки программного обеспечения без значительных ручных усилий. Например, такой инструмент, как [Speedscale] (https://speedscale.com/2022/03/24/kubernetes-load-test-tutorial/), может запускать sidecar вместе со службой, а также обнаруживать и записывать трафик на будущее. Затем эти данные могут использоваться службой Traffic Replay для создания наборов тестов на основе вероятных реальных сценариев, с которыми столкнется тестируемая система. Преимущество заключается в снижении нагрузки на инженеров по контролю качества, которым больше не нужно перепроектировать или переписывать целые наборы тестов в зависимости от меняющихся условий после развертывания. Это также предотвращает появление анти-шаблонов как в QA, так и в разработке, где инженерам в противном случае приходится заново изобретать колесо, пытаясь создать собственные тестовые наборы, рабочая нагрузка по обслуживанию которых становится неуправляемой по мере масштабирования кода приложения.
[Хорошо интегрированный автоматизированный набор тестов] (https://martinfowler.com/articles/microservice-testing/) может способствовать профилактическому состоянию экосистемы приложений путем тестирования нестабильности во время и после развертывания и сбора таких показателей, как задержка. , пропускная способность и частота ошибок. Мониторинг этих показателей расширяет возможности отделов контроля качества еще одной важной функцией: предоставление обратной связи командам разработчиков о том, где возникают ошибки. Выявлять ошибки во время тестирования — это здорово, но еще лучше предотвращать их с помощью итеративного тестирования и эффективного взаимодействия между командами.
Автоматизированные настройки также могут упростить имитацию тестирования хаоса для приложений, имитируя отключение зависимостей вверх по течению. Часто эти зависимости являются сторонним программным обеспечением, находящимся вне контроля организации. Иногда рассматриваемая зависимость является фундаментальной, например, крупный сбой Amazon Web Services (AWS) или региональный или глобальный сбой DNS. Хотя отказоустойчивость во время таких крупных и непредвиденных событий, вероятно, не является распространенным требованием, такие сценарии все же следует учитывать в наборах тестов, чтобы гарантировать отсутствие непреднамеренных побочных эффектов, таких как потеря данных клиентов, дублирование операций, таких как выставление счетов и т. д.
Все эти факторы способствуют надежности корпоративного решения и, в конечном счете, обеспечивают ценность для клиентов и спокойствие для разработчиков. Приложения SaaS масштабируются до беспрецедентных высот, особенно когда они внедряют новые технологии, такие как машинное обучение или блокчейн. В условиях этих меняющихся требований способность групп тестирования идти в ногу со временем будет иметь решающее значение для успеха приложений.
Оригинал