понедельник, 1 ноября 2010 г.

Ода тестированию производительности, или ХВАТИТ ПУТАТЬ ЕГО С НАГРУЗОЧНЫМ!

В нашу эру центрального отопления и повальной распространённости веб-сервисов многие люди, даже мэтры тестирования, предлагают рассматривать нагрузочное тестирование и тестирование производительности лишь в связке. Причина проста: тестируем веб, вот и смотрим скорость отклика (производительность) под разной нагрузкой: от одного до N клиентов.

В результате такого восприятия теряется понимание тестирования производительности, которое является НУ ОЧЕНЬ важным, потому что:

1) Вы любите, когда что-то тормозит? Клиенты тоже не любят, обычно баги производительности являются критичными.
2) Чаще всего проблемы с производительностью являются архитектурными. Когда клиенты их репортят, исправлять их уже поздно.
3) Локализовать ошибки производительности - это сложно, это действительно искусство.
4) Неграмотное тестирование производительности ("здесь что-то тормозит") почти всегда ведёт к тому, что критичный баг переходит в разряд KNOWN ISSUES. Чтобы этот баг мог быть исправленным, тестировщику придётся потрудиться!

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

Чтобы разобраться с тем, как тестировать производительность, да ещё и чтобы повысить вероятность исправления дефектов, я перечислю основные подходы к тестированию производительности. Для удобства восприятия, все подходы будут разбираться на примере архиватора файлов.

1) Отлавливаем "провалы" в производительности.
Разработчики могут вносить ошибки, связанные с производительностью, в любой момент. Чем раньше они узнают о проблеме - тем лучше.

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

Что важно:

- автоматизация. КАЖДЫЙ билд значит КАЖДЫЙ, это важно и чтобы вовремя заметить проблему, и чтобы чётче локализовать причины для разработчиков. Тесты на скорость работы - первые кандидаты в автоматизацию.

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

Поиск провалов - единственный тип тестов производительности, которые достаточно часто реализуются. С остальными хуже.

2) Сравниваем себя с конкурентами. В то время как маркетологи всё ещё гоняются за "фичез-листами", пользователи уже давно ищут телефоны без фотокамер. Пользователям важно ПРОСТО и БЫСТРО. Ну, и ещё 5-10% от функционала Вашего ПО. Поэтому, нам надо проверять, насколько наша скорость сопоставима со скоростью конкурентов. И если мы в 2, 3, 5 раз медленнее - бить в колокол.

Что важно:

- обеспечить абсолютно одинаковые условия. Окружения, файлы, последовательность действий.

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

3) Ищем "провалы" производительности, зависящие от внешних факторов.
Часто бывает такое, что пользователи жалуются "медленно", а мы вроде бы (по своим замерам) в несколько раз быстрее конкурентов. Поддельные тестировщики в ответ на такие жалобы в support отвечают "у нас всё хорошо". Настоящие тестировщики уже знают, в чём причина!
Узнаём всё, что может влиять на скорость работы. Типы файлов? Размеры архива? Файловая система? Операционка? Размер кластера? День недели? Расположение звёзд? И проводим тесты, сравнивающие производительность в зависимости от этих факторов. Зачастую бывает такое, что из-за использования неграмотного драйвера сохранение архива на фат может занимать в 30 раз больше времени, чем на нтфс, который входит в Вашу "стандартную" конфигурацию. Пользователи просто не дождутся результата!!
ОДНИМ из параметров тестов МОЖЕТ БЫТЬ количество подключений в клиент-серверном ПО. Все остальные тесты НЕ имеют отношения к нагрузочному тестированию.

Что важно:

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

- исследовать архитектуру продукта, делать тестирование производительности grey-box техникой. Поговорите с разработчиками. Они конечно же скажут, что ничто не может влиять на результат - у них работа такая :) Узнайте, какие ветви кода вызываются в зависимости от каких условий. Подумайте, как Вы можете вызвать не проверенные ветки кода, как задействовать эти условия?

4) Ищем узкие горлышки aka bottleneck'и. Если наш продукт неэффективно использует ресурсы компьютера, то мы либо теряем огромный запас в скорости работы, либо становимся почти неработоспособными на конкретных "железках". Свой продукт надо знать в лицо! Что ограничивает его скорость?
При проведении тестов, обязательно включаем все возможные мониторы. Какой ресурс занят на 100%?

Никакой, и до 100% всем далеко? Проблема алгоритма, мы написали немасштабируемый софт!

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

В любом случае, сообщая в дефекте сразу, в чём проблема, сеть является "боттлнеком", база или память, мы значительно помогаем разработчикам в исправлении - они сразу будут знать, "куда копать".

5) Общие советы.
Чтобы сделать тестирование производительности эффективным:

