Тестирование ПО (реферат), страница 3

Перед началом тестирования всегда должен быть заданбизнес-вопрос: "Какую цель мы преследуем, тестируя производительность?".Ответы на этот вопрос являются частью технико-экономическогообоснования (или business case) тестирования. Цели могут различаться взависимости от технологий, используемых приложением, или егоназначения, однако, они всегда включают что-то из нижеследующего:Параллелизм / Пропускная способностьЕсли конечными пользователями приложения считаются пользователи,выполняющие логин в систему в любой форме, то в этом случае крайнежелательно достижение параллелизма. По определению это максимальноечисло параллельных работающих пользователей приложения, поддержкакоторого ожидается от приложения в любой момент времени.

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

Простым примером являетсяHTTP 'GET' запрос из браузера рабочей станции на веб-сервер. Практическивсе приложения, разработанные для нагрузочного тестирования работаютименно по этой схеме измерений. Иногда целесообразно ставить задачи подостижению производительности времени ответа сервера среди всех узловприложения.Время отображенияВремя отображения - одно из самых сложных для приложения длянагрузочного тестирования понятий, так как в общем случае они неиспользуют концепцию работы с тем, что происходит на отдельных узлахсистемы, ограничиваясь только распознаванием периода времени в течениекоторого нет сетевой активности. Для того, чтобы замерить времяотображения, в общем случае требуется включать функциональные тестовыесценарии в тесты производительности, но большинство приложений длятестирования производительности не включают в себя такую возможность.Требования к производительностиОчень важно детализировать требования к производительности идокументировать их в каком-либо плане тестирования производительности.В идеальном случае это делается на стадии разработки требований приразработке системы, до проработки деталей её дизайна.

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

Оно также может проводиться и локально, но в этом случаенеобходимо настроить сетевые маршрутизаторы таким образом, чтобыпоявилась задержка, присутствующая во всех публичных сетях. Нагрузка,прилагаемая к системе, должна совпадать с реальным положением дел. Такнапример, если 50% пользователей системы для доступа к системеиспользуют сетевой канал шириной 56К, а другая половина используетоптический канал, то компьютеры, создающие тестовую нагрузку на системудолжны использовать те же соединения (идеальный вариант) илиэмулировать задержки вышеуказанных сетевых соединений, следуязаданным профайлам пользователей.Типичные вопросы тестирования производительностиТребования к производительности должны адресовать следующие, какминимум, вопросы:Что охватывается тестом производительности? Какие подсистемы,компоненты, интерфейсы и т.д.

должны быть протестированы? Если в тест включаются пользовательские интерфейсы, то сколькоодновременно работающих в системе пользователей ожидается длякаждого интерфейса (необходимо определить пиковые и нормальныезначения) Как выглядит аппаратная составляющая тестируемой системы?(Необходимо описать все сервера и сетевое оборудование) Каков сценарий использования каждого компонента системы? (например,20% запросов составляет вход в систему, 40% - поиск, 30% - выборэлемента, 10% - выход из системы) Каков сценарий использования системы? [в одном тесте напроизводительность могут быть задействованы разные сценариииспользования каждого компонента] Каковы требования ко времени выполнения серии операций сервернойчасти приложения?ИнструментарийСуществует распространённое ошибочное понимание того, чтоинструменты для нагрузочного тестирования системы - это инструментытакие же по принципу записи и воспроизведения как и инструменты дляавтоматизации регрессионного тестирования. Инструменты для нагрузочноготестирования работают на уровне протокола, тогда как инструменты дляавтоматизации регрессионного тестирования работают на уровне объектовграфического пользовательского интерфейса.ПримерИмеется стандартный интернет-браузер, выполняющий функциюперехода по указанной ссылке при нажатии кнопки.В данном случае для автоматизации регрессионного тестированиянеобходимо написать скрипт, передающий браузеру клик мышью и нажатиекнопки, в то время как для создания скрипта для нагрузочного тестированиянеобходимо написать передачу гиперссылки от браузера для несколькихпользователей, включая уникальные для каждого из них имя пользователя ипароль.Существуют различные инструменты для обнаружения и исследованияпроблем в различных узлах системы.

