Автоматична система безперервного тестування веб-додатків



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

Ключові слова--автоматична система безперервного тестування, CI, Jenkins, автоматизація, підхід, методика.

Вступ

Основною проблемою наявних підходів та методик тестування є їх вузько направленість. Завдяки цьому тестування складних багаторівневих систем ділиться на частини та проводиться окремо. Таке рішення видається раціональним, бо надає можливість швидко перевіряти необхідну область об'єкта та значно пришвидшує перший цикл тестування частинами, під кожну з яких можна швидко знайти спеціалістів та залучити їх на короткий термін для базового покриття тестами необхідної області. Але такий підхід не є оптимальним, оскільки він слабо орієнтований на цілісний результат що призводить до складності аналізу загальної якості продукту. Реалізація наявних методів та підходів дозволяє знизити більшість ризиків, проте приводять до вибору між малоефективним використанням часу чи коштів.

Аналіз проблеми

З класичної моделі тестування (рис.1) нас цікавлять основні 3 рівні тестування – системне, інтеграційне і модульне. Для зручності будемо розглядати їх на прикладі веб-додатків.

Рис.1 Класична модель тестування [1]

Системне тестування покривається Unit-тестами. Воно проводиться у самому коді програмного забезпечення та аналізується, як правило, розробниками за допомогою консольного журналу (логу). Цей вид тестування спрямований на базову перевірку функціоналу. Якщо об'єкт не проходить Unit-тести, проводиться відновлення програмного забезпечення до останньої стабільної версії та аналізуються проблеми. Цей вид тестування здебільшого вже автоматизований і покращувати його великого сенсу не має.

Інтеграційне тестування веб-застосунків проводиться через API (прикладний програмний інтерфейс) – набір визначень підпрограм, протоколів взаємодії та засобів для створення програмного забезпечення. Простими словами це можна назвати «вікном спілкування» між серверною (бекендом) та клієнтською (фронтендом) частинами веб-додатка. У більшості випадків тестується людиною повністю або розбивається на компоненти. Тестування проводиться за допомогою спеціальних інструментів, таких як Postman, SoupUI та т.п. і аналізується за допомогою логу та згенерованих звітів про тести, які аналізуються бізнес-аналітиками та менеджерами проекту.

Системному тестуванню відповідає UI тестування (тестування інтерфейсу користувача) що може проводитися як вручну так і за допомогою автотестів, написаних будь-якою мовою програмування, що підтримує Selenium WebDriver. Selenium WebDriver – це драйвер, що дозволяє коду взаємодіяти з клієнтською частиною додатку. У результаті автоматизації прикладного інтерфейсу (API) генерується лог та документ, який відправляється на аналіз. Створити повністю автоматичну систему неможливо, оскільки будь-який продукт постійно оновлюється і потрібна людина, яка буде корегувати тести на нижчому рівні. Результатом ручного тестування є документ з тест-кейсами, які буди перевірені у ході тестування, та звіти, у яких описується, що, як і коли тестувалося.

Також слід зазначити, що зараз для автоматизації тестування використовуються системи контролю версій та неперервного інтегрування. Прикладом цього є використання Git для синхронізації моделей тестування чи використання системи безперервної інтеграції Jenkins [2] для автозапуску тестування. Але ключовою проблемою є їх точкове використання і відсутність єдиного підходу.

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

Рис. 2 Загальна схема тестування веб-додатків

Після аналізу проблеми стає очевидно що Unit тести та ручне тестування інтерфейсів UI є задовільними оскільки Unit тести вже ефективно працюють на рівні розробки а мануальне UI тестування на виході видає добре оформлений результат. Залишається оптимізувати блок тестування API та автоматизоване UI тестування (на рис.1 виділені пунктиром), основною вадою яких є нестандартизований результат, який призводить до збільшення витрат часу на його обробку. Для кожного з напрямків є багато чудових інструментів, але це призводить до непов'язаної між собою документації, яка не може дати чіткого розуміння статусу продукту.

Запропонований підхід

Результатом аналізу проблеми є необхідність створення системи, яка змогла б об’єднати тестування API та автоматизоване тестування UI і стандартизувати їх вихідний результат. На основі цих вимог та аналізу наявних технологій була створена наступна теоретична модель системи (рис. 3).

Рис. 3 Теоретична модель системи

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

Каркасом запропонованої моделі є Jenkins, що це автономним сервером автоматизації з відкритим кодом. З його допомогою можна брати актуальні версії кожного модуля з Git та запускати їх відповідно до налаштованих параметрів.

На роль основного інструменту тестування API найкраще підходить Postman. Postman дозволяє створювати та використовувати запити, документувати й контролювати сервіси в одному місці.

Для коректної взаємодії Postman та Jenkins необхідно додатково встановити Newman. Для тестування UI підходить будь-яка мова програмування що підтримує Selenium WebDriver.

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

Застосування

Запропонована система тестування не може повністю замінити ручне тестування, проте чудово підходить для проведення регресів [3]. Регресійне тестування – це тип тестування, який проводиться, щоб перевірити, чи зміна коду в програмному забезпеченні не впливає на наявні функціональні можливості продукту. Це робиться для того, щоб переконатися, що продукт працює нормально з новим функціоналом, виправленнями помилок або будь-якими змінами в існуючій функції. Також плюсом є те, що замовник і кожен член команди у будь-який час може побачити статус тестування.

Висновки

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

Література

{1} Mauro Pezze and Michal Young, Software Testing. Techniques, Principles, and Practices / John Wiley\&Sons – 2008. – p. 16.

{2} https://www.jenkins.io/doc/ (дата звернення 14.11.2021).

{3} https://uk.myservername.com/what\-is\-regression\-testing (дата звернення 14.11.2021).

Dec 2, 2021