👇Особенности тестирования с брокерами сообщений по моему опыту - пост в нельзяграме - подписаться
⠀
Немного теории: брокеры сообщений, в основном, состоят из Producer или Publisher (поставщик сообщений), очередь сообщений и Consumer или Subscriber (получатель сообщений), еще есть topic (топик (тема) - это логическая единица, которая объединяет сообщения по некоторому критерию).
Вот я работала с инструментом Tibco EMS (Enterprise Message Service) - это корпоративная платформа обмена сообщениями), где я подписывалась на различные топики и вычитывала сообщения после конкретной проверки.
Очередь сообщений - это как почтовый ящик, где хранятся сообщения, отправленные продюсером.
В зависимости от брокера сообщений, сообщения могут удаляться после прочтения, а могут не удаляться.
⠀
В основном, я работала Tibco EMS, сейчас с Kafka, c Redis и RabbitMQ имею практический опыт.
Вот для меня как раз основное тестирование проводилось через топики, опишу пункты, что я проверяла и делала через топики.
🔅- отправка, то есть проверка корректности отправки сообщений в топики брокера
🔅- получение необходимых сообщений, проверка на отсутствие дублирующих сообщений
🔅- проверка содержания полученных сообщений, которые соответствует ожидаемым данным или формату
🔅- обработка нескольких сообщений, различных типов сообщений, как JSON, XML
🔅- вычитка сообщений
🔅- загрузка своих сообщений в топик c валидным и невалидным форматом, и как приложение правильно обрабатывала ошибки, возникающие при отправке или получении сообщений
🔅- проверка взаимодействия приложения с другими сервисами через топики
🔅- оценка времени, требуемое для доставки сообщений от отправителя к получателю, чтобы убедиться, что оно соответствует ожиданиям, как раз я ожидала, через сколько времени, появятся сообщения после выполняемого действия
🔅- проверка, что сообщения доставляются в том же порядке, в котором они были отправлены
⠀
Всё на уровне функциональных проверок, без нагрузочного тестирования.
⠀
С каким брокером сообщений работаешь?
Какие пункты проверки добавишь?
⠀
#тестированиеПО #QA #брокерысообщений
👇Особенности тестирования с брокерами сообщений по моему опыту - пост в нельзяграме - подписаться
⠀
Немного теории: брокеры сообщений, в основном, состоят из Producer или Publisher (поставщик сообщений), очередь сообщений и Consumer или Subscriber (получатель сообщений), еще есть topic (топик (тема) - это логическая единица, которая объединяет сообщения по некоторому критерию).
Вот я работала с инструментом Tibco EMS (Enterprise Message Service) - это корпоративная платформа обмена сообщениями), где я подписывалась на различные топики и вычитывала сообщения после конкретной проверки.
Очередь сообщений - это как почтовый ящик, где хранятся сообщения, отправленные продюсером.
В зависимости от брокера сообщений, сообщения могут удаляться после прочтения, а могут не удаляться.
⠀
В основном, я работала Tibco EMS, сейчас с Kafka, c Redis и RabbitMQ имею практический опыт.
Вот для меня как раз основное тестирование проводилось через топики, опишу пункты, что я проверяла и делала через топики.
🔅- отправка, то есть проверка корректности отправки сообщений в топики брокера
🔅- получение необходимых сообщений, проверка на отсутствие дублирующих сообщений
🔅- проверка содержания полученных сообщений, которые соответствует ожидаемым данным или формату
🔅- обработка нескольких сообщений, различных типов сообщений, как JSON, XML
🔅- вычитка сообщений
🔅- загрузка своих сообщений в топик c валидным и невалидным форматом, и как приложение правильно обрабатывала ошибки, возникающие при отправке или получении сообщений
🔅- проверка взаимодействия приложения с другими сервисами через топики
🔅- оценка времени, требуемое для доставки сообщений от отправителя к получателю, чтобы убедиться, что оно соответствует ожиданиям, как раз я ожидала, через сколько времени, появятся сообщения после выполняемого действия
🔅- проверка, что сообщения доставляются в том же порядке, в котором они были отправлены
⠀
Всё на уровне функциональных проверок, без нагрузочного тестирования.
⠀
С каким брокером сообщений работаешь?
Какие пункты проверки добавишь?
⠀
#тестированиеПО #QA #брокерысообщений
❤8🔥3✍2👨💻2❤🔥1👍1
Forwarded from Оповещения по курсам от protestinginfo
Продлила доступ на 9 месяцев обратной связи
⚡️ Онлайн-курс по тестированию бэкендат!
Новый поток стартует 5 АВГУСТА 2026г, но присоединиться можно уже сейчас 👌
И это даже выгодно:
— заранее начну делиться полезными материалами, рекомендациями и подготовкой к старту курса
— сможете спокойно войти в обучение без спешки и с хорошей базой
— доступ 9 месяцев
📌 Что будет на курсе:
• API тестирование (REST) — Postman, Swagger
• SQL от базового до JOIN — PostgreSQL, ClickHouse
• Redis — работа с кэшем
• Kafka — проверка асинхронных запросов
• Реальные практические задания по API + SQL
🔥 В программе:
— тестирование User Account API + SQL + MAIL API
— ClickHouse: анализ статус-кодов
— Redis: работа с данными пользователя
— Forum API + SQL
— негативные проверки запросов и многое другое
Скидки на участие:
Условия и сроки проверки заданий:
Тариф 1: без проверки.
Проверка заданий осуществляется только в течение ограниченного срока с начала обучения:
Тариф 2: только первые 3 месяца
Тариф 3: только первые 5 месяцев
Тариф 4 (полный): 9 месяцев
Обратная связь на протяжении всего доступа.
📖 Полная программа:
https://protestinginfo.ru/practice_api_sql#program
💳 Тарифы:
https://coreapp.ai/app/checkout/67631889a17350fd817c5cdb
⚡️ Онлайн-курс по тестированию бэкендат!
Новый поток стартует 5 АВГУСТА 2026г, но присоединиться можно уже сейчас 👌
И это даже выгодно:
— заранее начну делиться полезными материалами, рекомендациями и подготовкой к старту курса
— сможете спокойно войти в обучение без спешки и с хорошей базой
— доступ 9 месяцев
📌 Что будет на курсе:
• API тестирование (REST) — Postman, Swagger
• SQL от базового до JOIN — PostgreSQL, ClickHouse
• Redis — работа с кэшем
• Kafka — проверка асинхронных запросов
• Реальные практические задания по API + SQL
🔥 В программе:
— тестирование User Account API + SQL + MAIL API
— ClickHouse: анализ статус-кодов
— Redis: работа с данными пользователя
— Forum API + SQL
— негативные проверки запросов и многое другое
Скидки на участие:
APISQL25 — скидка 25% до 25 июля 2026APISQL20 — скидка 20% до 5 августа 2026APISQL15 — скидка 15% до 15 августа 2026Условия и сроки проверки заданий:
Тариф 1: без проверки.
Проверка заданий осуществляется только в течение ограниченного срока с начала обучения:
Тариф 2: только первые 3 месяца
Тариф 3: только первые 5 месяцев
Тариф 4 (полный): 9 месяцев
Обратная связь на протяжении всего доступа.
📖 Полная программа:
https://protestinginfo.ru/practice_api_sql#program
💳 Тарифы:
https://coreapp.ai/app/checkout/67631889a17350fd817c5cdb
protestinginfo.ru
Закрепление знаний по тестированию ПО
❤3👍2🤔2🙏1
Forwarded from Оповещения по курсам от protestinginfo
Хочу поблагодарить Надин за такой замечательный курс! За время прохождения я освоила навыки работы в Redis, а также стала более уверенно работать с Postman, Swagger и DBeaver. Считаю полезным то, что уроки устроены таким образом, что нужно возвращаться назад и повторять уже пройденное, это позволяет лучше усваивать материал. Отдельно хочу сказать про обратную связь - полноценные подробные ответы от Надин, где указано на что стоит обратить внимание при работе с с заданием, что помогало по итогу самостоятельно разобраться в ответе, а не получить готовый ответ от создателя курса) Сейчас перехожу к курсу Надин по подготовке к собеседованиям, чтобы закрепить все полученные навыки! Спасибо!
Замечательный отзыв от ученицы❤️
💘3❤2🔥2
📚 ProTestingInfo 🔷 Канал по тестированию 📚 pinned «Продлила доступ на 9 месяцев обратной связи ⚡️ Онлайн-курс по тестированию бэкендат! Новый поток стартует 5 АВГУСТА 2026г, но присоединиться можно уже сейчас 👌 И это даже выгодно: — заранее начну делиться полезными материалами, рекомендациями и подготовкой…»
Media is too big
VIEW IN TELEGRAM
Разверни👇 SSE В POSTMAN С GEMINI API
Подписаться в нельзяграм - пост
Postman можно тестировать Server-Sent Events (SSE)
SSE — это технология, позволяющая серверу отправлять данные клиенту через одно постоянное HTTP-соединение. В отличие от WebSocket, SSE работает поверх обычного HTTP и автоматически переподключается при обрыве. Идеально для чатов и потоковой генерации AI!
ПОШАГОВАЯ ИНСТРУКЦИЯ:
1️⃣ Получаем API ключ:
→ aistudio.google.com/app/apikey (в РФ используй VPN)
→ Жмем «Get API key»
→ Копируем ключ (начинается на AIza...)
2️⃣ Настраиваем Postman:
→ Создаем новый запрос
→ Метод POST
→ URL: https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:streamGenerateContent?alt=sse&key=ВАШ_КЛЮЧ
❗ Важно: параметр alt=sse включает потоковую передачу! Без него ответ придет одним куском.
3️⃣ Заголовки:
→ Вкладка Headers
→ Content-Type: application/json
4️⃣ Тело запроса:
→ Body → raw → JSON{
«contents»: [{
«parts»: [{«text»: «Расскажи о SSE»}]
}]
}
Совет: добавьте «generationConfig»: {«maxOutputTokens»: 200}, чтобы ограничить длину ответа.
5️⃣ Жмем Send и наблюдаем магию! ✨
ЧТО УВИДИМ В ОТВЕТЕ:
📊 Поток сообщений от сервера в реальном времени
📝 Каждая строка начинается с data: — это формат SSE
🔢 Текст генерируется по частям (токенам), как в ChatGPT
⚡ В последнем сообщении придет usageMetadata
SSE vs WebSocket vs Polling:
• SSE — однонаправленный поток через HTTP (просто!)
• WebSocket — двусторонняя связь (сложнее)
• Polling — клиент постоянно опрашивает сервер (тратит ресурсы 😅)
Где использовать SSE:
✓ Потоковая генерация текста AI
✓ Чаты — пользователь видит ответ по мере написания
✓ Live-уведомления и биржевые котировки
✓ Прогресс-бары долгих операций
Лайфхак для тех, кто работает с чат-ботами:
SSE позволяет показать «печатающий» ответ — текст появляется плавно, а не одним сообщением через 10 секунд.
⚠️ Частые ошибки:
• Забыли alt=sse → ответ без потока
• Неверный Content-Type → 400 Bad Request
• Старый Postman → обновитесь до версии 12+
Подписывайся на @protestinginfo
Пробовали уже SSE в работе? Делитесь в комментариях! 👇
#postman #api #testing #qa
Подписаться в нельзяграм - пост
Postman можно тестировать Server-Sent Events (SSE)
SSE — это технология, позволяющая серверу отправлять данные клиенту через одно постоянное HTTP-соединение. В отличие от WebSocket, SSE работает поверх обычного HTTP и автоматически переподключается при обрыве. Идеально для чатов и потоковой генерации AI!
ПОШАГОВАЯ ИНСТРУКЦИЯ:
1️⃣ Получаем API ключ:
→ aistudio.google.com/app/apikey (в РФ используй VPN)
→ Жмем «Get API key»
→ Копируем ключ (начинается на AIza...)
2️⃣ Настраиваем Postman:
→ Создаем новый запрос
→ Метод POST
→ URL: https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:streamGenerateContent?alt=sse&key=ВАШ_КЛЮЧ
❗ Важно: параметр alt=sse включает потоковую передачу! Без него ответ придет одним куском.
3️⃣ Заголовки:
→ Вкладка Headers
→ Content-Type: application/json
4️⃣ Тело запроса:
→ Body → raw → JSON{
«contents»: [{
«parts»: [{«text»: «Расскажи о SSE»}]
}]
}
Совет: добавьте «generationConfig»: {«maxOutputTokens»: 200}, чтобы ограничить длину ответа.
5️⃣ Жмем Send и наблюдаем магию! ✨
ЧТО УВИДИМ В ОТВЕТЕ:
📊 Поток сообщений от сервера в реальном времени
📝 Каждая строка начинается с data: — это формат SSE
🔢 Текст генерируется по частям (токенам), как в ChatGPT
⚡ В последнем сообщении придет usageMetadata
SSE vs WebSocket vs Polling:
• SSE — однонаправленный поток через HTTP (просто!)
• WebSocket — двусторонняя связь (сложнее)
• Polling — клиент постоянно опрашивает сервер (тратит ресурсы 😅)
Где использовать SSE:
✓ Потоковая генерация текста AI
✓ Чаты — пользователь видит ответ по мере написания
✓ Live-уведомления и биржевые котировки
✓ Прогресс-бары долгих операций
Лайфхак для тех, кто работает с чат-ботами:
SSE позволяет показать «печатающий» ответ — текст появляется плавно, а не одним сообщением через 10 секунд.
⚠️ Частые ошибки:
• Забыли alt=sse → ответ без потока
• Неверный Content-Type → 400 Bad Request
• Старый Postman → обновитесь до версии 12+
Подписывайся на @protestinginfo
Пробовали уже SSE в работе? Делитесь в комментариях! 👇
#postman #api #testing #qa
❤3❤🔥3✍2
Forwarded from GetAnalyst - Навыки • Системный анализ • Бизнес-анализ
🚦 Всё про брокеры: как работают и зачем нужны 🚥
Брокеры — это посредники в передаче сообщений между системами или сервисами.
Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.
👉 Принцип работы:
▫️ Сервис 1 (Producer/ Производитель) хочет отправить данные в Сервис 2 (Consumer/ Потребитель).
▫️ Сервис 2 в это время может быть перегружен или занят.
▫️ Чтобы Сервис 1 не ждал, пока Сервис 2 станет доступен, он кладет сообщение в Брокер и продолжает свою работу.
▫️ Брокер сохраняет сообщение и ставит его в очередь к обработке.
▫️ Как только Сервис 2 становится доступен, то он забирает сообщение из Брокера и обрабатывает его.
По сути брокеры - это временные Базы Данных,которые гарантируют, что сообщения (данные) в них будут храниться, пока их не заберут и не обработают соответствующие системы или сервисы.
НО! Это всё же не БД, хранить в них сообщения до бесконечности не надо.
👉 Брокеры могут использоваться:
+ в сервисной и микросервисной архитектуре (хореография),
+ в событийно-ориентированной архитектуре (EDA),
+ когда нужна фоновая обработка событий в монолите,
+ для асинхронных интеграций.
👉 Брокеры сообщений предлагают два основных шаблона обмена данными:
1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.
2. Публикация-подписка (Publish/Subscribe)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.
Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.
Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.
#АрхитектураGA
📱 Tg | 💙 ВК | 💬 Max
Брокеры — это посредники в передаче сообщений между системами или сервисами.
Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.
👉 Принцип работы:
▫️ Сервис 1 (Producer/ Производитель) хочет отправить данные в Сервис 2 (Consumer/ Потребитель).
▫️ Сервис 2 в это время может быть перегружен или занят.
▫️ Чтобы Сервис 1 не ждал, пока Сервис 2 станет доступен, он кладет сообщение в Брокер и продолжает свою работу.
▫️ Брокер сохраняет сообщение и ставит его в очередь к обработке.
▫️ Как только Сервис 2 становится доступен, то он забирает сообщение из Брокера и обрабатывает его.
По сути брокеры - это временные Базы Данных,которые гарантируют, что сообщения (данные) в них будут храниться, пока их не заберут и не обработают соответствующие системы или сервисы.
НО! Это всё же не БД, хранить в них сообщения до бесконечности не надо.
👉 Брокеры могут использоваться:
+ в сервисной и микросервисной архитектуре (хореография),
+ в событийно-ориентированной архитектуре (EDA),
+ когда нужна фоновая обработка событий в монолите,
+ для асинхронных интеграций.
👉 Брокеры сообщений предлагают два основных шаблона обмена данными:
1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.
2. Публикация-подписка (Publish/Subscribe)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.
Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.
Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6✍3❤2🆒1