Ничего не могу сказать хорошего или плохого про песочницу, так как сам из нее вышел очень давно, но ограничение (минимальное или максимальное) в 3000 знаков не должно являться сильным препятствием для изложения мыслей.
Опять же, не хочу вас никак оскорбить, просто дать дружеский совет. Для вашего общего понимания - как и в научной литературе, так в целом и на хабре (да и не только) статья - это не просто мысль, выкинутая в цифровой океан безумия. Статья обычно ставит некий вопрос, освещает некую проблему и предлагает либо теоретические, либо практические методы ее решения. Еще прекрасно, если статья содержит хоть какие-то выводы (из разряда - попробовал, вышло хорошо или не очень), но это уже суть каждого дела индивидуальная.
Обращаясь к вашей статье - на самом деле даже без опускания в глубокие дебри вы и правда описываете очень обширную и знакомую, пожалуй, каждому проблему. Проблема команды - когда она собирается в удачной конфигурации, то может горы свернуть, но через какое-то время она распадается.
И вроде бы вы даже пытаетесь указать на причину, но опять же - ничего не предлагаете для ее решения. Ведь самый логичный вопрос после прочтения вашей статьи: "А как можно избавиться от этой проблемы, или хотя бы максимально отсрочить этот момент?" - и вы не даете даже намека на ответ.
Хотя даже я, вообще не специалист в психологии, но человек который участвовал и даже немного руководил разными командами, мог бы дать несколько мыслей и рекомендаций тем, кто ищет ответ на этот вопрос. Хотя бы банальнейшее "Разбавляйте команду новыми людьми, прощайтесь со старыми хотя бы на время отправив в долгий отпуск". Но это я, простофиля в психологии, а вот автора с таким багажом знаний как у вас, все же хочется услышать более интересные и неочевидные ответы.
Совершенно непонятно что хотел сказать автор и какой вывод стоит сделать.
В целом ощущение, что автор прочитал книжку по психологии (или послушал одну лекцию) и просто скопировал сюда материал никак его не переработав и не адаптировав для публики, которая не в контексте изучаемого автором предмета. В итоге получился рассказ из разряда "Утром солнышко встает, днем макушку нам печет, ну а вечером ложится спать пора"
Желаю автору в будущем стараться больше раскрывать материал, разбавлять примерами и познакомиться с хоть какой структурой, чтобы было сразу ясно - зачем эта статья, в чем именно проблема и как с ней бороться. Все что есть сейчас в статье - это только описание проблемы, но не сказано чем она плоха и как с ней бороться.
Как же забавно, ностальгически и одновременно грустно читать было эту статью. Казалось бы, 2022 год на дворе - такие то технологии, модные словечки аля Docker, Load Balancer и все такое... А проблемы все те же самые, что мы с коллегами решали на заре моей карьеры лет 13 назад.
Только тогда бэкграунд проблемы был немного другой. Дано: Множество предприятий по нашей необъятной стране, программные модули весом почти "АЖ В ГИГАБАЙТ", на удаленных концах дай бог диалап кое-как работает 2 часа в день. То есть возможности регулярно обновлять модули на предприятиях не было, и в результате каждое могло работать со своей версией.
А самый прикол был в том, что эти самые предприятия должны были синхронизироваться - получать актуальные данные друг от друга, делалось это через единый центральный сервер. Каждый установленный модуль в удобное для сетевой нагрузки время отправлял свои новые данные и забирал другие с сервера.
И там были точно такие же проблемы - одно предприятие использовало прошлогоднюю версию, где какие-то данные лежали в одном поле одной строчки таблицы, а на другом предприятии стояла самая свежая версия, где эти данные были вынесены в отдельную таблицу построчно.
Для решения таких проблем нам приходилось писать специальные преобразователи. Они получали данные от старых версий и преобразовывали их в формат последней версии. И наоборот - для отправки на старые версии преобразовывали данные из нового формата в старый, определенной версии того предприятия, которое запрашивало обновления.
Можно, через передачу информации по сессии. Точнее схема такая:
1) Делаем авторизацию через скоуп подключения к браузеру
2) Через параметр SessionData получаем информацию о сессии, эта информация передается в виде строки, ее можно сохранить в хранилище, чтобы использовать в последующих тестах
3) В тесте, где нужно использовать эту сессию - загружаем параметр SessionData
Более подробно про методы получения и загрузки данных о сессии можно прочесть в документации:
time.sleep - это из примера Selenium, к дальнейшему рассказу про UiPath никакого отношения он не имеет. Там есть свои методы ожидания реакции, не требующие настройки таймеров. Что касается Selenium - даже если вы знаете как обходиться без time.sleep там, вы большой молодец, что не отменяет проблемы с удобством восприятия кода, где идет указание на элементы, с которыми идет работа в стиле div>div>div>div
Надежность тестов полностью зависит от поддержки их актуальности. Если вы доработаете/переработаете функционал, который проверяет тест, и при этом не заложите в тесты новых ожидаемых результатов - естественно, тест будет выдавать ложные результаты.
В случае, если вы держите тесты в порядке, они всегда содержат корректный порядок действий, содержат согласованный набор входных данных с ожиданием согласованного результата - они никогда вас не подведут.
Естественно, под "никогда" я имею ввиду, что вы не будете умышленно пытаться вмешаться в тестирование роботом. Например, принудительно закрывать приложения, которые тестирует робот, отключать Интернет тогда, когда робот тестирует ресурс в Интернете. В этих случаях робот обязательно сообщит об ошибках во время выполнения тестов.
В прочем, если вы получите в отчете о тестировании результат "Ошибка, нет доступа к ресурсу" - это тоже тот случай, когда нужно обратить внимание на тестируемый ресурс. А если вы понимаете "ну да, пропадал Интернет" - просто перезапускаете тесты (можно сделать выборку по проваленным и запустить только их).
Плюс в том, что вы можете автоматизировать ручное тестирование одинаково для Windows, Web и мобильных приложений. А еще важно то, что вы можете сделать тест бизнес-процесса, где участвует сразу несколько приложений.
Например, вы можете проверить, что после загрузки клиентом документа на сайт - сведения об этом появляются во внутренней CRM (например, в SAP). С помощью инструмента, про который рассказано в этой статье, данный тест можно написать за несколько минут, при этом не нужно быть ни разработчиком веб-решения, ни разработчиком/интегратором CRM. Если вы мне расскажете каким еще способом можно написать такой тест при условии, что автор теста не умеет программировать SAP - я буду вам очень признателен и с удовольствием ознакомлюсь с материалами.
Конечно, если у вас только web, который вы пишете сами - использовать указанный в статье инструмент может быть слегка Overkill. Но здесь статья скорее обращена к тем, кто:
1) Помимо Web делает Windows-приложения (вы будете удивлены, но таких еще очень много)
2) Не обладают компетенциями в selenium и подобных средствах
Нет смысла смешивать разные виды тестирования в одном инструменте..
Приношу свои извинения, если где-то в статье выразился некорректно. Автотесты на программном уровне должны быть написаны в той среде разработки, в которой вы создаете ваши приложения. В статье речь идет именно про ручное тестирование. Это может показаться странным, но я знаю немало компаний, где сидят целые отделы ручных тестировщиков, которые весь день занимаются тем, что просто кликают мышкой по очередным сборкам систем и заносят отчеты в Jira или аналогичное ПО. Можете считать, что целевой аудиторией этой статьи являются именно такие компании и команды. Если вас не затрагивает эта проблема - я искренне рад за вас и даже немножко завидую (без иронии и сарказма).
но поддержка, решение проблем и коммьюнити?
Как и у любого серьезного инструмента (а инструмент, названный в статье - серьезный), существует как общемировое комьюнити (форум), официальная поддержка, так и несколько российских комьюнити. И дабы не быть обвиненным в рекламе - на самом деле есть множество других RPA решений, в том числе отечественных, которые активно развиваются как в плане качества, так и в плане поддержки и комьюнити. Просто инструмент, про который я рассказал в статье - лично мне нравится больше всего и им я пользуюсь уже года два с большим удовольствием.
Возможно, вы немного запутались. Это статья на моей персональной странице хабра про мою частную практику, не относится ни к какому корпоративному блогу. Точно так же, как есть много статей, написанных частными специалистами про многие другие технологии, которыми они пользуются.
С таким подходом как у вас, можно назвать рекламными все статьи, которые посвящены применению Microsoft Visual Studio, InelliJ IDEA и прочим средам разработки. UiPath - это тоже среда разработки, которую использует очень много компаний по всему миру. А дальше лишь вопрос как эту среду разработки применять, об одном из способов применения я рассказал в этой статье.
Может быть вы поищете десяток статей про тестирование на MS VS, IDEA, PyCharm и тоже напишете в комментариях, что те статьи являются рекламными, если вам не ответят на вопросы, ответы на которые вы можете найти в документации? Или "это другое"?
Возможно, вам в принципе противно любое упоминание RPA, и я вас прекрасно понимаю. Еще года три назад я сам плевался ядом на любое упоминание такого подхода. Так что позволю себе роскошь и не буду в дальнейшем отвечать на ваши комментарии, которые полностью противоречат Хабраэтикету из официальных правил сайта: https://habr.com/ru/docs/help/rules/
Но я буду всегда рад увидеть вас в будущем в рядах интересующихся перспективными технологиями.
Конечно, заранее продумать всё невозможно, но бывают случаи, когда можно догадаться + если уже встретили один раз какое-то несвойственное появление, стоит его ожидать и впредь.
Например, бывает такое, что внезапно появляется блок авторизации у пользователей, которые уже авторизовались. Или же по аналогии - призыв к действию для тех, кто уже совершил действие.
Проверяется методом поиска такого элемента на странице (в вышеупомянутом UiPath это делается методом Check App State). Если он найден тогда, когда не должен выводится - считаем, что ошибка.
Многоуважаемый lair, пожалуйста, зайдите на официальную документацию продукта и там вы найдете ответы на все ваши вопросы. Я считаю неправильным превращать хабр в ксерокопию публично доступной информации в формате вопрос-ответ.
Если же вам интересно посмотреть все это вживую и позадавать дополнительные вопросы - я могу организовать для вас официальную демонстрацию от вендора. Для этого вам будет необходимо прислать название вашей компании, вашу должность и адрес рабочей электронной почты мне в личные сообщения.
Версионирование тестов осуществляется штатными средствами платформы, перед тем как запускать тесты на роботах - их нужно опубликовать на сервере (в оркестраторе), при публикации создается пакет с новым номером версии. Согласованность с версиями стороннего ПО можно организовать на уровне ALM вашего ПО, либо непосредственно в UIPath Test Manager, если вы осуществляете тестирование стороннего ПО (например, которое вам делают подрядчики или публичные облачные службы).
Все наборы данных и тесты попадают на исполнение из вышеупомянутых пакетов. Соответственно, разработчик может взять нужную версию и прогнать упавшие варианты, которые в нем доступны. Посмотреть что именно упало он может предварительно на сервере.
Возможно, множество ваших прочих вопросов будет исключено, если вы ознакомитесь с документацией продукта, либо же воспользуетесь публичной community-версией.
Не совсем понял о какой именно цене идет речь, но предполагаю, что о цене на лицензию решения с одним роботом. Стоимость лицензии никак не зависит от того, как вы ее используете, она дает вам право использовать робота как вы захотите 24х7, а дальше уже ваше дело: загружаете ли вы робота по полной или он выполняет одну задачку за 1 час в сутки.
В статье сравнивались затраты на 1 полностью загруженного тестировщика (8 часов в день) и 1 робота, который может работать 24 часа в сутки. То есть, если переложить восьмичасовую работу одного сотрудника на робота, даже не принимая во внимание тот факт, что он справится с делом быстрее - он будет способен дать вам еще 16 часов работы (отсюда в тексте есть упоминание, что 1 робот может заменить 3 тестировщиков).
В случае, если у вас тестированием занимается один недозагруженный сотрудник (условно посвящает этому 4 или меньше часов в день) - здесь, скорее всего, очевидной выгоды от применения роботов не будет (хотя надо посмотреть сколько он получает, если он получает у вас 150к+ в месяц, то по расчетам выгода есть).
Робот, как и остальные компоненты платформы UiPath - это специализированное ПО, над которым трудится очень много людей по всему миру. Как и любое качественное коммерческое ПО - оно требует лицензирования на каждую используемую единицу (точно так же, как лицензия требуется на каждую установку MS Windows, каждую установку MS Office, каждую установку антивируса, и так далее).
Если вам понятно что такое роботы, но вы не понимаете почему необходимо платить лицензии за каждого робота - это означает, что вы работали с некачественными поделками, и тут ваш вопрос вполне логичен.
Чтобы стало понятнее - ознакомьтесь с возможностями роботов именно от UiPath, в блоге есть больше статей с разными техническими подробностями о разных возможностях этих роботов: https://habr.com/ru/users/RPAconsultant/posts/
Отличный пример, к слову он не единственный. У Apple есть что-то похожее для обучения Swift. И для ряда своих учеников я применяю в том числе и эти инструменты.
Однако, с этими тремя учениками возникла проблема именно с освоением такого текстового формата. Наверное, если бы я, как типовой учитель, посидел бы с ними много занятий - смог вдолбить им это. Но благодаря использованному инструменту у меня получилось сделать именно для них обучение более быстрым и интересным.
Я могу задать сходный вопрос - а зачем нам графический язык, когда есть BrainFuck или ASM
Предлагаю вам снова перечитать статью и перепогрузится в проблематику.
Там есть пример программы, которая считывает excel-файл и отправляет письма всем людям из таблицы в файле. Она занимает всего три действия: "Прочитать файл", цикл "Для каждой строчки", и "Отправить письмо".
Когда людям нужно делать такие простые программы - они могут сделать их меньше, чем за 10 минут (для этой статьи я, как опытный разработчик, сделал эту программу за 2 минуты, но я делаю "скидку" для новичков).
А сколько они потратят времени, если будут пользоваться ASM? Хорошо, я понимаю, что вы утрировали, но давайте скажите мне сколько вы потратите времени, чтобы с нуля написать такую программу на RUST, только без использования Интернета (гугла).
Я хочу донести до вас мысль, что не нужно ножиком забивать гвозди. У каждого инструмента есть своя сфера применения, и никто не говорит, что "Давайте выбросим классическое программирование и будем рисовать". Я лишь говорю в этой статье, что можно начинать свой путь именно так, а дальше уже развиваться.
PS: Я совершенно не понимаю о чем вы говорите словами "все ориентированны на кликание мыши". Последний раз, когда я программировал без мышки - был первый курс университета, на котором мы писали под DOS на Borland C++ 3.1. Все остальное время во всех более современных средах разработки так или иначе можно (и даже нужно) применять мышку. Вы большой молодец, что выучили все сочетания клавиш и справляетесь со своей работой, выбросив мышку - но большинство современных разработчиков все же использует мышку, чтобы открывать файлы, вызывать контекстное меню, "рисовать" пользовательские интерфейсы итд.
Я не являюсь экспертом по Rust, поэтому не готов комментировать сравнение с ним.
Что касается вопрсов опечаток в коде и правильного использования типов данных - за это отвечают возможности анализаторов и компиляторов языков VB NET и C#, точно такие же, как используемые в Visual Studio от Microsoft.
ООП именно в виде графической разработки - никак. Но если очень хочется, и ведется командная разработка - то как правило старшие специалисты пишут нужные классы в виде классической dll-библиотеки, упаковывают ее в NuGet-пакет, публикуют в локальном NuGet-репозитории и дальше он используется в любых проектах, где нужно использовать собственные классы, структуры. С другой стороны - чаще всего разработчики на UiPath используют json-структуры для хранения и обмена информацией, что позволяет вообще не морочится с созданием собственных классов (в классическом понимании).
По поводу многопоточности - имеется вариант запуска других программ (процессов) на других машинах с ожиданием выполнения. Самый лучший способ - использовать встроенные в платформу очереди транзакций, которые гарантируют получение уникальной транзакции каждой отдельной машиной (то есть очередь из миллиона транзакций будет разбираться 2-3-4 итд машинами и нигде не будет путанницы).
С другой стороны - опускание в такие глубокие детали вызывает уже и встречный вопрос - а зачем все это нужно при решении несложных утилитарных задач? Усложнение не всегда действительно нужно. А часть вещей, которые вам хочется писать самому - уже есть в платформе, и их просто нужно научиться использовать. А чтобы научиться - есть бесплатная академия, где рассказано про все аспекты платформы: https://academy.uipath.com
Нет, при переименовании переменных, аргументов (входные - параметры функции, выходные - возвращаемое значение) и самих файлов ничего не летит, среда разработки сама все переименовывает везде (прямо как Visual Studio и IntelliJ IDEA, если пользоваться встроеннвм функционалом переименования).
Но если вы решите открыть исходный код в текстовом редакторе и поменять что-то ручками - конечно, поломается. Обо всех проблемах вы узнаете на этапе проектирования. Встроенный статический анализатор кода не даст просто запустить даже отладку. К слову, этот анализатор можно накрутить дополнительными условиями, которые будут запрещать запуск если ваши разработчики начнут именовать переменные от балды, отойдя от принятого в компании код-стайла.
В целом вы пишете очень разумные и правильные замечания, но все это (по крайней мере в этой платформе) уже несколько лет как "по-умолчанию" решено.
Под капотом у выбранного инструмента (UiPath) - платформа .NET (при чем как старый .NET Framework 4.6.2, так и современный .NET по выбору) с возможностью писать выражения и блоки кода на языках VB NET и C#. Например, если вам нужно отправить письмо и составить его из разных блоков текста в зависимости от множества условий - вам не обязательно надо использовать только визуальное программирование, вы можете написать элегантный код. Преимущество именно в возможности выбора подхода. Что касается вопрсов:
Рекурсия - Есть, работает. Как в графическом варианте (вызывая другой/этот же файл с графическим кодом), так и в виде написания подфункций в блоке на языке из перечисленных выше
Лямбда-выражения - Используются большинством разработчиков для фильтрации, сортировки списков, таблиц
IntelliSence - присутствует при написании выражений и блоков кода на VB NET, C#
GIT (а так же TFS, SVN) - имеется встроенная интеграция с ними, в том числе с популярными GitHub, и GitLab.
... много оных - надо понимать о чем именно речь, но благодаря возможности использования VB NET и C# - скорее всего есть.
Ничего не могу сказать хорошего или плохого про песочницу, так как сам из нее вышел очень давно, но ограничение (минимальное или максимальное) в 3000 знаков не должно являться сильным препятствием для изложения мыслей.
Опять же, не хочу вас никак оскорбить, просто дать дружеский совет. Для вашего общего понимания - как и в научной литературе, так в целом и на хабре (да и не только) статья - это не просто мысль, выкинутая в цифровой океан безумия. Статья обычно ставит некий вопрос, освещает некую проблему и предлагает либо теоретические, либо практические методы ее решения. Еще прекрасно, если статья содержит хоть какие-то выводы (из разряда - попробовал, вышло хорошо или не очень), но это уже суть каждого дела индивидуальная.
Обращаясь к вашей статье - на самом деле даже без опускания в глубокие дебри вы и правда описываете очень обширную и знакомую, пожалуй, каждому проблему. Проблема команды - когда она собирается в удачной конфигурации, то может горы свернуть, но через какое-то время она распадается.
И вроде бы вы даже пытаетесь указать на причину, но опять же - ничего не предлагаете для ее решения. Ведь самый логичный вопрос после прочтения вашей статьи: "А как можно избавиться от этой проблемы, или хотя бы максимально отсрочить этот момент?" - и вы не даете даже намека на ответ.
Хотя даже я, вообще не специалист в психологии, но человек который участвовал и даже немного руководил разными командами, мог бы дать несколько мыслей и рекомендаций тем, кто ищет ответ на этот вопрос. Хотя бы банальнейшее "Разбавляйте команду новыми людьми, прощайтесь со старыми хотя бы на время отправив в долгий отпуск". Но это я, простофиля в психологии, а вот автора с таким багажом знаний как у вас, все же хочется услышать более интересные и неочевидные ответы.
Совершенно непонятно что хотел сказать автор и какой вывод стоит сделать.
В целом ощущение, что автор прочитал книжку по психологии (или послушал одну лекцию) и просто скопировал сюда материал никак его не переработав и не адаптировав для публики, которая не в контексте изучаемого автором предмета. В итоге получился рассказ из разряда "Утром солнышко встает, днем макушку нам печет, ну а вечером ложится спать пора"
Желаю автору в будущем стараться больше раскрывать материал, разбавлять примерами и познакомиться с хоть какой структурой, чтобы было сразу ясно - зачем эта статья, в чем именно проблема и как с ней бороться. Все что есть сейчас в статье - это только описание проблемы, но не сказано чем она плоха и как с ней бороться.
Как же забавно, ностальгически и одновременно грустно читать было эту статью. Казалось бы, 2022 год на дворе - такие то технологии, модные словечки аля Docker, Load Balancer и все такое... А проблемы все те же самые, что мы с коллегами решали на заре моей карьеры лет 13 назад.
Только тогда бэкграунд проблемы был немного другой. Дано: Множество предприятий по нашей необъятной стране, программные модули весом почти "АЖ В ГИГАБАЙТ", на удаленных концах дай бог диалап кое-как работает 2 часа в день. То есть возможности регулярно обновлять модули на предприятиях не было, и в результате каждое могло работать со своей версией.
А самый прикол был в том, что эти самые предприятия должны были синхронизироваться - получать актуальные данные друг от друга, делалось это через единый центральный сервер. Каждый установленный модуль в удобное для сетевой нагрузки время отправлял свои новые данные и забирал другие с сервера.
И там были точно такие же проблемы - одно предприятие использовало прошлогоднюю версию, где какие-то данные лежали в одном поле одной строчки таблицы, а на другом предприятии стояла самая свежая версия, где эти данные были вынесены в отдельную таблицу построчно.
Для решения таких проблем нам приходилось писать специальные преобразователи. Они получали данные от старых версий и преобразовывали их в формат последней версии. И наоборот - для отправки на старые версии преобразовывали данные из нового формата в старый, определенной версии того предприятия, которое запрашивало обновления.
Можно, через передачу информации по сессии. Точнее схема такая:
1) Делаем авторизацию через скоуп подключения к браузеру
2) Через параметр SessionData получаем информацию о сессии, эта информация передается в виде строки, ее можно сохранить в хранилище, чтобы использовать в последующих тестах
3) В тесте, где нужно использовать эту сессию - загружаем параметр SessionData
Более подробно про методы получения и загрузки данных о сессии можно прочесть в документации:
https://docs.uipath.com/activities/docs/n-get-browser-data
https://docs.uipath.com/activities/docs/n-set-browser-data
Не очень понял вопроса с куками, пожалуйста, раскройте подробнее.
time.sleep - это из примера Selenium, к дальнейшему рассказу про UiPath никакого отношения он не имеет. Там есть свои методы ожидания реакции, не требующие настройки таймеров. Что касается Selenium - даже если вы знаете как обходиться без time.sleep там, вы большой молодец, что не отменяет проблемы с удобством восприятия кода, где идет указание на элементы, с которыми идет работа в стиле div>div>div>div
Надежность тестов полностью зависит от поддержки их актуальности. Если вы доработаете/переработаете функционал, который проверяет тест, и при этом не заложите в тесты новых ожидаемых результатов - естественно, тест будет выдавать ложные результаты.
В случае, если вы держите тесты в порядке, они всегда содержат корректный порядок действий, содержат согласованный набор входных данных с ожиданием согласованного результата - они никогда вас не подведут.
Естественно, под "никогда" я имею ввиду, что вы не будете умышленно пытаться вмешаться в тестирование роботом. Например, принудительно закрывать приложения, которые тестирует робот, отключать Интернет тогда, когда робот тестирует ресурс в Интернете. В этих случаях робот обязательно сообщит об ошибках во время выполнения тестов.
В прочем, если вы получите в отчете о тестировании результат "Ошибка, нет доступа к ресурсу" - это тоже тот случай, когда нужно обратить внимание на тестируемый ресурс. А если вы понимаете "ну да, пропадал Интернет" - просто перезапускаете тесты (можно сделать выборку по проваленным и запустить только их).
Плюс в том, что вы можете автоматизировать ручное тестирование одинаково для Windows, Web и мобильных приложений. А еще важно то, что вы можете сделать тест бизнес-процесса, где участвует сразу несколько приложений.
Например, вы можете проверить, что после загрузки клиентом документа на сайт - сведения об этом появляются во внутренней CRM (например, в SAP). С помощью инструмента, про который рассказано в этой статье, данный тест можно написать за несколько минут, при этом не нужно быть ни разработчиком веб-решения, ни разработчиком/интегратором CRM. Если вы мне расскажете каким еще способом можно написать такой тест при условии, что автор теста не умеет программировать SAP - я буду вам очень признателен и с удовольствием ознакомлюсь с материалами.
Конечно, если у вас только web, который вы пишете сами - использовать указанный в статье инструмент может быть слегка Overkill. Но здесь статья скорее обращена к тем, кто:
1) Помимо Web делает Windows-приложения (вы будете удивлены, но таких еще очень много)
2) Не обладают компетенциями в selenium и подобных средствах
Приношу свои извинения, если где-то в статье выразился некорректно. Автотесты на программном уровне должны быть написаны в той среде разработки, в которой вы создаете ваши приложения. В статье речь идет именно про ручное тестирование. Это может показаться странным, но я знаю немало компаний, где сидят целые отделы ручных тестировщиков, которые весь день занимаются тем, что просто кликают мышкой по очередным сборкам систем и заносят отчеты в Jira или аналогичное ПО. Можете считать, что целевой аудиторией этой статьи являются именно такие компании и команды. Если вас не затрагивает эта проблема - я искренне рад за вас и даже немножко завидую (без иронии и сарказма).
Как и у любого серьезного инструмента (а инструмент, названный в статье - серьезный), существует как общемировое комьюнити (форум), официальная поддержка, так и несколько российских комьюнити. И дабы не быть обвиненным в рекламе - на самом деле есть множество других RPA решений, в том числе отечественных, которые активно развиваются как в плане качества, так и в плане поддержки и комьюнити. Просто инструмент, про который я рассказал в статье - лично мне нравится больше всего и им я пользуюсь уже года два с большим удовольствием.
Возможно, вы немного запутались. Это статья на моей персональной странице хабра про мою частную практику, не относится ни к какому корпоративному блогу. Точно так же, как есть много статей, написанных частными специалистами про многие другие технологии, которыми они пользуются.
С таким подходом как у вас, можно назвать рекламными все статьи, которые посвящены применению Microsoft Visual Studio, InelliJ IDEA и прочим средам разработки. UiPath - это тоже среда разработки, которую использует очень много компаний по всему миру. А дальше лишь вопрос как эту среду разработки применять, об одном из способов применения я рассказал в этой статье.
Может быть вы поищете десяток статей про тестирование на MS VS, IDEA, PyCharm и тоже напишете в комментариях, что те статьи являются рекламными, если вам не ответят на вопросы, ответы на которые вы можете найти в документации? Или "это другое"?
Возможно, вам в принципе противно любое упоминание RPA, и я вас прекрасно понимаю. Еще года три назад я сам плевался ядом на любое упоминание такого подхода. Так что позволю себе роскошь и не буду в дальнейшем отвечать на ваши комментарии, которые полностью противоречат Хабраэтикету из официальных правил сайта: https://habr.com/ru/docs/help/rules/
Но я буду всегда рад увидеть вас в будущем в рядах интересующихся перспективными технологиями.
Конечно, заранее продумать всё невозможно, но бывают случаи, когда можно догадаться + если уже встретили один раз какое-то несвойственное появление, стоит его ожидать и впредь.
Например, бывает такое, что внезапно появляется блок авторизации у пользователей, которые уже авторизовались. Или же по аналогии - призыв к действию для тех, кто уже совершил действие.
Проверяется методом поиска такого элемента на странице (в вышеупомянутом UiPath это делается методом Check App State). Если он найден тогда, когда не должен выводится - считаем, что ошибка.
Многоуважаемый lair, пожалуйста, зайдите на официальную документацию продукта и там вы найдете ответы на все ваши вопросы. Я считаю неправильным превращать хабр в ксерокопию публично доступной информации в формате вопрос-ответ.
Если же вам интересно посмотреть все это вживую и позадавать дополнительные вопросы - я могу организовать для вас официальную демонстрацию от вендора. Для этого вам будет необходимо прислать название вашей компании, вашу должность и адрес рабочей электронной почты мне в личные сообщения.
Версионирование тестов осуществляется штатными средствами платформы, перед тем как запускать тесты на роботах - их нужно опубликовать на сервере (в оркестраторе), при публикации создается пакет с новым номером версии.
Согласованность с версиями стороннего ПО можно организовать на уровне ALM вашего ПО, либо непосредственно в UIPath Test Manager, если вы осуществляете тестирование стороннего ПО (например, которое вам делают подрядчики или публичные облачные службы).
Все наборы данных и тесты попадают на исполнение из вышеупомянутых пакетов. Соответственно, разработчик может взять нужную версию и прогнать упавшие варианты, которые в нем доступны. Посмотреть что именно упало он может предварительно на сервере.
Возможно, множество ваших прочих вопросов будет исключено, если вы ознакомитесь с документацией продукта, либо же воспользуетесь публичной community-версией.
Не совсем понял о какой именно цене идет речь, но предполагаю, что о цене на лицензию решения с одним роботом. Стоимость лицензии никак не зависит от того, как вы ее используете, она дает вам право использовать робота как вы захотите 24х7, а дальше уже ваше дело: загружаете ли вы робота по полной или он выполняет одну задачку за 1 час в сутки.
В статье сравнивались затраты на 1 полностью загруженного тестировщика (8 часов в день) и 1 робота, который может работать 24 часа в сутки. То есть, если переложить восьмичасовую работу одного сотрудника на робота, даже не принимая во внимание тот факт, что он справится с делом быстрее - он будет способен дать вам еще 16 часов работы (отсюда в тексте есть упоминание, что 1 робот может заменить 3 тестировщиков).
В случае, если у вас тестированием занимается один недозагруженный сотрудник (условно посвящает этому 4 или меньше часов в день) - здесь, скорее всего, очевидной выгоды от применения роботов не будет (хотя надо посмотреть сколько он получает, если он получает у вас 150к+ в месяц, то по расчетам выгода есть).
Робот, как и остальные компоненты платформы UiPath - это специализированное ПО, над которым трудится очень много людей по всему миру. Как и любое качественное коммерческое ПО - оно требует лицензирования на каждую используемую единицу (точно так же, как лицензия требуется на каждую установку MS Windows, каждую установку MS Office, каждую установку антивируса, и так далее).
Если вам неизвестно что такое роботы, можете ознакомиться в статье: https://habr.com/ru/company/uipath/blog/574342/
Если вам понятно что такое роботы, но вы не понимаете почему необходимо платить лицензии за каждого робота - это означает, что вы работали с некачественными поделками, и тут ваш вопрос вполне логичен.
Чтобы стало понятнее - ознакомьтесь с возможностями роботов именно от UiPath, в блоге есть больше статей с разными техническими подробностями о разных возможностях этих роботов: https://habr.com/ru/users/RPAconsultant/posts/
Отличный пример, к слову он не единственный. У Apple есть что-то похожее для обучения Swift. И для ряда своих учеников я применяю в том числе и эти инструменты.
Однако, с этими тремя учениками возникла проблема именно с освоением такого текстового формата. Наверное, если бы я, как типовой учитель, посидел бы с ними много занятий - смог вдолбить им это. Но благодаря использованному инструменту у меня получилось сделать именно для них обучение более быстрым и интересным.
Предлагаю вам снова перечитать статью и перепогрузится в проблематику.
Там есть пример программы, которая считывает excel-файл и отправляет письма всем людям из таблицы в файле. Она занимает всего три действия: "Прочитать файл", цикл "Для каждой строчки", и "Отправить письмо".
Когда людям нужно делать такие простые программы - они могут сделать их меньше, чем за 10 минут (для этой статьи я, как опытный разработчик, сделал эту программу за 2 минуты, но я делаю "скидку" для новичков).
А сколько они потратят времени, если будут пользоваться ASM? Хорошо, я понимаю, что вы утрировали, но давайте скажите мне сколько вы потратите времени, чтобы с нуля написать такую программу на RUST, только без использования Интернета (гугла).
Я хочу донести до вас мысль, что не нужно ножиком забивать гвозди. У каждого инструмента есть своя сфера применения, и никто не говорит, что "Давайте выбросим классическое программирование и будем рисовать". Я лишь говорю в этой статье, что можно начинать свой путь именно так, а дальше уже развиваться.
PS: Я совершенно не понимаю о чем вы говорите словами "все ориентированны на кликание мыши". Последний раз, когда я программировал без мышки - был первый курс университета, на котором мы писали под DOS на Borland C++ 3.1. Все остальное время во всех более современных средах разработки так или иначе можно (и даже нужно) применять мышку. Вы большой молодец, что выучили все сочетания клавиш и справляетесь со своей работой, выбросив мышку - но большинство современных разработчиков все же использует мышку, чтобы открывать файлы, вызывать контекстное меню, "рисовать" пользовательские интерфейсы итд.
Я не являюсь экспертом по Rust, поэтому не готов комментировать сравнение с ним.
Что касается вопрсов опечаток в коде и правильного использования типов данных - за это отвечают возможности анализаторов и компиляторов языков VB NET и C#, точно такие же, как используемые в Visual Studio от Microsoft.
ООП именно в виде графической разработки - никак. Но если очень хочется, и ведется командная разработка - то как правило старшие специалисты пишут нужные классы в виде классической dll-библиотеки, упаковывают ее в NuGet-пакет, публикуют в локальном NuGet-репозитории и дальше он используется в любых проектах, где нужно использовать собственные классы, структуры. С другой стороны - чаще всего разработчики на UiPath используют json-структуры для хранения и обмена информацией, что позволяет вообще не морочится с созданием собственных классов (в классическом понимании).
По поводу многопоточности - имеется вариант запуска других программ (процессов) на других машинах с ожиданием выполнения. Самый лучший способ - использовать встроенные в платформу очереди транзакций, которые гарантируют получение уникальной транзакции каждой отдельной машиной (то есть очередь из миллиона транзакций будет разбираться 2-3-4 итд машинами и нигде не будет путанницы).
С другой стороны - опускание в такие глубокие детали вызывает уже и встречный вопрос - а зачем все это нужно при решении несложных утилитарных задач? Усложнение не всегда действительно нужно. А часть вещей, которые вам хочется писать самому - уже есть в платформе, и их просто нужно научиться использовать. А чтобы научиться - есть бесплатная академия, где рассказано про все аспекты платформы: https://academy.uipath.com
Да, файл=функция.
Нет, при переименовании переменных, аргументов (входные - параметры функции, выходные - возвращаемое значение) и самих файлов ничего не летит, среда разработки сама все переименовывает везде (прямо как Visual Studio и IntelliJ IDEA, если пользоваться встроеннвм функционалом переименования).
Но если вы решите открыть исходный код в текстовом редакторе и поменять что-то ручками - конечно, поломается. Обо всех проблемах вы узнаете на этапе проектирования. Встроенный статический анализатор кода не даст просто запустить даже отладку. К слову, этот анализатор можно накрутить дополнительными условиями, которые будут запрещать запуск если ваши разработчики начнут именовать переменные от балды, отойдя от принятого в компании код-стайла.
В целом вы пишете очень разумные и правильные замечания, но все это (по крайней мере в этой платформе) уже несколько лет как "по-умолчанию" решено.
У вас явно устаревшее представление о том "что такое графическое программирование". Принял ваш вызов и сделал в двух вариантах:
Последовательность
Блок-схема
Под капотом у выбранного инструмента (UiPath) - платформа .NET (при чем как старый .NET Framework 4.6.2, так и современный .NET по выбору) с возможностью писать выражения и блоки кода на языках VB NET и C#. Например, если вам нужно отправить письмо и составить его из разных блоков текста в зависимости от множества условий - вам не обязательно надо использовать только визуальное программирование, вы можете написать элегантный код. Преимущество именно в возможности выбора подхода. Что касается вопрсов:
Рекурсия - Есть, работает. Как в графическом варианте (вызывая другой/этот же файл с графическим кодом), так и в виде написания подфункций в блоке на языке из перечисленных выше
Лямбда-выражения - Используются большинством разработчиков для фильтрации, сортировки списков, таблиц
IntelliSence - присутствует при написании выражений и блоков кода на VB NET, C#
GIT (а так же TFS, SVN) - имеется встроенная интеграция с ними, в том числе с популярными GitHub, и GitLab.
... много оных - надо понимать о чем именно речь, но благодаря возможности использования VB NET и C# - скорее всего есть.