Автоматизация тестирования ПО

Основные понятия Нагрузочное Тестирование Автоматизация функционального тестирования

Практикум Пишем систему автоматизации тестов "с нуля" PageObjects pattern PageObjects pattern + Selenium (Java) Работа со статическими ресурсами Запуск Selenium Server Модель нагрузки, как отправная точка при тестировании... Конфигурация тестового стенда для нагрузочного тестирования Создание скриптов для нагрузочного тестирования Запуск скриптов: Java Test Runner Automation Test Framework (ATFwk) Automation Test Framework (ATFwk)

Раздел: Автоматизация > Практикум > Модель нагрузки, как отправная точка при тестировании производительности

Модель нагрузки, как отправная точка при тестировании производительности

1. Введение
2. Что же такое нагрузочное тестирование?
3. Анализ требований
   • Анализ требований в зависимости от типа проекта
4. Анализ целевой аудитории
5. Определение базового профиля нагрузки
6. Разработка моделей нагрузки
   • Модель тестирования производительности
   • Модель стрессового тестирования
   • Модель объемного тестирования
   • Модель тестирования стабильности или надежности
7. Выводы
8. Литература

Введение

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

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

Что же такое нагрузочное тестирование?

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

Основные виды нагрузочных тестов:

• Тестирование производительности (Performance Testing)
• Стрессовое тестирование (Stress testing)
• Объемное тестирование (Volume Testing)
• Тестирование стабильности или надежности (Stability or Reliability Testing)

Говоря ранее о качественном нагрузочном тестировании, я имел ввиду проведение полного цикла работ:

• разработка моделей нагрузки
• конфигурация тестового стенда
• разработку скриптов
• проведение тестирования
• анализ результатов

Далее в статье речь пойдет преимущественно о первом и на мой взгляд самом важном этапе – о разработке моделей нагрузки (Work Load Model).

Примечание:
Согласно некоторым данным этот этап может занимать до 50% времени по нагрузочному тестированию.

Разобьем работу над моделью нагрузки на несколько частей и определим, что необходимо будет делать на каждой из них:

• анализ требований
• анализ целевой аудитории
• определение базового профиля нагрузки
• разработка моделей нагрузки

А теперь более подробно рассмотрим каждый пункт, шаг за шагом.

Наверх

Анализ требований

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

