Комментарии 17
А сколько у вас времени занимает один цикл регрессионного тестирования?
Сейчас это время 15-20 мин. Стараемся группировать тесты так, что бы длительность прохождения у всех групп была одинаковая.
ну если запуск теста занимает минуты, то ты не будешь их запускать каждый раз, а сперва подумаешь, надо ли запускать. как результат, не будешь писать сперва тесты, а потом код. а скорее напишешь код и потом будешь его тестировать.
для сравнения в одной из компаний у нас была скорость 300-500 тестов/сек. Кол-во тестов было на тот момент где то 10-15k. и вот в таком случае даже лень фильтровать тесты, тупо запускаешь все
Это всё на C++? Молодцы! Интуитивно, я бы уложился в на порядок меньшее количество тестов (написал бы всё на распределенных конечных автоматах, они быстро работают и легко тестировать) и до кучи бы записал день из реальной жизни и перематывал бы его с ускорением 5x. А как у вас как всё сделано (если не секрет)? FIX Gateway сами написали или QuickFIX присобачили?
Очень подробно и интересно, спасибо!
Вопрос насчет фреймворка-коннектора - так как у него есть набор кодеков для сериализации\десериализации сообщений от гейтов, то возникает проблема обновления кодека, если в соответствующем гейте изменился формат сообщения (если предположить, что нужно изменение в двух репо - самого гейта и фреймворка-коннектора). Как вы подошли к решению данной проблемы?
Хороший вопрос.
Когда строили тестовый проект, фреймворк-коннектор со своими кодеками жил в отдельной репе. И действительно была боль следить и синхронизировать репы. В конечном итоге терпение кончилось и репы объединили. Теперь, когда меняется формат сообщения, кодек сразу на это ругается и программист ядра или QA самостоятельно тюнят кодеки под новые требования.
В конечном итоге терпение кончилось и репы объединили.
А какие именно репы объединили? Судя по схеме, фреймфорк-коннектор взаимодействует с несколькими гейтами совершенно разных типов. Получается, что у вас и все эти гейты, и фреймворк лежат теперь в одной репе?
100K TPS, 0.5мс latency - серьёзные цифры, внушает! Какого примерно размера одна транзакция? TCP дампы нагрузочного тестирования должны получаться неслабых объемов...
Доброго времени суток!
Отвечу по порядку:
1. Пока идет разработка (ядра и тестов) в фиче-ветке никто не запрещает запустить точечно или полный набор тестов для самоконтроля. Но когда работа завершена и готова вливаться в мастер, все тесты должны быть успешно пройдены. Набор тестов один. Как правило разработчик или QA знают в какая из групп тестов наиболее уязвима/интересна при разработки новой фичи. При первичной отладки ребята запускают именно эти группы. Каждая группа тестов выполняется 15-20 мин.
2. На одном независимом тестовом окружении поднимается вся система (30 с лишнем компонентов), далее на нем выполняется одна группа тестов.
При одновременном мерже нескольких разработчиков, пайплайны встают в очередь. Как только ВМ освобождается, она передается следующему мержу.
3. Почти все тесты генерят тестовые данные для себя через внешние точки доступа к системе (то что доступно клиентам). Но есть группы тестов которые дополнительно для себя подготавливают тестовое окружение через: внутренние протоколы / запросы в БД / подкладка специальных снапшотов. Это отдельные группы тестов, они как и все остальные, выполняется изолировано на ВМ. Как правило данный тип тестов проверяет очень специфические use-кейсы.
Насколько такое мощное тестирование с почти полным покрытием позволяет избежать багов на проде? Может у вас есть какая-то статистика по количеству багов на протяжении развития тестов и увеличения покрытия?
Здравствуйте!
Ядро - это часть системы и другие компоненты переиспользуют его, что в свою очередь добавляет еще как минимум одно звено, отделяющее ядро от конечного пользователя. В связи с этим появляются интеграционные вопросы. Но если говорить конкретно за баги, которые отношение к ядру, то с каждым годом их количество заметно сокращается, если грубо оценивать в 2-3 раза.
Тестирование финтех бэкенда: как мы дошли до 20 тыс. тест-кейсов