t.me/atinfo_chat Telegram группа по автоматизации тестирования

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

Теги: #<Tag:0x00007f748c3cdc48>

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

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

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

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

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

Работая с 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”!

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

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

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

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

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

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

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

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

1 Симпатия

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

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

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

0 участников

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

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

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