Нагрузочные испытания прогнозирование ошибок

Мониторинг + нагрузочное тестирование = прогнозирование и отсутствие сбоев

IT-департаменту ВТБ несколько раз приходилось сталкиваться с нештатными ситуациями в работе систем, когда нагрузка на них многократно возрастала. Поэтому появилась необходимость разработать и опробовать модель, которая предсказывала бы пиковую нагрузку на критичные системы. Для этого IT-специалисты банка настроили мониторинг, проанализировали данные и научились автоматизировать прогнозы. Какие инструменты помогли спрогнозировать нагрузку и получилось ли с их помощью оптимизировать работу, мы расскажем в небольшой статье.

Проблемы с высоконагруженными сервисами возникают практически во всех отраслях, но для финансовой сферы они критичны. В час X все боевые единицы должны быть наготове, а потому требовалось знать заранее, что может случиться и даже определять день, когда подскочит нагрузка, и какие системы с ней столкнутся. Со сбоями нужно бороться и предотвращать их, поэтому необходимость внедрения системы прогнозной аналитики даже не обсуждалась. Нужно было модернизировать системы на основе данных мониторинга.

Аналитика на коленке

Зарплатный проект — один из самых чувствительных в случае сбоя. Он же наиболее понятен для прогнозирования, поэтому начать решили с него. Из-за высокой связности в моменты пиковых нагрузок могли испытывать проблемы и другие подсистемы, включая дистанционное банковское обслуживание (ДБО). Например, клиенты, обрадованные SMS о поступлении денег, начинали активно ими пользоваться. Нагрузка при этом могла подскакивать более чем на порядок. 

Первую модель для прогноза создавали вручную. Мы взяли выгрузку за последний год и посчитали, в какие дни ожидаются максимальные пики: например, 1-го, 15-го и 25-го числа, а также в последние дни месяца. Эта модель требовала серьезных трудозатрат и не давала точного прогноза. Тем не менее она выявила узкие места, куда нужно было добавить «железа», и позволила оптимизировать процесс перечисления денег, договорившись с якорными клиентами: чтобы не давать зарплату «залпом», транзакции из разных регионов разнесли по времени. Теперь мы обрабатываем их частями, которые IT-инфраструктура банка способна «прожевать» без сбоев.

Получив первый положительный результат, мы перешли к автоматизации прогнозирования.Своей очереди ждал еще десяток критичных участков.

Комплексный подход

В ВТБ внедрили систему мониторинга компании MicroFocus. Оттуда мы взяли сбор данных для прогнозирования, систему хранения и систему генерации отчетов. По сути, мониторинг уже был, оставалось только добавить метрики, модуль предсказания и создать новые отчеты. Поддерживает это решение внешний подрядчик «Техносерв», поэтому основные работы по реализации проекта легли на его специалистов, но модель мы строили самостоятельно. Систему прогнозирования сделали на основе Prophet — этот открытый продукт разработан в Facebook. Он прост в использовании и легко интегрируется с установленными у нас средствами комплексного мониторинга и Vertica. Грубо говоря, система анализирует график загрузки и на основе рядов Фурье делает его экстраполяцию. Есть также возможность добавлять некие коэффициенты по дням, взятые из нашей модели. Метрики снимаются без участия человека, раз в неделю прогноз автоматически пересчитывается, новые отчеты рассылаются адресатам. 

Такой подход выявляет основные цикличности, например, годовые, месячные, квартальные и недельные. Выплата зарплат и авансов, периоды отпусков, праздники и распродажи — все это влияет на количество обращений к системам. Выяснилось, например, что некоторые циклы накладываются друг на друга, а основную нагрузку (75%) на системы дает Центральный федеральный округ. Юридические и физические лица ведут себя по-разному. Если нагрузка от «физиков» относительно равномерно распределена по дням недели (это очень много небольших транзакций), то у компаний 99,9% приходится на рабочее время, притом транзакции могут быть короткими, а могут обрабатываться в течение нескольких минут и даже часов.

На основании полученных данных определяются длительные тренды. Новая система выявила, что люди массово уходят в ДБО. Это всем известно, но таких масштабов мы не ожидали и поначалу в них не поверили: количество обращений в офисы банка чрезвычайно быстро снижается, и ровно на столько же растет количество дистанционных транзакций. Соответственно, нагрузка на системы тоже растет и будет расти дальше. Сейчас мы прогнозируем нагрузку до февраля 2020 года. Нормальные дни получается предсказать с погрешностью в 3%, а пиковые — с погрешностью в 10%. Это хороший результат.

Подводные камни

Без трудностей, как водится, не обошлось. Механизм экстраполяции с использованием рядов Фурье плохо переходит через ноль — мы знаем, что в выходные юридические лица генерируют мало транзакций, но модуль предсказания выдает далекие от нуля значения. Можно было поправить их принудительно, но костыли — не наш метод. Кроме того, пришлось решить проблему безболезненного съема данных с систем-источников. Регулярный сбор информации требует серьезных вычислительных ресурсов, поэтому мы построили быстрые кэши с использованием репликации, получаем бизнес-данные уже с реплик. Отсутствие дополнительной нагрузки на мастер-системы в таких случаях — блокирующее требование.

Новые вызовы

Поставленная в лоб задача по предсказанию пиков была решена: связанных с перегрузкой сбоев в банке не было с мая этого года, и новая система прогнозирования сыграла в этом не последнюю роль. Да, ее оказалось недостаточно, и теперь банк хочет понять, насколько опасны для него пики. Нам нужны прогнозы с использованием метрик от нагрузочного тестирования, и примерно для 30% критичных систем это уже работает, остальные в процессе получения прогнозов. На следующем этапе мы собираемся прогнозировать нагрузку на системы не в бизнес–транзакциях, а в терминах IT-инфраструктуры, т. е. опустимся на слой ниже. Кроме того, нам нужно полностью автоматизировать сбор метрик и построение прогнозов на их основе, чтобы не заниматься выгрузками. В этом нет ничего выдающегося — мы просто скрещиваем мониторинг и нагрузочное тестирование в соответствии с лучшими мировыми практиками.

Процесс разработки программного обеспечения требует обширного постоянного тестирования, в первую очередь agile-тестирования, для обеспечения эффективной и предсказуемой работы. Однако гибкое тестирование имеет ограничения в отношении опыта конечного пользователя в многопользовательской системе. Когда проект программного обеспечения близится к завершению, компании должны обратиться к другому типу тестирования, известному как нагрузочное тестирование, чтобы определить, как приложение будет работать в реальном мире при различных уровнях нагрузки и трафика.

Что такое нагрузочное тестирование?

Нагрузочное тестирование — это подмножество тестирования производительности, используемое для программного обеспечения, веб-сайтов, приложений и связанных с ними систем. Это нефункциональный тест, который имитирует поведение нескольких пользователей, одновременно обращающихся к системе. Также называемое «объемным тестированием», нагрузочное тестирование воспроизводит производительность, стабильность и функциональность веб-системы в реальных условиях, поэтому оно является одним из последних и наиболее важных видов тестирования, проводимых перед развертыванием.

Нагрузочное тестирование выявляет несколько критических аспектов веб-системы, включая следующие:

• Общая операционная мощность приложения, включая количество одновременно работающих пользователей, которых можно поддерживать
• Способность приложения реагировать на пиковые нагрузки пользователей
• Стабильность инфраструктуры приложения
• Время отклика приложения, пропускная способность и потребность в ресурсах при различных уровнях пользовательской нагрузки

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

Зачем нужно нагрузочное тестирование?

Функциональные тесты играют важную роль в разработке программного обеспечения, но они имеют ограничения в прогнозировании производительности при различных уровнях вовлеченности пользователей. Нагрузочное тестирование выявляет критические проблемы производительности, которые не могут выявить другие тесты, что позволяет компаниям устранить проблемы до запуска программного обеспечения или внедрения обновлений.

Компаниям необходимо проводить нагрузочное тестирование по трем основным причинам:

• Оценить функциональность программного обеспечения
• Получение дохода, предоставление услуг и защита репутации компании
• Для обеспечения приятного и эффективного взаимодействия с пользователями

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

Обратите внимание, что хотя программное обеспечение для нагрузочного тестирования обычно ассоциируется с интернет-приложениями, оно также используется для тестирования оборудования.

Преимущества нагрузочного тестирования

Предприятия, предлагающие приложения для Интернета или интранета, получат огромную выгоду от нагрузочного тестирования. Некоторые из лучших причин для проведения нагрузочного тестирования включают:

1. Предотвращает простои и сбои в работе приложений

Использование нагрузочного тестирования помогает оптимизировать систему для нормальных и пиковых нагрузок и выявить возможные простои из-за неожиданной нагрузки.

Кроме того, нагрузочное тестирование помогает подготовиться к периодам роста или аномально высокого уровня использования, например, при продаже товаров электронной коммерции или запуске нового продукта.

2. Мониторинг стандартов производительности

Нагрузочное тестирование предоставляет данные о производительности, которые компании используют для оценки кода приложений и изменений в инфраструктуре.

Организация может разработать цели эффективности, проанализировав трафик в средние и пиковые часы.

3. Сокращение расходов

Время простоя сети обойдется компании в среднем в 5 600 долларов в минуту (300 000 долларов в час). Кроме того, пользователи, которые часто сталкиваются с нефункциональным приложением, с большей вероятностью никогда не вернутся к нему.

Затраты на нагрузочное тестирование неизменно ниже, чем потенциальные расходы на чрезмерное время простоя, недоступность сайта и более масштабные потери, связанные с недовольством клиентов.

4. Повышает эффективность

Нагрузочное тестирование выявляет узкие места в системе, устранение которых позволяет системе работать с максимальной эффективностью. Устранение узких мест позволяет не только повысить производительность работы, но и улучшить масштабируемость системы.

Эффективные, быстро загружающиеся страницы повышают удовлетворенность пользователей и улучшают рейтинг сайта в поисковой выдаче.

5. Соблюдение соглашения об уровне обслуживания

Нагрузочное тестирование позволяет организации измерить качество производительности, данные используются для разработки соглашений об уровне обслуживания ( SLA ), которые обеспечивают гарантированные базовые показатели для пользователей. Эти данные также полезны для сравнения показателей с внутренними эталонами и показателями конкурентов.

6. Планирование мощностей

Нагрузочное тестирование предоставляет информацию, жизненно важную для планирования мощностей. Если приложение положительно реагирует на тест, организация может планировать расширение и пиковое время соответственно. Если приложение регистрирует показатели за пределами принятых параметров — если оно «проваливает» нагрузочный тест — данные все равно полезны в качестве стресс-теста.

(Подробнее о разнице между нагрузочным и стресс-тестом вы узнаете далее в этом руководстве).

Проблемы и ограничения нагрузочного тестирования

Нагрузочное тестирование дает значительные преимущества, о чем свидетельствует его широкое распространение в различных отраслях и системах. Однако, как и в любом другом приложении, существуют недостатки и проблемы.

Вызов 1: Неосязаемость

Нагрузочное тестирование не обязательно является самым заметным инструментом, поскольку одним из его основных преимуществ является выявление потенциальных проблем до того, как они возникнут в реальной ситуации. Многие негативные финансовые и иные последствия, связанные с простоем сайта и сбоями в работе приложений, просто не реализуются.

Типы тестирования, ориентированные на сценарии «что если», обычно остаются без внимания. Хотя нагрузочное тестирование может помочь в анализе после перегрузки пользователей, оно гораздо более полезно для организации в качестве профилактического инструмента.

Вызов 2: Сложность

Как инструменты нагрузочного тестирования с открытым исходным кодом, так и собственные инструменты могут иметь высокий барьер для входа на техническом уровне. В зависимости от размера и сложности организации, у них может не быть сотрудников или ресурсов для проведения нагрузочного тестирования.

Исключением в этом вопросе является профессиональная платформа для нагрузочного тестирования, такая как ZAPTEST load testing, которая сосредоточится на предоставлении понятного, удобного интерфейса. ZAPTEST LOAD предлагает возможность создавать записанные и основанные на API сценарии, выполняющие бизнес-процессы конечного пользователя и измеряющие сквозные транзакции в системе под нагрузкой (SUL).

Виды нагрузочных испытаний

Существует несколько различных типов нагрузочного тестирования, что позволяет организациям адаптировать свою стратегию тестирования в зависимости от бюджета, сложности проекта, технических знаний сотрудников и других факторов.

1. Нагрузочное тестирование вручную

Ручное нагрузочное тестирование — это когда система оценивается без автоматизированных инструментов нагрузочного тестирования, то есть симулированные пользователи создаются вручную.

Ручное нагрузочное тестирование дает мало преимуществ, если вообще дает. Помимо логистических трудностей, результаты тестирования, как правило, ненадежны и практически невозможно воспроизвести. Если у организации нет особой необходимости в ручном тестировании, ее усилия лучше направить на автоматизированное тестирование программного обеспечения.

2. Инструменты для внутреннего тестирования

Поскольку нагрузочное тестирование является непрерывным процессом, особенно в период роста, многие организации предпочитают создавать собственные средства автоматизации нагрузочного тестирования.

Пользовательские инструменты разрабатываются с нуля для работы с конкретными приложениями организации, что позволяет легко и полностью интегрировать инструмент с системой. Дополнительные преимущества включают сокращение времени настройки, необходимости технического обслуживания, ошибок в работе, времени на обучение и т.д.

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

3. Инструменты тестирования с открытым исходным кодом

Существует множество инструментов тестирования с открытым исходным кодом. Будучи программами с открытым исходным кодом, они бесплатны для использования, предлагают широкие возможности для модификации и опираются на мощную поддержку сообщества.

Популярные инструменты тестирования с открытым исходным кодом включают Locust, k6 и JMeter. Каждый из них позволяет моделировать масштабные пользовательские нагрузки, записывать сценарии тестирования, просматривать отчеты о производительности и многое другое.

Хотя большинство инструментов с открытым исходным кодом «сделают свою работу», они могут иметь недостатки, особенно для корпоративных организаций. Инструменты с открытым исходным кодом часто сложны, им не хватает удобства для пользователя, которое есть в коммерческих инструментах автоматизации нагрузочного тестирования. Кроме того, поддержка обычно ограничивается вики, форумами и т.п., которые имеют ограниченное применение в чрезвычайных ситуациях.

4. Инструменты автоматизации нагрузочного тестирования корпоративного класса

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

Преимущества использования услуг по тестированию нагрузки на предприятии включают:

• Способность генерировать огромное количество пользовательского трафика
• Возможность захвата/воспроизведения
• Возможность поддержки нескольких протоколов
• Возможность восстановления утраченных документов
• Ввод тестовой документации одним щелчком мыши

К популярным компаниям, занимающимся нагрузочным тестированием предприятий, относятся ZAPTEST и их партнер по технологической отрасли, компания Gartner. (Те, кто знаком с индустрией автоматизации, могут также узнать ZAPTEST по их известной работе в области автоматизации роботизированных процессов). Более того, БЕСПЛАТНАЯ версия ZAPTEST предлагает бесплатную функциональность LOAD, позволяющую пользователям проводить тестирование производительности с использованием новейших функций и углубленного анализа.

Инструменты автоматизации нагрузочного тестирования корпоративного уровня предлагают надежные, поддерживаемые решения, которые не требуют таких технических знаний, как инструменты с открытым исходным кодом. Большинство корпоративных услуг по нагрузочному тестированию работают по модели подписки.

Что следует тестировать с помощью нагрузочного тестирования?

Автоматизированные инструменты нагрузочного тестирования генерируют данные, используемые для точного ответа на несколько жизненно важных вопросов:

• Сколько пользователей у приложения (сайта, системы и т.д.) в обычные часы? В часы пик?
• На какие элементы приложения влияет какое количество пользователей?
• Какое количество пользователей приведет к тому, что сайт перейдет в автономный режим?
• Когда у системы закончатся ресурсы?
• Как быстро загружается сайт?

Проводя нефункциональное моделирование, организация получает данные о скорости, надежности и способности к масштабированию. Тестирование отдельных аспектов создает более полную картину, в которой легче выявить узкие места.

1. Базовые показатели

Компании могут использовать нагрузочное тестирование для проверки базовой производительности приложения. Поскольку количество пользователей в ходе тестирования постоянно увеличивается, созданные данные показывают базовую производительность для средней скорости соединения, времени загрузки файлов и задержки.

2. Производительность эталона

Нагрузочное тестирование веб-сайта также позволяет получить эталонные данные о производительности. Хотя термины «базовый» и «эталонный» часто используются как взаимозаменяемые, они имеют существенные различия. Эталонное тестирование измеряет производительность по сравнению с конкурирующими сайтами или внутренними требованиями (например, SLA конечных пользователей).

Метрики/цели нагрузочного тестирования

Отдельные организации будут разрабатывать метрики тестирования, исходя из своих уникальных потребностей. Одним из значительных преимуществ автоматизированных инструментов нагрузочного тестирования корпоративного уровня является возможность настраивать отслеживаемые метрики.

Независимо от этого, большинство организаций будут отслеживать следующие показатели при автоматическом нагрузочном тестировании:

1. Время реакции

Время отклика является основной метрикой, измеряемой при автоматическом нагрузочном тестировании. Сколько времени требуется системе для ответа после того, как пользователь отправил запрос? (Время ответа более 10 секунд, скорее всего, заставит пользователя уйти).

2. Пропускная способность

Пропускная способность — это количество отправленных и полученных данных. При нагрузочном тестировании он обычно выражается в количестве посещений в секунду (hps) или транзакций в секунду (tps).

3. Метрики, специфичные для аппаратного обеспечения

Медленное время отклика может сигнализировать об аппаратных ограничениях, поэтому часть процесса нагрузочного тестирования включает мониторинг использования процессора, доступной оперативной памяти, дискового ввода-вывода и аналогичных аппаратных функций.

4. База данных

Для работы большинства приложений корпоративного уровня требуется несколько систем, но с увеличением количества баз данных возрастают и возможности возникновения узких мест. Программное обеспечение для нагрузочного тестирования измеряет количество чтений и записей в базе данных, а также количество открытых соединений с базой данных.

Устранение некоторой путаницы

Многие методы обеспечения качества программного обеспечения пересекаются и переплетаются. Даже те, кто обладает профессиональным опытом, могут чувствовать себя растерянными в отношении следующих видов услуг по тестированию программного обеспечения.

Тестирование производительности в сравнении с нагрузочным тестированием

Тестирование производительности — это общий термин для всех методов, используемых для измерения стабильности, отзывчивости, потребности в ресурсах и других показателей производительности программной системы, особенно в том, что касается пользовательского опыта.

Нагрузочное тестирование является подкатегорией тестирования производительности. Другие распространенные типы включают:

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

Тесты производительности — это нефункциональные тесты, которые обычно проводятся в конце цикла разработки или после завершения разработки.

Стресс-тестирование и нагрузочное тестирование

Нагрузочное и стресс-тестирование во многом схожи. Повторимся, что нагрузочный тест веб-сайта измеряет реакцию системы на ожидаемый объем трафика, например, нормальный или пиковый трафик. Вы проводите нагрузочное тестирование, чтобы оценить снижение производительности и ее связь с пользовательским опытом во время исторически ожидаемых нагрузок. Короче говоря, нагрузочное тестирование не предназначено для того, чтобы сломать систему.

Стресс-тестирование имеет другую цель. Во время стресс-теста количество пользователей увеличивается до тех пор, пока не произойдет ухудшение производительности вплоть до полного отказа. Стресс-тест не просто измеряет «точку разрыва» системы, но и рассматривает, какой тип автоматического восстановления будет произведен системой.

Разработчики могут задаться целью провести стресс-тест, но это может произойти и случайно во время нагрузочного теста верхнего уровня. В обоих типах тестов средства автоматизации нагрузочного тестирования заставляют систему превысить доступные ресурсы, предоставляя множество ценных данных.

Функциональное тестирование и нагрузочное тестирование

Функциональное тестирование и нагрузочное тестирование — это типы тестирования производительности, и хотя оба они необходимы, каждый из них служит разным целям.

Функциональное тестирование определяет, соответствует ли определенный аспект системы заранее установленным требованиям. Он используется гораздо чаще, чем нагрузочное тестирование, с четко определенными параметрами и этапами. Нагрузочное тестирование более непредсказуемо, его результаты могут сильно отличаться от ожидаемых.

Кроме того, нагрузочное тестирование полностью зависит от пользовательской нагрузки, в то время как функциональное тестирование основано на тестовых данных.

Характеристики эффективного нагрузочного испытания

Хотя нагрузочное тестирование предприятий является мощным инструментом, если предприятия хотят добиться максимальной эффективности тестирования, им следует придерживаться следующих передовых методов.

1. Использует реалистичные сценарии

Сценарии тестирования должны как можно ближе напоминать реальное поведение пользователей. Внимательно изучите поведение пользователей. Почему они используют ваше приложение? Какие типы устройств они используют для доступа к нему?

Включите в нагрузочный тест вашего сайта непредсказуемое поведение, поскольку реальные пользователи будут вести себя неожиданным образом, который вы не можете предугадать.

2. Не начинается с нуля

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

3. Использует реальные данные

Как показывает предыдущая практика, чем качественнее данные, полученные перед тестированием, тем полезнее результаты тестирования. Для разработки реалистичных сценариев обратитесь к данным, полученным ранее с помощью инструментов мониторинга.

Следует рассмотреть две полезные категории данных:

• Данные о движении пользователя: используемые устройства и браузеры, пройденные пути и точки падения.
• Системные данные: время первого прощания, загрузка DOM

4. Анализ и повторение

После нагрузочного тестирования ваша команда захочет определить узкие места и соответствующий им код. Превращение информации, полученной из результатов тестирования, в улучшаемые показатели не всегда просто, особенно при использовании программного обеспечения с открытым исходным кодом, хотя корпоративные инструменты автоматизации нагрузочного тестирования могут сделать этот процесс намного проще и эффективнее.

Хотя нагрузочное тестирование жизненно необходимо перед запуском продукта, это не решение «раз и готово». Вместо этого нагрузочное тестирование должно стать частью практики agile и автоматизации организации.

Кто участвует в процессе нагрузочного тестирования?

Несмотря на то, что нагрузочное тестирование проводится ближе к концу разработки, оно требует участия многих различных команд, включая команды, которые начинают работу гораздо раньше в жизненном цикле продукта.

1. Инженеры по развитию

Инженеры будут использовать интегрированные среды разработки для тестирования процессов во время разработки, в результате чего будут получены данные, которые помогут установить параметры нагрузочного тестирования перед выпуском.

2. Другие испытатели

Agile- и функциональные тестировщики обеспечивают ценное понимание конкретных компонентов приложения. Кроме того, данные, полученные в ходе гибких тестов, помогают определить базовые показатели, используемые при нагрузочном тестировании.

3. Конечные пользователи/заинтересованные стороны

Их цели определяют их поведение в приложении. Понимание их мотивации в системе помогает составить сценарии тестирования.

Процесс нагрузочного тестирования

Процесс нагрузочного тестирования может стать довольно сложным, особенно при использовании программного обеспечения для тестирования с открытым исходным кодом или собственного производства. Хотя программное обеспечение корпоративного класса значительно упрощает тестирование, понимание основных этапов проведения нагрузочного тестирования помогает добиться наилучших результатов.

Хотя специфика нагрузочного тестирования зависит от бизнес-модели, аппаратного обеспечения, пользовательской базы и других индивидуальных факторов, в большинстве случаев тестирование следует этой базовой структуре:

1. Определение целей

Четкие цели приводят к более полезным результатам. Определите наиболее важные функции приложения для тестирования.

2. Установление базового уровня

Если вы проводили предыдущие тесты, используйте эти данные для создания базовой линии производительности для предстоящего теста. Любое отклонение от базового уровня указывает на необходимость дальнейшего исследования.

3. Создание среды нагрузочного тестирования

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

4. Разработка сценариев нагрузки

Наиболее распространенным способом создания сценария нагрузки является комбинирование сценариев и записанных действий пользователя. Каждый сценарий будет включать измерения, операции и точки проверки.

5. Выполнение тестов

После того как вы установили базовые линии, сценарии нагрузки и создали тестовую среду, тесты готовы к выполнению. Вы можете запустить несколько сценариев одновременно, регулируя уровни пользователей, местоположение, браузеры и другие факторы.

6. Послетестовый осмотр

Проведенное тестирование позволяет получить впечатляющее количество данных, включая время отклика, время загрузки, ошибки, производительность сервера и многое другое. В большинстве случаев анализ данных предполагает повторное выполнение сценариев для сужения круга вопросов и выявления основной проблемы.

Ключом к успешной интерпретации данных является предварительная постановка четких целей и ведение обширной документации в процессе анализа.

Примеры нагрузочных испытаний

Нагрузочное тестирование используется во многих сценариях, включая ситуации, которые многие компании упускают из виду. Примеры включают:

1. Сайты

Загрузка больших файлов в течение длительного времени проверяет возможности веб-приложения.

2. Сервер

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

3. Жесткие диски

Многократное чтение и запись данных будет проверять пределы возможностей жестких дисков в системе.

4. Почтовый сервер

Почтовые серверы тестируются на нагрузку путем имитации активности пользователей. Большинство тестов нагрузки почтового сервера имитируют не менее 1 000 пользователей.

5. Интерфейс прикладного программирования

Нагрузочное тестирование API проводится для операционных систем, программных библиотек, языков программирования, аппаратного обеспечения и многого другого.

6. Принтер

Нагрузочные тесты принтера включают в себя отправку все большего количества заданий в очередь принтера. Это редко физический тест, требующий работы оборудования.

Нагрузочные тестовые примеры

Нагрузочное тестирование приносит пользу организациям всех типов и размеров. Некоторые реальные случаи, связанные с применением нагрузочного тестирования, включают:

1. Рекламные мероприятия

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

2. Публичные веб-порталы

Тестирование помогает подготовить крупные порталы к резким изменениям в использовании, например, когда на портале налоговой службы наблюдается рост посещаемости в налоговый сезон. Аналогичным примером может быть нагрузочное тестирование веб-порталов, чтобы помочь колледжу подготовиться к онлайн-регистрации в начале семестра.

3. Тестирование сервера

Подвергая сервер большому объему трафика, корпоративная организация может определить, достаточно ли ее инфраструктуры для предстоящего расширения. Тестирование сервера также является важной частью поддержания хорошо функционирующего веб-сайта.

4. Тестирование передачи файлов

Нагрузочное тестирование позволяет измерить скорость передачи файлов на жесткий диск и с жесткого диска, например, между ноутбуком и настольным компьютером или ноутбуком и ноутбуком. Помимо прочего, он может помочь организациям определить, какое оборудование следует приобрести для сотрудников.

Как написать тестовый пример нагрузки

Обучение нагрузочному тестированию может показаться сложным даже опытным специалистам в области программного обеспечения, но все гораздо проще, чем многие думают.

Создание руководящего документа — это первый этап разработки тестового случая нагрузки. Ваш план нагрузочного тестирования не обязательно должен быть сложным, полезным может быть даже список основных пунктов, но он должен описывать основные компоненты тестирования от начала до конца.

Убедитесь, что план нагрузочного тестирования включает следующие элементы:

1. Цели и требования

Почему вы проводите этот тест? Какие конкретные метрики вы тестируете, и какие результаты определят тип ответа относительно производства?

2. Границы

Опишите объем нагрузочного тестирования системы или браузера. Вы проводите тестирование компонентов или комплексное тестирование? Какую нагрузку на трафик вы тестируете (пиковую, нормальную или какую-то другую)?

Масштаб может измениться во время тестирования, особенно если вы столкнетесь с неожиданным событием. Тем не менее, вы все равно хотите изначально определить четкие границы тестирования.

3. Рабочая нагрузка

Вам необходимо подробно описать свой профиль нагрузки, который состоит из следующего:

• Ключевые сделки
• Распределение нагрузки на транзакцию
• Сроки проведения сделки

Разработка профиля нагрузки/модели рабочей нагрузки — это, пожалуй, самый важный элемент нагрузочного тестирования, поскольку он определяет, насколько близко ваш тест отражает поведение системы под нагрузкой реальных пользователей. Не забудьте провести нагрузочное тестирование браузера, поскольку вы не знаете, каким браузером будут пользоваться посетители.

4. Здоровье сервера

Опишите ваш план мониторинга серверов во время тестирования. Вам нужно будет контролировать оба сервера приложений, а также серверы, используемые для запуска нагрузочных тестов (хотя последнее обычно не является серьезной проблемой при использовании корпоративных инструментов нагрузочного тестирования).

5. Сценарий тестирования

Наконец, вам нужно описать сценарий тестирования, который представляет собой общий план реализации серии тестовых случаев.

6. Примеры тестовых примеров нагрузки

Некоторые общие примеры случаев, используемых на уровне предприятия, включают:

• Нагрузочное тестирование API для определения того, обрабатываются ли платежи менее чем за две минуты через стороннюю систему.
• Нагрузочное тестирование браузеров для определения того, ощущают ли пользователи разницу в скорости загрузки более чем в 10 секунд в зависимости от их браузера.
• Тест компонента на функциональность новой функции сайта при использовании во время пикового трафика.

Обратите внимание, что в вышеприведенных сценариях четко определены цели, границы и метрики.

Инструменты для нагрузочного тестирования

Корпоративные организации иногда разрабатывают собственные инструменты нагрузочного тестирования, но это процесс, требующий времени и инвестиций, что делает его скорее долгосрочной стратегией. Пока разрабатываются собственные инструменты, организация должна обратиться к бесплатным или корпоративным инструментам автоматизированного нагрузочного тестирования.

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

1. Бесплатные инструменты нагрузочного тестирования

Многие организации сначала рассматривают инструменты тестирования с открытым исходным кодом. Здесь нет недостатка в вариантах, включая следующие:

• JMeter — Java-приложение, основанное на корпоративном инструменте LoadRunner.
• Taurus — Инструмент, позволяющий писать собственные нагрузочные тесты.
• k6 — Инструмент нагрузочного тестирования, ориентированный на инфраструктуру back-end и предназначенный для опытных разработчиков.
• SoapUI — Нагрузочный тест SoapUI использует простой протокол доступа к объектам. Также доступна коммерческая версия этого приложения.
• Locust — инструмент нагрузочного тестирования, известный своим относительным удобством для пользователя и небольшими потребностями в ресурсах.
• ZAPTEST FREE Edition предлагает бесплатное тестирование производительности через LOAD Studio, где пользователи могут использовать записанные и основанные на API сценарии и даже коррелировать с функциональным тестированием.

