Что представляет собой тестирование производительности? Раньше в проектах мы прибегали по большей части к функциональному тестированию, и у нас редко появлялась возможность провести нефункциональное тестирование. Оно проводится для проверки таких факторов, как безопасность, надежность, масштабируемость, удобство пользования и т.д. Эти факторы качества также называются нефункциональными требованиями.

Благодаря проведению нефункционального тестирования мы улучшаем пользовательский опыт и охватываем проверками те области продукта, которые не были покрыты с помощью функционального тестирования. Одинаково важно проверить, и как система работает, и убедиться в ее функциональности. Одним из видов нефункционального тестирования является тестирование производительности, которое используется для проверки масштабируемости, стабильности характеристик и скорости работы тестируемого приложения.

На современном ИТ-рынке важную роль играет производительность приложений, и успех бизнеса в том числе зависит от снижения рисков по части доступности, надежности и стабильности приложения. Мы пытаемся достичь определенного времени отклика, пропускной способности и задействования ресурсов для нашего приложения, и тестирование производительности имеет здесь решающее значение. Кроме того, существует несколько типов тестирования производительности, включая нагрузочное, стресс-тестирование, тестирование на выносливость, тестирование производительности при всплесках нагрузки, объемное тестирование и тестирование емкости — все они могут помочь обнаружить потенциальные проблемы производительности в приложении.

Мы часто задаемся вопросом, зачем мы проводим тестирование производительности и так ли оно необходимо. Разрабатывая приложение, мы стремимся получить хороший продукт, а для этого нужно устранять узкие места и находить причины проблем с производительностью. Тестирование дает нам необходимую информацию, с помощью которой мы можем повысить качество приложения.

Как организовать тестирование производительности

Говоря о тестировании производительности, мы подразумеваем не просто использование какого-то инструмента и попытку получить результаты. Это не так просто, как кажется. Чтобы тесты работали эффективно, нам нужно знать, как управлять процессом. Что это значит? Давайте кратко обрисуем общий процесс.

Определение тестовой среды

В некоторых ситуациях для тестирования производительности можно использовать стейджинг. Многие компании руководствуются принципом, что он должен быть идентичен продакшену, и на поддержание этой среды уходят большие затраты. Мы выбираем стейджинг с меньшим количеством ресурсов в основном из-за снижения затрат. Если количество ресурсов превышает 70% по сравнению с продакшеном, результаты тестирования производительности также считаются валидными.

Критерии приемки 

Каковы критерии приемки? Владелец продукта или заказчик вместе с тестировщиками должны отобрать критерии, по которым можно будет понять, готово ли приложение к сдаче. Они вместе определяют критерии эффективности и цели. Если мы не ограничены во времени, полезно провести сравнение нашего приложения с чем-то похожим. Здесь мы конкретизируем планы и ограничения, а также распределяем ресурсы. За рамками этих целей и ограничений мы устанавливаем критерии успеха проекта. После этого начинаем измерять параметры и оценивать результаты, сравнивая фактические и ожидаемые, чтобы определить основу для тестов. Имея на руках основные параметры, можно отслеживать ход выполнения проекта.

Планирование и разработка тестов 

Во время планирования мы также определяем ключевые сценария для проверки возможных сценариев использования. Необходимо будет симулировать какое-то количество пользователей, спланировать данные тестирования и решить, какие метрики будут собираться. Это необходимо для понимания приложения, потребностей клиентов и целей тестирования.

У нас будут разные ожидания от нового приложения и от приложения, которое существует уже много лет. Если мы хотим разработать эффективные тесты, нам нужно понимать приложение, его функциональные возможности и то, как оно используется. Это поможет нам создавать реалистичные сценарии и находить возможные проблемы.

Нам необходимо определить потребности клиентов, чтобы определить ожидаемое использование приложения. Важно знать, сколько раз в день оно используется, сколько пользователей авторизовано, а сколько нет, и каковы ожидания в отношении скорости отклика.

Недостаточно просто иметь задачу протестировать производительность. Нам нужно понять цель тестирования и узнать, справится ли приложение с ожидаемой нагрузкой, какова его максимальная пропускная способность, как быстро приложение может отвечать на запросы при ожидаемой нагрузке и на ключевые запросы.

Настройка среды и внедрение тестов

Перед запуском тестов нужно подготовить среду, инструменты и другие ресурсы. На первом этапе тестирования мы собрали все возможные сведения о продакшен-среде, серверах и балансировке нагрузки. На этом этапе нужно подготовить также нечто подобное. Все данные об этих шагах должны быть задокументированы. Мы должны убедиться в изолированности среды — если в среде есть активные пользователи, обнаружить узкие места невозможно.

Для получения реалистичных результатов тестирования также важна пропускная способность сети. Если пропускная способность сети низкая, пользовательские запросы начинают выдавать ошибки тайм-аута. Это причина, по которой нужно изолировать сеть от других пользователей. Если между клиентом и веб-сервером есть прокси-сервер, клиент будет обслуживаться с данными в кеше и перестанет отправлять запросы на веб-сервер, и мы получим более низкое время отклика и нереалистичные результаты.

Тестировщик на этом этапе должен убедиться, что количество тестовых записей одинаково как в тестовом окружении, так и в базе данных. Если база данных небольшая, для большей точности необходимые тестовые данные нужно сгенерировать.

После настройки среды пора приступать к реализации тестов в соответствие с тест-дизайном, проведенным ранее. 

Выполнение тестов и анализ результатов

После окончания разработки тестов приступаем к их запуску и мониторингу. Затем мы можем проанализировать тесты и поделиться результатами их выполнения. Следующий шаг — улучшить тесты путем тонкой настройки и повторного тестирования, чтобы проверить, есть ли улучшения в производительности. Чаще всего мы отслеживаем следующие метрики: использование процессора, использование памяти, пропускная способность, количество выделенных процессом байтов, объем используемой виртуальной памяти, прерывания микропроцессора в секунду, время отклика, максимальное количество активных сеансов, число обращений в секунду, максимальное количество ожиданий, сборка мусора. Как только мы получим все значения метрик с допустимыми пределами, тестирование может быть завершено.

Выводы

Во-первых, нефункциональное тестирование так же важно, как и функциональное. Если мы хотим иметь представление об общем качестве нашего продукта, тестирование производительности необходимо включить в план. Чтобы правильно управлять тестированием производительности, нужно следовать всем этапам, это так же важно, как и написание самих тестов. Планировать тестирование следует тщательно. Результатом станут надежные тесты, возможность обнаружить и устранить узкие места еще на этапе тестов, а не в продакшене, и в конечном итоге — более качественный продукт.

Всех желающих приглашаем на открытое занятие, на котором вы познакомитесь с популярным приложением для тестирования API. Научитесь работать в нем и создавать заглушки. Регистрация доступна по ссылке.