Лекция
Привет, Вы узнаете о том , что такое нагрузочное тестирование - автоматизация, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое нагрузочное тестирование - автоматизация , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
Современное программное обеспечение просто обязано бесперебойно работать под колоссальными нагрузками. Любого рода проблемы, связанные с плохой производительностью, могут стать причиной отказа клиентов от использования вашего ПО. В связи с этим, проведение качественного нагрузочного тестирования должно стать обязательным, для обеспечения стабильности работы ваших приложений.
Теперь давайте ответим на вопрос: "Что же такое нагрузочное тестирование?", и постараемся более подробно описать процесс проведения нагрузочного тестирования.
Нагрузочное тестирование (Load Testing) или тестирование производительности(Performance Testing) - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.
Начиная работу в области нагрузочного тестирования, следует четко понимать, что это не просто запись и прогон (Record and Playback) скриптов, а более сложный процесс:
Далее предлагаю вам пункт за пунктом углубиться в тестирование производительности:
Также рекомендуем почитать статьи специалистов по нагрузочному тестированию:
Конечно, прочитать все это - не достаточно, чтобы сказать: "Я стал знатоком или экспертом в области тестирования производительности", для этого вам понадобится не один год и не один проект. От себя мы можем только пожелать вам удачи на этом нелегком пути. Если же у вас появятся вопросы, вы можете смело обратиться к нам. Специалисты группы ПроТестинг могут провести консультации по тестированию и обеспечению качества программного обеспечения
Чтобы обсуждать подходы к нагрузочному тестированию и проблемы решаемые с его помощью, предлагаем начать с терминологии. Понимая под различными терминами одни и те же сущности можно говорить на "одном языке".
Нагрузочное тестирование или Тестирование производительности - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе. В качестве примера можно привести работу сотрудников современного банка, в котором все работают с одними и теми же программными приложениями, установленными на банковских серверах. Или использование программного приложения веб магазин, в данном случае посетителями, нагружающими сервера, будут пользователи интернета.
Моделирование нагрузки происходит с помощью специальных продуктов и техник. Что же, чем и как мы собираемся моделировать? Для того чтобы разобраться в этом и нужно определиться с терминологией:
Теперь рассмотрим как эти сущности связаны между собой. Выразив интенсивность через интервал времени между итерациями, видим что рост интенсивности выполняемых операций это сокращение интервала времени. Рост нагрузки пропорционален росту интенсивности. Естественно также, что при увеличении интенсивности растет производительность. При этом увеличивается степень использования (загруженности) ресурсов. С какого-то момента рост производительности прекращается (а нагрузка может продолжать расти), происходит насыщение и затем деградация системы. В дополнение можно заметить что при тестировании изменение интенсивности операций может подчиняться какому либо закону (например, Пуассона) либо быть равномерным в течении всего теста.
Основными целями нагрузочного тестирования являются:
Заметим, что в рамках одной цели могут использоваться разные виды тестов производительности и нагрузки, например, для первой, второй и третьей цели нужно производить как тестирование производительности так и тестирование стабильности. Об этом говорит сайт https://intellect.icu . Но при планировании нагрузочного тестирования логичнее все же отталкиваться от технических целей (а не коммерческих, перечисленных выше), которые достигаются в результате тестирования и классифицировать тесты по ним:
Главное все-таки в том, чтобы понимать цели того или иного тестирования и постараться их достигнуть
Рассматривая этапы проведения нагрузочного тестирования, хотелось бы отметить следующие, на наш взгляд обязательные:
Определившись с видами нагрузочного тестирования, целями и терминологией, перейдем к основной задаче нагрузочного тестировании - разработке модели нагрузки.
Для этого необходимо определить следующее:
В список тестируемых задач должны войти операции, критичные с точки зрения бизнеса, а также с технической точки зрения:
Хотим еще раз подчеркнуть, что под степенью критичности операции мы подразумеваем ее влияние на бизнес процесс и работоспособность системы. Например, создание какого-нибудь отчета, полностью загружающего сервер базы данных в ночное время, не будет носить высокий приоритет для оптимизации, а в рабочие часы будет иметь максимальный приоритет.
Далее предлагаю вам ознакомиться со следующими разделами, шаг за шагом раскрывающими специфику разработки модели нагрузки:
Будем называть тестируемое прикладное программное обеспечение "приложением". Чтобы выделить части приложения, а именно операции, которые будут тестироваться, необходимо провести работу связанную с изучением приложения. Очень большую пользу при этом должны оказать разработчики приложения, если речь идет о тестировании в процессе разработки, либо бизнес пользователи и системные администраторы, если приложение находится в процессе эксплуатации. В ходе этой работы разумно сделать такие шаги:
Еще раз хочется заметить, что опрос бизнес пользователей или совместное исследование с разработчиками и администраторами системы может значительно облегчить задачу. Если приложение находится в эксплуатации, то можно провести мониторинг загрузки компонентов аппаратных серверов (процессора, память, диски) и проанализировать системные журналы веб серверов (снять stats pack, если в качестве сервера базы данных, например, используется Oracle). Системные журналы могут показать пики высокой активности пользователей в течение дня и дать количественное оценки того сколько транзакций (хитов) выполняется в единицу времени. Согласно закону Паретто или принципу 20/80, 20% операций приложения генерируют 80% нагрузки в системе, поэтому нужно стараться выбрать для моделирования именно эти 20% операций.
Ключевым моментом в модели нагрузки являются выбранные для тестирования операции или профиль нагрузки. Естественно выполняться эти операции в тесте должны одновременно. Профилей нагрузки для приложения может быть несколько и это оправдано. Ведь бизнес пользователи могут выполнять разные наборы операций в разное время. Например, начало операционного дня и конец дня, начало месяца (квартала) и соответственно завершение могут отличаться. Таким образом получаем различные наборы операций приложения, выполняющиеся одновременно и соответственно создающие различную нагрузку. Кстати, меняться могут не только сами операции но и их интенсивности. В первом приближении моделью нагрузки является набор профилей нагрузки, где каждый профиль отличается от другого или набором операций или интенсивностями выполнения этих операций.
Пример профиля нагрузки, в который входит 5 операций, значение n может быть различным для каждой операции:
<Профиль нагрузки>
Поскольку в профиле нагрузки как правило присутствует несколько операций - это означает, что у нас будет несколько групп пользователей. Желательно моделировать каждую операцию отдельной группой виртуальных пользователей (хотя в жизни часто бывает наоборот, один бизнес пользователь может отвечать за выполнение нескольких операций). Тем не менее, если назначить одному виртуальному пользователю выполнение одной операции, то так легче выдержать определенную интенсивность (и соответственно производительность) для этой операции в тесте, чем в случае, когда виртуальному пользователю назначается последовательная цепочка операций. Зная интенсивность выполнения операции нужно определить количество виртуальных пользователей в группе, выполняющих эту операцию. Идеальный случай когда работа с приложением аналогична работе заводского конвейера иесть точные оценки сколько операций в день делает один пользователь. Чаще всего бывает не так и известно только общее количество операций выполняемое в течение дня. Так же может оказаться, что интенсивность выполнения операции каждым пользователем очень низкая, например, один пользователь выполняет операцию раз в день или раз в два дня.
Моделирование работы с пересчетом интенсивностей в этом случае можно проиллюстрировать следующим примером
ПРИМЕР: (для одной операции)
Количество операций = 200 за 4 часа
Количество бизнес пользователей = 20
1. Определяем количество операций для каждого пользователя
200/20 = 10
2. В час каждый пользователь выполняет 2.5 операции
10/4 = 2.5
3. Определяем период повторения операции (интенсивность) для каждого пользователя
60/2.5 = 24 минуты
4. Чтобы уменьшить время теста до часа, и при этом получить хоть какую то статистику по выполнению операций, а так же улучшить "перемешивание" операций во время теста, можно увеличить интенсивность в 4 раза, при этом уменьшив количество пользователей так же в 4 раза.
24/4 = 6 мин. = 360 секунд
Таким образом, 5 виртуальных пользователей, выполняя операцию с периодом 6 минут, обеспечат за 4 часа заданную производительность равную 200 операциям.
Что дает такой пересчет:
Во-первых, есть возможность снизить время теста, не теряя статистики выполнения операций, а следовательно и достоверности результатов теста.
Во-вторых, можно снизить количество моделируемых пользователей там где их число уходит за несколько тысяч и таким образом понизить требования к количеству ресурсов нагружающих компьютеров (1VU может требовать до 10Мб оперативной памятинагружающего компьютера ), а в некоторых случаях и выполнить условия лицензионного соглашения (стоимость лицензии для тестового инструментария зависит от количества виртуальных пользователей)
Какие есть ограничения:
Для некоторых приложений, может быть критично количество одновременно открываемых соединений между клиентом и сервером. Встречались ситуации когда запросы к базе данных начинали работать значительно медленнее если при работе с приложением увеличивается количество именно разных пользователей (разные логины) а не интенсивность запросов. И наконец, увеличение интенсивности выполнения операций, не должно приводить к ситуации когда период повторения становится меньше чем время выполнения самой операции.
В любом случае, несмотря на некоторые ограничения, подобный расчет может допускать варьирование количеством виртуальных пользователей и интенсивностью выполнения ими операций. При этом производительность и соответственно нагрузка не должна изменяться и отличаться от заданной. Итак, нагрузочная точка включает в себя расчеты виртуальных пользователей и интенсивностей по всем операциям профиля нагрузки.
Хочется заметить что расчет нагрузочной точки, описанный в разделе Расчет точек нагрузки, основанный на собранной для работающего приложения статистике (или на ожидаемом объеме работы для вновь разработанного приложения), является исходным для дальнейшего роста нагрузки, а самарассчитанная нагрузочная точка может считаться базовой или baseline точкой. Теперь можно увеличивать нагрузку, двигаясь с некоторым шагом, увеличивая при этом только количество виртуальных пользователей в группах, не изменяя интенсивности выполнения операций для одного виртуального пользователя.
Полная модель нагрузки - это набор профилей нагрузки со всеми нагрузочными точками для каждого профиля. При разработке тестовых сценариев должны быть корректно реализованы все нагрузочные точки. Еще хотелось бы добавить, что нагрузочных точек для каждого профиля должно быть не меньше трех, чтобы можно было оценить зависимость времен отклика выполняемых операций от роста нагрузки. Очевидно, что чем линейнее такая зависимость тем лучше масштабируемость приложения и выше предсказуемость его поведения под нагрузкой.
Коммерческие инструменты для автоматизированного нагрузочного тестирования:
| Hewlett-Packard (Mercury Interactive) | HP Performance Center (включает HP LoadRunner) |
| IBM Rational | Rational Performance Tester |
| Borland (Segue) | Silk Performer |
| SmartBear | LoadComplete Web Load Testing |
| Neotys | NeoLoad |
Отдельным пунктом выделим бесплатные инструменты для автоматизированного нагрузочного тестирования:
Выводы из данной статьи про нагрузочное тестирование - автоматизация указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое нагрузочное тестирование - автоматизация и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.