Хотя инструменты тестирования с открытым исходным кодом не имеют прямых денежных затрат, их выбор все равно является важным обязательством для любого предприятия, поэтому важно понимать как преимущества, так и потенциальные недостатки.

Преимущества бесплатных инструментов нагрузочного тестирования

Бесплатные инструменты нагрузочного тестирования имеют несколько заметных преимуществ.

1. Низкая стоимость

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

2. Гибкость

Программное обеспечение с открытым исходным кодом часто пересматривается, обновляется и совершенствуется сообществом. Если у вас есть особые потребности в тестировании, могут существовать дополнения.

3. Более быстрая модернизация

Программное обеспечение с открытым исходным кодом обычно развивается быстрее, чем коммерческое. Исправления ошибок, обновления безопасности, новые функции и многое другое обычно появляются в более стабильном и быстром темпе.

Ограничения бесплатных инструментов нагрузочного тестирования

Хотя бесплатные инструменты нагрузочного тестирования имеют значительные преимущества, компаниям следует обратить внимание на потенциальные недостатки.

1. Отсутствие поддержки

Если пользователь столкнется с какими-либо проблемами при использовании программного обеспечения для нагрузочного тестирования с открытым исходным кодом, ему придется искать ответ самостоятельно, используя такие источники, как форумы и вики. В отличие от корпоративного программного обеспечения, бесплатные инструменты не имеют специальной службы поддержки, в которую можно позвонить или написать по электронной почте.

2. Сложность

Удобство использования не всегда является приоритетом для программного обеспечения для нагрузочного тестирования с открытым исходным кодом. Многие приложения предполагают, что пользователь обладает достаточно сложными знаниями в области разработки. Научиться проводить нагрузочное тестирование с помощью программного обеспечения с открытым исходным кодом обычно непросто.

3. Ограничения нагрузки на пользователя

Программное обеспечение для тестирования с открытым исходным кодом часто сталкивается с проблемами памяти и процессора при проведении нагрузочных тестов большой мощности. Компании корпоративного уровня могут обнаружить, что бесплатное нагрузочное тестирование просто недостаточно мощное для их нужд.

Инструменты для нагрузочного тестирования предприятий

Корпоративные инструменты тестирования — это платные продукты, разработанные для нужд крупных и сложных организаций. Часто они основаны на подписке, а цены зависят от количества симулируемых пользователей и других особенностей тестирования.

На выбор предлагается множество компаний, занимающихся нагрузочным тестированием, но ведущим предприятием является ZAPTEST, лидер в области гиперавтоматизации, ZAPTEST известен как один из лучших инструментов нагрузочного тестирования благодаря удобному программному обеспечению и неограниченному доступу к поддержке.

Качество и возможности, предлагаемые компаниями, занимающимися нагрузочным тестированием предприятий, могут значительно отличаться, поэтому организациям рекомендуется тщательно изучить каждого поставщика, прежде чем подписываться на услуги.

Преимущества инструментов корпоративного тестирования

Хотя конкретные функции и простота работы зависят от конкретного продукта, лучшие инструменты нагрузочного тестирования имеют следующие преимущества.

1. Простота использования

Программное обеспечение с открытым исходным кодом может иметь запутанный пользовательский интерфейс, сложные процессы и общее безразличие к пользователю. Однако в корпоративных инструментах особое внимание уделяется интуитивно понятному, простому опыту.

2. Поддержка клиентов

Основным преимуществом корпоративного тестирования является наличие квалифицированной поддержки. Специалисты, обученные не только нагрузочному тестированию, но и специфике работы принадлежащего вам нагрузочного тестера, готовы помочь решить любые проблемы. В корпоративной службе поддержки вы сможете обращаться в службу поддержки 24 часа в сутки 7 дней в неделю.

3. Надежность

Корпоративные инструменты тестирования предназначены для поддержки компаний с крупномасштабными операциями, где любой простой может привести к значительной потере доходов и удовлетворенности клиентов. Эти инструменты предназначены для предоставления точных данных, пригодных для долгосрочного планирования и принятия решений.

Ограничения инструментов корпоративного тестирования

Хотя инструменты корпоративного тестирования имеют множество преимуществ по сравнению с другими типами, они также содержат некоторые потенциальные ограничения.

1. Стоимость

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

В конечном итоге, устранение узких мест и предотвращение простоев приложений делает нагрузочное тестирование более экономически эффективным вариантом с течением времени, но организация все равно может понести значительные первоначальные затраты. В отличие от них, известные комплекты нагрузочного тестирования, такие как ZAPTEST, предлагают подписку на ПО+услуги по фиксированной стоимости с неограниченным использованием и лицензиями… эта модель позволяет снизить постоянно растущие расходы на тестирование по мере расширения компании.

2. Кривая обучения

Хотя корпоративные инструменты, безусловно, являются наиболее удобным вариантом нагрузочного тестирования, даже самые лучшие инструменты нагрузочного тестирования имеют, по крайней мере, некоторую кривую обучения. Члены команды, в идеале те, кто имеет опыт кодирования, должны будут потратить время на изучение того, как максимально эффективно использовать этот инструмент. И снова, ведущие инструменты нагрузочного тестирования, такие как ZAPTEST, смягчают этот недостаток, предоставляя платформу с низким кодом, которая не требует навыков кодирования и может использоваться большинством людей в организациях, а не только разработчиками.

Когда следует использовать корпоративные и бесплатные инструменты нагрузочного тестирования?

Бесплатные инструменты нагрузочного тестирования имеют свое место во многих организациях. Они являются наиболее экономичным вариантом, что делает их популярными среди стартапов и других предприятий с ограниченными ресурсами.

Бесплатные инструменты также являются эффективным способом повышения квалификации человека. Например, тестировщик может провести нагрузочный тест SoapUI не только для проверки системы, но и для улучшения своего понимания инструмента с открытым исходным кодом.

Для большинства коммерческих приложений и крупных организаций лучшими инструментами нагрузочного тестирования являются продукты корпоративного уровня, такие как ZAPTEST и аналогичные лидеры отрасли. Они обеспечивают надежность, точность и безопасность, которые защищают как вашу компанию, так и конечных пользователей. Кроме того, они гораздо проще в использовании, чем бесплатные инструменты, и обеспечивают непревзойденный уровень функциональности.

Контрольный список нагрузочного тестирования

Одним из важнейших ключей к успешному нагрузочному тестированию является организация. Многие компании обнаружили, что проведение тестирования с использованием контрольного списка помогает командам не отвлекаться от работы. Следующий контрольный список хорошо подходит в качестве отправной точки для организаций корпоративного уровня.

1. Веб-сервер

• Достаточно ли у вас пропускной способности для предотвращения образования узких мест?
• Может ли система обрабатывать достаточное количество транзакций в секунду?
• Достаточно ли у вас веб-серверов, чтобы справиться с загруженными и простаивающими угрозами?

2. Хозяин

• Есть ли у сетевых интерфейсов проблемы с процессором, памятью или дисковым пространством?
• Какие процессы выполняются на хосте?

3. Сервер приложений

• Какое использование ЦП необходимо для каждого уровня нагрузки?
• Утечка памяти в системе при различных уровнях нагрузки?
• Правильно ли серверы приложений распределяют нагрузку?

Хотя вы захотите изменить контрольный список в соответствии с конкретными потребностями вашей организации, эти основные элементы помогут вам охватить важнейшие аспекты производительности и работы системы.

Заключение

Нагрузочное тестирование играет важную роль в успехе любого проекта по разработке программного обеспечения. Чтобы по-настоящему использовать возможности средств автоматизации нагрузочного тестирования, организациям следует наладить партнерство с компанией по нагрузочному тестированию корпоративного уровня, такой как ZAPTEST.

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

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

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

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

Что такое нагрузочное тестирование?

Нагрузочное тестирование проводится для проверки того, что система/приложение может обрабатывать ожидаемое количество транзакций, а также для проверки поведения системы/приложения в условиях нормальной и пиковой нагрузки (количество пользователей).

Нагрузочное тестирование — это подмножество производительности. Тестирование и является типом нефункционального тестирования.

Подробнее: более 100 типов тестирования программного обеспечения

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

Мы проводим нагрузочные тесты, чтобы определить общее поведение системы, задержку и пропускную способность.

Нагрузочное тестирование определяет, как система ведет себя при доступе нескольких пользователей
Чтобы получить приемлемое время отклика приложения, все три команды (бизнес , проектирование и эксплуатация) должны быть согласованы заранее.

Мы знаем, что многие пользователи покидают приложение, когда время отклика превышает 2 секунды. Таким образом, группа бизнес-анализа должна сначала проанализировать время отклика приложения. Если время отклика превышает 2 секунды, команда инженеров должна оптимизировать производительность, а группа эксплуатации должна подготовиться с необходимыми ресурсами. Если системных ресурсов недостаточно, приложение останавливается.

Примеры нагрузочного тестирования:

Некоторые основные примеры нагрузочного тестирования:

• Тестирование веб-сайта путем загрузки серии больших файлов из приложения
• Тестирование сервера путем одновременного запуска нескольких приложений на сервере
• Тестирование принтера путем одновременного назначения принтеру большого количества заданий в очереди на печать
• Тестирование жесткого диска путем непрерывной записи и чтения данных
• Тестирование почтового сервера с тысячами одновременных пользователей

Почему важно нагрузочное тестирование?

Нагрузочное тестирование важно, потому что оно отвечает на некоторые ключевые вопросы производительности и дает уверенность в системе.

• Чтобы определить, соответствуют ли существующие ресурсов (инфраструктуры), которые у нас есть, достаточно или нет, чтобы справляться с ожидаемой и пиковой нагрузкой.
• Чтобы определить узкие места в приложении
• Чтобы выяснить, как наша система работает под нагрузкой
• Чтобы определить, сколько одновременных пользователей может обрабатывать приложение
• Чтобы определить, может ли наше приложение масштабироваться
• Чтобы определить, на каком уровне загрузить наше приложение может сломаться
• Чтобы найти максимальную рабочую мощность приложения
• Чтобы смоделировать реальные пользовательские сценарии. С точки зрения того, как он будет работать, когда сотни, тысячи или даже миллионы пользователей посетят его в режиме реального времени.
• Чтобы сэкономить деньги и получить доход

Важность нагрузочного тестирования — примеры

Возьмем, к примеру, один из самых больших дней продаж Amazon (Prime Day) в Июль 2018 г. Не удалось защитить достаточно серверов, чтобы справиться с всплеском трафика в Prime Day, который произошел в течение 15 минут после начала Prime Day. Один час простоя Amazon в Prime Day может стоить компании от 72 до 99 миллионов долларов упущенных продаж

Нью-Йоркская фондовая биржа внезапно закрылась и не возобновляла торги более 3 часов в 2018 году. Было сказано, что сбой был вызван технической «проблемой с конфигурацией».

Рейсы United Airlines в США были остановлены более чем на час из-за «проблем с автоматизацией». Авиакомпания опубликовала заявление, в котором говорится, что из-за проблем с подключением к сети рейсы не выполняются. Это приводит к потере дохода и доли рынка.

Как проводить нагрузочное тестирование

Процесс нагрузочного тестирования включает следующие этапы.

• Настройка тестовой среды. Первым шагом является создание специальной тестовой среды для нагрузочного тестирования. Тестовая среда должна быть такой же, как и производственная.
• Определение критериев производительности. На этом этапе мы должны определить такие критерии, как допустимые ограничения времени отклика, пропускной способности и загрузки ЦП
• .Определение нагрузочных тестов. На этом этапе мы определяем нагрузочные тесты, такие как подготовка тестовых данных для каждой транзакции, прогнозирование количества пользователей, обращающихся к системе, определение скорости соединения, различных браузеров и операционных систем, настройка серверов.
• Виртуальный Настройка пользователей — создание задач, выполняемых виртуальными пользователями.
• Создание, выполнение и мониторинг сценариев тестирования
• Анализ результатов тестирования и выработка рекомендаций — анализ узких мест производительности на основе отчетов и предоставление рекомендаций по их устранению< li>Точная настройка системы и повторное тестирование сценариев для преодоления всех узких мест

Преимущества и недостатки нагрузочного тестирования:

Преимущества нагрузочного тестирования:

• Выявление узких мест в производительности перед выводом приложения на рынок.
• Повысить масштабируемость системы с точки зрения ресурсов, таких как программное обеспечение, база данных, сети и т. д.
• Свести к минимуму риск простоя системы.
• Повышение удовлетворенности конечных пользователей.
• Снижение стоимости отказа. .

Недостатки нагрузочного тестирования:

• Большинство инструментов нагрузочного тестирования, доступных на рынке, лицензированы и стоят дорого, поскольку цена зависит от количества виртуальных пользователей.
• Тестерам необходимо изучить язык, поддерживаемый инструментом нагрузочного тестирования, чтобы создавать тестовые сценарии.

< h3>Разница между нагрузочным тестированием и стресс-тестированием (нагрузочное тестирование и стресс-тестирование)

НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ	НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ
Это подмножество тестирования производительности	Это подмножество тестирования производительности
Целью нагрузочного тестирования является определение ограничить систему, установить SLA приложения и проверить, как система справляется с большой нагрузкой	Цель стресс-тестирования — выяснить, как система ведет себя при экстремальных нагрузках и как она восстанавливается после сбоя
Ограничение нагрузки – это порог обрыва	Ограничение нагрузки выше порога перерыва
Атрибуты, которые проверяются при нагрузочном тестировании: пиковая производительность, пропускная способность сервера, время отклика при различных уровнях нагрузки , требования к балансировке нагрузки и т. д.	Атрибуты, которые проверяются при стресс-тестировании, – это стабильность, время отклика, пропускная способность и т. д.,
Нагрузочное тестирование выполняется для проверки производительности системы при экстремальной нагрузке.	Стресс-тестирование выполняется для проверки устойчивости системы при экстремальной нагрузке.
Это помогает нам понять, как система ведет себя при ожидаемой нагрузке.	Это помогает нам понять, как система ведет себя при экстремальной нагрузке, превышающей ожидаемую мощность.
Здесь тестовыми данными будет огромное количество пользователей .	Здесь тестовыми данными будет огромное количество пользователей и огромный объем данных.
Используется для определения верхнего предела емкости системы.	Используется для определения производительности и возможности восстановления системы, когда она подвергается нагрузке, превышающей верхний предел емкости системы. .
Нагрузочные тесты помогают тестировщику определить узкое место, а также понять основную причину таких проблем.	Стресс-тесты помогают тестировщику выявлять утечки памяти, замедления работы, проблемы безопасности и повреждение данных.

< strong>Какие популярные инструменты нагрузочного тестирования используются для нагрузочного тестирования?

На рынке существует множество инструментов для нагрузочного тестирования. Мы можем выбрать наш любимый инструмент из бесплатных инструментов нагрузочного тестирования веб-сайтов, платных инструментов и бесплатных инструментов в зависимости от наших потребностей. Почти все коммерческие инструменты тестирования производительности имеют бесплатную пробную версию. Вы можете получить возможность поработать на практике, прежде чем решить, какой инструмент лучше всего подходит для ваших нужд.

Некоторые из инструментов: LoadRunner, Apache JMeter, WebLOAD, LoadView и Loadrunner.

