Старый подход полной регрессии - не ответ

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

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

К сожалению, сквозное тестирование сохранилось и в современных архитектурах микросервисов, где оно приносит очень мало пользы и создает серьезные препятствия на пути к достижению высокой скорости разработки и развертывания программного обеспечения. Этот подход к тестированию может привести к остановке всего конвейера доставки, особенно если организация следует принципам гибкости и быстро отгружает код с использованием CI / CD и т. Д. Давайте посмотрим, как мы можем добиться большего в мире микросервисов.

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

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

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

Можно утверждать, что это не вопрос о микросервисе-монолите, а скорее вопрос о медленной / быстрой доставке. В монолите / микросервисе с медленной доставкой трудно определить, каковы ближайшие соседи, потому что многие изменения развертываются вместе. Если каждое развертывание состоит из одного изменения, разработчики и тестировщики могут легко определить, что следует тестировать. Я считаю, что микросервисы еще больше упрощают это, делая разделение задач еще более явным или внешним.

Нам не нужно постоянно все проверять. Глядя на сервис, который изменился, мы можем изолировать все сервисы, которые с ним взаимодействуют, и протестировать только взаимодействия с ними. Если границы системы прорисованы правильно, любые изменения должны затронуть только ближайших соседей.

Так как же гибким организациям тестировать архитектуру на основе микросервисов?
Я предпочитаю двусторонний подход, оба из которых предполагают возможность автоматизированного интеграционного тестирования. Если вы все еще выполняете полное руководство, вам нужно как можно скорее войти в игру по автоматизации.

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

Идентификация соседства службы может быть автоматизирована (например, с использованием служебной сети / отслеживания запросов для определения того, кто кому звонит) или вручную. После идентификации мы можем использовать такие методы, как тестирование CDC (Consumer-Driven Contract), чтобы убедиться, что каждое взаимодействие с тестируемой службой работает нормально. Многие организации также помечают / группируют интеграционные тесты, чтобы иметь возможность запускать подмножества интеграционных тестов для дальнейшей оптимизации (например, если изменяется только API 1, запускать тесты, связанные с ним, только в непосредственной близости).

Чем шире используется служба, тем крупнее будет ее район и, следовательно, тем больший объем тестирования необходимо провести. Хотя это означает, что развертывание этой службы не будет таким быстрым, также имеет смысл, что наиболее часто используемые службы должны двигаться медленно, чтобы предотвратить большие перебои в работе. Пока весь процесс после слияния с main автоматизирован, кого это волнует?

Но оптимизация при тестировании каждой службы, которую мы сделали (мы больше не тестируем все время постоянно), означает, что некоторые неизвестные неизвестные факторы могут стать причиной появления ошибок. Таким образом, вторым направлением нашей стратегии тестирования является постоянное выполнение интеграционных тестов для всех критически важных функций, ориентированных на клиентов, в производственной среде. Это могут быть автоматизированные тесты для нашего общедоступного API, тесты в стиле селена для пользовательского интерфейса или что-то еще, что может указывать на любое поведение, неожиданное для клиента. Если здесь обнаруживается аномалия, мы сообщаем об ошибке, которую соответствующая команда разработчиков затем берет на себя для расследования и исправления.

Последний набор тестов следует провести в первую очередь - фактически, их следует рассматривать как часть выпуска новой функции. Это еще один аргумент для разработчиков, пишущих интеграционные тесты. Постфактум команда / процесс контроля качества не может рассчитывать на то, чтобы успевать за быстро меняющейся командой разработчиков. Организация должна сосредоточиться на обеспечении возможности тестирования, управляемого разработчиками, давая им время для этого и настраивая инструменты, которые упростят написание тестов. После этого команды разработчиков могут сосредоточиться на создании и тестировании своих функций.

Двигайся как можно быстрее и ломайся как можно реже!

Читать далее: События, а не журналы - верная парадигма наблюдаемости.