Тестирование сложных систем
Я уже рассказывал, что плотно сижу на проекте «Умный трекинг» — это ключевой проект b2b-направления Додо Пиццы. Мы все помним, что он не умный и не трекинг (мы начинаем задумываться о ребрендинге), но это уже мало кого смущает и для простоты буду называть его УТ. Контекст, что такое УТ, вот тут.

Решил рассказать, как мы тестируем его. Поэтому ждите в ближайшее время посты про тестирование УТ.

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

Как работает группировка
Автотестов, которые проверяют бизнес-требования группировки, не было. И вот тут начиналось ручное тестирование. Базово УТ работал так - мы каждые 30 секунд запускаем итерацию УТ, плюс эти итерации запускаются при различных триггерах, например когда заказ упаковали или когда появился новый курьер. На то, как будет сформирована группа влияет что-то в районе 10 показателей, которые меняются прям на ходу. Прошло 1, 2, 5 минут, группы уже будут другими. Появился или исчез курьер - группы будут другими. Появился новый заказ - думаю вы поняли логику. Все эти показатели основываются на штрафах и бонусах. Задача группировщика найти такой вариант группировки, где суммарный штраф минимален (это очень упрощенное объяснение). Внимание вопрос, как я, ручной тестировщик, создавший на тестовом стенде 5-10 заказов, могу посчитать штрафы всех заказов по всем показателям (учитывая что есть штрафы которые меняются каждую минуту)? Сам пересчет и запрос к группировщику запускается каждые 30 секунд. Это невозможно.
Для понимания масштаба проблемы предлагаю вам прочитать недавнюю статью на хабре про алгоритмы в лифтах (просили кого-то на собесе протестировать лифт?). Вот у нас примерно тоже самое, только подвижных частей - больше.

Как мы тестировали требования
Мы проверяли основные требования. Что соседние заказы должны объединяться, заказы в разные стороны не должны группироваться, принятые заказы не должны группироваться с готовыми и т.д. Но даже тут были проблемы — заказы, по которым должны быть выданы сертификаты на пиццу. Чтобы заказ был близок к сертификату (чем ближе тем больше штраф), тебе либо нужно идти в БД сервиса и руками менять время принятия заказа, чтобы система посчитала его просроченным или близким к просрочке (но тогда данные могут разъехаться, если забыть поменять значение в какой-то другой таблице или базе), или сидеть ждать почти час, пока заказ просрочится. Ну и конечно же в таком режиме мы не могли не пропускать баги. Например, был прикол — решили реализовать требование не группировать заказы, угол между которыми больше 120 градусов (в основании угла пиццерия). Создали заказы, посмотрели, что пары заказов с таким углом не группируются. Я специально выделил слово «пары», потому что на проде тройки заказов группировались и на 180 градусов. Между 1-м и 2-м заказом 70°, между 2-м и 3-м — 90°. А между 1-м и 3-м — 160°. Ну и ещё заодно проверяли, что техническая интеграция всех систем прошла успешно.

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

В следующем посте расскажу как мы это дело автоматизировали и что из этого вышло.