Файл: Тестирование производительности программ : подходы в зависимости от категорий приложений.pdf

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

Часто в «домашних» условиях тестирование стабильности совмещают со стресс-тестированием, то есть проверяют не только стабильность, но и способность приложения переносить жесткие условия и сильные нагрузки длительное время.[3,c.544]

Тестирование стабильности проводится с целью убедиться в том, что приложение выдерживает ожидаемую нагрузку в течение длительного времени. При проведении этого вида тестирования осуществляется наблюдение за потреблением приложением памяти, чтобы выявить потенциальные утечки. Кроме того, такое тестирование выявляет деградацию производительности, выражающуюся в снижении скорости обработки информации и (или) увеличении времени ответа приложения после продолжительной работы по сравнению с началом теста.[17]

Оценивание надежности программных комплексов включает измерение количественных характеристик: завершенности, устойчивости к дефектам, восстанавливаемости и доступности-готовности . При этом предполагается, что в контракте, техническом задании или спецификации требований зафиксированы, и утверждены заказчиком определенные значения этих характеристик и их приоритеты. Измерения проводятся при функционировании готового программного комплекса для сопоставления с заданными требованиями и для оценивания рисков соответствия этим требованиям. Тестирование для оценки надежности комплекса программ должно проводиться в тестовом окружении, которое максимально приближено к реальным условиям применения системы. Входные параметры тестов следует задавать на основе вероятностного распределения соответствующих характеристик или их наборов при эксплуатации программногоmкомплекса.[17]
Для прямых, количественных измерений надежности необходимы инструментальные средства, встроенные в операционную систему или в соответствующие компоненты комплекса программ. Эти средства должны в динамике реального функционирования программ, автоматически селектировать и регистрировать аномальные ситуации, дефекты и искажения вычислительного процесса, программ и данных, выявляемые аппаратным, программно-алгоритмическим контролем или пользователями. Накопление и систематизация проявлений дефектов при исполнении программ позволяет оценивать основные показатели надежности, помогает определять причины сбоев и отказов и подготавливать данные для повышения надежности программных комплексов. Регулярная регистрация и обобщение таких данных способствует устранению ситуаций, негативно влияющих на функциональную пригодность и другие важные динамические характеристики. [15]

2.3 Конфигурационное тестирование

Конфигурационное тестирование — ещё один из видов традиционного тестирования производительности. В этом случае вместо того, чтобы тестировать производительность системы с точки зрения подаваемой нагрузки, тестируется эффект влияния на производительность изменений в конфигурации. Хорошим примером такого тестирования могут быть эксперименты с различными методами балансировки нагрузки. Конфигурационное тестирование также может быть совмещено с нагрузочным, стресс или тестированием стабильности.[4,c.21]

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

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

2. Проект по миграции системы с одной платформы на другую. Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.[12,c.25]

Уровни проведения тестирования. Для клиент–серверных приложений конфигурационное тестирование можно условно разделить на два уровня (для некоторых типов приложений может быть актуален только один): серверный или клиентский.

На первом, то есть серверном уровне, тестируется взаимодействие выпускаемого программного обеспечения с окружением, в которое оно будет установлено:

1. Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети / сетевых адаптеров и т.д.)

2. Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т.д.). [14]

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

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

1. Тип, версия и битность операционной системы (подобный вид тестирования называется кросс–платформенное тестирование)

2. Тип и версия Web браузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс–браузерное тестирование)

3. Тип и модель видео адаптера (при тестировании игр это очень важно)

4. Работа приложения при различных разрешениях экрана

5. Версии драйверов, библиотек и т.д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки) и т.д.[15]

Порядок проведения конфигурационного тестирования. Перед началом проведения конфигурационного тестирования рекомендуется:

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

Уже на начальном этапе становится очевидно, что чем больше требований к работе приложения при различных конфигурациях рабочих станций, тем больше тестов необходимо будет провести. В связи с этим, рекомендуется автоматизировать этот процесс. Конечно же автоматизированное тестирование не является панацеей, но в данном случае оно окажется очень эффективным помощником. [13,c.72]

3. Определение целей тестирования производительности

В общих случаях тестирование производительности может служить разным целям.[12,c.19]

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

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

1.Параллелизм / Пропускная способность:

