SE_labs

Инженерия программного обеспечения

<th>Address</th>

<th>City</th>

<th>Stars</th>

</tr>

<%

for(Hotel hotel : hotelList){

%>

<tr>

<td><%=hotel.getName()%></td>

<td><%=hotel.getAddress()%></td>

<td><%=hotel.getCity()%></td> <td><%=hotel.getStars()%> stars</td> </tr>

<%

}

%>

</table>

<%}%>

</body>

</html>

12. Выполните команды mvn install для веб-модуля. Получим собранный веб-модуль приложения hotelweb-1.0.war в каталоге /target и локальном репозитории maven.

Для запуска созданного веб-приложения необходимо установить tomcat:

$> aptitude install tomcat6 tomcat6-admin tomcat6-docs tomcat6-examples tomcat6-user

(точное название пакетов для Fedora проверьте через yum search tomcat6).

В файле /etc/tomcat6/tomcat-users.xml задаем пароль для пользователя admin.

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

гин tomcat-maven-plugin:

<plugin>

<groupId>org.codehaus.mojo</groupId> <artifactId>tomcat-maven-plugin</artifactId> <configuration>

<url>http://localhost:8080/manager/html</url>

<server>mainId</server>

</configuration>

</plugin>

Т.е. указываем адрес веб-сервера, где необходимо развернуть вебприложение.

Данные для авторизации на указанном сервере необходимо про-

писать в файле /etc/maven2/settins.xml в разделе <servers>:

<server>

<id>mainId</id>

41

Методические указания к выполнению лабораторных работ

<username>admin</username> <password>пароль</password>

</server>

Теперь достаточно в каталоге проекта выполнить mvn tomcat:deploy и веб-приложение будет доступно по адресу: http://localhost:8080/hotelweb.

13. Maven полностью поддерживает ant и для интеграции с ant существуют соответствующие плагины - “maven-ant-plugin” и “maven-antrun-plugin”.

Первый из них предназначен для генерации на основании pomфайла с maven-проектом, файла build.xml.

Если в каталоге с проектом выполнить команду mvn ant:ant, то мы получим файл build.xml и maven-build.xml для проекта и каждого его модуля. В maven-build.xml -файлах определяются ant “цели”, названия которых совпадают с названиями фаз жизненного цикла из мира maven: clean, compile, compile-tests, test, package …Файл build.xml со-

держит только подключение файла maven-build.xml. Если выполнить команду “ant compile”, то в каталоге target получим скомпилированный и готовый к работе файл модуля.

Плагин antrun позволяет вызывать из maven кусочки ant-кода.

3.3.2 MAVEN-ИЗАЦИЯ КУРСОВОГО ПРОЕКТА ПО ДИСЦИПЛИНЕ «МОДЕЛИРОВАНИЕ»

1.Maven-зируем проект по моделированию (если проект в стадии разработки еще не появился, берем на kid проект-пример BuldoExample). Собираем и инсталируем в локальный репозиторий используемую библиотеку Simulation.

2.Для своего проекта объявляем зависимость от артефакта

Simulation.

3.Для правильного формирования файла Manifest настраиваем плагин jar (указываем главный исполняемый класс, и задаем

динамическое формирование переменной classpath)

<plugin>

<groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration>

<archive>

<manifest>

<addClasspath>true</addClasspath>

<classpathPrefix>lib/

</classpathPrefix>

<mainClass>buldo0.Buldo0App

</mainClass>

</manifest>

</archive>

</configuration>

42

Инженерия программного обеспечения

</plugin>

Для автоматического копирования всех библиотек, от которых зависит наш проект, из локального репозитория артефактов в заданный каталог (в данном случае /lib) добавляем соответствующие настройки плагина dependency:

<plugin>

<groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions>

<execution> <id>copy-dependencies</id> <phase>package</phase> <goals><goal>copy-

dependencies</goal></goals>

<configuration>

<outputDirectory>target/lib

</outputDirectory>

</configuration>

</execution>

</executions>

</plugin>

4. Собираем и запускаем приложение: mvn package

java -jar BuldoExample.jar

3.4 Задания для самостоятельной работы

1.Изучить практические аспекты интеграции maven с системой сборки ant.

2.Изучить практические аспекты интеграции maven с средой разработки eclipse.

3.Выполнить запуск разработанных модульных тестов проекта с использование среды разработки eclipse.

3.5Содержимое отчета

–содержимое файла глобальных настроек maven;

–содержимое файлов pom.xml для каждого модуля webприложения;

–исходные тексты тестов для классов бизнес-логики приложения;

–результаты запуска тестов (находятся в каталоге

/targets/surefire-reports/);

–результаты запуска приложения на сервере;

–содержимое файла pom.xml для проекта по дисциплине «Моделирование»;

–выводы.

43

Методические указания к выполнению лабораторных работ

3.6 Контрольные вопросы

1.Назначение систем сборки. Примеры подобных систем.

2.Особенности системы сборки maven.

3.Конфигурация файла сборки проекта с использованием maven.

4.Понятие архетипа проекта.

5.Понятие артефакта maven.

6.Управление зависимостями в maven. Транзитивные зависимости.

7.Понятие и назначение плагинов в maven. Их настройка.

8.Управление maven-репозиториями.

9.Назначение и принципы написания модульных тестов.

10.Создание модульных тестов с использованием библиотеки

JUnit 4.

44

Инженерия программного обеспечения

4Лабораторная работа №4 Нагрузочное тестирование

4.1 Цель работы

Изучение принципов нагрузочного тестирования. Практическое применение кроссплатформенного инструмента Jmeter (Apache Jakarta Project).

