Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Appium - поделитесь опытом работы с инструментом

appium
Теги: #<Tag:0x00007f7b6247a240>

(Olha) #1

Прочитала и перепробовала много.
У меня один вопрос: Как вообще можно использовать этот инструмент на реальных проектах ?
Попробовала на практике поработать с этим инструметом.
Appium inspector очень очень медленный, рефреш страницы или поиск елемента это где-то по 10 минут на действие. Итог за час с таким перфомансом никакого результата работы

Если с Android приложением можна еще как то работать используя сторонний инструмент UIAutomator то с IOS по-моему никак. xPath не работает (находим елемент через инспектор, берем xPath к елементу, пробуем найти елемент по этому xPath-су, видим сообщение что такого елемента нет). Так же не работает поиск елементов по “ios uiautomation” локаторах. На официальном сайте множество баг по этому поводу.
С трудом написала несколько тестов, потом сделала апдейт с 1.4.0 до 1.4.8 и все конечно же перестало работать

Вот меня и интересует вопрос, если инструмент такой популярний так много людей популяризируют его уже несколько лет. Как они им пользуются с таким перфоменсом и с таким множеством баг.


(Константин) #2

Для поиска локаторов на андроиде использую утилитку monitor из android sdk. Работает шустро, для натива определяет элементы точно. Конечно же он вам не выдаст готовый локатор.
Для IOS`а использовал инспектор appium, медленно и уныло конечно, но не прям так страшно как вы описываете.
По поводу использования предложенных инспектором локаторов, никогда не доверял, составлял сам поэтому возможно и не возникало таких проблем.

С любым обновлением, любого приложения надо быть очень аккуратным, внимательным и четко отдавать себе отчет в том зачем вам это нужно и для чего. И конечно же быть готовым, что обратная совместимость может быть нарушена, а в случае с опенсорсными проектами риски возрастают в разы.


(Ray Romanov) #3

Работая с Appium, я определил для себя приоритет поиска элементов:
Основные критерии для поиска элементов у Android приложения можно опеределить так:
Resource-Id (byId)
XPath (byXPath)
Content-desc (byName)
Class (в основном используется для конкретизации поиска) (byClassName)

Основные критерии для поиска элементов у iOS приложения можно опеределить так:
Name, Value (byName)
XPath (byXPath)
Class (в основном используется для конкретизации поиска) (byClassName)

По поводу XPath, ведроид работает с лету так как отображаемая информация строится в XML дереве и поиск производится внутренними средствами. А вот с огрызком все сложнее сначала аппиум грабит структуру экрана к себе, потом производит поиск, выделяет хитрый ид элемента и потом по этому ид обращается к приложению, вот по этому избегайте XPath в огрызке, лучше вызывать “ios uiautomation”!


(Olha) #4

А можно подробнее как использовать “ios uiautomation”? В Appium инспекторе есть такая возможнасть проверять правильно ли написан локатор с используванием “ios uiautomation” но елемента он не находит.


(Ray Romanov) #5

Сейчас не смогу дать ответ, т.к. занимаюсь написанием автотестов под ведроид. Огрызок в недалекой перспективе, тогда и смогу помочь, в частности поиск через “ios uiautomation” элементов вместо XPath и скролинг. Кстати аппиум же записывает сценарий в формате “ios uiautomation” и там на вкладке можно выбрать на какой язык переконвертировать сценарий.


(Olha) #6

попробовала, записывает xPath-ом


(Mikulasi) #7

Существует такое понятие как предикаты, так вот для iOs в аппиупе есть поиск по предикатам. По поводу xpath, можно конечно пользоваться, но только в крайнем случае, так как он медленнее остальных локаторов. А вообще у нас на проекте сразу было обозначено, чтобы разработчики обязательно добавляли id.


(Mikulasi) #8

Касательно Android пользуйтесь uiautomatorviewer, просто скачайте android sdk. Если у вас iOs, то без инспектора никак. 10 минут на действие - имеется ввиду 10 минут на tap? Если так, то проверьте как заимплементили waitы, типа Thread.sleep(10000), что в приницпе является недопустимым и так называемым антипаттерном Сон))


(Mikulasi) #9

Вообще по поводу багов в аппиуме, то да, хвататет багов и кривых имплементаций (взять тот же swipe), которые часто приходится переписывать под себя используя JS, но в целом аппиум отличный фреймворк для автоматизации мобилок


(Aleksey Ilyenko) #10

Как тут уже сказали, лучше использовать нативные инструменты поиска: iOSUIAutomation и AndroidUIAutomator локаторы. Они работают гораздо быстрее, чем xpath, а по функционалу не уступают. И да, в некоторых случаях Аппиум просто отказывается искать по-другому, кроме как по xpath, и тогда приходится мириться с медленной скоростью. Пока только так в плане мобильной автоматизации :slight_smile:


(Aleksey Ilyenko) #11

По-моему, это самый полный гайд по iOS UIAutomation, а это оф документация по UiSelector’ам (Android UIAutomator)


(Taras) #12

Appium отличная библиотека…inspector втопку, сорси апликухи берите у девелоперов и все будет отлично… а с андроидом вообше проблем нет - ddms нативний (monitor) показивает любой локатор… с гибридними апликухами либо браузерами так вообше все летает


(Mykhailo Poliarush) #13

Опрос: используете ли Вы Appium для автоматизации мобильных приложений?

  • да использую и доволен appium
  • да использую и недоволен appium
  • не использую, но собираюсь использовать
  • не использую и не собираюсь использовать

0 участников


(Oleksandr Khotemskyi) #14

Работал с апиумом на одном из проектов. Хорошего сказать сложно.

  1. несовместимые между собой уже релизные версии - известный косяк апиума
  2. новые версии ios тоже поддерживаются не сразу, помню как долго добавлялась поддержка ios8.
  3. зависания, медленная работа, сложный дебаг - все здесь.

Но! Лучше фреймворка для кроссплатформенных тестов вроде пока и нет. Да еще и с синтаксисом селениума. Я даже хотел законтрибьютить им пару фиксов - да проект закончился и я попал на другой