SpiderTest: використовуй силу CI



Ця стаття є продовженням SpiderTest: Автотесты своїми руками. Проте, перша частина огляду на це додаток була більше орієнтована на десктопний інтерфейс. У цій же хотілося б поговорити про екзотику: зв'язку тестів з CI-server'ом і GitHub.
Може виникнути питання: «Навіщо взагалі все це потрібно? Ми написали тест, прогнали його в потрібних браузерах і нам достатньо» і в цілому він досить обґрунтований! Дійсно, для звичайного тестування, запуску автотестів з самого додатка SpiderTest в більшості випадків буває достатньо. Але що робити, якщо ми хочемо запустити тести в IE9-11, Opera, FireFox і Google Chrome різних версій? На одній машині це зробити неможливо, а створювати купу віртуальних машин і запускати по черзі в кожній утомливо (і взагалі це костиль).
А якщо ми хочемо провести димове тестування? Чи хочемо запускати тести не тільки в різних браузерах, але і в різних операційних системах (Windows OS, Linux OS)?
Найоптимальніший відповідь на поставлені вище питання – використовувати сервер безперервної інтеграції. У цій статті я розгляну налаштування SpiderTest і Jenkins. Справедливості заради варто сказати, що запускати тести можна і на bamboo, і на teamcity, але Jenkins простий і безкоштовний, тому розглянемо його.

Конфігурування Jenkins для Windows OSи Linux OS.

Перш ніж починати роботу потрібно встановити дистрибутив Jenkins завантажити Apache Maven Project, JDK 7 і Git і прописати їх в системних змінних.
Тепер можна приступати до налаштування Jenkins. І перше, з чого почнемо – встановимо потрібні плагіни.



Для цього потрібно перейти в «Налаштувати Jenkins» (1), а потім в «Керування плагінами» (2).
• GitHub plugin – плагін для роботи з GitHub
• JUnit Plugin – плагін для запуску модульних тестів
• Allure Jenkins Plugin – яндексовскій плагін для створення звітів.
Після установки потрібно перезавантажити сервер, це можна зробити, ввівши localhost:8080/restart, в адресному рядку.
Потім переходимо в «Конфігурування системи» (3). У вікні, заповнюємо блоки «Git», «Jenkins Location» і «Allure Plugin».
Слід вказати два «Git installations» для WindowsOS і LinuxOS, краще зробити як на скріншоті.



Так само не зайвим буде прописати «Jenkins Location» щоб була можливість заходити в Jenkins ззовні.



І, нарешті, заповнити «Allure Plugin»



Після конфігурування потрібно ще раз перезавантажити сервер.

Система контролю версій Git

Щоб тестування було зовсім серйозним, як в суворих програмістів, не зайвим для команди тестувальників використовувати систему контролю версій. Не мені пояснювати, що «система контролю версій забирає часу зовсім небагато, зате користі від нього цілісний вагон» © Коров'єв «Майстер і Маргарита».
Загалом створюємо профіль на гітхабі і закидаємо туди наступні файли з тих, що лежать в папці SpiderTest:
• Config – папка в якій вказані налаштування зберігаються списки кроків і елементів
• Data – папка з шаблонами класів, методів maven-проекту
• Lib – папка з бібліотекою SpiderTestCILib.jar
• Add-lib.bat – виконуваний файл, який додає бібліотеки в локальний репозиторій maven
• Add-lib.sh – те ж саме, але для LinuxOS.
• SpiderTestCI.jar – Jar-ник, який створює maven-проект.
• Start-test.bat – виконуваний файл, який запускає SpiderTestCI.jar.
• Start-test.sh — те ж саме, але для LinuxOS.
• TestKit – папка з автотестами.

Ось про SpiderTestCI.jar хотілося б сказати пару слів окремо, але трохи пізніше.

Створення плану складання тестів

Після того як Jenkins CI конфігурований, можна приступати до створення плану складання.



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



Git executable виберемо «за замовчуванням» Windows. І почнемо додавати кроки складання.





Першим кроком у створенні складання плану буде додавання бібліотеки в локальний репозиторій maven, виконавши add-lib.bat (або add-lib.sh у LinuxOS).

Другим кроком буде створення maven-проекту складання і запуск тестів. Для цього потрібно виконати start-test.bat [arg] (або start-test.sh [arg]), де [arg] – це шлях до файла, або шлях до папки з тестами.



І, нарешті, додати послесборочный крок Allure Jenkins Plugin із зазначенням версії звіту.



Тепер залишилося лише виконати збирання, натиснувши «Зібрати зараз».



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



Спонсором красивого звіту став Яндексовскій плагін Allure Plugin більш докладно про нього написано тут



Алгоритм роботи SpiderTestCI.jar

Виконуючи start-test.bat, SpiderTestCI.jar перевіряє що йому передали в якості аргументу: файл або папку з файлами. Якщо передали теку, то він шукає в ній файли з розширенням .sff (в папці повинні бути тільки файли тесту в розширенні .sff інакше джарник буде лаятися). Отже, SpiderTestCI.jar зчитує файл тесту, знаходить часто використовувані кроки і елементи і підтягує їх з config\namespaces\, потім з файлу config\config.cfg зчитує шлях до браузерів (у разі якщо вони вказані), після цього дивиться змінні (якщо вони вказані), потім зчитує шаблони maven-проекту з папки data і, нарешті, на виході отримуємо maven-проект з вже готовими до запуску тестами, який складається з трьох об'єктів:
• environment.xml
• pom.xml
• директорія src

Налаштування складальника на LinuxOS

Тепер налаштуємо ще одного збирача-раба щоб запускати тести на LinuxOS.
Перш ніж починати конфігурувати ще одного збирача, необхідно зробити деякі налаштування на линуксовой машині. А саме:
• JDK7 – щоб Jar-ники сприймати.
• Git – щоб Linux умів брати исходники з гитхаба.
sudo apt-get install git
Незайвим буде перевірити, що git прописався в системних змінних для цього потрібно в командному рядку ввести git. З'явилося багато тексту? Чудово)
• SSH-клієнт, щоб Jenkins зміг підключитися до свого збирачу по протоколу ssh.
sudo apt-get install openssh-client
sudo apt-get install openssh-server
• slave.jar – jar-ник, який запускається дженкінсом на машині «раба»
Його можна скачати, ввівши localhost:8080/jnlpJars/slave.jar
Потім скинути його в папку, наприклад \home\user\slave і дати всі права на папку типу
chmod –R 777
І ось тільки тепер можна в Jenkins налаштовувати новий вузол.



Ввести налаштування доступу по ssh. Слід упевнитися, що до виртуалке можна підключитися ззовні, наприклад, з допомогою Putty. До речі, варто давати адекватне ім'я збирачеві, щоб при перемиканні з одного на інший правильно ідентифікувати.



Потім включити підлеглий вузол до майстра. Включатися новий складальник перший раз буде так само довго, як і «майстер». Справа все в тих же бібліотеках maven.



Щоб запустити збірку на LinuxOS потрібно зробити наступні дії:
1. У налаштуваннях плану складання вибрати виконавця (машина на якій розгорнуто Jenkins – master, а назви всіх збирачів задаємо самостійно).



2. Переключитися між збирачами в блоці «Управління вихідним кодом».



3. Виправити в плані складання команди так, щоб були задіяні лінуксові виконувані файли:



І знову запустити збірку. Не зайвим буде згадати, що на віртуальних машинах повинні бути встановлені всі браузери, які використовуємо в тестах і драйвера цих браузерів прописані в системних змінних.
Ця стаття завершує огляд інструменту SpiderTest, але це не означає, що він зупиниться у своєму розвитку. Потрібно більше людей, які будуть використовувати SpiderTest, щоб просунути додаток на новий рівень. Підписуйтесь на нові версії, коментуйте, пропонуйте.

P. S. З випуску попередньої статті вже вийшло 3 версії SpiderTest. Остання версія 1.1.1 вже доступна для скачування. Наступний реліз не за горами і в ньому будуть доповнення, які ви додаєте в коментарі.
P. P. S практика показала, що потрібно дуже усвідомлено використовувати списки кроків і елементів. Вони зберігаються в спеціальну папку «config/namespaces» і якщо ви видаляєте/переносите або змінюєте файли з папки namespaces, то тести, що використовують їх, не будуть виконуватися. Так що прохання бути уважніше.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.