Для чего нагрузочное тестирование
Нагрузочное тестирование: что в нем интересного и какие навыки нужны?
Попросили рассказать о перспективах и задачах в сфере тестирования производительности Василия Кудрявцева, директора по качеству АО РТЛабс и руководителя нашего курса «Нагрузочное тестирование».
Самая актуальная на сегодня область в QA
Последние месяцы из-за сложившейся ситуации с пандемией все больше продуктов и сервисов переходят в онлайн, а уже существующие — быстрыми темпами расширяют свою аудиторию. Трафик и нагрузка возрастают, а вместе с тем и актуальность нагрузочного тестирования (НТ).
Даже начинающих специалистов, но с необходимым набором скиллов, хантят в течение нескольких недель. Причем выбор проектов огромен: банкинг, маркеты, доставка, образование и стриминговые сервисы, всевозможный онлайн-досуг и т.д.
Можно рассчитывать на зарплату на 30-50% выше, чем по другим направлениям тестирования.
Каждый проект в нагрузочном тестировании уникален
Проекты здесь действительно разнообразные. Это могут быть короткие и быстрые, когда за одну ночь ты успеваешь написать скрипты, подготовить сценарии и протестировать высоконагруженный сервис. А бывают длительные и крупные проекты, когда надо протестировать большую распределенную систему.
В моей практике самым интересным был проект одного известного Банка, когда мы объединяли централизованную сеть территориальных Банков, работали с огромными кластерами железа, которые представляли собой тысячи серверов. И действительно было интересно и приятно смотреть, когда долгое время готовишь скрипты и сценарии, а затем получаешь результат, который важен и нужен команде. Ну и в целом интересно поработать с большими железками.
Василий Кудрявцев
QA Load — самая разнообразная область, где специалисту надо не только заниматься кодом, но и всесторонне развиваться.
Но все же одних технических скиллов мало. Работодатели ищут тех, кто обладает в целом техническими основами, понимает, как правильно строить процессы, умеет рассказывать, показывать и готовить правильную отчетность.
Как стать нагрузочным тестировщиком?
У этого направления свои инструменты и сценарии, но что более важно, тут еще отличается сам подход. И если в целом в авто-тестировании в основном кодишь, в нагрузочном тестировании потребуется открыть для себя сразу много нового.
Курс «QA Load» мы собрали из крупиц материалов, объединив свой опыт решения задач для различных компаний. 70% программы содержит практику — и именно это отличает ее от остальных учебных проектов. У нас нет поверхностных тем, каждая изучается вглубь, с разбором кейсов и возможностью попробовать инструмент, потренировать навык.
Например, в нашем первом вводном модуле даже опытные нагрузочные тестировщики наверняка возьмут на вооружение пару фич, которые раньше не использовали в работе. Вы узнаете, для чего нужна «нагрузка», из каких этапов она состоит. Получите демонстрацию и практику подготовки профиля нагрузочного тестирования, который является одной из важных частей подготовки к проекту. Подробно разберете, для чего нужна методика и что такое отчетность. Выясните, каких типов бывают отчетности и что важно обсуждать со своей командой.
Во втором модуле вы изучите 4 основных инструмента нагрузочного тестирования: Performance center, Jmeter, Gatling, k6.io. Хотя их на рынке несколько больше, мы после опросов выделили используемые повсеместно и этого набора должно хватить, чтобы решить 90% «нагрузки». Чтобы эти инструменты сразу можно было встраивать в DevOps-процессы, есть отдельный урок про автоматизацию нагрузочного тестирования с помощью Jenkins, встраивание с помощью CI/CD. Также отдельно расскажем про Grafana и InfluxDB, чтобы соединить эту часть мониторинга с вашими тестами.
Третий блок курса посвящен сопутствующим задачам по нагрузке, где вы научитесь разрабатывать базовые заглушки и эмуляторы, погрузитесь в устройство баз данных, серверов приложений и очередей. Все это составляет значимую часть работы специалиста по нагрузочному тестированию. Последний в модуле урок наиболее полезен опытным специалистам. Тут мы будем оценивать свой процесс нагрузочного тестирования с точки зрения качества и разберем, что такое регрессионное нагрузочное тестирование именно для релизов в ваших продуктовых командах.
В течение обучения вас ждет интенсивная работа и 8 домашних заданий: закрепить пройденный материал, попробовать каждый инструмент, написать скрипты, провести тестирование и т.д. Будут задачи на разработку профиля НТ, настройку логирования и проведения регрессионного тестирования для веб-сайта. Для тех, кто хочет получить еще больше навыков и пользы, в заданиях есть пункты со звездочкой. Тренироваться вы будете на реальных системах, серверах, сайтах. Стенды для отработки предоставит партнер курса AdvancedHosting.
Завершающая часть программы — проектная работа, которую можно выполнить для своей рабочей или нашей учебной системы. Вы пройдете полный цикл тестирования и примените все навыки, полученные в процессе обучения. Если у вас нет своего проекта, мы подберем индивидуальный сервис, поэтому не будет двух одинаковых работ. Каждый студент сможет увидеть, какие проблемы встретились его сокурсникам, сможет перенять их опыт и решения.
Выполнение домашек и проекта дадут достаточно опыта, чтобы после курса претендовать на должность самостоятельного специалиста по нагрузочному тестированию.
У нас уже было такое, что без рекомендации одному из студентов первого запуска еще до конца обучения сделали оффер. Многие меняют работу до завершения курса, т.к. спрос на нагрузочников очень высок.
Василий Кудрявцев
Кому нужны навыки нагрузочного тестирования?
Наш курс рассчитан на уже разбирающихся в тестировании специалистов. Чтобы успешно осваивать программу нужно обладать базой программирования на одном из языков — в ходе обучения вы столкнетесь с SQL, Java, C, Scala, также предстоит много работы в Linux, поэтому понадобится знать базовые вещи: как подключиться к консоли, найти файл и т.д.
Функциональным тестировщикам и автоматизаторам хватит небольшого опыта программирования и базовых познаний, что позволит реализовать себя в самой интересной области тестирования.
Специалисты, которые уже занимаются нагрузочным тестированием, смогут систематизировать знания, почерпнуть для себя что-то новое, изучить новый инструмент, либо понять, что сейчас не учитывается в их текущих процессах по нагрузочному тестированию.
Курс также будет полезен разработчикам и специалистам тех. поддержки и ПО. Тем, кто работает в продуктовой команде и понимает, что текущие сервисы достигают таких нагрузок, которые стоит проверять. Или в случае, когда проект испытывает проблемы с производительностью своих систем, и есть цель действительно правильно выстроить процессы НТ. Полученные знания позволят разработать комплекс средств нагрузочного тестирования и на регулярной основе следить, чтобы с системами было все хорошо.
В новом потоке «QA Load» занятия начнутся 29 октября и будут длиться 4 месяца. Если направление вас заинтересовало, проходите вступительный тест и записывайтесь в группу, пока есть места. Ждем вас и до встречи в OTUS!
Нагрузочное тестирование: особенности профессии
Авторизуйтесь
Нагрузочное тестирование: особенности профессии
руководитель нагрузочного тестирования в компании Bell Integrator
В этой статье я расскажу про нагрузочное тестирование. Сейчас в России эта специальность стала уже не столь экзотической, как лет 15-20 назад. Но все равно, даже когда доводится собеседовать выпускников ведущих вузов страны (МГУ, МГТУ, МАИ, МИРЭА), редко можно услышать внятный ответ на вопрос «Что такое нагрузочное тестирование?». Студенты знают, что есть программисты, аналитики, в лучшем случае – слышали про существование тестировщиков. И к роли последних отношение весьма скептическое: дескать, низкоквалифицированная работа для неудачников. А о том, что есть вид тестирования, более требовательный к техническому кругозору специалиста, чем в разработке, почти никто не догадывается. Попробуем исправить эту несправедливость.
Что такое тестирование и его место в процессе разработки ПО
Сначала несколько слов о тестировании вообще.
Сегодня вряд ли найдется столь смелый руководитель проекта или заказчик, который не озаботится организацией тестирования разрабатываемого продукта. И чем более зрелый процесс разработки, тем больше внимания уделяется тестированию. И ведь это лишь один из инструментов обеспечения качества! А в него входят и аудиты, и выстраивание процессов разработки… Но это уже отдельная тема, на которую написана не одна книга.
Если кратко сказать, что же такое тестирование, то это проверка продукта на соответствие требованиям. В идеальном упрощенном случае заказчик с помощью бизнес-аналитиков формулирует требования, системные аналитики вместе с архитекторами переформулируют их в технические задания, разработчики пишут код, а тестировщики проверяют, соответствует ли то, что написано, требованиям.
Интуитивно понятно, что требования могут быть совершенно различными, а значит, будут отличаться важность и трудоемкость их проверки. Например, одно дело проверить требование «В правом верхнем углу экрана должна быть кнопка с крестиком, при нажатии на которую приложение закрывается» или «Фон главного экрана программы должен быть розового цвета», и совсем другое дело проверить требование «Система должна обслуживать 10 000 одновременно работающих пользователей и время реакции системы на их действия не должно превышать 3 секунды».
Отличие нагрузочного от других видов тестирования
Как требования отличаются друг от друга, так и виды тестирования, необходимые для их проверки, будут отличаться по приоритету, объему работ и квалификации выполняющего их персонала.
Для примера рассмотрим три наиболее распространенных вида тестирования: функциональное (ФТ), автоматизированное функциональное (АФТ) и нагрузочное (НТ).
Ручное функциональное тестирование (ФТ) – бесспорно, основной вид, и без него не обходится практически ни один проект разработки программного обеспечения. С него, как правило, начинается проверка новой системы, и уже потом наступает время АФТ и НТ. Основные навыки специалистов по ФТ – умение разобраться в документации и функциональности тестируемого продукта, составление и выполнение тестовых сценариев. Порог вхождения в такую специальность достаточно низкий: не требуется навыков программирования или опыта работы в ИT, достаточно уверенного пользования компьютером, пытливого ума и аккуратности. Среди людей, пришедших в ручное тестирование, я лично встречал не только выпускников технических вузов, но и бывших операционистов банка, учителей начальных классов и даже фельдшеров. Именно поэтому появился миф, что ФТ – это низкоквалифицированная работа для неудачников. А ведь опытный тестировщик совмещает в себе навыки и аналитика, и менеджера, и разработчика. И работать ему приходится со множеством инструментов разработки, тестирования, администрирования, багтреккинга и даже писать код на SQL или Python.
Автотестирование (АФТ) – работа на стыке разработки и тестирования. Специалисты АФТ автоматизируют рутинные или объемные проверки функционального тестирования. Они не только обладают основными навыками ФТ, но и пишут много кода на различных языках (Java, C#, Python, Scala…). Этим тестировщикам не требуется настолько широко охватывать функциональность продукта, как в ФТ, но зато каждый из них достаточно глубоко погружается в логику работы и реализацию того фрагмента, тестирование которого он автоматизирует. В каком-то смысле работников АФТ можно назвать «программистами в тестировании», и порог вхождения в профессию достаточно высок. К базовым навыкам можно отнести опыт объектно-ориентированного программирования (ООП) и уверенное владение SQL. А через несколько лет работы специалист АФТ осваивает несколько языков программирования, специальные инструменты автоматизации, фреймворки и уверенно интегрирует свой код в процесс разработки, обладая навыками CI/CD и DevOps.
Нагрузочное тестирование (НТ) стоит особняком. Оно позволяет проверить такие нефункциональные требования к системе, как производительность, стабильность, масштабируемость, стрессо- и отказоустойчивость. На первый взгляд, в нем немного меньше глубина погружения в функционал и реализацию тестируемой системы, и в этом смысле НТ находится между ФТ и АФТ. Но при более детальном рассмотрении оказывается, что специалист по НТ совмещает в себе навыки нескольких профессий. Во-первых, он должен быть немного архитектором, чтобы разобраться в устройстве продукта, понять его связи с другими системами и определить источники нагрузки. Во-вторых, ему часто приходится выполнять роль аналитика, чтобы разобраться со специфическими нефункциональными требованиями к системе и составить модель тестирования. В-третьих, от него требуются навыки администрирования: серверов и баз данных до операционных систем и инструментов мониторинга. В-четвертых, специалист НТ должен уметь программировать. Причем набор языков может быть самым разным: от С и Python до Java и Scala. Это обуславливается используемыми инструментами НТ и стеком технологий тестируемой системы. Приходится писать как собственно скрипты, моделирующие нагрузку, так и эмуляторы смежных систем («заглушки»), разного рода генераторы тестовых данных и парсеры. Но, в первую очередь, специалист по НТ должен быть тестировщиком, то есть мыслить категориями проверки системы на соответствие требованиям. Явно указанным или соответствующим здравому смыслу. По объему задачи НТ условно можно поделить на три равные части:
Таким образом, от специалиста по НТ требуются довольно противоречивые навыки: он должен быть аккуратен и внимателен, чтобы разбираться с технической документацией; усидчив, чтобы разбирать по логам и графикам причины проблем производительности; уметь неплохо программировать и при этом иметь широкий кругозор по ИT-технологиям. В области НТ, в отличие от ФТ и АФТ, очень большой разброс по квалификации специалистов, а значит и много возможностей для профессионального роста. При среднем пороге вхождения (требуются опыт программирования на любом языке, знание SQL и общее понимание сетевых технологий, которые даются в технических ВУЗах) за 2-3 года работы с различными системами специалист по НТ осваивает несколько языков программирования на уровне написания скриптов и «заглушек», погружается в устройство БД и особенности различных архитектурных решений от монолитов до микросервисов, осваивает различные инструменты НТ и мониторинга, повышает уровень владение SQL. Все это дает множество направлений для развития технических навыков.
При всех перечисленных различиях между типами тестирования у этих видов деятельности есть общие особенности: все они проверяют тестируемую систему на соответствие требованиям. Отличаются только цели и процесс.
Цели и процессы нагрузочного тестирования
Как и в любом тестировании, цели и процесс НТ вытекают из требований к тестируемой системе и зависят от организации разработки.
Для достижения каждой цели НТ нужно провести один или несколько тестов, при этом каждый из них может выполняться от нескольких минут до нескольких суток (например, тест проверки стабильности). Перед каждым тестом производится подготовка тестового стенда к нагрузке, а после выполняется анализ собранной информации (графики, таблицы, логи), делается заключение о том, успешно ли прошел тест, удовлетворяет ли система заявленным требованиям. Все это – «вершина айсберга» работ по НТ, а сам процесс может занимать от нескольких недель, до нескольких месяцев.
Различные варианты процессов НТ можно условно свести к двум:
В зависимости от варианта процесса меняется организация работ и взаимодействие в команде, формат документации, но при этом основные этапы сохраняются:
И на каждом из перечисленных этапов требуются те или иные навыки специалиста по НТ.
Основные навыки специалистов по нагрузочному тестированию
Как уже было сказано выше, работа в НТ требует разностороннего развития. Ниже приведу «джентельменский» набор навыков для уровня «middle+», т.е. среднего самостоятельного специалиста, способного в одиночку вести не слишком сложный проект НТ:
Конечно, не все эти навыки приобретаются сразу, и это далеко не полный их перечень. Но он позволяет понять, в каких направлениях приходится развиваться почти всем, кто связывает свою жизнь с нагрузочным тестированием.
Популярные инструменты нагрузочного тестирования
Если в функциональном тестировании еще можно обойтись без специальных инструментов, то в АФТ и НТ необходимы программы, позволяющие не только разрабатывать скрипты, но и выполнять их, проводя тестирование.
Еще лет десять назад в российском ИT господствовали enterprise-решения для НТ. Как следствие, данный вид тестирования на необходимом уровне могли себе позволить только крупные компании с большими бюджетами. Остальные довольствовались немногочисленными бесплатными opensource-решениями с «сырым» кодом, бедным функционалом и слабой поддержкой. Но время шло, дефекты этих инструментов исправлялись, а благодаря развитию сообществ, занимающихся нагрузочным тестированием, появилось настолько много расширений, библиотек и интеграций с другими инструментами, что возможности некоторых бесплатных решений сравнялись с функционалом платных. А отсутствие официальной поддержки с лихвой компенсируется форумами и чатами сообществ.
Поэтому на текущий момент список популярных инструментов для НТ по большей части состоит из бесплатных решений за исключением нескольких «динозавров»:
Подчеркну, что это перечень инструментов, позволяющих создавать скрипты НТ и выполнять тесты.
Кроме этого приходится пользоваться различными дополнительными средствами:
Данный список далеко не полный, но позволяет ознакомиться с наиболее популярными инструментами, которые используются специалистами НТ, и оценить необходимые знания в этой области.
Путь специалиста по нагрузочному тестированию от школы обучения до тимлида
Как было сказано ранее, перечисленные навыки и инструменты невозможно освоить сразу, тем более без реального опыта на проектах и задачах. Как же попасть в нагрузочное тестирование? В вузах такую специальность не дают, можно ли самому освоить профессию?
Конечно, при наличии хорошей образовательной базы (по специальности программирование, системы и сети, прикладная математика) можно начать изучать инструментарий и теорию. Но основная проблема, с которой придется столкнуться, это отсутствие возможности создать полноценную среду для НТ (стенд с развернутой системой для тестирования и мониторингом). Поэтому наиболее рационально будет пройти обучение на специальных курсах. Многие аутсорсинговые компании предлагают программы подготовки, позволяющие получить необходимые навыки и опыт с последующим трудоустройством. Тем самым, они пополняют свой штат, в том числе выпускниками технических вузов. Аналогичная школа обучения по специальности НТ работает с 2016 года и в нашей компании.
Обычно курсы идут 4-5 недель и включают в себя теоретическую часть, позволяющую разобраться в целях, методологии и процессе тестирования, и практическую, куда входит освоение 1-2 инструментов НТ и средств мониторинга. Ученики получают практические навыки: от разработки методики и скриптов до проведения тестов и подготовки отчета. Задачи выполняются на мощностях компании, предоставляющей обучение. Уроки ведут действующие специалисты по НТ, готовые поделиться своим опытом с реальных проектов. Выпускники школы НТ проходят стажировку уже на действующих проектах под присмотром наставников и по результатам выпускного экзамена зачисляются в штат компании на позицию младших специалистов по нагрузочному тестированию.
Дальнейшая карьера зависит исключительно от способностей и настойчивости. Среднестатистический выпускник курсов, поработав на 2-3 проектах, достигает уровня middle за 1.5 года, а звание senior можно получить уже на третьем году работы. При этом важно, что специалистам НТ предоставляется возможность менять проекты, осваивая различные технологии и инструменты, заниматься наставничеством выпускников школы обучения и принимать участие в преподавательской деятельности. Тем самым компания выращивает столь важное звено тимлидов, а сотрудникам дает шанс реализовать свой технический и управленческий потенциал.
Вместо заключения
Надеюсь, данная статья внесет немного ясности в то, что такое нагрузочное тестирование, чем занимается данный специалист, и поможет развеять миф, что тестирование – это для тех, кто не умеет программировать. Как видим, специальность нагрузочное тестирование дает широчайший кругозор и бескрайнее поле для развития технического специалиста. Здесь никогда не бывает скучно!
Нагрузочное тестирование: с чего начать и куда смотреть
Вы наверняка знаете, что есть большая разница между тем, как будет работать ваше приложение/сервис в зависимости от того, сколько пользователей его используют. То, что работало во время разработки, может развалиться, когда придут первые реальные пользователи со своим окружением, а то, что работало с сотней пользователей, может умереть, когда их станет 10 тысяч. Или бывает, что вы все потестили на искусственных данных, а потом ваша база начинает торзмозить из-за пользователя с именем İnari.
О том, как выживают баги, когда «включать» в проекте нагрузочные тесты, откуда брать для них данные и можно ли вообще не тестировать, вывалив результаты сразу в продакшн, мы поговорили с Алексеем Лавренюком («Яндекс») и Владимиром Ситниковым (Netcracker).
Пару слов о себе и своей работе. Как ваша работа связана с тестированием?
Алексей Лавренюк: Я разработчик в «Яндексе», в службе нагрузочного тестирования. Делаю инструменты и сервисы для тестирования производительности. Можно посмотреть на наши open-source инструменты для нагрузочного тестирования – Yandex.Tank и Pandora, и на наш сервис для нагрузочного тестирования – Overload. Сейчас открыт бесплатный доступ к его бета-версии.
Раньше мы умели тестировать только производительность серверных приложений, теперь осваиваем мобильные приложения – это новый тренд. Например, мы тестируем энергопотребление телефонов. Прочитать про это можно тут.
Владимир Ситников: Я уже 12 лет работаю в компании Netcracker. Сейчас я занимаю позицию инженера по производительности, т.е. я не тестирую продукты, но наблюдаю, как ведет себя система в реальной эксплуатации и в тестах. В сферу моей ответственности входит анализ того, как те или иные решения в сфере разработки и дизайна влияют на финальный результат. Поэтому я зачастую не просто смотрю на результаты тестирования, но и планирую его. В основном это относится к нагрузочному тестированию.
Когда-то я и сам занимался тестированием, но сейчас это осталось в прошлом.
— Давайте немного поговорим о теории. Корректно ли говорить, что проблемы на стадии тестирования появляются из-за разработчиков, не учитывающих какие-то параметры задачи или использующих неподходящее решение?
Алексей Лавренюк: Нельзя все предугадать заранее. В типичном сервисе очень много крутилок: для решения продуктовых задач можно выбирать разные алгоритмы, подбирать параметры этих алгоритмов, использовать библиотеки, фреймворки, настройки сервиса в продакшне, параметры железа. В сочетании эти крутилки дают миллиарды комбинаций, и без глубокого понимания того, как работает сервис, перебирать их можно очень долго. А понимание это нельзя получить, если у тебя нет инструмента для проведения экспериментов и анализа их результатов.
Нагрузочное тестирование — это не дубинка, которая бьет разработчиков по голове, когда они написали непроизводительный код. Это очень мощный измерительный прибор, по сути осциллограф для электронщика, позволяющий прощупать код и найти в нем узкие места. А потом после оптимизации увидеть (и продемонстрировать) результат в цифрах и графиках.
Владимир Ситников: Я бы хотел дополнить. «Откуда вообще возникают баги» — это вопрос тысячелетия. И он тесно связан с другим интересным вопросом — почему, несмотря на все тестирование, баги доживают до реальных систем и появляются только там. Почему в ходе тестирования мы их не находим? Неужели мы неправильно ставим задачу?
На мой взгляд, это связано с тем, что команды разработки и поддержки — разные. Одни люди делают решение и совсем другие — занимаются его поддержкой в ходе эксплуатации.
Половина всех проблем на продакшене — это сочетание 2-3 дурацких ошибок или допущений разработки: кто-то создал неправильный код, использовал дурацкий алгоритм и т.п. Каждая такая ошибка сама по себе не сказывается на производительности — современное железо довольно мощное, много чего переваривает. Но вместе две или три ошибки «выстреливают». А из-за разделения разработки и поддержки авторы этих ошибок о них и не узнают.
Редко когда по факту ищут авторов кода и говорят: «Пожалуйста, так больше не надо писать». Но чтобы гарантированно не совершать подобных ошибок в будущем, разработчику надо получить этот опыт. При поддержке своей собственной системы выводы из «набитых шишек» делались бы быстрее.
— Есть ли смысл в раннем нагрузочном тестировании (на этапе разработки)?
Алексей Лавренюк: Самые дорогие ошибки получаются тогда, когда нагрузочное тестирование притащили за уши на готовый проект (я уже не говорю о тех случаях, когда код тестируют в продакшене). Код написали, функционально он работает, но выясняется, что там, где требуется 10 ответов в секунду (всего-то), сервис может переварить только один, да и то со скрипом. Еще хуже, если в этом виноват фундамент – фреймворк, который выбрали, потому что «им все пользуются» или «ну он такой новый, прикольный». То есть придется переписывать вообще все.
Чем раньше отлавливаются проблемы, тем проще их решить.
— То есть начинаем разрабатывать и одновременно запускаем тестирование?
Владимир Ситников: И да, и нет. Иногда на ранней стадии надо совсем грубо посмотреть, что происходит. Это может иметь смысл. Но, как правило, вначале код не работает. А замерять производительность кода, который, допустим, возвращает неправильный ответ, — гиблое дело. Мы тратим время, ресурсы (в том числе машинные), а результат — неизвестный.
Однако запуск тестирования — история довольно длительная. Перед тем как что-то замерить, нужно понять, что именно замерять и на каких данных, закончатся ли у нас эти данные по ходу теста, как мы будем их возобновлять, за какими метриками будем следить, какие у нас есть ожидания относительно результатов и т.п. В совсем небольшом проекте все это можно провернуть за день-два, просто обсудив и приняв нужное решение. Но для более-менее крупного проекта подобные вопросы за один день не решаются, тем более тут требуется тесное взаимодействие с заказчиком.
Бывают случаи, когда заказчик приходит с определенными требованиями с самого начала, но чаще их приходится формулировать только на этапе «подключения» нагрузочного тестирования.
Поэтому думать о нагрузочном тестировании стоит с самого начала. И я бы не рассматривал нагрузочное тестирование как конечный продукт. Это некий процесс, которому надо следовать, чтобы избежать определенных ошибок. По мере создания решения (в процессе перехода непосредственно от разработки к тестированию и выводу на продакшн) меняется и назначение нагрузочного тестирования. Сначала оно используется для отладки, затем — для поиска ошибок, и в конце — как критерий того, что решение готово к продакшн.
Здесь мне кажется уместной аналогия с обычным тестированием. Когда его надо включать? Отнюдь не в конце разработки. То, что в конце разработки придут тестировщики и все исправят, — это миф. Тестирование не исправляет, а ищет ошибки. И нагрузочное тестирование — это инструмент поиска ошибок определенного рода. Однако в отличие от обычного тестирования, проверяющего по сути только возможность прохождения программы по ветке алгоритма до определенной точки, нагрузочное представляет собой бета-тест продакшна, что ведет к отличиям в данных, нагрузке, соотношении тестов в миксе и т.п.
Чтобы успешно находить ошибки, надо иметь критерии поиска. Поэтому как процесс нагрузочное тестирование запускается ближе к началу разработки, а по факту оно проходит условно после первого цикла тестирования (автоматического или ручного), когда кто-то дает отмашку, что в целом система ведет себя правильно.
— Понятно, что абсолютно все не протестировать. Какие моменты необходимо тестировать в первую очередь (в ракурсе нагрузочного тестирования)?
Алексей Лавренюк: Тестировать в первую очередь надо критический сценарий — то есть тот, который приносит деньги. И провести как минимум два вида тестов: на разладку, чтобы определить пределы производительности, и на измерение таймингов, чтобы убедиться, что сервис укладывается в SLA. То есть сервис обязательно нужно «добить» и померить тайминги на том уровне нагрузки, который предполагается в продакшн.
— С чего необходимо начинать нагрузочное тестирование?
Алексей Лавренюк: Перед тем, как начинать нагрузочное тестирование, нужно убедиться, что перед этим провели функциональное и поправили все баги. Причем именно на вашем стенде. Удостоверьтесь, что в середине вашей стрельбы к вам на стенд никто не придет, чтобы скачать пару сотен гигабайт. В общем, подготовьте удобное тестовое окружение, в котором вам никто не будет мешать.
Владимир Ситников: Само тестирование стоит начинать с формулирования нефункциональных требований — т.е. требований по производительности и стабильности.
Наиболее типичные нефункциональные требования (важнейшие количественные оценки приложения) — размер обрабатываемых данных, время их обработки и частота запусков. Какая-либо из этих метрик встречается почти в каждом проекте.
Понятие «нефункциональные требования» обширно. В разных проектах их составляющие могут иметь различный приоритет. Например, «система должна быть способна отработать 3 дня без перезагрузки» или «в случае пропадания и восстановления связи с базой данных приложение должно вернуться к нормальной работе не более чем за 2 минуты» — это тоже нефункциональные требования.
К слову, понятие «нефункциональные требования» формирует представление, что это нечто самостоятельное. Но по факту эти требования, описывающие, как должен работать функционал. Т.е. без нефункциональных требований и функциональные теряют смысл, равно как невозможно приложить NFR к любому случайно выбранному функциональному требованию.
— Существуют ли какие-то общие рекомендации по проведению нагрузочного тестирования?
Владимир Ситников: В целом нагрузочное тестирование похоже на обычное. Мы берем наиболее важные сценарии или те, за которые мы боимся больше всего. Поэтому кто-то с пониманием проекта должен прийти и указать на наиболее опасные сценарии. Дальше мы уже занимаемся автоматизацией и проводим замеры.
— Насколько большую роль играет интерпретация результатов нагрузочного тестирования?
Владимир Ситников: Огромную. Важны не цифры, а понимание, почему они именно такие. Если у нас получилось 42, это не значит, что результат — хороший. Заказчик просил, чтобы работало не дольше минуты, а у нас получилось полминуты. Мы молодцы, расходимся? Нет! Важно понимать, почему мы не могли сделать быстрее, во что мы упираемся. А еще надо быть уверенным в том, что отчет — реален.
Был такой пример: мы замеряли, как влияет виртуальная машина на производительность приложения, т.е. сравнивали производительность приложения, работающего на железе, и приложения, работающего на виртуальной машине. Сделали замеры, получили хорошие цифры (близкие к ожидаемым) — расхождение в производительности в несколько десятых процента. На этом все могло закончиться. Но кто-то внимательнее посмотрел на результаты и понял, что у нас вместо запуска приложения возвращалась страница с ошибкой логина. В тестах мы не прошли по реальному приложению. Вместо этого под видом каждого из шагов мы проверили скорость логина, который на неправильном пароле выдал отказ.
О чем говорит этот пример? О том, что без анализа того, что творилось внутри во время тестов, у нас возник неправильный вывод. Поэтому с точки зрения нагрузочного тестирования важны не полученные цифры, а понимание того, чем эти цифры объясняются.
Алексей Лавренюк: Очень часто люди недооценивают важность графиков, смотрят только на итоговые статистики. Если вы тоже так делаете, рекомендую погуглить «квартет Энскомба» и посмотреть вот эту статью от Autodesk.
Многие популярные в интернете нагрузочные инструменты, например ab, дают только итоговые статистики и ложную уверенность в работоспособности сервиса под нагрузкой. Они скрывают детали, провалы на графиках. Такой провал может стоить денег (покупатель ушел), а исправить его очень просто (поправить параметры garbage collector).
Кроме того, многие популярные и дорогие нагрузочные инструменты архитектурно устроены неправильно и лгут вам. Об этом написано в этой статье.
— Какие есть особенности нагрузочного тестирования веб-сервиса? По идее тестировать надо не только код, но и окружение, как это делается?
Алексей Лавренюк: Тестировать надо все, что вас интересует. Если вы подозреваете, что производительность приложения зависит от пробок в Москве, найдите способ это протестировать. Я не шучу, наши геосервисы запускают автоматически нагрузочные тесты на данных о пробках, когда их уровень достигает 7 баллов.
Еще у нас на тесте было мобильное приложение, которое активизировалось только в том случае, если телефон приходил в движение. То есть телефон во время теста нужно было шатать. Поэтому эти телефоны мы носили с собой. Была даже идея построить специальную шаталку телефонов, но приложение отправили на доработку, и необходимость в автоматизации пока отпала.
— Откуда берутся данные для нагрузочного тестирования вашего типичного проекта? Используются ли моки или данные с продакшн?
Владимир Ситников: Я бы не сказал, что к данным есть какой-то типичный подход. Проекты все-таки разные. Есть такие, где системы вообще не хранят данные, а являются промежуточными звеньями в некой цепочке. Для их тестирования мы просто генерируем необходимую информацию. Иногда, наоборот, системы что-то хранят. Если это, например, история записей, проблем, вроде как, нет. Но если системы хранят какое-то состояние (БД и т.д.), то здесь проявляются нюансы.
На начальном этапе, когда у нас нет никакого дампа продакшена, данные приходится генерировать (обсуждать бизнес-структуру и генерировать нужное количество подходящего сорта данных). К сожалению, я бы не сказал, что это успешно работает. Сгенерированные данные позволяют пережить какое-то время, но, к сожалению, получить таким образом данные, похожие на правду и подходящие для разных сценариев, тяжело. И начинаются игры, когда мы генерируем часть данных для одного типа запросов, часть — для другого, часть — для третьего. Нам удобнее генерить частями, но при этом получаются перекосы: либо данных слишком много (потому что мы по каждому типу сценариев хотим иметь запас), либо мы пропускаем какие-то сценарии. Из-за этого рано или поздно мы переходим на нечто более-менее похожее на дампы — импорт из внешних систем или продакшн с маскированием.
С импортом тоже есть свои проблемы. Мы работаем в телеком-сегменте, где дампы продакшн-систем нельзя копировать направо-налево. Там присутствуют определенного типа данные, которые просто так копировать нельзя. Поэтому приходится изобретать, как сделать так, чтобы система вроде бы работала, но данные были заменены на звездочки и т.д.
— Не проще тестировать сразу на продакшене, подключая какую-то долю пользователей?
Алексей Лавренюк: В нашем случае это не тестирование, это аккуратный релиз. По-хорошему, всегда, даже после тестирования, нужно выкатывать на долю пользователей, потому что в продакшне может пойти все не так, как в тестинге.
Чем подключение доли пользователей отличается от нагрузочного тестирования? В этом случае у вас нет возможности полностью управлять нагрузкой, вы не можете довести сервис до предела (пользователи просто 500 ошибку начнут получать), вы не можете безнаказанно крутить на нем ручки и замониторить столько, сколько могли бы на тестовых серверах.
С другой стороны, можно исхитриться: часть трафика с продакшн направить на ваши тестовые сервера и там использовать нагрузочные инструменты. Вот это уже нагрузочное тестирование, просто исходные данные берутся в реалтайме с продакшн окружения.
Иными словами, если вас устраивает ответ «держим/не держим» (причем с вероятностью разочаровать какую-то долю своих пользователей), то можно и не тестировать нагрузочно. Если же вы хотите знать пределы производительности, узкие места, в какие мониторинги лучше смотреть, за какие крутилки в первую очередь хвататься и к кому бежать – то все-таки сделайте нагрузочное тестирование.
Владимир Ситников: Это не наш случай. Существуют компании, которые без проблем тестируют в продакшене. У них есть часть клиентов, которая может быть перенаправлена на новую версию кода. В нашем случае речь идет о системе, важной для бизнеса наших заказчиков. Если она не работает, заказчик теряет деньги. Поэтому и нагрузочные тесты проводим до попадания кода в эксплуатацию.
— Есть ли у вас какой-то излюбленный инструментарий для проведения нагрузочного тестирования?
Владимир Ситников: Конечно. У нас 3 основных инструмента: для тестирования серверной части мы используем Apache JMeter, для тестирования браузера мы используем Selenium и для тестирования Java — JMH. Эти инструменты закрывают подавляющее большинство потребностей.
То, какие инструменты для тестирования предпочитает использовать Алексей Лавренюк, вы можете узнать у него лично на конференции по тестированию Гейзенбаг 2017 Piter. Перед тем, как побеседовать со всеми желающими в дискуссионной зоне, Алексей выступит с докладом о нагрузочном тестировании web-проектов, где в режиме real time show будет «обстреливать» демонстрационный web-сервис на Python Tornado, специально написанный так, чтобы проявились проблемы производительности, анализировать отчеты нагрузочных тестов, исправлять «узкие места», а затем сравнит производительность «до» и «после».
Описание этого и других докладов, которые ожидают вас на Гейзенбаг 2017 Piter, смотрите на сайте конференции.