Что тестировать в при работе с очередями
Перейти к содержимому

Что тестировать в при работе с очередями

  • автор:

Работа с очередями сообщений в процессах

В редакции ELMA Enterprise при моделировании процесса очереди сообщений можно использовать в двух случаях:

  1. Если нужно настроить, чтобы процесс запускался после получения сообщения из очереди. Подробнее об этом читайте в статье «События».
  2. Если в процессе требуется отправлять сообщения в очередь или получать их из очереди. Для этого используются операции Получить сообщение и Отправить сообщение . Эти операции независимы друг от друга. Кроме того, не рекомендуется размещать их в одном процессе. Для каждой из них следует использовать отдельный процесс. Чтобы добавить операцию, на странице процесса перейдите на вкладку Графическая модель и нажмите кнопку Развернуть или кнопку в правом нижнем углу экрана. Операции отображаются слева в разделе Очереди сообщений .

Операция «Получить сообщение»

Операция Получить сообщение позволяет проверять наличие сообщений в очереди и получать их. При этом пользователям предоставляется информация о возникших ошибках.

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

message-queues-in-processes-1

При необходимости измените название операции и укажите описание.

Очередь сообщений * — выбор очереди, из которой будут приходить системные сообщения. Доступны очереди, созданные в дизайнере в разделе Очереди сообщений .

Сценарий определения типа сообщения — сценарий, в котором автоматически определяется тип получаемого сообщения. Сценарий выполняется перед получением сообщения. Это поле отображается, только если вы выбрали тип очереди MSMQ.

Сценарий обработки сообщения — сценарий для определения действий, которые будут выполняться после получения сообщения из очереди.

Чтобы добавить новый сценарий, нажмите и введите имя сценария. Чтобы открыть сценарий в редакторе, нажмите .

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

Информируемые при ошибках — добавление пользователей ELMA4, которые получают системное уведомление, если при получении сообщения произошла ошибка. Чтобы добавить пользователей из матрицы ответственности, наведите курсор на кнопку + Добавить . Чтобы указать пользователей из оргструктуры, нажмите кнопку + Должность . Если вы хотите удалить пользователя из списка, нажмите .

Период проверки очереди — интервал времени, через который ELMA4 будет обращаться к серверу сообщений и получать от него сообщения. По умолчанию — 15 минут. Можно указать определенное количество дней, часов или минут.

Операция «Отправить сообщение»

Операция Отправить сообщение позволяет ставить сообщения в определенную очередь и отправлять их. При этом пользователям предоставляется информация о возникших ошибках.

Перетащите операцию на схему процесса и нажмите на неё дважды. Справа откроется окно настроек, в котором нужно заполнить поля. Укажите настройки и нажмите кнопку Сохранить .

message-queues-in-processes-2

При необходимости измените название операции и укажите описание.

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

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

Информируемые при ошибках — добавление пользователей ELMA4, которые получают системное уведомление, если при отправке сообщения произошла ошибка. Чтобы добавить пользователей из матрицы ответственности, наведите курсор на кнопку + Добавить . Чтобы указать пользователей из оргструктуры, нажмите кнопку + Должность . Если вы хотите удалить пользователя из списка, нажмите .

Нашли опечатку? Выделите текст, нажмите ctrl + enter и оповестите нас

Тестирование и проблема очередей в Laravel

введите сюда описание изображения

Имееться простой достаточно тест на Laravel. Ну примерно следующего содержания. $this->json(‘post’, route(‘. ‘))->assertOk(); После запуска получаю в консоле такую ошибку: Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Bus\Dispatcher] is not instantiable. in . \vendor\laravel\framework\src\Illuminate\Container\Container.php:1093 В контроллере который обрабатывает запрос после ответа идет еще сброс кэша. CacheClearJob::dispatch(); В самом Job классе просто вызов \Cache::forget(‘key’) Версия Laravel 8, PHP 7.4 UPD: вызов очистки кэша через register_shutdown_function() в конструкторе. Это и стало причиной проблеммы, добавляю в описание т.к. этот момент был только на скрине.