Полный список инструментов нагрузочного тестирования, доступных на рынке, см. в нашей статье о лучших инструментах нагрузочного тестирования.

Посмотрите наш полный список популярных инструментов нагрузочного тестирования.

Вывод:

Нагрузочное тестирование проверяет потенциальные ограничения производительности приложения. Успешное нагрузочное тестирование направлено на создание качественных приложений, которые могут обслуживать большое количество пользователей.
TAG: qa

Всем привет!

Меня зовут Дмитрий Винокуров и я работаю инженером по нагрузочному тестированию в Miro. Я хочу рассказать о личном опыте и опыте нашей команды в развитии направления нагрузочного тестирования (для краткости НТ). В статье я расскажу самые основы НТ, как на эти основы ложится наш процесс и на какие конкретные шаги он делится. Наш опыт местами может быть специфическим, но по большей части он будет применим ко многим компаниям, разрабатывающим веб-приложения и не только.

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

Описываемый подход основывается на нашем опыте и множестве просмотренных и прочитанных материалов. Подобный доклад делался на конференции DUMP в Екатеринбурге 14 мая 2021 г., эта статья представляет собой значительно дополненный и переработанный вариант выступления.

Автор арта на «обложке» — Orest Terremoto.

Содержание

1. О Miro и об авторе
2. Что такое нагрузочное тестирование?
3. Что нужно для нагрузочного тестирования?
4. Этапы нагрузочного тестирования
5. С чего начинали нагрузочное тестирование в Miro
6. С какими препятствиями столкнулись при развитии нагрузочного тестирования в Miro
7. Роли, которые в Miro решили воспитывать в инженерах команды нагрузочного тестирования
8. Некоторые общие принципы работы QA в Miro
9. Распределённая команда нагрузочного тестирования в Miro
10. Процесс нагрузочного тестирования в Miro
    1. Детализация требований
    2. Подготовка тестового окружения
    3. Подготовка сценария
    4. Запуск теста и измерения
    5. Анализ
    6. Отчёт
11. Результаты внедрения нагрузочного тестирования в Miro
12. Планы в отношении нагрузочного тестирования в Miro
13. Пожелания читателям
14. Полезные ссылки

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

Цель Miro — дать возможность распределённым командам работать так эффективно, как будто они находятся в одном помещении.

Что особенно важно относительно темы статьи — Miro поддерживает совместную работу в реальном времени большого числа пользователей, в этом самая основа нашей платформы. Это причина, почему нам особенно нужно нагрузочное тестирование. Когда люди собираются у одной оффлайн доски в офисе — они не испытывают никаких задержек в коммуникации и в работе с доской, так же и у нас, только в намного больших масштабах.

В прошлом году внезапно множество людей перешло на удалёнку по известным причинам и им понадобились инструменты для удалённой работы, подобные нашему. Количество зарегистрированных пользователей в Miro с начала 2020 до весны 2021 выросло в 8 раз, другие метрики росли схожим образом. Поэтому нам понадобилось срочно развивать все имеющиеся наработки по нагрузочному тестированию. Причём это не краткосрочная задача, а, учитывая перспективы рынка, весьма долгоиграющая. Что получилось и что ещё предстоит — об этом и будет статья.

Сам я уже около 12 лет занимаюсь разработкой ПО и последние несколько лет — разработкой инструментов автоматизации тестирования. Ещё я активно участвую в работе над публичной базой знаний по НТ вместе с соответствующим сообществом, ссылки про это и многое другое будут в конце статьи.

Что такое нагрузочное тестирование?

Нагрузочное тестирование — это тип тестирования, в котором мы проверяем, соответствует ли наша система поставленным нефункциональным требованиям к производительности при работе под высокой нагрузкой в различных сценариях. Это намного сложнее, чем unit тестирование, где всё просто работает или нет. При нагрузочном тестировании снимается целый ряд метрик, и даже задача проверки на соответствие требованиям уже является непростой. Существенные трудности состоят также в том, как воспроизвести поведение пользователей с прода, как воспроизвести сам прод, в том числе базу, и как поставить тестирование так, чтобы ручная работа была минимальной.

Тестирование вообще — это способ узнать об ошибках не от конечных пользователей, а раньше, и тем самым избежать потерь, репутационных и прочих. Нагрузочное тестирование — это способ подготовиться к высоким нагрузкам заранее и сделать так, чтобы большое число запросов от множества пользователей было благом, а не головной болью. Причин для бурного роста может быть множество и отказываться от подготовки к таким сценариям значит существенно повышать риск выхода из строя вашей системы в тот момент, когда она стала особенно нужна людям.

Что нужно для нагрузочного тестирования?

Итак, мы определились, НТ нам нужно, теперь перед его проведением необходимо наличие ряда ресурсов:

1. Общие требования. Нам нужно понимать, чего мы ожидаем от нашей системы в контексте нагрузки и производительности, хотя бы в общих чертах. Это может звучать просто, но не всегда у людей есть ясное представление о таких требованиях. «Система должна отвечать быстро под высокой нагрузкой» — это не требование, это пожелание. Я покажу примеры удачнее дальше в статье.
2. Специалисты. Для проведения НТ нужны инженеры. Поскольку серьёзное тестирование всегда требует автоматизации, нужны инженеры с навыками тестирования и разработки, а также аналитики и девопсы.
3. Платформа для тестового окружения. Если вы делаете НТ в первый раз — вам определённо понадобится подготовить инфраструктуру. Хорошо если у вас внедрён подход IaC (англ. infrastructure as a code, инфраструктура как код), он очень пригодится для создания окружения, подобного проду. Если нет — надо внедрять или придётся страдать даже на небольших конфигурациях. И в подавляющем большинстве случаев тестирование на проде — плохая идея. Но есть и исключения, можете погуглить «Netflix testing in production».
4. Время. НТ — это очень затратный по времени процесс, особенно когда вы делаете его впервые. Автоматизация экономит много времени, но всё равно нужно быть готовым потратить на подготовку и проведение НТ несколько дней или существенно больше, зависит от масштабов прода, используемого стэка, сценариев использования и поставленных задач.

Этапы нагрузочного тестирования

Мы собрали то, что необходимо для НТ. Перейдём к плану действий.

1. Детализация требований — что требуется от системы в терминах нагрузки и производительности, какой тип теста проводим и какие метрики необходимо собрать для проверки требований. Как я писал ранее, общие требования нужны ещё до тестирования, а когда процесс начат, нужно их декомпозировать в предельно конкретные и технические требования. Также нужно выбрать тип теста, реализуемого в тестовом сценарии, и составить список метрик, на сбор которых нужно настроить приложение, сценарий и инфраструктуру. Это аналитическая задача.
2. Подготовка тестового окружения — где будем моделировать прод и пользователей. Необходимо выбрать одно из доступных или создать новое тестовое окружение под разработанные требования и настроить сбор метрик, нужных для оценки степени соответствия требованиям. Это задача DevOps специалистов.
3. Выбор инструмента тестирования и подготовка сценария — как будем моделировать поведение пользователей. В сценарии тоже нужно запрограммировать сбор метрик. Это задача разработки.
4. Проведение теста и замеры — каковы значения метрик. Это может звучать просто, но весьма редко всё работает с первого раза. Бывает нужно откатиться на один из предыдущих шагов и что-то поправить. На данном этапе проводится анализ некоторых ключевых показателей, чтобы убедиться, что нет критических ошибок теста. Этот шаг — задача тестирования. Основная работа по анализу будет вестись на следующем этапе.
5. Анализ — соответствует ли система требованиям, есть ли проблемы. Если собираются правильные метрики, всё должно быть относительно просто, хотя и трудоёмко, а если нет — опять может понадобиться откатиться вплоть до первого шага. Здесь, в отличие от предыдущего шага, мы глубоко погружаемся в большое количество метрик чтобы выявить все возможные значимые факты. Это аналитическая задача.
6. Подготовка отчёта — какие знания мы получили?.. Это самый важный этап. НТ — процесс очень затратный по ресурсам и вы явно захотите получить максимум знаний от него. Снова аналитическая задача.

Есть ещё один этап, опциональный — план улучшения системы, то есть ответ на вопрос «как можно исправить обнаруженные недостатки?». Это не относится напрямую к нагрузочному тестированию, но упомянуто здесь, потому что результаты НТ в большинстве случаев должны быть «actionable», побуждать к действиям. Как видно из списка выше, нужны разные роли для проведения всего процесса НТ и эти роли должны сочетать в себе или одни люди, или нужно привлекать разных специалистов.

С чего начинали нагрузочное тестирование в Miro

К росту нагрузки мы начали готовиться задолго до пандемии и вот что у нас было:

1. Несколько человек занимались НТ часть своего времени.
2. Мы использовали JMeter как наиболее популярное решение. У нас был свой плагин для WebSocket, так как ключевой функционал Miro связан с работой с досками и требует очень быстрого клиент-серверного взаимодействия, как в играх. Кстати движок, с которого много лет назад начинала компания, был как раз игровым. Это с самого начала дало высокую интерактивность и скорость отклика.
3. Наш кластер был prod-like. К счастью, у нас был IaC. Нельзя сказать, что IaC — это серебряная пуля, сложности с ним тоже есть, но без него сложности с ростом масштаба становятся фатальными препятствиями.
4. Один достаточно объёмный и сложный WebSocket&HTTP API тест.

Ссылки на подробности про предыдущие наработки и многое другое будут в конце статьи.

С какими препятствиями столкнулись при развитии нагрузочного тестирования в Miro

НТ, особенно для сложной системы, — задача непростая. Чем глубже мои коллеги погружались в неё, тем больше возникало сложностей.

Технические препятствия:

1. JMeter перестал нас устраивать. В нём было очень неудобно программировать и отлаживать. Сложные сценарии — это почти всегда разработка, а не заполнение форм или написание отдельных небольших скриптов. Сценарий в JMeter — это не программа в обычном понимании, а сочетание инструкций, заполненных в формах, с встроенным кодом скриптов. Также в JMeter плохо с контролем версий, т.к. сценарий хранится в огромном XML. А у нас большое количество WebSocket взаимодействия со своим бинарным протоколом и достаточно сложные сценарии, над которыми работает несколько человек. Не хотелось изобретать обходные пути вокруг «особенностей» JMeter.
2. Много ручных действий для каждого запуска НТ на тестовом окружении. TODO лист состоял из 16 пунктов для каждого запуска, которые надо было проделывать вручную… И это была боль… А боль — это сильный стимул что-то поменять.
3. Не хватало инструментов для генерации разных распределений тестовых данных. А сценарии тестирования для разных компонентов возможны разные и нужно было уметь быстро создать нужное распределение. Идеально использовать базу максимально близкую проду и откатывать после каждого теста, но не всегда это возможно: это могут быть огромные объёмы и надо чистить сенситивные данные пользователей, а воспроизводить синтетические данные в нужном объёме — тоже сложная задача.

Организационные препятствия:

1. Много задач.
2. Недостаточно опыта.
3. Недостаточно доступных людей.

Роли, которые в Miro решили воспитывать в инженерах команды нагрузочного тестирования

Итак, мы столкнулись с рядом трудностей в проведении НТ и конечно можно было подумать «а давайте просто наймём больше QA инженеров» и действительно надо было нанимать людей специально для НТ, но вопрос на самом деле шире. QA инженеров нанять недостаточно, учитывая сложность этого направления необходимо было строить многопрофильную команду. Причём часть ролей отводилась будущим сотрудникам, а часть — имеющимся.

Так почему нам было недостаточно просто QA? Главная причина — прогнозируемый уровень сложности задач по НТ. У нас несколько десятков команд, все разрабатывают компоненты, которые должны работать в соответствии с требованиями по производительности в составе сложной системы. Но у каждой компании свой масштаб разрабатываемых систем. Кому-то может хватить просто одного человека, который умеет в JMeter, и может даже особо большого кластера для подачи нагрузки не понадобится. Кому-то нужно будет значительно больше, чем надо было нам. Всё зависит от уровня сложности системы.

С ростом скорее всего происходит более узкая специализация, но у нас для инженеров НТ было решено развивать следующие роли:

1. QA. Должен уметь искать проблемные места и выстраивать процесс обеспечения качества.
2. Аналитик. Должен уметь выявлять причинно-следственные связи, исследовать паттерны поведения пользователей и разбираться в сложных системах.
3. Разработчик. Должен уметь проектировать и программировать средства автоматизации и тестовые сценарии.
4. Преподаватель*. Должен уметь помогать учиться специалистам из других команд и готовить базу знаний, причём здесь речь не только про документацию.
5. DevOps*. Должен ориентироваться в архитектуре тестового окружения и уметь её модифицировать.

* 4-я и 5-я роли только для участников «центра» НТ команды, а не для всех НТ инженеров, о конкретной структуре я расскажу чуть позже.

Некоторые общие принципы работы QA в Miro

В нашей компании есть QA гильдия, объединяющая QA инженеров из разных функциональных команд и инженеров, разрабатывающих и отвечающих за общие инструменты обеспечения качества. И раз НТ у нас — это часть QA, а для QA уже были сформулированы и применялись ряд принципов, то и к НТ они были применены.

Вот ключевые из этих принципов:

1. Ответственность за качество лежит на всей команде. Не только на QA инженерах.
2. Тесты всех уровней пишут QA и разработчики. Чтобы не было пинг-понга «сделал-проверь-поправь-проверь-поправь-проверь-вроденорм».
3. Минимизация эффекта «единой точки отказа». Чтобы не было так, что QA в отпуске, а критичные баги просочились на прод.
4. Главный фокус QA инженеров — построение процесса разработки с точки зрения качества. Не столько искать ошибки, сколько предотвращать. Уровень задач становится выше, чем просто тестирование.

Распределённая команда нагрузочного тестирования в Miro

Если ранее я рассказывал об опыте коллег, то в описываемом далее я принимал уже непосредственное участие. В компанию вместе со мной были взяты люди, которые занимались уже только НТ. И вот какую команду мы строили и какими задачами занимались.

1. «Центр» — команда НТ — центр компетенций и поддержки. Зоны ответственности:
   1. Разработка инструментария (особое внимание к качеству!). У функциональных команд заказчик — клиенты Miro, у нашей команды заказчик — функциональные команды. Внутренние инструменты не должны быть поделками, сделанными «на коленке». Это должны быть полноценные и качественные продукты с должным уровнем поддержки всех видов. Функциональные команды и так загружены и повышать их уровень стресса плохими инструментами — недопустимо. Поэтому у нас есть:
      1. Мастер-классы.
      2. Miro доски-презентации.
      3. Confluence документация.
      4. Версии, changelog, детальная отладочная информация в ходе работы инструмента.
      5. Общий репозиторий с примерами кода и всеми НТ сценариями, чтобы было единое место, где собрана вся практика НТ.
      6. Отдельные чаты на каждый инструмент для поддержки, сообщений о релизах, багрепортов и фичереквестов.
   2. Помощь в обучении и консультирование коллег из функциональных команд, не только QA инженеров.
   3. Проведение больших тестов, когда нужна проверка суммы функционала от множества команд.
   4. Поддержка тестовых окружений совместно с QA Automation Team и DevOps Team.
2. «Агенты» — QA инженеры и разработчики в функциональных командах — проводят более узконаправленные тесты.

Процесс нагрузочного тестирования в Miro

Шаг 1/6. Детализация требований

