Терминология
Есть большая разница между тем, как будет работать ваше приложение/сервис в зависимости от того, сколько пользователей его используют. То, что работало во время разработки, может развалиться, когда придут первые реальные пользователи со своим окружением, а то, что работало с сотней пользователей, может умереть, когда их станет 10 тысяч. Или бывает, что вы все потестили на искусственных данных, а потом ваша база начинает торзмозить из-за пользователя со специфическим именем.
Современное программное обеспечение просто обязано бесперебойно работать под колоссальными нагрузками. Любого рода проблемы, связанные с плохой производительностью, могут стать причиной отказа клиентов от использования вашего ПО. В связи с этим, проведение качественного нагрузочного тестирования должно стать обязательным, для обеспечения стабильности работы ваших приложений.
Нагрузочное тестирование (Load Testing) или тестирование производительности (Performance Testing) — это автоматизированное тестирование, имитирующее работу определенного количества пользователей на каком-либо общем для них ресурсе.
Термин нагрузочное тестирование может быть использован в различных значениях в профессиональной среде тестирования ПО. В общем случае он означает практику моделирования ожидаемого использования приложения с помощью эмуляции работы нескольких пользователей одновременно. Таким образом, подобное тестирование больше всего подходит для многопользовательских систем, чаще — использующих клиент-серверную архитектуру (например, веб-серверов). Однако и другие типы систем ПО могут быть протестированы подобным способом. Например, текстовый или графический редактор можно заставить прочесть очень большой документ; а финансовый пакет — сгенерировать отчёт на основе данных за несколько лет. Наиболее адекватно спроектированный нагрузочный тест даёт более точные результаты.
Основная цель нагрузочного тестирования заключается в том, чтобы, создав определённую ожидаемую в системе нагрузку (например, посредством виртуальных пользователей) и, использовав идентичное программное и аппаратное обеспечение, наблюдать за показателями производительности системы.
В идеальном случае в качестве критериев успешности нагрузочного тестирования выступают требования к производительности системы, которые формулируются и документируются на стадии разработки функциональных требований к системе до начала программирования основных архитектурных решений. Однако часто бывает так, что такие требования не были четко сформулированы или не были сформулированы вовсе. В этом случае первое нагрузочное тестирование будет являться пробным и основываться на разумных предположениях об ожидаемой нагрузке и потреблении аппаратной части ресурсов.
Начиная работу в области нагрузочного тестирования, следует четко понимать, что это не просто запись и прогон скриптов, а более сложный процесс:
Моделирование нагрузки происходит с помощью специальных продуктов и техник. Что же, чем и как мы собираемся моделировать? Для того чтобы разобраться в этом и нужно определиться с терминологией:
1. Виртуальный пользователь (Virtual User) - программный процесс, циклически выполняющий моделируемые операции.
2. Итерация (Iteration) – это один повтор выполняемой в цикле операции.
3. Интенсивность выполнения операции (Operation Intensity) - частота выполнения операции в единицу времени, в тестовом скрипте задается интервалом времени между итерациями.
4. Нагрузка (Loading) - совокупное выполнение операций на общем ресурсе.
5. Производительность (Performance) - количество выполняемых операций за период времени (N операций за M часов)
6. Масштабируемость приложения (Application Scalability) - пропорциональный рост производительности при увеличении нагрузки.
7. Профиль нагрузки (Performance Profile) — это набор операций с заданными интенсивностями, полученный на основе сбора статистических данных либо определенный путем анализа требований к тестируемой системе.
8. Нагрузочной точкой называется рассчитанное (либо заданное Заказчиком) количество виртуальных пользователей в группах, выполняющих операции с определенными интенсивностями.
Теперь рассмотрим, как эти сущности связаны между собой. Выразив интенсивность через интервал времени между итерациями, видим, что рост интенсивности выполняемых операций — это сокращение интервала времени. Рост нагрузки пропорционален росту интенсивности. Естественно также, что при увеличении интенсивности растет производительность. При этом увеличивается степень использования (загруженности) ресурсов. С какого-то момента рост производительности прекращается (а нагрузка может продолжать расти), происходит насыщение и затем деградация системы. В дополнение можно заметить, что при тестировании изменение интенсивности операций может подчиняться какому-либо закону (например, Пуассона) либо быть равномерным в течение всего теста.
Уникальность запросов
Даже сформировав реалистичный сценарий работы с системой на основе статистики её использования, необходимо понимать, что всегда найдутся исключения из этого сценария. Например, большинство пользователей посещают одни и те же страницы, а несколько пользователей интересуются совершенно другими страницами.
Время отклика системы
В общем случае время отклика системы подчиняется функции нормального распределения.
В частности, это означает, что, имея достаточное количество измерений, можно определить вероятность, с которой отклик системы на запрос попадёт в тот или иной интервал времени.
Конфигурация стенда
На результаты нагрузочного тестирования могут влиять разные факторы, такие как конфигурация тестового стенда, загруженность сети, заполненность базы данных и многие другие. Причем влияние их на производительность приложения может быть значительным и иметь нелинейную зависимость, поэтому выразить её формулой будет практически невозможно. Следовательно, чем меньше будут разниться параметры тестовой и реальной инфраструктуры, тем меньше будет погрешность в полученных результатах.
При проведении нагрузочного тестирования важно аккуратно подойти к установке инструмента нагрузочного тестирования. Инструмент устанавливается на генератор нагрузки – виртуальную или физическую машину, ресурсы которой используются для создания нагрузки на систему. Генератор нагрузки должен располагаться максимально близко к тестовому окружению. Это необходимо для устранения искажений при подаче нагрузки, вызванных задержками сети, величина которых может варьироваться от нескольких миллисекунд до нескольких десятков секунд.
В самом идеальном случае тестовый стенд один к одному дублирует конфигурацию реального сервера, на котором работает или же будет работать приложение. Однако, как мы с вами знаем, идеальных случаев практически не бывает (то памяти мало, то процессора такой частоты нет в наличии, то операционная система не той версии, то стоимость некоторого серверного ПО не укладывается в бюджете). Перечислим основные причины, по которым не всегда получается продублировать конфигурацию системы на тестовом стенде:
1. Сложность дублирования дорогого серверного железа для тестовых нужд
2. Ограничения на использование лицензий требуемого программного обеспечения
3. Закрытость архитектуры приложения со стороны заказчика по соображениям безопасности
4. Трудность воссоздания или транспортировки базы данных приложения
5. Сложность воссоздания требуемой архитектуры сети
6. и многое другое (всё перечислить крайне сложно из-за большого количества нюансов, влияющих на конфигурацию системы)
Целесообразность же воссоздания инфраструктуры необходимо оценить с учетом выделенных ресурсов, времени и усилий, так как не всегда результат будет оправдывать средства.
Разработка модели нагрузки
Для этого необходимо определить следующее:
В список тестируемых задач должны войти операции, критичные с точки зрения бизнеса, а также с технической точки зрения:
Хотим еще раз подчеркнуть, что под степенью критичности операции мы подразумеваем её влияние на бизнес-процесс и работоспособность системы. Например, создание какого-нибудь отчета, полностью загружающего сервер базы данных в ночное время, не будет носить высокий приоритет для оптимизации, а в рабочие часы будет иметь максимальный приоритет.
Создание и отладка тестов
Напомним, что само по себе нагрузочное тестирование — это автоматизированное тестирование, а значит это разработка, отладка, контрольный запуск и анализ результатов, а не просто запись и запуск (Record & Playback).
Если мы хотим получить удобный для использования и сопровождения набор тестовых скриптов, нам необходимо будет внедрить приемы обеспечения качества: использование стандартов, шаблонов и инструкций. Необходимо договориться об общем использовании одинаковой структуры каталогов, архитектуры скриптов, именовании функций, переменных и транзакций. В итоге каждый участник группы, отвечающей за нагрузочное тестирование, будет знать архитектуру тестового набора, а также без труда сможет прочитать и внести необходимые изменения в скрипт, написанный другим тестировщиком.
Проведение тестирования
С проведением тестирования серверной части приложения всё просто: мы уже создали и отладили скрипты, осталось только запустить и подождать. Но хотелось бы отдельно отметить тестирование производительности клиентской части, о котором речи вообще не было.
Основная цель тестирования клиентской части состоит в измерении времени, необходимого браузеру, для загрузки HTML-страницы. Наиболее важными показателями здесь являются количество загружаемых данных, их объем, а также количество выполненных запросов.
Собрать данную статистику можно как с использованием встроенных инструментов браузера, так и с помощью специализированных инструментов и онлайн-сервисов. Помимо общего веса страницы, инструменты предоставляют детализированную информацию по каждому из компонентов. Изучив параметры запросов, можно обнаружить ряд проблем, приводящих к ухудшению скорости отображения страницы. К примеру, подгружается слишком большая картинка и Javascript, или отправляется значительное количество запросов.
Другая необходимая проверка направлена на анализ заголовков кэширования, поскольку корректность его выполнения при повторном посещении страницы позволяет повысить скорость загрузки страницы до 80%.
Тестирование клиентской части также позволяют обнаружить ряд дефектов, например, отсутствие или некорректную работу элементов на странице.
Анализ результатов
Анализ результатов проводится исходя из изначальных требований. Замеряться и оцениваться может время отклика, количество запросов и процент ошибок, пропускная способность. Но кроме этих характеристик, одним из результатов, получаемых при нагрузочном тестировании и используемых в дальнейшем для анализа, являются показатели производительности приложения. Основные из них разобраны ниже.
1. Потребление ресурсов центрального процессора, %
Метрика, показывающая сколько времени из заданного определённого интервала было потрачено процессором на вычисления для выбранного процесса. В современных системах важным фактором является способность процесса работать в нескольких потоках для того, чтобы процессор мог производить вычисления параллельно. Анализ истории потребления ресурсов процессора может объяснять влияние на общую производительность системы потоков обрабатываемых данных, конфигурации приложения и операционной системы, многопоточности вычислений, и других факторов.
Подготовка, отправка и публикация отчета по проведенному нагрузочному тестированию
Итак, в результате тестирования были получены логи и графики нагрузки. Что с ними делать дальше?
А дальше, используя эти логи и графики, нужно понять, где узкие места, все ли устраивает и какие существуют способы повышения эффективности работы проекта.
Наиболее частые и популярные ошибки при тестировании и интерпретации результатов теста:
· Нет четкой цели, для чего нужно тестирование данного проекта.
· Нередко проводят неправильное нагрузочное тестирование и получают ошибочный вердикт по результатам тестирования.
· Получают большое количество результатов и не могут их растолковать, не знают, что с ними делать.
· Неправильное представление результатов нагрузочного тестирования клиенту. Клиент может не знать всех терминов и инструментов тестирования. Нужно объяснить клиенту результаты тестирования понятным ему языком: «было столько-то, стало столько-то» и «хорошо стало или плохо», а также предложить ему решение проблемы, если она есть.
· DDOS тестируемой системы. Нагрузили систему, и через некоторое время она перестала отвечать. Причина – безнадежно «заDDOSили» инструментами тестирования.
Поэтому при нагрузочном тестировании:
· Нужно обращаться к разным страницам веб-системы.
· Нужно загрузить демо-данные (реальный объем будущего проекта).
· Важно использовать авторизованные хиты.
· Также полезно проверять производительность загрузки статики (CSS, JS).
Здесь можно выявить различные ошибки. Например, верстальщик забыл добавить css-файл, NGINX отдает страницу с 404-й ошибкой через Apache средствами PHP (ошибка администратора). В итоге все слоты Apache заняты обработкой 404-й ошибки, попутно еще загружая сам сайт - получился типичный DDOS сайта. Решение этой проблемы - отдавать легкую статичную страницу с 404-й ошибкой сразу средствами NGINX.
Терминология
Есть большая разница между тем, как будет работать ваше приложение/сервис в зависимости от того, сколько пользователей его используют. То, что работало во время разработки, может развалиться, когда придут первые реальные пользователи со своим окружением, а то, что работало с сотней пользователей, может умереть, когда их станет 10 тысяч. Или бывает, что вы все потестили на искусственных данных, а потом ваша база начинает торзмозить из-за пользователя со специфическим именем.
Современное программное обеспечение просто обязано бесперебойно работать под колоссальными нагрузками. Любого рода проблемы, связанные с плохой производительностью, могут стать причиной отказа клиентов от использования вашего ПО. В связи с этим, проведение качественного нагрузочного тестирования должно стать обязательным, для обеспечения стабильности работы ваших приложений.
Нагрузочное тестирование (Load Testing) или тестирование производительности (Performance Testing) — это автоматизированное тестирование, имитирующее работу определенного количества пользователей на каком-либо общем для них ресурсе.
Термин нагрузочное тестирование может быть использован в различных значениях в профессиональной среде тестирования ПО. В общем случае он означает практику моделирования ожидаемого использования приложения с помощью эмуляции работы нескольких пользователей одновременно. Таким образом, подобное тестирование больше всего подходит для многопользовательских систем, чаще — использующих клиент-серверную архитектуру (например, веб-серверов). Однако и другие типы систем ПО могут быть протестированы подобным способом. Например, текстовый или графический редактор можно заставить прочесть очень большой документ; а финансовый пакет — сгенерировать отчёт на основе данных за несколько лет. Наиболее адекватно спроектированный нагрузочный тест даёт более точные результаты.
Основная цель нагрузочного тестирования заключается в том, чтобы, создав определённую ожидаемую в системе нагрузку (например, посредством виртуальных пользователей) и, использовав идентичное программное и аппаратное обеспечение, наблюдать за показателями производительности системы.
В идеальном случае в качестве критериев успешности нагрузочного тестирования выступают требования к производительности системы, которые формулируются и документируются на стадии разработки функциональных требований к системе до начала программирования основных архитектурных решений. Однако часто бывает так, что такие требования не были четко сформулированы или не были сформулированы вовсе. В этом случае первое нагрузочное тестирование будет являться пробным и основываться на разумных предположениях об ожидаемой нагрузке и потреблении аппаратной части ресурсов.
Начиная работу в области нагрузочного тестирования, следует четко понимать, что это не просто запись и прогон скриптов, а более сложный процесс:
Моделирование нагрузки происходит с помощью специальных продуктов и техник. Что же, чем и как мы собираемся моделировать? Для того чтобы разобраться в этом и нужно определиться с терминологией:
1. Виртуальный пользователь (Virtual User) - программный процесс, циклически выполняющий моделируемые операции.
2. Итерация (Iteration) – это один повтор выполняемой в цикле операции.
3. Интенсивность выполнения операции (Operation Intensity) - частота выполнения операции в единицу времени, в тестовом скрипте задается интервалом времени между итерациями.
4. Нагрузка (Loading) - совокупное выполнение операций на общем ресурсе.
5. Производительность (Performance) - количество выполняемых операций за период времени (N операций за M часов)
6. Масштабируемость приложения (Application Scalability) - пропорциональный рост производительности при увеличении нагрузки.
7. Профиль нагрузки (Performance Profile) — это набор операций с заданными интенсивностями, полученный на основе сбора статистических данных либо определенный путем анализа требований к тестируемой системе.
8. Нагрузочной точкой называется рассчитанное (либо заданное Заказчиком) количество виртуальных пользователей в группах, выполняющих операции с определенными интенсивностями.
Теперь рассмотрим, как эти сущности связаны между собой. Выразив интенсивность через интервал времени между итерациями, видим, что рост интенсивности выполняемых операций — это сокращение интервала времени. Рост нагрузки пропорционален росту интенсивности. Естественно также, что при увеличении интенсивности растет производительность. При этом увеличивается степень использования (загруженности) ресурсов. С какого-то момента рост производительности прекращается (а нагрузка может продолжать расти), происходит насыщение и затем деградация системы. В дополнение можно заметить, что при тестировании изменение интенсивности операций может подчиняться какому-либо закону (например, Пуассона) либо быть равномерным в течение всего теста.
Основные виды тестирования производительности
Тестирование производительности (Performance testing)
Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:
Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить, насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом, цели стрессового тестирования могут пересекаться с целями тестирования производительности.
Данный вид тестирования принято проводить в первую очередь, чтоб выявить предельные возможности системы. Во время стресс-теста нагрузка на систему подается непрерывно до тех пор, пока не будет достигнут один из критериев его остановки. На втором этапе проводится нагрузочный тест (Load Test), с помощью которого оценивается способность системы справляться с длительной нагрузкой (4-8 часов). Количество пользователей для нагрузочного теста определяется в количестве 80% от результата максимальной производительности, выявленной при стресс-тесте.
Объемное тестирование (Volume Testing)
Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит:
Схема подачи нагрузки при данном виде теста такая же, как и при нагрузочном. Для проведения теста требуется база данных, заполненная необходимым объемом данных.
Тестирование стабильности или надежности (Stability / Reliability Testing)
Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты, влияющие именно на стабильность работы.
Дата: 2018-12-28, просмотров: 749.