- убедите аналитиков и маркетологов или кто-там-у-вас-определяет-что-нужно-пользователям, что производительность - это ВАЖНО! Во-первых, это действительно важно. Во-вторых, к счастью, почти все и так это понимают.

- привлекайте к тест-анализу разработчиков. Они могут помочь как никто другой.

- сделайте ОЧЕНЬ понятный отчёт. Если вывести в текстовый лог результаты операций, то есть шанс, что вы не поймёте результатов вообще. Где бага, где всё хорошо?
Грамотно сгруппируйте результаты замеров, чтобы результат был понятен и очевиден.

no pasaran!

10 комментариев:

  1. Тема заголовка "или ХВАТИТ ПУТАТЬ ЕГО С НАГРУЗОЧНЫМ!" не раскрыта, к сожалению.

    ОтветитьУдалить
  2. А никакой связи с нагрузочным :)

    Чаще всего его путают, когда говорят что нагрузочное и производительность - одно и то же (при тестировании скорости отклика при разной нагрузке).

    Вышеперечисленные в статье подходы не имеют ничего общего с нагрузочным. Зато являются тестированием производительности.

    ОтветитьУдалить
  3. Андрей, классное предложение структуры!

    Напишите СВОЮ статью, можете даже использовать часть моей, я не против.

    ОтветитьУдалить
  4. а мне понравилось :) как всегда эмоционально, живо, вощем цепляет =) Спасибо, Наталья, за блог ;)

    ОтветитьУдалить
  5. Привет, прочитал. В целом по делу, но
    1) А что будут делать разработчики архиватора, если проблемы идут "от сети" и как архиватор связан с сетью? Ведь имхо если сеть нагрузила машину так, что файлы не архивируются, результаты тестирования будут неадекватные.
    2) Если в два раза медленнее, но жмет в два раза лучше - бить в колокол?
    3) Если архиватор будет использовать 100% чего-либо это заафектит остальной софт. Это разве хорошо?
    4) Как убеждение маркетологов и ещё-кого-то-там сделает тестирование эффективным?

    ОтветитьУдалить
  6. 1) Чистый эксперимент - т.е. кроме тестируемого софта всё остальное должно работать по минимуму. Сеть - это пример. Ну к примеру мы архивируем на сетевой диск ;)

    2) "Если в два раза медленнее, но жмёт в два раза лучше" - о, грамотный комментарий!! Я об этом зря не написала. Сравнивать надо 2 максимально идентичные операции, это важно. И бить в колокол в случае, если у нас нет настрек на такой же (приблизительно) уровень сжатия - НАДО. Потому что маркетологи об этом знать ДОЛЖНЫ.

    3) Есть кнопочка "архивировать в фоновом режиме". Если у меня свободны 90% ресурсов, а архивация занимает 2 часа - это жесть!

    4) Тестирование - сервис, и мы с маркетологами над одной и той же целью работаем. Мы им можем рассказать что внутри, они - что понаобещали снаружи. Умение объединить усилия - важно!

    ОтветитьУдалить
  7. Про "2" подробнее: к примеру, у нас софт в 2 раза лучше жмёт, и в 2 раза дольше это делает. Маркетологи не в курсе. Как думаешь, что будут клиенты писать на форумах? Что мы хорошо жмём? Фигушки! Что мы тормознуто работаем :)

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

    Но мы же заинтересованы в успехе продукта? Значит, надо им помочь :)

    ОтветитьУдалить
  8. В идеальных условиях конечно надо стыковать маркетинг с разработкой, а главное с тестерами, но по жизни я такое встречал очень редко - мухи отдельно, котлеты отдельно:)
    А потом, ты сама работала в продуктовых конторах))))) Задача маркетологов показать то, что им велел начальник маркетологов:)Главное показать то, что твой продукт лучше, чем у конкурентов. Просто лучше, а не работает лучше. Ты же сама наверняка видела стопитсот раз, когда фича маркетингом пропиарена, а в продукте её либо нет, либо она глючная, а починят/добавят только в следующем пакете заплаток, либо просто забьют:)

    З.Ы. архиватор с ресурсным менеджером - круть, хачу такой:)

    ОтветитьУдалить
  9. Не, ну мы ж чай не отмазки искать собрались :) Конечно, и маркетологи иногда лажают, и аналитики, и мы сами. Но это ж не повод ничего не улучшать, всё равно всё в наших силах! :)

    Про архиватор с ресурсным менеджером не совсем поняла. Я имела в виду использование сторонних мониторов во время проведения тестов над нашим родным и ненаглядным архиватором :)

    ОтветитьУдалить
  10. 3) Есть кнопочка "архивировать в фоновом режиме". Если у меня свободны 90% ресурсов, а архивация занимает 2 часа - это жесть!


    Архиватор увидал такое счастье и отхавал ещё ресурсов, а потом отдал винде, если ей надо))

    ОтветитьУдалить