Тестирование производительности. Узнай, что именно тормозит и что с этим нужно делать
Завершая цикл статей (часть 1, часть 2) о вычислении производительности софта, хотелось бы рассказать, как правильно проводить перформанс-тестирование (performance testing). Тема становится все более популярной, но при этом далеко не все понимают, что под этим подразумевается. Ведь прежде чем ответить на вопрос «как», нам нужно разобраться с вопросом «что»: что именно нам нужно тестировать?
Нефункциональные требования, или «хочу, чтобы все работало быстро»
В теории перед тем, как начать программировать, нужно придумать спроектировать архитектуру будущего софта. Но еще раньше надо определиться с требованиями, которые бывают как функциональные (нужна кнопка «Вход» и такие-то страницы), так и нефункциональные (например, использовать PostgreSQL, Ubuntu 14.04). Одним из типов нефункциональных требований и являются требования к производительности.
Рис. 1. Perfomance-тесты в действии
Другие статьи в выпуске: 
Xakep #201. Как стать киборгом
Определяемся с требованиями к производительности
Требования к производительности могут и даже должны отличаться от проекта к проекту — практически не бывает двух проектов с одинаковыми требованиями. Их можно сгруппировать по типам софта (это описано в разных книгах по методологии тестирования, но я буду полагаться на свой опыт, а книги ты и так сможешь прочитать).
- Desktop-приложения (актуально и для современных мобильных и веб-приложений). В таком софте обычно важны скорость запуска, время отклика на нажатия клавиш (никто не хочет ждать десять секунд после нажатия на пункт меню), время выполнения распространенных операций. Например, в текстовом редакторе при открытии файла можно и подождать секунду-другую, но вот ждать столько же, пока на экране появится набранный символ, — это нонсенс.
- Server-side приложения — всевозможные СУБД, API (REST-, SOAP-, RPC-серверы) и так далее. Тут список требований к скорости работы может быть просто огромный, начиная от времени ответа на запрос для одного клиента и заканчивая временем отклика при условии, что у нас есть одновременно 1k клиентов к REST API и все они что-то делают.
- *aaS, всевозможные облака. Производительность облака может измеряться совсем иначе, чем, например, REST API сервиса. Тут в зависимости от типа облака все может сильно и очень сильно меняться. В случае с perfomance SaaS (software-as-a-service) требования почти такие же, как и к любому высоконагруженному веб-приложению. А вот если ты тестируешь IaaS (infrastructure-as-a-service), то требования могут быть совсем другими, например: запуск X виртуальных инстансов не должен занимать больше Y времени, а вот временем, сколько она будет выключаться, иногда можно и пренебречь.
Тут как и с любыми требованиями — нужно отталкиваться от того, что в итоге должно получиться, и не забывать про здравый смысл. Ведь если твой REST API отправляет ответ за одну секунду, а WEB UI потом десять секунд отображает результат, то оптимизировать бэкенд нужно не в первую очередь. Пользователи будут более благодарны за быстрый UI.
Такие разные тесты
Основных видов перформанс-тестирования не так уж и много: performance testing, load testing (нагрузочное тестирование), stress (стресс-тестирование) и configuration (конфигурационное тестирование, где мы меняем всевозможные параметры софта и железа). Исходя из требований, времени и возможности (см. «треугольник требований»), мы можем выбрать необходимые тесты. Поговорим подробнее о них, прежде чем приступить к написанию тестов.
Тесты производительности
Тут все просто и очевидно. Запускаем тест и смотрим, сколько времени он выполнялся и насколько стабильно работал. В идеальном случае такие тесты должны работать на твоем CI (Continuous Integration), а сравнивать результаты нужно с результатами предыдущей версии продукта.
Рис. 2. Нагрузочные тесты
Load testing, или «загрузка завершена на 80%»
Нагрузочное тестирование — это если не самый простой, то один из самых простых вариантов тестирования производительности. Ведь что может быть легче, чем сделать 100–1000 одновременных запросов к нашему API и посмотреть, что упадет? Цель такого тестирования — не столько определить скорость работы разрабатываемого ПО, сколько оценить его поведение при ожидаемой нагрузке. Помнишь, мы говорили о требованиях? Вот здесь они и пригодятся.
Обычно в первую очередь нагрузочные тесты нацеливают на самые распространенные действия пользователей. Например, для тестирования разных компонентов OpenStack мы пытаемся эмулировать определенные действия пользователей такими сценариями:
- boot and delete VM;
- create and list volumes;
- add and remove user role и так далее.
В случае разработки очередного убийцы конкурента Facebook мы бы проверяли сценарии, относящиеся к загрузке картинок, просмотру профиля и прочему.
Во вторую очередь мы тестируем более редкие и сложные сценарии. Например, наш сайт отлично работает с кешем. Тогда тестируем то, что заведомо в кеш не попало! Результаты могут быть очень интересными :).
При нагрузочном тестировании очень важно не только собирать результаты, но и правильно их обрабатывать. Линейную зависимость между нагрузкой на систему и скоростью ее работы мы видим редко, но, как правило, это число можно принять как функцию нормального распределения. Таким образом, при большом количестве прогонов подобных тестов с разной нагрузкой в итоге можно посчитать, как софт себя поведет при необходимой нагрузке без прогона тестов. Естественно, такие числа будут неточными, но они помогут приблизительно понять, какую часть нашей системы нужно будет оптимизировать и когда.
Cтресс-тестирование — даешь максимальную нагрузку!
Если нагрузочное тестирование проверяет наш софт на соответствие требованиям производительности, то стресс-тесты дают максимальную (пиковую) нагрузку и позволяют узнать, когда наш сайт (API, база данных) перестанет работать.
Один из популярных сценариев стресс-тестирования — выяснить, будет ли работать сайт под планируемой нагрузкой или нет. Допустим, начальство готовит запуск новой рекламной кампании и вместо десяти тысяч мы ожидаем пятьдесят тысяч пользователей в час. Простое решение: изменяем конфигурацию нагрузочных тестов, увеличив каждый параметр в пять раз. Если тесты успешно пройдены, можно еще увеличить нагрузку, и так несколько раз, пока что-то не поломается. Такой подход называется пропорциональной нагрузкой, и логично предположить, что в противовес каждой пропорциональной нагрузке есть своя диспропорциональная :).
Рис. 3. Не все тесты могут работать
Она подразумевает неравномерную нагрузку на разные компоненты системы: например, немного на backend, много — на базу данных (или не на саму БД, а на сеть между базой данных и софтом, который ее использует, — так можно проверить, как поведет себя ПО при плохом и/или очень медленном подключении к БД).
Если даже при очень большой нагрузке все работает без видимых изменений в скорости, то, скорее всего, что-то не так с тестами. Ведь чтобы заDDoS’ить любую систему, нужно просто увеличить количество хостов, которые этот DDoS проводят. В случае стресс-тестов все может быть аналогично, хотя иногда тормозят сами тесты или недостаточно пропускной способности сети. Такое бывает, если, к примеру, ты запускаешь тесты у себя на ноутбуке, а тестовое окружение развернуто где-то на Amazon EC2.
Такие тесты очень часто падают, что может вызвать панику у менеджера или заказчика. Но упавшие тесты не всегда означают, что все плохо, — ведь мы тестируем свой продукт на каких-то граничных условиях, которых пользователи могут никогда и не достигнуть. Тест не пройден? Отлично, будем знать, какой предел у нашего приложения :). Этот вид тестов также иногда называют capacity tests или «тесты на пропускную способность железа или ПО».
Configuration testing — «А давайте уберем debug=True из конфига?»
Конфиг приложения может очень сильно влиять на производительность. От банального включения/выключения кеша и забытого флага debug=True до тонкой настройки СУБД и nginx. Бывают случаи, когда сложно предположить, как повлияет та или иная опция конфига на общую скорость работы. Поэтому такие изменения необходимо тщательно тестировать в паре с нагрузочными тестами.
Как (не) тестировать?
Универсальных советов по тестированию производительности нет и быть не может, поскольку каждый продукт индивидуален. Есть общие принципы, которые применимы к определенным типам тестов или программных продуктов. Руководствоваться ими или нет — решать тебе, я лишь поделюсь своими наблюдениями по этому поводу.
Многие крупные производители как софта, так и железа предлагают рекомендации по тестированию производительности своих продуктов. Следуя им, можно получить значения, очень похожие на те, что заявлены в рекламных буклетах. Вот только в реальной жизни от таких тестов пользы мало.
Тестирование производительности без автотестов и рабочего CI процесса — скорее исключение, чем правило. Создать руками нагрузку, которую делают десять пользователей, мягко говоря, очень сложно. А без CI трудно понять, когда и какие тесты были запущены и каков их результат. Красивые графики и диаграммы будет интересно и полезно посмотреть всем.
Тестировать производительность нужно регулярно, а результаты — тщательно анализировать, при необходимости узкие места должны быть исправлены, после чего тот же набор тестов следует запустить еще раз. Важно повторить все тесты, а не только те, которые показали низкую производительность проверяемого софта. Если после предыдущего теста остались хоть какие-то артефакты (например, созданный временный файл, запись в базу данных), то результаты следующих тестов могут быть искажены.
При написании перформанс-тестов необходимо прежде всего понимать, что и зачем будет тестироваться. Правило Парето работает и тут: если большинство использует только 20% продукта, то в первую очередь эти 20% и нужно тестировать, даже если тесты на другие функции написать быстро и легко. Тестировать производительность надо только в том случае, если это действительно нужно.
Для запуска таких тестов, как правило, не требуется много ресурсов. Я не беру случаи, когда нужно эмулировать действительно большие нагрузки. Под такие задачи выпускаются даже специальные девайсы для генерации сетевого трафика в десятки тысяч долларов стоимостью. Подобный девайс легко положит не только среднестатистический сайт, но и всю локалку, если железо в ней не будет рассчитано на соответствующую нагрузку.
Как писать перформанс-тесты?
Ответ зависит от того, кому мы зададим этот вопрос.
Разработчики с радостью напишут свой новый фреймворк на том языке, который они считают более подходящим.
DevOps-команда напишет bash-скрипт, который потом будет очень сложно поддерживать.
Тестировщики, как правило, отвечают на этот вопрос просто: «Мы будем использовать JMeter».
Самое время поговорить о распространенных фреймворках для тестирования производительности.
Мир Java и JMeter
JMeter можно считать стандартом де-факто в мире тестирования производительности и Java. С его помощью можно тестировать любые веб-приложения, но сценарии придется писать на Java. Простые сценарии можно составлять без написания кода — достаточно настроек и нажатия кнопок в GUI. Главное, на мой взгляд, достоинство JMeter представляют его отчеты. После запуска и выполнения тестов он не только покажет время их работы, но и расскажет, сколько ушло на сами тесты и сколько потребовалось веб-серверу, чтобы вернуть ответ.
Рис. 4. JMeter в действии
В Сети существует множество плагинов практически на любой случай. Всевозможные графики и диаграммы, интеграция с jUnit и Jenkins. Все это можно установить в несколько кликов мышкой и сразу же запустить тесты.
Tsung и Erlang
Про Tsung мы уже писали в «Хакере» # 164 (сентябрь 2013-го), поэтому подробно описывать его не буду. Tsung написан на Erlang и поддерживает множество протоколов от HTTP до LDAP и PostgreSQL. Его распределенная архитектура и скорость работы без труда устроит настоящее перформанс-тестирование любого сервиса, потребовав при этом минимум усилий и ресурсов.
Бояться Erlang не стоит, так как все конфигурационные файлы представляют собой понятный XML и писать код на Erlang придется только в очень специфических случаях.
Locust, или пишем тесты на Python
Locust — это библиотека на Python, предназначенная для разработки нагрузочных тестов (угадай, на каком языке :)). Создавать сами тесты настолько просто, что с этой задачей может справиться практически любой, кто в состоянии написать «Hello, world».
Рис. 5. Web UI Locust
Locust может работать как локально, так и распределенно, для большей нагрузки. Фреймворк предназначен в первую очередь для тестирования веб-приложений, но ты легко можешь написать плагин для работы с нужным протоколом. В качестве примера в документации есть реализация клиента для тестирования XML RPC сервиса.
Из недостатков этого решения можно выделить то, что для его запуска необходимо открыть его Web UI, написанный на Flask, и отсутствие поддержки получения отчетов в формате xUnit.
Это доставляет массу неудобств при использовании его в CI.
CI и тестирование производительности
Про то, что любые тесты необходимо запускать на CI, говорят все. Тесты производительности в этом случае не исключение. Общие требования к CI такие же, как и для любых тестов (некоторые нюансы, конечно, есть). Так как цели перформанс-тестирования могут отличаться, то и результаты тестов нужно обрабатывать по-разному.
Например, если ты запускаешь нагрузочные тесты, которые проверяют, что приложение работает не медленнее, чем написано в техническом задании или спецификации, то каждый упавший тест необходимо обязательно анализировать и исправлять дефект. В случае же стресс-тестирования «красный» тест необязательно может означать, что есть какие-то проблемы. Возможно, просто наше приложение не рассчитано на такую нагрузку. И в продакшене подобной нагрузки никогда не будет. Следовательно, бросать все и чинить прямо сейчас не надо. Главное — объяснить менеджеру или заказчику, что это нормально (что бывает самой трудной задачей).
Рис. 6. Jenkins и JMeter
Иногда не только полезно, но и необходимо сравнивать результаты тестирования с предыдущей попыткой запуска. Для этого существует достаточно много плагинов к Jenkins. Некоторые из них сопоставляют результаты из лога в формате xUnit. Тебе необходимо только выбрать тот, который нужен.
Железо vs. виртуальное окружение
В современном мире все чаще и чаще приходится работать не с железными серверами, а с виртуальными. В большинстве случаев для тестирования производительности маленьких и средних систем виртуальных машин вполне хватает. Тем более если в продакшене тоже все на виртуалках. Но иногда проблемы, связанные с высокими нагрузками, находятся только на железе. Например, я в свое время столкнулся с багом пакета lvm2 на Ubuntu. Такой же баг был и в Debian. Внутри виртуалок у меня так и не получилось его воспроизвести, в то время как на железном сервере простой bash-скрипт на пятнадцать строчек с этим справился. Кроме того, очень тяжело находить проблемы, связанные с производительностью и высокой нагрузкой дисковых подсистем, гипервизоров и ядра на виртуальных окружениях.
Заключение
Если после тестирования производительности у тебя ничего не поломалось, значит, что-то сделано не так. Можно попробовать добавить больше нагрузки, и тогда наверняка какой-то из компонентов выйдет из строя. И это может быть не только приложение или база данных. Ядро Linux, многие приложения, которые, казалось бы, оттестированы годами, при большой нагрузке могут внезапно отказать.
Наткнуться на проблему с ядром или багом в пакете lvm2 легко. Исправить это гораздо сложнее. И я еще не говорю о выходе из строя железа и проблемах с пропускной способностью локальной сети при тестировании распределенных систем. Тестирование производительности — интересный и полезный этап разработки высоконагруженных систем. А после тестирования все только начинается.
Обзор тестирования производительности
Тестирование производительности является важной частью тестирования. К сожалению, на мой взгляд, тестирование производительности не пользуется такой популярностью, как функциональное тестирование. Тем не менее, производительность значительно влияет на то, как часто пользователи будут обращаться к продукту, а также на их готовность совершить покупку. В этой статье я надеюсь помочь заложить прочный фундамент для тестирования производительности.
Почти 70% потребителей признают, что скорость работы страницы влияет на их готовность совершить покупку в интернет-магазине. — Unbounce, 2019
Принципы
Тестирование должно соответствовать определенным ожиданиям.
Результаты и тестирование должны быть воспроизводимыми.
Результаты должны быть читаемы и сравнимы с ожиданиями заинтересованных сторон.
Тестирование должно проводиться в среде, которая максимально приближена к реальной.
Необходимо учитывать сроки и стоимость проекта.
Операционные профили, профили нагрузки и генераторы нагрузки
Операционные профили определяют шаблоны, которые пользователь или компонент системы может использовать в системе. Например, тесты производительности могут содержать один или несколько операционных профилей. Чтобы создать операционный профиль, тестировщику необходимо собрать определенную информацию:
Во-первых, получить доступ и определить, какие данные необходимо собрать.
Роли и пользователи (администраторы, обычные пользователи, пользователи с уникальными правами).
Определить, какие задачи может потребоваться выполнить пользователю для выполнения конкретной работы.
Спросить себя, сколько пользователей для каждой роли обычно получают доступ и используют систему.
Определить способ сбора данных.
Интервьюирование может предоставить необходимые данные. Например, беседа с менеджером продукта может помочь определить шаги пользователя в приложении.
Также может помочь проверка функциональной документации системы.
Анализ предыдущего тестирования производительности поможет определить, какие показатели необходимо оценить.
После того как все данные собраны, их необходимо оценить, чтобы убедиться в их достаточности.
Профили нагрузки. После сбора всей информации об операционном профиле мы можем создать профиль нагрузки. При создании профиля нагрузки тип теста производительности будет определять способ построения профиля.
Необходимо определить некоторые ключевые термины:
Ramp-up — увеличение нагрузки через регулярные промежутки времени (добавление одного пользователя в минуту).
Ramp-down — снижение нагрузки через регулярные промежутки времени.
Steps — немедленное изменение нагрузки (добавление 50 пользователей одновременно каждые 3 минуты).
Predefined Distribution (предопределенное распределение) — определяет конкретный период для использования профиля нагрузки.
Примеры профилей нагрузки:
Генератор нагрузки — программное средство, которое генерирует нагрузку на основе предоставленного профиля работы и нагрузки. Примером генератора нагрузки является JMeter.
Метрики:
Показатели производительности могут варьироваться в зависимости от среды пользователя/заинтересованной стороны.
Техническая среда (мобильная, веб-приложение и т.д.)
Операционная среда
Бизнес среда
Соглашение об уровне обслуживания (Service Level Agreements)
Одним из наиболее важных аспектов метрик является определение того, какая метрика (метрики) поддерживает цель проекта. Существует такое понятие, как слишком много метрик. Помните, что каждая отслеживаемая метрика требует времени для сбора, анализа и будет использоваться в той или иной форме отчета. После получения результатов может быть хорошей идеей объединить данные, чтобы представить более широкую картину и помочь тем, кто читает отчет, лучше понять его.
Собираем всё вместе
После того как вся необходимая информация собрана, пришло время определить, какой инструмент использовать для тестирования производительности. При выборе инструмента необходимо учитывать несколько факторов:
Насколько стабильным является инструмент? Сам инструмент может вызвать проблемы с производительностью, известные как эффект зондирования.
Некоторые инструменты предоставляют более качественную отчетность, чем другие, поэтому определение типа метрик, необходимых для проекта, является ключевым моментом.
Активно ли поддерживается и обновляется инструмент?
Опыт тестировщиков. Различные инструменты могут использовать разный язык, поэтому хорошо выбрать инструмент с языком, который знаком тестировщикам.
При разработке сценариев следует обратить внимание еще на один момент — «время на обдумывание». Когда сценарии выполняются без него, предполагается, что пользователи выполняют задачи мгновенно, но это не так. Некоторые инструменты позволяют устанавливать случайное время на обдумывание, но оно должно быть включено во все сценарии, особенно когда имитируется пользователь.
Нагрузочное тестирование vs Тестирование производительности
Сегодня мы немного поговорим про теорию тестирования. Очень часто можно услышать вопрос: «Как же правильно говорить: Нагрузочное тестирование или Тестирование производительности? И чем одно от другого отличается?». В русскоязычной среде термины «Нагрузочное тестирование» и «Тестирование производительности» перепутаны, и не всегда понятно откуда что взялось.
Введение
На текущий момент существует множество видов тестирования также существует большое количество классификаций эти видов. Основная классификация видов тестирования происходит по целям. На рисунке ниже представленная классификация видов тестирования.
Классификацию тестирования можно продолжать и дальше, разделяя на ещё более атомарные единицы данные типы тестирования. Основная сложность при классификации видов тестирования заключается в том, что в основном все стандарты существуют на английском языке, и при переводе терминов могут возникать коллизии взаимозависимости от того, как тот или иной термин будет переведен на русский язык. В связи с этим, кроме русского перевода вида тестирования в скобочках будет указываться его английское наименование. В рамках данной статьи мы рассмотрим более подробно тестирование производительности (Performance Testing).
Тестирование производительности (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) — позволяет сравнить производительности на разной конфигурации программной и аппаратной части системы. Данное тестирование помогает выбирать наиболее оптимальную конфигурацию аппаратного и программного обеспечения. В ходе тестирования производится проверка на разных конфигурациях, при этом профиль тестирования не изменяется от конфигурации к конфигурации и имеет среднюю или пороговую интенсивность нагрузки.
Тестирование позволяет ответить на такие вопросы как:
- какую СУБД выбрать?
- какое оборудование выбрать (платформа, производитель, цена и т.д.)?
- как повлияют на работу приложения обновления и патчи?
Выводы
Ну хорошо, из этой статьи мы видим что видов тестирования Производительности много. Очень много, даже слишком много. А какой нужно использовать для конкретно нашей системы? А почему? А сколько делать по времени тесты стабильности? А нужно ли проводить тестирование изолированно или в комплексе с интеграцией? А что делать если нет стенда, сил, времени на такое тестирование? Обращайтесь к нам, в Перфоманс Лаб, мы с удовольствием вам поможем.
Кстати, у нас скоро будет конференция по нагрузочному тестированию, где мы расскажем не только про теорию, но и про практику и про самые последние новости в этой области.
Что такое тестирование производительности
Тестирование производительности — это вид тестирования программного обеспечения, направленный на определение его способности работать с определенными рабочими нагрузками и в определенных условиях. Основная цель тестирования производительности — выявить проблемы, связанные с быстродействием, надежностью и стабильностью системы, а также определить возможные узкие места и точки отказа.
Виды тестирования производительности
Тестирование производительности включает в себя несколько видов тестирования, таких как:
Нагрузочное тестирование — проверка системы на работоспособность под определенной нагрузкой, например, при одновременной работе определенного количества пользователей или при выполнении определенного количества запросов.
Стресс-тестирование — определение предельных рабочих условий системы, при которых она продолжает функционировать, но с ограничениями по производительности, а также выявление точек отказа системы.
Тестирование стабильности — проверка системы на способность работать без сбоев и с заданной производительностью на протяжении длительного времени.
Тестирование масштабируемости — определение способности системы адекватно функционировать при увеличении рабочих нагрузок или количества пользователей.
Примеры тестирования производительности
Пример 1: Магазин электроники проводит распродажу, и за сутки на сайт приходят миллионы посетителей. Нагрузочное тестирование поможет определить, справится ли сервер с такой нагрузкой и не упадет ли сайт.
Пример 2: База данных компании растет со временем, и тестирование масштабируемости поможет определить, будет ли система работать стабильно при увеличении объема данных.
Инструменты для тестирования производительности
Для проведения тестирования производительности существует множество инструментов, таких как:
- JMeter
- LoadRunner
- Gatling
- WebLOAD
Выбор инструмента зависит от требований к проекту, опыта тестировщика и предпочтений команды.
�� Тестирование производительности — важный этап разработки ПО, который помогает обеспечить стабильность, надежность и высокую производительность системы. С его помощью можно предотвратить сбои, узкие места и обеспечить удовлетворительный уровень обслуживания пользователей.