Signadot спонсировал этот пост.
Я потратил последние 20 с лишним лет, создавая распределенные системы, и одна истина остается постоянной: тестирование микросервисов является сложной задачей. Тестирование тени — это мощный подход для безопасной проверки изменений микросервиса, потому что инженерные лидеры стремятся к лучшим способам испытать сложные архитектуры микросервиса.
В то время как наша предыдущая статья была сосредоточена на фундаментальной концепции тестирования тени — в течение двух версий сервиса бок о бок против одного и того же трафика — есть гораздо больше, чтобы изучить, как этот подход разблокирует совершенно новые сигналы тестирования.
Реальная магия происходит, когда мы используем это параллельное выполнение, чтобы получить действенные идеи, которые традиционные методы тестирования просто не могут предоставить. Давайте рассмотрим четыре мощных подхода к тестированию, которые позволяет тени тестирования, каждый из которых предоставляет уникальные сигналы, которые помогают разработчикам с уверенностью отправить.
1. Проверка контракта API: обнаружение нарушений изменений
Контрактное тестирование API является, пожалуй, наиболее сразу же ценным применением тени тестирования. Традиционное контрактное тестирование основано на фиктивных услугах и проверке схемы, которые могут пропустить тонкие проблемы совместимости. Тестирование тени выводит проверку контракта на следующий уровень, сравнивая фактические ответы API между версиями.
Вот как это работает:
Этот подход ловит нарушающие изменения, которые были бы невидимы для традиционного тестирования: изменения типа поля, новые необходимые поля, измененные ответы на ошибку и даже деградация производительности, которые могут нарушать соглашения на уровне обслуживания (SLA).
Этот подход сочетает в себе лучшее из тестирования контракта на основе спецификации с проверкой времени выполнения. Вместо того, чтобы просто проверять, соответствует ли ваша новая реализация API, вы напрямую измеряете совместимость со всем, что в настоящее время ее потребляет.
Например, когда команда в компании Fintech внедрила этот подход, она поймала тонкое нарушающее изменение, когда поле конвертировалось из строки в целое число — то, что его валидаторы OpenAPI не помечали, но это было бы сломано несколько потребителей вниз по течению. Система теневого тестирования сразу же подчеркнула расхождение, что позволило команде исправить его перед слиянием.
2. Тестирование производительности: сравните бок о бок
Тестирование производительности — это еще одна область, где сияет тестирование тени. Традиционное тестирование производительности обычно происходит в конце цикла разработки в выделенных средах с синтетическими нагрузками, которые часто не отражают реальные модели использования.
С тестированием тени вы можете:
Этот подход особенно мощный в сочетании с инструментами канарского анализа, такими как Kayenta, которые могут автоматически анализировать статистическую значимость в различиях в производительности.
Розничная платформа, с которой я работал, использовала этот подход для проверки основной оптимизации запросов базы данных. В то время как его синтетические критерии показали 40% улучшение, тень в отношении реального трафика выявило случаи края, когда некоторые запросы пользователя работали хуже. Команда смогла решить эти проблемы до развертывания, избегая того, что было бы серьезным производственным инцидентом во время пикового сезона покупок компании.
Прелесть этого подхода заключается в том, что он не просто проверяет, правильно ли функционируют ваш код-он проверяет, правильно ли он функционирует в реальных условиях с различными моделями трафика, которые было бы почти невозможно точно имитировать.
3. Анализ журнала: раскрытие скрытых проблем
Анализ журналов часто упускается из виду в традиционных подходах к тестированию, однако журналы содержат богатую информацию о поведении приложений. Тестирование тени обеспечивает сложные сравнения журналов, которые могут выявлять тонкие проблемы, прежде чем они проявляются как проблемы, связанные с пользователем.
С тестированием на основе журнала вы можете:
Я видел, как этот подход улавливает проблемы, которые проскользнули бы через любой другой тестирование. Одна инженерная команда обнаружила, что их новый код генерировал кластер предупреждений о соединении базы данных, которого не было в базовой версии. Хотя эти предупреждения не вызывали немедленных сбоев, они были ранним показателем истощения пула соединений, который в конечном итоге привел бы к каскадным тайм -аутам под нагрузкой.
Этот подход Bridges Testing and Observication, создавая цикл обратной связи, который помогает разработчикам понять оперативное влияние их изменений перед развертыванием.
4. Анализ безопасности API: влевая проверка безопасности.
Возможно, наиболее инновационное применение теневого тестирования находится в области безопасности. Традиционное тестирование безопасности часто происходит слишком поздно в процессе разработки, после того, как код уже был развернут. Тестирование тени обеспечивает истинный сдвиг, оставленный для обеспечения безопасности, обеспечивая динамический анализ против реальных шаблонов трафика.
Подход работает так:
Анализ безопасности времени выполнения с тени тестирования
ZED Attack Proxy (ZAP)-это инструмент безопасности с открытым исходным кодом, который выступает в качестве прокси-сервера «человек в среднем», перехватывая и осматривая сообщения между клиентом и сервером. Он автоматически сканирует на уязвимости безопасности, анализируя ответы и моделируя атаки, чтобы обнаружить недостатки, такие как инъекция SQL, перекрестные сценарии и недостатки аутентификации.
Этот подход особенно мощный для обнаружения таких проблем, как новые конечные точки API, в которых могут отсутствовать проверки аутентификации, недостатки проверки ввода или уязвимости раскрытия информации — все до того, как ваш код будет объединен.
Согласно недавнему отчету Gartner, «к 2025 году 60% организаций будут использовать автоматизированные испытания на безопасность, встроенные в трубопроводы CI/CD для обнаружения уязвимостей безопасности до развертывания, по сравнению с 20% в 2021 году». Тестирование тени обеспечивает идеальную структуру для такого рода автоматической проверки безопасности.
Интегрируя сканирование безопасности непосредственно в ваш рабочий процесс тестирования перед Merge, вы ловите уязвимости во время разработки, когда они простые и дешевые для исправления. Это устраняет традиционное узкое место безопасности, где проблемы обнаружены в конце цикла разработки, требуя дорогостоящего переделки и откладывания выпусков.
Самоподобные тесты: автоматическое обнаружение шаблона
Что делает эти подходы к тени особенно ценными, так это их природа по своей природе. В отличие от традиционных подходов к тестированию, которые требуют постоянного обновления тестовых наборов, издеваний и утверждений, теневое тестирование использует реальные трафики и автоматизированные сравнения для обнаружения проблем с минимальным вмешательством человека.
Мощность заключается в базовом сравнении: под управлением обеих версий бок о бок и автоматически выявляя различия в поведении, эти тесты по существу пишут сами. Они могут обнаружить тонкие проблемы, появляющиеся модели и регрессии, не требуя, чтобы инженеры предвидели все возможные края.
Это принципиально меняет парадигму тестирования. Вместо того, чтобы тратить бесчисленные часы на поддержание хрупких тестовых матчей, команды могут сосредоточиться на зданиях, в то время как автоматический дифференциальный анализ обеспечивает сеть безопасности.
Пионеры микросервисов в таких компаниях, как Netflix и Uber, в течение многих лет использовали вариации этих методов. Разница сейчас в том, что современные инструменты делают эти подходы к тестированию с высоким уровнем сигнала, доступными для инженерных групп всех размеров.
Заключение
Тестирование тени открывает новое поколение подходов к тестированию, которые обеспечивают более глубокое понимание и больше уверенности, чем традиционные методы. Обнаружая проблемы контракта API, регрессии производительности, подозрительные модели журнала и уязвимости безопасности, прежде чем они достигнут производства, команды могут быстро с большей уверенностью отправлять.
Если вы заинтересованы в изучении того, как тестирование тени может преобразовать вашу стратегию тестирования микросервисов, я бы хотел продолжить разговор. Проверьте нас на signadot.com или присоединяйтесь к нашему сообществу.
Будущее тестирования микросервисов — это не только проведение большего количества тестов раньше — речь идет о получении лучших сигналов, которые действительно предсказывают производственное поведение. Тестирование тени ведет эту эволюцию, доказывая, что с правильным подходом мы можем иметь как скорость, так и качество.
Signadot-это платформа для тестирования Kubernetes для микросервисов. Используя Signadot, инженерные команды «сдвигаются налево», чтобы выяснить проблемы раньше и повысить доверие. Узнайте больше новейших из Signadot Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Арджун Айер, генеральный директор Signadot, является опытным экспертом в облачной местной области с глубокой страстью к улучшению опыта разработчика. У Арджуна хвастается более чем 25-летним опытом работы в отрасли, есть богатая история разработки программного обеспечения для интернет-масштаба и … Подробнее от Arjun Iyer
