Тестирование производительности ПО

Тестирование*

На сайте тестировщиков недавно появилась статья, которая описывает один из подходов к тестированию ПО. Я считаю, что он является наиболее правильным и разработчикам нужно обязательно взять её на вооружение при тестировании собственных продуктов.

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

Попутно хочу задать вопрос разработчикам, которые читают Хабр: а вы тестируете свои программные продукты на производительность? Какой алгоритм для этого испольуете? Инструментарий?

Цитата:

Первые тесты желательно проводить на самом низком нагрузочном профиле так как еще непонятно поведение системы, возможно есть серьезные препятствия для нормальной/ожидаемой производительности.
Обычно практикуется повышение нагрузки, выраженное в увеличении интенсивностей выполнения операций (увеличение количества пользователей) с тем чтобы получить зависимости времен отклика от различных нагрузок.
Одновременно с проведением теста необходимо снимать метрики производительности серверного оборудования так как тестирование Приложения обычно производится относительно аппаратных конфигураций (кол-во CPU x Memory). Наиболее важными из них являются:

Показатели в процентах для процессоров:

CPU user использование процессоров для работы Приложения,
CPU wio ожидание процессорами ввода/вывода,
CPU idle «простой» процессора
Очереди на процессора
Использование памяти
Очереди на диски
При этом дисковая подсистема и сеть не должны быть «узкими местами» так как в этом случае будет непонятно насколько эффективным с точки зрения производительности является само Приложение

PS источник и полный текст: software-testing.ru

14 марта 2007, 11:47

NaFigator 33,4 G+

комментарии (8)

atermath 14 марта 2007, 13:19 #

Занимался (и занимаюсь) тестированием производительности веб-приложений, которые делает наша компания. Процедура не сильно отличается от описанной в статье, если коротко:
1) выделяем пользовательские последовательности действий (сценарии поведения)
2) группируем эти сценарии
3) определяем количество виртуальных пользователей (для достижения заданных целей - малая, средняя, высокая загрузка, исследование на максимально возможную загрузку системы - пиковая производительность и т.п.)
4) пишем тесты, выполняем.

инструментарий - опенсорсовский:
- генератор трафика - Apache JMeter
- для сбора информации о загрузке системы используется вывод команды top c соответствующими фильтрами, для последующего анализа - самописный лог-парсер (параллельно он еще вычисляет ряд статистических критериев, но об этом ниже)

Само по себе тестирование производительности - вещь хорошая, но в разовом исполнении оно дает только приблизительный результат (ну да, можно сказать, что "вот, мы сейчас обеспечиваем работу стольких-то пользователей"), наибольший интерес для нас представляет сравнение результатов подобного тестирования от версии к версии.
Подобное сравнение опирается на сбор:
* информации о загрузке процессора (частотная группировка, с фиксированным шагом - 0-2%б 2-4% и т.п.)
* информации об объеме расходуемой памяти (аналогично, частотная группировка)
* прочая информация (времена доступа к базе, и т.п. - все по частотам)
От релиза к релизу алгоритм предварительной обработки замеров не меняется (строится частотная диаграмма). Сравнение качественных изменений проводится Т-Стьюдент тестом (для этого нам и были нужны частотные выборки одинаковой длины). Ну а вычисленный коэффициент как раз и показывает, насколько значимо приложенеи поменяло свое поведение.

p.s.
в планах ввести практику обязательного прохождения приложением теста на производительность.

NaFigator 14 марта 2007, 13:22 # ↑

Правильный линк на генератор трафика Apache JMeter вот: http://jakarta.apache.org/jmeter/
(у вас побилось...)

atermath 14 марта 2007, 13:24 # ↑

хм, спасибо. ссылка была истрактована как относительная, mea culpa - не указал http:// :)

Rostislav 15 марта 2007, 12:19 # ↑

Хочу отметить, что даже разовые прогоны позволяют узнать многое о системе, и не всегда дают только приблизительный результат. Есть еще немало параметров и метрик которые полезно знать прежде чем запускать систему.
Я бы еще посмотрел на результаты, пусть даже разовые, не только со стороны обеспечения количества пользователей или анализа загрузки программно-аппаратного комплекса, но и как на результаты дающие уверенность, что завтра мы сможем, в случае увеличения нагрузки на систему, оперативно отреагировать и поддерживать большее количество. В данном случае я говорю об одном из трех основных показателей производительности - масштабируемости.
Так же при единичном прохождении можно выявить как себя поведет система при нестандартных нагрузках, а главное посмотреть на восстанавливаемость системы после непредвиденных сбоев. Это тоже очень немаловажно.
А вы у себя проходите эти фазы нагрузочного тестирования?

atermath 15 марта 2007, 12:38 # ↑

идеи есть, и в частном порядке я эксперименты ставлю (учитывая, что сервисы работают под Tomcat, c восстанавливаемостью плохо, уж если Out of memory, то до рестарта). Но как постоянная практика - это на стадии введения.
Нестандартные нагрузки - исследование интересное, но в нашем сегменте рынка (intranet-сервисы, и слабонагруженные internet-приложения) не сильно пока востребованное.

Меня еще интересует работа системы длительное время при стабильной средней нагрузке (stability testing) - расход памяти, загрузка, скорость отдачи страниц

norguhtar 15 марта 2007, 12:41 # ↑

Кстати не можете объяснить чем вызвана популярность tomcat ? :)

atermath 15 марта 2007, 13:35 # ↑

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

norguhtar 15 марта 2007, 14:15 # ↑

Я тоже просто его довольно долго использовал. Но сейчас использую resin он уже GPL :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.