Інженерія програмного забезпечення 2020

Вступ
Курс «Инженерия программного обеспечения» посвящен изучению ос-

новных принципов управления программными проектами, методологий и
технологий поддержки и оптимизации разработки качественного программ-
ного обеспечения.
В методических указаниях приведена теоретическая база и рассматри-
ваются практические аспекты администрирования и использования систем
поддержки командной разработки крупных программных проектов, а именно:
систем управления проектами, распределенных систем управления версиями
документов, систем автоматизации сборки программного обеспечения и сис-
тем автоматизации тестирования приложений (включая модульное и нагру-
зочное тестирование).
Методические указания основаны на использовании принципов agile-
разработки программного обеспечения и ориентированы на использование
свободно распространяемого программного обеспечения.
Методические указания могут использоваться при выполнении команд-
ных курсовых проектов и работ студентами выпускных курсов (например, по
таким дисциплинам как «Объектно-ориентированное программирование»,
«Моделирование», «Технологии проектирования программных систем» и др.)
с целью изучения принципов настройки и использования инструментария
поддержки процесса разработки, а также управления конфигурациями разра-
батываемого программного обеспечения.
Обов‘язковими до виконання є лабораторні роботи № 1, 2, 3, 4 (для

отримання мінімальних балів з дисципліни див. вимоги до кожної з л.р.).
Методичні вказівки до виконання лабораторних робіт
Содержание
ВСТУПЛЕНИЕ .......................................................................................... 1
ЛАБОРАТОРНАЯ РАБОТА №0 (*) ИНСТРУМЕНТЫ УПРАВЛЕНИЯ
ПРОЕКТАМИ (PROJECT MANAGEMENT) ............................................................ 4
1.1 Цель работы ............................................................................ 4
1.2 Теоретические сведения ........................................................ 4
1.3 Порядок выполнения работы ................................................ 4
1.4 Задания для самостоятельной работы .................................. 6
1.5 Содержимое отчета ................................................................ 6
1.6 Контрольные вопросы............................................................ 7
1 ЛАБОРАТОРНАЯ РАБОТА №1 ВСТАНОВЛЕННЯ ТА НАЛАШТУВАННЯ
СЕРВЕРА GIT ...................................................................................................... 8
1.7 Цель работы ............................................................................ 8
1.8 Теоретические сведения ........................................................ 8
1.8.1 Протоколы работы с git-сервером................................... 8
1.8.2 Установка и начальная настройка Git-сервера .............. 8
1.8.3 Настройка доступа к Git-серверу с
использованием Gitosis .................................................... 9
1.8.4 Настройка публичного доступа к репозиторию с
использованием Gitweb .................................................. 12
1.8.5 Интеграция системы управления проектами
Redmine с Git ................................................................... 13
1.9 Порядок выполнения работы .............................................. 13
1.10 Задания для самостоятельной работы ................................ 14
1.11 Содержимое отчета .............................................................. 14
1.12 Контрольные вопросы.......................................................... 15
2 ЛАБОРАТОРНАЯ РАБОТА №2 ІНСТРУМЕНТИ ЗБОРКИ ПРОЕКТІВ
(MAVEN) 16
2.1 Цель работы .......................................................................... 16
2.2 Теоретические сведения ...................................................... 16
2.3.1 Организация сборки многомодульного проекта ......... 17
2.3.2 Maven-изация курсового проекта по дисциплине
«Моделирование» ........................................................... 29
2.6 Контрольные вопросы.......................................................... 31
3 ЛАБОРАТОРНАЯ РАБОТА №3 ЗАСОБИ МОДУЛЬНОГО ТЕСТУВАННЯ
(JUNIT) 32
3.1 Цель работы .......................................................................... 32
2
Інженерія програмного забезпечення

