bootg.com »
United States »
Библиотека тестировщика | QA, тестирование, quality assurance, manual testing, autotesting, ручное тестирование, автотесты » Telegram Web
📶 Паттерны коммуникации в распределенных системах
Распределенные системы состоят из многих отдельных частей/узлов, работающих вместе, но физически расположенных в разных местах. Эти части системы должны общаться друг с другом через сеть, чтобы система могла функционировать как единое целое.
Хотя коммуникация критически важна, правильно ее организовать бывает непросто: разработчики иногда пытаются использовать один и тот же подход ко всем задачам коммуникации, что может быть неэффективно. Важно понимать, что существуют разные способы организации коммуникации, и выбор правильного метода зависит от конкретной задачи. Рассмотрим основные паттерны коммуникации, которые можно использовать для решения разных задач.
☑️ Запрос-ответ с HTTP
Этот синхронный паттерн коммуникации предполагает, что один сервис отправляет запрос другому сервису и ожидает ответа или ошибки, блокируя свою работу до получения результата. REST, наиболее популярный архитектурный стиль для этой модели коммуникации, использует методы протокола HTTP — GET, POST, PUT и DELETE.
Однако использование этого паттерна может привести к проблемам, если сервисы образуют цепочку взаимодействий: в таком случае сбой одного из сервисов может привести к отказу всей операции, а также к расточительному использованию ресурсов и каскадным сбоям.
☑️ Общие данные
Этот паттерн часто остается незамеченным, поскольку разработчики не всегда воспринимают его как модель коммуникации. В рамках этого подхода один компонент записывает данные в определенное место, а другой компонент считывает и обрабатывает эти данные. Например, один сервис может загрузить файл в облачное объектное хранилище (например, в корзину Amazon S3), а другой сервис затем извлекает этот файл для дальнейших действий.
Главное преимущество этого паттерна — простота реализации и возможность обеспечения взаимодействия между устаревшими и современными системами без проблем совместимости. Однако он не подходит для сценариев, требующих низкой задержки.
☑️ Асинхронный запрос-ответ
В отличие от синхронного подхода, запрос-ответ может быть реализован асинхронно и без блокировки. В этом случае получающий сервис должен явно знать место назначения для отправки ответа. Для реализации этого паттерна идеально подходят очереди сообщений, которые позволяют буферизовать несколько запросов.
Основная сложность здесь — корреляция между запросом и ответом: экземпляр сервиса, отправивший запрос, может отличаться от экземпляра, получающего ответ, поэтому требуется способ отслеживания запросов.
☑️ Коммуникация на основе событий
В этом подходе сервисы не общаются напрямую друг с другом, а генерируют события, которые могут быть использованы другими сервисами. Это требует наличия места для отправки данных о событиях и механизма, позволяющего получающим сервисам обнаруживать эти события. Брокеры сообщений, такие как RabbitMQ, могут обрабатывать оба этих аспекта. Издатели используют API для отправки событий в брокер, который управляет подписками и уведомляет подписчиков при поступлении события.
Этот паттерн идеально подходит для создания слабосвязанных взаимодействий между сервисами. Однако брокер сообщений должен обеспечивать надежную доставку событий, их упорядочивание и согласованность. Кроме того, добавляется дополнительный компонент в систему.
👨💻 Подробнее читайте в статье.
📨 Материал взят из нашей еженедельной email-рассылки, посвященной бэкенду. Подпишитесь, чтобы быть в числе первых, кто получит дайджест.
Распределенные системы состоят из многих отдельных частей/узлов, работающих вместе, но физически расположенных в разных местах. Эти части системы должны общаться друг с другом через сеть, чтобы система могла функционировать как единое целое.
Хотя коммуникация критически важна, правильно ее организовать бывает непросто: разработчики иногда пытаются использовать один и тот же подход ко всем задачам коммуникации, что может быть неэффективно. Важно понимать, что существуют разные способы организации коммуникации, и выбор правильного метода зависит от конкретной задачи. Рассмотрим основные паттерны коммуникации, которые можно использовать для решения разных задач.
☑️ Запрос-ответ с HTTP
Этот синхронный паттерн коммуникации предполагает, что один сервис отправляет запрос другому сервису и ожидает ответа или ошибки, блокируя свою работу до получения результата. REST, наиболее популярный архитектурный стиль для этой модели коммуникации, использует методы протокола HTTP — GET, POST, PUT и DELETE.
Однако использование этого паттерна может привести к проблемам, если сервисы образуют цепочку взаимодействий: в таком случае сбой одного из сервисов может привести к отказу всей операции, а также к расточительному использованию ресурсов и каскадным сбоям.
☑️ Общие данные
Этот паттерн часто остается незамеченным, поскольку разработчики не всегда воспринимают его как модель коммуникации. В рамках этого подхода один компонент записывает данные в определенное место, а другой компонент считывает и обрабатывает эти данные. Например, один сервис может загрузить файл в облачное объектное хранилище (например, в корзину Amazon S3), а другой сервис затем извлекает этот файл для дальнейших действий.
Главное преимущество этого паттерна — простота реализации и возможность обеспечения взаимодействия между устаревшими и современными системами без проблем совместимости. Однако он не подходит для сценариев, требующих низкой задержки.
☑️ Асинхронный запрос-ответ
В отличие от синхронного подхода, запрос-ответ может быть реализован асинхронно и без блокировки. В этом случае получающий сервис должен явно знать место назначения для отправки ответа. Для реализации этого паттерна идеально подходят очереди сообщений, которые позволяют буферизовать несколько запросов.
Основная сложность здесь — корреляция между запросом и ответом: экземпляр сервиса, отправивший запрос, может отличаться от экземпляра, получающего ответ, поэтому требуется способ отслеживания запросов.
☑️ Коммуникация на основе событий
В этом подходе сервисы не общаются напрямую друг с другом, а генерируют события, которые могут быть использованы другими сервисами. Это требует наличия места для отправки данных о событиях и механизма, позволяющего получающим сервисам обнаруживать эти события. Брокеры сообщений, такие как RabbitMQ, могут обрабатывать оба этих аспекта. Издатели используют API для отправки событий в брокер, который управляет подписками и уведомляет подписчиков при поступлении события.
Этот паттерн идеально подходит для создания слабосвязанных взаимодействий между сервисами. Однако брокер сообщений должен обеспечивать надежную доставку событий, их упорядочивание и согласованность. Кроме того, добавляется дополнительный компонент в систему.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔧🔧 Тестирование состояний и переходов / Таблица принятия решений
Техники тест-дизайна: тестирование состояний и переходов (или диаграмма), таблица принятия решений, причина и следствие, предугадывание ошибок.
01:18 — Тестирование состояний и переходов (State Transition Testing)
07:15 — Таблица принятия решений (Decision Table)
12:35 — Причина и следствие (Cause/Effect)
15:10 — Предугадывание ошибок (Error Guessing)
16:27 — Итоги. Практические применение
#видео
Техники тест-дизайна: тестирование состояний и переходов (или диаграмма), таблица принятия решений, причина и следствие, предугадывание ошибок.
01:18 — Тестирование состояний и переходов (State Transition Testing)
07:15 — Таблица принятия решений (Decision Table)
12:35 — Причина и следствие (Cause/Effect)
15:10 — Предугадывание ошибок (Error Guessing)
16:27 — Итоги. Практические применение
#видео
#дайджест перед выходными
🐞 Тестирование «черного ящика» или опыт десятка machine learning проектов — доклад с конференции SQA Days-26
🐞 Ценность рефакторинга и тестирования для бизнеса — как объяснить заказчику, что тесты полезны, а время, потраченное на рефакторинг — это время, потраченное не зря
🐞 ИИ в тестировании — крутой репозиторий обучающих ресурсов
🐞 Создание основных компонентов для мобильных устройств — разработка платформы автоматизации тестирования
🐞 Business driven testing — как тестировщику решать задачи бизнеса
🐞 Тестирование «черного ящика» или опыт десятка machine learning проектов — доклад с конференции SQA Days-26
🐞 Ценность рефакторинга и тестирования для бизнеса — как объяснить заказчику, что тесты полезны, а время, потраченное на рефакторинг — это время, потраченное не зря
🐞 ИИ в тестировании — крутой репозиторий обучающих ресурсов
🐞 Создание основных компонентов для мобильных устройств — разработка платформы автоматизации тестирования
🐞 Business driven testing — как тестировщику решать задачи бизнеса
🍾🍾 Девять причин, почему тестирование становится бутылочным горлышком
Часто можно слышать, как тестировщики жалуются, что стали «слабым звеном» для своей команды. На них постоянно давят, чтобы они закруглялись с тестированием, и им кажется, что у них не остается времени на качественное исследовательское тестирование или хорошую автоматизацию.
В статье вы узнаете, применимы ли причины к вашей команде.
#гайд
Часто можно слышать, как тестировщики жалуются, что стали «слабым звеном» для своей команды. На них постоянно давят, чтобы они закруглялись с тестированием, и им кажется, что у них не остается времени на качественное исследовательское тестирование или хорошую автоматизацию.
В статье вы узнаете, применимы ли причины к вашей команде.
#гайд
⚙️⚙️ Автотесты на Postman в связке с Newman, Gitlab CI и AllureTestops: как организовать тестирование бэка на проекте
В данной статье автор расскажет о том, как организовать тестирование бэка на проектах.
В качестве основного инструмента тестирования был выбран Postman. Проверки прошли различные этапы эволюции. Сначала использовался данный инструмент только для визуальной проверки отдельно взятых методов бэка. Проверка заключалась в том, что импортировался либо yaml файл с коллекцией списка методов некоторого микросервиса, либо в виде импорта отдельного курл запроса. При этом проверялись различные комбинации проверок заголовков, тел ответов и запросов, коды ответов и т.д.
Продолжение тут
#гайд
В данной статье автор расскажет о том, как организовать тестирование бэка на проектах.
В качестве основного инструмента тестирования был выбран Postman. Проверки прошли различные этапы эволюции. Сначала использовался данный инструмент только для визуальной проверки отдельно взятых методов бэка. Проверка заключалась в том, что импортировался либо yaml файл с коллекцией списка методов некоторого микросервиса, либо в виде импорта отдельного курл запроса. При этом проверялись различные комбинации проверок заголовков, тел ответов и запросов, коды ответов и т.д.
Продолжение тут
#гайд
Используете ли вы VPN?
Anonymous Poll
14%
Нет, мне лень
29%
Очень редко по особым случаям
36%
Регулярно
21%
Почти не выключаю/каждый день
🧑💻 Статьи для IT: как объяснять и распространять значимые идеи
Напоминаем, что у нас есть бесплатный курс для всех, кто хочет научиться интересно писать — о программировании и в целом.
Что: семь модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций.
Для кого: для авторов, копирайтеров и просто программистов, которые хотят научиться интересно рассказывать о своих проектах.
👉Материалы регулярно дополняются, обновляются и корректируются. А еще мы отвечаем на все учебные вопросы в комментариях курса.
Напоминаем, что у нас есть бесплатный курс для всех, кто хочет научиться интересно писать — о программировании и в целом.
Что: семь модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций.
Для кого: для авторов, копирайтеров и просто программистов, которые хотят научиться интересно рассказывать о своих проектах.
👉Материалы регулярно дополняются, обновляются и корректируются. А еще мы отвечаем на все учебные вопросы в комментариях курса.
🤔🤔 Защита персональных данных в мобильных приложениях: как не нарушить закон
В статье рассматривается, под какие требования попадают приложения, насколько законно хранить персональные данные на смартфоне в открытом виде и попадает ли мобильное ПО под действие Федерального закона «О персональных данных» (152-ФЗ) и подзаконных актов по теме защиты ПДн
Читать статью
#почитать
В статье рассматривается, под какие требования попадают приложения, насколько законно хранить персональные данные на смартфоне в открытом виде и попадает ли мобильное ПО под действие Федерального закона «О персональных данных» (152-ФЗ) и подзаконных актов по теме защиты ПДн
Читать статью
#почитать
🧔🧔 Стала тестировщиком в Австрии
Ольга переехала в Австрию, выучилась на тестировщика и начала IT-карьеру в австрийской компании
В видосе будут ответы на следующие вопросы:
👉 Кем работала раньше?
👉 В каком городе сейчас живешь и на какую компанию работаешь?
👉 Какие требования к английскому?
👉 Чем отличается поиск на локальном и международном рынке?
👉 Проходила собеседование и делала тестовые? Какие они были?
👉 Зарплаты/налоги?
👉 Из того что узнала на обучении что пригодилось, а что нет?
Смотреть
#видео
Ольга переехала в Австрию, выучилась на тестировщика и начала IT-карьеру в австрийской компании
В видосе будут ответы на следующие вопросы:
👉 Кем работала раньше?
👉 В каком городе сейчас живешь и на какую компанию работаешь?
👉 Какие требования к английскому?
👉 Чем отличается поиск на локальном и международном рынке?
👉 Проходила собеседование и делала тестовые? Какие они были?
👉 Зарплаты/налоги?
👉 Из того что узнала на обучении что пригодилось, а что нет?
Смотреть
#видео
👂👂 Слушаем события в Selenium с помощью Listeners. Как реагировать на события без тонны кода
Работа с веб-приложениями с использованием Selenium зачастую требует выполнения различных действий и обработки многочисленных событий. В стандартном подходе это может привести к написанию большого количества кода для логирования, обработки ошибок и выполнения других задач. В этой статье мы рассмотрим, как можно значительно упростить этот процесс, используя Listeners в Selenium
Продолжение тут
#туториал
Работа с веб-приложениями с использованием Selenium зачастую требует выполнения различных действий и обработки многочисленных событий. В стандартном подходе это может привести к написанию большого количества кода для логирования, обработки ошибок и выполнения других задач. В этой статье мы рассмотрим, как можно значительно упростить этот процесс, используя Listeners в Selenium
Продолжение тут
#туториал
Что такое параллельное тестирование?
Anonymous Quiz
16%
Тестирование нового и старого билда одновременно для сравнения результатов
17%
Тестирование, при котором несколько тестировщиков работают над одним и тем же проектом
1%
Тестирование, при котором тесты выполняются только в ночное время для снижения нагрузки на систему
66%
Тестирование, при котором одновременно тестируются различные компоненты системы на разных платформах
#дайджест перед выходными
🐞 Как протестировать плагин на разных версиях браузера — советы по упрощению тестирования с помощью песочницы и виртуалки
🐞 Как пользоваться локаторами Playground — подробное руководство
🐞 Тестирование «черного ящика» или опыт десятка machine learning проектов — доклад с конфы SQA Days-26
🐞 Тест-дизайн в автоматизации тестирования — тест-дизайн и его влияние на качество автотестов
🐞 Создание основных компонентов для мобильных устройств — как создавать DriverFactory, App Execution Plugins и AndroidDriver Adapters
🐞 Как протестировать плагин на разных версиях браузера — советы по упрощению тестирования с помощью песочницы и виртуалки
🐞 Как пользоваться локаторами Playground — подробное руководство
🐞 Тестирование «черного ящика» или опыт десятка machine learning проектов — доклад с конфы SQA Days-26
🐞 Тест-дизайн в автоматизации тестирования — тест-дизайн и его влияние на качество автотестов
🐞 Создание основных компонентов для мобильных устройств — как создавать DriverFactory, App Execution Plugins и AndroidDriver Adapters