• Если конечными пользователями приложения считаются пользователи, выполняющие логин в систему в любой форме, то в этом случае крайне желательно достижение параллелизма. По определению это максимальное число параллельных работающих пользователей приложения, поддержка которого ожидается от приложения в любой момент времени. Модель поведения пользователя может значительно влиять на способность приложения к параллельной обработке запросов, особенно если он включает в себя периодически вход и выход из системы.[12,c.23]
• Если концепция приложения не заключается в работе с конкретными конечными пользователями, то преследуемая цель для производительности будет основана на максимальной пропускной способности или числе транзакций в единицу времени. Хорошим примером в данном случае будет являться просмотр веб-страниц, например, на портале Wikipedia.

2. Время ответа сервера.

Эта кон­цеп­ция стро­ит­ся во­круг вре­ме­ни от­ве­та од­но­го узла при­ло­же­ния на за­прос, по­слан­ный дру­гим. Про­стым при­ме­ром яв­ля­ет­ся HTTP 'GET' за­прос из бра­у­зе­ра ра­бо­чей стан­ции на веб-сер­вер. Прак­ти­че­ски все при­ло­же­ния, раз­ра­бо­тан­ные для на­гру­зоч­но­го те­сти­ро­ва­ния ра­бо­та­ют имен­но по этой схеме из­ме­ре­ний. Ино­гда це­ле­со­об­раз­но ста­вить за­да­чи по до­сти­же­нию про­из­во­ди­тель­но­сти вре­ме­ни от­ве­та сер­ве­ра среди всех узлов при­ло­же­ния.[12,c.27]

3.Время отображения.

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

4. Требования к производительности.

Очень важно де­та­ли­зи­ро­вать тре­бо­ва­ния к про­из­во­ди­тель­но­сти и до­ку­мен­ти­ро­вать их в ка­ком-ли­бо плане те­сти­ро­ва­ния про­из­во­ди­тель­но­сти. В иде­аль­ном слу­чае это де­ла­ет­ся на ста­дии раз­ра­бот­ки тре­бо­ва­ний при раз­ра­бот­ке си­сте­мы, до про­ра­бот­ки де­та­лей её ди­зай­на. См. Ин­же­не­рия про­из­во­ди­тель­но­сти.[12,c.30]

Од­на­ко те­сти­ро­ва­ние производительности часто не про­во­дит­ся со­глас­но спе­ци­фи­ка­ции, так как нет за­фик­си­ро­ван­но­го по­ни­ма­ния о мак­си­маль­ном вре­ме­ни от­ве­та для за­дан­но­го числа поль­зо­ва­те­лей. Те­сти­ро­ва­ние про­из­во­ди­тель­но­сти часто ис­поль­зу­ет­ся как часть про­цес­са про­фай­лин­га про­из­во­ди­тель­но­сти. Его идея за­клю­ча­ет­ся в том, чтобы найти «сла­бое звено» — такую часть си­сте­мы, соп­ти­ми­зи­ро­вав время ре­ак­ции ко­то­рой, можно улуч­шить общую про­из­во­ди­тель­ность си­сте­мы. Опре­де­ле­ние кон­крет­ной части си­сте­мы, сто­я­щей на этом кри­ти­че­ском пути, ино­гда очень непро­стая за­да­ча, по­это­му неко­то­рые при­ло­же­ния для те­сти­ро­ва­ния вклю­ча­ют в себя (или могут быть до­бав­ле­ны с по­мо­щью add-on’ов) ин­стру­мен­ты, за­пу­щен­ные на сер­ве­ре (аген­ты) и на­блю­да­ю­щие за вре­ме­нем вы­пол­не­ния тран­зак­ций, вре­ме­нем до­сту­па к базе дан­ных, овер­хе­да­ми сети и дру­ги­ми по­ка­за­те­ля­ми сер­вер­ной части си­сте­мы, ко­то­рые могут быть про­ана­ли­зи­ро­ва­ны вме­сте с осталь­ной ста­ти­сти­кой по про­из­во­ди­тель­но­сти.[12,c.43]

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

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

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

Таким образом, тестирование производительности позволяет обнаружить и устранить широкий спектр потенциальных проблем, которые программное средство может начать испытывать на стадии эксплуатации.[12,c.19]

4. Подходы в зависимости от категорий приложений

Из углубленно–изученного мною курса по технологиям программирования я вынес следующую классификацию видов тестирования. Тестирование бывает: