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

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

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

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

Тестирование сегодня

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

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

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

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

Бизнес требует изменений

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

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

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

Особенности тестирования на основе целевых параметров

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

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

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

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

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

Главное отличие — более значимые результаты

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

  1. Какова нормальная производительность конечных пользователей, работающих с системой?
  2. Какое количество одновременно работающих пользователей должно поддерживаться?
  3. Насколько быстро система должна откликаться на запросы?
  4. Какие уровни использования системных ресурсов приемлемы?

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

Тестирование, основанное на принципе целевых параметров, напротив, позволяет определять точные требования к системе до запуска тестов и предоставляет более углубленные ответы по четырем важным вопросам, заданным выше. Фактически, при тестировании могут быть заданы вопросы наподобие: «Какое количество пользователей сможет одновременно работать с приложением при условии, что время реакции системы не превышает Х секунд, без угрозы перегрузки системы?», или «Насколько я могу быть уверенным в точности полученных результатов?»

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

Пора начать учитывать условия реального мира

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

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

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

Пол Даун — главный консультант компании Embarcadero Technologies.

Сценарий тестирования на основе целевых параметров

Критерии теста
  • 1000 одновременно работающих пользователей.
  • 8-секундное время обработки запроса в 90% случаев.
  • Использование ресурса центрального процессора менее чем на 85%.
  • Полный контроль инфраструктуры приложения (база данных, Web-сервер, сервер приложений и др.).
Три стадии тестирования

Стадия 1. Увеличивать нагрузку, пока не будут достигнуты либо 8-секундный отклик, либо 85-процентный уровень использования центрального процессора. Если время отклика достигнет 8-секундного уровня ранее, чем будут подключены 1000 пользователей — прекратить тест. Если уровень использования процессора превысит 85%, прекратить тест. Если время отклика превысит 8-секундный уровень при подключении более 1000 пользователей, завершить стадию.

Стадия 2. Испытать систему при постоянной нагрузке. Если уровень загрузки процессора превысит 85%, прекратить тест. Если тест в этой стадии продолжается в течение 15 минут, завершить стадию.

Стадия 3. Уменьшать нагрузку, пока все пользователи не будут отключены.

Результаты

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

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

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

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

Достижения

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

Тестирование на основе целевых параметров в системе Embarcadero Extreme Test

Методика тестирования на базе целевых параметров реализована в системе Extreme Test компании Embarcadero Technologies. Данный программный инструментарий представляет собой набор средств для измерения и анализа производительности приложений масштаба предприятия. Система позволяет точно определить и изолировать узкие места приложения и на основе этих данных принимать продуманные решения о выделении ресурсов, обосновании готовности приложения к эксплуатации и планированию мероприятий на случай возникновения экстремальных ситуаций с производительностью. Extreme Test — инструментарий для ИТ-специалистов, отвечающих за производительность корпоративных Web-приложений, масштабируемость и производительность серверов баз данных на различных платформах и миграцию прикладных инфраструктур.

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

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

Кроме того, Extreme Test включает редактор моделей пользовательского поведения — Extreme Test?s User Model Editor, который позволяет автоматически создавать максимально реалистичные пользовательские сценарии, что, в свою очередь, дает возможность получать более точные и содержательные результаты тестирования.

Рис. Архитектура Extreme Test

Embarcadero Extreme Test предлагает масштабируемую архитектуру для сквозного тестирования производительности обработки запросов к приложениям (см. рис). Поддержка различных платформ гарантирует, что тесты, разработанные для одной среды, можно будет использовать и для приложений на базе других инфраструктур. Одним из основных направлений разработок Embarcadero является управление инфраструктурой баз данных. Свой опыт в этой области компания привнесла в систему Extreme Test, в которой реализован обширный набор средств генерации нагрузки для баз данных. Система предоставляет возможности автоматической генерации нагрузки, а также моделирования операций чтения/записи и пользовательских соединений по JDBC для практически неограниченного набора источников данных. Помимо нагрузочного тестирования серверов баз данных, учитывающего специфику этого вида инфраструктурного программного обеспечения, система обеспечивает средства стрессового тестирования для серверов приложений и Web-серверов.

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

Интегрированный репозиторий системы обеспечивает:

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

Универсальное рабочее место Universal Workbench, входящее в Extreme Test, заменяет разрозненные инструменты тестирования. Компонент системы обеспечивает единый интерфейс для управления всеми аспектами тестирования, включая настройку среды, создание теста, его выполнение и анализ полученных результатов. Universal Workbench предоставляет единую консоль для выполнения всех задач и проведения всех этапов тестирования, что способствует повышению продуктивности специалистов, работающих с системой. Extreme Workbench включает инструментарий, необходимый для генерации нагрузочных тестов от начала и до конца: создание, отладка и компиляция тестовых скриптов, конфигурирование устройств, которые вовлечены в тестирование, сбор всех тестовых артефактов, отображение необходимых для анализа таблиц и статистических данных по ходу выполнения текста. Интеграция в универсальное рабочее место системы инструментов, подобных редактору кодов и отладчику, способствует повышению эффективности разработки приложений.

Extreme Test имеет интегрированную среду создания скриптов на базе стандартного языка JavaScript, которая позволяет упростить и гарантировать точность разработки пользовательских скриптов тестирования. Пользователям предоставляются средства понимания кода, быстрой навигации, отладки и встроенной документации в форме JavaDoc. Система позволяет идентифицировать точные точки тестирования, а также генерировать тестовые скрипты по любому пользовательскому сценарию. Интегрированная среда создания скриптов обеспечивает:

  • автоматическое создание скриптов;
  • отладку и компиляцию скриптов;
  • редактирование скриптов;
  • вызов типовых скриптов тестирования.

— Наталья Дубова