2. About
Andrey Kovalenko
5 last years in IT - again.
3 years of developing and implementing
distributed protected networks
2 last years - performance engineer.
kovalenko.andrey.odessa
3. Performancetesting
Performance testing: The process of testing to determine the
performance of a software product.
Performance - sub-characteristic of one of the quality
characteristic - efficiency.
5. What is performance?
Load testing - to verify application behavior under normal and peak load
conditions.
Stress testing - To determine or validate an application’s behavior when it
is pushed beyond normal or peak load conditions.
Capacity testing - To determine how many users and/or transactions a
given system will support and still meet performance goals.
15. Some stuff to learn
• Deep knowledge of HTTP load generation, measurement software
• Experience with Oracle/MSSQL Databases and SQL tuning and scripting, Oracle
AWR reports and trace logs Deep knowledge and experience in Windows and
Linux OS: Red Hat Scripting: Python, shell, Perl, etc.
• Strong understanding on OS, network, Web servers and browsers.
• Strong in performance requirement analysis, and construction of performance test
cases.
• Strong understanding of Java, JSP, and JavaScript coding and the use of Java
SDK performance tools.
• Experience with HTTP and web services
• Deep knowledge in Java Performance (CPU, Memory, IO, SWAP, Network usage),
hotspot detection, GC logs, optimization and analysis of bottle-necks using various
profilers.
• suggest option for resolutions of problems Work individually on the tasks, not
required full attention from the TL, but yet, a Team player - working closely with
Developers, TLs and architect.
• Able to send executive summary of the tests
Небольшое замечание о презентации – мы затронем самые базовые вещи, не будет обсуждения хитрых метрик производительности и вопросов, какой показатель лучше презентовать менеджерам – среднее или верхний квартиль или «10 вещей, которые вы точно забудете в своём первом перформанс проекте» – все будет сильно проще ) Постараемся ответить на вопросы – зачем на нужно тестирование проихводительности и как его запустить в нашем модном agile проекте)
Итак, тема нашего обсуждения - тестирование производительности как часть agile процесса разработки продукта. Соответственно, прежде чем начать, определимся, что такое тестирование производительности.
Сейчас будет немного определений и, возможно, занудной классификации ) Прошу меня заранее простить.
Не мудрствуя лукаво, обратимся к определению из словаря ISTQB (International SW testing qualification board). Итак – тестирование производительности – это процесс тестирование, направленный на определение производительности продукта. А производительность – это одна из подхарактеристик качества - эффективности, которая является интуитивно понятной.
Зачем нужно тестирование производительности?
Гугл из года в год приводит результаты своих исследований, в которых указывает, что клиент, прождавший более трёх секунд после нажатия на ссылку и не дождавшийся загрузки страницы, с большой вероятностью выберет другой сайт. Мобильные устройства по-прежнему требуют от приложений умения работать на ограниченных ресурсах и в условиях плохих каналов связи. Базы данных бизнес-решений занимают терабайты, а клиент по-прежнему ждёт, чтобы отчёт формировался побыстрее. Именно поэтому в последнее время тестирование производительности становится всё более востребованным – потому что может принести вашей компании дополнительную прибыль
Несколько слов о тестировании производительности в целом.
Тестирование производительности является видов нефункционального тестирования и подразделяется на несколько видов –
Load testing – создаём ОЖИДАЕМУЮ нагрузку (количество пользователей и транзакций), определяем время отклика системы для различных операция, сравниваем с заранее определёнными KPI, проверяем потребляемые ресурсы системы
Stress Testing – даём нагрузку сверх ожидаемой и смотрим, что произойдёт с системой (упадёт, заберёт все ресурсы, начнёт тормозить). Убираем нагрузку, смотрим, вернулась ли система к нормальному поведению
Capacity testing – проверяем, сколько пользователей выдержит система, продолжая находиться в заданных рамках производительности.
На самом деле можно выделить ещё несколько подвидов тестирования производительности, но для нас – этого будет достаточно.
Кстати, предупреждаю сразу – все названия, произнесённые мною, трактуются по-разному различными специалистами. Некоторые, например, меняют местами performance и load testing.
Жизненный цикл тестирования производительности, в общем-то, ничего не отличается от любого другого вида тестирования
Планирование – Подготовка – Выполнение – Анализ-при необходимости повторное Выполнение
Планирование - анализируем структуру приложения, выявляем узкие места, определяем мониторы, которые нужно будет контролировать определяем KPI
Подготовка – готовим тестовые данные, тестовую лабораторию, пишем и отлаживаем скрипты и сценарии
Выполнение – очень необычно – но выполняем наши сценарии и собираем данные мониторов
Анализ – ещё более необычно – анализируем массив данных, полученных на предыдущем этапе. Готовим отчёты, анализируем причины проблем, открываем дефекты
НО
Если вы обратили внимание – то всех определениях использовались слова «пользователи» и «нагрузка». Отсюда достаточно просто сделать вывод, что тестирование производительности – это ВСЕГДА (ну ладно, почти всегда) автоматизированное тестирование (поскольку нам нужно эмулировать работу многих пользователей) с использованием инструментов для генерации нагрузки (которые стоят обычно немаленьких денег).
Тестирование производительности нуждается для проведения в соответствующей аппаратной инфраструктуре, её настройке и мониторинге. Можно, конечно, попробовать провести тесты на окружении, не похожем на продакшн, а потом экстраполировать результаты – но, как показывает практика, сделать это качественно получается достаточно редко.
И, наконец, для проведения анализа результатов неплохо иметь инженера, обладающего хотя бы зачатками знаний в области математической статистики, значит, нужно привлекать к процессу «дорогого» инженера.
К тому же, тестирование производительности - длительный процесс – тесты нужно написать, отладить, создать тестовую среду, прогнать тест (тест может длиться несколько дней или недель) и проанализировать результаты.
Итого, можно смело констатировать, что тестирование производительности - это дорогой (нужен Automation QA, разбирающийся в коде, аппаратных и программных составляющих и имеющих математический бэкграуд+железо) и долгий процесс. Запоминаем этот факт и идём дальше.
Теперь быстренько вспоминаем, что такое Agile. Agile – это манифест, определяющий подходы к разработке ПО. Не буду вдаваться в подробности и различные техники – но в любой методологии Agile основным принципом является частая поставка рабочего программного обеспечения. Два основных слова – частая и рабочего. Это приводит нас к тому, что за две недели (как обычно длится итерация) нам нужно провести полный цикл тестирования – в том числе и тестирования производительности. А как мы видели на предыдущем слайде – тестирование производительности - это длительный и дорогой процесс( Более того, возникает ещё один вопрос – поскольку тестирование производительности - это дорого, то неэффективно тратить ресурсы на систему, не прошедшую функциональное тестирование – ваши дорогостоящие тесты просто «свалятся» из-за функциональных багов.
Обычно после таких размышлений agile разработчики с опаской относятся к тестированию производительности и если и проводят его - то в минимальном объёме на релизной версии продукта, а то и после релиза. К чему это приводит? Клиент получает неторопливо работающее приложение, падающее при нагрузке в 50 пользователей и сжирающее все доступные на сервере ресурсы.
Но не всё так плохо. Давайте попробуем понять, как же нам встроить тестирование производительности в Agile и не потратить на это много ресурсов.
Итак, перед нами возникает несколько вопросов – Когда проводить, какие преимущества мы получим от связки performance testing&Agile и сколько это будет стоить?
Небольшое предупреждение – всё дальнейшее – не более, чем мой личный опыт и и вполне возможно вы встретите на просторах интернета аргументированные мнения, что Agile и Performance testing несовместимы
Вопрос номер раз – КОГДА?
Не ждите, пока ваше приложение «встанет на ноги». Чем раньше, тем лучше, поскольку, как мы все знаем, чем раньше мы нашли дефект, тем дешевле его исправить! Мы помним, что по Agile уже к концу первой итерации мы должны получить рабочий прототип – вот окончание первой итерации - время для нас запустить первые тесты. Не придумываем ничего нового – те же стандартные уровни тестирования – модульное, интеграционное, системное, приёмочное. Что тестировать, если приложение ещё сырое? У приложение ещё нет UI и API– не беда, займитесь тестированием на уровне компонентов, анализом кода, определением KPI. Появились первые элементы UI или первые методы API – займитесь первыми тестами для них.
Разработчики сломали ваши тесты – пока они чинят, займитесь single-user тестированием на больших объёмах данных, часто даже такой вид тестирования позволяет выявить узкие места.
Как видно на рисунке на любом уровне разработки и функционального тестирования есть место для вашей деятельности.
Постарайтесь «отставать» с запуском ваших сценариев от команды функционального тестирования на одну итерацию - так вы будете точно знать, какая функциональность готова к вашему тестированию и не будете тратить напрасно время, пытаясь понять, почему валятся ваши замечательные тесты.
Теперь к «плюшкам», которые мы можем получить внедрив performance testing в Agile. Запоминаем, чтобы рассказать потом менеджерам
Применение гибкого тестирования производительности позволяет снизить ряд рисков, возникающих при разработке приложений и положительно влияет на качество: Оптимизация кода: Оптимизация на уровне модулей происходит в начале разработки. Таким образом, издержки на исправления значительно ниже, чем если бы проблемы были выявлены на поздних стадиях. Отказы приложения: Снижается риск отказа приложения, вызванный такими факторами, как утечки памяти, взаимоблокировки в СУБД и “Хард-код”. Раннее обнаружение узких мест: Снижается трудоемкость и продолжительность тестирования производительности, а также уменьшается необходимость в повторном тестировании. Даты релиза: Тестирование каждую итерацию приводит к осведомленности о производительности приложения в любой момент времени. Благодаря этому, появляется больше шансов выпустить релиз в срок.
Проведение тестов на реальных данных и сценариях: поскольку Agile исповедует принцип Business people and developers must work together daily throughout the project – у вас есть отличная возможность получить от клиентов реальные сценарии использования продукта и наборы данных – поверьте, в тестировании производительности это дорого стоит. Можно рассказать массу занимательных историй, как были получены отличные отчёты по производительности на синтетических данных и что потом имели сказать нам клиенты, получившие продукт, не справлявшийся с их задачами. Проблемы производительности: Уменьшается количество проблем производительности на последующих этапах – а это нам даёт что? Правильно – громадное уменьшение стоимости исправления этих дефектов.
Итак – как прикрутить performance тестирование к Agile процессу и что нам это даёт - в общих чертах понятно.
Дорогие инструменты и оборудование для тестирование производительности!
Инструменты – наберите в поисковике free load testing tools – мне кажется, выбор достаточен – вот те, которые я нашёл по первой ссылке. Кстати, любой из них отлично встраивается в систему Continuous Delivery – например, в Jenkins, которая тоже бесплатная.
Сервера – это, конечно, дорого и нужно – но может быть, для вашего приложения для начала хватит мощности обычного десктопа, чтобы эмулировать 300 пользователей? По собственному опыту могу сказать – на первое время хватит.
Да и аренда машинного времени в облаке позволит вам минимизировать ваши затраты на организацию своей лаборатории по тестированию производительности.
Отдельно хотел бы остановится на коммерческом продукте от моей любимой компании HP, которым пользуемся мы в своей деятельности – LoadRunner от компании HP
Основные моменты, по которым вы будете его использовать –
Комьюнити версия – вся функциональность до 50 одновременных пользователей бесплатно
Функционал труклайент – позволяет вам создавать скрипты для нагрузочного тестирования чего угодно, имеющего web-интерфейс, методом тыка.
Интеграция с Selenium и Unit-фреймворками – через возможность использования в виде скриптов кода на C# и Java.
Инструмент автоматического анализа полученных результатов - позволяет делать качественные отчёты для стейкхолдеров, даже не обладая продвинутыми знаниями в нагрузочном тестировании и математической статистике
Итак, вы можете найти для себя инструмент, который позволит вам, имея минимальный опыт, быстро (решая проблему с короткими итерациями Agile) и недорого (решая проблему с ограниченным бюджетом) внедрить тестирование производительности в ваш проект и избежать многих проблем в дальнейшем.
Напоследок – думаю, я не сказал сегодня ничего, что вы не знали – но надеюсь, что помог вам посмотреть по-другому на привычные вещи и сделать шаг вперёд)
Всем спасибо за терпение и готов ответить на вопросы, если они у вас появились