4.2Теоретические сведения

4.2.1ПОНЯТИЕ И НАЗНАЧЕНИЕ НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ

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

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

например, http, odbc, NCA и др.

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

–время отклика (время выполнения операции);

–число операций, выполняемых в единицу времени (TPS –

transactions per second).

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

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

45

Методические указания к выполнению лабораторных работ

Итак, нагрузочное тестирование (англ. Load Testing) — определение или сбор показателей производительности и времени отклика про- граммно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).

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

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

Нагрузочное тестирование тесно связано с тестированием объемов, что подразумевает оценку способности системы обрабатывать объемы данных по мере их накопления (рост базы данных сайта спустя несколько месяцев, тем более лет, может оказаться значительным – а сможет ли наш код работать с ней?). Существует понятие тестирование масштабируемости, которое также тесно связано с тестированием производительности; основная его цель – оценка роста производительности приложения по мере добавления ресурсов (память, процессор и т.д.)

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

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

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

46

Инженерия программного обеспечения

–25 пользователей просматривают товар и выходят из системы;

–25 пользователей добавляют товар в корзину, оформляют его и выходят из системы;

–25 пользователей используют функцию возврата товара и выходят из системы;

–25 пользователей входят в систему и не проявляют никакой активности.

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

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

Одним из оптимальных подходов в использовании нагрузочно-

го тестирования для измерений производительности системы тестирование на стадии ранней разработки. Нагрузочное тестирование первых стадиях готовности архитектурного решения с целью определить состоятельность называется 'Proof-of-Concept' тестированием.

4.2.2 ОСНОВНЫЕ ПРИНЦИПЫ НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ

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

1. Уникальность запросов.

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

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

2. Время отклика системы.

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

47

Методические указания к выполнению лабораторных работ

В частности это означает, что имея достаточное количество измерений, можно определить вероятность, с которой отклик системы на запрос попадёт в тот или иной интервал времени.

3.Зависимость времени отклика системы от степени распределенности этой системы.

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

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

4.Разброс времени отклика системы.

Из утверждений 1, 2 и 3 можно также заключить, что при достаточно большом количестве измерений величины времени обработки запроса в любой системе всегда найдутся запросы, время обработки которых превышает определенные в требованиях максимумы; причем, чем больше суммарное время проведения эксперимента тем выше окажутся новые максимумы.

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

5. Точность воспроизведения профилей нагрузки.

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

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

4.2.3 ИНСТРУМЕНТАРИЙ ДЛЯ ТЕСТИРОВАНИЯ ПРОИЗВОДИТЕЛЬНОСТИ

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

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

48

Инженерия программного обеспечения

–приложение;

–база данных;

–сеть;

–обработка на клиентской стороне;

–балансировка нагрузки.

Наиболее популярные инструменты для нагрузочного тестирования представлены ниже.

Таблица 4.1 – Инструменты нагрузочного тестирования

ПО				Описание
OpenSTA		Свободно распространяемое						программ-
		ное обеспечение			для		нагрузочно-
		го/стресс тестирования, лицензированное								GNU
		GPL. Использует		распределенную				архитекту-
		ру приложений, основанную на CORBA. Дос-
		тупна версия под Windows, хотя имеются про-
		блемы совместимости с Windows Vista. Под-
		держка прекращена в 2007 году.
IBM	Rational	Основанное	на	среде		разработки			Eclipse
Performance Tester		ПО, позволяющее создавать нагрузку боль-
		ших объемов	и	измерять			время		отклика
		для приложений с клиент-серверной архитекту-
		рой. Требует лицензирования.
JMeter		Основанный	на		Java		кроссплатформен-
		ный инструментарий,			позволяющий				произво-
		дить нагрузочные тесты с использованием JDBC
		/ FTP / LDAP / SOAP / JMS / POP3 / HTTP /
		TCP соединений.		Даёт		возможность			созда-
		вать большое	количество				запросов		с	раз-
		ных компьютеров		и	контролировать				процесс
		с одного из них.
HP		Инструмент для нагрузочного тестирования,
LoadRunner		изначально разработанный для эмуляции
		работы большого количество параллельно
		работающих пользователей. Также может быть
		использован для unitили интеграционного.
Visual		Visual Studio предоставляет инструмент для
Studio Load		тестирования производительности включая
Test		load / unit testing.

49

Методические указания к выполнению лабораторных работ

4.3 Порядок выполнения работы

1.Развертывание тестируемого веб-приложения на веб-сервере romcat.

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

Для запуска тестируемого веб-приложения необходимо устано-

вить tomcat:

aptitude install tomcat6 tomcat6-admin tomcat6-docs tomcat6-examples tomcat6-user

Вфайле /etc/tomcat6/tomcat-users.xml создаем роль для менеджера

исоздаем пользователя, у которого та же роль:

<role rolename="manager"/>

<user username="manager" password="qwerty" roles="manager"/>

Перезапускаем сервер.

sudo /etc/init.d/tomcat6 restart

Для запуска менеджера веб-приложений tomcat необходимо в браузере ввести строку http://127.0.1.1:8080/manager/html. При этом нужно указать пароль, который был создан ранее (user : «manager», pass : «qwerty»).

После этого нужно поместить ваш проект на сервер. Для этого при помощи графического интерфейса в меню WAR file to deploy (рисунок 4.1) необходимо выбрать war-файл и нажать кнопку deploy. После чего можно заходить на главную страницу вашего приложения.

Рисунок 4.1 – Загрузка проекта на сервер 2. Установка и запуск Jmeter.

50