Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Тестирование уникальности счетчиков от задвоения


(Михаил Братухин) #1

Добрый день, коллеги!

Есть вопрос по данной теме. Уже пару раз наталкивались на проблему задвоения номеров операций в пром. эксплуатации, но при ручной и полуавтоматической попытке воспроизвести ситуацию в прошлый раз ничего такого не выявилось, счетчики менялись и оставались уникальными. Есть идеи как можно было бы тестировать операции (через сервисы) на предмет уникальности создаваемых ордеров? А то как-то оно не очень пока понятно как это дело проверять и воспроизводить, а тем более “автоматизировать” данные проверки.


(Sergey Korol) #2

Лично я не совсем понял, о каких счетчиках речь… Более осязаемый пример можно?


(Михаил Братухин) #3

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

Вот и вопрос как бы можно было такие штуки вылавливать.


(YobiByte) #4

Насколько я понял, тут всё проще пареной репы, если система состоит из “веб-морды”, на которую “накидываются” запросы (может быть и в несколько потоков), сервера, на котором идёт обработка, и БД (или систем БД). Ну и хочется отличать ВСЕ запросы при работе скриптов по номерам
:smile:

У меня подобное было и решено было мной общением с девелопером, чтобы в коде страницы появилась “бесполезное” поле с ID “cotd”, что, в переводе, значило “count of the day”.

Он, имея доступ к коду и БД, сделал дополнительное поле с тем же названием, которое увеличивало своё значение на единицу на каждый запрос, с обнулением счётчика в 23:59:59.
Итого, все рабочие сутки мы имели свой уникальный номер для каждого запроса в любом из роботов.

Например: мы прогоняем скрипты в 12:00, соседний отдел прогоняет их (для своих целей) в 12:03. Тесты идут по полчаса. Но ни у нас, ни у них нет одинаковых цифр номеров запросов на страницах, которые скрипты читают и пишут в логи прогона. У них в логах свои номера, у нас - свои.

пысы: по-моему, это - решение. Если же тут не та система, прошу подробнее описать и тогда найдём новое решение
:wink:


#5

По-моему, этот вопрос должен решаться разработчиком путем блокировки значения на время транзакции (orm это должно делать ) . Чтобы это потестировать, можно взять jmeter, выбрать элемент http://jmeter.apache.org/usermanual/component_reference.html#Synchronizing_Timer, который отправляет несколько реквестов одновременно, поставить туда 5- 10 реквестов и подергать сервис таким образом.


(Sergey Korol) #6

Сервис возвращает id операции в ответе? Если да, то мне видится следующий сценарий:

  • В качестве прекондишена достаем список уже существующих id из БД и помещаем в глобальное хранилище, поддерживающее concurrent read / write.
  • Берем какой-нибудь вменяемый тестовый фреймворк и скейлим любой сценарий, предполагающий журналирование операций.
  • Читаем ответ от сервиса и проверяем, существует ли уже такой id в списке. Если нет, помещаем его в хранилище. В противном случае - фейлим тест.

Тут еще важно где-нибудь логировать ваши операции и ответы с id, чтобы можно было легко понять, какой end-point сфилонил.

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

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

Кстати, еще интересно, а поле id у вас БД какое? Автоинкремент по записи, или какой-то сервис отвечает за генерацию уникального id? Просто пытаюсь понять, на каком уровне может возникать проблема.


(Михаил Братухин) #7

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


(YobiByte) #8

Отличный вариант. Только надо озвучить и получить утверждение от девелопера о том (или если есть доступ, посмотреть самим), что каждый id ОБЯЗАН быть уникальным. Если же там три цифры рандомайзом - недалеко до того, что зафейлим нормальный тест.