4 ЛАБОРАТОРНАЯ РАБОТА №4 ТЕСТУВАННЯ ПРОДУКТИВНОСТІ ПЗ
(APACHE JMETER)........................................................................................... 41
4.1 Цель работы .......................................................................... 41
4.2.1 Понятие и назначение нагрузочного тестирования .... 41
4.6 Контрольные вопросы ......................................................... 48
5 ЛАБОРАТОРНАЯ РАБОТА №5 (*) ЗАСОБИ БЕЗПЕРЕРВНОЇ ІНТЕГРАЦІЇ
(CONTINUOUS INTEGRATION SERVERS – HUDSON (JENKINS).......................... 49
5.1 Цель работы .......................................................................... 49
5.2 Краткие теоретические сведения ........................................ 49
5.3 Принцип работы ................................................................... 49
5.4 Сборка по расписанию......................................................... 49
5.5 Порядок выполнения лабораторной работы ..................... 50
3
Лабораторная работа №0 (*)

Инструменты управления проектами (Project Man-
agement)
1.1 Цель работы
Изучить функции современных систем управления проектами и
научиться применять их на практике. Получить навыки установки, на-
стройки и администрирования системы управления проектами Redmine.
1.2 Теоретические сведения

Управление проектами – это достижение четких целей в опреде-
ленные сроки. Достаточно сложно точно определить, как достичь по-
ставленной цели в заданный срок, в условиях ограниченности ресурсов
и непредсказуемых внешних условий. Управление проектами всегда
связано с рисками и обычно определяется тремя взаимозависимыми
факторами – время, ресурсы (материальные средства, участники, внеш-
ние аутсорсинговые услуги) и качество результата. Управление проек-
тами – это принятие решений в отношении 3 этих факторов. Например,
можно пойти на снижение качества результата, и повышение затрат, но
уложиться в срок.
Хотя управление проектами слабо поддается автоматизации, сис-
темы управления проектами помогают провести расчет времени проек-
та, спланировать ресурсы и предоставляют инструменты для общения и
совместной работы в команде. Подобные проекты предлагают общее
решение для организации работы над любым видом проекта.
При управлении проектами важнейшую роль играет вопрос коор-
динации работы всех участников, обмена информацией, учета и плани-
рования работ. Системы управления проектами предоставляют воз-
можность участникам получать информацию о состоянии проекта, при-
оритетах задач, истории задач и др.
Существуют платные системы управления проектами (Team
Foundation Server, JIRA и др.) и open source системы (Mantis Bug Track-
er, Trac, Redmine и др.). Полный обзор систем приведен на сайте
http://en.wikipedia.org/wiki/Comparison_of_project_management_software.
1.3 Порядок выполнения работы

1. Формирование команды для выполнения лабораторных работ.
Состав команды желательно оставить таким же, как при выпол-
нении КП по дисциплине «ООП», поскольку на базе лабораторных ра-
бот и КП будет выполняться РГР.
2. Установка системы Redmine:
4
– установить ruby:
для ОС Ubuntu:
$ aptitude install ruby1.8 ruby1.8-dev irb rdoc ri
для ОС Fedora:
$ yum install ruby ruby-devel ruby-libs ruby-mode
ruby-rdoc ruby-irb ruby-ri ruby-docs
– скачать менеджер пакетов ruby (пакет rubygems 1.3.7), рас-
паковать и выполнить в корне директории команду:
$ ruby setup.rb
– с помощью менеджера пакетов ruby, установить rails вер-
сии 2.3.5, rack 1.0.1 и rake 0.8.3 соответствующими коман-
дами, например:
$ gem install rails –v=2.3.5
– установить модуль ruby mysql:
$ gem install mysql –with-mysql-
config=/path/to/mysql_config
– скопировать и распаковать пакет redmine-1.0.0.tar.gz;
– создать пустую базу данных MySQL и соответствующего
пользователя redmine, предоставив ему права на созданную
базу:
create database redmine character set utf8;
create user 'redmine'@'localhost' identified by
'my_password';
grant all privileges on redmine.* to
'redmine'@'localhost';
– указываем настройки БД для ‗production‘ в файле con-
fig/database.yml.
– создаем ключ сессии, выполнив в корневой директории:
$ rake generate_session_store
и структуру базы данных:
$ rake db:migrate RAILS_ENV="production"
– заполняем БД данными конфигурации:
$ rake redmine:load_default_data
RAILS_ENV="production"
– настраиваем доступ (пользователь, от имени которого за-
пущен Redmine, должен иметь права на запись к директори-
ям files, log, tmp):
$ useradd redmine
$ chown -R redmine:redmine files log tmp pub-
lic/plugin_assets
$ chmod -R 755 files log tmp public/plugin_assets
– проверим установку:
$ ruby script/server webrick -e production
По адресу http://localhost:3000 заходим на стартовую стра-
ницу Redmine.
3. Настраиваем веб-сервер apache для работы redmine.
5
– устанавливаем модуль Passenger Apache:

$ gem install passenger
$ cd /var/lib/gems/1.8/gems/passenger-2.2.15
$ bin/passenger-install-apache2-module
– необходимо раскомментировать строку в файле
config/environment.rb:
ENV['RAILS_ENV'] ||= 'production'
– в конфигурационный файл apache добавим загрузку модуля
passenger:
LoadModule passenger_module
/usr/lib/ruby/gems/1.8/gems/passenger-
2.2.15/ext/apache2/mod_passenger.so
<IfModule passenger_module>
PassengerRoot
/usr/lib/ruby/gems/1.8/gems/passenger-2.2.15
PassengerRuby /usr/bin/ruby1.8
PassengerDefaultUser www-data
</IfModule>
– создать символическую ссылку на директорию установки
redmine:
$ ln -s /opt/redmine/redmine-1.0.0
/var/www/redmine
– создаем виртуальный хост для redmine:
<VirtualHost *:80>
ServerName redmine.local
DocumentRoot /var/www/redmine/public
LogLevel warn
ErrorLog /var/log/apache2/redmine_error
CustomLog /var/log/apache2/redmine_access combined
<Directory /var/www/redmine/public>
AllowOverride all
Order allow,deny
Allow from all
Options -MultiViews Indexes FollowSymLinks
</Directory>
</VirtualHost>
– проверить установку.
4. Изучить функциональные особенности системы.
5. Изучить функции администрирования и настройки системы.
1.4 Задания для самостоятельной работы

Создать собственное оформление (тему) системы.
1.5 Содержимое отчета

– название и тема лабораторной работы;
– цель лабораторной работы;
– описание процесса установки Redmine;
6
– функционал системы;
– выводы.
1.6 Контрольные вопросы

1. Что входит в понятие «ресурсы программного проекта»?
2. Принципы agile-разработки.
3. Перечислите основные характеристики и возможности систе-
мы Redmine.
7
1 Лабораторная работа №1
Встановлення та налаштування сервера git
Дослідження архітектури, синтаксису та принципів роботи з роз-
поділеними системами керування версіями документів на прикладі git.
Створення та налаштування серверу git-репозиторію.
Інтеграція системи керування проектами Redmine c Git-
репозиторием (*якщо виконували лаб.роботу №0).

1.8.1 ПРОТОКОЛЫ РАБОТЫ С GIT-СЕРВЕРОМ
Git работает с четырьмя сетевыми протоколами для передачи

данных: локальный, SSH, Git и HTTP, HTTPS.
SSH — наиболее часто используемый транспортный протокол,
предоставляющий доступ и на чтение, и на запись. Два других сетевых
протокола (HTTP и Git) в большинстве случаев дают доступ только на
чтение.
Git-протокол ― самый быстрый из доступных протоколов, обыч-
но используется в паре с SSH разработчиков, имеющих доступ на за-
пись, тогда как все остальные используют git:// для доступа на чтение.
Протоколы HTTP и HTTPS просты в настройке. Использование
доступа к репозиторию по HTTP не очень эффективно: операции clone
и fetch обычно выполнятся намного дольше, и при этом расходуется
намного больше трафика, чем при использовании других протоколов.
1.8.2 УСТАНОВКА И НАЧАЛЬНАЯ НАСТРОЙКА GIT-СЕРВЕРА
Установка Git для ОС Fedora: $ yum install git-core, для

Ubuntu: $ aptitude install git-core.
Далее приводятся команды для ОС Ubuntu.
Для начальной настройки Git-сервера, необходимо экспортиро-
вать существующий репозиторий в новый «чистый» (bare) репозиторий
— репозиторий, который не содержит рабочей копии.
$ git clone --bare my_project my_project.git
Initialized empty Git repository in
/opt/projects/my_project.git/
Для создания чистого репозитория используйте команду:
git --bare init
После того, как получена чистая копия репозитория, необходимо
поместить ее на Git-сервере и настроить протокол доступа к Git-
репозиторию. К примеру, есть сервер git.example.com с SSH-доступом.
8
Для создания хранилища репозиториев на сервере в каталоге /opt/git,

необходимо просто скопировать репозиторий:
$ scp -r my_project.git user@git.example.com:/opt/git
В этом случае, все пользователи, которые имеют SSH-доступ к
серверу и имеют доступ на чтение каталога /opt/git могут клонировать
(clone) проект из репозитория, используя команду:
$ git clone user@git.example.com:/opt/
git/my_project.git
Если ssh-пользователь имеет доступ на запись (write access) к ка-
талогу /opt/git/my_project.git, он автоматически получит доступ на вне-
сение изменений в репозиторий (push access).
Настроим SSH-доступ к репозиторию. Будем использовать метод
authorized_keys для аутентификации пользователей. Для начала, соз-
дайте пользователя git и директорию .ssh в домашнем каталоге пользо-
вателя.
Теперь необходимо добавить публичные SSH-ключи в файл
authorized_keys пользователя git. К примеру, публичные ключи разра-
ботчиков (пользователей Git-репозитория) получены и находятся в ка-
талоге /tmp.
$ cat /tmp/id_rsa.vasya.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.petya.pub >> ~/.ssh/authorized_keys
В данном случае для создания репозитория нового проекта один
из пользователей репозитория должен создать «чистый» репозиторий
на сервере. Каждый из пользователей (admin, vasya, petya) могут соз-
дать локальный репозиторий проекта следующим образом:
$ git clone git@gitserver:/home/git/project.git
Можно ограничить пользователя git возможностью работы только
с Git-репозиторием (выполнение git-команд) с помощью ограниченного
shell (git-shell), который устанавливается вместе с Git. Для этого необ-
ходимо отредактировать /etc/passwd и задать git-shell вместо bash или
csh в качестве shell, используемого для доступа к серверу для пользова-
теля git:
git:x:1000:1000::/home/git:/usr/bin/git-shell
1.8.3 НАСТРОЙКА ДОСТУПА К GIT-СЕРВЕРУ С ИСПОЛЬЗОВАНИЕМ GITOSIS
Gitosis — набор скриптов для управления файлом authorized_keys

и организации простого контроля доступа к репозиторию. Для управ-
ления доступом к репозиторию используется специальный Git-
репозиторий.
Для установки Gitosis требуется наличие установленных python-
setuptools:
$ aptitude install python-setuptools
Клонируем и устанавливаем Gitosis с главного сайта проекта:
9
$ git clone git://eagain.net/gitosis.git

$ cd gitosis
$ sudo python setup.py install
Gitosis создает хранилище репозиториев в каталоге /home/git.
Gitosis автоматически управляет публичными ключами для дос-
тупа к репозиторию, поэтому переместим файл authorized_keys, ключи
разработчиков добавим позже:
$ mv /home/git/.ssh/authorized_keys
/home/git/.ssh/ak.bak
Далее необходимо инициализировать Gitosis с вашим публичным
ключом (если он не на сервере, скопируйте его сюда):
$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
Initialized empty Git repository in /home/git/gitosis-
admin.git/
Reinitialized existing Git repository in
/home/git/gitosis-admin.git/
Это позволит пользователю (с указанным публичным ключом)
вносить изменения в главный Git-репозиторий для настройки Gitosis.
Необходимо настроить возможность выполнения post-update скрипта:
$ sudo chmod 755 /home/git/gitosis-
admin.git/hooks/post-update
Если все верно настроено, можно получить репозиторий управле-
ния доступом к Git-серверу, использую ssh-доступ пользователя, для
которого был добавлен публичный ключ при инициализации Gitosis.
# on your local computer
$ git clone git@gitserver:gitosis-admin.git
После копирования репозитория, появится каталог gitosis-admin.
Файл gitosis.conf используется для определения пользователей, репози-
ториев проектов и прав доступа к ним. Директория keydir используется
для хранения публичных ключей всех пользователей, которые имеют
какой-либо доступ к репозиторию.
Изначально файл gitosis.conf содержит информацию только для
проекта gitosis-admin:
$ cat gitosis.conf
[gitosis]
[group gitosis-admin]
writable = gitosis-admin
members = git
Т.е. git – единственный пользователь, который имеет доступ к ре-
позиторию проекта gitosis-admin.
К примеру, добавим новый проект. Создадим новый раздел
mobile, в котором перечислим разработчиков команды mobile и проек-
тов, к которым разработчики должны иметь доступ. Создадим новый
проект iphone_project. Изменим содержимое файла gitosis.conf:
[group mobile]
10
writable = iphone_project
members = git
После внесения изменений в проект gitosis-admin, необходимо
зафиксировать изменения и отправить изменения на сервер:
$ git commit -am 'add iphone_project and mobile group'
[master]: created 8962da8: "changed name"
1 files changed, 4 insertions(+), 0 deletions(-)
$ git push
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 272 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@gitserver:/home/git/gitosis-admin.git
fb27aec..8962da8 master -> master
Можно начать работу с новым проектом iphone_project, указав
его как удаленный репозиторий для локальной копии проекта. Нет не-
обходимости в создании «чистой» копии репозитория для новых проек-
тов на сервере — Gitosis создает их автоматически при первой отправке
изменений в проект (push).
$ git remote add origin
git@gitserver:iphone_project.git
$ git push origin master
Initialized empty Git repository in
/home/git/iphone_project.git/
Counting objects: 3, done.
Writing objects: 100% (3/3), 230 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@gitserver:iphone_project.git
* [new branch] master -> master
Чтобы предоставить доступ другим пользователям к проекту, не-
обходимо добавить их публичные ключи в каталог keydir.
$ cp /tmp/id_rsa.vasya.pub keydir/vasya.pub
$ cp /tmp/id_rsa.petya.pub keydir/petya.pub
После этого можно добавить новых пользователей в группу
mobile для предоставления доступа (read/write) к проекту
iphone_project:
[group mobile]
members = git vasya petya
Для предоставления пользователю vasya доступа к проекту толь-
ко на чтения, необходимо изменить gitosis.conf:
[group mobile]
members = git petya
[group mobile_ro]
readonly = iphone_project
members = vasya
11
Создадим группу mobile, наследуя всех участников группы mo-

bile_committers:
[group mobile_committers]
members = git vasya petya
[group mobile]
members = @mobile_committers
Желательно также добавить loglevel=DEBUG в разделе [gitosis].
1.8.4 НАСТРОЙКА ПУБЛИЧНОГО ДОСТУПА К РЕПОЗИТОРИЮ С ИСПОЛЬЗОВА-
НИЕМ GITWEB
При неоходимости предоставить анонимный доступ на чтение к

Git-репозиторию проекта, самый простой способ — запустить веб-
сервер, указав в качестве document root директорию, содержащую хра-
нилище Git-репозиториев проектов. Для этого можно использовать лю-
бой веб-сервер, рассмотрим на примере Apache.
Итак, хранилище репозиториев находится в каталоге /home/git и
сервер Apache на машине должен быть запущен.
Для начала активируем post-update hook:
$ cd project.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
post-update hook выглядит следующим образом:
$ cat .git/hooks/post-update
#!/bin/sh
exec git-update-server-info
Теперь при отправке изменений на сервер по SSH, Git запустит
данную команду, чтобы обновить файлы, необходимые для выполнения
команды fetch по HTTP.
Далее необходимо добавить VirtualHost в конфигурационном
файле Apache-сервера, указав document root, где находится корневая
директория Git-проектов.
<VirtualHost *:80>
ServerName git.gitserver
DocumentRoot /home/git
<Directory /home/git/>
Order allow,deny
allow from all
</Directory>
</VirtualHost>
Необходимо также предоставить группе www-data доступ к ди-
ректории /home/git, чтобы веб-сервер имел доступ на чтение каталога с
репозиториями.
$ chgrp -R www-data /home/git
12
После перезапуска сервера Apache, появится возможность клони-

ровать репозитории из указанного хранилища репозиториев следую-
щим образом:
$ git clone http://git.gitserver/project.git
После того как настроен read/write и read-only доступ к проекту,
настроим веб-интерфейс для отображения репозитория с использовани-
ем GitWeb.
Для начала, необходимо получить исходный код GitWeb и сгене-
рировать CGI-скрипт:
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git/
$ make GITWEB_PROJECTROOT="/home/git" \
prefix=/usr gitweb/gitweb.cgi
$ sudo cp -Rf gitweb /var/www/
Переменная GITWEB_PROJECTROOT должна указывать на ди-
ректорию, где необходимо искать Git-репозитории проектов.
Необходимо, чтобы Apache использовал CGI для этого скрипта.
Добавим VirtualHost в конфигурационный файл Apache:
<VirtualHost *:80>
ServerName gitserver
DocumentRoot /var/www/gitweb
<Directory /var/www/gitweb>
Options ExecCGI +FollowSymLinks
+SymLinksIfOwnerMatch
AllowOverride All
order allow,deny
Allow from all
AddHandler cgi-script cgi
DirectoryIndex gitweb.cgi
</Directory>
</VirtualHost>
Теперь по адресу http://gitserver/ возможно просмотреть репози-
торий проекта, а указывая http://git.gitserver как путь к репозиторию,
можно копировать репозиторий по HTTP.
1.8.5 ИНТЕГРАЦИЯ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ REDMINE С GIT
Для подключения репозитория проекта заходим в настройки про-

екта, переходим на закладку «Репозиторий», выбираем git и указываем
путь к репозиторию. Redmine позволяет организовать обзор содержи-
мого репозитория, истории изменений, отличия различных версий и др.
Существует возможность привязывать изменения в репозитории
к определенным задачам, а также автоматическое изменение статуса
задач при выполнении определенных коммитов в репозитории проекта.

Для отримання оцінки (максимально) 75 (С) балів:
13
1. Установить и настроить git / Або створити репозиторій про-

екту на публічному сервісі https://github.com/.
2. Каждая команда создает Git-репозиторий своего проекта и по-
мещает туда исходный код проекта (в качестве проекта можно
использовать курсовой проект по любой дисциплине).
3. Виконати та зафіксувати в звіті стандартну сесію роботи з Git-
репозиторієм.
Для отримання оцінки вище 75 (С) балів

1. Установить и настроить git.
2. Каждая команда создает Git-сервер с главным репозиторием
своего проекта и помещает туда исходный код проекта (в каче-
стве проекта можно использовать курсовой проект по любой
дисциплине).
3. Настроить read/write-доступ к Git-репозиторию для каждого
члена команды с использованием Gitosis (або ін.).
Для отримання оцінки вище 90 (А) балів

1. Додатково до попереднього блоку (оцінка вище 75 (С) балів)
Настроить публичный доступ на чтение к репозиторию и веб-
интерфейс с использованием Gitweb.
1. Запустить Redmine.
2. Создать в Redmine свой проект и настроить для него репозито-
рий.

1. Ознайомитись із додатковим синтаксисом команд git
(https://eln.stu.cn.ua/pluginfile.php/82756/mod_folder/content/0/progit.pdf?f
orcedownload=1).
2. Разобраться с настройкой шаблонов коммитов для автоматиче-
ского изменения статуса задач в системе Redmine (раздел «Админист-
рирование»).

– описание процесса создания Git-репозитория и предостав-
ления доступа к нему (используя два способа, указанных в
задании); привести результаты выполнения команд;
– содержимое конфигурационных файлов;
– сессия работы (своя для каждого члена команды) с резуль-
татами выполнения команд;
– результаты настройки репозитория для проекта в Redmine в
виде скриншотов;
14
– процесс настройки шаблонов коммитов для связи с задача-

ми проекта и примеры, отображающие результат настройки.

1. Назначение систем управления версиями документов.
2. Методики организации совместной работы над файлами без
конфликтов.
3. Архитектурные особенности систем управления версиями.
Архитектурные особенности git.
4. Сессия работы с проектом в git-репозитории.
5. Переключение из одной ветки git в другую без фиксации изме-
нений в текущую.
15
Інструменти зборки проектів (maven)
Изучение цикла сборки проекта. Практическое применение инст-
румента сборки maven. Добавление фазы тестирования в жизненный
цикл проекта. Написание модульных тестов с использованием библио-
теки JUnit.

Процессы компиляции, тестирования, сборки и развертывания
проекта на сервере (если это веб-приложение) осуществляются неодно-
кратно на протяжении всего жизненного цикла программного обеспе-
чения. Осуществлять процесс сборки ПО вручную при большом числе
исходных файлов, учитывая зависимости между модулями проекта, а
также зависимости от сторонних библиотек, требуемых для сборки,
практически невозможно. Кроме того, сборка проекта должна происхо-
дить независимо от среды разработки. Цикл сборки должен включать
этап тестирования с генерацией отчетов о пройденных и проваленных
тестах.
Процесс создания готового дистрибутива ПО также требует ав-
томатизации, т.к. существует огромное количество форматов создавае-
мых пакетов в зависимости от ОС, платформы, дистрибутива Linux и
т.д.
Системы сборки предназначены для автоматизации указанных
процессов. Примеры подобных систем – утилита make, набор утилит
Autotools (autoconf, automake, libtool, gnulib), qmake, bakefile, Cmake,
ant, Gant, maven.
Мaven – инструмент декларативного описания проекта. Maven
вводит понятие объектной модели проекта (Project Object Model –
POM), описание проекта, его уникальные координаты, перечень зави-
симостей и другие атрибуты.
Преимущества использования подобной модели:
1. Управление зависимостями.
Поскольку каждому проекту ставятся в соответствие уникальные
координаты (groupId:artifactId:version), то эти же координаты исполь-
зуются для определения зависимостей.
2. Удаленные репозитории.
Координаты, определяемые в POM-модели, используются для
индексирования и поиска нужных артефактов в maven-репозиториях.
3. Стандартизация цикла сборки проекта.
16
Плагины maven (plugins) реализуют последовательность действий

для различных фаз цикла сборки и организуют сборку проекта в соот-
ветствии с его описанием (тип проекта и др.) и настройками конфигу-
рационных переменных для плагинов, определенными в POM-модели
проекта.
4. Интеграция с различными средами разработки.
Среды разработки (Eclipse, NetBeans, and IntelliJ) создают свои
собственные файлы проектов, в которых хранят информацию о проек-
те, причем для разных IDE эти файлы разные. Maven стандартизирует
описание проекта и позволяет сгенерировать файлы проекта для той
иной среды разработки на основе модели проекта.
5. Простой поиск и загрузка требуемых артефактов.
Возможность автоматического поиска и загрузки нужных биб-
лиотек-артефактов из удаленных репозиториев благодаря уникальным
координатам артефакта, а также существует возможность организации
собственного репозитория артефактов и настройки репозиториев для
проекта.

2.3.1 ОРГАНИЗАЦИЯ СБОРКИ МНОГОМОДУЛЬНОГО ПРОЕКТА
1. Установить пакет maven2

aptitude install maven2.
Установите переменные окружения maven2
export PATH=$PATH:$HOME/maven2/bin
Проверьте правильность установки и настройки maven командой
$> mvn --version
2. Настроить репозиторий артефактов (локальный) для maven.
Поскольку нам нужны глобальные настройки репозитория (для
всех проектов), то редактируем файл
/путь/к/maven2/settings.xml (аналогично репозиторий можно
было прописать в pom.xml файле конкретного проекта). В раз-
деле <profiles></profiles> добавляем:
<profile>
<id>stuRepo</id>
<repositories>
<repository>
<id>main</id>
<name>StuRepository</name>
<url>http://devel.stu.cn.ua:8081/artifactory/repo/
</url>
<layout>default</layout>
</repository>
<repository>
<id>snapshots</id>
17
<url>http://devel.stu.cn.ua:8081/artifactory/repo/
</url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>http://devel.stu.cn.ua:8081/artifactory/plugi
ns-releases/</url>
<snapshots>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>snapshots</id>
<url>http://devel.stu.cn.ua:8081/artifactory/plugi
ns-snapshots/</url>
<releases>
</releases>
</pluginRepository>
</pluginRepositories>
</profile>
И активируем профайл:
<activeProfiles>
<activeProfile>stuRepo</activeProfile>
</activeProfiles>
3. Создадим многомодульный проект — веб-приложение, пре-
доставляющее информацию о гостиницах. Приложение состо-
ит из двух модулей:
– модуль бизнес-логики: business-logic.jar;
– модуль веб-приложения: hotelweb.war.
В каталоге проекта создадим модуль бизнес-логики приложения.
Используя плагин archetype, создадим «пустой» maven-проект для мо-
дуля бизнес-логики:
mvn archetype:generate
Выберите архетип под номером 15 (internal -> maven-archetype-
quickstart (), тип packaging для проекта — jar). Укажите
groupId=se.lab03, artifactId=business-logic, version=1.0
Теперь создадим заготовку проекта для модуля веб-интерфейса
нашего приложения (в каталоге проекта). Для этого используем плагин
archetype, указав соответствующий тип шаблона проекта (maven-
archetype-webapp):
mvn archetype:generate
18
Выберите архетип под номером 18 (18: internal -> maven-

archetype-webapp (A simple Java web application). Укажите
groupId=se.lab03, artifactId=hotelweb, version=1.0.
Полученная структура проекта приведена на рисунке 3.1.
Рисунок 3.1 — Структура многомодульного проекта

4. Плагин eclipse позволяет выполнить генерацию проекта для
среды разработки eclipse. Настройки плагина можно добавить
в главный pom.xml файл проекта.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<dowloadSources>true</dowloadSources>
<dependenciesAsLibra-
ries>true</dependenciesAsLibraries>
<useFullNames>false</useFullNames>
</configuration>
</plugin>
После выполнения команды mvn eclipse:eclipse, maven сгенериру-
ет файлы проекта, которые необходимы для работы в среде разработки
eclipse. Для полной поддержки maven в Eclipse необходимо загрузить
19
соответствующий плагин, но для выполнения данной лабораторной ра-

боты это необязательно.
5. Редактируем главный pom.xml файл, который находится в
корне каталога с нашим проектом. Содержимое родительского
pom.xml файла:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>${app.groupid}</groupId>
<artifactId>hotelproject</artifactId>
<version>${app.version}</version>
<packaging>pom</packaging>
<name>Hotel Project</name>
<modules>
<module>business-logic</module>
<module>hotelweb</module>
</modules>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId> org.apache.maven.plugins
</groupId>
<artifactId> maven-compiler-plugin
</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
<properties>
<app.groupid>se.lab03</app.groupid>
<app.version>1.0</app.version>
<app.finalname>${artifactId}-
${app.version}</app.finalname>
</properties>
</project>
Поскольку название проекта и его версия будет повторяться во
всех трех (одном родительском и двух дочерних) проектах, то создадим
глобальные переменные в родительском проекте. Внутри секции
―properties‖ создаем три переменные ―app.groupid‖, ―app.version‖ и
―app.finalname‖. На эти имена переменные будем ссылаться при объяв-
20
лении maven-координат проекта. Значение элемента packaging для ро-

дительского проекта имеет значение pom. Для настройки параметров
компиляции создаем элемент build, внутри которого определяем пара-
метры для плагина ―maven-compiler-plugin‖, в частности версию ис-
пользуемого компилятора.
В modules указываем два дочерних модуля: business-logic и мо-
дуль hotelweb. Порядок размещения не важен, т.к. внутри файлов pom,
описывающих дочерние модули, мы будем явно декларировать список
нужных для них зависимостей.
6. Редактируем pom.xml для модуля business-logic
<parent>
</parent>
<artifactId>business-logic</artifactId>
<packaging>jar</packaging>
<name>Hotel business-logic application</name>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Поскольку данный модуль является дочерним по отношению к
другому проекту, то в самом начале pom-файла размещаем ссылку на
родительский модуль внутри элемента parent. При описании группы ар-
тефакта модуля и его версии используем объявленные в родительском
pom-файле переменные ${myapp.groupid} и ${myapp.version}. В списке
зависимостей модуля от внешних библиотек определена библиотека
junit, так как она понадобится для написания тестов. Причем область
действия (scope) этой зависимости установлена «test», т.е. библиотека
будет подключена только на этапе тестирования проекта.
7. Pom.xml файл web-модуля приложения
21
<parent>
</parent>
<artifactId>hotelweb</artifactId>
<packaging>war</packaging>
<name>Hotel webapp tutorial application</name>
<dependencies>
<dependency>
<artifactId>business-logic</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.4</version>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
Для веб-модуля определили две зависимости – зависимость от
модуля business-logic и библиотеки servlet-api.
Однако для зависимости business-logic мы не указали область
действия scope. А значит, maven будет подключать к веб-модулю и
business-logic и нужные для business-logic ресурсы всегда (и при компи-
ляции проекта и при упаковке модуля в war-файл). Для того чтобы со-
общить maven о том, что какой-то артефакт не нужно упаковывать в
war-файл, нужно установить для этого артефакта область scope равной
―provided‖ (будет предоставлен кем-то еще). Добавьте к элементу зави-
симости (dependency) для артефакта business-logic новый тег
<scope>provided</scope>.
8. Перейдем к реализации модуля бизнес-логики приложения.
Создадим пакет domain для хранения классов бизнес-логики, и
services — для хранения сервисов нашего приложения.
Класс объекта гостиница Hotel.java:
22
package se.lab03.domain;
public class Hotel {

private String name;
private String address;
private String city;
private int stars;
/**
* Default constructor;
*/
public Hotel() {
super();
// TODO Auto-generated constructor stub
}
/**
* Bean Constructor using field values.
* @param name
* @param address
* @param city
* @param stars
*/
public Hotel(String name, String address, String city,
int stars) {
super();
// TODO Auto-generated constructor stub
this.name = name;
this.address = address;
this.city = city;
this.stars = stars;
}
/**
* @return Returns the address.
*/
public String getAddress() {
return address;
}
/**
* @param address The address to set.
*/
public void setAddress(String address) {
this.address = address;
}
/**
* @return Returns the city.
*/
public String getCity() {
return city;
}
/**
* @param city The city to set.
*/
23
public void setCity(String city) {

this.city = city;
}
/**
* @return Returns the name.
*/
public String getName() {
return name;
}
/**
* @param name The name to set.
*/
public void setName(String name) {
this.name = name;
}
/**
* @return Returns the stars.
*/
public int getStars() {
return stars;
}
/**
* @param stars The stars to set.
*/
public void setStars(int stars) {
this.stars = stars;
}
}
Класс сервисов HotelService.java реализует два метода: findAvai-
lableCities() method, который предоставляет список доступных городов,
и findHotelsByCity() method, который возвращает перечень гостиниц
для заданного города.
package se.lab03.services;
import java.util.ArrayList;
import java.util.List;
import se.lab03.domain.Hotel;
public class HotelService {
private static String[] cities =

{
"Chernigov",
"Kiev",
};
private static Hotel[] hotels = {
new Hotel("Ukraine","pr. Mira, 18","Chernigov",2),
24
new Hotel("Bryansk","Shevchenko str.,

17","Chernigov",2),
new Hotel("Gradetskiy","pr. Mira,
19","Chernigov",3),
new Hotel("Verhovina","Krechatik str.,
135","Kiev",4),
new Hotel("Krechatik","Krechatik str.,
14","Kiev",5),
};
public List<Hotel> findHotelsByCity(String city){
List<Hotel> hotelsFound = new ArrayList<Hotel>();
for(Hotel hotel : hotels) {
if (hotel.getCity().equalsIgnoreCase(city)) {
hotelsFound.add(hotel);
}
}
return hotelsFound;
}
public String[] findAvailableCities() {
return cities;
}
}
Создадим тесты для классов Hotel.java и HotelService.java.
package se.lab03.domain;
import java.util.List;
import org.junit.*;
import static org.junit.Assert.*;
public class HotelTest {

protected Hotel hotel;
@Before
public void prepareTest() {
hotel = new Hotel();
assertNotNull(hotel);
}
@Test
public void testHotelNullFields() {
assertNull(hotel.getName());
assertNull(hotel.getAddress());
assertNull(hotel.getCity());
assertEquals(0,hotel.getStars());
}
}
Добавьте тесты для методов установки и получения (getters и
setters) характеристик объекта Hotel. Аналогично добавьте тесты мето-
дов класса HotelService.java.
25
9. При выполнении команды mvn compile откомпилированые

классы приложения будут помещены в каталог /target.
10. Команда mvn package автоматически скомпилирует, запус-
тит тесты и создаст модуль business-logic-1.0.jar в каталоге
/target модуля бизнес-логики.
root@laptop:~/WORK/SE/LABs/Lab3/HotelProject/business-
logic# mvn package
[INFO] Scanning for projects...
[INFO] ------------------------------------------------
----------------
[INFO] Building Hotel business-logic application
[INFO] task-segment: [package]
[INFO] ------------------------------------------------
----------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered re-
sources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered re-
sources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/olga/WORK/SE/LABs/Lab3/HotelProject/business-
logic/target/surefire-reports
T E S T S
-------------------------------------------------------
Running se.lab03.services.HotelServiceTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time
elapsed: 0.065 sec
Running se.lab03.AppTest
elapsed: 0.01 sec
Running se.lab03.domain.HotelTest
elapsed: 0.032 sec
Results :
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] ------------------------------------------------
----------------
[INFO] BUILD SUCCESSFUL
26
[INFO] ------------------------------------------------
----------------
[INFO] Total time: 5 seconds
[INFO] Finished at: Sat Dec 12 16:10:49 EET 2009
[INFO] Final Memory: 8M/112M
[INFO] ------------------------------------------------
----------------
Команда mvn install установит модуль бизнес-логики в локальный
репозиторий maven, что позволит использовать его в других модулях
или проектах.
11. Перейдем к реализации веб-модуля приложения. Он пред-
ставляет собой jsp-страницу, на которой выводим перечень го-
родов, и если выбран город, то перечень гостиниц этого горо-
да.
<html>
<body>
<h2>SELab3-Hotel application</h2>
<%@ page import="
java.util.List,
se.lab03.domain.Hotel,
se.lab03.services.HotelService"
%>
<%
HotelService service = new HotelService();
String[] cityList = service.findAvailableCities();
String selectedCity = re-

quest.getParameter("city");
List<Hotel> hotelList = ser-
vice.findHotelsByCity(selectedCity);
%>
<h3>Choose a destination</h3>
<form action="index.jsp" method="get">
Please choose a city:
<SELECT name="city">
<OPTION value="">---No city---</OPTION>
<%
for(String cityName : cityList){
%>
<OPTION val-
ue="<%=cityName%>"><%=cityName%></OPTION>
<%
}
%>
</SELECT>
<BUTTON type="submit">GO</BUTTON>
</form>
<% if (hotelList.size() > 0) { %>
<h3>Available hotels in <%=selectedCity%> </h3>
27
<table border="1">
<tr>
<th>Name</th>
<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>
Т.е. указываем адрес веб-сервера, где необходимо развернуть веб-
приложение.
28
Данные для авторизации на указанном сервере необходимо про-

писать в файле /etc/maven2/settins.xml в разделе <servers>:
<server>
<id>mainId</id>
<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-кода.
2.3.2 MAVEN-ИЗАЦИЯ КУРСОВОГО ПРОЕКТА ПО ДИСЦИПЛИНЕ «МОДЕЛИРО-
ВАНИЕ»
1. Maven-зируем проект по моделированию (если проект в стадии

разработки еще не появился, берем на kid проект-пример
BuldoExample). Собираем и инсталируем в локальный репози-
торий используемую библиотеку Simulation.
2. Для своего проекта объявляем зависимость от артефакта
Simulation.
3. Для правильного формирования файла Manifest настраиваем
плагин jar (указываем главный исполняемый класс, и задаем
динамическое формирование переменной classpath)
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/
</classpathPrefix>
29
<mainClass>buldo0.Buldo0App
</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
Для автоматического копирования всех библиотек, от которых
зависит наш проект, из локального репозитория артефактов в заданный
каталог (в данном случае /lib) добавляем соответствующие настройки
плагина dependency:
<plugin>
<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

1. Изучить практические аспекты интеграции maven с системой
сборки ant.
2. Изучить практические аспекты интеграции maven с средой
разработки eclipse.
3. Выполнить запуск разработанных модульных тестов проекта с
использование среды разработки eclipse.

– содержимое файла глобальных настроек maven;
– содержимое файлов pom.xml для каждого модуля web-
приложения;
– исходные тексты тестов для классов бизнес-логики прило-
жения;
– результаты запуска тестов (находятся в каталоге
/targets/surefire-reports/);
30
– результаты запуска приложения на сервере;

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

1. Назначение систем сборки. Примеры подобных систем.
2. Особенности системы сборки maven.
3. Конфигурация файла сборки проекта с использованием maven.
4. Понятие архетипа проекта.
5. Понятие артефакта maven.
6. Управление зависимостями в maven. Транзитивные зависимо-
сти.
7. Понятие и назначение плагинов в maven. Их настройка.
8. Управление maven-репозиториями.
9. Назначение и принципы написания модульных тестов.
10. Создание модульных тестов с использованием библиотеки
JUnit 4.
31
Засоби модульного тестування (JUnit)
Научиться разрабатывать Unit-тесты с использованием инстру-
ментальной библиотеки JUnit. Разработать тесты для одного из стан-
дартных классов JDK.

Тестирование программного обеспечения — процесс выявления
ошибок в программном обеспечении. Выделяют следующие виды тес-
тирования согласно различным критериям классификации.
1. Степень изолированности компонентов:
модульное тестирование;
интеграционное тестирование;
системное тестирование.
2. Объект тестирования:
функциональное тестирование;
нагрузочное тестирование;
тестирование удобства использования интерфейса;
тестирование безопасности;
тестирование совместимости.
3. Знание системы:
тестирование «белого» ящика;

тестирование «черного» ящика.
4. Время проведения:
альфа-тестирование;
бета-тестирование;
приемочное тестирование;
регрессионное тестирование.
5. Степень автоматизации:
ручное тестирование;
автоматизированное;
полуавтоматизированное.
32
6. Выполнение кода:
статическое тестирование;
динамическое тестирование [1].
Конечной целью любого процесса тестирования является обеспе-

чение качества программного обеспечения. При этом ни один вид тес-
тирования не предоставляет 100% гарантии работоспособности прило-
жения.
Планирование тестовых сценариев должно быть выполнено та-
ким образом, чтобы проверялись всевозможные варианты использова-
ния приложения.
Модульное тестирование предполагает проверку работоспособ-
ности наименьших составляющих приложения: обычно это отдельный
класс и его методы. В случаях, если при выполнении методов тести-
руемого класса происходит вызов методов стороннего класса, необхо-
димо отделить тестируемые классы друг от друга, заменить их с помо-
щью mock-объектов, заглушек, имитаций. Например, если тестируется
метод класса, принимающий имя и пароль пользователя, а затем обра-
щающийся к базе данных для проверки правильности введенных поль-
зователем данных аутентификации (другой класс), то нужно заменить
класс, работающий с реальными данными «имитацией», которая не вы-
полняет обращения к базе данных, а хранит данные пользователей
внутри самого класса. Имитация должна быть достаточно проста, что-
бы не содержать ошибок – в противном случае говорить о модульном
тестировании нельзя.
JUnit [4] – популярный в настоящее время инструмент модульно-
го тестирования java-приложений. JUnit 4 основан на использовании
аннотаций.
К примеру, для тестирования правильности выполнения методов
класса Calculator, необходимо создать следующий тестовый класс
TestCalculator:
import org.junit.Test;
import static org.junit.Assert.*;
public class TestCalculator {
public Calculator calculator;
33
@Before
public void prepareTestData() {
calculator = new Calculator ();
...
@Before
public void setupMocks() { ... }
@After
public void cleanupTestData() { ... }
@BeforeClass
public static void setupDatabaseConnection() { ... }
@AfterClass
public static void teardownDatabaseConnection() { ... }
@Test
public void testAdd() {
assertEquals(4, calculator.add(1, 3) );
assertEquals(2, calculator.add( -3, 5 ) );
assertEquals(0, calculator.add(0, 0) );
assertEquals(-10, calculator.add(-4, -6) );
34
@Test
public void testDivide() {
…..
@Test(expected=ArithmeticException.class)
public void testDivisionByZero() {

calculator.divide(4, 0);
}
…
}
Рекомендуется (но необязательно) использование стандарта име-
нования тестового класса и его методов (префикс test).
Для обозначения тестового метода используется аннотация
@Test. Метод assertEquals проверяет равенство ожидаемого и получен-
ного значения. Другие подобные методы – assertTrue, assertFalse,
assertNull, assertNotNull, assertSame.
Аннотацией @Before обозначают методы, которые должны быть
запущены перед запуском каждого тестового метода, аннотацией
@After – после запуска каждого тестового метода соответственно. Если
в тестовом классе определено несколько методов с аннотацией
@Before, порядок запуска методов может быть произвольным.
Аннотациями @BeforeClass и @AfterClass обозначают методы,
которые должны быть выполнены до и соответственно после выполне-
ния всего набора тестов класса. Эти методы должны быть объявлены
как статические.
Планы тестов должны включать и «неправильные» варианты ис-
пользования системы, например, недопустимые входные параметры
метода. Тестирование того, что код корректно работает в исключитель-
ных ситуациях, также важно, как и тестирование функциональности
кода. Для тестирования корректности работы метода в исключительной
ситуации необходимо объявить ожидаемое исключение в аннотации
@Test.
Параметр timeout аннотации @Test позволяет указать временные
ограничения выполнения тестового метода:
35
@Test(timeout=5000)
public void testOperation() { ... }.
В некоторых случаях требуется отключение тестового метода

класса. Для этого используется аннотация @Ignore. В качестве пара-
метра желательно указать текст сообщения, которое будет выведено
при запуске тестовых методов класса.
@Ignore("Not running because <fill in a good reason here>")

@Test
public void testOperation(){ ... }.
Набор тестов можно определить следующим образом:
@RunWith(value=Suite.class)
@SuiteClasses(value={CalculatorTest.class, AnotherT-
est.class})
public class AllTests {
...
}
JUnit 4 вводит возможность определения набора различных клас-

сов для запуска тестов. Аннотация @RunWith определяет использова-
ние класса Suite для запуска тестов. В свою очередь, аннотация
@SuiteClasses используется классом Suite для определения тестов, ко-
торые входят в данный набор. При определении набора тестов допуска-
ется возможность использования методов, аннотированных с помощью
@BeforeClass и @AfterClass, которые будут вызываться перед началом
запуска всех тестов и после выполнения последнего теста из набора со-
ответственно. Таким образом, можно выполнить настройку необходи-
мых параметров сразу для целого набора тестов.
Класс Parameterized библиотеки JUnit 4 позволяет запускать одни
и те же тесты, но с разными наборами данных. Рассмотрим это на при-
мере. Ниже приведен пример теста для метода, который вычисляет
факториал заданного числа n:
@RunWith(value=Parameterized.class)
public class TestFactorial {
private long expected;

private int value;
36
@Parameters
public static Collection data() {
return Arrays.asList( new Object[][] {

{ 1, 0 }, // expected, value
{ 1, 1 },
{ 2, 2 },
{ 24, 4 },
{ 5040, 7 },
});
public TestFactorial(long expected, int value) {

this.expected = expected;
this.value = value;
@Test
public void factorial() {
Calculator calculator = new Calculator();
assertEquals(expected, calculator.factorial(value));
}
}
Класс Parameterized запускает все тесты класса FactorialTest (в

примере он только один), используя при этом данные методов, промар-
кированных аннотацией @Parameters. В данном случае имеем список с
пятью элементами. Каждый элемент содержит массив, который будет
использован в качестве аргументов конструктора класса FactorialTest.
Тест factorial() использует эти данные при вызове метода assertEquals().
Тест будет выполнен 5 раз с использованием следующих данных:
factorial#0: assertEquals(1,calculator.factorial(0));
37
factorial#4:assertEquals(5040,calculator.factorial(7));

Создать тестовый класс и тесты для проверки правильной работы
методов класса. Проверке подлежат не менее 5 методов класса на вы-
бор.
Классы для тестирования выбираются в соответствии с таблицей
1.1
Таблица 1.1 – Варианты заданий
Група КИ-171 Група КИ-172
№ Класс № Класс
1 java.util.ArrayList 1 java.lang.Enum
2 java.lang.Byte 2 java.util.HashMap
3 java.io.BufferedReader 3 java.util.Scanner
4 java.math.BigInteger 4 java.util.Vector
5 java.text.BreakIterator 5 java.lang.Long
6 java.util.Arrays 6 java.io.FileOutputStream
7 java.lang.Boolean 7 java.util.LinkedList
8 java.io.BufferedWriter 8 java.io.ObjectInputStream
9 java.text.DecimalFormat 9 java.io.ObjectOutputStream
10 java.util.BitSet 10 java.util.LinkedHashSet
11 java.lang.Character 11 java.util.HashTable
12 java.io.DataInputStream 12 java.util.jar.Manifest
13 java.math.BigDecimal 13 java.lang.reflect.Constructor
38
14 java.text.SimpleDateFormat 14 java.util.jar.Attributes
15 java.util.Calendar 15 java.io.FileInputStream
16 java.util.StringTokenizer 16 java.lang.reflect.Method
17 java.lang.Double 17 java.math.BigDecimal
18 java.io.DataOutputStream 18 java.io.File
19 java.io.File 19 java.text.BreakIterator
20 java.util.HashSet 20 java.io.StringReader
21 java.lang.StringBuffer 21 java.lang.Float
22 java.util.Collections 22 java.util.PriorityQueue
23 java.text.StringCharacterIterator 23 java.lang.Math
24 java.lang.String 24 java.io.DataOutputStream
25 java.lang.Math 25 java.io.StringReader
26 java.io.LineNumberReader 26 java.util.ArrayList
27 java.io.StringReader 27 java.util.Calendar
28 java.util.PriorityQueue 28 java.util.BitSet
29 java.util.Stack 29 java.util.Collections
30 java.lang.Integer 30 java.util.Stack
31 java.util.LinkedHashMap 31 java.lang.Double
32 java.lang.Float 32 java.io.BufferedWriter
33 java.lang.Short 33 java.util.Arrays
34 java.lang.reflect.Field 34 java.lang.Short
39
Група КІт-191
1 java.util.jar.Attributes 18 java.lang.String
2 java.util.Stack 19 java.lang.Short
3 java.util.PriorityQueue 20 java.lang.reflect.Field
4 java.util.LinkedHashMap 21 java.lang.Math
5 java.util.HashSet 22 java.lang.Integer
6 java.util.Collections 23 java.lang.reflect.Constructor
7 java.util.Calendar 24 java.lang.Double
8 java.util.BitSet 25 java.util.jar.Manifest
9 java.util.Arrays 26 java.lang.Byte
10 java.util.ArrayList 27 java.lang.Boolean
11 java.text.StringCharacterIterator 28 java.io.StringReader
12 java.text.SimpleDateFormat 29 java.io.LineNumberReader
13 java.text.DecimalFormat 30 java.io.File
14 java.text.BreakIterator 31 java.io.DataOutputStream
15 java.lang.reflect.Method 32 java.io.DataInputStream
16 java.math.BigDecimal 33 java.io.BufferedWriter
17 java.lang.StringBuffer 34 java.io.BufferedReader
40
Тестування продуктивності ПЗ (Apache Jmeter)
Изучение принципов нагрузочного тестирования. Практическое
применение кроссплатформенного инструмента Jmeter (Apache Jakarta
Project).

4.2.1 ПОНЯТИЕ И НАЗНАЧЕНИЕ НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ
Нагрузочное тестирование применяется для анализа работы ин-

формационных систем на различных уровнях нагрузки. Это автомати-
зированное тестирование, имитирующее работу определенного количе-
ства бизнес пользователей на каком либо общем (разделяемом ими) ре-
сурсе. Моделирование нагрузки происходит с помощью специальных
продуктов и техник.
Основным понятием нагрузочного тестирования является вирту-
альный пользователь. Управляя числом виртуальных пользователей,
тестировщик управляет нагрузкой на систему. Виртуальный пользова-
тель выполняет типичные операции в системе путем воспроизведения
трафика, который отправляется клиентским приложением на сервер.
Виртуальный пользователь исполняет скрипты, которые посылают на
сервер пакеты в формате действующего протокола, например, http,
odbc, NCA и др.
Основные показатели производительности информационной сис-
темы, которые измеряются в ходе нагрузочного тестирования:
– время отклика (время выполнения операции);
– число операций, выполняемых в единицу времени (TPS –
transactions per second).
Одним из терминов нагрузочного тестирования является "кривая
деградации" – график, показывающий зависимость производительности
системы (например, в единицах времени отклика) от рабочей нагрузки
(например, от числа виртуальных пользователей).
Основным результатом нагрузочного тестирования являются из-
мерения производительности информационной системы, которые могут
быть использованы для локализации узких мест и оптимизации произ-
водительности.
41
Нагрузочное тестирование тесно связано с тестированием объе-

мов, что подразумевает оценку способности системы обрабатывать
объемы данных по мере их накопления (рост базы данных сайта спустя
несколько месяцев, тем более лет, может оказаться значительным – а
сможет ли наш код работать с ней?). Например, текстовый
или графический редактор можно заставить прочесть очень большой
документ; а финансовый пакет – сгенерировать отчет на основе данных
за несколько лет.
Существует понятие тестирование масштабируемости, которое
также тесно связано с тестированием производительности; основная
его цель – оценка роста производительности приложения по мере до-
бавления ресурсов (память, процессор и т.д.)
Для каждой страницы (для каждого сервиса, который предостав-
ляет сайт) нужно определить нижнюю границу времени отклика. Необ-
ходимо учитывать распределение этих цифр по времени суток, нужно
рассчитывать распределение и по популярности сервисов.
В идеальном случае в качестве критериев успешности нагрузоч-
ного тестирования выступают требования к производительности систе-
мы, которые формулируются и документируются на стадии разработки
нефункциональных требований к системе до начала программирования
основных архитектурных решений. Однако часто бывает так, что такие
требования не были четко сформулированы или не были сформулиро-
ваны вовсе. В этом случае первое нагрузочное тестирование будет яв-
ляться пробным и основываться на разумных предположениях об ожи-
даемой нагрузке и потреблении аппаратной части ресурсов.
Одним из оптимальных подходов в использовании нагрузочно-
го тестирования для измерений производительности систе-
мы тестирование на стадии ранней разработки. Нагрузочное тестирова-
ние первых стадиях готовности архитектурного решения с целью опре-
делить состоятельность называется 'Proof-of-Concept' тестированием.

1. Развертывание тестируемого веб-приложения на веб-сервере
tomcat.
В качестве тестируемого веб-приложения в лабораторной работе
предлагается использовать курсовой проекта по дисциплине «ООП» за
прошлый семестр.
Для запуска тестируемого веб-приложения необходимо устано-
вить tomcat:
aptitude install tomcat6 tomcat6-admin tomcat6-docs
tomcat6-examples tomcat6-user
В файле /etc/tomcat6/tomcat-users.xml создаем роль для менеджера
и создаем пользователя, у которого та же роль:
42
<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.
Скачать пакет jakarta-jmeter-2.4.tar.gz можно с официального сай-
та http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi или с сер-
вера kid.stu. Распаковываем скачанный пакет и запускаем программу
при помощи скрипта из папки bin:
$ ~/jakarta-jmeter-2.4$ ./bin/jmeter.sh
Интерфейс Jmeter приведен на рисунке 4.2.
43
Рисунок 4.2 — Интерфейс программы Jmeter

3. Тестирование веб-приложения.
Для начала необходимо в тестовый план добавить элемент Thread
Group. В Thread Group указывается количество пользователей, которые
отправляют запросы на сервер, за какой период времени они отправля-
ют запросы и количество запросов, которые отправляет каждый поль-
зователь (рисунок 4.3). Для того чтобы добавить Thread Group необхо-
димо на Test Plan кликнуть правой кнопкой мыши и выбрать пункт Add
--> ThreadGroup.
Рисунок 4.3 — Thread Group со значениями по-умолчанию

В поле Number of threads указываем количество пользователей,
которое будет обращаться на сервер. В следующем поле указывает за-
44
держки между началом каждого потока. Например, если ввести Rump-

Up period 5 секунд, JMeter завершит запуск всех ваших пользователей к
концу 5 секунд. Так, если у нас есть 5 пользователей и 5 секунд период,
то задержка между началом нового потока будет 1 секунда (5 пользова-
телей / 5 секунд = 1 пользователь в секунду). Если установить значение
в 0, то JMeter сразу же запустит все потоки. Поле Loop Count указывает,
сколько раз будет повторяться тест.
После определения полей необходимо указать задания, которые
будут выполнять виртуальные пользователи. В Test Plan добавляем
HTTP requests со значениями по-умолчанию Add->ConfigElement-
>HTTPRequestDefaults(рисунок 4.4).
Рисунок 4.4 — HTTP Request Defaults

Далее добавляем HTTP Request (Add --> Sampler --> HTTP Re-
quest) и в поле HTTP Request Path пишем путь к странице, на которую
будет отправлен запрос типа get. В поле Server name указывать адрес
сервера нет необходимости из-за того, что мы в странице по умолча-
нию указали наш сервер (рисунок 4.5).
45
Рисунок 4.5 — HTTP Request главной страницы

Таким же способом добавляем второй HTTP Request, только в
поле Path указываем путь к другой странице.
Последним шагом, который необходимо сделать, чтобы на-
чать тестирование, является добавление слушателей (Listener), которые
будут обрабатывать всю информацию, полученную от HTTP Request.
Для этого добавим Graph Results (Add --> Listener --> Graph Results) и
View Results Tree (Add --> Listener --> View Results Tree) (рисунок 4.6 и
4.7).
После завершения тестирования в слушателях можно будет по-
смотреть результаты тестирования. На рисунке 4.8 приведен пример
теста, на котором видно, что система не справилась с нагрузкой, кото-
рую мы на неѐ отправили. Можно детально посмотреть содержимое
каждого пакета, а также пример html страницы, которую получили в
ответ на наш запрос. Если же ответ получили отрицательный, то мож-
но определить, по какой причине.
46
Рисунок 4.6 — Graph Results
Рисунок 4.7 — View Results Tree
47
Рисунок 4.8 — Результаты тестирования

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

1. Изучить возможности организации database testing (тестирова-
ние работы с БД) с использованием JMeter.
2. Освоить практические аспекты интеграции JMeter с JUnit.

– результаты тестирования в виде графиков;
– результаты тестирования в виде дерева;
– написать причины, по которым система не выдержала на-
грузки (ссылаясь на результаты тестирования).

1. Виды тестирования и соответствующие инструменты автома-
тизации.
2. Назначение и принцип организации нагрузочного тестирова-
ния. Инструменты нагрузочного тестирования.
3. Какие показатели выступают результатом нагрузочного тести-
рования.
4. Объясните термин «кривая деградации».
5. Планирование сценария нагрузочного тестирования в JMeter.
48
5 Лабораторная работа №5 (*)

Засоби безперервної інтеграції (Continuous
Integration Servers – Hudson (Jenkins)
Изучить функции инструментов непрерывной интеграции и нау-
читься применять их на практике. Получить навыки установки, на-
стройки и администрирования системы непрерывной интеграции
Husdon.
5.2 Краткие теоретические сведения

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

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

сборка проекта;
выполнение тестов;
развѐртывание готового проекта;
отправка отчетов.
Локальная сборка может осуществляться:
по внешнему запросу,
по расписанию,
по факту обновления репозитория и по другим критериям.
5.4 Сборка по расписанию

В случае сборки по расписанию, они, как правило, проводятся
каждой ночью в автоматическом режиме — ночные сборки (чтобы к
началу рабочего дня были готовы результаты тестирования). Для раз-
49
личения дополнительно вводится система нумерации сборок— обычно,

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

боты
Существует много инструментов непрерывной интеграции, на-
пример: Hudson, его форк Jenkins, CruiseControl, TeamCity, Bamboo. В
данной лабораторной работе будет рассматриваться Hudson (для Jenkins
настройка очень похожая), так как он простой в настройке, имеет мно-
жество плагинов, бесплатный и с отрытым исходным кодом.
Рассмотрим установку данного в ос Ubuntu подробно и самого
начала.
Для начала нам понадобиться apache-tomcat 5 или выше, openjdk-
6, и сам Hudson, в примере будет рассмотрено развѐртывание на .war
архива, на веб сервер tomcat, так как это способов есть универсальным,
можно также настроить ppa репозиторий для ubuntu, установить от туда
Hudson в виде .deb пакета и выполнить развѐртывание на apache2, но
данный способ не есть универсальным.
1. Установка ПО
sudo -s
//установим openjdk-6:
apt-get install openjdk-6-jdk
//устнаовим tomcat
wget http://apache.cp.if.ua/tomcat/tomcat-7/v7.0.21/bin/apache-tomcat-
7.0.21.zip
unzip apache-tomcat-7.0.21.zip
Установим Hudson
cd apache-tomcat-7.0.21/webapps/
50
wget http://java.net/projects/hudson/downloads/download/war/hudson-
2.1.1.war
mv hudson-2.1.1.war hudson.war
chmod -R 755 apache-tomcat-7.0.21/
apache-tomcat-7.0.21/bin/startup.sh
Теперь можем отрывть веб бразуер и перейти по адресу:
http://localhost:8080/hudson/ в случае если вы все выполнили правильно вы

увидите:
Рисунок 1 — Развертывание.
По умолчанию все проекты буду сохраняться в /root/.hudson/jobs
2. Базовая настройка
Настроим необходимые инструменты необходимые для сборки. В

отрытом окне веб-браузера выбираем: Manage Hudson → Configure
System:
1. Секция JDK: установить путь к JDK. (По умолчанию

установлено).
2. Секция ANT: Name — Ant1.8; Install automatically —
Ставим галочку; Install from Apache — 1.8.2 (или
выше);
После чего сохраняем сделанные изменения кнопкой «Save» и

выходим из настроек на основную страницу.
51
В качестве примера рассмотрим рассмотрим работу Hudson с svn

резпозиторием на sourceforge.net (с git и github почти аналогично). Для
начала нам потребуется централизованое хранищи на sourceforge.net,
поэтому зарегистрируемся там и создадим svn репозиторий, вы должны
получить:
Рисунок 2 — Пустой репозиторий.
Репозироий пустой, поэтому создадим HelloWorld проект на Java,

и создадим ant-скрипт его сборки.
build.xml имеет вид:
<project name="HelloWirld" default="all">

<target name="clean">
<delete dir="build"/>
</target>
<target name="compile">
<mkdir dir="build/classes"/>
<javac srcdir="src" destdir="build/classes"/>
</target>
<target name="jar" depends="clean,compile">

<mkdir dir="build/jar"/>
<jar destfile="build/jar/HelloWorld.jar" basedir="build/classes">
<manifest>
<attribute name="Main-Class" value="oata.HelloWorld"/>
</manifest>
</jar>
</target>
<target name="run">
<java jar="build/jar/HelloWorld.jar" fork="true"/>
</target>
</project>
52
Устновим subversion:
apt-get install subversion
После чего выполним инициализацию svn-репозитория и выпол-
ним коммит.
Рисунок 2 — Проект sourceforge.net.
Теперь в Hudson создадим проект который будет автоматически

собираться.
Для этого выберем New Job:
53
Рисунок 3 — Создание проект CI
В поле Job name: пишем «HelloWorldOnHudson», тип сборки

«Build a free-style software project» и нажимаем «ОК». После чего попа-
даем в меню основных настроек проекта, проведем настройку в секци-
ях:
1. Source Code Management:
Subversion
Repository URL (Путь к репозиторию):
svn://svn.code.sf.net/p/ololololololol/code/trunk
2. Build Triggers:
- Poll SCM: ***** - это означает что Hudson булет

проверять хранилище на наличие новых версий
(ревизий); ***** - означает каждую минуту; 5 * *
* * - каждые 5 минут, каждого часа.
3. Build: Add build step → Invoke ant
- Ant Version: 1.8 (выбираем то имя которое мы

указали в пункте базовой настройки (1.5.2).
54
 Target : jar (Цель ant-скрипта);
Основные настройки закончены, сохраняем изменения. Видим,

что наш проект добавлен.
Рисунок 4 — Проект в Hudson

Теперь можем сделать ручную сборку. Также сервер будет вы-
полнять автоматическую сборку при появлении новой ревизии.
Журнал сборки:
Updating svn://svn.code.sf.net/p/testforlabse/code-0/trunk revision: Sep 29, 2011 4:22:29 PM depth:infinity

ignoreExternals: false
At revision 2
no change for svn://svn.code.sf.net/p/testforlabse/code-0/trunk since the previous build
[workspace] $ /root/.hudson/tools/Ant1.8/bin/ant jar
Buildfile: /root/.hudson/jobs/HelloWorldOnHudson/workspace/build.xml
clean:
[delete] Deleting directory /root/.hudson/jobs/HelloWorldOnHudson/workspace/build
compile:
[mkdir] Created dir: /root/.hudson/jobs/HelloWorldOnHudson/workspace/build/classes
[javac] /root/.hudson/jobs/HelloWorldOnHudson/workspace/build.xml:8: warning: 'includeantruntime' was

not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 1 source file to /root/.hudson/jobs/HelloWorldOnHudson/workspace/build/classes
55
jar:
[mkdir] Created dir: /root/.hudson/jobs/HelloWorldOnHudson/workspace/build/jar
[jar] Building jar: /root/.hudson/jobs/HelloWorldOnHudson/workspace/build/jar/HelloWorld.jar
BUILD SUCCESSFUL
Total time: 1 second
[DEBUG] Skipping watched dependency update; build not configured with trigger: HelloWorldOnHudson
#5
Finished: SUCCESS
Все результаты работы хранятся в директории cd

/root/.hudson/jobs/
Рисунок 5 — Рабочая директория

Для того что бы убедиться что сервер автоматически делает
сборки, достаточно сделать комит в svn (или др.) и подождать 1-2 ми-
нуты, и вы уведите новую сборку.
56
Рекомендованная литература
1. Бек К. Экстремальное программирование: разработка через тес-
тирование. Библиотека программиста. – СПб.: Питер, 2003. – 224
с.: ил.
2. Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разра-
ботки программного обеспечения: Учебное пособие. – М.: ИД
«ФОРУМ»: ИНФРА-М, 2008. – 400 с.: ил.
3. Котляров В.П., Коликова Т.В. Основы тестирования программно-
го обеспечения: Учебное пособие. – М.: Интернет-Университет
Информационных Технологий; БИНОМ. Лаборатория знаний,
2006. – 285 с.: ил. (Серия «Основы информационных техноло-
гий»).
4. Макгрегор Дж., Сайкс Д. Тестирование объектно-
ориентированного программного обеспечения. Практическое по-
собие: Пер. с англ. – К.: ООО «ТИД «ДС», 2002. – 432 с.
5. Управление проектами разработки ПО. Учебно-методическое по-
собие по дисциплине «Гибкие технологии разработки программ-
ного обеспечения» / Сост. Шопырин Д.Г. – Санкт-Петербург,
Санкт-Петербургский государственный университет информаци-
онных технологий, механики и оптики, 2007. – 131 с.
6. Фаулер М. Архитектура корпоративных программных приложе-
ний: Пер. с англ. – М.: Издательский дом «Вильямс», 2006. – 544
с.: ил.
7. Vincent Massol, Ted Husted. JUnit In Action. Manning. – Special
Sales Department, 2004. – P. 386.
8. Git – The Fast Version Control System [Электронный ресурс]. –
Режим доступа: URL: http://git-scm.com. – Название с экрана.
9. JMeter – Apache JMeter [Электронный ресурс]. – Режим доступа:
URL: http://jakarta.apache.org/jmeter. – Название с экрана.
10.JUnit.org Resources for Test Driven Development [Электронный ре-
сурс]. – Режим доступа: URL http://www.junit.org. – Название с
экрана.
11.Redmine – Overview [Электронный ресурс]. – Режим доступа:
URL: http://www.redmine.org. – Название с экрана.
12.Redprojects – инструменты, помогающие работать [Электронный
ресурс]. – Режим доступа: URL: http://www.redmine.net.ua. – На-
звание с экрана.
13.Welcome to Apache Maven [Электронный ресурс]. – Режим досту-
па: URL http://maven.apache.org. – Название с экрана.
57
58

Інженерія програмного забезпечення 2020

Загружено:

Сведения о документе

Авторское право

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Інженерія програмного забезпечення 2020

Загружено:

Авторское право:

Вступ

Курс «Инженерия программного обеспечения» посвящен изучению ос-

Обов‘язковими до виконання є лабораторні роботи № 1, 2, 3, 4 (для

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

Лабораторная работа №0 (*)

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

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

– устанавливаем модуль Passenger Apache:

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

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

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

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

Git работает с четырьмя сетевыми протоколами для передачи

Установка Git для ОС Fedora: $ yum install git-core, для

Для создания хранилища репозиториев на сервере в каталоге /opt/git,

1.8.3 НАСТРОЙКА ДОСТУПА К GIT-СЕРВЕРУ С ИСПОЛЬЗОВАНИЕМ GITOSIS

Gitosis — набор скриптов для управления файлом authorized_keys

$ git clone git://eagain.net/gitosis.git

Создадим группу mobile, наследуя всех участников группы mo-

При неоходимости предоставить анонимный доступ на чтение к

После перезапуска сервера Apache, появится возможность клони-

Для подключения репозитория проекта заходим в настройки про-

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

1. Установить и настроить git / Або створити репозиторій про-

Для отримання оцінки вище 75 (С) балів

Для отримання оцінки вище 90 (А) балів

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

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

– процесс настройки шаблонов коммитов для связи с задача-

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

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

Плагины maven (plugins) реализуют последовательность действий

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

1. Установить пакет maven2

Выберите архетип под номером 18 (18: internal -> maven-

Рисунок 3.1 — Структура многомодульного проекта

соответствующий плагин, но для выполнения данной лабораторной ра-

лении maven-координат проекта. Значение элемента packaging для ро-

public class Hotel {

public void setCity(String city) {

public class HotelService {

private static String[] cities =

new Hotel("Ukraine","pr. Mira, 18","Chernigov",2),

new Hotel("Bryansk","Shevchenko str.,

public class HotelTest {

9. При выполнении команды mvn compile откомпилированые

Tests run: 8, Failures: 0, Errors: 0, Skipped: 0

String selectedCity = re-

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

1. Maven-зируем проект по моделированию (если проект в стадии

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

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

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

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

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

тестирование «белого» ящика;

Конечной целью любого процесса тестирования является обеспе-

import static org.junit.Assert.*;

public class TestCalculator {

public Calculator calculator;

public void prepareTestData() {

calculator = new Calculator ();

public void setupMocks() { ... }

public void cleanupTestData() { ... }

public static void setupDatabaseConnection() { ... }

public static void teardownDatabaseConnection() { ... }

public void testAdd() {