Отслеживать
задан 11 янв 2022 в 19:25
1,935 1 1 золотой знак 8 8 серебряных знаков 20 20 бронзовых знаков
Ошибка воспроизводится только в тестах? Кажется, что это должно касаться и обычного запуска
11 янв 2022 в 19:55

@nomnoms12 удивительно но нет. при обычном запуске все хорошо отрабатывает. причем сам тест работает. Tests: 1 passed . после всех тестов в консоли появляется эта ошибка. Если закоментировать CacheClearJob::dispatch() то нет ёё.

11 янв 2022 в 20:00

Можете, пожалуйста, выложить часть файла config/app.php ? Мне интересно, как там выглядит импорт BusServiceProvider

11 янв 2022 в 20:05

@nomnoms12 хмм подозреваю что не в том дело. Вот смотрите, я закоментировал тот код что с очередями. В приложении в сервис провайдере регистрируется некий сервис $this->app->singleton(‘environment-service’, function ($app): EnvironmentService < return new EnvironmentService(); >); теперь проблемма с ним, не находит его. — Fatal error: Uncaught ReflectionException: Class environment-service does not exist

11 янв 2022 в 20:50

@nomnoms12 используеться app(‘envinonment-service’) и в приложении в обычном режиме нормально работает.

11 янв 2022 в 20:52

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

register_shutdown_function() запускается, когда свою работу завершает не только сам тест, но и PHPUnit. Я расставил в разных файлах вывод того, что сейчас выполняется:

echo sprintf("%s called\n", __METHOD__); 

Затем запустил, и получилось так:

Tests\Feature\Order\OrderCreatedTest::testOrderCreated called App\Domain\Order\Controllers\OrderController::order called Illuminate\Foundation\Testing\TestCase::tearDown called PASS Tests\Feature\Order\OrderCreatedTest ✓ order created Tests: 1 passed Time: 0.15s App\Domain\Order\Controllers\OrderController::shutdown called 

Получается, порядок такой:

  1. запуск теста
  2. запуск контроллера
  3. запуск tearDown()
  4. запуск метода shutdown() , который был зарегистрирован через register_shutdown_function() в контроллере

TestCase , от которого отнаследован тест, имеет 2 важных метода:

  • setUp() — создает экземпляр приложения, бутсрапит его. На этом экземпляре, собственно, и прогоняются тесты.
  • tearDown() , который «прибирается»: $this->app->flush() . Что в этом flush() происходит?
public function flush() < parent::flush(); $this->buildStack = []; $this->loadedProviders = []; $this->bootedCallbacks = []; $this->bootingCallbacks = []; $this->deferredServices = []; $this->reboundCallbacks = []; $this->serviceProviders = []; $this->resolvingCallbacks = []; $this->terminatingCallbacks = []; $this->beforeResolvingCallbacks = []; $this->afterResolvingCallbacks = []; $this->globalBeforeResolvingCallbacks = []; $this->globalResolvingCallbacks = []; $this->globalAfterResolvingCallbacks = []; > 

А это — содержимое parent::flush() :

public function flush() < $this->aliases = []; $this->resolved = []; $this->bindings = []; $this->instances = []; $this->abstractAliases = []; $this->scopedInstances = []; > 

Как видите, происходит серьезная чистка экземпляра приложения, после которой мало что продолжает работать. Если закомментировать $this->app->flush(); , ваш тест пройдет, но это также нарушит логику PHPUnit, в котором каждый тест должен быть независим, а значит «уборка» необходима.

Что можно посоветовать? Найти другой способ очистки кеша. Деструктор контроллера не подходит по этой же причине — выполняется после tearDown() . Попробуйте это:

public function __construct() < CacheClearJob::dispatch()->afterResponse(); > 

Тестирование очередей и потоков данных.

