Стратегии тестирования ответов в микросервисной архитектуре

Эволюция системной архитектуры
Методы тестирования монолитных приложений
Эволюция тестирования микросервисов
техническая практика
куда идти
напиши в конце

Эволюция системной архитектуры

С быстрым развитием Интернета система веб-приложений превратилась из внутренней разработки предприятия в рыночного пользователя.Бизнес становится все более и более сложным, а количество пользователей увеличивается.Те отдельные приложения, которые раньше работали хорошо начинают сталкиваться с узкими местами разработки, тестирования, развертывания и выпуска, такими как扩展新增功能艰难,系统庞大难以维护,编译太耗时，发布流程太慢и другие проблемы преследовали команду разработчиков.

Появление SOA вызвало стремительный скачок в эволюции системной архитектуры: была предложена идея сервис-ориентированной архитектуры, система была разделена на несколько сервисных компонентов, а сервисные компоненты управлялись единообразно через ESB (Enterprise Service Bus). ESB снова становится узким местом. Далее следует недавняя популярная в отрасли микросервисная архитектура, которая еще больше совершенствует идею SOA, делая систему компонентной, обслуживаемой и децентрализованной, подчеркивая轻量级,松耦合,服务自治,独立部署.

Микросервисная архитектура устраняет болевые точки монолитных приложений, устраняет узкое место SOA, а также значительно усложняет. С точки зрения развертывания, эксплуатации и обслуживания, развертывания услуг, управления и мониторинга. С точки зрения разработки и дизайна усложнятся разделение, проектирование, кодирование и тестирование сервисов. К счастью, технология контейнеризации (например, чрезвычайно популярный Docker) в значительной степени помогла нам преодолеть различия в среде, а некоторые инструменты оркестрации контейнеров, такие как Kubernetes, Rancher, Docker-compose, предоставляют решения для управления развертыванием контейнеров. Являясь лидером отрасли, ThoughtWorks также решительно выступает заИнтеграция разработки, проектирования, развертывания, эксплуатации и обслуживанияКонцепция культуры DEVOPS, а также обширные консультации и результаты, чтобы помочь корпоративной команде R & D лучше реализовать разработку микросервисной архитектуры.

Итак, с точки зрения кодирования и тестирования, как можно обеспечить качество системы в рамках микросервисной архитектуры?

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

Методы тестирования монолитных приложений

Когда в нашем сознании есть только одна вещь, мы можем использовать ее, не задумываясь.

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

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

Обеспечьте достаточное покрытие модульными тестами, поддерживайте определенное количество тестов Servcie и добавьте несколько E2E-тестов для важных бизнес-процессов.

Эволюция тестирования микросервисов

Микросервисная архитектура является эволюционной архитектурой.Команда разработчиков проводит бизнес-анализ (Event Storming) с экспертами предметной области для разделения независимых сервисов.Количество независимых сервисов, определенных системой в начале, может быть несколько, вместе с бизнесом.Сложно и в -глубина, будет продолжать получать новые услуги. На следующем рисунке представлена система с микросервисной архитектурой, включающая четыре службы:

Многие службы в микросервисной системе неизбежно вызываются между службами, и они обычно используют облегченные API-интерфейсы HTTP RESTful. Так как же обеспечить надежность межсервисных вызовов и качество интеграции системы в целом? Особенно, когда разные сервисы разрабатываются и тестируются разными небольшими командами.

Модульные тесты для самого сервиса

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

Тестирование системной интеграции (UI)

Модульное тестирование позволяет разработчикам счастливо жить в своем собственном мире.Каждая команда разработчиков строит часть системы по чертежам.Только когда эти маленькие части интегрированы воедино, они могут предоставлять услуги пользователям в соответствии с их ожиданиями.Бизнес-ценность системы. Поэтому мы должны пройти системное интеграционное тестирование (тестирование пользовательского интерфейса), чтобы гарантировать качество интеграции.

оттестовая пирамидаКак видно из системы, тестов пользовательского интерфейса меньше всего. Хотя его бизнес-ценность является самой высокой, из-за его высокой стоимости он охватывает только бизнес-сценарии со сложными бизнес-процессами. Даже когда количество сервисов в системе с микросервисной архитектурой достигает определенного уровня, многие команды разработчиков начинают отговариваться от UI-тестирования, потому что интеграционное тестирование в системе с несколькими сервисами (даже с одной системой приложений) столкнется со множеством болевых точек:

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

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

