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

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