• Время отклика (время необходимое для открытия страницы или получения ожидаемого результата)
• Интенсивность (число запросов в секунду – (Qps)
• Используемые ресурсы (загрузка процессора, кол-во используемой памяти, дисковое и сетевой I/O)
• Максимальное количество пользователей (определяет число пользователей, способных работать с системой в условиях заданной конфигурации)

А также некоторые метрики связанные с работой бизнес сценариев (например, количество бизнес операций в единицу времени, время выполнения бизнес операции и т.д.)

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

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

Примечание:
В случае, когда требования заданы не полностью, базовая нагрузочная точка может быть рассчитана по имеющимся данным (см. расчет нагрузочных точек), при условии наличия необходимых характеристик.

Примечание:
Характеристика “Максимальное количество пользователей” на самом деле является малоинформативной, в случае если для тестирования нам необходимо будет работать с несколькими группами пользователей. Поэтому крайне важно будет знать более менее точное количество пользователей в каждой группе.

Анализ требований в зависимости от типа проекта

При анализе требований необходимо учесть разрабатывается ли новое (startup project) или же проект направлен на профилирование нагрузки для уже находящегося в эксплуатации приложения (profiling project).

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

Для startup проектов:

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

Для profiling проектов:

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

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

Примечание:
В случае, если подобный анализ “имел место быть”, и в документации по проекту четко описаны все требования, то можно считать, что вам повезло. Так как в противном случае часть работы по разработке требований может лечь на Ваши плечи и будет включено во время отведенное на тестирование, которого и без того обычно не хватает.

Наверх

Анализ целевой аудитории

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

Примечание:
В случае, если тестируемая система уже находится в эксплуатации, пользовательские сценарии и распределенее запросов в течении дня, можно получить проанализировав логи приложения и сервера.

В результате мы получим:

• Четко выделенные группы пользователей (например, администраторы, операторы, зарегистрированные клиенты, новые пользователи и т.д.)
• Описание сценариев тестирования, на основе реального поведения пользователей из каждой группы.
• График распределение выполнения бизнес операций в течении дня.

Например:
Утром операторы проверяют журналы посещения, обрабатывают сообщения клиентов, после обеда вводят новые товары в базу, и в конце рабочего дня снова анализируют журналы и сообщения. Значит основная нагрузка на журналы посещения и базы сообщений будет в начале и в конце рабочего дня.

Наверх

Определение базового профиля нагрузки

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

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

Например:

В группе “Администраторы” работает 10 админов. Они выполняют 2 основные операции - “добавить пользователя” и “забанить пользователя”.

Распределим выполнение операций следующим образом: 5 админов выполняют операцию добавления и 5 забанивают пользователей. Проведем перерасчет интенсивности выполнения операций:

В течении дня 10 администраторов добавляют 240 пользователей. Значит, интенсивность выполнения операции добавления для 1 администратора = 1 операция в час. Но в нашем случае только 5 админов будут выполнять операцию добавления, значит нам необходимо увеличить интенсивность так, чтобы количество добавленных пользователей осталось прежним. Итого, мы получим, что выполняя по 2 операции в час, 5 админов будут добавлять те же 240 пользователей. Проведя аналогичный перерасчет интенсивности для операции “забанить пользователя”, мы получим профиль нагрузки для группы Администраторы:

группа	кол-во юзеров	операция	интенсивность опер./час
админы	5	добавить пользователя	2
админы	5	забанить пользователя	5

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

группа	кол-во юзеров	операция	интенсивность опер./сек
админы	Z	добавить пользователя	N
админы	Z	забанить пользователя	N
...
покупатели	Z	вход/выход в систему	N
покупатели	Z	поиск товара	N
покупатели	Z	покупка товара	N
...
продавцы	Z	просмотр посещения	N
продавцы	Z	добавление/удаление товара	N

Именно это таблица и будет являться полным базовым профилем нагрузки (performance baseline profile) для тестируемого приложения.

Наверх

Разработка моделей нагрузки

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

Так разным может быть:

• количество пользователей и интенсивность запросов
• старт самих пользователей: последовательно по одному, ступенчато группами или же запуск всех сразу.
• длительность сценария от 10 минут до нескольких часов или даже дней.

Проще всего изменения проводить, варьируя параметрами в базовом профиле нагрузки и инструменте для тестирования производительности (например, в HP LoadRunner Controller).

Модель тестирования производительности

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

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

Модель стрессового тестирования

Увеличивая интенсивность операций выше пиковых (максимально разрешенных) значений либо увеличивая количество пользователей, до тех пор пока нагрузка не станет выше максимально допустимых значений, проверяем, что система работоспособна в условиях стресса. Далее, опустив нагрузку до средних значений, проверяем (способность системы к регенерации), что система вернулась к нормальному состоянию (основные нагрузочные характеристики не превышают базовые).

Модель объемного тестирования

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

Модель тестирования стабильности или надежности

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

Наверх

Выводы

Четкое следование всем вышеописанным инструкциям по разработке моделей нагрузки, позволит нам:

• провести дополнительный анализ и тестирование требований по производительности
• уточнить параметры и характеристики производительности
• получить более четкого представления о работе системы в целом
• получить на выходе план предстоящих работ связанных с нагрузочным тестированием
• определить предельный объем данных системы (с сохранением приемлемой производительности)
• определить предельное количество пользователей (групп) системы (с сохранением приемлемой производительности)
• определить ресурсоёмкие операции или сценарии (для дальнейшего профилирования системы)
• отслеживать эффект от вводимых оптимизаций системы при регулярных измерениях производительности, используя разработанные и проверенные модели нагрузки,

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

Наверх

Литература

1. Технология нагрузочного тестирования информационных систем с большим объемом данных , Вячеслав Берзин, Oracle Magazine, [01.12.04]
2. Блог “Нагрузочное тестирование ПО” (http://ashirobokov.blogspot.com), Андрей Широбоков
3. Сайт “ПроТестинг.RU” (http://www.protesting.ru/automation/performance.html)
4. Performance Testing Guidance for Web Applications, J.D. Meier, Carlos Farre, Prashant Bansode, Scott Barber, and Dennis Rea; Microsoft Corporation; September 2007

Автор: Алексей Булат

Обсудить статью в блоге автора

Наверх