Типы очередей – FIFO, LIFO. Пакетная обработка – когда количество транзакций – конечное число. Напр., очередь накопилась до определенного числа – и она поступает на обработку. Пакет – очередь, состоящая из определенного конечного числа транзакций. Случайное обслуживание – осуществляется случайным образом (обычно на основе вероятностной величины). Очередь по приоритету. Каждая транзакция имеет свой приоритет, определяемый по определенному правилу. Бывает одноприоритетная очередь. Очередь по приоритету – это когда имеется одна очередь, а внутри этой очереди имеются несколько очередей. Множественная обработка – это когда множество очередей, и имеется свое правило, какую очередь выбрать (на курском вокзале я покупаю билет в той кассе, где народу меньше, а в кассах аэрофлота я стою только в той очереди, где продается билет на нужный мне рейс).

Как тестировать очереди.

Несколько общих рекомендаций, которые дает Бейзер в тестировании черного ящика: Тестирование пределов длины очереди. Т.е. пробуем превысить максимально заданное количество. Тестирование пустой очереди. Активация обработки, когда в очереди нет ничего. Проверка циклов. Очередь образуется, возможно, в каком-то цикле. Тогда нужно протестировать этот цикл по правилам тестирования циклов (см.предыдущую лекцию). Динамическое изменение длины очереди. Тестирование сортировки и выбора. В FIFO и LIFO идет либо прямая либо обратная сортировка соответственно. Поэтому здесь следует тестировать правильность сортировки, чтобы очередь работала как надо. Если идет сортировка на основе ключа, тогда надо еще просмотреть, как пройдет сортировка в случае повторяющихся ключей. Тестирование очереди с множественными приоритетами. Тестируют каждую очередь, а затем более высокий уровень приоритетов – между очередями (см. пример с аэрофлотом выше). Тестирование потоков данных.

Романова Т.Н. – Технология программирования [2011] by Melvin Страница 50

Построим граф потока данных (граф потока данных). На основе этого графа тестируем. 1 DEF(i) =

b 2 a множество определений данных

USE(i)= 3 Множество использований данных

4 DU-цепочка [x,I,j]

DU-цепочки:*a,1,4+, *b,1,3+, *b,1,6+, *c,4,6+. 5

6 Шаги способа DU-тестирования.

1. Построение управляющего графа программы. 2. Построение информационного графа программы. 3. Формируем DU-цепочки и записываем все переменные. 4. Построение маршрутов, которые следует протестировать. 5. Подготовка тестов. Достоинства метода: 1. простота формирования DU-цепочек. 2. Простота автоматизации. Граф строится автоматически. Недостаток метода: 1. Трудно определить оптимальное число независимых путей. Дело в том, что число независимых путей тяжело определить.

Романова Т.Н. – Технология программирования [2011] by Melvin Страница 51

Hard skills для входа в тестирование бэка

Привет, Хабр! Меня зовут Ольга Кузнецова, я QA Lead, более 7-ми лет работаю в ИТ-сфере в различных должностях и сегодня хочу поговорить о минимальных необходимых hard skills для тестирования бэкенда.

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

Информация изложена “от общего к частному”, и в каждом разделе рассказано про минимально-достаточные знания. В самом начале речь пойдёт про навыки, которые необходимы любому тестировщику, в том числе, и бэкэндеру, так как я считаю это неотъемлемой частью. После перейдём к более узко-направленным вещам.

0.0 Базовая база

Совершенно ни для кого не секрет тот факт, что надежный фундамент в любой области — это важно. Именно по этой причине так много внимания уделяется, на первый взгляд, простым вещам и важность этих знаний я вынесла отдельно. Корректное изучение более сложных вещей невозможно без глубокого понимания азов. Игнорирование этого момента негативно сказывается на всём процессе тестирования и приводит к его замедлению, усложнению и увеличению количества ошибок в продакшене. Более того, это первый этап большинства собеседований независимо от специализации в QA.

