Download to read offline
Uploaded bySQALab
Тестирование производительности для специалистов по автоматизации - зачем и как?
Доклад Андрея Коваленко на конференции SQADays в Минске посвящён тестированию производительности в автоматизации QA. Он описывает важность этого тестирования, его жизненный цикл и взаимодействие между автоматизацией и производительностью. Проблематика включает подходы к эффективному тестированию производительности и необходимость проведения таких тестов в разработке ПО.
More Related Content
Similar to Тестирование производительности для специалистов по автоматизации - зачем и как?
Тестирование производительности для специалистов по автоматизации - зачем и как?
- 1. Software quality assurancedays International Conference of Software Quality Assurance sqadays.com Minsk. May 29–30 2015 Коваленко Андрей Lohika. Одесса, Украина Путь к тестированию производительности. Как его пройти от автоматизированных тестов.
- 2. Performance testing forAutomation QA – why and how? Андрей Коваленко 6 последних лет в ИТ 3 года в разработке и внедрении распределённых защищённых сетей 3 последних года- инженер по анализу и тестированию производительности kovalenko.andrey.odessa О докладчике
- 3. Performance testing forAutomation QA – why and how? Что такое тестирование производительности?
- 4. Performance testing forAutomation QA – why and how? Зачем нужно тестировать производительность?
- 5. Performance testing forAutomation QA – why and how? Функциональное
- 6. Performance testing forAutomation QA – why and how? Функциональное автоматизированное
- 7. Performance testing forAutomation QA – why and how? Тестирование производительности
- 8. Performance testing forAutomation QA – why and how? Жизненный цикл тестирования
- 9. Performance testing forAutomation QA – why and how? Жизненный цикл тестирования производительности
- 10. Performance testing forAutomation QA – why and how? Автоматизация VS Производительность
- 11. Performance testing forAutomation QA – why and how? Автоматизация->Производительность (долго и скучно)
- 12. Performance testing forAutomation QA – why and how? Автоматизация->Производительность (чтобы оставить себе время на отдых)
- 13. Performance testing forAutomation QA – why and how? Автоматизация->Производительность
- 14. Performance testing forAutomation QA – why and how? Автоматизация->Производительность http://www.opensourcetesting.org/performance.php ContiPerf 2
- 15. Performance testing forAutomation QA – why and how? Вопросы? kovalenko.andrey.odessa
Editor's Notes
- #3 Добрый вечер. Рад, что у кого-то хватило сил дойти до нашей встречи, надеюсь эти жертвы были не зря и вы узнаете что-то новое для себя) Если по ходу выступления у вас возникнет желание что-то спросить или поправить меня – буду рад)
- #4 Несколько слов о тестировании производительности в целом. Тестирование производительности является видом нефункционального тестирования и подразделяется на несколько видов – Load testing – создаём ОЖИДАЕМУЮ нагрузку (количество пользователей и транзакций), определяем время отклика системы для различных операция, сравниваем с заранее определёнными KPI, проверяем потребляемые ресурсы системы Stress Testing – даём нагрузку сверх ожидаемой и смотрим, что произойдёт с системой (упадёт, заберёт все ресурсы, начнёт тормозить). Убираем нагрузку, смотрим, вернулась ли система к нормальному поведению Capacity testing – проверяем, сколько пользователей выдержит система, продолжая находится в заданных рамках производительности. На самом деле можно выделить ещё несколько подвидов тестирования производительности, но для нас – этого будет достаточно. Кстати, предупреждаю сразу – все названия, произнесённые мною, трактуются по-разному различными специалистами. Некоторые, например, меняют местами performance и load testing. Не буду рвать на себе рубашку, что именно мои правильные – можете использовать любые.
- #5 На самом деле, ответ достаточно простой – тестирование производительности позволяет нам зарабатывать больше денег) Здесь я обычно показываю статистику, сколько Амазон и Гугл теряет миллионов, если их страницы грузятся на 0,1 секунду дольше., как мы теряем в конверсии посетителей в покупатели, при увеличении задержки загрузки сайта на одну секундую Но в этот раз я решил ограничится фразой, которую вы видите на слайде. Хочу спросить у вас – насколько она имеет отношение к реальности? Попробуйте поставить себя на место пользователя – что бы предпочли вы? Как показывают постоянно растущие бюджеты на тестирование производительности – все крупные игроки на рынке понимают его важность для бизнеса и в последнее время всё больше заинтересованы включить в цикл QA продукта этот вид тестирования. Но тут возникает проблема – если с функциональным тестированием и инструментами для него мы все хорошо знакомы – то как оценивать и тестировать производительность нашего приложения – вопрос для большинства открытый. Те, кто вчера был до докладе Рекса Блэка уже слышали, что перед тем, как приступать к тестированию производительности, вам нужно хорошо понимать, какие результаты вы хотите получить и что с ними делать. Если вы уже готовы - Я постараюсь показать, что между функциональным тестированием и тестированием производительности не так много различий, как мы привыкли думать и что вам нужно сделать, чтобы внедрить такое тестирование в вашем проекте.
- #6 Давайте посмотрим, чем отличаются эти типы тестирования – функциональное и тестирование производительности. Сначала – о функциональном (ручном и автоматизированном). Какие основные моменты можно отметить в этом виде тестирования?
- #7 Перейдём к функциональному авторизированному тестированию
- #8 И, наконец, тестирование производительности Как вы можете заметить, функциональное автоматизированное тестирование и тестирование производительности уже имеют общие моменты. Для нас особенно важно то, что оба этих вида тестирования построены на использовании автоматизации – и можно попробовать пере использовать базу ваших автоматических тестов для проверки производительности вашей системы
- #9 Для того, чтобы понимать, как это сделать, давайте рассмотрим стандартный жизненный цикл тестирования, который, я полагаю, вы отлично знаете, и поймём, что нужно изменить в каждой фазе, чтобы получить на выходе тестирование производительности.
- #10 Отличий не так много В начале нашего жизненного цикла мы определяем, что мы будет тестировать – спецификации. Только в данном случае, нужно выделить те из них, которые могут иметь влияние на производительность системы. В этом вам могут помочь девы и архитекторы. Так же на этом этапе следует проанализировать все компоненты системы – веб-сервера, ДБ – возможно, вам придётся добавить в тестирование что-то оттуда Далее нам нужно определить KPI – основными из них являются время выполнения операции и граничные уровни загрузки системы Планирование и дизайн – опять же, всё очень похоже, но тут появляются два момента специфичных для тестирования производительности – определение транзакций, который мы будем мерять (мы их получим автоматически при составлении сценария) - наши тесты надо проводить на environment, максимально похожем на продакшен – это может быть проблемой, единственное, что может вам помочь – написание, отладка тестов на локальной машине – итоговый тест- аренда площадки в облаке - Мониторы – это отдельная и большая тема. Но для начала вы можете обойтись стандартным набором нативных мониторов вашей системы, если получится, добавить (может быть, с помощью разработчиков) специфичные мониторы и логи для вашего приложения и ДБ. Выполнение – ничего необычного) Анализ результатов –пожалуй самое большое отличие! Вам будет мало просто обнаружить проблему в системе – от вас будут ждать также локализации источника проблемы и рекомендаций по исправлению ситуации. Это требует достаточных знаний как вашего продукта, так и технологий, на которых он простроен. К тому же, для того, чтобы подготовить хороший отчет - вам могут понадобиться знания (хотя бы базовые) математической статистики… Определение спецификаций Функционал влияющий на производительность – совместно с разработчиками 2. Модули влияющие на производительность – совместно с разработчиками и FA/SA 3. Анализ уровней приложения Приёмочные критерии (KPI производительности): Основные значения TRT – совместно с FA и на основе публичной информации Граничные значения потребления системных ресурсов – из собственного опыта Планирование и дизайн: Пользовательский сценарий – совместно с FA Выделение транзакций – совместно с FA Написание скриптов Создание тестового окружения, аналогичного клиентскому Создание мониторов системных ресурсов и ресурсов приложения 4. Выполнение и анализ Выполнение нагрузочного сценария Сбор результатов Анализ результатов, сравнение с KPI Анализ всех доступных логов системы (GC log, DB logs, dumps…) Профилирование приложения для выявления узких мест системы Создание рекомендаций для настройки приложения и окружения Подготовка отчёта
- #11 Итак, что мы получили в итоге. Безусловно, тестирование производительности имеет отличия от обычного автоматизированного функционального тестирования – основные отличия я привёл на слайде. Но на самом деле, тестирование производительности – это один из подвидов automation – так что у вас есть все шансы, успешно внедрить его у себя на проекте. Дальше я привёл два пути, которыми вы можете прийти к тестированию производительности
- #12 Путь первый – в лоб – кому-то может оказаться подходящим – предполагает не использовать никакие сторонние компоненты Удаляем из скриптов валидацию получаемых данных Выделяем в коде интересующие нас транзакции Оборачиваем эти транзакции в любые конструкции измерения времени (можете использовать что хотите - аспекты, переопределённые методы тестов, просто new Date) Создаем тестовое окружение Подготавливаем набор мониторов системных ресурсов и ресурсов приложения Создаём и реализуем временной сценарий (порядок запуска и остановки скриптов) После запуска собираем результаты и подготавливаем отчёт Две проблемы, которые вас могут ожидать – это запуск и параллельное выполнение ваших скриптов – основная беда – построение временного сценария, в котором нагрузка будет правильно распределена во времени Подготовка отчётов – что нужно включить в отчёт, как оно должно выглядеть, какие параметры являются важными, а какие можно опустить? Тут вам поможет только интернет – тут, как говорится, Ищущему да воздастся
- #13 Проверяем используемую вами IDE - ищем функционал запуска тестов производительности Выбираем 3rd party инструмент с подобным функционалом Удаляем из скриптов валидацию получаемых данных Обозначаем в коде транзакции Автоматически получаем набор необходимых мониторов Создаем тестовое окружение Запускаем тестовый сценарий и автоматически получаем отчёт
- #14 Главное, что я бы хотел подчеркнуть – сейчас возможности для тестирования производительности (по крайней мере, веб-приложений) есть практически в любом инструменте Eclipse. Плагин Selenium к Jmeter Visual Studio и многие другие А если и нет – то практически любое приложение для тестирования производительности умеет импортировать ваши автоматизированные функциональные скрипты или предоставляет плагины для IDE
- #15 Хочу вас заверить, потратив может быть один день - вы сможете найти подходящую именно для вас открытую платформу для тестирования – которая позволит использовать вам перейти к тестированию производительности, используя в качестве базы ваши уже готовые автоматизированные тесты. Более того, не забывайте, что почти все коммерческие продукты сейчас предоставляют бесплатные версии – возможно их мощностей хватит для тестирования именно вашего продукта) В завершении я бы хотел ещё раз подчеркнуть основную идею, которую я хотел донести – тестирование производительности действительно большая и сложная область тестирования ПО – но если вы хотите начать – то начинайте – это не так сложно, как кажется и в помощь вам существует множество хороших и разных подходов и продуктов! Спасибо)