Введение

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

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

Задачи, которые решает тестирование производительности

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

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

Гибкая методология

Компании по всему миру работают над тем, чтобы создавать продукты более высокого качества за меньшее время. Для достижения этой цели многие производители начали применять гибкие методологии разработки. Именно такой подход поможет ускорить выход продукта на рынок, повысить его качество и увеличить производительность, а также объединить различные цели бизнеса и технологии. Использование гибких методологий разработки дает мощный импульс компаниям. Cогласно аналитическому отчету ведущей международной исследовательской компании Forrester, в последние годы значительно возрос интерес к гибким методологиям. По сравнению с традиционной водопадной моделью, гибкая методология позволяет получить большую ценность за более короткий срок, а также значительно увеличивает ROI.

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

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

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

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

Тестирование производительности при гибкой разработке

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

Цель заключается в определении узких мест ключевых бизнес-процессов жизненного цикла ПО на самой ранней стадии. Для этого необходимо определить, локализовать и устранить узкие места производительности на уровне компонент или кода.
Методика тестирования производительности в гибкой методологии включает в себя 3 этапа оптимизации:

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

Уровень компонент: Выполнение тестов для локализации и устранения узких мест на уровне компонент приложения.

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

Оптимизация на уровне модулей

Цель

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

Начальные условия

Тестирование производительности на уровне модулей производится во время разработки приложения при помощи unit-тестов для оптимизации функций.

Последовательности действий

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

Оптимизация на уровне компонент

Цель

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

Начальные условия

Компоненты развернуты на соответствующих серверах приложений.

Последовательность действий

• Определить компоненты приложения на основе следующих характеристик:
  1. Высокая критичность для бизнеса и эксплуатации.
  2. Могут быть развернуты и использованы независимо друг от друга.
• Зафиксировать требования к масштабируемости и времени отклика каждой компоненты.
• Подготовить скрипты для вызова отдельных компонент.
• Выполнить тесты для каждой компоненты в отдельности. Для двух основных типов узких мест приложения, выполняются следующие тесты:
  1. Параллельный тест: Выполняются одновременные запросы к компонентам с возрастающей нагрузкой до тех пор, пока не возникнет ошибок.
  2. Тест на пропускную способность: Компоненты тестируются на большое количество обращений в секунду с ограниченным числом пользователей.
•  При помощи полученных результатов, оптимизировать компоненты на уровне программной и аппаратной конфигурации и выполнить тесты повторно.

Оптимизация на уровне приложения

Цель

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

Начальные условия

Приемочное тестирование завершено и приложение работает стабильно.

Последовательность действий

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

Три модели: уровни успеха

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

По требованию

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

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

Распределение компетенций

Модель «Распределения компетенций» может использоваться как промежуточный шаг между моделью «По требованию» и «Полным погружением». У многих организаций может быть недостаточно тестировщиков, а также могут отсутствовать среды нагрузочного тестирования и инструменты для тестирования, чтобы поддерживать модель полного погружения.

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

• Специалист по нагрузочному тестированию должен быть доступен команде во время серьезных переработок продукта в области производительности;
• Данная модель может потребовать большее число тестировщиков и инструментов, чем модель «По требованию».

Полное погружение

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

Гибкое тестирование производительности и снижение рисков

Применение гибкого тестирования производительности позволяет снизить ряд рисков, возникающих при разработке приложений и положительно влияет на качество:
Оптимизация кода: Оптимизация на уровне модулей происходит в начале разработки. Таким образом, издержки на исправления значительно ниже, чем если бы проблемы были выявлены на поздних стадиях.
Отказы приложения: Снижается риск отказа приложения, вызванный такими факторами, как утечки памяти, взаимоблокировки в СУБД и “Хард-код”.
Раннее обнаружение узких мест: Снижается трудоемкость и продолжительность тестирования производительности, а также уменьшается необходимость в повторном тестировании.
Даты релиза: Тестирование каждую итерацию приводит к осведомленности о производительности приложения в любой момент времени. Благодаря этому, появляется больше шансов выпустить релиз в срок.
Проблемы производительности: Уменьшается количество проблем производительности на последующих этапах.
Трудоемкость тестирования производительности: Тесты производительности могут быть использованы повторно, благодаря чему сохраняется до 60% затрат на тестирование.

Заключение

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

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

 

Адаптация статьи «Agile Performance Testing process — Whitepaper»: Оригинал