Сервис продажи билетов на хоккейные и футбольные матчи региональных клубов получил нагрузочное тестирование перед стартами продаж и набор автоматических проверок перед каждым релизом. Работу сделал Евгений Росляков: сайтами и их проверкой он занимается с 2016 года, работает самозанятым по договору, юрлицам выдаёт закрывающие документы, берёт заказы в Москве и удалённо.
Сервис написан на PHP. Билеты на обычные матчи расходятся спокойно, а старт продаж на важную игру превращался в проблему. Болельщики открывают сайт в одну минуту и выбирают места, и в какой-то момент всё падало: схема зала зависала, оплата не проходила, места застревали в брони, которую никто не оплатил.
Разработчики клиента срочно чинили и выпускали исправление. После спешных правок ломалось что-то другое: то неверно считалась скидка, то не работал возврат, то личный кабинет открывался пустым. Следующего старта продаж ждали с тревогой.
Нужно было понять, где система не выдерживает, исправить слабые места вместе с разработчиками и проверять каждый релиз до выхода к болельщикам, а не после.
Отдельного тестировщика у клиента не было. Релизы проверял сам разработчик, как успевал, и обычно только основной путь покупки.
Сразу договорились: проверяем только тестовую среду клиента, а не рабочий сайт во время продаж.
Тестирование производительности ПО начал с логов прошлых стартов продаж. По ним собрал профиль нагрузки: как быстро нарастает поток, сколько людей одновременно смотрят схему зала, сколько доходит до оплаты. По этому профилю построил сценарий «выбор места, бронь, оплата» и гонял его на копии сервиса.
Узких мест нашлось три. Блокировки мест в базе мешали друг другу, когда много людей выбирали соседние кресла. Схема зала каждый раз собиралась заново, а не бралась из кеша. Очередь платёжных операций копилась и не успевала разбираться. Исправляли разработчики клиента, а я после каждой правки повторял прогон и показывал, стало ли лучше. Отчёт для них описывает сценарии, найденные причины и порядок повторной проверки.
Регрессионное тестирование настроил для того, чтобы срочные правки не ломали соседнее. Расчёт цен, скидок и блокировку мест покрыл юнит-тестами на PHPUnit: там ошибки обходятся дороже всего. Пути в браузере записал на Selenium: покупка билета, возврат, вход в личный кабинет. Всё запускается перед каждым релизом.
Отдельно проверил обмен данными с мобильным приложением и кассами стадиона. Тестирование API шло запросами с разными данными, в том числе ошибочными: занятое место, повторная оплата, обрыв связи посреди покупки.
Перед стартом продаж у клиента теперь есть карта слабых мест, и видна она на тестовой среде, а не на болельщиках. Схема зала открывается стабильнее, а места не зависают в брони без оплаты: блокировки переписаны, очередь платежей разбирается вовремя.
Главная перемена в процессе: релиз не уходит без проверки. Юнит-тесты за несколько минут показывают, не сломан ли расчёт цен или скидок, а браузерные сценарии проходят покупку и возврат так же, как это делает болельщик. Срочная правка больше не превращается в новую поломку, потому что её ловят до выхода.
Кассам стадиона и мобильному приложению проверка API тоже принесла спокойствие: на ошибочный запрос приходит понятный ответ, а не зависание.
Без оговорок не обойтись. Тестовая среда мельче рабочей, поэтому нагрузку я оцениваю по профилю и по поведению узких мест, а не по абсолютным значениям. Перед самыми крупными матчами прогон лучше повторять, а браузерные сценарии придётся обновлять вместе с интерфейсом. Вести это клиент может сам: сценарии записаны так, что их способен править обычный разработчик.
Если ваш сайт падает на пике, а после срочных правок ломается что-то ещё, напишите мне на freelance.ru: что происходит и когда ждёте поток людей. Обсудим, что проверять в первую очередь.