0.1 Терминология

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

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

0.2 Артефакты тестирования

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

0.3 Техники тест-дизайна

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

0.4 Паттерны

Достаточно спорным моментом являются паттерны, поскольку не каждый ручной тестировщик будет писать автотесты. Один мой коллега когда-то сказал: “Всё давно изобретено до нас и для нас”. Паттерны — это просто опыт других людей, сформулированный в набор правил, который поможет упростить вашу жизнь. Учиться лучше на чужих ошибках и обязательным минимумом в данном случае будут page object и page factory.

На этом заканчивается блок обязательных базовых вещей в моём списке. Переходим непосредственно к знаниям и навыкам для работы с бэкэндом.

1. Операционная система

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

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

Любимый вопрос на собеседовании: “Что делает команда chmod 666”?

2. Клиент-серверная архитектура

Знания, которые требуются на подкорке, и их невозможно переоценить. Выстраивание процесса тестирования, написания стратегии, создания тест-кейсов, локализации появляющихся проблем — всё это при отсутствии знаний архитектуры будет сопровождаться проблемами различной сложности. Более того, они всегда будут стрелять в самых неожиданных и непредсказуемых местах и спрогнозировать их невозможно!

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

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

3. Протоколы передачи данных

Помимо самого простого и известного протокола IP, существует ещё ряд других, работающих на различных уровнях. Они отличаются по функционалу, у каждого из них есть свои плюсы и минусы при использовании для решения определенных прикладных задач. Фактически, в большинстве своём на различных проектах требуется глубокое знание только одного из упомянутых протоколов, а про остальные достаточно знать на уровне “об их существовании”. Так какой же из них нам нужен более подробно?

Обязательный минимум: конечно HTTP! Здесь прежде всего стоит обратить внимание на основные методы: GET, POST, PUT, PATCH, DELETE. Это самые часто используемые из большого количества существующих. И второй важный пункт — нужно разобраться с категориями кодов ответов и запомнить основные из них. В идеале, почитать отличие http от https.

4. REST-архитектурный стиль

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

Обязательный минимум: понимание REST-архитектуры и, в большинстве своём, знание JSON как самого распространенного на данный момент формата по обмену данными. Здорово, если для общего развития вы будете знать о том, что такое GraphQL.

4. Инструменты

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

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

6. Базы данных

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

Обязательный минимум: умение делать выборки из используемой базы данных для проверки имеющихся записей и работать с этими данными, сортируя их, группируя и другими различными образами создавая необходимую проверку. Здорово, если вы будете знать JOIN синтаксис и уметь применять (это, наверняка, вам понадобится во время собеседования!!). Однако, чаще всего обычного SELECT для работы будет достаточно.

7. Очереди

При тестировании бэк-энда у нас может скапливаться очередь из ещё не отправленных сообщений. Очередь может быть организована двумя разными способами: FIFO и LIFO. Выбор способа зависит от необходимости, архитектуры, проекта, аналитики и запросов бизнеса, что для нас, как для инженеров, не несет особых сложностей. В любом случае процесс работы с очередями достаточно общий, и тестирование сводится к проверке наличия в очереди сообщения и соответствия его контракта аналитике, а содержимого — к сценарию тестирования. Инструментов для работы существует множество, но в большинстве случаев используется Kafka.

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

8. Логирование

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

Обязательный минимум: ориентироваться в уровнях логирования для корректной оценки различных состояний системы. В каждом из используемых инструментов есть способ фильтрации. Необходимо уметь работать как минимум с одним из них: от grep в командной строке до KQL в кибане.

9. Автоматизация

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

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

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

Если у вас есть какие-то замечания или предложения — буду рада их обсудить.

  • тестирование
  • backend
  • начало карьеры
  • Блог компании Innovative People
  • Тестирование IT-систем
  • Учебный процесс в IT
  • Карьера в IT-индустрии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *