Home

Спонсор: Compuware

Перевод: RedRoxx Technologies

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

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

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

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

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

Разрушение барьеров

Compuware предлагает такую возможность в виде решения Automated Software Quality, или ASQ (Автоматизированное Обеспечение Качества). ASQ состоит из двух частей — первая часть обеспечивает автоматическую генерацию виртуальных пользователей для моделирования реальной нагрузки, а вторая — предоставляет возможности для анализа производительности отдельных операций на уровне кода.

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

Решение Compuware ASQ реализовано для двух наиболее распространенных распределенных платформ — Miscrosoft .Net и Java. ASQ можно использовать как для отдельных приложений, так и для распределенных приложений — как с толстым клиентом, так и для веб-приложений.

Использование решения

ИТ-организации могут найти свой уникальный способ использования решения ASQ для исследования проблем производительности и масштабируемости. Тем не менее, если говорить в контексте совместной работы разработчиков и тестировщиков, то существует классический подход, при котором начинать нужно с нагрузочного тестирования на стадии тестирования, используя инструменты Compuware QACenter Performance Edition.

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

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

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

Рисунок 1 . Compuware QACenter Performance Edition генерирует виртуальных пользователей.

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

По этой информации можно сделать вывод о том, что для данной тестовой конфигурации существует некоторое предельное количество пользователей, которое она может выдержать. Использование CPU на тестовом сервере увеличивается по мере добавления новых пользователей. Когда число виртуальных пользователей достигает 200, использование CPU практически постоянно находится на уровне 100%. В этой точке время отклика начинает стремительно возрастать. Очевидно, тестовый сервер уже не справляется с нагрузкой, которую генерирует QACenter Performance Edition. Таким образом, мы обнаружили узкое место производительности нашей тестовой среды в виде процессорной мощности сервера.

Эта информация может помочь тестировщикам сделать прогноз относительно того уровня уже реальной назгрузки, при котором время отклика приложения станет неприемлемым для пользователей. Далее этот прогноз можно использовать уже при планировании мощностей и и управления уровнем качества услуг (SLA).

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

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

Рисунок 2 . Compuware DevPartner показывает распределение времени выполнения тразнакции и числа выполнений по строчкам кода

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

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

Например, на Рис.2 показаны результата анализа производительности DevPartner для сессии нагрузочного тестирования, рассмотренного раньше. Передвигаясь по списку методов, легко определить, какая фукнция или функции выполнялись медленнее с ростом нагрузки. В данном случае, анализ необходимо сосредоточить на функции, выполняющей обращение к базе данных, так как эта функция выполняется дольше, чем большинство других операций. Более детальный анализ кода показал, что соединение с базой данных, которое открывается на чтение, не закрываетя после завершения чтения. Это отсутствие операции закрытия соединения приводит к утечке: объект уже не используются, но остается ссылка на него, поэтому он не может быть удален сборщиком мусора. Если посмотреть на колонку Count (Рис. 2), можно увидеть, что эта операция выполнялась несколько миллионов раз, в результате чего объем занятой памяти существенно вырос, а производительность, соответственно, снизилась.

Диаграмма использования памяти DevPartner подтверждает наличие утечки памяти, вызванной отсутствием явного закрытия соединения с базой данных. На ней (Рис. 3) видно, что количество занимаемой памяти неуклонно увеличивается. Явное закрытие соединения устраняет утечку и увеличивает производительность и надежность приложения.

Рисунок 3 . Диаграмма RAM footprint показывает динамическое распределение памяти во времени

Анализ производительности DevPartner сам по себе занимает довольно мало ресурсов. Тесты показывают, что процесс сбора данных требует от 2,5 до 3 процентов CPU. Если все же такой уровень дополнительных накладных расходов можеть искажать результаты нагрузочного тестирования, рекомендуется сначала выполнить нагрузочное тестирование отдельно, чтобы обнаружить, существуют ли проблемы производительности или масштабируемости, а затем выполнить его уже вместе с анализом производительности, чтобы локализовать эти проблемы.

Для использования анализа производительности DevPartner необходимо установить либо DevPartner Studio (Microsoft), либо DevPartner Java Edition c лицензией DevPartner Studio Server или DevPartner Java Server. Пример, показанный на Рис.1 и 2 был взят с демонстрационного e-commerce приложения, используемого консультантами и инженерами Compuware, работаюего на двух машинах 600 MHz Pentium III 256 MB RAM.

Заключение

Обеспечение хорошей производительности и масштабируемости распределенных приложений не должно быть сложным и ресурсоемким. Объединяя решения Compuware для нагрузочного тестирования и анализа производительности, тестировщики теперь могут предоставлять разработчикам всю необходимую информацию для анализа, диагностики и исправления проблем производительности, не имея специальной технической подготовки или знания исходного кода. Если в процессе нагрузочного тестирования обнаруживается проблема, они могут подключить к конфигурации Compuware DevPartner и собрать информацию, с помощью которой разработчики приложения легко и быстро найдут и исправят дефект. Такой подход можно использовать для Miscrosoft-, Java-приложений или их комбинаций, для приложений с толстым клиентом, веб-приложений или сервисов.

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