Что такое перформанс-тестирование

Запись техническая, для порядка, уточнений и ссылания на первоисточники.

Тестирование продуктивности — вот самый точный перевод термина «performance testing».

Но чаще всего используется словосочетание «тестирование производительности«.

А еще чаще мы говорим «перформанс тестинг», чтобы не упариться с переводом.

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

Большинство уверено, что в «перформансе» речь идет только о максимальных нагрузках, и в чем-то право. Вообще, мнения о том, что подразумевает «перформанс-тестинг», слегка очень сильно расходятся. Этому есть здравое, нижележащее объяснение.

Перформанс-тестированию можно подвергнуть любое приложение или изделие (например, изделие №2), но здесь и далее подразумевается только тестирование веб-ориентированных приложений.

Проверка продуктивности сайта

в принципе подразумевает следующее:

1. Эмулирование пользовательских запросов к тестируемому сайту на минимальных, средних, и максимальных величинах (которые должны быть определены ДО начала перформанс-тестинга).
   • Это называется испытание сайта в рабочих условиях, или максимально к ним приближенных.
2. Сравнение изначальных критериев оценки продуктивности функционирования сайта (чего хотели добиться) с реальными показателями (что получилось).

Критерии продуктивности

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

Критерии продуктивности должны быть:

• измеримыми,
• количественными,
• прогнозируемыми,
• понятными.

Пример критериев

1. при поиске профилей с фотографиями сервер должен «выдерживать» не меньше 150 одновременным запросов,
2. генерация страницы с результатами запроса не превышает 4 секунд,
3. результаты запросов кэшируются и выдаются очередному пользователю, который делает запрос, аналогичный предыдущему,
4. приложение «выдерживает» 600 активных пользователей.

Делая вид, что основываются на этой информации, веб-строители выбирают подходящие инструменты и программное обеспечение. Например, мы верим в то, что система управления базами данных MySQL выдерживает, не кашляя, 200 одновременных запросов. Точнее, принимает и ставит сукиных детей в очередь. Значит, «Для обеспечения 150 одновременным запросов на разрабатываемом приложении мы выбираем MySQL!» говорят веб-строители, а потом оказывается, что надо было сразу выбирать Berkeley, но «Боржоми» уже закончилось…

Иногда разработчики ничего особо не выбирают, а пользуются тем, что есть и чем они умеют управлять…

Тестировщиков проблема выбора веб-строителей не волнует. Тестировщиков волнует проверка продуктивности этого творения.

Что следует проверять

при перформанс-тестировании, уже придумано до и для нас:

1. Время отклика

   • В оригинале: Response time.
   • Измеряется в секундах время между исходным запросом к серверу и его «окончательным» ответом клиенту во всех рабочих режимах — как в режиме нормальной нагрузки, так и в усиленном режиме, когда перегорают сразу все UPS в здании.

2. Максимально допустимая нагрузка

   • В оригинале: Load testing.
   • Просто последовательно увеличиваем нагрузку с нуля до «допустимых» параметров.
   • Основной вопрос, на который мы пытаемся ответить посредством лоад-тестинга: «Как изменяется время отклика при увеличении нагрузки на сервер — линейно или по-дурацки?»
     • Линейно: если время отклика растет пропорционально увеличению нагрузки. Это нормально.
     • По-дурацки: если время отклика растет непропорционально увеличению нагрузки. Начинаются задумчивые, непрогнозируемые, неконтролируемые «тормоза».
       • Иногда вместо «по-дурацки» говорят «логарифмически». Пример: «Время отклика растет логарифмически!»
       • Лично еще не встречал человека, который мог свободно и уместно использовать этот термин.
   • Уточнение: лоад-тестинг является составной частью всеобщего перформанс-тестинга.

3. Максимально выдерживаемая нагрузка

   • В оригинале: Stress testing.
   • Делаем то же самое, что и при load testing, просто не останавливаемся, когда доходим до предполагаемых пределов. Продолжаем увеличивать нагрузку. Доводим сервачок до истерики. Получаем информацию о том, как он себя поведет, когда нагрузка превысит расчетные нормы. Узнаем, до каких масштабов сервер (ну, или приложение) будет стараться работать, и на каких значениях оно откажется нам служить.
   • Таким образом, разница между Load и Stress testing в перформансе очень субъективна, грань тонка, а со стороны вообще не разобрать, что происходит — просто сидит человек перед компьютером… В действительности разница в том, что Load приносит нам информацию о поведении приложения «в рамках ожидаемого», а stress приносит нам информацию о поведении приложения при пересечении этих «рамок».

4. Время отклика

   • В оригинале: Response time.
   • Измеряется в секундах время между исходным запросом к серверу и его «окончательным» ответом клиенту во всех рабочих режимах — как в режиме нормальной нагрузки, так и в усиленном режиме, когда перегорают сразу все UPS в здании.

5. Среднее время наработки на отказ

   • В оригинале: Mean time to failure (MTTF).
   • Разработчики клянутся в том, что при нагрузке в 300 активных пользователей сервер «будет беспроблемно жить в течение часа, пока кэш не переполнится».
     • Тестировщики начинают подсчитывать: час — 300 юзеров. Значит, 600 юзеров «убьют» приложение за полчаса. А 1200 юзеров убьют сервер моментально!
     • Или нет: час = 300 юзеров. А если два часа держать сервер под этой нагрузкой? А если три? А если шесть часов держать сервер под таким массивом запросов — он рухнет? Нет? Давайте проверять.
     • А давайте узнаем, сколько времени будет «безотказно» работать сервер с базой данных отдельно от сервера с приложением! А процессор не перегреется?
   • В общем, на основе собственных знаний, инженеры предполагают, что в течение недели сервер будет «стабильно» жить под пиковой нагрузкой в 300 запросов в течение часа. Нормально? Это предсказывали? Это и проверили?
   • Для тестирования веб-серверов MTTF может и не быть очень важной проверкой. Если сдох — ну, ребутнём его… Но, например, без тестирования на MTTF систем, которые будут работать далеко от разработчиков (в космосе), фэйл может быть буквально трагичным.

6. Настройка продуктивности

   • В оригинале: Performance tuning.
   • Звучит странно, но тут действительно подразумевается конечная подстройка производительности тестируемого сервера. Тестировщики СОВМЕСТНО с разработчиками настраивают и в сотый раз перепроверяют работу сервера с учетом сделанных изменений. Сами по себе тестировщики здесь беспомощны.

   • В тысячный раз увеличивается нагрузка на сервер до тех пор, пока все «узкие места» не объявлены «выявленными и ликвидированными». Или «выявленными, но признанными недопустимыми».

Инструменты для тестирования продуктивности

Бесплатные

• Apache JMeter
• Grinder
• WebLoad
• Microsoft Web Application Stress Tool
• OpenSTA
• QEngine

Платные

• NeoLoad
• LoadRunner
• Rational Robot, Rational Performance Tester
• SilkPerformer
• AQtime
• PureLoad
• QALoad

Если много свободного времени

1. Читаем тоже общую, но толковую статью «Описание подхода к тестированию производительности ПО«:

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

2. Читаем двухсотстраничный Performance Testing Guidance (pdf) из лабораторий Microsoft за авторством
   1. J.D. Meier
   2. Carlos Farre
   3. Prashant Bansode
   4. Scott Barber
   5. Dennis Rea

Пожалуйста, разубедите меня в том, что за умение проводить перформанс-тестинг платят больше, нежели за мануальное и автоматизированное тестирование.