Як Allure Framework допомагає мені аналізувати проходження автотестів

Тестувальнику-автоматизатору замало налаштувати тести. Не менш важливо вміти їх аналізувати. І тут стане в нагоді Allure Framework. У цій статті я розповім, чому це дійсно хороший інструмент для аналізу проходження автотестів, та на прикладах поясню особливості його використання.

Що таке Allure Framework

Це досить гнучкий інструмент для створення звітів. Він надає багато інформації про проходження тестів, чим спрощує аналіз їхніх результатів.

Allure Framework має кілька переваг:

• Детальні сценарії виконання тестів. Це дозволяє створювати тести, які відповідають особливостям проєкту.
• Агрегація тестів на основі тегів. Такий функціонал спрощує роботу з аналітикою та пошук потрібної інформації.
• Широкі можливості інтеграції. Allure Framework можна об’єднувати з тестовими фреймворками та використовувати з різними мовами програмування.
• Автоматичне розподілення дефектів тестів та продукту. Це дає змогу зменшити життєвий цикл багів.
• Варіативність налаштувань. Надає багато засобів для налаштування під власні вподобання.
• Безкоштовний фреймворк. Це, мабуть, один із найголовніших плюсів на фоні багатьох платних фреймворків та інших інструментів за підпискою.

Allure універсальний — він підтримує роботу з Jasmine, JUnit, Spock, TestNG та іншими фреймворками, перелік яких постійно поповнюється. Але в межах статті я обмежусь прикладами з JUnit 4 як одного з найпопулярніших.

У чому користь використання Allure

Робота з фреймворком починається фактично після формування звіту. Після його підготовки ви матимете зрозумілий HTML-документ, яким за необхідності можна поділитися з колегами. Цей файл надає чітку загальну картину того, які функції вже охоплено, скільки тестів впало.

При цьому ви можете дослідити інші деталі: історію виконання тестів, їх розподілення по категоріям, інформацію про оточення, використані інструменти тощо.

В Allure доступний широкий вибір графіків. Наприклад, можна завантажити статус проходження тесту, щоб дізнатись відсоток вдало виконаних тестів та співвідношення фейлів або дефектів коду. Або інший приклад — розподіляти тести за категоріями, скажімо, на дефекти продукту та дефекти тесту. Щодо останнього, прописувати щось додатково не потрібно — Allure все зробить сам.

Також можете візуалізувати дані про час проходження кожного тесту. Це допоможе зрозуміти, який з них виявився найшвидшим, а який — найдовшим, і далі міркувати, в чому проблема.

Як запустити Allure Framework

Для початку підключаємо потрібні залежності та налаштовуємо плагін:

Наступний крок — робимо прогон тестів, після якого в папці target з’явиться папка allure-results. В ній будуть розміщуватися створені файли з результатами тестів. А далі для отримання звіту достатньо застосовувати команди allure:report:

Звіт можна зробити більш простим та зрозумілим або «‎апгрейдити» на свій смак. Для цього використовуйте анотації:

• Step — для виділення окремих методів, як кроків. Це має бути атомарна дія або перевірка.
• Attachment — доповнює основну анотацію і надає додаткову інформацію. Якщо метод щось повертає, ви отримаєте, наприклад, скрін або текст, який повертається. Тож не треба власноруч перевіряти код чи розбиратися, де й що лежить на сайті. Все відобразиться у звіті.
• DisplayName та Description — допомагають робити тести більш унікальними. Погодьтесь, не зручно, коли у тестів схожі назви кожного методу. За допомогою анотації DisplayName можна надати кожному тесту зручне і зрозуміле ім’я. А Description дозволить коротко описати тест: що ви очікуєте в результаті, які дані вводяться тощо.
• Story та Feature — розділяють тести за функціоналом або юзер сторі.

Як налаштувати Allure

Для підключення фреймворку використовуються відповідні залежності.

