Comments 8
А как выполнена интеграция с Jira?
Идентификатор Issue становится тэгом?
Идентификатор Issue становится тэгом?
Feature.
Да, для интеграции тег соответствует Jira Issue ID. Кроме того, Robot Framework надо запускать в ключиком, чтобы из лога можно было напрямую перейти в Jira.
Допустим у Вашего проекта в Jira префикс RF, то есть баг у Вас с идентификатором RF-123456. Тогда Вы привязываете к тесту тэг RF-123456, а в строке запуска робота пишете
tagstatlink RF-*:https://ваш-хост-с-jira/browse/RF-%1:Open_in_Jira
и все тэги, начинающиеся с RF- получат ссылки в Jira (из моего любимого лога).
Допустим у Вашего проекта в Jira префикс RF, то есть баг у Вас с идентификатором RF-123456. Тогда Вы привязываете к тесту тэг RF-123456, а в строке запуска робота пишете
tagstatlink RF-*:https://ваш-хост-с-jira/browse/RF-%1:Open_in_Jira
и все тэги, начинающиеся с RF- получат ссылки в Jira (из моего любимого лога).
А какие инструменты вы используете при работе?
Мы попробовали робот чуть меньше года назад и ушли на pytest с чистой совестью. Интеграция с PyCharm через энное место и стабильно крашится, дебажить неудобно.
При написании тестов удобно пользоваться и PyCharm, и Atom с соответствующими плагинами. Некоторые не гнушаются даже стандартным Блокнотом. Дебаг в общепринятом смысле тут недоступен — да. Но как мы уже писали в статье, у робота прекрасный лог и его вполне достаточно для тех нужд, для которых обычно используется дебаг.
Наша команда сравнивала pytest и робот параллельно, дабы постепенно перейти с цирка на баш+c#+python+java. И вот как раз по поводу лога, всех сильно удивило, что робот не умеет показывать строку, где тест упал. Ну то есть можно подключить стектрейс руками, но очень странно, что это issue на гитхабе до сих пор висит открытым.
Для расчета покрытия я написал утилиту, которая берет из Swagger список API бэкенда и сопоставляет его с тем, что было протестировано.
Интересно было бы почитать про это. Просто сравнение по вызываемым эндпойнтам или какие-то тонкости?
Если вкратце, то в автотестах есть метод, который логирует каждый вызов API — URL, параметры и теги, с которыми был запущен тест, совершивший этот вызов. После выполнения тестов вручную (или силами CI) запускается утилита для анализа лога.
Утилите указываются все теги, для которых рассчитывается покрытие (например, smoke), а она выбирает из файла записи, соответствующие указанным тэгам.
Затем она идёт по нужному адресу в Swagger и вытягивает оттуда информацию об «энд-поинтах», методах, и параметрах — ну и сопоставляет эти данные, выводя статистику относительно всех эндпоинтов и методов.
В файле лога большинство вызовов содержат какие-то идентификаторы и на самом деле их сложно сопоставить с тем, что лежит в Swagger. Поэтому в утилиту заложена хитрая логика, которая умеет выделять идентификаторы из URL и делать на их основе пометки, впоследствии используемые при сопоставлении.
Помимо развёрнутой информации (что покрыто, что не покрыто, что покрыто частично — когда использованы не все параметры) она генерит ещё и svg-плашку, которая выводится в описании проекта gitlab.
Утилите указываются все теги, для которых рассчитывается покрытие (например, smoke), а она выбирает из файла записи, соответствующие указанным тэгам.
Затем она идёт по нужному адресу в Swagger и вытягивает оттуда информацию об «энд-поинтах», методах, и параметрах — ну и сопоставляет эти данные, выводя статистику относительно всех эндпоинтов и методов.
В файле лога большинство вызовов содержат какие-то идентификаторы и на самом деле их сложно сопоставить с тем, что лежит в Swagger. Поэтому в утилиту заложена хитрая логика, которая умеет выделять идентификаторы из URL и делать на их основе пометки, впоследствии используемые при сопоставлении.
Помимо развёрнутой информации (что покрыто, что не покрыто, что покрыто частично — когда использованы не все параметры) она генерит ещё и svg-плашку, которая выводится в описании проекта gitlab.
UFO just landed and posted this here
Sign up to leave a comment.
Почему для нового проекта я взял Robot Framework