Парный интеграционный тест

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

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

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

Хотя интеграционное тестирование Pair принципиально не устраняет болевые точки тестирования пользовательского интерфейса, оно поднимаетНакопить многоконцепция, которая говорит нам:Пока можно гарантировать надежность интеграции между двумя службами, мы можем быть уверены, что системная интеграция также надежна.

Интеграционное тестирование, знакомящее с концепцией контракта

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

Чтобы фронтенд и бэкенд разработчики работали параллельно, мы ввели концепцию Contarct. Front-end и back-end разработчики совместно определяют протокол API (контракт) на основе бизнеса.Протокол существует в каталоге тестовых ресурсов базы кода в виде файла JSON, а front-end использует файл JSON в качестве файла JSON. основа утверждения для тестирования в процессе разработки. Внутренние разработчики обращаются к содержимому протокола для реализации API.

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

Нет необходимости запускать другие службы, среда проста и работает быстро.
Управление тестированием сужено до одной службы.
По договору пишем код и тестируем отдельно.

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

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

После некоторой отладки мы обнаружили проблему и решили ее按照Contract单独运行测试一切OK，为什么上集成环境就莫名其妙挂掉！Сомнения:

// 两天前
request {
    method 'POST'
    url '/users'
    body([
            name: $(regex('[a-z]{6, 20}')),
            email: 'sjyuan@thoughtworks.com',
            homePage: 'http://sjyuan.cc'
    ])
    headers {
        contentType('application/json')
    }
}

// 两天后
request {
    method 'POST'
    url '/users'
    body([
            name: $(regex('[a-z]{6, 20}')),
            email: 'sjyuan@thoughtworks.com',
            homePage: 'http://sjyuan.cc',
            gender: 'M'
    ])
    headers {
        contentType('application/json')
    }
}

В истории Git обнаружено, что потребитель службы (внешняя часть) обновил протокол API, в то время как поставщик службы (внешняя часть) не изменил синхронно реализацию.

оглядываться引入Contract概念的集成测试, причина, по которой модификация протокола не подвергается воздействию до интегрированной среды, заключается в отсутствии механизма автоматического мониторинга для заблаговременного обнаружения проблем и раннего предупреждения. Подумаем дальше:Один и тот же контракт API используется в качестве основы утверждения теста для поставщика услуг и потребителя услуг. После изменения контракта одной стороной тест другой стороны завершится неудачно..

В конечном счете, нам не хватает эффективного принудительного сдерживания, связывающего обе стороны, что скоро будет обнаружено.消费者驱动契约测试Это ограничение может быть предусмотрено.

CDCT (тестирование контрактов, управляемых потребителем)

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

CDCT подчеркивает, что договорами управляют потребители и обе стороныподчиняться вместе, ядроподчиняться вместе.

Итак, как гарантироватьподчиняться вместеШерстяная ткань?

Упоминается в Agile-манифесте可工作的软件优于面面俱到的文档. Тест, который знакомит с концепцией контракта, определяет документ контракта (файл протокола JSON). На стороне потребителя документ используется в качестве основы для тестовых утверждений, и документ преобразуется в可工作的软件(исполняемый набор тестов: изменение документации приведет к сбою теста). Для поставщика услуг, поскольку утверждение теста не имеет обязательной связи с документом контракта, оно может быть не более чем одним面面俱到的文档.

Следовательно, только когда обе стороны преобразуют документ в работающее программное обеспечение, модификация документа приведет к провалу теста любой из сторон, и документ действительно станет обеими сторонами.подчиняться вместе(Рабочее программное обеспечение всегда надежно, но документация может быть устарела).

Управляющие потребителем контракты в тесте договора на основе договора, обе стороны могут работать, чтобы создать тестовый люкс:

CDCT имеет引入Contract概念集成测试Многие преимущества контракта гарантируются рабочим набором тестов, который является последовательным и работает в режиме реального времени.

техническая практика

При выработке стратегии решающая победа находится за тысячи миль.