Мы рассмотрели, что такое НТ и посмотрели на то, как устроена распределённая команда НТ в Miro. Теперь пройдёмся по этапам НТ, наложенным на наш процесс. Начнём с самого важного этапа.

Ещё раз подчеркну, что к формулировке требований стоит подойти особенно ответственно. Без чёткого понимания, чего вы хотите от тестируемого приложения, дальше двигаться нельзя.

Источники требований

1. OKR, цели и ключевые результаты. Часть из них может относиться к поддерживаемой нагрузке и производительности для всех многопользовательских систем.
2. Соглашения о качестве работы системы. Все, кто работают с клиентами, должны обеспечивать определённый уровень качества, формально описанный или неформально принятый. И это лучшее место для спецификации таких нефункциональных требований, как требования по производительности.
3. Аналитика сайта. Нужна не напрямую для формулировки требований, а для определения текущего профиля использования, который может служить основанием для сценария воспроизведения поведения пользователей и как основа для прогнозов.
4. Пользовательские сценарии. Мы должны понимать, как наши клиенты используют нашу систему, чтобы понимать, каким частям системы уделить внимание.
5. Прогнозы. Мы должны примерно представлять, что будет в будущем с показателями использования системы и всегда иметь запас прочности.
6. Знания и опыт продакт-менеджеров. Не всегда всё нужное зафиксировано в документах и мониторинге.

Остановлюсь подробнее на паре используемых нами инструментов:

1. Looker — инструмент для сбора и анализа бизнес-показателей. Мы сформулировали требования, далее в ходе составления сценария в большинстве случаев нам нужно опираться на множество текущих показателей работы прода. Здесь могут помочь такие бизнес-показатели, как данные о том, какой диапазон размера досок используется каким количеством пользователей.
2. Grafana — примерно то же самое, но для системных метрик. Например, мы хотим проверить требование «Miro должен держать 500К онлайн пользователей с такими-то показателями скорости ответа по критичным компонентам». Чтобы смоделировать это, нужно знать, как при существующем уровне нагрузки используется сайт, какими функциями и с какой частотой пользуются клиенты, чтобы в итоге перевести абстрактных «500К пользователей» в RPS по основных типам запросов. В получении RPS как раз помогает Grafana.

Выбор модели нагрузки

Различают две модели нагрузки:

1. Закрытая. В генераторе нагрузки есть очередь определённого размера: если она заполнена и ответы от сервера ещё не пришли, то новые запросы не отправляются до тех пор, пока не поступят ответы на старые запросы. Серверу стало плохо? Подождём, пусть разгребёт.
2. Открытая. Генератор нагрузки отправляет запросы, не дожидаясь ответов сервера и не обращая внимания на его состояние. Серверу стало плохо? Это его проблемы, жизнь такая, продолжаем грузить.

Подробнее по отличиям этих моделей нагрузки и про сценарии использования каждой можно посмотреть в видео из школы Яндекса — «Нагрузочное тестирование типичного интернет-сервиса» от Андрея Похилько.

Выбор типа теста

Для разных требований нужны разные тесты. Вот основные примеры типов тестов:

1. Smoke-тесты — проверка всех составляющих НТ на малом масштабе.
2. Тесты на базовый уровень — снимаем текущие метрики работы системы.
3. Тесты на объём — выдержит ли система повышенную нагрузку при «нормальном» сценарии использования?
4. Тесты на лимиты — до какого уровня можно грузить систему, прежде чем она начнёт деградировать?
5. Тесты на стабильность — как долго система сможет держать определённый уровень нагрузки?
6. Тесты на масштабируемость — ведёт ли добавление новых серверов к поддержке большего числа запросов?
7. Тесты на пиковые нагрузки — выдержит ли система резкое повышение нагрузки?
8. Тесты на восстанавливаемость — достаточно ли быстро система восстанавливается после сбоя?
9. Тесты на взаимодействие — эффективно ли взаимодействуют компоненты системы?
10. Деградационные тесты — один или несколько тестов, описанных ранее, запускаются автоматизированно и регулярно, с построением отчётов с отображением динамики за длительный период.

Эти тесты могут быть совмещены и не все могут быть нужны.

Декомпозиция требований

«Cистема должна отвечать быстро при высокой нагрузке» – это плохое требование, слишком расплывчатое и оставляющее больше вопросов, чем определённости в том, как его проверять.

Более конкретное требование — «система должна обеспечивать столь же комфортный опыт использования как сейчас при росте нагрузке в X3 пользователей». Здесь указано, что такое «высокая нагрузка» — указано «X3 пользователей» и указано что опыт работы с системой должны быть «столь же комфортным как сейчас». Здесь есть на что опираться — на текущие показатели работы с системой.

Детализация означает конвертацию пользователей в RPS, основываясь на существующем и ожидаемом профилях использования. Такая конвертация уместна только для Stateless протоколов, как самые распространённые HTTP и HTTP, а для Stateful число подключенных клиентов может быть очень важно, как например для FTP, протокола работы с MySQL или некоторых банковских протоколов. Ещё один важный момент — не доверяйте средним значениям времён ответа, используйте персентили, т.к. среднее зачастую является плохой метрикой.

Вот примеры конкретных требований, которые могли быть получены из высокоуровнего и других источников данных:

1. RT1. Запрос типа #1 при нагрузке X1 RPS должен иметь p(50) в A1 ms, p(95) в B1 ms …
2. RT2. Запрос типа #2 при нагрузке X2 RPS должен иметь p(50) в A2 ms, p(95) в B2 ms …
3. …
4. ER1. Процент ошибок для критичных сервисов не должен превышать N%
5. ER2. Процент ошибок для некритичных сервисов не должен превышать M%
6. …
7. IS1. Нагрузка CPU не должна превышать P%
8. IS2. Система должна иметь резерв для обработки +10% нагрузки
9. …

Метрики

Есть очень хорошая книга по SRE от Google, где среди прочего описаны «4 золотых сигнала»:

1. Время ответа. Именно то, что заметит пользователь.
2. Трафик. RPS, число запросов в секунду, всё просто.
3. Ошибки. Об их максимально допустимом проценте могут быть свои требования.
4. Насыщение. Если даже требования по остальным показателям выполняются, но при этом сервера загружены по полной — это должно наводить на соответствующие выводы. Всегда нужно иметь запас.

И даже если попытаться, сложно придумать другие необходимые категории метрик. Все 4 необходимы и достаточны.

Естественно, метрики всех четырёх типов тесно взаимосвязаны. Повышение трафика и соответственно насыщения со временем приведёт к росту времени ответа и ошибок. Резко упавшее время ответа может говорить о том, что у нас отказала БД и время ответа упало из-за того, что все запросы просто быстро завершаются с ошибкой.

Некоторые добавляют и другие показатели. Например, стабильность, которая показывает как долго система может работать без остановки и как быстро восстанавливается после проблем. Это сложный показатель и скорее его стоит отнести не к типам метрик, а к выводу отчёта после целого теста на стабильность. Подобная ситуация с доступностью и масштабируемостью. Есть ещё понятие критического ресурса, как компонента, от которого сильнее всего зависит качество работы всей системы.

APDEX

Индекс производительности приложений Application Performance inDEX (APDEX) может быть использован для преобразования ряда времён ответов в одно число, если определены диапазоны удовлетворительных, допустимых и недопустимых времён.

Значения APDEX легки в сравнении, но тяжелы в интерпретации.

Шаг 2/6. Подготовка тестового окружения

Сценарий готов, далее нужно подготовить целевую систему, которую тестовый сценарий будет проверять.

Тестовое окружение состоит из двух частей:

1. Целевая система (имитация прода).
2. Кластер подачи нагрузки (имитация пользователей).

Для их реализации у нас используются:

1. IaC
   1. AWS. Когда счёт используемых серверов идёт на десятки и сотни, без автоматизации никак. У нас был давно принят выбор перейти от арендованного железа в облако. Вопрос выбора конкретного провайдера (AWS, Google Cloud, Microsoft Azure) — тема отдельного доклада. Я лишь скажу, что в своих инструментах я активно использую AWS API и это на самом деле удобно, не знаю как можно было бы жить без этого или аналогичного инструмента.
   2. Terraform, Terragrunt (дефакто стандарт для IaC)
   3. Ansible. Систем управления конфигурациями много и многие по-своему хороши, тут надо девопсов спрашивать почему Ansible, хотя мне как в основном Python-разработчику нравится этот выбор
2. Свой управляющий инструмент (консольная Python утилита с множеством команд, опций и конфигом), который выполняется в части подготовки тестового окружения (он же ещё используется при запуске сценария)
   1. Запуск кластеров целевой системы и подачи нагрузки.
   2. Деплой версий и запуск приложений на серверах приложений.
   3. Создание серверов подачи нагрузки.

Шаг 3/6. Подготовка сценария

Мы определились с тем, что требуется от системы и как пользователи с ней работают, теперь это поведение нужно смоделировать в тестовом сценарии.

Эскиз на человеческом языке

Перед началом разработки хорошей практикой является создание эскиза сценария на «человеческом языке». Это поможет выразить, какое поведение пользователей планируется моделировать без траты времени на погружение в детали инструментов НТ. И инструмент тоже поможет подобрать, если такой вопрос стоит. А ещё, при составлении отчёта, такой эскиз поможет ревьюерам понять моделируемое поведение пользователей, не погружаясь в код.

Как было показано ранее, на этапе детализации требований мы разделяем активность пользователей на отдельные RPS. Иногда бывает нужно ещё объединять запросы в подобие подсценария.

Вот пример такого эскиза сценария:

1. Подсценарий #1 — получение уведомлений (X RPS)
2. Подсценарий #2 — получение статуса серверов (Y RPS)
3. Подсценарий #3 (Z SPS)
   1. Логин
   2. Открытие дэшбоарда
   3. Открытие доски с W1 виджетов для U1 доли пользователей, W2 для U2 и так далее
   4. Движение курсором
   5. Добавление нескольких виджетов
   6. Закрытие доски

Выбор инструмента

В данный момент у нас используется три инструмента для НТ:

1. Свой инструмент для моделирования работы с досками.
2. k6. Для него мы в своём управляющем инструменте реализовали обёртку для кластерного запуска и сбора результатов.
3. JMeter (legacy, практически не используется).

Вообще говоря, с инструментами НТ вопрос сложный. Их множество и коллегами был проведён детальный разбор наиболее популярных, чтобы понять, что сможет справиться в первую очередь с ключевым функционалом Miro — работой с досками. У нас используется бинарный протокол, работающий через WebSocket, требуемый для высокой скорости работы с досками. Основы, необходимой для его реализации, не было найдено и между доработкой какого-то из имеющихся решений и разработкой собственного узкоспециализированного решения выбор был в пользу второго варианта, разработки своего инструмента. Насчёт остальных направлений НТ и выбора инструментов — мы решили не ограничивать команды, а реализовывать поддержку в нашем управляющем инструменте для каждого инструмента, который коллегам показался подходящим. Под управляющим инструментом я имею ввиду средство управления тестовой средой и запуска НТ, об этом будет позже. Интеграция в него дополнительного инструмента НТ — задача в принципе несложная, поэтому мы можем позволить командам пользоваться тем, чем им мы удобно. Так, например, несколько человек экспериментируют с Locust. А мы наблюдаем за успешностью использования инструментов и на базе этого формируем проверенные практикой советы по выбору инструмента НТ для тех, кто только начинает этим заниматься.

Исследование

Ещё один шаг перед написанием кода — исследование того, как реальный фронтенд взаимодействует с бэкендом с помощью инструментов разработчика в браузере и попробовать несколько простых взаимодействий вручную, например через Postman.

Но иногда проще начать сразу с кода.

Данные

Было бы идеально тестировать на базе, подобной проду, и сбрасывать её перед каждым тестом, но это очень редко возможно из-за колоссальных объёмов данных и необходимости использования сложных инструментов чистки реальных данных. Поэтому у нас есть свой инструмент генерации данных, который умеет создавать в нужном объёме и в разумный срок основные бизнес-сущности: пользователей, команды, организации, доски разного размера, проекты и строить связи между ними. Этот генератор использует то же API, что и основное веб-приложение, и каждый сеанс генерации данных представляет собой немного хаотичный пример НТ. На выходе получается подробный лог и набор файлов, которые можно подключать к НТ сценариям.

Советы по коду

При написании кода может быть полезно следовать таким рекомендациям (известным, впрочем, и в других областях):

1. Сценарий нужно разрабатывать насколько возможно настраиваемым, чтобы иметь возможность например запустить его на других RPS без изменения кода, поэтому хардкод подобных параметров должен быть минимальным.
2. Не стоит пренебрегать документацией по инструменту НТ. Не изобретайте колесо, инструменты НТ разрабатываются на основе большого опыта и в большинстве случаев то, что вам нужно, уже существует.
3. Мониторинг чаще всего придётся доделывать на основе базовых компонентов, гораздо реже можно найти то, что идеально подойдёт.
4. Помните, что чем больше статистики, мониторинга и логирование — тем выше побочная нагрузка, нужно уметь найти баланс.
5. Никогда не используйте код подобный `… request(); sleep(N); request() …` для моделирования 60/N RPM, это не работает, найдите компоненты для вашего инструмента НТ, реализующие требуемую частоту запросов, или хотя бы используйте асинхронный код.

Шаг 4/6. Запуск теста и измерения

Целевая система готова, переходим к самому интересному — запуску теста и снятию метрик. Как я говорил ранее, НТ — это не функциональное тестирование, поэтому мы не просто снимаем ряд булевых показателей типа работает/не работает, а получаем целый ряд разнообразных метрик. Как разбираться в них — большая тема, здесь я затрону только некоторые моменты из неё.

Какие метрики снимать — есть базовый набор и есть специальные для каждого теста, это надо решать ещё при подготовке сценария и тестового окружения.

В ходе собственно выполнения теста у нас используются:

1. Свой управляющий инструмент. Функции:
   1. Деплой тестового сценария и данных (поддерживается несколько сценариев и инструментов НТ).
   2. Запуск теста.
   3. Сбор результатов и логов инструмента НТ.
2. Универсальные средства мониторинга и сбора логов.

Здесь ещё можно упомянуть Open Source проект Taurus, который, как и наше внутреннее решение, предназначен для запуска разных инструментов НТ и поддерживает более 20 инструментов тестирования. Ещё есть тоже открытый Яндекс.Танк. Свой инструмент я решил разрабатывать, потому что задумывалась тесная интеграция с управлением тестовым окружением и инструмент больше про это. Сделать просто распределённый запуск инструмента НТ — задача не такая уж сложная.

И пара советов:

1. Не пытайтесь сразу запустить полный тест, начните с нескольких небольших smoky-тестов. Проверьте, что сценарий выполняется как надо, RPS воспроизводятся и все нужные метрики собираются.
2. Не стоит полагаться на сценарий и метрики полностью. Попробуйте поработать с системой вручную.

Шаг 5/6. Анализ

Паттерны

Давайте предположим, что сценарий выполнился и у нас множество метрик. На что стоит обратить внимание в первую очередь? Вот некоторые примеры. Первые три могут говорить или не говорить о неполадках, а последние вероятнее всего говорят о проблеме:

1. «Пила». Значимые скачки показателя вверх/вниз с достаточно большими промежутками между ними могут говорить, например, о насыщении какого-то ресурса до предела и падении ряда агентов, поднятии новых и повторе ситуации. Или такой может быть внутренняя логика работы приложения.
2. «Полка». Может говорить о том, что мы достигли предела и дальше система не справляется, хотя и не падает. Здесь надо смотреть состояние генераторов нагрузки, возможно больше этого предела они и не грузят и это не ошибка, а просто достижение необходимого уровня. Ещё это может быть предельное значение, выше которого подняться в принципе невозможно — например, загрузка CPU под 100%. Такие случаи требуют особого внимания.
3. «Всплеск». Резкий скачок, причину которого надо изучать. Это может быть, например, внезапно запустившаяся сборка мусора. Но если это график ошибок, то очевидны проблемы.
4. Резкое падение. Например, в начале теста при постепенном увеличении нагрузки может умереть один из воркеров, генерирующих трафик. Или это может быть график общего числа RPS для всего кластера, что может говорить об отказе одного из серверов.
5. Плавная деградация. Это может быть, например, график RPS на сервере, которые начали проседать при стабильной нагрузке. Или обратная ситуация, нагрузка тоже стабильна, а на графике использование оперативной памяти в течение продолжительного срока. Тоже однозначно нужно обратить внимание.
6. Линейный/нелинейный рост связанных показателей. Если некоторый входной параметр растёт линейно, важно чтобы уровень нагрузки подсистем тоже рос хотя бы линейно, но никак не быстрее на несколько степеней. Здесь самое время вспомнить про сложность алгоритмов: O(n), O(log n), O(n^2) и подобное. Чем сильнее нелинейность — тем меньше будет толку от новых и новых серверов.

На графиках ниже показаны синтетические примеры описанных выше паттернов:

Пример

Разберём простейший пример, который может научить нескольким полезным вещам:

1. Проблема: система отвечает слишком медленно на некоторый сценарий. Пусть 95-я персентиль времени выполнения стала 15 с вместо 2 с.
2. Анализ:
   1. Найти узкое место, которое тормозит сценарий. Пусть это будет некоторый API запрос.
   2. Проверить насыщение API серверов. CPU, RAM, IO, очереди сообщений и прочее.
   3. Проверить зависимости. Допустим, в нашей системе используется другой компонент системы, который отвечает слишком медленно.
   4. Проверить сервер, на котором работает этот другой компонент. Допустим там ~100% CPU.
3. Действие — добавить результаты разбора в отчёт. Какие действия предпринимать, чтобы исправить проблему — это не такой простой вопрос. Изменить тип инстанса на больший — это просто, но это не всегда правильное решение. Если используется алгоритм с сильно нелинейной сложностью, то даже увеличение мощности CPU сервера ненадолго поможет.
4. Броки:
   1. Наблюдайте за всем, за чем можно, помня про побочную нагрузку от замеров.
   2. Ищите подлинные причины проблем.
   3. Простой вывод — не всегда правильный.

Шаг 6/6. Отчёт

Самое главное сделано. Остаётся подвести итоги и зафиксировать полученные в ходе нагрузочного тестирования знания. Особо хочу отметить, что НТ — это операция, требующая весьма существенных затрат труда, времени и прочих ресурсов. Поэтому вы явно захотите получить максимум пользы, потратив всё это.

Чтобы извлечь максимум пользы из проведённого НТ — нужен хороший отчёт. Каковы же критерии хорошего отчёта? НТ делается НТ инженерами не только и не столько для себя, а много для кого и для разных людей польза от отчёта зависит от наличия развёрнутых ответов на соответствующие вопросы:

1. Для менеджера — насколько система соответствует требованиям, есть ли запас и какая ситуация может вызвать проблемы с системой?
2. Для DevOps — есть ли слабые места системы со стороны инфраструктуры?
3. Для разработчиков — есть ли слабые места системы со стороны кода?
4. Для НТ инженера — какие инструменты НТ с какими настройками использовались, какой сценарий использовался, на какой конфигурации инфраструктуры проводился тест? Все эти знания в том числе для того, чтобы можно было воспроизвести сценарий при каких-либо изменениях кода или инфраструктуры для сравнения.

Нет отчёта — нагрузочное тестирование впустую!

Ещё один очень важный момент. Серьёзный подход требует регулярного НТ. Оно невозможно без автоматизации построения отчётов и степень этой автоматизации зависит от частоты проведения тестирования.

Результаты внедрения нагрузочного тестирования в Miro

Я рассказал о том, какие этапы НТ есть и как мы работаем на каждом из них.теперь перечислю, чего мы добились благодаря внедрению НТ в таком виде:

1. Понятный и описанный процесс. Чётко описано, какие шаги нужно выполнить и что нужно делать на каждом из шагов.
2. Большие тесты: 200K, 500K пользователей online при типичном сценарии использования. Каждый сложный тест зачастую проходит много итераций перед успешным выполнением, поэтому без автоматизации столько раз гонять большие тесты было бы чрезвычайно долгим и утомительным занятием, полным ошибок.
3. Проверка компонентов перед выкаткой на прод.
4. Обоснованный выбор параметров компонентов для поддержки планируемой нагрузки. То есть не просто с потолка брать «ну наверное хватит сотни воркеров», а выбирать параметры на основе результатов проверок.
5. Автоматизация, упрощение и ускорение проведения НТ. Я говорил в начале про список из 16 пунктов, которые надо было пройти вручную при каждом запуске НТ на кластере. Теперь это один конфиг и одна команда. Больше автоматизации даёт больше надёжности и больше возможностей уделить время более творческим и сложным задачам.
6. Деградационное тестирование (начало). Автоматическое выполнение тестов по реалистичному API сценарию на типичной нагрузке каждую ночь на последней версии сервера и построение графиков трендов для отслеживания динамики показателей скорости ответа и числа ошибок.

Планы в отношении нагрузочного тестирования в Miro

Несмотря на то, что было сделано многое, ещё больше предстоит. Вот планируемые направления развития:

1. Деградационное тестирование (полноценная интеграция с CI/CD). В идеале постоянное НТ должно быть встроено в пайплайн и так же как функциональные тесты влиять на принятие решения о релизе.
2. Тестирование микросервисов. Мы в процессе переезда с монолита, и всё больше работы появляется в этом направлении.
3. Вовлечение большего числа команд. У нас их несколько десятков и пока не все включены в процесс.
4. Улучшение инструментария. При бурном росте не всегда получается выдержать хорошую архитектуру, так что есть немного техдолга.
5. Дополнение внутренней документации НТ примерами конкретных кейсов: как тестировали, что и как выявили, как доработали. Общая документация — это хорошо, но дополнение её солидным набором описаний конкретных кейсов — бесценно.
6. Более исследовательская работа: профилирование, хаос-тестинг и т.д.

Пожелания читателям

Напоследок пожелаю следующее:

1. Верьте в свой проект. Если не будете верить вы, пользователи и подавно не будут.
2. Делайте НТ. Высокие нагрузки должны стать источником дополнительной прибыли или других благ, а не источником проблем.
3. Делайте НТ заранее. Профилактика всегда лучше лечения.
4. Делайте НТ правильно. Ресурсы у всех ограничены, и лучше тратить их с умом.
5. Делайте НТ регулярно. Всё течёт, всё изменяется.
6. Автоматизируйте. Ну это очевидно в 21 веке, я думаю.

Полезные ссылки

В ходе работ по НТ мной и моими коллегами были в том числе использованы источники из базы знаний, создание которой было инициировано русскоязычным QA Load сообществом и в которой я один из мейнтейнеров, также мы многое почерпнули и из самого чата этого сообщества. Ссылки:

1. Русскоязычное QA Load сообщество в Telegram
2. База знаний QA Load сообщества

Предыдущие материалы о НТ в Miro:

1. Достоверный нагрузочный тест c учетом непредвиденных нюансов (доклад с DUMP-2019)
2. Достоверный нагрузочный тест с учётом непредвиденных нюансов
3. Управление сотнями серверов для нагрузочного теста: автомасштабирование, кастомный мониторинг, DevOps культура

QA процесс в Miro:

1. Качество — ответственность команды. Наш QA опыт
2. QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде

Прочие ссылки:

1. Ликбез о том, кто такие QA инженеры и кто такие тестировщики (от Dodo Engineering) — «Кто ты, QA-инженер или тестировщик?»
2. Глава про «4 золотых сигнала» в книге по SRE от Google

Соседние файлы в папке Лекции

• #
• #
• #
• #
• #
• #
• #
• #

Для информационных систем, которым предстоит работа с большими объемами данных, задачи проведения нагрузочного тестирования приобретают высокий приоритет. Зачастую система показывает хорошую производительность на данных небольшого объема, но с ростом загрузки возникают разного рода проблемы, которые могут быть связаны с неоптимальным построением запросов, технологическими конфликтами различных элементов системы, ограничениями системных ресурсов и т. д.

---

Если подобные проблемы обнаруживаются уже в ходе эксплуатации, в условиях реальной пиковой нагрузки, результатом становится резкое снижение быстродействия или даже остановка системы. На поиск причин сбоя и их устранение может уйти несколько дней, что для «mission-critical» приложений обычно приводит к потерям, несопоставимым со стоимостью затрат на проведение тестирования информационных систем. Кроме того, помимо оценок производительности и отказоустойчивости работы системы под нагрузкой, тестирование позволяет выполнить сравнение эффективности работы различных систем или анализ быстродействия работы на разном оборудовании или в различном окружении.

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

---

Нагрузочное тестирование: этапы, методика и инструментарий.

В любом проекте по тестированию можно выделить следующие самостоятельные этапы:

• анализ и проектирование модели нагрузки,
• настройку стенда реализации,
• разработку типовых сценариев,
• реализацию модели нагрузки,
• проведение нагрузочных испытаний,
• анализ результатов тестирования и построение прогнозных моделей.

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

Стандартные процедуры тестирования, принятые в компании «Аплана» основаны на методологии и инструментарии IBM Rational, однако в ряде проектов мы используем технологии и других производителей, в частности, Mercury Interactive. Рекомендации, которые приводятся в данной статье, носят общий характер и не привязаны жестко к той или иной методологии или инструментарию.

Целью данного подготовительного этапа тестирования является моделирование типовых процессов, выполняемых пользователями. По нашему опыту, именно этот этап является наиболее трудоемким – до 50 % всего проекта – и требует от тестировщика аналитических навыков, а также владения средствами автоматизированного тестирования.

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

Реализация модели нагрузки различных систем заключается в разработке тестовых скриптов, реализующих отдельные бизнес-операции. Причем скрипты должны эмулировать работу без привлечения уровня пользовательского интерфейса приложения – это необходимо для возможности параллельной эмуляции работы большого количества пользователей на одном компьютере.

В результате, модель нагрузки представляет собой расписание выполнения (Test Suite, Schedule), содержащее группы пользователей, распределение групп пользователей по компьютерам в момент выполнения и сценарии работы пользователей. Для записи и последующего воспроизведения на этапе выполнения автоматизированных скриптов используются специализированные инструментальные средства.

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

Для определения графика зависимости производительности системы от пользовательской нагрузки и от нагрузки по данным (так называемых профилей производительности), необходимо создать набор тестовых баз данных, которые имеют разный объем (мощность), но совпадают по структуре. Целесообразно формировать наборы тестовых данных, число записей в которых отличается в разы, например, для 2000, 4000, 8000 и т. д. записей.

В этом случае тестирование системы позволяет оценить изменение параметров производительности тестируемого программного обеспечения и определить законы изменения измеряемых параметров в зависимости от нагрузки. Логарифмическая шкала позволяет оценить скорость роста времен отклика и обнаружить узкие места.

Проще всего создать необходимые тестовые базы данных требуемого объема с помощью процедуры дублирования, для чего необходимы следующие шаги:

• определение таблиц базы данных, которые требуется дублировать;
• определение взаимосвязи таблиц базы данных (ограничений целостности); здесь следует учитывать, что часть ограничений целостности может оказаться заложенной в бизнес-логику приложения и не быть прописанной в качестве ограничений целостности в базе данных;
• определение необходимых объемов таблиц исходной базы данных;
• определение способов формирования новых записей в таблицах на основе исходных (чтобы значения полей записей должны быть осмысленными);
• формирование новых записей.

Проведение испытаний.

Проведение испытаний заключается в выполнении определенных тестовых пакетов с определенным количеством пользователей. По результатам данного этапа необходимо получить значения измеряемых параметров при заданных конфигурациях и заданной нагрузке. Чаще всего измеряемыми параметрами являются время отклика системы и процент загрузки системных ресурсов (чаще всего оперативной памяти и процессора). Для дальнейшего анализа данные испытаний фиксируются в таблице, которая может выглядеть таким образом:

В ходе каждого цикла исполнения модели определяются средние значения и отклонения от средних значений для измеряемых параметров.

По итогам испытаний тестирование позволяет получить графики зависимости измеряемых параметров при изменении нагрузки (числа пользователей) и неизменной конфигурации системы. На графиках показаны примеры зависимостей времени отклика и загрузки системных данных от числа пользователей (пользовательской нагрузки). Дополнительной серией испытаний можно получить зависимости измеряемых параметров от конфигурации системы (например, при использовании различного оборудования и/или системного ПО).

Основным результатом проведения нагрузочных испытаний является расчет показателей производительности таких как время отклика на запрос и загруженность системных ресурсов сервера в зависимости от загрузки (числа подключенных пользователей). Эти результаты обычно представляются в виде сравнительных отчетов по времени выполнения различных функций программного обеспечения при одинаковой нагрузке, при использовании различных программно-аппаратных конфигураций, при работе с различными объемами данных и т. д.

Наиболее распространенные виды отчетов о результатах нагрузочных испытаний:

• Response vs Time (resources) – отклики по времени, загрузка ресурсов,
• Performance – производительность, время отклика,
• Compare Performance – сравнение производительностей.

В отчет о тестировании обычно также включается перечень «узких мест» программной системы с указанием причин.

Указанным способом определяются так называемые первичные результаты, т. е. результаты, определяемые непосредственно из тестирования. На их основе могут быть построены прогнозные модели, позволяющие оценить производительность тестируемого ПО на других конфигурациях и при другой нагрузке. Полученные таким образом результаты относятся к классу вторичных или аналитических результатов проведенного тестирования.

Если результаты тестирования подтвердили необходимость увеличения мощности системных ресурсов, то фактически встает вопрос о выборе программно-аппаратной платформы, на которой ПО будет поддерживать в системе параллельную работу заданного количества пользователей. В этом случае, возможно, потребуется проведение серии испытаний системы на различных платформах.

Особенности тестирования промышленных систем.

Как правило, нагрузочное тестирование является неотъемлемым этапом внедрения системы, однако довольно распространенной становится ситуация, когда необходимо тестирование промышленной системы, работающей в режиме 24?7. Такая необходимость, например, возникает, когда система, успешно проработав несколько месяцев или даже лет, приближается к своей пиковой нагрузке по объему данных или количеству пользователей.

Чтобы избежать остановки системы на время проведения тестирования, а также лишних рисков, обычно создается тестовый стенд, который воспроизводит работу промышленной системы и на базе которого проводятся все эксперименты. Однако в этом случае задача тестировщиков может усложняться в силу следующих обстоятельств:

