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

Автор: | 08.12.2008

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

Тестирование продуктивности – вот самый точный перевод термина “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.
    • Звучит странно, но тут действительно подразумевается конечная подстройка производительности тестируемого сервера. Тестировщики СОВМЕСТНО с разработчиками настраивают и в сотый раз перепроверяют работу сервера с учетом сделанных изменений. Сами по себе тестировщики здесь беспомощны.

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

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

Бесплатные

Платные

  • 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

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

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

  1. Алексей Лупан

    #401122 – Bash.Org.Ru
    Шоколадница
    а как ты производительность тестируешь?
    ekeeper
    никак, я просто в нее верю

  2. mishka

    Хороший пост! По делу и без “воды”. Только не понял одну вещь: почему “Иногда вместо “по-дурацки” говорят “логарифмически”.”? По-моему, логарифмически – это даже лучше чем линейно. Вот экспоненциально – это “по-дурацки” 🙂 Логарифм вроде функция хорошая: http://ru.wikipedia.org/wiki/Логарифмическая_функция

  3. Алексей Лупан

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

  4. Олег Грибовский

    Среднее время безотказной работы – это не совсем правильный перевод.
    Mean time to failure – это Среднее время наработки на отказ в соответствии с ГОСТ 27.002

  5. Андрей

    На самом деле тут описывается не только Перформанс в его чистом виде но и Стресс Тестинг (2. Максимально допустимая нагрузка). Эти 2 понятия очень часто путают многие тестеры, но различить их довольно таки лего. Перформанс – это вид тестирования при котором проверяю в основном скорость работы приложения на 1 запрос. Стресс Тестинг – это то как проложение вебед себя при больших нагрузках. Алексей название этой рубрики не совсем подходит к ее описанию. Перформанс часто используется вместе со стресс тестингом но это 2 разные вещи. Да и самое важное “Уточнение: лоад-тестинг является частью перформанс-тестинга.” – это абсолютно не так. Лоад-тестинг также становится Стресс Тестингом в случае когда проверяются пиковые мощности (как описанно во 2-м пунтке).

  6. Albert Gareev

    Хорошая статья, Алексей.
    Добавлю, с Вашего позволения.
    Performance Testing – собирательное название. Относительно недавно пришло на замену “чистому” определению Load Testing.
    И сейчас часто употребляется как Load/Performance Testing.
    Подразделы можно выделить такие:
    Performance/Regression Testing – снимаем характеристики, и при последующих билдах/патчах сраниваем новые со старыми
    Scalability Testing – ищем performance threshold, докуда (No. of concurrent connections) infrastructure (или только application server) может выдерживать нагрузку.
    Stress Testing – даем заведомо превышающую норму нагрузку. Это может быть слишком много юзеров, или слишком часто/быстро посылаем запросы. В результате, сервер часть запросов теряет, на часть отвечает невпопад… А тестер радостно потирает руки и пишет баг-репорты.
    Endurance Testing – заставляем работать долго, очень долго, пока не вылезут ляпы ресурс-менеджемента. Memory Leakage (не всю память программа освобождает), например. Или сокеты открывали, но не закрывали. Или хэндлеры создавали, но не освобождали. А может банально пожрать все место на диске или в базе данных.
    Другие реальные задачи для Performance Testing – поблочное тестирование элементов инфраструктуры, с целью выявления “узких” мест (bottlenecks). Firewall, Router, DB, etc.
    PS. Все понятия изначально усваивал на английском, на русском звучит непривычно, честно говоря.

  7. Albert Gareev

    Насчет тулз.
    TestComplete – надо выбросить. На уровне протокола не поддерживает. Concurrent VUs не создает. И вообще это functional test automation tool.
    В бесплатные добавить QEngine.
    В платные добавить NeoLoad.
    Последний по юзабилити заткнет за пояс все остальные, вместе взятые, и стоит в 10 раз дешевле LoadRunner.
    И таки да.
    Senior Automaion Developer получает процентов на 20 больше тестера (Senior QA Analyst). Однако, и ручной тестинг не является его основной обязанностью.
    Sr. Load/Performance Testing Engineer получает процентов на 10 больше чем Sr. Automation Developer. Потому как развелось немеряно “Record/Playback” automation developers.
    По крайней мере, у нас в Канаде.

  8. optollafleell

    Hello all! I like this forum, i found multifarious gripping people on this forum.!!!
    Pronounced Community, consideration all!

  9. Sergey

    Из текста….
    “………..
    В тысячный раз увеличивается нагрузка на сервер до тех пор, пока все “узкие места” не объявлены “выявленными и ликвидированными”. Или “выявленными, но признанными недопустимыми”.
    Вопрос –
    имеется ввиду : “выявленными, но признанными допустимыми”. ?

  10. Уведомление: Perfomance testing — Программирование, мотивация и продуктивность

  11. Alena

    привет,
    прекрасная статья. и дабы ее еще улучшить:
    “Время отклика” – вот это описание встречается в п.1 и п.4

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.