Чжугэ Лян, звезда Трех Королевств, отвечает за разработку стратегии, а военные генералы, такие как Гуань, Чжан и Чжао, отвечают за то, чтобы вступить в битву, тем самым выиграв поле битвы за тысячи миль. Как только команда определила стратегию тестирования, она должна быть передана хорошим инструментам для ее реализации.

Что касается модульного тестирования, в отрасли уже есть очень хорошие инструменты и среды тестирования, такие как приложение Springboot, которое мы делаем,JUnit, Mockito, JMock, Hamcrestи т. д. являются звездами в наборе инструментов для тестирования. Для CDCT в настоящее время более популярен фреймворк JVM.Spring cloud Contractи многоязычныйPact.

Если команда разрабатывает приложение Springboot,Spring cloud Contractхороший выбор. Он использует Groovy DSL для определения тестового контракта и создания набора тестов. Набор тестов проверяет, удовлетворяет ли поставщик услуг контракту. После прохождения теста создается файл jar, который затем используется в качестве исполняемой заглушки. сервер. Потребитель основан на сервере-заглушке. Напишите тест, который проверяет, что функция удовлетворяет контракту:

В CDCT как производители тестов, так и потребители тестов должны внедрить отказоустойчивый подход. т. е. если какая-либо из сторон нарушает контракт, лучше потерпеть неудачу в первую минуту сборки, чем ждать 2 часа спустя в интеграционном тесте. Итак, нам нужно интегрировать CDCT в CI как этап конвейера сборки.

куда идти

Дорогостоящее тестирование пользовательского интерфейса позволяет команде разработчиков постепенно терять доверие к нему, особенно введение архитектуры микросервисов, оно усложняет работу, заставляя отрасль отказаться от тестирования пользовательского интерфейса на высоком уровне. Еще в 2009 году известный эксперт по Agile и TDD Дж. Б. Райнсбергер представил на InfoQIntegration Tests Are a Scam.

Интеграционные тесты — это афера, вам может понадобиться написать 2-5% интеграционных тестов, чтобы сделать E2E-тест, но они могут везде повторять модульные тесты, а интеграционные тесты повторяют друг друга. Что еще хуже, когда интеграционный тест дает сбой, вы не знаете, что пошло не так, и не можете вовремя определить проблему.

Дж. Б. Рейнсбергер позже написал в блоге«Интеграционные тесты — это мошенничество», статья заимствует мощный анализ данных, чтобы подтвердить свою точку зрения. Лучшие практики, которые он предлагает:Используйте контрактные тесты или протокольные тесты для интеграционных тестов!

Мартин Фаулер, 2012 г.Проверить теорию пирамидВ нем также говорится:

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

Технологический радар ThoughtWorksТестирование контрактов, ориентированное на потребителя, было официально принято в 2016 году.

Мы решили ВЕРНУТЬ тестирование контрактов, ориентированное на ПОТРЕБИТЕЛЕЙ, из архива для этого выпуска, даже если мы позволили ему исчезнуть в прошлом.

Преобладание микросервисной архитектуры побуждает все больше и больше команд разработчиков внедрять CDCT и постепенно ослаблять тестирование пользовательского интерфейса. Стратегия тестирования команды развивается по-разному:

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

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

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

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

напиши в конце

Сложность микросервисной архитектуры отражается не только в технологии, но и в бизнес-архитектуре системы, а техническая архитектура всегда служит бизнес-архитектуре. Отличные стратегии тестирования и методы проектирования позволяют нам лучше создавать сложные архитектурные системы и преодолевать проблемы, которые они несут, и в конечном итоге определять, будет ли система успешной или нет, зависит от людей. Поэтому каждый в команде должен сохранять открытость, продолжать учиться, повышать свой уровень (навыки и бизнес) и овладевать соответствующими навыками для внедрения микросервисов, например, использовать DDD для разделения сервисов, чтобы лучше управлять микросервисами. Архитектура.

Posted by Yuan Shenjian• 25 июля 2017 г. @ThoughtWorks®

Уведомление об авторских правах:Бесплатно для некоммерческой перепечатки • • • Сохранить непроизводную подпись |Creative Commons BY-NC-ND 3.0

Оригинальная ссылка:Проектный институт Цао Цао/тест-страйт… Поддержка оригинала

⤧ Следующий пост CSRF ⤧ Предыдущая запись Модульное тестирование глазами программиста