• редко удается полностью продублировать конфигурацию системы на тестовом стенде и используется менее мощное оборудование;
• в ряде случаев, из соображений конфиденциальности и безопасности, владелец промышленной системы (заказчик) ограничивает доступ к информации о логике работы процессов на сервере и клиентах, о конфигурации и архитектуре системы.

Дополнительные сложности могут быть обусловлены шифрованием уникальным ключом каждой сессии и каждого передаваемого пакета, нестандартным протоколом обмена и т. д. В частности, все указанные сложности характерны практически для любого серьезного финансового приложения.

Подробное рассмотрение перечисленных вопросов выходит за рамки данной статьи, поэтому мы приведем несколько общих рекомендаций.

---

Если существует различие в конфигурациях тестового стенда и тестируемой системы, необходима оценка переходного коэффициента для производительности тестовой и промышленной систем. На основании этого коэффициента проводится масштабирование полученных зависимостей. Для получения погрешности оценки, не превышающей 5-10 %, рекомендуется проведение оценки переходного коэффициента несколькими независимыми способами, например, на основании анализа независимых данных о производительности использованных аппаратных платформ.

Для тестирования же систем, представляющих для тестировщика «черный ящик», когда неизвестны детали конфигурации и функционирования системы, а также для перехвата и эмуляции пользовательской активности при работе с подписанным трафиком, используются низкоуровневые протоколы обмена данными.

В данной статье мы попытались отразить ключевые моменты организации нагрузочного тестирования. Вне зависимости от целей проекта, для получения адекватных результатов необходимо иметь в наличии инструментарий и квалифицированных специалистов, владеющих методикой тестирования.

Любое программное обеспечение должно работать под нагрузкой длительное время. Сбои и отказы системы могут привести к убыткам, потере клиентов и другим неприятным последствиям. Нагрузочное тестирование позволяет определить, как и с какой скоростью работает программа под определенной нагрузкой. Посредством нагрузочного тестирования оценивается соответствие производительности продукта требованиям, сформулированным в ТЗ.

Нагрузочное тестирование рекомендуется проводить при выпуске нового программного обеспечения, доработке эксплуатируемого ПО и при изменении конфигурации стендов.

Ключевые преимущества

⦁ Оценка возможностей системы и ⦁ определение максимальной производительности.
⦁ Предупреждение отказов системы в промышленной эксплуатации.
⦁ Выявление ошибок (например, утечка памяти, некорректные настройки или распределение ресурсов).
Поиск оптимального комплекса технических средств (КТС).
Выдерживая громадные нагрузки, программное обеспечение просто обязано эффективно работать. Поэтому нагрузочное тестирование является гарантией стабильности действий приложений.

Нагрузочное тестирование является сложным процессом, включающим в себя
⦁ аналитическую работу,
⦁ выбор подходящего вида тестирования под заданные цели.

Нагрузочное тестирование требует обстоятельных знаний специфики различных серверов, сетевых протоколов, практических навыков в программировании и т. д.

Основные этапы нагрузочного тестирования

Подготовка — Проводится анализ целей и статистики эксплуатации системы. Определяются бизнес-операции, имеющие значение с точки зрения нагрузки на систему. Создается и согласуется документ «Методика нагрузочного тестирования», который включает: стратегию тестирования, список и описание тестов, критерии успешного завершения, описание средств мониторинга и инструментов нагрузочного тестирования. Осуществляется подготовка тестовых данных, настраивается мониторинг, наполняется база данных.

Проведение — Выполняется запись и отладка скриптов нагрузочного тестирования и реализация сценариев нагрузочного тестирования. С помощью разработанной системы нагрузочного тестирования выполняется тестирование приложений. В рамках нагрузочных испытаний собирается различная статистическая информация, с помощью которой выполняется анализ производительности.

Отчет — После проведения нагрузочного тестирования компании клиенту предоставляется отчет, который описывает результаты тестирования, отступления от методики (если имеются), список ошибок, предложения по оптимизации работы системы, общие замечания.

Направления нагрузочного тестирования

Тестирование производительности — Определение характеристик производительности системы

Тестирование стабильности — Проверка работоспособности системы в течение длительного времени эксплуатации, в том числе с большими объемами данных и высокой нагрузкой

Стресс-тестирование — Проверка корректности работы системы в режиме перегрузки и сбоев

Тестирование на достижимость бизнес-планов — Исследование того, как система будет работать, когда будут достигнуты плановые бизнес-показатели

Объемное тестирование — Тестирование поведения системы при увеличении объема данных

Тестирование сервера — Проверка работоспособности и надежности серверной части системы

Тестирование производительности

Тестирование производительности позволяет определить максимальную интенсивность операций, при которой система удовлетворяет требованиям ко времени отклика. Тестирование производительности рекомендуется проводить для новой версии ПО, планируемого к внедрению.

Ключевые преимущества

⦁ Выявление и предотвращение отказов системы перед внедрением в промышленную эксплуатацию.
⦁ Определение максимального количества одновременно работающих пользователей в системе.
⦁ Определение максимального количества одновременно выполняемых операций без потери качества обслуживания.

Основные задачи

В рамках тестирования производительности собирается статистика использования системы, на основе которой составляется профиль нагрузки. После этого вычисляется начальная точка и размер шага для увеличения интенсивности выполнения операций.

В ходе выполнения тестирования определяется максимальная производительность системы:

⦁ наибольшая интенсивность выполнения операций с требуемым качеством обслуживания (SLA);
⦁ пиковая производительность системы, при которой происходит ухудшение показателей качества обслуживания операций (время выполнения, отказы).

Объемное тестирование

Данный вид тестирования позволяет проверить использование системных ресурсов при увеличении объема данных и принять проактивные меры для предотвращения отказа системы в будущем. Объемное тестирование подходит не только для систем, планируемых к внедрению в опытно-промышленную эксплуатацию, но и на стадии проектирования.

Ключевые преимущества

Объемное тестирование позволяет:

⦁ Определить глубину хранения данных, при которой не произойдет деградации производительности системы.
⦁ Подобрать оптимальный комплекс технических средств.
⦁ Выявить лучшее архитектурное решение для системы, находящейся на этапе проектирования.

Основные задачи

Главной задачей объемного тестирования является оценка производительности системы при увеличении потока данных. В ходе тестирования эмулируется увеличение интенсивности операций системы с одновременным увеличением объемов базы данных. В процессе тестирования измеряется общая производительность системы: количество операций за определенный период времени, время отклика системы и количество пользователей, одновременно работающих в системе.

Объемное тестирование рекомендуется основывать на следующих бизнес-прогнозах:

⦁ как увеличится число пользователей системы?
⦁ как увеличится интенсивность операций?
⦁ какой объем базы данных будет, например, через 5 лет?

Тестирование стабильности

Тестирование стабильности предназначено для оценки возможности системы работать длительное время под нагрузкой. Этот тип тестирования позволяет выявить утечки памяти или некорректные настройки ПО. Данный вид работ рекомендуется проводить как для новых систем, так и для новых версий уже эксплуатируемого ПО.

Ключевые преимущества

Тестирование стабильности позволяет:
⦁ Предупредить сбои системы и ухудшение скорости и качества обработки данных.
⦁ Проверить возможность стабильной работы системы, находящейся под длительной нагрузкой.
⦁ Определить характеристики системы, которые подлежат отслеживанию в ходе опытно-промышленной эксплуатации.
⦁ Выявить недостаток аппаратных и системных ресурсов до внедрения в опытно-промышленную эксплуатацию.

Основные задачи

В ходе тестирования стабильности на целевую систему в течение не менее 24 часов подается средний уровень нагрузки, 70-80% от максимального уровня.
Одновременно с подачей нагрузки измеряются следующие показатели:
⦁ время выполнения операций;
⦁ распределение системных ресурсов;
⦁ другие показатели с учетом особенности системы.

В результате тестирования могут быть найдены многие трудноуловимые в обычных условиях ошибки, такие как утечка памяти, некорректные настройки серверного окружения, недостаток аппаратных или системных ресурсов.

Нагрузочное тестирование серверов

В процессе повседневной эксплуатации ИТ-систем достаточно трудно оценить соответствие параметров аппаратной инфраструктуры актуальным техническим требованиям и текущим бизнес-процессам.
Для измерения имеющихся серверных мощностей необходимо создать для них условия, приближенные к пиковым нагрузкам. Нагрузочное тестирование сервера позволяет наиболее точно моделировать подобные сценарии работы.

Какие задачи решает нагрузочное тестирование
⦁ выбор оптимальной аппаратной и программной конфигурации компонентов сервера;⦁ проверка максимальной производительности аппаратных средств и отладка сценариев их работы в периоды пиковых нагрузок;⦁ предупреждение отказов сервера при увеличенном потреблении ресурсов сети, повышенной загрузки оперативной памяти и  центрального процессора;⦁ проверка стабильности работы сервера при максимальных нагрузках в разные временные отрезки в круглосуточном режиме.

Основные этапы нагрузочного тестирования

Определение критериев испытания

Разработка стратегии тестирования, определение параметров работы сервера, допустимых границ значений при работе оборудования. Далее приводится перечень производимых тестов и используемых инструментов. В заключение подготавливаются тестовые параметры и сценарии.

Проведение испытаний

В соответствии с выбранным сценарием производится эмуляция одновременной работы пользователей с приложением. Оценивается скорость обработки данных с дисковой подсистемы, время выполнения запросов, объем потребления ресурсов сети, а также уровень загрузки оперативной памяти и центрального процессора. Возможен запуск нескольких сценариев одновременно.

Анализ результатов тестирования

По результатам нагрузочного тестирования сервера компании клиенту предоставляется детальный отчет о проведенных испытаниях с графиками зависимостей, описанием вероятных проблем и предложениями по улучшению конфигурации оборудования.
Тестирование различных компонентов системы

Сетевая архитектура

Выявление потенциальных дефектов сетевых адаптеров и драйверов. Установление запаса производительности и определение качества работы сети.

Приложения

Оценка максимальной эффективности работы выбранных приложений при заданных значениях метрик производительности. Типичные объекты исследования — операционные системы (Linux, MS Windows Server, Solaris), серверы приложений (WildFly (RedHat JBoss Application Server), IBM WebSphere, WebLogic), системы управления базами данных (MySQL, PostgreSQL, MS SQL), корпоративное ПО (ERP-, CRM-системы и т.д.)

Базы данных

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

Стресс тестирование

Стресс-тестирование предназначено для проверки поведения системы в условиях стресса и оценки способности системы к восстановлению после прекращения воздействия стресса. Этот тип тестирования необходим для систем с высокой степенью критичности для бизнеса, а также приложений с высокой отказоустойчивостью.

Как правило, стресс-тестирование проводится в следующих случаях:
⦁ Если велика стоимость отказа системы в экстремальных ситуациях.
⦁ Если есть возможность резкого увеличения нагрузки на систему в экстремальных ситуациях.

К стрессовым условиям относятся: повышение интенсивности выполнения операций до очень высоких значений, аварийное изменение конфигурации сервера.

Ключевые преимущества

⦁ Выявляются узкие места в отдельных компонентах системы, из-за которых возможно снижение производительности системы в стрессовых условиях.
⦁ Определяются показатели нагрузки системы, при которых система отвечает требованиям к производительности, заявленным на этапе проектирования.

Основные задачи

В ходе проведения стресс-тестирования  разрабатываются сценарии, эмулирующие нагрузку на систему, значительно превышающую ожидаемые показатели системы. При этом снимаются показатели по производительности, которые в дальнейшем анализируются и позволяют сделать выводы о выносливости или устойчивости приложения в случае всплеска активности по его использованию.
Основными задачами стресс-тестирования являются:
⦁ исследование поведения системы при пиковых нагрузках;
⦁ исследование обработки ошибок и исключительных ситуаций при пиковых и диспропорциональных нагрузках;
⦁ исследование узких мест в отдельных компонентах системы;
⦁ тестирование емкости системы.

Книги: [Классика] [Базы данных] [Internet/WWW] [Сети] [Программирование] [UNIX] [Windows] [Безопасность] [Графика] [Software Engineering] [ERP-системы] [Hardware]       ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. (Вторая редакция) Сэм Канер, Джек Фолк, Енг Кек Нгуен Издано:2000, Киев, Издательство «ДиаСофт» Для специалистов в области разработки программного обеспечения ISBN: 966-7393-42-9 Мягкий переплет, 544 стр. Формат: 60×84/16 Начало Предисловие Об авторах [Заказать книгу в магазине «Мистраль»] Содержание Часть I. Основы Глава 1. Пример серии тестов Первый цикл тестирования Второй цикл тестирования Что дальше? Глава 2. Желаемое и действительное в жизни тестировщика Полностью протестировать программу невозможно Цель тестировщика - проверка правильности программы? Итак, для чего же тестируют программы? Глава 3. Типы тестов и их роль в процессе разработки программного обеспечения. Обзор стадий разработки Стадии планирования Тестирование на этапе планирования Стадии проектирования Тестирование на этапе проектирования Тестирование "стеклянного ящика" на стадии кодирования Регрессионное тестирование Тестирование "черного ящика" Сопровождение Глава 4. Программные ошибки Качество Что такое программная ошибка? Категории программных ошибок Глава 5. Документирование и анализ ошибок Отчет следует составлять немедленно Структура отчета о проблеме Каким должен быть отчет о проблеме Анализ воспроизводимой ошибки Методика анализа воспроизводимой ошибки Поиск способа воспроизведения ошибки Часть II Приемы и технологии тестирования Глава 6. Система отслеживания проблем Основное назначение системы отслеживания проблем Задачи системы Процесс отслеживания проблемы Пользователи системы отслеживания проблем Реализация базовых функций системы отслеживания проблем Дополнительные замечания о документировании проблем Терминология Глава 7. Разработка тестов Характеристики хорошего теста Классы эквивалентности и граничные условия Тестирование переходов между состояниями Условия гонок и другие временные зависимости Нагрузочные испытания Прогнозирование ошибок Тестирование функциональной эквивалентности: автоматизация, анализ чувствительности и случайный ввод Регрессионное тестирование: успешно ли исправлена ошибка Регрессионное тестирование: стандартная серия тестов Выполнение тестов Глава 8. Тестирование принтеров и других устройств Общие вопросы конфигурационного тестирования Тестирование печати Глава 9. Адаптационное тестирование Изменен ли исходный код? Привлекайте к работе специалистов, свободно владеющих языком Встроен ли текст в программный код? Перевод длиннее исходного текста Наборы символов Клавиатура Фильтрация ввода Загрузка, сохранение, импорт и экспорт символов основного и расширенного набора ASCII Язык и операционная система Клавиши вызова Сборные сообщения Идентификаторы сообщений об ошибках Правила переноса Правописание Порядок сортировки Преобразование текста к верхнему и нижнему регистру Правила подчеркивания Принтеры Размеры бумаги Процессоры и видео Форматы данных и опции настройки Единицы измерения Изображения, связанные с конкретной культурой Выходные данные, связанные с конкретной культурой Совместимость с местными продуктами Не будьте наивными Автоматизированное тестирование Глава 10. Тестирование документации Хорошая документация Цели тестировщика документации Как тестирование документации повышает надежность программного продукта Назначьте технического редактора Работа с руководством в процессе его разработки Интерактивная справка Глава 11. Инструментальные средства тестировщика Базовые инструменты тестировщика Автоматизация приемочного и регрессионного тестирования Стандарты Тестирование "стеклянного ящика" Глава 12. Планирование и документация Общее назначение тестового плана: продукт или инструмент? Цели, преследуемые при планировании тестов и разработке документации Тесты каких типов следует фиксировать в плановых документах Стратегия разработки компонентов тестового плана Компоненты плана тестирования Документирование тестовых материалов Заключение Часть III. Управление проектами и группами Глава 13. Объединяющая Чем приходится поступаться разработчикам программного обеспечения Модели разработки программного обеспечения Затраты на качество Последовательность этапов проекта Проектирование продукта Реализация базовых функций Почти альфа Альфа Пре-бета Бета Замораживание пользовательского интерфейса Подготовка к финальному тестированию Последняя проверка целостности Выпуск После выпуска Глава 14. Управление группой тестирования Роль группы тестирования Группа тестирования - не избавление программистов Альтернатива: независимые тестовые агентства Советы по планированию Персонал Приложение. Распространенные программные ошибки Ошибки пользовательского интерфейса Обработка ошибок Ошибки, связанные с граничными условиями Ошибки вычислений Начальное и последующие состояния Ошибки управления потоком Ошибки обработки или интерпретации данных Ситуации гонок Повышенные нагрузки Аппаратное обеспечение Контроль версий и идентификаторов Ошибка выявлена и забыта Начало Предисловие Об авторах Заказать книгу в магазине «Мистраль»

