Правильный подход к составлению профиля нагрузочного тестирования
Тестирование производительности для специалистов по автоматизации - зачем и как?
1. Software quality assurance days
International Conference of
Software Quality Assurance
sqadays.com
Minsk. May 29–30 2015
Коваленко Андрей
Lohika. Одесса, Украина
Путь к тестированию производительности. Как его
пройти от автоматизированных тестов.
2. Performance testing for Automation QA – why and how?
Андрей Коваленко
6 последних лет в ИТ
3 года в разработке и внедрении
распределённых защищённых сетей
3 последних года- инженер по анализу и
тестированию производительности
kovalenko.andrey.odessa
О докладчике
3. Performance testing for Automation QA – why and how?
Что такое тестирование
производительности?
4. Performance testing for Automation QA – why and how?
Зачем нужно тестировать
производительность?
Добрый вечер.
Рад, что у кого-то хватило сил дойти до нашей встречи, надеюсь эти жертвы были не зря и вы узнаете что-то новое для себя)
Если по ходу выступления у вас возникнет желание что-то спросить или поправить меня – буду рад)
Несколько слов о тестировании производительности в целом.
Тестирование производительности является видом нефункционального тестирования и подразделяется на несколько видов –
Load testing – создаём ОЖИДАЕМУЮ нагрузку (количество пользователей и транзакций), определяем время отклика системы для различных операция, сравниваем с заранее определёнными KPI, проверяем потребляемые ресурсы системы
Stress Testing – даём нагрузку сверх ожидаемой и смотрим, что произойдёт с системой (упадёт, заберёт все ресурсы, начнёт тормозить). Убираем нагрузку, смотрим, вернулась ли система к нормальному поведению
Capacity testing – проверяем, сколько пользователей выдержит система, продолжая находится в заданных рамках производительности.
На самом деле можно выделить ещё несколько подвидов тестирования производительности, но для нас – этого будет достаточно.
Кстати, предупреждаю сразу – все названия, произнесённые мною, трактуются по-разному различными специалистами. Некоторые, например, меняют местами performance и load testing. Не буду рвать на себе рубашку, что именно мои правильные – можете использовать любые.
На самом деле, ответ достаточно простой – тестирование производительности позволяет нам зарабатывать больше денег)
Здесь я обычно показываю статистику, сколько Амазон и Гугл теряет миллионов, если их страницы грузятся на 0,1 секунду дольше., как мы теряем в конверсии посетителей в покупатели, при увеличении задержки загрузки сайта на одну секундую Но в этот раз я решил ограничится фразой, которую вы видите на слайде. Хочу спросить у вас – насколько она имеет отношение к реальности? Попробуйте поставить себя на место пользователя – что бы предпочли вы?
Как показывают постоянно растущие бюджеты на тестирование производительности – все крупные игроки на рынке понимают его важность для бизнеса и в последнее время всё больше заинтересованы включить в цикл QA продукта этот вид тестирования.
Но тут возникает проблема – если с функциональным тестированием и инструментами для него мы все хорошо знакомы – то как оценивать и тестировать производительность нашего приложения – вопрос для большинства открытый. Те, кто вчера был до докладе Рекса Блэка уже слышали, что перед тем, как приступать к тестированию производительности, вам нужно хорошо понимать, какие результаты вы хотите получить и что с ними делать.
Если вы уже готовы - Я постараюсь показать, что между функциональным тестированием и тестированием производительности не так много различий, как мы привыкли думать и что вам нужно сделать, чтобы внедрить такое тестирование в вашем проекте.
Давайте посмотрим, чем отличаются эти типы тестирования – функциональное и тестирование производительности. Сначала – о функциональном (ручном и автоматизированном). Какие основные моменты можно отметить в этом виде тестирования?
Перейдём к функциональному авторизированному тестированию
И, наконец, тестирование производительности
Как вы можете заметить, функциональное автоматизированное тестирование и тестирование производительности уже имеют общие моменты. Для нас особенно важно то, что оба этих вида тестирования построены на использовании автоматизации – и можно попробовать пере использовать базу ваших автоматических тестов для проверки производительности вашей системы
Для того, чтобы понимать, как это сделать, давайте рассмотрим стандартный жизненный цикл тестирования, который, я полагаю, вы отлично знаете, и поймём, что нужно изменить в каждой фазе, чтобы получить на выходе тестирование производительности.
Отличий не так много
В начале нашего жизненного цикла мы определяем, что мы будет тестировать – спецификации. Только в данном случае, нужно выделить те из них, которые могут иметь влияние на производительность системы. В этом вам могут помочь девы и архитекторы. Так же на этом этапе следует проанализировать все компоненты системы – веб-сервера, ДБ – возможно, вам придётся добавить в тестирование что-то оттуда
Далее нам нужно определить KPI – основными из них являются время выполнения операции и граничные уровни загрузки системы
Планирование и дизайн – опять же, всё очень похоже, но тут появляются два момента специфичных для тестирования производительности
– определение транзакций, который мы будем мерять (мы их получим автоматически при составлении сценария)
- наши тесты надо проводить на environment, максимально похожем на продакшен – это может быть проблемой, единственное, что может вам помочь – написание, отладка тестов на локальной машине – итоговый тест- аренда площадки в облаке
- Мониторы – это отдельная и большая тема. Но для начала вы можете обойтись стандартным набором нативных мониторов вашей системы, если получится, добавить (может быть, с помощью разработчиков) специфичные мониторы и логи для вашего приложения и ДБ.
Выполнение – ничего необычного)
Анализ результатов –пожалуй самое большое отличие! Вам будет мало просто обнаружить проблему в системе – от вас будут ждать также локализации источника проблемы и рекомендаций по исправлению ситуации. Это требует достаточных знаний как вашего продукта, так и технологий, на которых он простроен. К тому же, для того, чтобы подготовить хороший отчет - вам могут понадобиться знания (хотя бы базовые) математической статистики…
Определение спецификаций
Функционал влияющий на производительность –
совместно с разработчиками
2. Модули влияющие на производительность –
совместно с разработчиками и FA/SA
3. Анализ уровней приложения
Приёмочные критерии (KPI производительности):
Основные значения TRT – совместно с FA и на основе публичной информации
Граничные значения потребления системных ресурсов – из собственного опыта
Планирование и дизайн:
Пользовательский сценарий – совместно с FA
Выделение транзакций – совместно с FA
Написание скриптов
Создание тестового окружения, аналогичного клиентскому
Создание мониторов системных ресурсов и ресурсов приложения
4. Выполнение и анализ
Выполнение нагрузочного сценария
Сбор результатов
Анализ результатов, сравнение с KPI
Анализ всех доступных логов системы (GC log, DB logs, dumps…)
Профилирование приложения для выявления узких мест системы
Создание рекомендаций для настройки приложения и окружения
Подготовка отчёта
Итак, что мы получили в итоге.
Безусловно, тестирование производительности имеет отличия от обычного автоматизированного функционального тестирования – основные отличия я привёл на слайде. Но на самом деле, тестирование производительности – это один из подвидов automation – так что у вас есть все шансы, успешно внедрить его у себя на проекте.
Дальше я привёл два пути, которыми вы можете прийти к тестированию производительности
Путь первый – в лоб – кому-то может оказаться подходящим – предполагает не использовать никакие сторонние компоненты
Удаляем из скриптов валидацию получаемых данных
Выделяем в коде интересующие нас транзакции
Оборачиваем эти транзакции в любые конструкции измерения времени (можете использовать что хотите - аспекты, переопределённые методы тестов, просто new Date)
Создаем тестовое окружение
Подготавливаем набор мониторов системных ресурсов и ресурсов приложения
Создаём и реализуем временной сценарий (порядок запуска и остановки скриптов)
После запуска собираем результаты и подготавливаем отчёт
Две проблемы, которые вас могут ожидать –
это запуск и параллельное выполнение ваших скриптов – основная беда – построение временного сценария, в котором нагрузка будет правильно распределена во времени
Подготовка отчётов – что нужно включить в отчёт, как оно должно выглядеть, какие параметры являются важными, а какие можно опустить? Тут вам поможет только интернет – тут, как говорится, Ищущему да воздастся
Проверяем используемую вами IDE - ищем функционал запуска тестов производительности
Выбираем 3rd party инструмент с подобным функционалом
Удаляем из скриптов валидацию получаемых данных
Обозначаем в коде транзакции
Автоматически получаем набор необходимых мониторов
Создаем тестовое окружение
Запускаем тестовый сценарий и автоматически получаем отчёт
Главное, что я бы хотел подчеркнуть – сейчас возможности для тестирования производительности (по крайней мере, веб-приложений) есть практически в любом инструменте
Eclipse.
Плагин Selenium к Jmeter
Visual Studio
и многие другие
А если и нет – то практически любое приложение для тестирования производительности умеет импортировать ваши автоматизированные функциональные скрипты или предоставляет плагины для IDE
Хочу вас заверить, потратив может быть один день - вы сможете найти подходящую именно для вас открытую платформу для тестирования – которая позволит использовать вам перейти к тестированию производительности, используя в качестве базы ваши уже готовые автоматизированные тесты. Более того, не забывайте, что почти все коммерческие продукты сейчас предоставляют бесплатные версии – возможно их мощностей хватит для тестирования именно вашего продукта)
В завершении я бы хотел ещё раз подчеркнуть основную идею, которую я хотел донести – тестирование производительности действительно большая и сложная область тестирования ПО – но если вы хотите начать – то начинайте – это не так сложно, как кажется и в помощь вам существует множество хороших и разных подходов и продуктов!
Спасибо)