Что такое нагрузочное тестирование программного обеспечения
Обновлено: 25.06.2024
Каковы основные заблуждения, связанные с автоматизированным и нагрузочным тестированием
Когда действительно необходимо автоматизировать тестирование
Каков процент flaky tests в Google
Управление качеством, или Quality Assurance (QA), — процесс многогранный, так или иначе он присутствует во всех составляющих разработки ПО. Грамотная организация QA способствует ускорению Time-to-Market и выводу на рынок изменений с ожидаемым уровнем качества. Автоматизированное и нагрузочное тестирование — неотъемлемые процедуры QA, позволяющие оптимизировать и дополнить базовые подходы к тестированию. В то же время неквалифицированное использование этих процедур увеличивает цикл разработки и приводит к ошибочному пониманию уровня качества программного продукта. Такое тестирование не дает верной картины того, насколько код качественный.
Ниже мы разберем типичные заблуждения, связанные с процессами автоматизированного и нагрузочного тестирования.
Нагрузочное тестирование
1. Методика нагрузочного тестирования (НТ) ― никому не нужный документ, на составление которого уходит много времени. Для того чтобы составить грамотную методику, необходима глубокая аналитика, основанная на нефункциональных требованиях, продуктивной статистике использования или проблематике производительности железа и программного продукта на стороне заказчика.
Авторы
Другие статьи автора
Статьи по теме
В ней должны быть зафиксированы ключевые элементы процесса тестирования: сценарии нагрузки, профили, описание тестовых и продуктивных стендов, целевые метрики и показатели. Важный момент — согласование методики НТ с заказчиком. Без него тестирование даже не стоит начинать. Грамотно разработанная методика способна существенно сократить сроки проведения нагрузки, обеспечить прозрачность и предсказуемость результата.
При проведении нагрузочного тестирования системы управления учетными данными для крупного госзаказчика методика не была должным образом согласована с клиентом до начала работ. После представления результатов тестирования заказчик аргументированно обосновал неудовлетворенность ими и используемыми подходами. В итоге система не была принята в эксплуатацию в срок.
На доработку сценариев и методики нагрузочного тестирования, а также на проведение повторных тестов было потрачено гораздо больше времени, чем планировалось изначально. Этого можно было бы избежать, если бы на подготовительном этапе методика была верно составлена и согласована с заказчиком.
2. Показатели работоспособности продукта под нагрузкой могут быть интересны только инженерам по нагрузочному тестированию. Это абсолютно ошибочное мнение. Показатели производительности продукта важны всем, начиная от аналитиков, архитекторов продукта, инженеров инфраструктуры и заканчивая бизнесом. Они важны так же, как и нефункциональные требования, предъявляемые к продукту.
Сложно делать бизнес, не понимая, на что способны программные решения, которыми приходится пользоваться. Формируя архитектуру системы и составляя технологический стек для нее, специалисты должны учитывать ряд факторов: ее производительность, SLA от смежных систем и их способность обеспечить производительность в рамках единого интеграционного взаимодействия.
Тестирование — итеративный процесс, поэтому необходимо грамотно оценивать трудозатраты. Так, для комплексных интеграционных систем процесс НТ может занять значительную часть времени, отведенного на всю разработку продукта.
3. Проверить производительность любой системы можно за 5 человеко-дней. Очень частое заблуждение, причем со стороны не только бизнеса, но и производства. Процесс нагрузочного тестирования включает не только генерацию большого объема данных для его подачи в систему, но и целый комплекс совместных работ различных специалистов. На разных этапах могут быть задействованы:
- бизнес-аналитик;
- системный аналитик;
- архитектор продукта;
- разработчик;
- инженер DBA;
- администратор инфраструктуры;
- инженер по НТ.
Нагрузочное тестирование будет эффективным только при тесном взаимодействии всех участников и общей заинтересованности в результате.
После каждой итерации НТ необходимо:
- анализировать продуктовые и системные метрики, показывающие влияние нагрузки на железо;
- оптимизировать продукт и/или инфраструктуру с помощью тюнинга настроек серверного ПО или самого продукта;
- документировать результаты для последующей настройки продуктивного стенда.
Поскольку тестирование — процесс итеративный, необходимо грамотно оценивать трудозатраты. В некоторых случаях, например, для комплексных интеграционных систем, процесс НТ может занять значительную часть времени, отведенного на всю разработку продукта. Таким образом, проведение тестирования за 5 дней — чистая профанация.
4. Автоматизация НТ невозможна или малоэффективна. Это не совсем так. Для передовых компаний уже стало традицией включать прохождение сценариев по нагрузочному тестированию в цикл непрерывной интеграции. Для этого выбирают основные сценарии по производительности. Для того чтобы процедуру можно было провести на обычном стенде для функционального тестирования, на него подается не пиковая нагрузка.
Сценарии ограничиваются временем прохождения (не более 1–2 часов) и функциональностью, они также стандартизированы по набору количественных метрик. Цель тестирования — убедиться в том, что уже собранные соседние билды существенно не отличаются по системным и продуктовым показателям при подаче нагрузки.
В данном случае автоматизация нагрузки — надежное подспорье для управления циклом разработки. Она позволяет оперативно узнавать о проблемах, связанных с деградацией показателей производительности, и анализировать их причины. Но данный инструмент плохо работает на краткосрочных проектах, не предполагающих развития (длительностью менее 3–4 месяцев). В этом случае автоматизация нагрузочных тестов — это, скорее, лишние расходы, которые себя не оправдывают.
Мы разрабатывали систему с хранилищем данных объемом более терабайта для крупного российского банка. Детальный анализ хотя бы одной метрики производительности в среднем занимает около полуднЯ и может потребовать привлечения DBA-специалиста. Зачастую это затратно для проекта. Автоматизация сбора критичных для системы метрик и сравнение результатов тестов по ним позволили сократить суммарное время на операцию нагрузочного тестирования до пары часов. Это значительно снизило трудозатраты на тестирование и локализацию нефункциональных дефектов от релиза к релизу.
Автоматизированное тестирование
1. Чем больше автотестов, тем лучше. В данном случае этот количественный показатель напрямую не связан с качеством продукта на выходе. На это влияет качество аналитики и проработки тест-дизайна, на основе которого автоматизировали кейсы. Если за продолжительное время автотесты нашли лишь несколько некритичных дефектов, это повод задуматься, а то ли мы вообще проверяем.
Другой важной составляющей является показатель успешности прогона автотестов. Если из-за проблем со скриптами он стабильно ниже 50%, очевидно, что такая автоматизация неэффективна.
2. Проблему с нестабильными тестами можно решить многочисленными ручными перепрогонами. Flaky tests, или нестабильные тесты — это вечная проблема автоматизации. Избавиться от нее на 100% практически невозможно — все равно какая-то доля тестов даст false positive или false negative. Даже у такого гиганта, как Google, количество flaky tests составляет порядка 1,5%. В других компаниях это число может доходить до 50%. С этим необходимо бороться: подключать разработчиков, дебажить каждый компонент и разбираться, с чем связано конкретное падение автотестов. Причин может быть несколько, начиная c серьезных проблем в самом продукте и заканчивая некорректно настроенной инфраструктурой и ошибками в скриптах.
Обратная ситуация тоже валидна: необходимо убедиться, что автотесты действительно проверяют то, что требуется. Поэтому важно хотя бы раз пройти сценарии вручную и удостовериться, что обнаруженные дефекты коррелируют с тем, что нашли автотесты.
Мы проводили анализ автоматизации для крупной компании: тестировалась сложная интеграционная система. Выяснилось, что было разработано несколько сотен автотестов, которые запускались ежедневно на нескольких окружениях. Доля flaky tests в проекте составляла 60% (!). На стороне заказчика был выделен сотрудник, который регулярно прогонял автотесты до тех пор, пока они не становились зелеными на одном и том же билде. Мы провели аудит стека автотестов, выкинули из него неэффективные, а оставшиеся переписали.
3. 100-процентная автоматизация гарантирует успешный вывод в продуктивную эксплуатацию. Автоматизированное тестирование в первую очередь нужно для сокращения времени на принятие решения. Но на его основе нельзя делать полноценные выводы о выпуске продукта в прод. Это решение должен принимать человек. Здесь важна комплексная оценка: качество тестового покрытия требований, успешность прогона автоматических и ручных кейсов, критичность обнаруженных дефектов, сроки их исправления.
Нельзя сбрасывать со счетов и нефункциональную составляющую: удобство интерфейса продукта и скорость его отклика, возможность многопользовательской работы, уязвимость решения перед атаками хакеров.
Автоматизация нагрузки — подспорье для управления циклом разработки. Она позволяет оперативно узнавать о проблемах, связанных с деградацией показателей производительности, и анализировать их причины.
Чтобы минимизировать риски, в ряде случаев необходимо провести ручное приемочное тестирование в среде, близкой к продуктивной, с использованием реальных данных. А затем, уже с учетом перечисленных факторов, принимать итоговое решение. Раскатка всех компонент на продуктивные серверы должна осуществляться автоматически, причем в полном соответствии с тем, как это делалось на тестовых и препродакшен-стендах. Для этого можно использовать механизмы Continuous Integration и Continuous Deployment. Мы используем Development Pipeline, настроенный таким образом, чтобы каждое изменение в продукте проходило ряд автоматических проверок и далее раскатывалось на нужный стенд.
Сегодня мы немного поговорим про теорию тестирования. Очень часто можно услышать вопрос: “Как же правильно говорить: Нагрузочное тестирование или Тестирование производительности? И чем одно от другого отличается?”. В русскоязычной среде термины “Нагрузочное тестирование” и “Тестирование производительности” перепутаны, и не всегда понятно откуда что взялось.
На текущий момент существует множество видов тестирования также существует большое количество классификаций эти видов. Основная классификация видов тестирования происходит по целям. На рисунке ниже представленная классификация видов тестирования.
Классификацию тестирования можно продолжать и дальше, разделяя на ещё более атомарные единицы данные типы тестирования. Основная сложность при классификации видов тестирования заключается в том, что в основном все стандарты существуют на английском языке, и при переводе терминов могут возникать коллизии взаимозависимости от того, как тот или иной термин будет переведен на русский язык. В связи с этим, кроме русского перевода вида тестирования в скобочках будет указываться его английское наименование. В рамках данной статьи мы рассмотрим более подробно тестирование производительности (Performance Testing).
Считается, что тестирование производительности [1] — это то тестирование, которое не является функциональным. Существует множество видов тестирования производительности. Классификация видов тестирования производительности строится на основе того, какие цели преследует определенный вид тестирования. Как правило тестирование производительности преследует не одну, а несколько целей в связи с тем, многие типы тестирования в ходе его проведения совмещаются с другими целями или повторяются несколько раз в ходе цикла тестирования. Основное отличие тестирования производительности также заключается в том, что оно происходит только после полного функционального тестирования. Ошибки функциональности не исправляются в ходе тестирования производительности. Для данного вида тестирования чаще всего выделяется отдельный нагрузочный стенд, повторяющий копию промышленного стенда. В связи с массовым распространением Agile методологий тестирование производительности также интегрируется в жизненный цикл разработки программного обеспечения.
На рисунке ниже показана основная классификация видов тестирования производительности.
На основе классификации показанной на рисунке выше можно выделить основные виды тестирования, которые производятся во время этапа тестирования производительности системы. Основные типы тестирования и вопросы, которые они решают представлены в таблице.
| № | Вид тестирования | Вид тестирования по английский | Вопрос на который отвечает тестирование |
|---|---|---|---|
| 1 | Нагрузочное тестирование | Load Testing[2] | Достаточно ли быстро работает система? |
| 2 | Тестирование стабильности | Stability Testing[3] | Достаточно ли надежно работает система на долгом интервале времени? |
| 3 | Тестирование отказоустойчивости | Failover Testing[4] | Сможет ли система переместиться сама на другой сервер в случае сбоя основного сервера? |
| 4 | Тестирование восстановления | Recovery Testing[5] | Как быстро восстановится система? |
| 5 | Стрессовое тестирование | Stress Testing[6] | Что произойдет при незапланированной нагрузке? |
| 6 | Тестирование объемов | Volume Testing[7] | Как будет работать система, если объем базы данных увечится в 100 раз? |
| 7 | Тестирование масштабируемости | Scalability Testing[8] | Как будет увеличиться нагрузка на компоненты системы при увеличении числа пользователей? |
| 8 | Тестирование потенциальных возможностей | Capacity Testing[9] | Какое количество пользователей может работать? |
| 9 | Конфигурационное тестирование | Configuration Testing[10] | Как заставить систему работать быстрее? |
| 10 | Тестирование сравнения | Compare Testing[11] | Какое оборудование и ПО выбрать? |
Нагрузочное тестирование (load testing)
Нагрузочное тестирование (load testing) – данный тип тестирования позволяет оценить поведение системы при возрастающей нагрузке, целью нагрузочного тестирования является также определение максимальной нагрузки, которую может выдержать система.
Это наиболее распространенный и известный тип тестирования, и поэтому в русскоязычной среде он на слуху. Часто в рунете, особенно те, кто не в теме QA, под нагрузочным тестированием понимают все виды испытаний. Но, в англоязычной литературе, это всего лишь подвид тестирования производительности.
Рассмотрим его подробнее: В роли нагрузки может выступать количество пользователей, а также количество операций на сервере.
Производительность при этом определяется следующими факторами:
- скоростью работы программного обеспечения;
- скоростью работы аппаратного обеспечения;
- скоростью работы сети.
Во время тестирования могут осуществляться следующие операции, позволяющие более точно измерить производительность и определить “узкое место” системы [12]:
- измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций;
- определение количества пользователей, одновременно работающих с приложением;
- определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций).
После нахождения максимальной производительности рекомендуется её “подтвердить”. Для этого проводится дополнительный тест со следующим профилем:
Тестирование стабильности (stability testing)
Тестирование стабильности (stability testing) — позволяет проверить работоспособность системы на длительном интервале времени. При этом нагрузка может не достигать пиковых значений, а иметь средние значение, так же само время выполнения операций не являет основным фактором в оценке результатов тестирования.
В ходе тестирования основной акцент делается на измерение
- отсутствие утечек памяти;
- отсутствие перезапусков серверов;
- отсутствие перезапусков программного обеспечения;
- любые ошибки, связанные с накоплением данных;
- отсутствие отключений или сбоев в работе сетевого оборудования.
Тестирование отказоустойчивости (failover testing)
Тестирование отказоустойчивости (failover testing) – данный вид тестирования производительности позволяет проверить поведение системы в случает сбоя серверов или при других неблагоприятных факторах. Такое тестирование особенно важно в системах, работающих в режиме 24/7, т.к. в случае их выхода из строя возможны потери клиентов, репутации, денег и т.п.
Во время тестирования проверяются следующие операции:
- как будет преодолеваться отказ, а именно как система будет перемещать операции между мощностями работающего и нет оборудования;
- как будет осуществлен перехват управления системой при отказе управляющего сервера;
- как будет осуществлен обход и обработка отказа (переключение на резервный канал связи, отправка данных по другому маршруту и т.д.).
Тестирование восстановления (recovery testing)
Тестирование восстановления (recovery testing) – обычно неотъемлемо связан с тестированием отказоустойчивости и позволяет определить, как быстро система сможет восстановится после сбоя её программной или аппаратной части. Сам сбой производится тестировщиком путём отключения, например, одного из серверов или его перезагрузки. Тестирование не нацелено на проверку надёжности системы. При этом нагрузка на систему не уменьшается и имеет средние или пороговое значение.
В ходе тестирования измеряются следующие показатели:
- время, за которое система восстановится после сбоя;
- корректность восстановленных данных.
Стрессовое тестирование (stress testing)
Стрессовое тестирование (stress testing) — целью данного вида тестирования производительности является оценка производительности системы при пороговых значениях рабочей нагрузки или за её пределом. Также в ходе тестирования можно оценивать работу системы при изменении ресурсов доступных системе таких как процессорное время, память, ширина сетевого канала и т.д.
В ходе тестирования измеряется:
- возможность и время регенерации системы – возможность и время возвращения системы к нормальному состоянию после стрессовых нагрузок;
- корректность логирования ошибок и оповещений о их возникновении;
- производительность системы при стрессовой нагрузке;
- оценка влияния сбоев тестируемой системы на внешние системы.
Тестирование объемов (volume testing)
Объемное тестирование (volume testing) — тестирование позволяет оценить производительность системы при увеличении объёмов данных как самого приложения, так и его базы данных. Основной вопрос, на который отвечает данный вид тестирования производительности: “Что будет завтра с этим приложением или через год при увеличении числа пользователей и/или увеличение хранимых пользовательский и системных данных?”.
Во время тестирования измеряются следующие параметры:
- зависимость времени выполнения операций на сервере от объема данных;
- количество пользователей, которые могут одновременно работать с приложением “быстро”;
- как быстро увеличивается объем данных при работе приложения.
Тестирование масштабируемости (scalability testing)
Тестирование масштабируемости (scalability testing)[13] – данное тестирование производится для проверки возможностей масштабирования приложения под любым видом нагрузки. Также необходимо проверять производительность системы во время масштабирования.
Виды масштабирования, которые проверяются в ходе тестирования:
- вертикальное масштабирование – увеличения производительности каждого отдельного компонента системы (добавление оперативной памяти на сервере, замена процессора и т.д.) для повышения производительности всей системы в целом;
- горизонтальное масштабирование – распределение системы на большее количество серверов параллельно работающих и выполняющих одни и те же функции;
- применение временного масштабирования внутри системы с помощью очередей, асинхронных запросов и т.п.
Тестирование потенциальных возможностей (capacity testing)
Тестирование потенциальных возможностей (capacity testing) – является отчасти подвидом тестирования масштабируемости. Если в тестирование масштабируемости основной вопрос, который ставится: насколько хорошо справляется система с возрастающим количеством пользователей (нагрузки). То в данном случае вопрос звучит следующим образом: сколько пользователей (с какой нагрузкой) может работать с системой при этом время отклика и другие параметры производительности должны находится в пределах допустимых значений? Данный вид тестирования позволяет определить стратегию масштабирования и вообще понять, а стоит ли масштабировать систему?
Конфигурационное тестирование (configuration testing)
Конфигурационное тестирование (configuration testing) [14] – данный вид тестирования проверяет производительность системы на разных аппаратных и программных конфигурациях. В ходе тестирования измеряются основные показатели производительности системы при средних и пороговых значениях нагрузки. Данное вид тестирования производительности позволяет убедится, что на других конфигурациях аппаратного и программного обеспечения система будет работать с одинаковой производительностью.
Тестирования сравнения (compare testing)
Тестирования сравнения (compare testing) – позволяет сравнить производительности на разной конфигурации программной и аппаратной части системы. Данное тестирование помогает выбирать наиболее оптимальную конфигурацию аппаратного и программного обеспечения. В ходе тестирования производится проверка на разных конфигурациях, при этом профиль тестирования не изменяется от конфигурации к конфигурации и имеет среднюю или пороговую интенсивность нагрузки.
Тестирование позволяет ответить на такие вопросы как:
- какую СУБД выбрать?
- какое оборудование выбрать (платформа, производитель, цена и т.д.)?
- как повлияют на работу приложения обновления и патчи?
Ну хорошо, из этой статьи мы видим что видов тестирования Производительности много. Очень много, даже слишком много. А какой нужно использовать для конкретно нашей системы? А почему? А сколько делать по времени тесты стабильности? А нужно ли проводить тестирование изолированно или в комплексе с интеграцией? А что делать если нет стенда, сил, времени на такое тестирование? Обращайтесь к нам, в Перфоманс Лаб, мы с удовольствием вам поможем.
По мере роста и усложнения сайтов и приложений главной проблемой разработчиков становится обеспечение высокой производительности. Все современные исследования говорят о том, что от производительности сайта напрямую зависит количество посетителей, рост продаж и увеличение трафика. Потому так важно обратить внимание на то, как быстро пользователи могут получить доступ к сайту в браузере.
Данная статья расскажет об основных понятиях и открытых инструментах для оптимизации производительности. С ее помощью вы сможете выяснить, как быстро ваш сервер отвечает на запросы пользователей, и разработать индивидуальный план.
Основные понятия
Для начала нужно ознакомиться с базовыми терминами и понятиями.
- Задержка – это показатель того, насколько быстро сервер реагирует на запросы клиента. Обычно измеряется в миллисекундах (мс). Задержка также часто называется временем отклика. Чем ниже этот показатель, тем быстрее сервер обрабатывает запрос. Задержка измеряется на стороне клиента с момента отправки запроса до получения ответа. В этот показатель включены затраты сетевых ресурсов.
- Пропускная способность – это количество запросов, которые сервер может обрабатывать в течение определенного промежутка времени. Обычно этот показатель измеряется в запросах в секунду.
- Процентиль – это способ группировки результатов по проценту от всего набора данных.
Основы нагрузочного тестирования
- Достаточно ли у сервера ресурсов (памяти, CPU и т. п.), чтобы обработать ожидаемый трафик?
- Достаточно ли быстро реагирует сервер, чтобы обеспечить хороший пользовательский опыт?
- Эффективно ли работает приложение?
- Нужно ли серверу вертикальное или горизонтальное масштабирование?
- Есть ли особо ресурсозатратные страницы или вызовы API?
Нагрузочное тестирование выполняется путем запуска специального программного обеспечения на одном компьютере (или в кластере машин). Это ПО генерирует большое количество запросов и отправляет их на веб-сервер на втором компьютере (или в другой инфраструктуре). Существует много таких инструментов, позже мы рассмотрим некоторые их них. На данный момент сосредоточимся на общих терминах, которые будут актуальны независимо от того, какое средство для нагрузочного тестирования вы выберете. Обычное программное обеспечение для нагрузочного тестирования используется для определения максимального количества запросов в секунду, которое может обрабатывать сервер. Для этого на сервер отправляется как можно большее количество запросов; затем нужно проверить, сколько из них сервер смог обработать успешно.
Общая тенденция такова: чем выше нагрузка (чем больше запросов в секунду), тем выше задержка. Чтобы получить более реальную картину о задержке сервера при заданной нагрузке, нужно будет протестировать его несколько раз с разным количеством запросов. Не все приложения для тестирования нагрузки способны на это, но немного позже мы ознакомимся с wrk2 (это средство командной строки для тестирования нагрузки, которое может выполнить эту функцию).
Как определить разумный показатель задержки?
Время загрузки веб-сайта в диапазоне 2-5 секунд – обычное дело, но часть времени, связанная с задержкой веб-сервера, обычно составляет около 50-200 миллисекунд. Идеальный показатель задержки индивидуален для каждого сайта. Он зависит от большого количества факторов (аудитории, рынка, целей сайта, наличия пользовательского интерфейса или API и т. д.). Имейте в виду: большинство исследований показывают, что в производительности учитывается каждый маленький бит скорости, и даже совсем незаметные улучшения приводят к улучшению результатов в целом.
Планирование нагрузочного тестирования
Чтобы понять, как работает сервер и веб-приложение и как они реагируют на нагрузку, можно предпринять несколько общих действий. Во-первых, во время тестирования нужно отслеживать правильные системные ресурсы. Затем нужно определить максимальное количество запросов в секунду, которое может обработать данный сервер. Также следует определить пропускную способность, при которой задержка сервера приведет к низкой производительности и плохому пользовательскому опыту.
1: Мониторинг ресурсов
Программное обеспечение для нагрузочного тестирования соберет и предоставит информацию о запросах и задержках. Но есть и некоторые другие системные показатели, которые нужно отслеживать, чтобы понять, каких ресурсов не хватает серверу при работе с большими объемами трафика.
В основном это касается нагрузки процессора и свободной памяти: мониторинг этих данных при большой нагрузке поможет вам принять более обоснованные решения о том, как масштабировать инфраструктуру и где сосредоточить усилия при разработке приложения.
Если у вас уже есть система мониторинга типа Prometheus, Graphite или CollectD, вы сможете собрать все необходимые данные.
Если такой системы нет, подключитесь к веб-серверу и используйте следующие инструменты командной строки для мониторинга в реальном времени.
Для мониторинга доступной памяти используйте команду free. В комбинации с командой watch данные будут обновляться каждые 2 секунды.
Флаг -h выводит числа в удобочитаемом формате.
total used free shared buffers cached
Mem: 489M 261M 228M 352K 7.5M 213M
-/+ buffers/cache: 39M 450M
Swap: 0B 0B 0B
Выделенное число в выводе представляет свободную память после вычитания буфера и кэша. Новые версии free выводят другие результаты:
. total used free shared buff/cache available
Mem: 488M 182M 34M 14M 271M 260M
Swap: 0B 0B 0B
Новый столбец available вычисляется по-разному, но обычно представляет одну и ту же метрику: текущий объем доступной памяти для приложений.
Для мониторинга использования CPU в командной строке есть утилита mpstat, которая выводит количество свободных ресурсов CPU. По умолчанию утилита mpstat не установлена в Ubuntu. Вы можете установить ее с помощью следующей команды:
sudo apt-get install sysstat
При запуске mpstat нужно задать интервал обновления данных в секундах:
Она выведет строку заголовков, а затем строку статистики, и будет обновляться каждые две секунды:
Linux 4.4.0-66-generic (example-server) 08/21/2017 _x86_64_ (4 CPU)
08:06:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:06:28 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
08:06:30 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
Столбец %idle показывает, какой процент ресурсов ЦП не используется. Загрузка процессора часто разделяется на разные категории (user CPU и system CPU).
2: Определение максимальной скорости отклика
Как говорилось ранее, большинство программ нагрузочного тестирования особенно хорошо подходят для поиска максимальной скорости ответа веб-сервера. Как правило, при этом нужно указать только конкурентность и продолжительность тестирования.
Конкурентность – это показатель, который отображает количество параллельных подключений, которое может обрабатывать сервер. Значение по умолчанию 100 подходит в большинстве случаев, но вы можете выбрать индивидуальное значение. Для этого нужно проверить MaxClients, MaxThreads сервера и другие подобные параметры.
Также вам нужно будет выбрать URL-адрес для тестирования. Если ваше программное обеспечение может обрабатывать только один URL за один раз, стоит выполнить несколько тестов для разных URL-адресов, так как требования к обработке могут сильно различаться в зависимости от страницы. Например, требования к загрузке домашней страницы сайта и страницы продукта разные.
Некоторое программное обеспечение для нагрузочного тестирования позволяет сразу указать несколько URL-адресов, которые нужно проверить. Это позволяет более точно имитировать реальный трафик. Если у вас есть данные об использовании сайта (из аналитического программного обеспечения или логов сервера), вы можете применить эти данные в тестировании.
Отобрав URL-адреса, запустите тестирование. Убедитесь, что программное обеспечение очень быстро отправляет запросы. Если программное обеспечение разрешает выбрать скорость запроса, выберите значение, которое почти наверняка будет слишком высоким для вашего сервера. Если программное позволяет установить задержку между запросами, уменьшите это значение до нуля.
Использование ресурсов процессора и памяти будет увеличиваться. Свободные ресурсы процессора могут достигать 0%, и клиент может получить ошибку соединения. Это нормально, поскольку сервер работает на пределе возможностей.
Когда тестирование закончится, программное обеспечение выведет статистические данные, включая количество запросов в секунду. Обратите внимание на время отклика: этот показатель, вероятно, будет очень плохим, так как сервер должен быть чрезвычайно перегружен во время теста. Поэтому количество запросов в секунду не является точным показателем максимальной пропускной способности сервера, но это хорошее начало для дальнейшего исследования.
Затем нужно повторить тестирование, чтобы получить дополнительную информацию о том, как работает сервер на пределе ресурсов.
3: Определение максимальной пропускной способности
На данном этапе нужно использовать программное обеспечение, которое может немного ускорить загрузку, чтобы проверить производительность сервера на разных уровнях пропускной способности. Некоторые программы позволяют указывать задержку между каждым запросом, но это затрудняет определение точной пропускной способности.
Здесь можно обратиться к инструменту wrk2, который позволяет указывать точное количество запросов в секунду.
Возьмите максимальную скорость запросов, которую вы определили на предыдущем этапе, и разделите ее на 2. Запустите еще один тест с новыми данными и обратите внимание на время ответа. Находится ли показатель в приемлемом диапазоне?
Если да, увеличьте значение до максимума и повторите тестирование, пока задержка не достигнет максимального значения, которое вы считаете приемлемым. Это и будет фактическая максимальная скорость ответа, которую может обрабатывать ваш сервер.
Инструменты для нагрузочного тестирования
Существует множество программных пакетов с открытым исходным кодом для нагрузочного тестирования серверов. Кроме того, существует множество платных сервисов, которые умеют автоматически создавать графики и отчеты на основе данных, полученных в ходе тестирования. Эти сервисы отлично подходят крупным сайтам, которым необходимо генерировать высокую нагрузку для тестирования большой инфраструктуры.
Тем не менее, некоторые из открытых инструментов также могут работать в режиме кластера. Рассмотрим несколько наиболее популярных инструментов с открытым исходным кодом.
Инструмент ab
Поскольку он является однопоточным, инструмент ab не может использовать несколько процессоров для отправки большого количества запросов. Он не подойдет, если вы хотите полностью нагрузить мощный веб-сервер.
Базовый вызов команды ab выглядит следующим образом:
Флаг –n задает количество запросов. Флаг –с задает конкурентность. Затем нужно указать URL, который нужно протестировать. Вывод (выдержка из которого приведена ниже) указывает количество запросов в секунду, время запроса и список процентилей времени ответа:
JMeter
JMeter – это мощное и многофункциональное приложение для нагрузочного и функционального тестирования от Apache Software Foundation. Функциональное тестирование – это проверка вывода приложения.
JMeter предлагает графический интерфейс Java для настройки тестовых планов.
Планы тестирования можно записать с помощью прокси-сервера JMeter и обычного браузера. Это позволяет вам использовать в тестах трафик, который более точно имитирует реальную работу сервера.
JMeter может выводить информацию о процентилях в отчетах HTML и других форматах.
Siege
Siege – еще один инструмент командной строки для нагрузочного тестирования. Он похож на ab, но имеет несколько дополнительных функций. Siege – многопоточный инструмент, что обеспечивает относительно высокую пропускную способность. Он также позволяет указать сразу несколько URL-адресов для нагрузочного тестирования. Базовый вызов выглядит так:
Флаг –с указывает конкурентность. Флаг -t определяет продолжительность тестирования (в данном случае – 30 секунд). Siege выводит среднее время отклика и скорость запроса:
. . .
Transactions: 5810 hits
Availability: 100.00 %
Elapsed time: 29.47 secs
Data transferred: 135.13 MB
Response time: 0.01 secs
Transaction rate: 197.15 trans/sec
Throughput: 4.59 MB/sec
Concurrency: 2.23
. . .
Siege не предоставляет процентилей для статистики задержек.
Locust
Locust – это инструмент для нагрузочного тестирования на основе Python, который предоставляет веб-интерфейс для мониторинга результатов в реальном времени.
Сценарии тестирования Locust пишутся с помощью кода Python, что предоставляет дополнительные преимущества тем, кто хорошо знаком с этим языком программирования.
Locust также можно запускать в распределенном режиме: вы можете запустить кластер из серверов Locust, который будет создавать высокую нагрузку вашего сервера. Это позволяет выполнить качественное нагрузочное тестирование целой инфраструктуры веб-серверов.
Locust может предоставить подробную статистику в CSV-файлах, которые можно загрузить.
Инструмент wrk2
wrk2 – это многопоточный инструмент командной строки для нагрузочного тестирования, способный производить нагрузку с заданной частотой запросов. Он может предоставлять подробную статистику задержек и поддерживает сценарии на языке программирования Lua.
wrk2 вызывается командой wrk:
Параметр -t определяет количество потоков (в данном случае их 4, здесь нужно использовать количество процессорных ядер вашего сервера). Параметр -c указывает количество одновременных запросов (здесь 100). Флаг –d определяет продолжительность тестирования (30 секунд). Флаг –R указывает частоту запросов в секунду (100). Подробный вывод задержки предоставит флаг –latency.
. . .
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 5.79ms
75.000% 7.58ms
90.000% 10.19ms
99.000% 29.30ms
99.900% 30.69ms
99.990% 31.36ms
99.999% 31.36ms
100.000% 31.36ms
. . .
Заключение
В этой статье мы рассмотрели терминологию и основные понятия нагрузочного тестирования, ознакомились с планированием тестов и рассмотрели некоторые из доступных открытых инструментов для тестирования.
Определив производительность инфраструктуры, вы можете использовать эту информацию, чтобы попытаться улучшить время отклика и снизить нагрузку на сервер. Возможно, вы примете решение в пользу вертикального или горизонтального масштабирования. Вы можете оптимизировать конфигурацию своего веб-сервера: изменить количество поддерживаемых подключений, рабочих процессов или потоков. Вы также можете оптимизировать кэширование часто используемых данных, уменьшить нагрузку на базу данных и время запроса.
Нагрузочное тестирование (англ. Load Testing) – процесс умышленной нагрузки системы, путем подачи множества запросов на саму систему или устройство, с целью определения показателей производительности, времени отклика, проверки соответствия требованиям, которые были предъявлены к данной системе или отдельному устройству
Этапы нагрузочного тестирования
- Разработка и согласование моделей нагрузки. Для модели отбираются критичные для данного вида тестирования операции, определяются интенсивность их выполнения в тесте. Определяются профили нагрузок, если испытуемое приложение имеет различные модели поведения. Рассчитываются нагрузочные точки.
- Для моделируемых операций разрабатываются нагрузочные скрипты и создаются необходимые пулы данных.
- Разрабатываются сценарии выполнения скриптов, которые соответствуют профилям модели нагрузки.
- Проводится проверка работы скриптов в сценариях. Необходимо выполнить каждый скрипт, входящий в сценарий, используя хотя бы несколько виртуальных пользователей в группе, чтобы исключить ошибки взаимного влияния скриптов друг на друга. Тут же могут быть обнаружены скрипты с недостаточно хорошо сделанной корреляцией.
Нагрузочное тестирование онлайн
Для чего нужно нагрузочное тестирование сайта? Нагрузка на хостинг или сервер Вашего сайта растет и может создать нагрузку, которая будет критичной для работы сайта. Мы проводим нагрузочное тестирование для предотвращения подобных проблем с помощи комплексного стресс-теста. Основное направление деятельности компании направлено на осуществление контроля качества разрабатываемых высокотехнологичных продуктов на всем протяжении жизненного цикла их разработки. Востребованными услугами являются проблемы тестовых исследований взаимодействия человека и программного продукта, функциональное нагрузочное тестирование и тестирование безопасности применения ПО.
Цели нагрузочного тестирования:
- Оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию;
- Оценка производительности и работоспособности приложения на этапе выпуска новых релизов;
- Оптимизация производительности приложения, настройка серверов и оптимизация кода
- Подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера
Оборудование тестового стенда должно как можно ближе соответствовать промышленной конфигурации. Особенно если на основе полученных в результате тестирования времени выполнения операций будут приниматься бизнес решения. Если речь идет об оптимизации приложения, то соответствие конфигураций тестового стенда и промышленного уже не так актуально. Для мониторинга тестовых серверов необходимо иметь доступ на сервера с правами для использования необходимых утилит, например, MS Windows Performance для MS Windows или sar, iostat, vmstat для unix-образных OS.
Инструменты и сценарии нагрузочного тестирования
Первые запуски тестов являются пробными и позволяют понять поведение системы в целом: работу приложения и оборудования. Начинать испытания надо с нагрузочных точек с меньшей нагрузкой, двигаясь по мере нарастания нагрузки от меньшей к большей. В процессе тестирования количество нагрузочных точек может поменяться и изменятся количества виртуальных пользователей, входящих в ту или иную нагрузочную точку. Результаты испытаний, должны быть логически согласованы и при увеличении нагрузки, результаты времени выполнения операций и загрузки тестового оборудования, должны соответственно изменяться. Если на нагрузочной точке с большей нагрузкой результаты лучше, то такой эксперимент надо провести заново, чтобы понять причины такого “выброса”. Возможна ситуация, что нагрузочные точки были неправильно спроектированы и возможно нужно увеличить размер “шага”, чтобы действительно почувствовать увеличение нагрузки. Набор экспериментов и результатов, должны быть достаточны для того, чтобы можно было провести анализ “узких” мест и сделать выводы о производительности и стабильности работы тестируемого приложения.
Тестирование производительности (Performance testing)
Задача тестирования производительности определить масштабируемость приложения под нагрузкой:
- измеряется время выполнения операций при определенных интенсивностях выполнения
- определяется количество пользователей, одновременно работающих с приложением
- определяется границы приемлемой производительности при увеличении нагрузки
- проводится исследование производительности на высоких, предельных и стрессовых нагрузках
Тестирование стабильности (Stability / Reliability Testing)
Тестирование стабильности (надежности) проверяет работоспособность приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций играет второстепенную роль, а на первое место выходит отсутствие утечек памяти, перезапуски серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.
Стрессовое тестирование (Stress Testing)
Стрессовое тестирование проверяет работоспособность приложения или системы в целом в условиях стресса. Помогает оценить способность системы к возвращению в нормальное состояние после прекращения воздействия нагрузки. Нагрузкой может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Частной задачей стрессового тестирования может быть оценка деградации производительности.
Объемное тестирование (Volume Testing)
Объемное тестирование позволяет оценить производительность при увеличении объемов данных в базе данных приложения:
- измеряется время выполнения операций при одновременном интенсивном выполнении
- производиться определение количества пользователей, одновременно работающих с приложением
Согласно положениям современной системной инженерии процедура тестирования не должна являться конечным этапом в процессе создания программного обеспечения. Ошибки в процессе создания подобного рода продуктов не выявленные на этапе их возникновения будут накапливаться, поэтому, так важно своевременное их обнаружение и устранение. Сам процесс тестирования должен применяться не только к программам, но и к интерфейсам или электронному оборудованию.
Компания производит тестирование в несколько этапов, которые состоят из:
• анализа требований, которые были предъявлены разработчиками к своему продукту и их корректность;
• разработки чек-листа тестирования;
• проведения тестовых процедур;
• определения полноты соответствия заявленных требований к результатам тестирования;
• выработке отчета или об успешности теста, либо о выявленных нарушениях в функционировании программного продукта.
Целью проведения проверки степени безопасности продукта, является определение его уязвимости к воздействию вирусов или внешних атак хакеров. От этого показателя напрямую зависит правильность и надежность работы, как программ, так и оборудования. Конечный потребитель должен получить гарантии того, что установка нового продукта не снизит производительность и не поставит под угрозу целостность системы. Безопасность это также конфиденциальность и низкий уровень доступности. Целостность системы оценивается ее способностью к самовосстановлению, после внешнего проникновения или при несанкционированном воздействии.
Мы проводим комплекс работ любой сложности и обладаем лабораторией, квалифицированными специалистами и собственными инструментами разработки и проведения тестовых работ.
Тестирование производительности тестирования программного обеспечения
Тестирование производительности тестирования программного обеспечения
Тестирование производительности связано со временем。
Основное содержание
- Основы тестирования производительности
- Введение в понятия и терминологию
- Модель теста производительности
- Введение в классификацию тестов производительности
- Внедрение и управление тестом производительности
Основы тестирования производительности
Зачем проводить тестирование производительности (ПОЧЕМУ) (наиболее важно)
- Может ли приложение быстро отвечать на запросы пользователей?
- Может ли приложение обрабатывать ожидаемую пользовательскую нагрузку и иметь избыточную емкость?
- Может ли приложение обрабатывать количество транзакций, необходимых бизнесу?
- Стабильно ли приложение при ожидаемых и неожиданных пользовательских нагрузках?
Можете ли вы гарантировать, что пользователям будет удобно работать с программным обеспечением?
Основная причина проблемы, как правило,：
Сотни серверов на нескольких платформах; гетерогенные системы, несколько приложений; тысячи рабочих станций; локальные сети, глобальные сети и архитектура распределенных сетей других типов; Точка неудачи.
Миф: Вы можете улучшить производительность, увеличив конфигурацию оборудования, поэтому тестирование производительности не имеет значения?
Это утверждение неверно. Проблема может быть решена только временно, а не принципиально.
На что следует обратить внимание при выполнении тестов производительности? (ЧТО)
- Параллельные пользователи, пропускная способность
- Среднее время отклика
- Занятость ресурса сервера
- Надежность и масштабируемость
- Определите причины системных проблем и обратите внимание на то, какие методы используются для повышения производительности системы.
- Подходит ли конфигурация программного и аппаратного обеспечения (планирование емкости, выбор оборудования)
Кто обратит внимание? (ВОЗ)
Каковы основные проблемы? (Где)
- Проверка квалификации
- Самый простой и наиболее часто используемый в тестировании производительности. Основная проблема: может ли система работать в ожидаемых условиях при данных условиях?
- Основная проблема: как мы можем заставить систему иметь требуемые нам характеристики производительности?
- Раунды настройки производительности деятельности переплетаются с действиями в других областях. Это область приложения для тестирования производительности, которая может быть задействована как на стадии разработки, так и на стадии тестирования.
- Основная цель - найти дефекты в системе с помощью тестирования производительности.
Миф:
Тестирование производительности не зависит от функционального тестирования.
Это утверждение неверно. Тестирование производительности зависит от функционального тестирования.Когда проводится тестирование производительности? (ПРИ)
- Обычно проводится на среднем и позднем этапах функционального тестирования.
Введение в понятия и терминологию
Тестирование производительности заключается в тестировании различных показателей производительности системы путем моделирования различных нормальных, пиковых и аномальных условий нагрузки с помощью инструментов автоматического тестирования.
Какие показатели эффективности обычно связаны с тестированием производительности?
Номер одновременно
Количество одновременных пользователей: пользователей, которые оказывают давление на сервер. Например, только 20 из этих 60 человек общаются или выполняют другие операции. Эти 20 человек являются числом одновременно работающих пользователей.
Число одновременных пользователей: количество пользователей, выполняющих одну и ту же операцию одновременно.
Время отклика
Также называется временем ответа на запрос: TTLB
Время, необходимое для ответа на запрос, обычно составляет:Время ответа транзакции
Транзакция - это набор тесно связанных операций. Логин - это транзакция.Транзакций в секунду
TPS относится к числу транзакций, которые система может обработать в секунду. Это важный показатель для измерения производительности системы.
Когда давление увеличивается, если кривая TPS изменяется медленно или имеет плоскую тенденцию, вполне вероятно, что сервер начинает испытывать узкое место. Если в среде не произойдет существенных изменений, максимальная пропускная способность обработки транзакций для той же системы будет неизменной с увеличением и уменьшением числа одновременных пользователей.пропускная способность
Количество запросов клиентов, обработанных системой за единицу времени. (Согласно бизнесу) напрямую отражает пропускную способность системы программного обеспечения, обычно измеряемую количеством запросов или количеством страниц.С точки зрения бизнеса пропускная способность может также измеряться количеством посетителей / день или количеством обработанных услуг / час;
С точки зрения сети пропускная способность может измеряться в байтах / день.Время мышления
- это время, в течение которого пользователь остается между двумя действиями.Использование ресурсов
Использование различных системных ресурсов. Процессор, сеть, диск, сеть.Модель теста производительности
Модель кривой перегиба
![]()
Резюме. По мере увеличения числа одновременно работающих пользователей пропускная способность и использование ресурсов увеличиваются, что указывает на то, что система активно обрабатывает данные, поэтому увеличение времени отклика неочевидно и находится в относительно хорошем состоянии. Однако, поскольку число одновременно работающих пользователей продолжает увеличиваться, давление продолжает увеличиваться, и пропускная способность и использование ресурсов достигают насыщения, и затем пропускная способность резко падает, что приводит к резкому увеличению времени отклика. Точка соединения между зоной легкого давления и зоной тяжелого давления является оптимальным числом одновременно работающих пользователей системы, поскольку различные ресурсы полностью используются и реакция является быстрой, а точка соединения между зоной сильного давления и зоной перегиба является максимальным числом одновременных пользователей системы. Потому что после этого производительность системы резко упадет или даже упадет.
Классификация теста производительности
Тест производительности, тест производительности, нагрузочный тест, стресс-тест, тест конфигурации, тест параллелизма, тест надежности, тест восстановления после сбоя, тест большого объема данных
Ориентиры
Существуют базовые стандарты, которые позволяют сравнивать различия и изменения в системе.
Сценарий приложения:- Вы можете установить эталон производительности, сравнив его с установленными стандартами, чтобы после изменения системной среды и параметров вы могли снова выполнить тест по тому же стандарту, чтобы увидеть влияние этого изменения на производительность.
- Сравнительный анализ системы может выявить проблемы с производительностью на ранней стадии.
- Система никогда не тестировалась на какую-либо производительность, и оценка производительности системы должна выполняться в качестве эталона для последующей разработки и настройки.
Узкий тест производительности
Моделируя комбинацию бизнес-давления и сценариев использования производственной операции, можно проверить производительность системы на соответствие требованиям производственной системы. Это распространенный метод испытаний.Нагрузочный тест
Испытание под нагрузкой должно непрерывно увеличивать давление в тестируемой системе до тех пор, пока производительность не станет экстремальной. Например: время отклика превысило заранее заданную цель или использование определенного ресурса достигло насыщения.
Основная цель - найти предел загрузки системы и предоставить данные для настройки системы.Стресс-тест
Целью стресс-теста является выявление системных проблем при высокой нагрузке, таких как конкуренция ресурсов, проблемы синхронизации, утечки памяти и т. д.Как нагрузочное тестирование, так и стресс-тестирование можно проводить в комбинации.
Нагрузочный тест для определения производительности системы при различных рабочих нагрузках. Цель состоит в том, чтобы проверить изменения в различных показателях производительности системы, когда нагрузка постепенно увеличивается.
Стресс-тестирование - это тест для определения максимального уровня обслуживания, который может обеспечить система, путем определения узкого места системы или неприемлемых точек производительности.Тест конфигурации
предназначен для настройки программно-аппаратной среды тестируемой системы, чтобы понять степень влияния различных сред на производительность системы и, таким образом, найти наиболее распределительный принцип для различных ресурсов.Параллельное тестирование
предназначен для имитации одновременного доступа пользователей, чтобы проверить, имеют ли несколько пользователей одновременный доступ к одному и тому же приложению, нет ли тупиковой ситуации или других проблем с производительностью при записи одного и того же модуля или данных.Количество одновременных пользователей отличается от количества одновременных пользователей.
Тест надежности
позволяет системе приложений продолжать работать в течение некоторого периода времени, загружая определенное деловое давление на систему, чтобы проверить, может ли система работать стабильно в таких условиях.Тест восстановления после сбоя
- Метод тестирования восстановления после сбоев предназначен для систем с резервным копированием и балансировкой нагрузки. Этот метод тестирования можно использовать для проверки того, может ли пользователь продолжать использовать систему, если в системе происходит сбой локально, и в какой степени это повлияет на пользователя в этом случае. воздействие.
- Основные ключевые бизнес-системы реализуются посредством горячего резервного копирования или распределения нагрузки. Бизнес-система такого типа обычно требует, чтобы у одного или нескольких серверов были проблемы, и система приложений все еще может нормально работать. Этот метод предназначен для имитации отказа оборудования в тесте и проверки возможности нормальной работы ожидаемой технологии восстановления.
- Этот тип тестирования не требуется для всех систем, особенно для тех, которые не указывают четко потребность системы в непрерывной работе.
Большое количество данных теста
Существует два типа:- Независимый тест объема данных
Тестируйте большие объемы данных для определенных систем хранения, передачи, статистики и запросов. - Комплексное тестирование объема данных
- это комплексная программа тестирования, которая сочетает в себе стресс-тестирование, нагрузочное тестирование, параллельное тестирование и тестирование надежности.
Цель теста каждого типа теста
- Тестирование производительности: проверка квалификации
- Нагрузочное тестирование: возможности планирования, настройка производительности
- Стресс-тестирование: верификация способностей, способность планирования, настройка производительности, обнаружение дефектов
- Тестирование конфигурации: возможности планирования, настройка производительности
- Параллельное тестирование: обнаружен дефект
- Проверка надежности: проверка квалификации
- Тестирование восстановления после сбоев: проверка возможностей, настройка производительности и обнаружение дефектов
Реализация теста производительности
Реализация тестирования производительности:
- Ранняя подготовка (функциональная устойчивость, составная команда)
- Выберите инструменты (для обучения инструмента)
- План тестирования производительности (спрос, план, план, стратегия, ресурсы)
- Разработка тестов производительности (подготовка среды разработки сценариев, написание сценариев, вспомогательных инструментов)
- Выполнение теста производительности (выполнение скрипта-записи результатов)
- Настройка производительности и анализ
- Отчет о тестировании производительности
Подготовка к тестированию производительности
- Проверка основных функций системы
Убедитесь, что в прикладной системе, которая должна быть протестирована в настоящее время, есть условия для тестирования производительности.
Убедитесь, что версия системы приложения, которая в настоящее время проходит тестирование производительности, стабильна. - Сформировать тестовую команду
Определите состав ролей в команде и определите навыки персонала.
Тестовый инструмент
План тестирования производительности
- Потребности в исследованиях и тестировании
- Тест бизнес сфера
- Тестовая среда: аппаратная среда, программная среда, сетевая среда
- Цель теста
- Показатели эффективности: показатели эффективности бизнеса, показатели эффективности системы
- Стратегия тестирования: инструменты тестирования, методы тестирования, выполнение теста
- Написать план тестирования производительности
- Подготовка тестовой среды:
Развертывание и проверка прикладного программного обеспечения
Импорт основных данных базы данных - Тестовый скрипт, тестовые данные
параметризация скрипта
отладка сценария - Тестовое выполнение
Стресс-тест, настройка системы
нагрузочный тест - Написать отчет о тестировании производительности
Общие этапы реализации для различных тестов: отчет о требованиях-решениях-реализации-выполнения-вывода кода
Дизайн теста производительности
- Дизайн тестовой среды
Корреляция между результатами теста производительности и средой тестирования очень велика, независимо от того, какой тип теста производительности, вы должны сначала определить среду тестирования, включая программную / аппаратную среду системы, среду базы данных и т. д. и так далее. - Дизайн тестового сценария
Тестовый сценарий имитирует профиль фактического бизнеса, который включает в себя бизнес, коэффициент бизнеса, цель теста и счетчики производительности, которые необходимо отслеживать во время теста. - Дизайн теста
Сценарий тестирования дорабатывается, как правило, с учетом: типа теста, описания содержимого теста, предварительных условий, последовательности бизнес-операций и требований к параметризации. Контрольные точки и т. Д. - Разработка скрипта и вспомогательного инструмента
Выполнение теста производительности
- Создать тестовую среду
- Развертывание тестовых сценариев и тестовых сценариев
- Выполните тесты и запишите результаты
Анализ и настройка тестов производительности
Анализ результатов испытаний является наиболее сложной частью. Это гибкий процесс. Каждый анализ результатов теста производительности требует от аналитика значительного понимания производительности программного обеспечения, архитектуры программного обеспечения и различных индикаторов теста производительности. Анализ теста производительности требует различных диаграмм. Общий метод: метод анализа точки перегиба.
Читайте также:
