Тестирование производительности программного обеспечения
Выполнил студент группы: 22ИСП2-о11
Якимова Софья Андреевна
Калининград
Тестирование производительности
Тестирование производительности — это вид тестирования программного обеспечения, направленный на определение его способности работать с определенными рабочими нагрузками и в определенных условиях.
Тестирование производительности программного обеспечения
Различают три аспекта производительности приложений — от них зависят метрики(показатели), указанные далее. Скорость: Как быстро загружается страница? Скорость — это время отрисовки страницы, время обработки API-запроса или пропускная способность сети при передаче больших файлов. Стабильность: Нормально ли, стабильно ли ведет себя система, не возникают ли ошибки, мешающие работе? Для оценки стабильности учитывается количество ошибок. Масштабируемость: Если понадобилось увеличить/расширить/углубить/укрупнить систему, то сколько это будет стоить и сколько времени? А если количество пользователей сервиса удвоится за год? А если в 10 раз? Для оценки масштабируемости нужно проанализировать использование ресурсов под разными нагрузками.
Нагрузочное тестирование
Цель нагрузочного тестирования — увидеть поведение тестируемой системы под ожидаемой нагрузкой. Здесь нет необходимости «ломать» систему, цель тестирования — получить нагрузку, которую приложение ожидаемо будет получать в «часы пик», обычно это рабочие часы. Способно ли приложение стабильно работать при ожидаемой нагрузке? Аналогия такого тестирования из реальной жизни — экстренные тесты в больницах или аэропортах. Они проводятся для моделирования пиковых ситуаций и проверки, как учреждение будет справляться. Ключевые преимущества Оценка возможностей системы и определение максимальной производительности Предупреждение отказов системы в промышленной эксплуатации Выявление ошибок (например, утечка памяти, некорректные настройки или распределение ресурсов) Минусы: Ресурсоемкий Мало статистических данных и не очень хорошо эмулирует такие пользовательские сценарии, как ограничение скорости запросов пользователя Не подходит для серьезного и масштабного тестирования в сотни и тысячи потоков, т.к он сам по себе ресурсоемкий, а на большом количестве запросов и потоков очень сильно нагружает систему
Стресс-тестирование
После нагрузочного тестирования мы будем знать, как система ведет себя при ожидаемой нагрузке. Цель стресс-тестирования — «сломать систему». Приложение тестируется под экстремальной нагрузкой, чтобы увидеть, когда/где/как все ломается, и это называется стресс-тестированием.
Стресс-тестирование должно:
Проверить поведение системы в «ненормальных» условиях, при экстремальной нагрузке Определить цифровые значения одновременных пользователей/запросов к системе, при которых она выходит из строя Помочь найти способы нормально отработать ошибки, в первую очередь выдавая релевантные сообщения о них Лучше подготовить систему к возможным экстремальным условиям, в том числе проведением упреждающих мер типа улучшения ее кода, «чистки» баз данных, и подобные коррекционные действия
Тестирование стабильности (Soak testing)
Тестирование стабильности — это попытка ответить на вопрос, как система работает в течение длительного времени. Цель: подтвердить, что система будет работать надежно и долго. Проблемы, которые будут обнаружены при таком тестировании: • Исчерпание количества возможных подключений к БД • Неожиданные перезагрузки серверов • Утечки ресурсов, например, памяти • Журналы или другие файлы, которые «раздувают» систему
Тестирование пиковой нагрузки
Тестирование пиковой нагрузки (тестирование пиков, spike testing, иногда спайк-тестирование) — один из видов тестирования производительности. Приложение (сайт) получает резкое и очень большое повышение нагрузки (количества запросов к серверу), с последующим столь же резким понижением. Цель такого тестирования — изучить поведение приложения при экстремальных скачках трафика, и предусмотреть действия команды, если и когда такое случится. Предметом изучения также является поведение системы после скачков трафика. Преимущества : Определение последствий резких скачков нагрузки в программной и аппаратной части Будет известно, как приложение поведет себя во время скачка, и как будет восстанавливаться Руководители проекта будут примерно знать пределы выносливости системы в дни распродаж, активной регистрации новых клиентов и т.п. И команда подготовит предложения Недостатки : Необходимость создать отдельное тестовое окружение, из-за специфичности такого тестирования Требуется довольно много ресурсов и времени
Тестирование масштабируемости
Тестирование масштабируемости — один из видов нефункционального тестирования, при котором QA-команда анализирует производительность приложения (сайта) с точки зрения способности масштабироваться (приспосабливаться), реагируя на увеличение/уменьшение количества пользователей, запросов, и других динамических параметров системы. Такое тестирование проводится как на аппаратном, так и на программном уровне. Тестирование масштабируемости определяет моменты, когда приложение начинает некорректно реагировать на расширение, и определяет причины. Определить: Как приложение будет реагировать на стабильный рост нагрузки (например кратное увеличение количества клиентов) Какое максимальное количество пользователей (клиентов) теоретически доступно в этом проекте Проблемные места в аппаратной и программной части Ухудшится ли user experience Как аппаратная часть (серверы) отреагирует на постоянное расширение клиентской базы, например кратное или на порядок
Преимущества и недостатки:
Преимущества: Создает видение перспектив проекта Находит проблемные места в аппаратной и программной части, мешающие расширению проекта Экономит время и деньги в будущем Улучшит user experience
Недостатки: Не направлено на устранение функциональных проблем в приложении Качественные инструменты могут повысить расходы QA-команда должна обладать большим опытом нагрузочного тестирования При обнаружении проблем процесс может непредсказуемо затянуться При тестировании популярного «нагруженного» продукта сложно подобрать время для тестов
Тестирование объема
Это проверка поведения приложения/сайта при получении очень большого объема данных (поэтому такое название). В первую очередь оценивается время ответа приложения (время отклика). Как источник данных может использоваться база данных, или файл описания интерфейса большого размера, и с ним производятся операции записи/чтения.
Цели:
● Определение «емкости» приложения — получение инсайтов (предположений) по вероятному количеству поступающих данных в тестируемом продукте и реакции на это; это количество должно быть обработано без сбоев и отказов. Знание «емкости» приложения, то есть его «пределов выносливости» — поможет планировать расширяемость (масштабируемость) и упростит создание планов на случай непредвиденных ситуаций (contingency-планов), и просто большого наплыва пользователей. ● Поиск ошибок — Помогает обнаруживать ранее допущенные архитектурные ошибки в приложении, при повышении нагрузки на него. Например, большое время отклика или полный отказ, эксплойты, и прочие неприятные вещи. ● Время отклика — Помогает убедиться, что производительность приложения не пострадает, и что время отклика останется высоким независимо от количества данных, «пропущенных» пользователями через приложение. ● Предотвращение потерь данных — Единственный возможный способ проверить сохранность данных при многократном увеличении размера баз данных и нагрузки на них.
Преимущества и недостатки:
Преимущества объемного тестирования ● Экономия средств компании, своевременным обнаружением проблем с нагрузкой на серверы. Сэкономленные средства направляются на улучшение системы ● Быстрое создание планов масштабирования ● Идентификация проблемных точек и прочих сложностей на ранней стадии ● Система готовится к реальному применению достаточно быстро и эффективно Недостатки объемного тестирования ● Не удастся гарантировать идеально точное выделение памяти/дискового пространства во всех реальных ситуациях ● QA-команда должна быть с опытом в тестировании баз данных ● Сделать копию реального окружения может быть сложно и долго ● Требуется много времени на покрытие всех тестовых условий, написание и выполнение сценариев, это может затянуть релиз ● В небольших системах огромный объем данных вряд ли возможен. Следовательно, такое сложное тестирование не обязательно нужно небольшим, не очень популярным приложениям ● Не всегда возможно эмулировать нужный тип поступающих данных
Вывод:
Тестирование производительности остается особенно важным, поскольку использование онлайн-систем и приложений не замедляется, а, наоборот, набирает скорость, и наличие системы, способной справиться с большими нагрузками, как никогда важно в условиях огромной конкуренции
СПАСИБО ЗА ВНИМАНИЕ!
Калининград