Нагрузочное тестирование – что это?

Нагрузочным называется тестирование, направленное на проверку способности программы эффективно работать при пиковых или очень высоких нагрузках, связанных с большим количеством запросов пользователей.

Учитывая сказанное, становится понятным почему НТ особенно активно используется именно для многопользовательских программ, например, интернет-магазинов или онлайн-кинотеатров.

Сравнение с автотестами и ручным тестированием

Далеко не всегда можно четко провести границу между разными видами тестирования. Например, НТ очень напоминает и даже в чем-то пересекается с так называемым стресс-тестированием, которое также проверяет программу на устойчивость и производительность под предельной нагрузкой.

Но для эффективного практического использования нагрузочного тестирования необходимо понимать отличие от двух других очень распространенных методов проверки – ручного и автотестирования. Первый является самым популярным, так как именно с него начинается тестирование любого ПО. Главное задачей ручного функционального тестирования выступает выявление багов и системных сбоев. Другими словами – определение работоспособности программы.

Далее проводится автотестирование, связанное с более детальной проверкой разработанного программного продукта. Речь идет о выявлении слабых мест исходного кода, его последующей оптимизации и наладке.

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

Важно понимать, что проблемой программного продукта может стать не только полный отказ от обработки запросов, но и чрезмерно медленная работа.

Очевидно, что покупатель не станет ждать оформления заказа в течение получаса, если интернет-магазин декларирует, что это займет 3 или 5 минут.

Виды тестирования в целом

Автотесты и ручное тестирование – это поверхностное разделение, не отражающее сути тестирования. На практике видов тестирования – куда больше:

Краткое описание основных ветвей:

• По степени автоматизации. То, о чем мы говорили выше – автоматическое, ручное, автоматизированное. Автоматизированное – это когда мы один раз написали тесты, и они запускаются сами при каких-то определенных условиях, очень полезно при регрессионном тестировании (когда мы проверяем, что ничего из уже работающего не сломалось при новом апдейте). Автоматическое – мы написали скрипты, которые проводят тесты за нас.
• По разработке тестовых сценариев. Тестирование должно покрывать вероятные сценарии, и здесь мы определяем, откуда мы эти сценарии будем брать.
• По уровню тестирования. Мы решаем, на каком уровне абстракции мы тестируем (приложение, система, или ее отдельные модули) или на какой стадии разработки нам нужно провести тестирование.
• По позитивности сценария. Проверяем либо позитивные (что-то должно произойти), либо негативные (что-то не должно произойти) сценарии.
• По исполнению кода. Тестировать можно не только приложение, но и сам его код – проверка компиляции, проверка сохранения стиля кода, проверка исполнения кода интерпретатором и так далее.
• По знанию системы. Если мы не имеем доступа к исходникам и тыкаем приложение со стороны пользователя – черный ящик, если мы можем посмотреть весь код – белый ящик.
• По целям. Что мы хотим протестировать? Целей может быть очень много, и веток здесь – соответственно много. Тестировать можно новый функционал, старый функционал, IU, нагрузку, защиту, умение серверов восстанавливаться, базы данных и так далее. Здесь же лежит и нагрузочное тестирование.

Что крайне важно: окончательный вид тестирования может складываться из нескольких ветвей, если они не противоречат друг другу. Например, мы проводим регрессионное белоящичное стресс-тестирование – это значит, что мы при наличии доступа к исходникам проверяем, что после введения нового функционала в проект старые показатели быстродействия при пиковых нагрузках не изменились. Или мы можем провести сероящичное системное автоматическое нагрузочное тестирование (performance testing) на основе требований – то есть мы тестируем всю систему при неполном понимании кода (возможно, используем сторонние сервисы, в которые не можем влезть) на предмет стабильной работы при нормальной нагрузке, «нормальную нагрузку» берем из ТЗ заказчика или из оценок маркетологов.

Виды нагрузочного тестирования

Нагрузочное тестирование – это одна из ветвей тестирования производительности:

У нагрузочного тестирования есть собственные подвиды:

• Непосредственно нагрузочное. Мы проверяем, что приложение нормально работает при средней нагрузке.
• Стабильности. То же, что и нагрузочное тестирование, но на длительном промежутке времени.
• Отказоустойчивости. Предположим, уборщица в серверной мыла пол и выдернула штекер из розетки – у сервера пропало питание. Сможет ли система быстро развернуться заново на новом сервере или в облаке?
• Восстановления. Подвид предыдущего – как быстро система развернется заново?
• Стресс-тест. Выдержит ли онлайн-магазин наплыв покупателей на Черную Пятницу?
• Объема. Что будет, если в базу данных резко записать 100 000 000 новых клиентов?
• Масштабируемости. Как быстро развернутся новые кластеры в облаке при необходимости?
• Потенциальных возможностей. При таком тестировании проверяются вообще все пределы приложения: максимум клиентов в минуту, максимум записей в БД, максимум суммарно открытых коннектов и так далее.

Поскольку нагрузочное тестирование не является функциональным, границы видов местами расплываются: стресс-тест может перерасти в тест объема, тот перерастает в тест масштабируемости, когда тест проваливается – он автоматические переквалифицируется в тест восстановления. Поэтому в реальной работе вам обычно дают конкретное задание: например, «Проверить, как онлайн-магазин поведет себя при оформлении 10 000 заказов в минуту», а вы сами уже решаете, как его квалифицировать (нагрузочный, стресс-тест, объема или масштабируемости) и проводите дополнительные тесты при необходимости.

Составляем методику тестирования

Непосредственному проведению тестов обязательно предшествует разработка МНТ. Аббревиатура расшифровывается как методика нагрузочного тестирования. Она представляет собой документ, содержащий все возможные сценарии и прогнозы развития событий. Составление МНТ предусматривает последовательное выполнение следующих операций:

1. Сбор максимально полной информации о проекте. Формулирование основных терминов, чтобы избежать разночтений при трактовке результатов.
2. Определение целей нагрузочного тестирования. Необходимо для выбора подходящих текстов.
3. Установление ограничений при проведении НТ. Обычно речь идет о том, что уже проверено другими видами тестирования, например, багах или определенных функциях программы.
4. Правила моделирования системы. Включают отличие от реальных условий использования программы. Они обеспечиваются за счет применения заглушек, виртуализации и эмуляторов.
5. Возможные ошибки и причины их возникновения.
6. Характеристики тестового стенда и используемых в ходе тестирования программных продуктов или иных инструментов тестировщика.
7. Требуемые характеристики программного продукта.
8. Непосредственное описание этапов тестирования посредством моделирования нагрузки на систему.
9. Определение перечня получаемых результатов проведения тестов и методов их последующего анализа.
10. Составление требований к итоговому отчету, включая выдачу рекомендаций по устранению слабых/проблемных мест программы, а также определение максимальной производительности системы.

Приведенная схема МНТ не является догмой. Она корректируется в зависимости от специфики тестируемого программного обеспечения и задач, поставленных разработчиками ПО/заказчиком.

Необходимость разработки методики нагрузочного тестирования

Составление МНТ помогает не только более эффективно провести тестирование, но и обосновать его актуальность перед заказчиком. Дополнительным плюсом разработки документа становится формализация отношений и возможность четкой формулировки задач, стоящих перед тестировщиком.

Порядок проведения НТ

По большому счету, процедура нагрузочного тестирования представляет собой практическую реализацию составленной ранее МНТ. В общем случае производятся такие действия:

• изучение тестируемой системы;
• определение целей тестирования;
• разработка МНТ;
• проведение тестов;
• сбор результатов и их анализ;
• оформление отчета и его передача заказчику.

ПО для тестов

Оценка производительности ПО в рамках нагрузочного тестирования предусматривает использования разнообразного инструментария.

В том числе – специализированных программ и сервисов, самые популярные из которых заслуживают отдельного описания.

Apache JMeter

Наиболее востребованный инструмент в работе тестировщика. Имеет открытый исходный код, что дополняется еще несколькими существенными преимуществами:

• простым и доступным интерфейсом;
• использованием популярного языка программирования Java;
• наличием множества дополнительных плагинов и встроенных опций.

Бонусом становится разносторонний анализ полученных результатов. Единственный существенный недостаток – отсутствие поддержки JavaScript.

LoadRunner

Профессиональный инструмент для нагрузочного тестирования, эффективное использование которого требует от исполнителя определенной квалификации. Отличается широким функционалом и комплексным подходом к проверке ПО. Позволяет тестировать как программы для ПК, так и мобильные приложения. Работает непосредственно в браузере.

Единственным серьезным недостатком выступает высокая стоимость лицензии.

LoadNinja

Удобный сервис для конструирования тестов, не требующий знания программирования. Использует в работе несколько метрик, позволяющих не только провести тестирование, но и отладку исходного кода. Основным недостатком становится возможность применения исключительно для ПО, поддерживающих или использующих JavaScript.

K6

Недавно появившийся, но стремительно набирающий популярность онлайн-сервис. Предназначен исключительно для проверки производительности интернет-ресурсов и ПО. Успешно интегрируется с различными инструментами CI.

Дополнительные средства

Вам нужно уметь пользоваться не только софтом для нагрузочного тестирования, но и средствами, составляющими экосистему проекта. Естественно, на каждом проекте используется свой уникальный набор технологий, но в большинстве случаев встречаются следующие:

Как стать специалистом в нагрузочном тестировании?

Самый простой и очевидный способ получить профессию тестировщика – посещение специализированных курсов. При этом имеет смысл остановиться на платном обучении, так как бесплатное редко оказывается эффективным в силу достаточно серьезных требований к специалисту.

Минимальная продолжительность курсов составляет месяц-полтора. Причем предпочтение следует отдавать тем учебным центрам, в программу которых в обязательном порядке входят не только теоретические, но и практические занятия.

Важно понимать, что тестирование – это такая область IT-индустрии, которая требует разносторонних знаний.

Именно поэтому многие тестировщики изначально были системными администраторами, программистами или представителями других профессий. После освоения навыков различных видов тестирования, включая нагрузочное, их востребованность на рынке труда, как и уровень заработка, резко увеличивается.

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

Логичным следствием этого становится быстрый карьерный и зарплатный рост квалифицированных тестировщиков, выступающий дополнительным стимулом в пользу выбора профессии.

На какие курсы обратить внимание?

Если вы пока слабо ориентируетесь в тестировании – вам нужны курсы, которые дадут крепкую базу, и из базы вы уже сможете развиваться дальше самостоятельно. На каких курсах можно эту базу получить:

• Нагрузочное тестирование. Курс посвящен непосредственно нагрузочному тестированию, поэтому подойдет тем, у кого уже есть знания/опыт в тестировании. Длительность – 4 месяца, по 4 академических часа в неделю. На курсе рассматриваются конкретные инструменты и подходы нагрузочного тестирования: приведенные выше приложения, метрики, планирование, отчетность и так далее. Стоимость: 91 000 рублей.
• Тестировщик на Java. Длительный (10 месяцев) курс на получение профессии тестировщика с навыками автоматизации. На курсе рассматриваются вся основная теория по самым распространенным видам тестирования (включая нагрузочное), теория подкрепляется практикой. Язык, на котором вы будете автоматизировать тестирование – Java. Основной упор – на автоматизацию тестирования web-приложений. Стоимость: от 3 153 рубля в месяц при рассрочке на 36 месяцев.
• Курсы тестирования ПО (QA) в Москве. Можно записаться как на дистанционные, так и на офлайн-курсы. Программа курса – очень насыщенная, вас познакомят со всеми основными видами тестирования и инструментами тестировщика, а также научат работать в команде и понимать место/роль тестировщика в бизнес-логике IT-компании. Длительность курса – 12 месяцев, стоимость – от 2 380 рублей в месяц.

Что почитать или посмотреть по теме?

1. Канал на YouTube «Нагрузочное тестирование с нуля».
2. Видео ролик на YouTube «Обзор JMeter. Нагрузочное тестирование в JMeter».
3. Видео ролик на YouTube «Что такое нагрузочное тестирование?»
4. Святослав Куликов «Тестирование программного обеспечения. Базовый курс».
5. Гленфорд Майерс, Том Баджетт, Кори Сандлер «Искусство тестирования программ».
6. Boris Beizer «Software Testing Techniques».

FAQ

Что такое нагрузочное тестирование?

Нагрузочным тестированием называется проверка производительности программного обеспечения при работе под серьезной нагрузкой.

С какой целью оно проводится?

Основная цель НТ – проверка способности ПО выдерживать одновременное присутствие на сайте большого числа пользователей или получение объемных запросов.

Когда НТ становится особенно актуальным?

Нагрузочное тестирование в обязательном порядке проводится для сервисов и сайтов, предназначенных для обслуживания большого числа клиентов или работы аналогичного количества пользователей. Например, интернет-магазинов или социальных сетей.

Чем НТ отличается от других видов тестирования?

Обычно нагрузочное тестирование проводится в числе последних. Оно не предназначено для выявления багов или проверки полноценного функционала системы в обычных условиях. Задачей НТ выступает тестирование сайта, работающего под экстремальной нагрузкой.

В чем важность составления методики нагрузочного тестирования?

МНТ позволяет четко сформулировать задачи тестирования, определить используемые тесты и даже обосновать необходимость НТ перед заказчиком.

Как стать тестировщиком и насколько актуальной является эта профессия сегодня?

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

Подведем итоги

1. Нагрузочным называется один из видов тестирования производительности, в рамках которого происходит проверка способности системы выдерживать пиковые или чрезмерные нагрузки.
2. НТ проводится на последней стадии тестирования – после выявления и устранения багов программного кода, проверки функционала и производительности ПО в обычных условиях.
3. Основанием для проведения НТ выступает методика нагрузочного тестирования. Она разрабатывается с учетом задач, поставленных перед тестировщиком и специфики тестируемого сайта.
4. Профессия тестировщик находится на стыке нескольких видов IT-деятельности, а потому требует обширного набора знаний и умений.
5. Для получения специальности требуется пройти учебный онлайн-курс, но по-настоящему квалифицированным профессионалам можно стать только после получения соответствующего опыта и практических умений.