Публикации
Мужчина
Привет! Приму эстафету рассказов о нагрузочном тестировании в Яндексе.
Андрей, такой ещё вопрос по организации процесса
Ситуация: разрабатывается сервис (приложение, сайт, ... ). Пехота прошлась по функционалу, можно теперь и по нагрузке продавить :)
У вас есть результаты тестов, допустим (не приведи Господь конечно), что всё плохо именно с точки зрения перформанса, сколько у вас времени на сообщение результатов?
Да, как-то мутнова-то получилось, пример:
Релиз нового функционала через две недели (итерация), доработали фичу и прошлись по функционалу тестировщиками ().
Отдали танкистам, через полторы недели.. у вас есть три дня на проведение тестов, анализ результатов и отправке "совета".. Если всё плохо, но об этом узнают за день до релиза, чего происходит?
Раньше стрелять нельзя, ибо не во что (пишется пока что), далее стрелять нельзя ибо тестируется (функциональные баги там и всё такое).. сколько времени на нагрузку отводится и что бывает , когда (не приведи Господь конечно) всё плохо?
Или у вас процессы ваще по-другому построены? Может нет определённого времени, к которому нужно выпустить новый сервис (функционал, приложение и др.).. или всё же умудряетесь стрелять с коленок, пока ещё мишень только пишется... ммм?
Итак, как устроен процесс.
Если речь идет о новом проекте, то мы можем начать исследования (либо выдать уже имеющиеся данные) компонентов сервиса, например стораджа, прокси, шаблонизатора, без интерграции в проект. Либо выделить разработчику лоад-генератор для отладки своего кода с точки зрения перфоманса, дабы не пришлось переписывать заново. Непроизводительные куски выявляются сразу, это экономит время танкистам и всему проекту.
После того как сервис готов пройти приемочное тестирование, разработчик на отладочных стрельбах не обнаружил каких-либо проблем, мы раскатываем проект в тестинге, определяемся с требованиями и проводим тесты. Обычно проблемы вылазят после первых стрельб, наша задача показать, где именно проблема. Разработчик уходит оптимизировать код, если нужно мы помогаем в исследовании узких мест и отладке.
Что касается нехватки времени. Мы даем информацию о качестве продукта, выкатить его в продакшен или нет, это дело менеджера. Он берет на себя все риски. Если времени нехватает, мы можем порекомендовать менеджеру выключить критичные фичи в продукте, которые нагрузку заведомо не держат, либо подготовить failover-механизмы для минимизации факапа.
Док, спасибо! :) Со всем согласен.
Тесты производительности по большому вскрывают или проблемы в архитектуре, или проблемы с кодом разной сложности, или в конфигурации среды. Первые надо вскрывать как можно раньше. Ровно для этого и привлечение специалистов по тестированию производительности на этапе проектирования более чем оправдано. Вторые — на этапе разработки (здесь правда и сам разработчик может отлаживаться и профилироваться автономно). Третьи — на этапе подготовки к эксплуатации. В таком случае все ключевые проблемы можно решать в тот же момент, когда они возникают. И тогда перед запуском обычно достаточно просто приемочного тестирования.