Все узлы системы могут бытьклассифицированы следующим образом:Приложение База данных Сеть Обработка на клиентской стороне Балансировка нагрузкиТакже следует отметить появление сетевых Business-to-business (B2B)приложений, использующих соглашение об уровне услуг (или SLA, ServiceLevel Agreement). Нарастающая популярность B2B приложений привело ктому, что всё больше приложений переходит на сервис-ориентированнуюархитектуру, в случае которой обмен информацией происходит без участиявеб-браузеров.

Примером такого взаимодействия может служить бюротуристических услуг, запрашивающее информацию об определённомавиарейсе между Санкт-Петербургом и Омском, в то время как авиакомпанияобязана предоставить ответ в течение 5 секунд. Часто нарушение договора обSLA грозит крупным штрафом.Наиболее популярные инструменты для нагрузочного тестированияпредставлены ниже.ПОOpenSTAIBM RationalPerformanceTesterНаименованиепроизводителяКомментарии'Open SystemTestingArchitecture'Свободно распространяемое программноеобеспечение для нагрузочного/стресстестирования, лицензированное GNU GPL.Использует распределенную архитектуруприложений, основанную на CORBA.Доступна версия под Windows, хотяимеются проблемы с совместимостью сWindows Vista.

Поддержка прекращена в2007 году.IBMОснованное на средеразработки Eclipse ПО, позволяющеесоздавать нагрузку больших объёмов иизмерять время отклика для приложений склиент-серверной архитектурой. Требуетлицензирования.JMeterОснованный на Java кроссплатформенныйинструментарий, позволяющийпроизводить нагрузочные тесты сОткрытый проект использованием JDBC / FTP / LDAP /Apache JakartaSOAP / JMS / POP3 / HTTP / TCPProjectсоединений. Даёт возможность создаватьбольшое количество запросов с разныхкомпьютеров и контролировать процесс содного из них.HPLoadRunnerHPSilkPerformerMicro FocusVisualStudioLoadTestMicrosoftИнструмент для нагрузочноготестирования, изначально разработанныйдля эмуляции работы большого количествопараллельно работающих пользователей.Также может быть использован для unitили интеграционного.Visual Studio предоставляет инструментдля тестирования производительностивключая load / unit testingОдним из результатов, получаемых при нагрузочном тестировании ииспользуемых в дальнейшем для анализа, являются показателипроизводительности приложения.

Основные из них разобраны ниже.1. Потребление ресурсов центрального процессора (CPU, %)Метрика, показывающая сколько времени из заданного определённогоинтервала было потрачено процессором на вычисления для выбранногопроцесса. В современных системах важным фактором является способностьпроцесса работать в нескольких потоках, для того, чтобы процессор могпроизводить вычисления параллельно. Анализ истории потребления ресурсовпроцессора может объяснять влияние на общую производительность системыпотоков обрабатываемых данных, конфигурации приложения иоперационной системы, мультипоточности вычислений, и других факторов.2.

Потребление оперативной памяти (Memory usage, Mb)Метрика, показывающая количество памяти, использованной приложением.Использованная память может делиться на три категории:Virtual - объём виртуального адресного пространства, котороеиспользует процессор. Этот объём не обязательно подразумевает,использование соответствующего дискового пространства илиоперативной памяти. Виртуальное пространство конечно ипроцесс может быть ограничен в возможности загружатьнеобходимые библиотеки. Private - объём адресного пространства, занятого процессором ине разделяемого с другими процессами. Working Set - набор страниц памяти, недавно использованныхпроцессом. В случае, когда свободной памяти достаточно,страницы остаются в наборе, даже если они не используются.

Вслучае когда, свободной памяти остается мало, использованныестраницы удаляются.При работе приложения память заполняется ссылками на объекты,которые, в случае неиспользования, могут быть очищены специальнымавтоматическим процессом, называемым "сборщиком мусора" (англ. GarbageCollector). Время затрачиваемое процессором на очистку памяти такимспособом может быть значительным, в случае, когда процесс занял всюдоступную память (в Java - так называемый "постоянный Full GC") или когдапроцессу выделены большие объёмы памяти, нуждающиеся в очистке.