У цьому прикладі мені також знадобився окремо налаштований плагін, аби не доводилося завантажувати додаткові файли. Це можна зробити в Maven.

На цьому кроці у мене сталась цікава помилка. Maven не бачив Allure, який я завантажувала в проєкт. Замість нього збирач завантажував інший, вказаний за дефолтом. Так могло бути через неправильно додані залежності. Але в мене ситуація інакша, тому я й знайшла доволі оригінальне рішення.

Завдяки цьому плагін бачить потрібну версію та джерело його завантаження. Як можете побачити на ілюстрації нижче, в структурі проєкту немає Allure. Але після запуску allure:report він сам його завантажить і сформує звіт:

Переходимо до анотацій. DisplayName, яка розміщена перед класом, буде вказувати на назву окремого с’юту. Це допоможе швидше сформулювати клас або згрупувати класи по одному с’юту. Анотація Feature сформує його за окремим функціоналом:

Також є анотація DisplayName для окремого тестового методу, завдяки якій усі тести матимуть унікальну назву. Це доповнює опис того, що ми хочемо або не хочемо бачити, та групування за User Story.

Існують й інші анотації в методах, які щось перевіряють або повертають. Наприклад, я використала Step та Attachment. Перша анотація потрібна для відокремлення кроків, які виконують тест, та фіксації цього у звіті. Друга — застосовується там, де я щось повертаю. У наведеному прикладі повертається текст у звіті:

Після такої підготовки можна запустити процес.

Однак хочу акцентувати увагу на іншому. Тут є папка allure-results, де знаходяться результати проходження тестів та окремі файли, в які ми повернули необхідні дані.

Одразу після проходження тестів можна не помітити папки з Allure. Тому треба завантажити його за допомогою команди allure:report.

Спочатку Maven намагається знайти Allure, але після невдалої спроби переходить до завантаження.

У результаті з’являється папка з необхідною саме нам версію фреймворку.

Далі — переходимо в папку site, в якій знаходиться потрібний файл:

Формуємо звіт в Allure Report

Відкриваємо файл і бачимо загальну інформацію: про наявність трьох тест-кейсів; про те, що вони пройшли добре, що є розділення за с’ютом.

Також тут можна дізнатися про наявність степів. Наприклад, якщо в нашому тесті був один Step, то він один і буде відображатися. Бачимо й Attachment, який ми отримали в цьому тесті.

Також є графіки, які демонструють, що все пройшло добре. Критичність тестів нормальна:

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

Один тест тривав три секунди.

Те ж саме можна побачити на вкладці Timeline. Тести запускалися послідовно, тому це оформлено як пряма лінія. Але якби був паралельний запуск, вигляд графіку був би інакший. Як бачите, перший тест тривав найдовше.

А два інших пройшли швидше.

У розділі Behaviors є розділення за Feature та User Story. Я вказувала окремо одну сторі на два тести й іншу сторі на третій — щоби наочно показати, як фреймворк їх розділяє. Але якби я вказувала інший клас з тією ж Feature Annotation, тут був би ще один клас, але з іншою User Story.

Зверніть увагу: в блоці Trend — пусто. Це логічно на даному етапі. Сам по собі Trend показує графік виконання тестів, їх історію. Тож для заповнення блоку та формування тренду потрібно пройти декілька кроків. Для автоматизації цього процесу я розробила невеликий скрипт, про який розповім трохи згодом.

Загальна ж ідея проста: в target формується папка site, яка відкриває звіти. А в ній розташовується папка history, яка і буде основою для Trend.

Для того, щоб сформувати тренд не пустим, потрібно перезібрати звіт. Він формується на основі allure-results. Як можна побачити на ілюстрації, тут немає жодної history, тому й Trend порожній.

Тож треба просто перенести сюди потрібну папку.

Вона буде зберігатися, а ми зможемо сформувати звіт заново.

І отримаємо заповнений Trend.

Як Allure працює з помилками в тестах

Але давайте чесно: наш звіт нецікавий! Все зелене, нічого не зламалося, інформації мало. Треба щось зламати. При цьому для демонстрації розподілення по категоріях я би створила одразу дві проблеми. Наприклад, один тест буде шукати текст, якого немає на сторінці:

Інший тест спробує звернутися до неправильного локатору:

Як я зазначала вище, можете автоматизувати створення трендів. Для цього я написала скрипт. Коли тести пройдуть і з’явиться повідомлення про проблеми, цей скрипт автоматично перенесе папку history у потрібне місце.

Тепер при виявленні помилок у звіті вже набагато більше цікавіше:

У загальній інформації повідомляється про три тест-кейси і три різні результати. Один тест впав, один — пройшов нормально, останній — зламаний.

Багато змін у вкладці Trend. Тут показано розділення з кількістю запусків та графіком падіння тестів.

Розділення за с’ютами також сигналізує про негаразди. Тут говориться про зламаний тест — той, який не зміг знайти потрібний елемент.

Є також тест, який впав, бо не знайшов відповідного тексту.

Більше інформації тепер наявна і в графіках:

Бачимо розподілення за категоріями. Як видно далі, в одному тесті був дефект продукту, в іншому — дефект самого тесту.

Також є тренд з часом проходження усіх тестів, а не кожного окремо. З цього можна зробити висновок: перший запуск тривав трохи більше 6 секунд, а другий — майже 6 секунд.

Критичність є нормальною, бо не було вказано додаткової інформації.

У таймлайні зазначено, що один запуск відбувся 5 хвилин тому, а інший — тільки-но. Тож тепер можна дізнаватися, коли саме щось пішло не так.

Щоб порівняння було максимально повним, можна полагодити всі ті проблеми і заново запустити тести. Тепер у звіті все пройшло добре. При цьому на графіках видно, що в одному запуску все зламалося, але в останньому — знов все в нормі.

Також можна звернутися до історії окремих тестів, де показані всі зміни: нормальне проходження тестів, виявлення проблеми і знову все ОК.

Аналогічні дані є й про перезапуски та їх результати.

Така ж картинка й в іншому блоці: проходження, падіння, знову проходження. Бачимо ще й рівень успішності тестів: 3 з 4. І це все лише частина можливостей Allure. Ви можете гнучко налаштовувати інструмент під себе та додавати ще більше анотацій, аби отримувати потрібну вам інформацію.

Як інтегрувати Allure з Jenkins

Після інтеграції цих інструментів в меню Jenkins з’явиться кнопка Allure Report. Вона викликає саме той звіт, який показаний вище.

Allure реалізований як плагін: достатньо знайти його, завантажити та встановити:

Далі в конфігураціях Jenkins налаштуйте Commandline. За бажанням можете вказати, звідки має завантажуватися Commandline. Хоча й так все має працювати коректно.

Після цього в проєкті в Post Build Actions треба налаштувати і зібрати Allure Report.

Тоді побачите Trend та кнопку Allure Report для відкриття звіту.

І врешті решт — результати тестів можна отримувати безпосередньо в Jenkins.

Коли відкриєте звіт, там буде зібрана вся потрібна вам інформація:

При роботі з Allure Framework уважно стежте за відповідністю версій. У мене з цим було чимало проблем. Якщо якась версія плагіну не поєднується з Allure, нічого не працюватиме. Тож при виникненні проблем спробуйте передусім оновити чи відкотити назад версію плагіну.

У разі будь-яких питань стосовно роботи Allure Framework раджу звертатися до двох основних джерел:

• Офіційна документація
• Репозиторій на Github. Тут ви можете поспілкуватися з розробниками фреймворку або читати, як інші користувачі вирішували ті чи інші проблеми. Впевнена, з Allure Framework ви завжди знайдете оптимальне рішення.