“Katalon Studio - это довольно простой и понятный инструмент для автоматизации тестирования, и вам не нужно обладать большими знаниями программирования, чтобы писать автоматизированные тестовые кейсы.” – читаю я в первой статье результата поиска в Яндекс и нахожу каждое слово соответствующим действительности. Чтобы пользоваться этим довольно простым инструментом все же нужно обладать начальными знаниями программирования, желательно на Java или его упрощенном варианте - Groovy.
Полтора года назад я пришел в проект на должность инженера по автоматизации тестирования, где готовилась к выходу веб-версия приложения по работе с тарифами и расчету начислений. Еще до моего появления в проекте был выбран инструмент «Katalon Studio» (KS) для автоматизации тестирования будущего веб-приложения. Так что я не принимал участия в процедуре выбора инструмента автоматизации. Но знал, что часть Java-библиотек из инструмента, использовавшегося для тестирования десктопного приложения без труда были перенесены в KS.
Имея небольшой опыт разработки тестов на Selenium в связке Maven/JBehave/TestObjects, я с удовольствием принялся изучать новый инструмент на просторах интернета и даже научился понимать английский язык, на котором говорят индусы.
В статье я хотел бы немного поделиться впечатлениями и опытом автоматизации тестирования веб-приложения с помощью Katalon Studio. Этот еще довольно редко используемый в тестировочном процессе инструмент, однако быстро развивается и уже занимает верхние места в специализированных рейтингах (2020 Gartner Peer Insights Customers’ Choice for Software Test Automation).
Еще раз, что это?
Katalon Studio - это фреймворк для автоматизации тестирования API, веб-приложений, мобильных и настольных приложений с довольно богатым набором функций и может запускаться на платформах Windows, macOS и Linux.
Основные особенности инструмента:
язык программирования: Groovy (с поддержкой Java)
стиль программирования тестов: вызов методов классов (кивордов)
поддерживает BDD Cucumber для Behavior Driven Testing (в стиле When-And-Then)
использует движки Selenium и Appium
поддерживает SOAP и RESTful для тестирования API и сервисов
около 200 встроенных кивордов
возможности тестирования могут быть расширены с помощью создания пользовательских кивордов, плагинов из Katalon Store, импорта сторонних библиотек из файлов jar.
подробный просмотр отчетов в Katalon TestOps
Откуда он взялся?
Компания-вендор Katalon LLC зарегистрирована в США, разработка ведется преимущественно во Вьетнаме.
Сайт компании. Первая версия Katalon Studio появилась в 2015 году. Отдельно существует браузерное расширение Katalon Recorder для Chrome и Firefox для быстрой “полуручной” автоматизации.
Сколько стоит?
Free License или Enterprise license ($759 в год на одну машину или $1529 в год мульти-лицензия). Имеются помесячные варианты оплаты и пробный период 30 дней.
Загрузка KS становится доступной после процедуры регистрации на сайте разработчика. Необходимо указать свой личный e-mail (напр. gmail) для получения Katalon Studio Free License. Начиная с версии 7.0.0 компания-разработчик изменила (можно сказать ужесточила) лицензионное соглашение. Появился платный продукт KSE (Katalon Studio Enterpise). Бесплатный KS согласно новому соглашению можно теперь использовать только в одиночном порядке. Т.е. в проекте каждый тестировщик может использовать KS в целях автоматизации тестирования, но только под своей персональной Free License. Для командной работы и использования юридическим лицом требуется платная лицензия. В этом случае нужно регистрироваться как юридическое лицо.
Установка
После регистрации готовый к употреблению продукт скачивается одним архивом. Установка в операционную систему не требуется. Можно скачать официально и предыдущие версии KS. При необходимости их можно запускать одновременно. Но нужно быть осторожным и делать это с запасной веткой кода, так как поздние версии могут «оптимизировать код под себя». В настоящий момент можно загрузить версию KS 7.7.2. Прошлые версии официально доступны на GitHub.
Документация
Документация по KS довольно неплохо изложена на английском языке на официальном сайте. Там же есть несколько видео-уроков. В конце каждого раздела имеется место для дискуссий и вопросов.
Продолжение моей истории
На изучение нового инструмента мне было выделено достаточно времени (примерно месяц), чтобы его установить, настроить и потренироваться делать простые тесты. Вообщем через пару недель занятий на версии KS 6.2.0 (которая до сих пор в работе и про которую здесь в основном речь) я уже умел собирать веб-элементы и записывать простые смоук-тесты с помощью встроенных методов, не прибегая, ну или почти не прибегая к программированию. Это такие тесты, где нужно покликать на все, что должно кликаться на странице, позаполнять инпуты, почекать чекбоксы, повыбирать значения в листбоксах, проверить наличие текста на странице или в элементе и пр. Т.е. фактически процентов 80 автоматизированного теста можно сделать встроенными методами. Это одно из больших преимуществ KS – легкость вхождения в автоматизацию тестирования.
Про безопасность и сохранение кода
Можно одновременно запускать несколько экземпляров приложения. Инструмент работает довольно стабильно, без внезапных падений. Зависания бывают крайне редко. Имеется автосохранение, однако не во всех местах интерфейса(!), поэтому лучше выработать привычку сохранять изменения до выхода из текущего окна. Механизм взаимодействия с GIT вшит (в сокращенном варианте) в панель инструментов. Не скажу, что он очень дружелюбен. К нему нужно приспособиться. В трудных случаях помогает git-консоль.
При работе с кодом можно просмотреть историю изменений, сравнить с предыдущими ревизиями (встроен построчный diff-функционал), подправить или откатить изменения до какой-либо сохраненной локальной или серверной версии, восстановить код из внешнего файла.
Во время коммитов можно также просмотреть/подправить изменения, частично отказаться от коммита «в этот раз» (отменить индексацию) или откатить изменения до актуальной ревизии на GIT-сервере.
Собираем элементы на веб-странице
Собрать элементы – означает записать веб-элементы, которые будут тестироваться, в хранилище объектов (Object Repository).
//в Groovy всё является объектами. Наверное, поэтому и веб-элементы в KS называются тоже объектами.
KS по умолчанию записывает веб-элементы по набору атрибутов, если этого недостаточно, то может по ХPath или по CSS. Если HTML-код страницы хорошо структурирован, элементы имеют уникальный ID, то достаточно просто щелкнуть на объект во время записи и больше не беспокоиться о его параметрах. В случае проблемного кода в дальнейшем объекты могут не находиться по записанным параметрам и их придется настроить и проверить вручную (обычно по XPath).
Также во время записи объекту можно дать более понятное название, отредактировать его атрибуты и проверить его обнаруживаемость на странице. За один раз можно записать объекты с разных страниц. Сборщик объектов сам разложит их по страницам, на которых они были найдены. Сбор объектов можно продолжить с какой-то уже загруженной страницы.
Рекордер работает довольно продуктивно. Иногда кажется, что он делает слишком длинные XPath-ы. Но работают они потом (особенно на статических тестовых данных) весьма успешно. Сейчас я создаю объекты вручную обычно только для групп элементов, а также объекты, в которые передаются дополнительные параметры динамически и пр. сложных случаев.
Например, объект с динамическим параметром, к названию которого прибавляю (), чтобы отличать его в дереве хранилища объектов:
или, например, виртуальный объект, который включает все элементы определенного класса для групповых операций с ними, который я маркирую словом list:
li_navigation_item_list ( Selected Locator XPath: //*[@class = 'nav-item'] )Собираем элементы на странице + записываем простой тест
Второй режим сборщика объектов/рекордера предусматривает одновременную запись простого теста. Лично я пользовался этим режимом только во время изучения работы KS. Этот режим подходит для быстрой записи простых тестов, в которых не много тестовых шагов. Все также, как и при сборе объектов + в конце сохраняем тестовый кейс. При записи длинных тестов он начинает работать нестабильно и может сбросить запись.
Тест-кейсы
Записанные вручную или автоматически тестовые кейсы древовидно располагаются в меню в алфавитном порядке и этот порядок изменить нельзя. Сохраненный кейс можно просматривать и редактировать в двух режимах: ручном (Manual) и скриптовом (Script). Мануальный режим больше подходит для быстрого просмотра содержимого тест-кейса. Скриптовый – для уже привыкших к кодированию тестировщиков. Здесь есть одно существенное неудобство. Ручной режим имеет автоматическую нумерацию тестовых шагов, которую никак нельзя посмотреть в скриптовом. В последнем имеется нумерация строк кода, которую никак нельзя посмотреть в ручном режиме. Выход – в комментариях. Комментарии в коде в одинарных кавычках видны также и в ручном режиме в столбце Description. Кроме этого есть еще встроенный метод WebUI.comment(), текст которого высвечивается почему-то в столбце Input.
Режим Manual:
Режим Script:
Наборы и коллекции тест-кейсов
Тестовые кейсы собираются в тест-сьюты (наборы).
Наборы тестов можно запускать вручную или можно написать батник с целью автозапуска. Для этого в KS есть кнопка на тулбаре "Build CMD". А затем этот батник запускать по расписанию с помощью Планировщика заданий Windows или CI-сервера.
Тестовые наборы собираются в тест-коллекции. Они, как и наборы могут запускаться вручную или автоматически.
Киворды
С усложнением тест-кейсов возникает потребность больше разбираться в программном коде и создавать новые методы. Например, для подсчета элементов на странице или проверки их сортировки пока не предусмотрено встроенных кивордов. В KS методы пользовательских классов с целью их упрощенного вызова в коде нужно пометить метой "@Keyword ". Пользовательские классы с кивордами доступны в меню в ветке Keywords. В этой папке можно создать вначале пакеты. Например, helper и checker. В первом будут находиться классы и методы для помощи в тестах, а во втором – чисто проверяльщики, сверщики и пр.
Суперклассом пользовательских классов является класс CustomKeywords. Вызов киворда в любом тест-кейсе выглядит примерно так:
CustomKeywords.'checker.CollectionChecker.checkElementsAreSorted'(tObj)Метод класса можно вызвать также и традиционным способом через декларацию импорта библиотеки и объявления экземпляра класса:
import eets.checker.CollectionChecker as CollectionChecker
...
CollectionChecker collectionChecker = new CollectionChecker()
collectionChecker.checkElementsAreSorted'(tObj)
Разница в объеме кода заметна. Тем не менее традиционный способ тоже используется. Киворды (одной инструкцией) можно вызывать только в тест-кейсах.
При создании киворда в случае необходимости вызвать в нем другой киворд (метод) из другого класса можно использовать только традиционный способ.
Встроенные киворды находятся почти все в классе WebUiBuiltInKeywords. Они вызываются в тест-кейсах и различных классах традиционным способом, но без объявления экземпляра класса.
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
...
WebUI.delay(5)
/в Groovy точка с запятой не ставятся в конце инструкций. Если вы скопировали Java-код, то после его сохранения точки с запятыми пропадают. В настройках можно указать их оставлять, хотя это без гарантии/
Запуск тестов и логирование
При запуске теста можно выбрать браузер, а также при необходимости выбрать желаемые именно для данного теста предустановки браузера (Custom Desired Capabilities), которые, однако нужно заранее прописать в настройках. Для браузеров Chrome и Firefox есть возможность запускать тесты без видимого окна браузера (headless). Также можно запускать браузер на удаленной машине, на которой запущен сервер веб-драйвера. Таким образом, можно параллельно открыть еще один экземпляр KS и продолжать заниматься разработкой тестов.
Логи теста можно посмотреть в двух режимах: Log Viewer и Console. В большинстве случаев причина ошибки сразу понятна, если конечно не переусердствовать при явной обработке ошибок. Труднее приходится, когда в тест-кейсе вызывается, например, другой тест-кейс, в котором вызывается метод с обработчиком ошибки. Вообщем, чем проще написаны методы – тем легче находить ошибки. Из просмотрщика логов можно сразу перейти к соответствующей строке скрипта.
Для управления тестами предусмотрена возможность программировать события до и после тест-кейсов, наборов и коллекций (ветка "Test Listeners "). Первая ветка в меню "Profiles" содержит параметры настройки тестового окружения и глобальные переменные для всего проекта (default) и для каждого тестового окружения в отдельности.
Вывод логов при запуске наборов и коллекций можно настроить в отдельные файлы и папки. Как опция имеется возможность создания скриншота при падении теста, а также записи видео всего тест-кейса.
Отладка
Режим отладки имеет стандартные функции для детального анализа причины ошибки. У него такое же меню, как и для обычного запуска теста. Вызывается он кнопкой с жучком. Также нужно переключить оконный интерфейс на режим Debug. Перед запуском нужно расставить в коде тест-кейса точки останова программы. Автотест доходит до первой точки и ждет дальнейших действий. Значение всех переменных (пользовательских и системных) и параметров всех вызванных методов и их внутренних методов на момент останова можно быстро посмотреть. Не скажу, что сильно удобно пользоваться, однако учитывая редкость использования, то вполне нормальный функционал. Длинных и сложных тестов у нас немного, и я стараюсь разбивать их на отдельные менее сложные.
Тестовые данные и переменные
В тест-кейсах предусмотрена возможность подключить таблицы Excel (с указанием листов), CSV-файлы, результаты SQL-запросов к базам данных. Можно также создавать собственные таблицы внутри KS (Internal Data). В ветке меню Data Files для всех источников данных создаются табличные представления с учетом или без учета заголовков. Их содержание можно просматривать (внутренние таблицы можно редактировать). Поддерживаемые СУБД: MySQL, MS SQL Server, Oracle, PostgreSQL. Для каждой имеется пример строки подключения. На счет работы с Oracle могу сказать, что не все SQL-конструкции поддерживаются. Хранимые процедуры и функции PL/SQL можно запускать и создавать новые. В настройках проекта можно также настроить отправку/проверку тестовых e-mail, если это требуется в тесте.
В тест-кейсе на вкладке Variables можно создавать переменные разных типов, подключить ячейки из табличных источников (Test Data Value) или же подключить всю таблицу как переменную (Test Data). Глобальные переменные можно здесь «переподключить» со сменой названия для короткого и быстрого вызова в коде, или же можно запрашивать их в коде напрямую. Все переменные, указанные на этой вкладке, автоматически подключаются до начала теста. Это основная причина для размещения переменных здесь. При копировании тест-кейсов все переменные также копируются. Если этого не требуется, то тестовые данные можно получать напрямую из подключенных источников и вообще не пользоваться этой вкладкой.
Также можно объявлять переменные прямо в коде тест-кейса. Но это уже другая тема о разделении кода и тестовых данных. И этой темы нужно придерживаться, чтобы не было потом тяжело вносить изменения в тесты. На мой взгляд, лучше всего записывать тестовые данные в Excel-файл. Его можно использовать и для мануального тестирования и для подключения к тестировочному фреймворку. Следует помнить, что если в коде нам нужна числовая переменная, то нужно сделать явное преобразование. В примере ниже объявляется переменная, тип которой станет известен после ее инициализации. Для этого запрашиваем значение из ячейки (4;71) присоединенной таблицы Excel, которое приходит как текст и требует преобразования:
def widthSShBreit = ((TD_DE_TESTDATA.getValue(4, 71)) as Integer)Очень полезная вкладка Variables (Script mode). Это xml-вариант вкладки Variables. Он подходит для быстрого копирования переменных и прочих действий с ними. Нужно только помнить, что каждая переменная имеет уникальный id в системе. Поэтому если скопипастить переменные в другой тест-кейс, то нужно поменять хотя бы один символ в id каждой переменной на новом или старом месте.
Контрольные точки тестовых данных
Некоторые тестовые данные могут по разным причинам меняться и служить причиной падения тестов. Для контроля за такими данными предусмотрен функционал Checkpoints. Создание контрольных пунктов происходит также, как и при подключении источников данных. При этом для каждой ячейки предусмотрен чек-бокс, поставленная галочка в котором будет означать контроль значения этой ячейки при запуске тестов, в которых оно запрашивается.
Отчеты
На ветке Reports можно посмотреть результаты запуска наборов и коллекций тестов с логами, скриншотами и видео. Кроме этого имеется соответствующая папка в файловой системе с информацией о результатах прогона тестов, которую можно использовать для интеграции с другими инструментами тестировочного процесса. К сожалению, в настоящее время, отдельная ветка с отчетами в меню, а также соответствующая информация в файлах доступны только в Enterprise версии. Начиная с версии 6.3.0 отчеты можно смотреть на страницах тест-наборов и коллекций. Кроме этого отчеты можно также посмотреть в Katalon Analytics (см. ниже), после предварительной загрузки данных туда.
TestOps
Для интеграции с системами тест-менеджмента и CI имеется встроенный механизм сопряжения, реализованный в виде плагинов для Enterprise-версии.
Имеется также собственный аналитический центр Katalon Analytics с довольно большим функционалом по ссылке.
Отчеты в нем доступны также и для бесплатной версии KS. Он может быть настроен как самостоятельный CI-сервер. Однако для этого потребуется приобрести платный инструмент Katalon Runtime Engine.
Какая интеграция используется в нашем проекте и какая перспектива?
В настоящее время в качестве системы проект-менеджмента у нас используется популярный немецкий инструмент Polarion.
Результаты запуска тестов с помощью самостоятельно настроенного механизма передаются туда и стандартно отображаются на панели отчетов.
Есть еще пара графических диаграмм, но в целом отчетность скромная, и нужно много чего доделывать руками. Хотя Polarion активно развивается в последнее время, руководство нашего проекта приняло решение о переходе на Jira в связке с Jenkins. Katalon Studio имеет встроенный механизм сопряжения с обоими этими инструментами. В связи с этим планируется покупка Enterprise-лицензий KS по мере необходимости. Katalon Analytics мы не используем по причине закрытости проекта.
Резюме
После года работы с инструментом автоматизации уже можно сказать хорошие или плохие (бывает и никакие:) слова. В целом впечатление очень неплохое. Хотя ощущение недоделанности инструмента или странноватой логики его работы по началу присутствовало. Думаю, что в первую очередь им должны заинтересоваться проекты, в которых автоматизация тестирования только начинается. Мануальные тестировщики с базовыми знаниями ООП и SQL быстро освоят этот инструмент. Очень приятно, что помимо встроенных методов, готовых плагинов можно создавать свои методы и правила работы. Это позволяет решать практически любые задачи, выработать оптимальный стиль работы и обеспечить преемственность автоматизации.
Конечно, лицензионная политика производителя ПО налагает ограничение на популяризацию инструмента. Однако, если разобраться, то в настоящее время KS могут использовать не только хорошо финансируемые проекты, но и экономные проекты (с версией KS ниже 7.0.0). Я бы рекомендовал начинать с версии 6.2.2 для того, чтобы присмотреться к инструменту, и не нарушая лицензии, внедрить его в проект.
Разработчикам KS хочется выразить большую благодарность за удобства в работе с инструментом. Проект активно развивается, но есть еще много чего улучшить и добавить в функционале. Не стоит забывать, что тестирование мобильных приложений и веб-сервисов, недавно еще и Windows-приложений также включено в пакет. А это значит, что через несколько лет, Katalon Studio может стать стандартом автоматизации, если, конечно, лицензионная политика вендора будет обдуманной и понятной пользователям и потенциальным покупателям этого заслуживающего уважения инструмента автоматизации.