Сегодня я буду рассказывать про то, как использовать Allure TestOps для повседневных задач. На самом деле, мне кажется, что будет интересно. Я, по крайней мере, слушаю свои выступления.
Ну, в смысле, когда я их рассказываю, мне заходят. Надеюсь, зайдет и вам. Давайте я пока потихонечку расскажу план, то, что будет происходить.
Да, вопросы можно туда задавать. Я уже тоже об этом написал. Можно и здесь писать, я буду их периодически читать.
Сегодня мы будем экспериментировать прямо на живом стенде Allure. У нас есть стенд GazingBug. Я буду немножечко на другом стенде жить.
В качестве CI-системы мы будем использовать сегодня GitLab. Но тут есть нюанс. GitLab немножко подтупливает, уже 40 человек, это очень хорошо. GitLab немножко подтупливает.
И поэтому я буду показывать, как настроить все в GitLab, но основные все операции делать в Jenkins, просто потому что он реально быстрее. При этом вам не надо запариваться по поводу Jenkins, вы можете прямо на сервере, который у вас будет, все делать по аналогии. Просто пока вы будете настраивать у себя, например, что-то там запускать, у вас это будет как раз долгое время, и это нормально, потому что вы послушаете меня, отличаетесь и так далее. А чтобы мне быстро рассказывать и чтобы вы не уснули, я буду использовать Jenkins.
Ну и, на самом деле, так или иначе, Jenkins до сих пор довольно популярный CI. И поэтому я думаю, что конкретно даже в записи он обязательно пригодится и будет использоваться всеми. Во время демо я отключу свой видеопоказ. То есть я буду... Вот эта картинка, она пропадет.
Сейчас вы можете убедиться, что это действительно я, если кто-то сомневается, мало ли. Доклад у меня, точнее, демка будет разбита на шесть частей. В первой части я расскажу как раз, как настраивать вся интеграцию первичную.
Во второй части я расскажу, как добавлять больше всякой мета-информации в ваши тест-кейсы. Это тоже довольно интересная и важная задачка. В третьей части мы запускаем тесты из Allure. В третьей части мы поговорим про ручное тестирование и автоматизацию, как это работает вместе.
В четвертой части запускаем тесты изолюра. В пятой части поговорим про дефекты. И в шестой части про дашборды.
Идея примерно всего этого воркшопа заключается в том, чтобы показать, насколько просто может быть управление автоматизацией тестирования одинаково как... как для автоматизаторов, так и для ручных тестировщиков. То есть, грубо говоря, если вы занимаетесь ручным тестированием и вообще не понимаете, что у вас там автоматизируется, и для вас это какая-то вообще непонятная реальность, то для вас ждет большой сюрприз. На самом деле все это может быть очень просто и вам подконтрольно. Если же вы автоматизатор на проекте, у которого наоборот, который говорит о том, что у нас все автоматизировано и так далее.
Для вас тоже будет много полезной информации, но тут вот есть один нюанс. Периодически, когда я делаю такие вот демки на большую аудиторию, то возникают ситуации, в которых такие очень хардкорные автоматизаторы говорят, типа, да какое ручное тестирование, его нет и так далее. Или там ручные тестировщики говорят, типа, у нас там мало автоматизации. В этом конкретно воркшопе не надо как-то предвзято относиться к той или другой роли, просто наслаждайтесь тем, что я буду показывать, и все будет отлично.
У нас уже подходит время. Да, да, да, сейчас пишут вопрос, в демо будет генерация тест-кейсов из автотестов и обратно. Да, ровно на этом и построена система Allure TestOps. Я думаю, что мы начинаем уже. Я буду после каждого из шести вот этих блоков, после каждого пишите вопросики.
Я буду, насколько у меня будет хватать сил, на них отвечать. Если там вопросов будет слишком много, то мы, наверное, их сразу же будем переносить куда-то на конец. Если вопросов будет не так много, то буду постараться сразу же в реалтайме на них отвечать.
Нас уже 46 человек. Я думаю, 50 человек мы добьем, и это отлично, очень-очень хорошо. Я начинаю шарить свой экран. А, кстати, да, я тут экспериментировал с тем, как я выгляжу в фотобуф.
В общем, довольно забавно. Я могу вас повеселить, например, вот таким вот. Привет, как дела? Хорошо.
Можно что-нибудь сделать. Вот такое. Ребята, очень рад вас видеть.
Прям обнимашки со всеми. Теперь все видно, да? Все, поехали. Окей, я возьму, открою Demo Project. Это у меня прямо чистый, пустой проект.
Тут вообще никакой информации нет. И давайте настроим первую штуку. Первое, что надо сделать.
У меня есть вот такой вот репозиторий. Я скидываю его в чатик. Вы можете у него нажать fork. Тут появится кнопочка.
авторизуюсь тут, потому что мне это понадобится. Так, менеджер паролей. Вот, у вас появится кнопочка «Форк».
Вы можете ее прям нажать, эту кнопочку, и у вас пока будет, собственно, пока вы будете форкать, все как бы нужно произойдет, и вы будете работать со своим репозиторием. Вы здесь нажимаете «Форк». Дальше нам надо сделать так, чтобы у нас результаты наших автотестов, вот у нас написаны автотесты. Причем неважно, кем они написаны, они написаны каким-то автоматизатором.
И сейчас это вообще неважно. Вот они у нас написаны, я говорю, и к ним я буду возвращаться довольно редко. Первое, что я делаю, я захожу в настройки. После того, как вы форкнули, я захожу в настройки CICD. Здесь нам надо проставить вот такие переменные.
Я сделаю побольше. Первая переменная, мы нажимаем кнопочку Add Variable. И сюда вписываем ее значение.
Сейчас я скину, какие переменные мы добавляем. Allure endpoint это ссылка на Gazing Bug. Можете продублировать сюда URL стенд? Это первая переменная.
Project idea это когда вы создали у себя проект в Allure. У меня создан проект, и вот у меня в URL отображается проект №50. Это в моем случае 50, в вашем случае это не 50, это тот проект, который у вас есть.
И третье, это Allure Token. Да, отлично. И третье, это Allure Token.
При этом, когда мы эти перемены создаем, давайте я их отредактирую, мы обязательно убираем вот эти вот флаги. Вот этот флаг не должен быть добавлен. Ну и смотрите, как это выглядит. Allure Endpoint и я указываю конкретное значение.
Allure Project ID, и у меня здесь 50. Вы помните, что вот этого делать не надо. Тут надо эти флаги убрать. И токен, я его не буду показывать, просто там будет находиться токен.
Как мы получаем токен? Мы заходим в свой профиль, нажимаем профайл. У меня тут много токенов. Мы создаем новый токен, называем его GitLab, например. GitLab.
Токен. Давайте GitLab Workshop. Вот. У нас создается токен.
Он вот таким вот образом распечатывается. Нажимаем кнопочку копирования и вот тут вот редактируем вот эту вот штуку. Ну, именно редактируем. Я тут редактирую Project ID, а вы добавляете вот здесь вот variable token, вот так вот, Allure token и добавляете вот эту вот штуку.
И вот эту вот тему отчелкиваете. Потом нажимаем save. Я не буду нажимать кнопку save, потому что у меня уже все здесь настроено. Я этот токен сейчас потру, чтобы это было secure, и мы возвращаемся в наш проект.
После того, как мы сделали эти операции, мы переходим в pipelines. И просто сразу же нажимаем run pipeline. Делаем run pipeline. У нас запустилась джоба, и она скоро отобразится здесь.
Но я проведу такие же манипуляции с gazing bug. Давайте так. У меня есть для GUnit 5 джоба. Здесь у меня такие же настройки, но немножечко другие.
Смотрите, давайте на них посмотрим. Первое. Я выбираю, где у нас сервер находится.
Это как раз то же самое, где у нас находится сервер. Здесь я выбираю Demo Project. Здесь я выбираю способ формирования Launch Name.
Это мы сейчас увидим. И у нас есть теги. У нас есть регулярная джоба, и вот она так будет запускаться. Это как у нас конфигурируется Jenkins. Нажимаем «Saved», «Build with parameters», и у меня также сконфигурированы еще джобы с кукумбером.
Я ее буду просто как дополнительную пускать, и пусть она запустится. Когда мы переведем на эту страничку, мы увидим следующую информацию. Здесь у нас появится информация о том, что у нас джобы запускаются в активном режиме. Часто с кейсов пока нету, просто запускаются джобы. Так, GUnit 5 у нас пришел без результатов тестов.
Мы сейчас это починим и разберемся почему. Давайте пока я ее дропну и давайте посмотрим, почему у нас результаты тестов для GUnit 5 не загрузились. Идем сюда, смотрим.
Потому что я убил случайно вот этот build step. Gradle clean test. Запускаем наши тесты.
Окей. И build with параметр. И запускаем еще раз.
У нас кукумбер тесты уже прошли. У нас... Я про это и говорю, что видите, как GitLab Job, она долго, очень долго идет. То есть если посмотреть на pipeline, он до сих пор у нас, скорее всего, освобождает агенты. Вот он проделал...
какую-то свою работу, ну и, соответственно, он сейчас выполняется. И вот вы видите в реалтайме результаты тестов. Это одна из первых фичей, которая есть в Allure. Суть в том, что вы получаете результаты тестов не в конце выполнения вашей джоба, а вы получаете их в реальном времени. На самом деле это экономит огромное количество времени.
То есть если у вас что-то пошло не так, то вы увидите об этом сразу. У вас тесты идут 30 минут. И вы не будете дожидаться окончания джоба и сразу же увидите, грубо говоря, результат.
Вот, например, как вы видите, у нас один результат теста пришел, и сейчас придут остальные. Если посмотреть на то, как это организовано в пайплайне, мы можем вот сюда зайти, то здесь все это сделано то же самое, что сделано в Jenkins, оно реализовано здесь. Как вы видите, вот у нас способ формирования ланчнейма, это Allure GitLab. и commit. А тут у нас демо-кукумбер и номер билда.
То есть тут как бы вот так же можете задать способ формирования ланчнейма. Также есть информация про теги и информация про Allure тест-план. Это нам сейчас не особо интересно, это нам будет интересно чуть попозже. Отлично, да. Потом мы запускаем наши тесты и потом мы закрываем Allure PTL.
То есть это вот как раз дает нам реалтаймовые результаты тестов даже в GitLab. Оно сейчас немножко некрасиво сделано, мы над этим работаем. Скоро появится именно прикольная интеграция через докер-контейнер, но там все не так просто, потому что GitLab CI прибивает все процессы.
Короче, мы там аккуратно все сделаем. На самом деле, при всем при том, что задача кажется простой, она с внутренностями. Итак, давайте дальше. Мы запустили наши тесты, и давайте перейдем непосредственно и посмотрим у нас сам Allure-отчет.
Здесь у Zoodops есть быстрые фильтры, то есть мы можем быстренько посмотреть, какие тесты у нас есть, можем посмотреть их по разным параметрам и так далее. Это мы немножко позже посмотрим. Потом делаем фичи.
Вот у нас результаты тестов. Вот у нас тест прошел, у нас есть информация, что мы стартанули драйвер, остановили драйвер, есть информация про API-тесты и так далее. Вся вот эта информация, она сгенерировалась на основе нашего кода. Если вы уже пользуетесь Allure, то тогда у вас вообще проблем нет, потому что у вас все это как раз появится.
Если вы не пользуетесь Allure, то я отдельно потом запишу, как любой код, даже без степов и без всего, превратить также в красивый сценарий. Давайте пока на этом останавливаться тоже не будем. Дальше что мы делаем? Дальше мы переходим в Test Cases, и тут Test Cases нет.
Почему? Нам надо остановить наши джобы. Мы нажимаем Stop Job Run. Я сейчас объясню, зачем мы это делаем.
Вот так вот нажимаем «стоп», «стоп», «стоп», переходим в «тест кейсес», и мы видим, как у нас генерировались тесты. Соответственно, это одна из основных, наверное, фичей Allura, которая называется «живая документация по автопрестам». И давайте я тут коротко расскажу, зачем мы эту фичу делали. Суть в том, что автоматизация начинает набирать обороты.
Прямо уже, ну, прям сильно. Во многих компаниях я знаю, что... появляется прям большое количество тестов. И людям внутри команды, внутри проекта всегда интересно, сколько у них тестов, что это за тесты, какие тесты у нас есть на API, какие тесты у нас есть на веб-интерфейс. И вот эта вот задача, она в целом отчасти решается Allure Report.
Зайдите в Allure Report, посмотрите, какие у вас тесты. Но на самом деле в проекте обычно работают несколько человек, по крайней мере у меня так. У меня есть мобильные тесты, у меня есть веб-тесты, у меня есть опишные тесты. Над тестами могут работать разные, как я уже сказал, разные роли.
Разработческие тесты, тесты инженера по автоматизации. И Allure позволяет вам через вот такое вот красивое написание тестов делать лайв-документацию. Соответственно, когда у вас запускается результат теста, на его основе генерируется тестовая документация.
Если теста нет в системе... Она создает новый. Если тест существует в системе, то она обновляет его тестовый сценарий и все остальное.
То есть у нас тут есть, например, информация про то, кто ответственный за этот тест. На самом деле вот это чуть ли не самая такая активная фича, которую я пользуюсь в первую очередь. И она появляется после того, как мы пишем вот такую вот аннотацию в коде. И вы всегда можете понять, кому прийти, если с этим тестом что-то не так. Ну и вся остальная метаинформация тоже собирается.
Итак, ну и, соответственно, можно, например, посмотреть по разным тестам, которые у нас есть. Мы, например, можем посмотреть тесты на конкретную свечу, мы можем посмотреть тесты на конкретную историю, ну типа и так далее. То есть вот это все у нас появляется.
Итак, я заканчиваю первый блок. В первом блоке я рассказал, как независимо от того, какие тесты у вас есть, с помощью настройки GitLab вы просто форкаете репозиторий, потом делаете небольшие настройки из трех переменных. в ваших конфигах. Вот здесь вот.
Или вы настраиваете то же самое в Jenkins. Здесь я показываю веб-интерфейс. Вот это через веб-интерфейс как настроить. Это все есть наша документация. А вот здесь вот у меня есть интеграция через пайплайны.
Пайплайн-скрипты, в принципе, они естественно, они поддерживаются. И это выглядит вот таким вот образом. Виза, люра, плод. И внутри вы запускаете тест.
И у вас тут как раз будет работать вот этот вот real-time. Результаты тестов попадают в... валюр. Здесь вы можете посмотреть хороший отчет, посмотреть только все сломанные тесты, посмотреть причину падения каждого теста и так далее. И на основе результатов тестов у вас генерируется тестовая документация, и вы можете уже понимать, сколько у вас тестов, в каком они состоянии, как часто они запускаются и так далее.
У нас в этом блоке все. Появляются какие-то вопросы? Пока вопросов нет.
Отлично. Тогда едем дальше. Или у нас есть в чатике вопросы? Сейчас посмотрю. Да, окей.
А, вот Михаил пишет вопрос, видимо. Давайте я дождусь. Вот у тебя есть вопрос от Ильи Соболева. Что является ID теста?
Отличный вопрос. Супер, супер круто. Молодцы. Это отличный вопрос.
Смотрите. Вот эта штука является ID-шником тестов. То есть мы используем full qualified name. в качестве ID-шника теста.
То есть это package name, потом вот этот class name и method name. Вы скажете, типа, Артем, слушай, но у нас же тесты могут переименовываться. Я сразу же забегу вперед, и у нас есть вот такой вот плагин, зацените, я просто нажимаю правой кнопочкой, говорю assign ID, выбираю проект, demo project, нажимаю OK, и он проходит по всем нашим тестикам.
и расставляет вот такие красивенькие ID-шнички. Вот так вот. То есть у нас используется два типа ID-шников.
Первый тип ID-шников используется, это вот этот full name. Это для того, чтобы, если у вас легкая разработка, если вы не хотите как-то сильно завязывать тесты друг на друга, то вы используете вот этот full name. Но в этом случае вам надо аккуратно переименовывать ваши тесты.
На самом деле удивительно, но я последний раз переименовывал название теста, я уже не помню когда. То есть я просто... привык к тому, что этого делать не надо, потому что всякие другие системы, любые X-Unit отчеты и так далее, они на самом деле всю историю хранят также по вот этому full name, и лучше просто лишний раз это не переименовывать.
Нам можно переименовать лучше вот этот вот display name, а вот здесь вот красоту в названии метода наводить, мне кажется, не надо. Но если вы хотите использовать фиксированные ID-шники, у вас, например, тесты постоянно переименовываются и постоянно происходит какой-то рефакторинг, одной кнопкой... одной кнопкой, вы прям нажимаете, и у вас генерируется, ну, точнее, он осигнит все ID-шники, которые есть в Allure, он проставляет.
И, соответственно, после этого вы можете спокойно делать переименование и так далее. Про плагин я еще подробнее чуть-чуть расскажу. Сейчас я этот, от RollBet, короче, вот эти вот данные, они нам пока не нужны. Надеюсь, вопрос ответил. И покажите немного в коде, на то слишком быстро пролистали.
Немного в коде аннотация. В коде аннотации очень простые, давайте просто их разберем. У нас тест состоит из шагов, как вы видите.
Мы открываем страницу pull-request, создаем pull-request с какого-то бранча и должны увидеть, что этот pull-request создан. Если мы перейдем сюда, то мы увидим вот такую вот аннотацию, которая эквивалентна тому, что мы увидим в Алюре. То есть, грубо говоря, вот видите, это один в один. То есть это такая вот дополнительная разметка. Дальше давайте пройдемся дальше.
У нас тут есть story. Вот смотрите, story. И тут есть название. Мы переходим сюда и видим story и такое же название.
Вот оно один в один. У нас есть теги. И переходим сюда.
Вот у нас теги. У нас есть display name. Оно ровно так же.
Вот оно, display name. Вот здесь вот. Оно сюда добавляется.
И так далее. У нас есть, например, для всех тестов у нас есть фича issues. И она, вот она, блин.
И у нас есть тут фича. Я другой тест показываю, но это без разницы. То есть, типа, оно просто мапится. Об этом я сейчас поговорю в следующем блоке.
Поэтому вот оно сейчас будет подробно рассказано в следующем блоке. Поэтому можно, в принципе, продолжать. Итак, еще какие-то вопросы.
Питон как? В Python то же самое, там есть декораторы. И там тоже самое.
В.NET тоже есть. Давайте я сразу сделаю вот такой вот пример. Я сейчас покажу.
Смотрите, у нас есть проект, который называется Allure Examples. Я его скидываю в общий чат. Вот.
Вот, смотрите. В TestTrail чуть попозже. Вот этот, я запинил вопрос, вот про это мы чуть-чуть попозже поговорим.
Давайте вот так вот, мы это запинили. Короче, так, вот тут вот. И у нас тут есть пул реквестики.
Посмотрите, скоро появится GUnit 5, TestNG, у нас Robot Framework и PyTest. Давайте зайдем в PyTest. Мы посмотрим файлы.
И вы тут увидите всю вот эту разметку. Фикстуры, severity, label, tag и так далее. То есть можете посмотреть, тут вся разметка есть.
И то же самое давайте сделаем, то же самое в.NET, один в один. Давайте посмотрим код. Зайдите сюда сами, и вы увидите, что оно повторяется очень похоже. Смотрите.
AllureFeature, AllureSuite и так далее. AllureSuite. То есть пройдите, посмотрите вот этот вот пример. Он показывает один в один для всех языков.
Так. Окей. StatusActive. Это я тоже покажу сейчас, что такое StatusActive. Давайте пока двинемся дальше.
Про StatusActive я тоже запомнил. Поехали дальше. Это будет немножко дальше. Смотрите, вторая, ну, типа, Тёма показал сейчас вам вот такую штуку и говорит, ребята, вот смотрите, как всё хорошо. Но, а, кстати, вот ещё параметризованные тесты, зацените, как они клёво выглядят.
У вас прямо есть табличка с параметрами, и сразу же видно, что этот тест параметризованный, и как бы с какими параметрами он запускался. Но в разметке тестов я уверен, что у вас тесты, когда вы их размечаете, они размещаются с дополнительными параметрами. И много наших клиентов добавляют еще дополнительную разметку в ваши автотесты. Они, например, хотят посмотреть, какие микросервисы у них тестируются, какие тесты API, какие UI и так далее.
То есть всякую доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-доп-д Что нам надо сделать? У нас есть... Сейчас зайду.
Так. Я тут немножко... Ладно, окей.
Давайте я это быстро сделаю прямо вот так вот. Что я делаю? Я завожу аннотацию, которая называется micro-service. Вот таким вот образом.
Вот это я удаляю и тут пишу. Сейчас, секундочку, мне надо открыть еще один проект, чтобы оно было синхронно. GitHub, Ярошенко, Кукумбер.
Я прибейзил неправильно свои тестики, и у меня из-за этого немножко съехала разметка, она должна быть общая. Вот, MSRV, вот таким вот образом. Я добавляю вот такую вот аннотацию, появляется аннотация «Микросервис», и я начинаю размечать свои тесты. Например, вот этот у нас тест будет на «Микросервис биллинг», а вот этот тест будет на «Микросервис репозиторий». Заметьте, что это кастомная аннотация, я ее вот прям взял и только что сделал.
То есть вы можете таким же образом размечать свои тесты. И давайте все тесты остальные также разметим. Микросервис billing, микросервис billing, микросервис, вот это пусть будет репозиторий. Вот эта вот аннотация, она добавляет признак каждому тесту микросервис. После того, как мы сделали вот это вот изменение, мы идем в Allure и говорим, что если у нас есть у теста признак микросервис, то создай микросервис custom field.
Зачем это сделано вот так вот? Потому что вот это ключ, который находится в коде. А вот это это некоторое слово, которым вы оперируете.
Оно, может быть, например, в какой-то момент вы можете переназвать его на русском языке. Поэтому ровно на это слово в коде завязываться опасно. То есть если вот здесь оно переименуется, тогда оно тут поменяется. Поэтому мы интегрируемся через вот такой вот ключик.
После этого сейчас я сделаю commit. Я делаю commit, ладно, через тут вот терминал, сделаю git status. А, я понял, что у меня за проблема.
Давайте я сейчас закрою проектик, я просто открою другой проект. Я просто открыл не тот проект. Мне надо вот этот вот проект, там уже все это сделано. Вот, у нас уже есть микросервис, тут настроен.
Но хорошо, что я показал, как это работает. Оно работает совершенно точно так же. Соответственно, я беру вот этот вот ключик, вставляю сюда.
Также мне интересно фреймворк, с помощью которого у меня тест автоматизируется. Я пишу фреймворк, и тут тоже пишу фреймворк. Вот таким вот образом.
Делаю submit. Вы можете сейчас все вот это повторять у себя. Я вам скину в чате вот эту информацию. Раз. Вот это.
micro-service. А framework, вот это вот, это framework. Вот, поехали дальше.
Следующее, что мы сделаем, это мы хотим понять, на каком окружении запускались наши тесты. Для этого у н��с есть тут, и мы видим, что у нас тесты запускаются с какими-то параметрами. Мы говорим о том, что вот этот параметр, это в алюре будет host. Вот этот вот параметр, branch, это в алюре будет branch. И сделаем то же самое с BrowserName, и это будет браузер.
Почему мы делаем именно так? Почему такой вот маппинг? Суть в том, что у вас одна джоба может отличаться от другой джобы, потому что вот эти вот параметры, они часто создаются тестировщиками, и они обозначают одно и то же, разными тестировщиками, они обозначают одно и то же, но их надо к единому формату привести. И, соответственно, чтобы не перерабатывать ваши джобы, потому что это много проблем, вот эти параметры, на них у вас завязан код, то есть они у вас используются в коде. Вот эту задачу можно решить на уровне Allure.
То есть вы сюда добавляете название параметра и потом указываете, какой этот параметр будет означать. Дальше мы переходим в слои тестов. Как я говорил, у нас есть разные типы тестов.
У нас есть рестовый слой. Мы берем, копируем рест и говорим, что это API. тесты второе у нас есть веб интерфейсные тесты web нажимаем в и у нас юальные тесты юайтест да ну типа и соответственно вот такая вот задача короче будет решена теперь переходим в ланче и давайте запустим наши тесты еще раз запускаем кукумбер запускаем g-unit 5 И можно запустить вот это, но я пока не буду делать, потому что, я говорю еще раз, он будет долго запускаться, вы можете у себя это запустить, и у вас все это будет работать.
У меня появилась новая информация, смотрите, у меня появилась информация о том, где запускаются наши тесты. Теперь мы видим браузер, мы видим хост, и мы видим бранч, на котором наши тесты запускались. Если мы пойдем сюда вглубь, то мы увидим, что у нас появилась у каждого теста информация про тип теста. Это UI-тест.
Также появился environment, на котором этот тест запускается. Это на самом деле реально очень удобно, потому что вы сразу же понимаете, что этот тест запускался в браузере Firefox на таком хосте. И дальше у нас появилась информация про framework и про репозитории, которые мы тестируем. То есть, грубо говоря, вот эти метаинформации вы можете очень легко кодировать в ваших тестах, и потом она будет добавляться в валюту. Теперь мы переходим в тест-кейсы.
И видим, что тут документация не обновилась. Почему она не обновилась? Потому что нам надо нажать Stop вот в этот момент.
И у нас информация обновилась. То есть вот у нас произошел апдейт тестовой документации. И теперь мы можем делать всякие прикольные штуки.
Посмотреть только опишенные тесты. Посмотреть опишенные тесты на GUnity. Посмотреть опишенные тесты на GUnity, которые тестируют фичу Labels. Таких тестов нет.
То есть, грубо говоря... минимальными такими усилиями вы можете действительно импровить вашу тестовую документацию и очень много полезных вещей искать. Какие у нас есть UI тесты, какие у нас есть UI тесты на G-Unity и так далее.
Это на самом деле довольно круто. Вторая фича, которая тут есть, это можно указывать с помощью Lanchers. Здесь можно указать Live Documentation Policy.
Вот это вот сейчас у меня документация обновляется со всех ланчей. На самом деле я так редко делаю, потому что у нас есть pull-реквесты, и разработчики разрабатывают новые тесты, они разрабатывают в pull-реквестах. И с этих pull-реквестов документацию обновлять не надо. Надо, короче, чтобы она обновлялась только с мастера. Соответственно, я тут могу задать условия.
Написать, что тег равно мастер. И у меня документация будет обновляться только с тестов, которые запускаются на мастере. Это очень удобно.
Соответственно, также можно автоматически закрывать ланчи. Например, сейчас у меня автоматически закрывается ланч после 24 часов. Можно поставить меньшее время, и у вас вот эту операцию делать руками не надо будет.
Зачем нужно делать вот эту операцию закрытия ланчей? После того, как вы закрыли ланч, работа над ним завершается. Вы не можете создавать, делать с ними никаких активных действий. То есть, грубо говоря, если мы зайдем сюда, то тут будут... Ого, прикольно.
Что случилось? Так, давайте посмотрим. Еще раз.
Что-то не то. Окей, сеть, видимо. Короче, если вы зайдете сюда, то вы увидите, что все кнопки отсутствуют.
Если мы нажмем play, здесь... и то вы увидите, что кнопочки появляются. То есть, грубо говоря, с закрытыми ланчами нет возможности работать, и это специально сделано так, что этот ланч уже уходит в архив.
И еще одна прикольная фича это деревья тестов. Мы делаем микросервис. Приходит к вам руководитель и говорит, «Тема, а покажи, пожалуйста, какие микросервисы у нас тестируются». Ты говоришь, «Не вопрос, микросервис». И выбираете тут «Микросервис».
Вот так вот. Отлично. Переходите в тест-кейсы и меняйте группировку тестов на микросервисы.
И теперь вы видите, что у вас на микросервис-биллинг 6 тестов, а на микросервис-репозиторий 8 тестов. У нас, например, сейчас происходит миграция тестов. Мы переписываем частично тесты с Java на JavaScript. То есть мы меняем у себя фреймворк. И для этого мне надо понимать прогресс.
Как быстро мы меняем наши тесты. с Java на JavaScript. Для этого мы можем сделать так же, сделать, допустим, в деревья, создать Frameworks и сгруппировать по Framework.
Вот таким образом. Переходим в Test Cases, выбираем Frameworks, вот так вот, и видим, у нас сейчас 7 тестов на Cucumber, 7 тестов на Junio платформе. При этом очень удобно, что любой человек может быстро сделать свое представление по тестам.
Вот кто-то пришел, посмотрел по микросервисам, кто-то посмотрел по фреймворкам и так далее. И также вы это можете группировать. То есть я сделал только первого уровня, а, например, я хочу по фреймворку посмотреть вот здесь.
Я добавляю фреймворк, перехожу обратно, и у меня уже по микросервисам будут тесты. Смотрите, сначала они группируются по микросервису, а внутри они группируются по фреймворку. Это довольно прикольный подход в отличие от обычных тест-рейловских. папочек, потому что проблема тестироваловских папочек заключается в том, что у вас фиксированная структура. И я периодически, на самом деле довольно часто, прихожу в команду, когда занимаюсь автоматизацией тестирования, и вот эти папочки, они написаны одним человеком, и это какая-то магия, которая описана одним человеком, и все остальные живут в этой парадигме.
И если вам надо сделать какой-либо другой срез по этим тестам, то у вас будут проблемы. Вы можете жить только в одной этой структуре. В Allure вы можете смотреть на тесты под разным углом.
Хотите, посмотрите их по фичам, хотите, посмотрите по микросервисам, хотите, посмотрите ваши тесты по фреймворкам. И это, на самом деле, очень удобно, потому что позволяет вам очень быстро переключать контекст. У нас есть чатики. Да, уже хорошо, что Егор ответил. Да, параметризованные тесты зачетно.
У нас вот этот блок подходит к концу. В этом блоке я рассказал, как с помощью простых настроек в Allure сервере вы можете сделать так, чтобы у вас появилась информация об окружении, на котором ваши тесты запускались. Также появилась информация про типы тестов, API-ные тесты, UI-ные тесты и так далее. И дополнительная информация про всякие custom-филды, например, framework, microservice и прочее. При этом эта информация попадает в вашу тестовую документацию очень легко, и вы можете по ней потом фильтровать и смотреть, какие у вас есть UI-ные тесты, какие у вас опишенные есть тесты, и делать разную группировку.
То есть вот у вас группировка по микросервисам, вот у вас группировка по фичам, и все это для опишенных тестов. Здесь есть какие-то вопросы? Да, вопрос выше, Павел. Павел, сейчас смотрю. Ммм...
Я правильно понял, что для корректной работы реалтайма надо делать покил Allure KTL? Нет, это не то, что прям надо делать покил Allure KTL, это не для корректной работы реалтайма. То есть, грубо говоря, нам надо остановить процесс.
Я думаю, что в течение пары недель у нас появится уже команда, которая будет выглядеть так. Allure Uploader Start, Allure Uploader Stop. И тогда не надо будет килять процесс.
Но внутри... это все равно будет остановка процесса. Это будет посыл сигнала, что Allure останавливается. И, по сути, у нас, когда мы запускаем Allure Uploader, то у нас результаты тестов аплоудятся, и он постоянно висит и аплоудит в этот момент. А когда мы...
Ну, и ему надо потом сказать, типа, чувак, все, остановись, результаты тестов больше уже не приедут, потому что у нас Gradleukling-тест, эта команда закончилась, и, соответственно, больше не надо смотреть. Вопрос выше. А можете рассказать, как прокидывать attach, если тест упал? Тут это легко делается.
Вот у меня есть такой метод, который называется attachPageSource. Тут есть такая вот аннотация attachment. Здесь вы можете посмотреть, как она прикладывается.
И, соответственно, если мы зайдем в результаты тестов, то, естественно, там будет у нас информация про attach. Выглядит он вот таким вот образом. Вот у нас есть страничка, которую мы приатачили. Более подробно вы можете найти вот в этом репозитории, который я скидывал, где с примерами Allure Examples. Я его скинул?
Да. Вот здесь есть примеры, как делать атачменты на всех языках. То есть вот сюда вот зайдите.
Там есть отдельный атачмент-тест, который показывает, как делать атачменты. Куда можно записывать мануальные тесты? Да, это ровно сейчас про то, что мы будем говорить. Сейчас как раз переходим к блоку мануальных тестов.
Если вопросов нету, поехали как раз туда. Я вот смотрю, что вроде как вопросов нету. Если что-то я забыл ответить, то отвечу.
В Алюре также можно хранить и мануальные тесты. У некоторых есть аллергия на слово «мануальные тесты». И я сам не очень люблю называть их мануальными тестами, потому что это тестовая документация.
Тест сегодня мануальный, завтра он автоматизированный. И я сам пользуюсь этой фичой, когда нахожу ошибку в Allure. И, соответственно, для меня это просто способ сначала как-то свои мысли оформить, если у меня нет доступа к идее, например, нету возможности сейчас этот тест написать. А потом я его автоматизирую. Поэтому мы разблокируем вот тут вот замочек и пишем Auth, External, Auth.
И дальше пишем Auth via Google. У нас появляется вот такой вот тестик. Здесь мы можем разметить его.
Например, сказать, что этот тест у нас критичный, и он у нас через веб-интерфейс. Также сказать, например, что этот у нас микросервис у нас будет. Микросервис у нас будет. Биллинг, например.
Неважно. А, давайте сделаем микросервис другой. Секундочку, какой биллинг? Давайте сделаем его красивым. Микросервис авторизации у нас будет.
Микросервис. И сделаем ALF. Отлично.
И напишем для него сценарий. Открываем главную страницу, авторизуемся как пользователь Ярошенко АМ. У нас немножко другая концепция. Вместо того, чтобы писать на каждый степ ожидаемый результат, у нас есть вложенные шаги. И я объясню, почему.
Опять же, я сейчас работаю с несколькими проектами, в которых есть ручное тестирование. Я когда ревьюю тесты, то я ужасаюсь, что впишут обычно в expected result. Открываю главную страницу, страница открыла.
Ввожу в поле такое-то значение. Значение в поле введено. Это как минимум в два раза больше работы. На мой взгляд, это бессмысленная вообще документация. Есть некоторые места, когда надо писать expected result, но это не постоянно.
Понятно, что если вы отправляете запрос и получаете ответ... то тогда это можно писать. Но в остальных случаях, мне кажется, что это логика избыточная. Поэтому у нас они делаются, если надо, это делается со степами. Я сейчас это покажу.
Вводим в поле логин значение Ярошенко АМ. Вводим в поле пароль значение вот такое. Нажимаем кнопку.
Войти. Потом, я сейчас переключаюсь между вот этими штуками с помощью шифта. Вот здесь вот эта информация есть. Вот вы можете ее почитать. Я делаю таб, и тогда у меня делаются сапшаки.
Я делаю shift-tab, и я возвращаюсь назад. Дальше мы делаем следующее. Вот shift-tab я сейчас нажал. Второе.
Авторизуемся как пользователь. Проверяем, что текущий... пользователь ярошенко а м а и тут можно как раз сделать ожидаем да им что имя пользователя артем ярошенко ожидаем что аватарка пользователя асов под новым аватар сейчас секундочку а вам так к пользователям как в Атача.
А потом давайте я сделаю, возьму свою аватарочку, скачаю Артем Ярошенко и приложу ее. Вот это вот мы делаем download. Приехал у меня. Он тот скачал? Нет, не тот.
Вот, ага. И тут мы делаем, потом мы идем сюда. Давай, давай, показывайся. И просто перетаскиваем ее вот в этот вот степ. Здесь у меня есть вот такая вот аватарка.
Я говорю аватарка и делаю submit. Вот у меня появляется вот такая вот красивая аватарка. И потом я говорю, что разлогиниваемся, например. Раз, секундочку.
Из-за того, что браузер... пытаюсь увеличить, чтобы вам было удобно. Браузер немножко прыгает, извините.
Вот так вот и разлогиниваемся. Все. У нас получается вот такой вот сценарий.
В нем довольно подробно описано, что произошло. Соответственно, у вас есть подробное описание. Можно, в принципе, написать еще description, но это уже на ваше усмотрение.
Что потом происходит с такими тестами, по крайней мере, у меня? Дальше я перехожу в идею. У меня вот здесь появляется идея, и я создаю новый тест.
Вы как бы этот тест написали, мы его в следующем блоке позапускаем. То есть это будет прямо настоящий тестик. Я даже сейчас сделаю клон нашего тестика.
Мы все склонируем, и у нас будет называться этот тестик через Facebook. Потому что сейчас вот этот тест мы автоматизируем. Потом дальше, как у нас происходит автоматизация вот этого теста.
Мы копируем вот этот вот ID-шник, переходим в Allure, делаем Auth, Test. Дальше мы делаем следующее. Public, Void, Test, Google, Auth. Ставим на табсу Test. И нажимаем правой кнопкой и делаем Import Test Case.
И вот так вот делаем. И смотрите, что получается. У нас вот эта вот болванка, которую мы сгенерировали теста, ну, типа, или там ручной тест и так далее, мы его очень легко перекинули полностью в код.
Причем, заметьте, у меня есть кастомная, вот эта вот кастомная аннотация, микросервис, я ее создал, она вот лежит у меня прямо в проекте. И Allure ее тоже проставил. То есть Allure написал, что у нас фича AUS, микросервис AUS, стори такая-то.
Тут можно навести порядок, например, сделать, ну, грубо говоря, понятно, что у нас фича, это будет вот здесь. Понятно, что стори у нас, ну, типа, да, микросервис, например, мне тоже кажется, что он идет сюда. Сюда можно еще добавить аннотацию, что это Yershenka.am и так далее.
То есть, грубо говоря, порядок надо навести, но прикольно, что у нас появляется прямо полный сценарий. И этот сценарий очень легко... отдать разработчикам после того чтобы он это полностью автоматизировал и он может сюда код например вставлять вот таким вот образом то есть и тут вызов команды селенида то есть вы тут начинаете работать с браузером такая такой способ разметки позволяет вам экономить на самом деле довольно много на коммуникации то есть ручной тестировщик он начинает реально концентрироваться в сторону того чтобы у вас было хорошо сделано все с точки зрения понятности тестов А автоматизатор, он вот эти вот вещи, короче, уже заполняет. Понятно, что этот подход немножко отличается от этого подхода. Видите, что тут надо будут степы.
Если у вас используется степовый подход, то просто удалите степы, которые такие, и замените их на степы, которые у вас здесь созданы. Тут все будет окей. Кроме того, те, кто слушал мой доклад, который называется TestCase SSCode, для вас уже конкретные примеры.
Грубо говоря, сейчас есть такой тренд, я рассказывал про то, что на самом деле тест-кейс сохранить в ТМСках это немножко тяжело, потому что вы даже рефакторинг не можете сделать. Я думаю, что вы все в курсе, что если у вас там поменяется, условно говоря, какие-нибудь данные, то вы потом 3000 тестов не отрефакторите. Это практически невозможно.
Никакая ТМСка не даст вам нормальных инструментов рефакторинга большого количества тестов. И я знаю команды, которые, вот я сейчас общаюсь с одной компанией, которая просто говорит, что ну типа все, мы подошли к пику, у нас типа там, по-моему, 3000 у них ручных кейсов, когда актуализация тестов невозможна. То есть типа следующий, вот они уже говорят, что типа следующий левел, это все, они типа не могут уже заниматься актуализацией тестов, потому что вот 3000 тестов для них сейчас пик. И им надо либо уже людей нанимать чисто под актуализацию тестов, либо что-то менять. Соответственно, есть идея переносить вот эту документацию в код.
При этом, заметьте, вы можете, как ручные тестировщики, можете спокойно продолжать пользоваться Allure с этой стороны, но при этом в одну кнопку переносить тот же сценарий ровно в код. Мы сейчас вот над этой функциональностью работаем. У нас поддерживается Java, Python, Cucumber.
Java, Python, Cucumber, Kotlin, по-моему, еще поддерживается. PHP, он в стадии доработки. И, по-моему, пока все. Я еще собираюсь работать с.NET.
Скоро появится поддержка.NET, ровно такая же. И, соответственно, есть такая мысль, чтобы это все отображалось легко в коде. И вот такая вот тема.
Итак, тут два назначения у этого плагина. Первое назначение это для ручных тетерочков, которые устали рефакторить, потому что... В ИТ-эйке рефакторить очень легко.
Просто копируете строку, и она у вас делается. Нужен переиспользуемый степ, просто создайте тестовый метод. Public, static, do... Зачем я тут показываю?
Вот, у меня вот эти степы, они переиспользуются. Вот этот степ используется в нескольких тестах, я даже могу сказать в каких. Я говорю find usages, и вот все места, где у меня этот степ используется.
И таким образом вы, немножко разобравшись в коде, можете прямо, ну, типа, очень-очень мощно прокачивать свои тесты и тратить минимум времени на актуализацию. И второе это для автоматизаторов, которым лень писать вот такие вот красивые, короче, названия. Им хочется, типа, код писать, а вот этим могут заниматься как раз другие роли, которые тесты составляют. Давайте тут немножко изменим. Естественно, автоматизатор делает рандом юзер.
рандом юзер, тут есть рандом пасс, потом пользователь рандом юзер, мистер рандом. То есть у него... И аватарку он вообще скипнул, например. У него получится вот такой вот какой-то сценарий. То есть он его немножко изменит, и у вас сценарий поменяется на самом деле.
Особенно если он использует какие-то свои вот такие штуки, то это совершенно точно произойдет. Дальше нам надо запустить наши тесты. Давайте запустим тестики.
Запускаем наш тест. Как-то подозрительно. Вот, тест запустили.
Нажимаем Upload Allure Results. Выбираем Demo Project. И говорим, что локальный запуск.
переходим в Allure, у нас тут появляется локальный запуск, переходим в него и смотрим. У нас, как вы видите, появилась информация про Owner, которую я добавил, и вся остальная информация сохранилась. То есть вот таким вот образом оно все устроено.
Теперь мы нажимаем Stop, переходим в тест-кейсы и заметьте, у нас автотест стал автоматическим. То есть вот этот вот авторизация через Google, он стал автоматическим. У него появился ключ автотеста, и его второй айдишник в мире автоматизации тестирования. Но при этом все остальные поля, если бы вы обновили, они тоже обновились бы.
Но сценарий пока остался ручной. Его можно сравнить. Вот слева у нас некоторый эталонный сценарий, мы называем его не ручной, а эталонный сценарий.
Это тот сценарий, который должен, ну типа, грубо говоря, ну типа ассоциируется именно с эталоном. А справа у нас сценарий автоматический. То есть можно посмотреть, что тут у нас Ярошенко Артем, тут рандом юзер.
Понятно, что тут немножко не хватает какого-то дифа. То есть было бы круто, чтобы мы подсвечивали красным, что изменилось. Это появится в Алюре совершенно точно. Но при этом мы можем посмотреть, что реально сделал автоматизатор. Сравнить сценарий, который нам пришел из автотеста, с некоторым ручным сценарием.
Периодически люди оставляют ручные сценарии. Я покажу зачем. В некоторых случаях это может быть полезная фича. В следующем блоке я покажу, зачем можно оставлять у автотеста ручной сценарий.
Либо вы можете его удалить. Вы сделали ревью, сказали, что вроде как автотест делает ровно то, что я хочу, поэтому давайте эталонный сценарий удалим. В таком случае у вас будет использоваться вот этот автоматический сценарий в качестве эталонного.
Если вы что-то хотите изменить, то вы можете вытянуть текущий сценарий автотеста и в нем что-нибудь поменять. Например, тут можно написать «выставить куки с со-значением таким-то, таким-то». Потом нажать «Submit», перевести статус в «Outdated», скинуть коллеге, что типа «ребята, тут у нас outdated теста». Заходите в outdated test, вот у нас outdated test. У него, я там смотрю свои тесты, я ввожу сюда, заходит Дима Баев, говорит, какие у меня тесты outdated, у него нету.
Заходит Артем Ярошенко, говорит, какие у него outdated тесты, вот его outdated тесты. Я смотрю, что изменилось, смотрю, а, надо кулку выставить, окей, сорян, извиняюсь, модифицирую свой тест, загружаю его обратно, опять же проводится... какое-то сравнение вот этих вот сценариев, и потом опять можно этот сценарий удалить.
Собственно, вот таким вот образом организовано именно создание ручных тестов и их интеграция с автотестами. Про запуск ручных тестов мы сейчас поговорим чуть позже. То есть это вот прям в следующем блоке я покажу, как эти тесты проходить.
Этот тест у меня, ну, условно говоря, фейковый, то есть я его тут удалю, потому что коммитить это все долго будет. Вот эти вот данные, вот эти все коммитить. Поэтому я его просто удалю сейчас вот таким вот образом, и пусть он нам не мешает.
Кстати, у нас, видите, тест у нас никогда не удаляется. У нас тест уходит в такой режим, и вы можете, если что, его ревернуть. И он у вас опять появится.
То есть вот эта вот фича, она тоже довольно прикольная, потому что нельзя удалять тесты. Это, на самом деле, на мой взгляд, очень плохо, поэтому мы их просто прячем, и при необходимости их можно найти. Окей, итак, в этом блоке я рассказал, как мы создали ручной тест. В ручной тест мы можем писать сценарий. Сценарий у нас многоуровневый, и это очень удобно, потому что можно посмотреть короткий сценарий, а можно посмотреть длинный сценарий.
Также сюда можно добавлять атача. С помощью идеи плагина мы эти тесты можем автоматизировать, и у нас генерируются прямо клевые тест-кейсы. И потом, когда мы заливаем результаты в Allure, эти тесты скрепляются уже по Allure ID. То есть это основной ключ, по которому происходит автоматизация. И тест превращается из ручного в автоматический.
Собственно, на этом... А, еще последняя тема. Можно с помощью вот этих вот политик настроить, какие данные хранятся в алюре, а какие хранятся в коде.
То есть в данном случае вы видите, что все поля нередактируемы. Нельзя ни ишью отредактировать, ни теги, потому что это все берется из кода. Но если вы выставите вот такую вот настройку, мы переходим в upload, выставляем настройку, что, например, теги у нас будут из тест-кейса.
Переходим обратно в Allure, хоп, и теги теперь редактируемые. Теперь теги находятся, информация про теги, она находится в Allure. Мне этот подход не очень нравится, то есть я все-таки топлю за подход, когда все переносится в код, но тем не менее, если у вас какой-то переходный период. или, например, действительно тегами управляют менеджеры, там, ручные тестировщики и так далее, это в целом вполне нормально, потому что при желании вы можете все это синкнуть с кодом с помощью одной кнопочки. То есть Allure пробежится по коду, высинет атрибуты и перенесет их в код.
Поэтому в целом это вполне приемлемо. Итак, на этом блок заканчивается. Какие вопросы? Я читаю чат. Так, переход.
Плагин огонь. Для P-Charm он есть. Еще раз повторюсь, для P-Charm он есть. Мы вот, смотрите, заходим в плагин. Мы заходим в Allure.
Я недавно обновил. Посмотрите, какой красавчик, с каким красивым логотипом. Просто чудно.
Мы заходим в supported products, и мы видим, что у нас тут есть... P-Charm, P-Charm Community, причем важно, что у нас для Community Edition. Вам не нужно платный P-Charm использовать и так далее. То есть это все прям поддерживается.
Заходите, смотрите. Переход на Allure из текущей TMS. Да, у нас есть специальная дока, которая называется примерно следующая. Сейчас покажу.
Да, это ошибка, которую мне просили поправить. Migration via Script. Мы умеем автоматически мигрировать с разных ТМС. У нас есть поддержка Test Rail, Zephyr, Zephyr Scale, это которая TM4G, и RTM.
Вот, собственно, вот эти вот штуки у нас поддерживаются. Можете про это почитать, мы помогаем мигрировать, в том числе и степы, и аттачменты, и все остальное. Про импорт из кейсов.
На запись, да, естественно, было бы интересно видеть, было-стало. Не понял, ну ладно. Правильно я понял, что если на уровне кода был удален тест, то Allure сам это поймет и он будет удален. Нет, надо сделать вот так вот.
Смотрите, я сейчас прям покажу. Надо вот здесь вот нажать правой кнопочкой и... Секундочку, тут у нас сначала надо сделать вот так вот, я сейчас покажу. Вот так вот.
Окей. И вот тут вот надо нажать Allure Delete Test Case. Давайте сейчас я его открою сначала, чтобы мы его вернули потом. Вот, у нас есть вот этот тест. Я просто нажимаю Allure Delete Test Case.
Demo Project. Ок. И он удаляет тест. Он удалил код.
А теперь, если мы зайдем сюда, то тут тест тоже будет удален. Но мы его восстановим сейчас, потому что не надо удалять тесты. просто так.
Так что, короче, вот такая вот логика. Я, кстати, заметил, что у меня плагин реагирует на Allure ID, и на самом деле, если Allure ID не будет, то, видите, менюшка эта пропадает. Я, короче, подумал, как это сделать.
Как раз круто, что я провожу презентацию и нахожу какие-то проблемы в плагине. Видите, тут нету менюшки «Удалить». Я ее добавлю, я обработаю этот случай. Удалить целый пакет нет. Пока, кстати, только если бы тесты запускают.
Да, об этом мы поговорим, ребят. Про те тесты, которые не запускаются, об этом мы поговорим. Удалить целый класс пакет пока нельзя. Это я тоже сделаю.
Это хорошие фич-реквесты, я их запомню. Еще интересная организация связка степов. Грубо говоря, одинаковые шаги в разных тестах.
Один тест, по сути, является степом в других тестах. На самом деле это можно делать через релейшн. но я говорю про это. То, что можно тесты вот так вот линковать, мне это кажется не очень хорошей идеей. Опять же, даже на большом проекте ребята сейчас очень сильно пищали.
Вы, кстати, в курсе, что тест-рейл выкатил переиспользуемые шаги. Я прям крайне рекомендую тем, кто пользуется тест-рейлом, посмотреть на эту фичу. Тест-рейл...
Как там? Reusable steps. Потому что мне тут недавно рассказывали про то, что в TestTrailer нет reusable steps, но вот они сейчас. Короче, они недавно выпустили последний релиз.
Как они? Shared steps. Да.
И они выпустили релиз, и у них наконец-то появился Shared steps. И мы с командой бросились... изучать вот эту фичу и все такие, короче, типа, ребята, надо вот эту вот шарик степы врубать и так далее.
Но проблема заключается в том, что вот я опять же говорю к организации ручных тестов, как я подхожу, что если у вас есть reusable степы, то это на самом деле очень плохая практика для вообще ведения тестовой документации. Я понимаю, что вам кажется, что авторизация это как бы, ну, типа там, вот же логин, пароль, короче, ну, типа, надо же, типа, вот эти шаги прям повторить, но на самом деле это... авторизация это самый примитивный и минимальный пример.
У нас просто пишется, что типа юзер, ну, типа там требования, что типа юзер авторизован. То есть мы там говорим, наличие такого-то, такой-то функциональности для авторизованного пользователя. И в команде вообще-то ни у кого не возникает проблемы с тем, чтобы понять, как авторизоваться.
Но я видел очень негативные примеры использования вот этих Shared Steps, потому что вот она выкатилась, и знаете, что я увидел? Что ручные тестировщики начали в Shared Steps закидывать проверки, и эти проверки дублировать в разных тестах. И это стало просто какая-то жесть.
Автоматизатор берет тест, который он будет автоматизировать, а у него там какой-то набор проверок, которые надо выполнить между шагом 3 и 4. Потому что мы как раз на этой странице находимся, и нам, как ручным тестировщикам, удобно сразу же тут и прокликать. Но это очень большой эфорт вносит в автоматизацию. Поэтому пока у меня отношение к Shared Step такое, что надо очень хорошо подумать, как сделать так, чтобы она не навредила этой фичам. Но, тем не менее, посмотрите, прикольный пост. Тест-трейлер молодцы, двигаются.
в нужном направлении. Ну и если вы делаете тест-кейсы как код, то у вас шаристепы есть из коробки, и мало того, вы даже можете параметры задавать для этих степов и так далее. То есть вы можете использовать один степ с разными параметрами.
На самом деле я больше за эту штуку топлю. Да, в tmfg тоже такое запилили недавно. В общем, ребята, я согласен.
То есть это, ну типа, да, да, окей, я согласен, то есть типа, что Это такая, короче, штука, которая сейчас там появляется. Мне радостно, что продукты эти темы добавляют. Шарит степы это шарит степы.
Окей, так, а у нас в чате есть какие-то вопросы? Я ничего не пропустил? Все, окей, поехали дальше.
Следующая проблема, с которой мы хотим поговорить, ребят, вот смотрите, у нас, типа, есть наши тесты. И когда приходит, например, какой-нибудь менеджер и разработчик, он смотрит сюда, и ему хочется понять, как эти тесты запустить. То есть, типа, Тёма, ты нам рассказал, тестовая документация есть. Отлично. А как мне тесты запустить?
Я хочу прям взять и запустить все тесты на Create, как я говорю. Давайте сделаем так. Я хочу взять и сделать вот так.
Раз, два, три, четыре. У меня, например... Я отрефакторил какие-то активные операции, мне надо проверить, что эти операции по выполнению криев всех сущностей, они работают. Я вот у себя выбрал вот так вот тесты и хочу их запустить.
Потому что мне неинтересно, где у нас тесты запускаются. GitLab это, GitHub это, Jenkins. То есть я вообще про это знать не хочу. Давайте сделаем с этим интеграцию.
Для этого нам надо зайти в Jobs. У меня тут Jenkins настроен, я его настрою очень быстро. Это просто надо сделать. Тут, в принципе, ничего не надо смотреть. Мне надо указать, что это браузер, вот это у нас хост, вот это у нас бранч.
Делаем submit. И то же самое мы делаем вот здесь. Сейчас, секундочку. Я говорю, что вот это браузер, вот это у нас хост, вот это вот бранч.
Мы эту штуку делаем для того, чтобы Allure передал вот эти параметры при запуске джобов. Как вы видите, у нас есть такая вкладочка Jobs, и Allure запоминает все джобы, которые когда-либо были запущены в GitLab. В GitLab я добавил еще вот такую штуку. Давайте зайдем в Files, GitLab CI, и будем считать, что у нас на вход приходят вот такие данные. Base URL, Browser Name, как вы видели.
Поэтому я их добавляю вот здесь. Первое, что я делаю, я говорю... Это будет GitLab. И нажимаю Submit.
И потом проверяю, что все хорошо. Вот это у меня произошло. Второе, что я делаю, если вы за мной повторяете сейчас, вам надо зайти в Members и добавить сюда комета. Вот этого бота. Он нужен для того, чтобы Allure мог запустить вашу GitLab джогу.
Даете ему мейнтейнер. Наверное, я дам самые лучшие права. Чтобы, ну, типа, вот. Вот после этого Allure сможет запускать ваш pipeline, и вы сможете запустить прямо с нашего стенда запустить тесты, которые у вас находятся здесь. Соответственно, дальше, как я и говорил, нам надо сюда передать какие-то параметры.
Для примера я буду использовать вот эти вот параметры. Base URL, то есть мы также его добавляем. Мы говорим, вот эта job, она с параметрами. Вот это у нас бранч.
Мы говорим, есть Base URL. Стандартный базуру пусть будет testing.github.com. И это у нас хост.
И еще один параметр добавляю. который называется Browser Name. Browser Name. По дефолту пусть у нас будет Firefox.
И это будет браузер. Все, Submit. Вот так вот мы сконфигурировали нашу джобу.
Как только вы сконфигурировали джобу вот таким вот образом, вы можете просто взять и запустить ваши тесты. Выбираете нужные вам тесты. Давайте на Create вот эти вот тестики запустим.
Выбираете окружение. Мы запустим на мастере. Хост у нас будет... А давайте вот gazing bug сделаем. https gazing bug github.com Он никак не используется.
Я просто хочу вам показать, что можно легко из Allure прям выбирать другое окружение. И тут мы типа сделаем Firefox. То есть вот такие вот значения. Так, давайте, кстати, не через эту.
Через эту даже не очень прикольно. Лучше прямо вот отсюда. Я люблю запускать тесты вот отсюда.
Давайте сделаем следующее. У нас возьмем вот тесты на issues вот так вот и запустим их. Тут даже будет интереснее. Первое, что мы сделаем, выберем environment, пусть это будет Opera.
Следующее мы сделаем host, пусть это будет, как я и говорил, HTTPS, ей zenbug, github.com. И бранчик выберем мастер. Делаем safe environment. И теперь смотрите прикол, мы переходим в jobs.
И Allure предлагает вам запустить эти тесты. То есть он сам за вас знает, какие тесты автоматизированы, а какие нет. То есть мало того, вы можете указывать параметры, с которыми эти тесты будут запускаться. Если вы наведете сюда, то вы увидите дефолтные параметры.
Вот здесь будут указаны конкретные параметры, с которыми ваш тест запустится. Ну и просто нажимаем Submit, и у вас делается запуск. Переходим в GitLab, переходим во вкладку CI-CD Pipelines.
И видим, что у нас запустилась наша джоба. То есть мы в алюрчике указали тесты, которые мы хотим запустить, и эти тесты прямо явно запустились в GitLab. Как происходит фильтрация тестов?
Переходим сюда и смотрим в GitLab. Фильтрация тестов происходит вот отсюда. Вот, собственно, в этот момент у нас запустятся ровно те тесты, которые были.
Я подробнее об этом, наверное, чуть позже расскажу, если кому-то будет интересно. А теперь давайте позапускаем другие тесты на Jenkins, которые нам быстро покажут, как наши тесты работают. Тесты на Create. Мы делаем Create, Create, Create, Create.
Делаем запуск. Делаем Environment. Давайте выберем браузер Chrome.
Host давайте вот такой вот. Branch Master. Делаем Save. Переходим в Джобы.
Как вы видите, Allure запомнил, что мы запускали что-то в Cucumber, а что-то в GitLab. Давайте поменяем вот эту джобу на JUnit 5. То есть я могу прямо в этот момент просто заменить джобу и сказать, что, типа, нет, вот эти тесты менять пока не в GitLab. Это очень удобно, когда вы переезжаете с Jenkins на GitLab, либо наоборот. Вы можете прямо контролировать, какие тесты где запустятся, и нажимаете Submit. Переходим на страницу ланчей.
Как вы видите, у нас тут появились иконочки. И перейдем в Jenkins. Где у нас Jenkins? Вот.
И смотрите, вот у нас запустились две джобы. Вот кукумбер и вот это вот. Причем, заметьте, параметры, с которыми они запустились.
Вот тут вот параметры. У нас хром, сам хост и мастер. И второе, давайте посмотрим тоже джобу, с которыми она запустилась. Хром, хост, мастер.
То есть, грубо говоря, у вас реально очень легко запускаются тесты буквально в два клика. Блин, что-то у нас тут тесты попадали. Какой-то косяк, наверное.
Давайте посмотрим, что у нас за фейлит-тесты. Смотрим фейлит-тесты. Блин, что-то мне лень смотреть эти тестики. Давайте-ка их перезапустим. Нажимаем rerun, нажимаем submit.
И зацените, Allure сам понимает, какую джобу надо запустить. И он запустит ровно ту джобу с теми параметрами, которые были выбраны. Это очень крутая фича, она работает с двух сторон. То есть она типа... если вы запускаете тесты не из Allure, мы сейчас про это поговорим, то она тоже будет работать.
Allure, так как он знает о всех джобах, о тестах, которые в них запускались, и о параметрах, то он умеет перезапускать упавшие тесты ровно на том окружении, на котором у вас тесты запускались. И за счет этого у вас получаются все тесты, и вот у нас уже один тест упал. То есть у нас тесты поклеились, как вы видите, и у нас уже один тестик упал.
Давайте его добьем тогда. Как раз я рассказывал. И вот эта функциональность позволяет вам абстрагироваться от автоматизации. Вот эту фичу очень любят менеджеры, ручные тестировщики и так далее, потому что вам уже становится неважно, какие у вас тесты есть, в каком CI они запускаются и так далее.
Вы начинаете оперировать с этой системой, как будто бы у вас все есть ручные тесты. Ну, кстати, вот, фейлип исчезли. Вот, теперь у нас реально зеленый пак. полностью зеленых тестов, и при этом я понятия не имею, какие джобы у меня запускаются.
Если у меня есть там желание посмотреть, я могу посмотреть, но при этом нет необходимости в эту штуку погружаться. Кстати, вот, у нас запустились тесты, которые я запустил наконец-то из GitLab. Давайте посмотрим в pipeline депозитории.
Так, вот, в pipeline. И удостоверимся, что они запустились ровно там, где я просил. Сюда вот заходим, сюда.
И вот здесь вот у меня, смотрите, у меня распечатывается. Я запускаю вот на таком окружении. То есть Allure вот в этот момент, он передал информацию, вот эту вот, конкретно в GitLab, и у вас произошел запуск тестов. Окей, с автоматическими тестами понятно, но мы сейчас к ним еще вернемся.
Давайте посмотрим, что у нас с ручными тестами. Мы можем взять, ну, давайте заодно сразу же добавим туда и автоматических тестов. Делаем запуск. Джоба, я говорю, что лучше не гитлабовскую, а вот эту вот кукумберовскую, ой, это дженкинсовскую. Выказываю окружение, на котором мы будем.
Браузер у нас будет хром, хост у нас будет прот и вот это вот мастер. Сохраняем окружение, нажимаем submit. У нас появляется такой вот ланчик. Мы сюда переходим, мы сразу же смотрим тесты мануальные, потому что нам нужны только мануальные тесты и смотрим наш тестик. Нажимаем кнопочку Assign to me.
Этот тестик ассайнится на меня. И начинаем просто по очереди проходить. Мы пишем раз, потом два, вот это сделали, вот это сделали, потом вот это, потом реально сравнили, что все хорошо, потом разлогинились и нажимаем Passed.
Таким образом у нас получается интеграция с ручным тестированием тоже. Кстати, если мы отожмем Manual, то мы увидим, что все остальные... автоматические тесты к нам тоже приехали, и это на самом деле очень круто, потому что вы можете не ждать окончания.
Вот с TestTrail я знаю, что есть такая проблема, что когда кто-то пишет интеграцию с TestTrail, то там не очень понятно, какие тесты реально автоматизированы, а какие тесты ручные. И приходится сначала дожидаться, пока джоба пройдет, а потом проходить все остальное оставшееся, так называемое. А Allure эту проблему решает. Кроме того, у вас есть информация по поводу того, сколько по времени у вас выполнялись, ну, типа, каждые шаги, и видно, что вот этот тест мы выполнили за 21 секунду. В Allure это есть, типа, информация внутри.
Также можно посмотреть, как тесты выполнялись на таймлайне. Вот информация про автотесты, которые у нас бежали. Но это фейковые тесты, поэтому они выглядят вот так вот.
И есть информация у пользователя админа, типа, вот он выполнял тесты вот таким вот образом. Это что касается вот такого точечного ручного тестирования. То есть пока вот это все позакрываем, давайте еще запустим тестики. Так, давайте я отключу вот эту джобу, пока чтобы она меня не мониторила.
Если вы не хотите, чтобы эта джоба использовалась для запуска, отключайте вот этот атрибут, она не будет использоваться для запуска, и можно после этого запускать тесты. Кстати, интересно, оно работает? Я что-то забыл уже. Может, оно и не работает.
Выберем вот эту тему. Да, нет, все хорошо. Видите, уже выбира��тся сразу же другая джоба.
Так, нам нужно запустить все тесты, поэтому давайте просто все, но ручные не будем запускать. Делаем run, добавляем окружение, Firefox, prod, master, save. И опять же, очень прикольная фича, смотрите какая. Я нажимаю запуск второго инвайрмента, выбираю prod.
выбираю браузер оперу и выбираю branch master теперь у меня тестов будет в два раза больше и делаю сад нет у нас запустились тесты и allure запустит 4 джоба и тестов будет в два раза больше таким образом вы можете в один запуск мержит несколько разных инварах если мы посмотрим сюда то мы увидим что у нас одна джоба стартанула Вторая в процессе. Для этого, для... У Кумпера то же самое.
Одна джоба стартанула, вторая была в процессе. И сейчас у нас смерзнутся результаты нескольких инвайрментов в один запуск. То есть у нас сейчас будет сборная солянка. И здесь надо некоторые вещи показать.
Теперь зацените, насколько удобно это все прикольно сделано, потому что когда мы делаем фейли-тесты, у нас тут уже есть окружение. И если я сейчас выберу перезапустить все фейли-тесты, то я сам уже даже не знаю, типа вот это упало на Firefox и на Opera, а вот это упало только на Opera, а вот это упало на Opera, а вот это и на Opera, и на Firefox. И я уже в голове не удержу всю вот эту вот механику, типа кто где запускался. А Allure удержит.
Мы нажимаем Rerun, выбираем Submit, и у нас все тесты перезапускаются еще по одному разу. И получается, еще запускается, грубо говоря, наверное, 4 джобы. Я не знаю, сколько их запустится, потому что я в голове не могу удержать, что я хотел перезапустить. А, 3 джобы запустилось. Заметьте, что, видимо, одна из джоб, которая здесь была, она прошла полностью успешно.
А Люра это понял и перезапустил только те джобы, в которых были какие-то проблемы. Дальше у нас остался всего лишь один сломанный тест. И давайте я покажу еще одну фичу, которая довольно прикольная, которую можно использовать.
Этот тест можно превратить в ручную. Такое бывает, что когда у вас падает, допустим, там, Selenium, либо, ну, типа, падает инфраструктура, некоторые автотесты нельзя перепройти. Либо, например, этот автотест сломался.
То есть вы видите, что он сломался, вы идете сюда, говорите, этот тест outdated. Потом переходите обратно, но он сломался посередине. То есть он, типа, там...
грубо говоря, пытался нажать на кнопку, эта кнопка не нажимается, но в целом мы функциональность руками можем пройти, потому что мы можем через другую кнопку к этой функциональности попасть. Мы нажимаем rerun, у вас автоматический тест, он превращается в ручной тест. И вы можете просто вместо того, чтобы проходить этот тест в автоматическом режиме, вы можете пройти этот тест в ручном режиме. Мало того, результат автоматического теста не потеряется, у вас это все, этот тест фейлит, он навсегда останется в истории как фейлит, но при этом вы можете предоставить результат ручного тестирования.
И это, на самом деле, довольно крутая фича, потому что она позволяет вам... Кстати, вот у меня еще есть один автоматический тест как раз для моего второго примера. И у вас этот тест будет зеленый.
И вторая штука, которая есть, вы можете написать для этого теста ручной сценарий. Давайте это сделаем. Как мы тогда говорили, вытягиваем сценарий, пишем, вот это мы уже не будем делать, вот это говорим, открываем страницу репозиторий, потом второе, создаем pull-request, создаем PR с бранча, потом проверяем, что он существует. бранча существует. И вот это тоже удаляем.
Делаем submit. Переходим в его последнюю историю. Делаем rerun.
И у вас появляется ручной сценарий вместо автоматического. То есть, грубо говоря, если у вас, допустим, сейчас еще не так хорошо развита документация, и у вас там вся информация в тестах еще не совсем в актуальном состоянии, то вы можете легко использовать ручной сценарий, а не автоматический, для того, чтобы проходить ваши тесты. Это такая вот штука. Тут я еще хочу показать. Я уверен, что сейчас найдутся ребята, которые уже очень хорошо и давно вкладываются в именно CI, то есть вот в эти вот системы, короче, и которые на самом деле все процессы давно построили вокруг пайплайнов.
И они меня спросят, типа, Тёма, а как вот нам все то же самое сделать? То есть ты тут выбираешь тестики, это все требует ручных задач, а как нам типа просто все в CI положить? Для этого все в Allure есть.
Вы добавляете вот такой вот фильтр, вот такой вот, with Allure Test Plan, и тут написано status равно active. Давайте я подробнее про это расскажу. У нас есть язык запросов, который там, сейчас кинут ссылку на документацию в канал, который выглядит таким вот образом.
Мы пишем, секундочку, мы пишем, допустим, status равно active. Овнер равно Ярошенкае. Роле Овнер. Так, давайте еще раз.
Что так? Роле Овнер. А, таких тестов нету.
Секундочку, что-то пошло не так в роли. Owner равно... Странно. Сейчас я разберусь. Давайте так.
And... У нас нету вот этой вот подсветки пока, и из-за этого... Есть некоторые ограничения, которые надо использовать. Нет, что-то как бы ему не нравится.
Что-то ему не нравится с этим. Не могу сказать, что. Должно работать, но оно не работает. Почему?
Ну, ладно, бывают проблемы. Идея заключается... А если просто вот так вот сделать? Что-то ему не нравится именно вот этого штука.
Ладно. С этим разберусь. Будем считать, что это нам в копилку, короче, таких небольших сегодняшних факапов, но статус равно active. Почему вот это работает?
Ладно, будем считать, что у нас есть некоторые тесты, которые есть в активном статусе. И у нас есть проблема. Проблема заключается в том, что у нас вот этот pipeline, он находится у разработки, и мы к нему никакого отношения не имеем. И давайте запустим эти тесты.
Мы запустили наши тесты. Они сейчас приедут вот сюда вот. Сейчас к нам приедут тесты. Теперь у нас идет вся работа с тестами со стороны этого пайтлайна. То есть, грубо говоря, представим, что мы руками из Allure ничего не запускаем.
Что будет происходить? У нас приехали тесты. Блин, они еще и прошли.
Давай предположим, что вот этот тест, он у нас упал. Вот так вот он у нас упал по какой-то причине. Мы посмотрели, почему он упал, и нам не понравилось, что он упал.
Мы делаем его outdated, тест 246. Переходим обратно, и этот тест outdated. Говорим, что, типа, ребята, это у нас ошибка, она больше воспроизводиться не будет. И когда мы второй раз запустим наши тесты, Запускаем наши тесты.
Мы запомнили, что тест называется Close New Issue 11.246. Вот в этом запуске его не будет, потому что он не попадет под вот этот вот фильтр. Под вот этот фильтр он не попадет.
Таким образом вы можете устраивать карантин тестов. То есть, грубо говоря, у вас тесты постоянно запускаются, и у каждого разработчика в пайтлайне, в том числе в GitLab так тоже можно. У вас просто прописаны фильтры тестов, которые надо запускать.
Например, можно написать status.active and tag равно critical. Я говорю, у нас почему-то вот эта скрытая моя песочница по query сломалась. Меня это печалит. Я пробую сейчас еще раз оживить.
status равно active and tag равно critical. Нет, что-то ему не нравится. Окей. А может быть из...
Нет, что-то ему где-то не нравится, оставим его тогда пока в покое. Соответственно, и у вас вот эта вот штука, она находится на стороне ваших пайтлайнов, и заметьте, что тут запустилось уже меньше тестов. То есть до этого запустилось 8 тестов, а теперь у нас 6 тестов. При этом мы можем легко посмотреть тесты, которые у нас outdated, и заняться их исправлением. То есть это типа своеобразный карантин тестов.
Вы выключаете тесты, они не попадают в разработческие пайплайны, разработчики перестают вас терроризировать, потому что отчего у вас тесты постоянно падают и так далее. И при этом Allure сигнализирует о том, что, ребята, у вас есть некоторые outdated тесты, с которыми надо поработать. Либо вы их совсем выключаете, либо как-то с ними поработать.
Ну и прикольно, например, отсюда эти outdated тесты запустить, например, после того, как вы хотите поправить код. и хотите проверить, заработал этот код или нет. И еще один пункт уже совсем.
Это наборы тестов. Вы можете взять некоторые тесты, например, там Close. И давайте вот это Close, вот эти вот тесты. И с ними сделать тест-план.
Тесты на Close. У вас появляются тесты на Close. Видно, кто будет выполнять эти тесты.
Например, если бы у вас тут... были мануальные тесты, то вы тоже их увидели. Вот тут будет список тестов, которые у вас есть. Здесь будут параметры, с которыми эти тесты запускаете.
И теперь вместо того, вот у вас есть набор этих тестов, и теперь вы можете просто брать и вот так вот создавать тестовый набор. То есть тут вот говорит мастер, прод и хром. И в один клик запускать. Таким образом у вас получается, типа, некоторая группа тестов, там, тесты на картинке, тесты, там, на авторизацию, их можно разбить на тестовые наборы и запускать их по кусочкам. Кроме того, то же самое можно сделать со стороны, ну, типа, этого Jenkins.
То есть в этот фильтр можно сказать, запусти только те тесты, которые есть в тестовом наборе номер один. Запусти только те тесты, которые есть в тестовом наборе номер два. Таким образом, у вас могут быть автоматические пайплайны, которые запускают только выбранные вами тесты.
Окей, давайте на этом закончим и посмотрим на вопросы. Итак, я тут рассказал следующее. Вам не надо особо понимать, как у вас устроены джобы, Jenkins, Tilt City и так далее, чтобы запускать тесты. Вы просто выбираете тесты, указываете окружение, на котором вы хотите тесты запустить, и они запускаются. Мы также умеем перезапускать вот эти вот тесты, то есть вы можете выбрать тесты уже в запуске в конкретном, это экономит кучу времени, когда вам надо просто перезапустить уже какие-то конкретные тесты, и это тоже хорошо работает и довольно удобно.
Итак, давайте читаем вопросы. Насколько я понял, Allure пока по расписанию не делает. Вот по расписанию не делает, но для этого можно сделать, как я уже сказал, следующее, то есть мы можем сконфигурировать вот этот вот.
мы можем Дженкинс заставить периодически гонять тесты и указать набор тестов, с которыми мы это гоняем. То есть, грубо говоря, сейчас это решается так со стороны CI. То есть CI отвечает за расписание, а в Алюре хранятся информации про те тесты, которые надо запускать.
Насколько я понял, сейчас тоже можно, но надо как-то хитро. Уже рассказал как. Запуск будет инсценицирован со стороны CI. Про фильтрацию тестов интересно, как устроено.
На примере тест-нг запускается ттт, который указывается в тест-нг.xml. И с какими ранами реализована фича выбранных тестов. На самом деле с тест-нг, JUnit 5, JUnit 4, Cucumber 6, Cucumber 4, PyTest, JavaScript Test, Robot Framework и еще какие-то тесты, Jest и так далее уже реализованы. На самом деле у нас реализовано довольно много фреймворков запуска конкретных тестов.
И вы можете просто попробовать ее у себя. Если она не будет реализована с нашей стороны, то мы, скорее всего, возьмем это в приоритет. То есть, типа, если у вас есть какой-то фреймворк, для которого это надо сделать, с большой вероятностью мы сделаем это довольно быстро, потому что у нас вся механика уже отработана, и нам надо просто, ну, типа, там, конкретно экстеншен написать, а обычно они пишутся недолго.
Стоп, есть сущность результата как в лаке. Да, если тест флакает, он будет выглядеть примерно вот так вот. Сейчас я перезапущу вот этот тест.
Давайте я там rerun и pass it. У нас есть те тесты, которые перезапускаются, они выглядят, ну, типа, вот мы видим тест, у него, короче, есть fail, забыл, как оно тут выглядит, где-то тут был какой-то фильтр. Короче, ладно, вот. На самом деле самый простой способ посмотреть вот здесь вот.
Тут в каждом запуске у вас есть прямо конкретный список всех тестов, которые перезапускались. И в данном случае можно сразу же рассмотреть и понять причину, по которой этот тест перезапускался. Это все собрано удобно в одном виджете, в одном месте.
А насколько стоит ваш продукт, как распространяется? Продукт стоит 30 долларов за человека в месяц. Это примерно как тест рейл, на самом деле.
По-моему, тест рейл даже дороже. У нас очень большое преимущество, что у нас read-only аккаунты, они бесплатные. Поэтому вы покупаете только на людей, которые пользуются фичами, а менеджеры, разработчики и все остальные, они очень счастливы, потому что они наконец-то видят это прозрачно, как устроено ваше тестирование.
Так, теперь я в чатик пойду. А в чатике пока нет вопросов. Тогда отлично, поехали. А, или есть.
Егор, поможешь мне? Есть какие-то вопросы, на которые я этот... Ну, наверное, если ты вот этот про кукумбер сейчас сможешь ответить. Остальных, наверное, нет. Да, я понял.
Про кукумбер у нас нет пока маппинга степов кукумберных на степы валюри. То есть, грубо говоря, сейчас надо писать... Короче, давайте так.
Нет маппинга, который позволяет валюри держать степы кукумбера, и чтобы ручной тестировщик эти степы набирал. И насколько я вообще кукумбер знаю, на самом деле это довольно порочная практика, потому что в этот момент у человека... ему сложно понять контекст.
Суть в том, что на маленьком проекте это работает, а на большом проекте работать это не будет. Когда у тебя будет уже несколько сотен степов, выбрать из них нужный будет сложно. Поэтому пусть он пишет своими словами, а ты потом, когда экспортируешь эту идею, вставишь туда нужные степы. Поэтому этой фичи у нас нет. И я пока сомневаюсь про то, что она прям нужна.
Потому что для небольших проектов она может. Ну, типа быть, а для более больших проектов уже тяжело. Окей, поехали дальше.
Теперь мне надо запустить наши тесты еще раз. Сделаем это отсюда. Раз и два.
И давайте посмотрим сейчас некоторую проблематику. Смотрите, у нас на всем пути запускались тесты. И это были одни и те же ошибки.
Я просто это знаю, потому что я их писал. Вот эта ошибка. Она, видите, встречается два раза.
Кстати, Allure показывает similar failures. Вы можете нажать кнопочку, и он вам покажет вот такую вот матрицу, в которой будет видно, что это одна и та же ошибка. Это евристика.
Она работает не по полному совпадению, а по евристике. Поэтому у вас similar failures будет работать правильно. Зацените эту фишку обязательно.
Но какая проблема? Вот у меня есть одни и те же ошибки. Постоянно.
Это 100% одни и те же ошибки. И... И какая проблема есть, вот я тоже сейчас работал на проекте, когда, точнее, не работал, я там сейчас есть, но когда я туда пришел, была проблема у руководства тестировщиков понять вообще, а что падает-то.
Ну, типа, вот что сейчас сломано, на что надо обратить внимание. И эту проблему никак не решить. Приходится делать митинги. На утренних митингах тестировщики-автоматизаторы говорят, блин, ну там опять что-то там тестинг тупит.
там еще, и вот это все, оно слишком многословно и слишком много времени занимает. Поэтому мы сделали дефекты. И сейчас покажу, как они работают.
Вы берете вот эту вот штуку и видите элемент not found by expats. Говорите link defect и пишите отсутствует, отсутствует, так, отсутствует кнопка, давай, давай, короче, Пропала кнопка удаления issue. После этого создаем automation rule. Вот это вот надо просто указать название правила.
Вставляем сюда наш RegExp и пишем вот такую вот штучечку. Она очень небольшая. Для этого, конечно, надо знать RegExp.
Но, тем не менее, ее написать довольно просто. Проверяем, какие у нас результаты сюда попали и нажимаем Link Defect. Потом идем в следующую issue. Можно посмотреть Result Resolution. Для этого есть фильтр.
И пишем WebDriver Not Reachable. Сразу же создаем. У нас получается, что не работает. Cluster Selenium Off. Делаем так.
Create Automation Rule. Message. И сюда вставляем. Видим, что у нас два теста упало с этой ошибкой. делаем link дефект все после этого заходим на страницу overview и видим что у нас две ошибки всего лишь есть запуске в одной два теста в другой один тест давайте теперь запустим наши тесты еще раз и посмотрим теперь как этот механизм отработает Смотрите, у нас появилась информация про тесты, и как вы видите, у меня один тест автоматически разметился, а второй тест мне надо разобрать.
Я перехожу в него, и у меня говорится тут, типа, изменился какой-то тайтл. Я пишу, изменился тайтл виджета создания тикета. Добавляю к нему такое же правило, проверяю, точнее...
Вот так вот тут напишу message. Мы сейчас поймем, зачем я вот это пишу. И вот здесь вот я проверяю, что у меня RegEx подработал правильно.
И нажимаю link defect. Потом перехожу сюда и вижу, что у меня вот ошибки. Ну и давайте третий раз запустим.
У меня всего лишь три типа ошибки. И, соответственно, теперь я пока немножко похилософствую. С помощью вот этой фичи вы можете сократить время на разбор ваших автотестов практически до минимума.
На моем опыте это где-то 80% тестов вам не надо будет разбирать. У вас постоянно будут отрабатывать правила авторитизации, и самое крутое, что вы будете разбирать только новые ошибки. То есть старые ошибки будут разбираться с помощью Allure, и Allure это все будет контролировать, а новые ошибки вам надо будет один раз разметить руками.
Ну и, соответственно, пример вот этого подхода, он ровно такой вот, как я показал. То есть у нас получается, что... У нас запускаются ночью все тесты обязательно.
Это как бы, ну, типа, это именно прогревание. То есть это не то, что типа там, а чего вы там на pull-request тесты не запускаете? Нет, запускаем.
Но ночью запускаются обязательно все тесты. И, соответственно, есть утренний разбор, на котором мы смотрим, мало ли какие ошибки новые в тестах появились. Есть, соответственно, разработчик, который расставляет эффекты над новыми падениями. И потом в течение дня...
Когда у нас запускаются тесты на разных pull-request, на разных тестовых средах и так далее, эти ошибки уже никого не аноят. И это на самом деле реально экономит кучу времени. Например, сейчас мы заходим сюда и видим, короче, вот у нас одно падение, один дефект. Смотрим, так, а что произошло-то? Пропала кнопка удаления еще.
Ну, все понятно. Также есть вот такой вот виджет, на котором мы видим вот такие вот данные. Нам надо позакрывать наши результаты.
Есть виджет, на котором мы видим вот такие вот данные, и мы видим, когда у нас воспроизводился дефект. Вот этот дефект воспроизводился 3 минуты назад вот в этом вот ланче. Вот этот вот дефект воспроизводился 2 минуты назад вот в этом вот ланче.
И, соответственно, у вас есть информация под контролем полностью по поводу любого такого теста. Например, мы можем сразу же перейти в этот test case и сказать, что этот тест outdated. Все.
После этого он, например, не будет у нас. не как на Sonos. И у нас получается, что мы видим, что это outdated.
Вот это description обычно используется для того, чтобы сделать описание. Эта ошибка связана с тем-то, и ее нужно править в тестах. И, соответственно, у каждого такого description есть описание, и как теперь устроена у нас работа.
Теперь у нас первая штука. Мы смотрим все ланчи, в которых не проставлены дефекты. Это самое первое условие, чтобы там были прямо четко у каждого результата тестов, у каждого падения должна быть проставлена причина падения, должна быть ясна.
Менеджеры смотрят на то, что здесь все понятно, и потом мы выбираем самые худшие падения и чиним их в первую очередь. Например, если у вас проблема есть с селениумом. вам инфраструктура, которая занимается селением, она вам не верит, то вы просто берете, приносите ему вот этот вот дефект и говорите, чуваки, вот смотрите, вот у нас информация полностью вся по дефектам и вот у нас реально это нас оноит, потому что посмотрите и показывайте насколько это реально проблема вас беспокоит и тут есть вся необходимая статистика и вся необходимая информация. Это можно линковать с ишьюсами.
То есть у нас тут, например, можно взять и слинковать ее с issue, которая у нас в Jira Cloud, либо, например, слинковать issue, давайте я слинкую ее, link issue с Jira сервером. Вот это вот. Нет, давайте у нас...
Ну, пусть будет так, ладно, давайте не будем выбирать. Вот. Мы можем перейти сюда и посмотреть на эту задачку у себя.
И можем сделать так. Мы делаем in progress, она здесь перевозится в in progress. Я сделаю тут done, и вот здесь вот эта задачка переместится в done. И вот видите, у нас дефект закроется.
А дефект закроется, это означает, что он больше не будет привязываться. Давайте покажу, как это будет выглядеть. Я надеюсь, на селение он упадет, но вы мне поверите.
просто, что как только у вас пища закрывается, у вас дефекты перестают привязываться вот здесь. И, соответственно, он опять упадет и опять вам покажет, ну, да, не получилось. Ладно, несколько раз запущу, пока может быть повезет.
Он не будет привязываться. И, соответственно, это очень удобно, потому что как только у вас жира закроется, у вас дефект автоматически закроется. И, соответственно, если у вас он где-то еще воспроизводится...
то вы сразу увидите этот дефект в Unresolved, и как только вы его там увидите, вы сразу поймете, что, типа, «Эй, разработчики, погодите, а что это вы тут назакрывали, хотя у нас, как бы, ну, там, проблемы еще есть? » Так, тут, вот тут вот, может быть, он вас… Вот, смотрите. Вот, он отвалился.
Видите, веб-драйвер not reachable. И он уже без дефекта. То есть если мы, типа, vizout resolution сделаем. Но еще прикольная штука. Этот аллюр подсказывает его вот здесь вот.
То есть, по сути, можно как бы сразу же его выбрать. И когда вы сделаете линейный дефект, он его переоткроет. Единственное, сейчас не сделано так, чтобы он переоткрывал задачу, потому что это довольно сложная штука, и ее надо переоткрыть руками. Потому что, ну, типа... Jira управлять на самом деле не так просто.
Там надо кучу конфигураций сделать, потому что надо понимать, в каком новом статусе должна быть задача. То есть ее надо переоткрывать. Надо сконфигурировать, в какой статус переводить задачу при переоткрытии дефекта. Но в целом в этом направлении мы тоже работаем.
Итак, в этом блоке я рассказал следующее. На самом деле на разбор автотестов входит очень много времени. И для того, чтобы его не тратить и заниматься полезными делами, существует механизм дефектов. Вы создаете дефекты, вы привязываете к ним правила автоматизации, которые выглядят очень просто. Я вот еще раз повторю, что они как бы очень простые, не надо сильно вымудривать.
И после этого эти правила автоматизации начинают разбирать ваши тесты за вас. Вы можете посмотреть все дефекты в одном месте, вы можете синхронизировать эти дефекты с Jira issue и... Вместо того, чтобы заниматься непонятной, кропотливой работой по анализу результата тестов, заниматься более полезной деятельностью, например, показывать разработчикам, как можно жить лучше.
Итак, есть какие-то вопросы здесь? Вопрос по стандартным отчетам. Посмотри в этом в чате Зума. Зума? Да.
Максим Яковлевич. Да, что со стандартными отчетами матрицы покрытия, общей статистикой, багов и так далее. Да, это сейчас вот ровно мы к этому подходим, это следующий, ну типа вот следующий блок ровно про это.
А есть линковка issue-linkов и stostops в идее, есть линковка issue-linkов. Ну да, на самом деле этот линковать, да, можно с Jira линковать, у нас тоже это проработано, я даже сейчас быстренько это покажу. Ну, смотрите, можно прямо в тестах писать вот такие вот... вот такую вот штуку jira issue прям сразу же мы это тоже у себя довольно активно используем и вот эта штука она довольно прикольно работает смотрите вы линкуете вот так вот тест то есть вы при написании теста сразу проставляете к какой issue он относится потом заходите в настройки тут есть такая issues и делайте так jira и указывайте какой у вас Jira сервер будет использоваться.
Ну, например, давайте Jira сервер. Делаем submit и теперь давайте запустим наши тесты. Заметьте, что до этого, вот мы и запускали наши тесты, тут никакой привязки к Jira не было.
Ну, то есть тут нет сейчас никакой привязки. Я сделал конфигурацию и теперь давайте посмотрим, что из этого получится. Да, заходим сюда, видим дерево, видим, короче, здесь, и смотрите, у нас появились вот такие красивые ссылочки.
Они приехали вот прямо отсюда. И если мы сейчас сделаем так и перейдем вот сюда вот, и тут введем пароль от Allura, нажмем Sign Up, то мы увидим наши тестики, которые привязаны к каждой из этих issues. И все это, опять же, происходит автоматически. Это очень круто. И теперь вот эту тему я периодически показываю.
Она, на самом деле, очень крутая. Смотрите. Потом можно сделать вот так вот.
Берем, пишем AE1. Увидим все тесты на AE1. Делаем запуск. Берем Environment. Делаем Firefox.
Вот это вот. Мастер. Делаем issue.
AE1. Вот это вот. Safe Environment.
запуск. Переходим в AE1 и смотрите, у нас есть тут четыре теста и ровно эти четыре теста запустились в этом запуске. И это реально очень удобно, потому что вы очень быстро можете интегрироваться с Jira и запускать ровно те тесты, которые связаны с конкретным issue.
Мы работаем над улучшением плагина и скоро вот эта логика по запуску тестов. она будет находиться прямо в Jira. То есть вам не надо будет покидать пределы Jira, чтобы запустить вот эти четыре автотеста и превратить их вот в такой вот запуск.
То есть это будет работать полностью автоматически. Потом следующий заходит, смотрите, как круто. Кто-то скажет типа, Тёма, а почему тестов 4, а результатов 5?
Потому что вот этот тест у нас параметризованный, и мы можем в этом убедиться. Мы заходим сюда и видим, что у нас тест запретился с одним параметром и со вторым параметром. И таким образом это все делается очень удобно и наглядно. Про Jira, надеюсь, ответил.
Из IDE в TestOps issue сортируются, это хорошо. А из TestOps VDE их можно портировать на все упавшие тесты? Из TestOps VDE... Из TestOps VDE. Сейчас проверим.
Вроде можно. Давайте посмотрим. Сейчас я не очень понимаю сценария, но давайте посмотрим. Если вы возьмете тест, у которого проставлено issue, и создадите новый тест, и сделаете импорт.
то он простаем вам Jira issue. И у вас могут быть вопросы, а можно ли делать какую-то импорт каких-то конкретных полей в конкретном цикле лунного света и так далее. Все это можно делать, просто у нас не так много, ну, типа, мы не так много запросов еще обработали, но если у вас есть какие-то конкретные примеры, то, чего не хватает в Алюре, то пишите нам, потому что механика работает, а вокруг этого накрутить уже какую-то конкретику на самом деле не так сложно.
Так что оно работает. Можно прокидывать, синхронизировать и в одну сторону, и в другую сторону. Окей, и давайте уже к самому вкусному пункту перейдем. Это про менеджеров и аналитику.
У нас есть дашборды, и давайте на них посмотрим. Делаем automation dashboard, и по нему делаем следующее. Давайте посмотрим, насколько у нас все тесты стабильные. Выбираем Launch Analytics, Average Success Rate, тут пишем True и делаем так вот.
Вот мы видим, насколько стабильны у нас тесты. 89% стабильности. Делаем клон и посмотрим, насколько стабильны у нас опишенные тесты. P-Tests.
Вот, делаем Submit и смотрим. А пишные тесты у нас проходят с вероятностью единицы. Но это у меня фейковые данные, поэтому проходит и проходит.
И давайте посмотрим UI-ные тесты. У меня таких тестов 10. И вот у нас UI-ные тесты. И они проходят у нас с вероятностью 81%.
А что у нас по времени выполнения тестов? Выбираем duration. И тут пишем dur. 30 миллисекунд. В среднем как они выполняются?
DUR. Тут пишем DUR. Одну секунду.
Ну и понятно, кто медленно выполняется. Тут, наверное, я сейчас, ну, типа, DUR. Вот. У нас, типа, тест выполняется где-то одну секунду. А давайте посмотрим, какие тесты самые плохие.
Давайте так сделаем. Clone. Делаем Top Test Cases. Выбираем Success Rate.
и смотрим у нас есть самый плохой тест это удаление exist user потому что он типа 66 процентов а давайте посмотрим по этому по тоже топ сделаем по метрике по метрике duration вот так вот хоп и смотрим у нас самый плохой тест который этот идет это 21 и это у нас ручной тест это на самом деле плохо давайте посмотрим только для мануальная делаем вот так вот а сделаем отдельный дашборд дашборд и на него выведем делаем Берем Top Test Cases, метрика Duration, Automation равно False. Окей, и вот у нас появляется топ самых медленных тестов для ручного тестирования. Вот у нас появляются, ну, типа, вот эти вот графики надо перемешать. Вот, и так, нет, вот так вот.
Вот, и, короче, у нас получается вот такая вот... картина то есть вы можете вот эти вот метрики довольно легко делать мало того заметьте что я использую два разных набора посмотрите у меня тест это запускались постоянно в одной и той же джобби то есть у меня не было двух разных джоб одна для опишных тестов другая для веб-тестов а allure при этом умеет доставать информацию про раз тесты независимо от того, в каких джобах они запускались. То есть проблема, например, Tool of, вот даже если взять Allure Report, что там можно собрать статистику только по конкретным запускам. То есть у вас есть Jenkins, конкретная джоба, и у вас, типа, вот в рамках нее будет аналитика. Но там нельзя сделать аналитику кросс-джоб.
А для менеджеров не важно, что у вас есть какая-то конкретная джоба. Для менеджеров важно, что, типа, есть веб-тесты. и им охота узнать, как у нас дела обстоят с веб-тестами, грубо говоря, вообще, в целом. Также я использую Users.
Обычно вот такой вот дашборд я делаю. Делаю rschenk-am, делаю task-case-pychart, by-status, тут пишу role owner равно rschenk-am. У меня вот 10 тестов. Потом пишу, такую же делаю эту штуку, пишу buy-off и тут делаю buy-off. Раз.
Вот у меня количество тестов у каждого человека. Потом я беру, например, и делаю так, и пишу top test cases метрика duration. Это мои самые...
плохие тесты, которые я условно говоря написал. И второе, беру и пишу success rate. Надо его сдвинуть. Вот.
И то же самое можно сделать, например, по buy clone. buy buy Так, вот. И давайте посмотрим клон с Accessorate. Вот.
И у меня получается вот такая вот картиночка, на которой я вижу сразу же все проблемные места. То есть я типа по команде сразу же понимаю, насколько у кого... Ну, то есть первое, что я вижу, например, что у господина Ярошенко есть тесты, которые outdated. Ему бы надо этим...
заняться как-то в первую очередь. Второе, я вижу, что, типа, у господина Ярошенко есть какие-то проблемы с аксесс-рейтами. По времени выполнения у него вроде как все неплохо, но как бы, ну, как бы тут, окей.
И, например, там, Артему я дам задачи, которые будут себя включать, скорее всего, рефакторинг тестов, потому что очевидно, что, типа, вот, тесты двух сотрудников и у одного, типа, какие-то не очень тесты, а у второго, типа, вполне себе прекрасные тесты. И, например, Диме можно дать задачи по поводу написания новых тестов, а Артему надо бы немножко подумать над тем, как тесты делать. Что по поводу coverage?
У нас есть такой виджет, который показывает coverage. Это называется 3Map. Вы можете выбрать способ группировки и какие-то тест-кейсы, но он покажет вам такую картину. Как это работает? Мы видим, что авторизация у нас вообще не покрыта.
milestones покрыта, лейблы покрыты и так далее. Давайте заведем туда ручных кейсов. Открываем дерево, ручной тест.
Куда-нибудь сюда заведем ручной тест и куда-нибудь вот сюда вот еще парочку ручной и еще один. Переходим в дашборды, в coverage. И смотрим.
Вот у нас матрица покрытия. То есть мы видим, что у нас issues, ну, типа, так, нормально покрыто. MailStorms вообще хорошо покрыто. Labels не очень. Авторизация вообще никак не покрыта, ну, в смысле, автоматическими тестами.
И pull-requests покрыты, ну, типа, так себе. И мы можем потом переместиться внутрь сюда и увидеть, что у нас создание pull-requests покрыто очень хорошо, а закрытие pull-requests покрыто не очень хорошо. Ну, и, соответственно, мы можем зайти вот сюда.
и посмотреть то же самое. То есть у нас закрытие покрыто хорошо, а остальное покрыто не очень хорошо. И еще Stands, Stages. Я обычно еще делаю такой вот виджет.
Делаю примерно следующее. Состояние стейджа. Как это сделать?
Ну, давайте, допустим, там, ну, типа, давайте сделаем тестинг. Я сюда добавлю... Сейчас скажу, я что добавлю.
вот этот pie chart, по-моему, вот так вот, by execution status, и вот здесь вот сделаю tag равно Тестинг. Вот так вот. Это будет первая штука. Давайте сделаем... Пока тут нету тестов, это нормально.
И мы сделаем сейчас стейбл. Давайте так, клон и тут стейбл. Вы сейчас поймете, что я сделаю.
Вот так вот. Можно, кстати, да, можно их вот таким вот образом. И потом мы делаем клон и выбираем launches, да.
И тут выбираем клон и выбираем... Вот тут вот launches, да. Все, я подготовился. Теперь давайте посмотрим, позапускаем тестики наши. Мы возьмем наши issue и сделаем следующее.
Я хочу запустить вот эти тесты. Мы запускаем. Это будет у нас на теге testing. Я буду запускать на тестинге в браузере Chrome.
Вот здесь и на мастере. Safe environment. Это пошло в тестинг.
Окей. И вот это у нас запускается на stable. Или как я там делал? Нет, все-таки надо посмотреть. Давайте посмотрим.
Stages. Stable, да. Окей. Тут я пишу stable, тут я делаю environment, браузер Firefox, хост и мастер сейв.
Погнали. Теперь я могу зайти на вот этот дашборд, увидеть, как у меня запускаются тесты. Вот видно, что вот этот ланч у меня сейчас находится в таком состоянии, вот этот ланч в таком состоянии. Сейчас у меня допройдут наши тестики. Что-то пошло не так.
извиняюсь что-то пошло не так сейчас пойду поймут пойму чё что-то какой-то рассинхрон пошел почему такой рассинхрон пошел только что все работало сейчас секундочку потому что у меня тут появился ручной тест я понял я не отфильтровал по ручным тестам ну и боссу ручные тесты просто возьмем сделаем ручные тесты Возьмем вот так вот и всем им скажем Passed. Окей, возьмем вторую тему. Вот у нас есть вот такой вот. 3, Manual.
Короче, что-то у нас рассинхронизировалось, как всегда. Давайте еще раз перезапустим эти тесты и у нас будет счастье. Слишком быстро кнопки нажимал.
Окей, так, проверим джобы. Тут все хорошо. Браузер, браузер. А, вот он вот эту джобу запустил.
Надо ее отключить. Вот проблема, скорее всего. Все, давайте еще раз сделаем.
Вот это у нас запускается run. Я просто не посмотрел. Все, теперь точно все будет хорошо.
Вот это у нас запускается в стейбле. Стейбл. и мы выставляем environment хром, prod, master. Ok, stable.
А вот второе мы запустим в тестинге. Testing, environment, prod, Firefox и master. И нам сейчас надо будет еще ручные тесты пройти, но это уже другая история.
Отлично, теперь у нас все заработало. Вот у меня есть ручные тесты. Я говорю, ручные тесты беру и, например, их прохожу.
Отлично. И здесь у меня тоже останутся ручные тесты, а тут я и завалю. Мануальные тесты, я их говорю, ой, я говорю, что они фейлят. Отлично, все. Вот у меня есть ручные тесты.
Я закрываю вот эти два ланча. И вот что у меня будет на дашбордах. Я буду видеть состояние текущее моих тестингов. То есть я в данном случае вижу, что у меня тут три теста pass, а тут три теста fail.
Вот это у нас stable. Stable. Stable. Нет, не клон. Так, я уже просто немножко два часа разговариваю, немножко устал уже, так что извините, это тоже stable.
И тут показывается количество тестов, которые мы запускали. Тут 12. Но самая крутая тема заключается в следующем. Когда вы сейчас запустите тесты еще раз, давайте запустим тесты еще раз в стейбле. тесты, add environment, Chrome, branch, master и тег у нас stable, сделаем запуск, то на дашборде мы увидим, что у нас пошел какой-то новый запуск наших тестов. И сейчас вот этот вот результирующий кружочек, он будет относительно последних тестов.
То есть, грубо говоря... Вот эти ланчи, они мерзнутся, и вот в этом кружочке отображается каждый тест-кейс, который был запущен в этих ланчах с последним статусом. И с помощью такого виджета, мы сейчас это увидим. Давайте пройдем наши тестики.
Ручные manual, pass it. И перезапустим сломанные тесты. Fail it.
И перезапуск. Вот. И, соответственно, вот на этом виджете у нас будет отображаться информация про, ну, типа, вот этот вот последний статус каждого там тестинга, стейбла и так далее.
И вот это очень уже наглядная картинка. Обычно ее делают даже не то, что там тестинг и стейбл, а я тут делаю какую-то версию продукта и по версии продукта прям вижу, как у нас происходит релиз, какие у нас происходят запуски и так далее. И, например, если мы сейчас вот это вот закроем. перейдем в дашборд, мы увидим, что у нас тут осталось два фейлит-теста, и сейчас они до сих пор в состоянии фейлит. Надеюсь, нормально рассказал, показал.
Итак, у нас есть графики, которые по всяким выбросам, есть возможность построить графики по кавериджу, есть возможность посмотреть отдельно мануальные тесты, есть возможность посмотреть отдельно стейджи, есть возможность отдельно посмотреть все по юзерам. Ну, типа, вот такие вот дела. Как outdated test отображается в коде...
Да, я уже начинаю отвечать на вопросы. Как outdated test отображается в коде IDE? На самом деле, они пока не отображаются никак, но скоро около теста, вот здесь вот, у них будет такой вот кружочек, и вы сможете...
Ну, короче, скоро в IDE появится возможность быстро перейти в outdated test, точнее, быстро увидеть свои outdated... тесты, которые назначены на вас. То есть такая возможность появится, пока это не делается никак. И вот тут вот мануальный тест можно импортнуть в EDE. Наоборот, мы сейчас работаем.
Ну, чтобы мануальные тесты из EDE отображались в Allure, мы над этим работаем. Эта функциональность скоро появится. И, соответственно, когда они будут запускаться, они будут запускаться в общем наборе, они в Алюре будут превращаться в мануальные тесты. Эта функциональность у нас есть, скоро будет готова. Так, результаты можно импортировать, естественно, результаты мануальных тестов можно импортировать.
На самом деле у меня все, наверное, по таким вот как бы основным штукам. Много, надеюсь, всего показал, рассказал интересного. Давайте, если у кого-то есть какие-то глобальные вопросы, то можно позадавать их. Если нет вопросов...
то можно, в принципе, расходиться, потому что я уже и так, видимо, вас замучил. У нас тем временем 40 человек, было сейчас уже 36 человек. Хорошо, почти все досидели. Это, на самом деле, меня очень радует. Есть какие-то вопросы общие?
Да, я согласен, что нужно переосмыслить полученную информацию. Это я согласен, потому что обычно так и бывает, что после демок... которые я показываю, действительно в командах начинают задумываться, что можно жить совершенно по-другому, и что на самом деле мир ручного и автоматического тестирования, он связан гораздо сильнее, чем это обычно принято считать. И как бы вот за счет вот этих вот фичей можно, ну, прям очень хорошо делать этот...
Да, окей, хорошо, это все расшарим, конечно, это... Каких основных возможностей не будет в iOS Swift? Все будет.
В iOS Swift все будет. ровно так же. Все будет ровно так же.
Для нее надо использовать XC Results, вот такую библиотечку. Она конвертирует результаты тестов из iOS в этот... Короче, из iOS конвертирует прямо из стандартного формата валюровский. Там сохраняются все степы и так далее.
Поэтому приходите, если у вас iOS-ные проекты, приходите к нам, я все покажу, расскажу.