Ответ: инструмент поддерживает жесты через класс TouchAction. Например, для жестов свайпа используются методы press, moveTo и release.
Стираем. Это убрали больше года назад.
приложение и пакет приложения (appPackage),
Уж если указываете Андроидовский appPackage, то надо бы указать и bundleId от iOS
Ответ: для распознавания элементов мобильных приложений Appium применяет локаторы, аналогичные Selenium. Это могут быть id, name, class, XPath. А также в Appium используются локаторы accessibility id.
Тут забыты нативные локаторы Android: UiSelector, UiSelector, iOS: NSPredicate, Class Chain Queries.
Ох ты. АПИ вообще самое простое в автоматическом тестировании. Правда опять же 70% это подготовка тестовых данных одинаково для всех при интеграционных тестах.
т.е. у вас куча АПИ коллов, которые вы руками посылаете и проверяете ответы?
Изучения автоматизации вам только в плюс. Не знаю что у вас веб, мобильники или может апи проект, но автоматизация вытягивает только на больших проектах. Зарплаты автоматчиков под час в разы больше мануальщиков. Поэтому только на реально больших проектах.
Зато при правильной автоматизации и релизы на больших проектах реальны за пару дней, с минимальным количеством мануальщиков.
ПС Да и уделять 10-20% на автоматизацию, так не получится выхлоп. Там много тонкостей. Ведь клацание на кнопочки это только 15-30% в больших проектах. Остальные 70% это подготовка данных тестирования типа - создать аккаунт, положить деньги, изменить страну проживания, добавить карту, сделать карту expired (уже забыл по русски - просроченой?): теперь начинаем тест. Вот написания этих дополнительных возможностей по генерации данных и есть реальные сложности в больших проектах.
Но в идеале хорошо приводить примеры кода тех или иных частей. И как это взаимодействут друг с другом.
ЗЫ вот у нас в поекте есть все части что вы упомянули. Вообще все. Мы делали UI тесты, а все остальное приросло по ходу и API и DB. Как итог API + DB вынесли в отдельный модуль и теперь это используется в 5ти других проектах.
Все правильно! Надо ждать нужный экран, а не ставить слипы. Со временем это придет. Когда тестов станет 100+. Ибо каждая секунда ожидания это уже более 100секунд.
Чтобы они там в BrowserStack бежали быстро надо их там и запускать. Иначе время пинга увеличит время выполнения теста в 3-5 раз. Так себе решение по мне. Не все фирмы по секурити пропустят так делать.
Проблема вторая - аренда скажем 25 параллельных тел в месяц это огромная сумма.
Вот мы запускаем на своей ферме:
2 макМини
14 андроид тел
12 аппл тел
Данный конфиг = 3 месяцам подписки BrowserStack.
Скорость тестов всегда зависит от апки. Где-то они длинные, где то короче. Ну логика приложений разная. Одно дело делать заказ и другое проверить настройки.
К примеру скорость наших тестов на 12 тел iPhone
220 тестов за 25 мин. Те же Андроид тесты чуть медленнее. По итогу примерно 500 тестов за 30 мин (250 iOS / 250 Android) успевают пробежать на нашем конфиге.
Да там половину и знать не надо. Что там в Чалзе нужно знать, кроме как настроить, смотреть да иногда редактировать запросы/ответы? Это все из разряда - есть башка, разберешься на месте.
Не, тут все просто. Такой фулл КА отвечать может только за кусок функционала. Скажем заказ карт. Вот он его и тестит манульно и автотесты пишет, по образу и подобию имеющегося фреймворка. Тогда это возможно. Речь не идет о написании с нуля тест фреймворка. А только о его наполнении авто тестами.
В большинстве случаев более сложные задачи в коде отданы чистым автоматчикам.
Речь идет о больших проектах. Маленькие вполне может осилить такой фулл стак КА.
Таким образом, каждый тест будет независимым: даже если один упадет, то другие все равно запустятся и принесут результат. А вот объединять несколько кейсов в один не стоит, так как при первом провале проверки assert следующие не запустятся и результат их проверки будет известен только после исправления работы упавшего утверждения.
Тут все зависит:
Какая сложность и временные затраты на подготовку теста (Setup)
Возможно ли проверить что то еще без продолжения теста. Например проверяется сразу несколько параметров в ответе.
Читаемость. Будет ли сохранена читаемость теста при обьединении.
Очень часто тест состоит из тескольких частей. И часто мелкие ошибки не фатальны для продолжения теста. В таких случаях очень удобно проверять мягкими ассертами (Soft Assert поддерживаются с jUnit5 и в testNG). Которые не останавливают тест, но фейлят в самом конце. Таким образом можно ловить сразу несколько ошибок.
1) testNG чуть более гибкий, чем jUnit (beforeSuite, beforeTest, beforeClass, beforeMethod — очень удобно)
2) Android Studio теперь имеет удобный UI инспектор (Layout Inspector)
3) не вижу редакторов, например IntelliJ
Какой Robot, есть еще проще https://maestro.mobile.dev/ !
Только, чем проще инструмент, тем более простые тесты он может написать.
Стираем. Это убрали больше года назад.
Уж если указываете Андроидовский
appPackage, то надо бы указать иbundleIdот iOSТут забыты нативные локаторы Android: UiSelector, UiSelector, iOS: NSPredicate, Class Chain Queries.
Ох ты. АПИ вообще самое простое в автоматическом тестировании. Правда опять же 70% это подготовка тестовых данных одинаково для всех при интеграционных тестах.
т.е. у вас куча АПИ коллов, которые вы руками посылаете и проверяете ответы?
Изучения автоматизации вам только в плюс. Не знаю что у вас веб, мобильники или может апи проект, но автоматизация вытягивает только на больших проектах. Зарплаты автоматчиков под час в разы больше мануальщиков. Поэтому только на реально больших проектах.
Зато при правильной автоматизации и релизы на больших проектах реальны за пару дней, с минимальным количеством мануальщиков.
ПС Да и уделять 10-20% на автоматизацию, так не получится выхлоп. Там много тонкостей. Ведь клацание на кнопочки это только 15-30% в больших проектах. Остальные 70% это подготовка данных тестирования типа - создать аккаунт, положить деньги, изменить страну проживания, добавить карту, сделать карту expired (уже забыл по русски - просроченой?): теперь начинаем тест. Вот написания этих дополнительных возможностей по генерации данных и есть реальные сложности в больших проектах.
Ну так оно всегда будет. И дальше будет расти количество мануальщиков, чтобы в 10 часов все успеть.
А что с автоматизацией? На что уходит 10 часов?
В общем вы все правильно описали!
Но в идеале хорошо приводить примеры кода тех или иных частей. И как это взаимодействут друг с другом.
ЗЫ вот у нас в поекте есть все части что вы упомянули. Вообще все. Мы делали UI тесты, а все остальное приросло по ходу и API и DB. Как итог API + DB вынесли в отдельный модуль и теперь это используется в 5ти других проектах.
Еще раз
npm install -g appiumпоставит Appium 2.X, который без установки драйверов просто не сможет запустить ни Android тесты, ни iOS.https://appium.io/docs/en/2.3/guides/migrating-1-to-2/
Ну а вообще взлетает, так взлетает :-) - вы тогда и систему свою уточняйте. В противном случае ваше "Руководство по запуску автоматизации с Appium и Pytest" просто не будет работать у большинства.
только после
Appium текущий не заработает. Уже почти год как нужно ставить драйверы.
А ссылка на "Официальная документация Appium" совсем неправильная.
Аналогично Test Automation University - Mobile Testing:
Все правильно! Надо ждать нужный экран, а не ставить слипы. Со временем это придет. Когда тестов станет 100+. Ибо каждая секунда ожидания это уже более 100секунд.
Чтобы они там в BrowserStack бежали быстро надо их там и запускать. Иначе время пинга увеличит время выполнения теста в 3-5 раз. Так себе решение по мне. Не все фирмы по секурити пропустят так делать.
Проблема вторая - аренда скажем 25 параллельных тел в месяц это огромная сумма.
Вот мы запускаем на своей ферме:
2 макМини
14 андроид тел
12 аппл тел
Данный конфиг = 3 месяцам подписки BrowserStack.
Скорость тестов всегда зависит от апки. Где-то они длинные, где то короче. Ну логика приложений разная. Одно дело делать заказ и другое проверить настройки.
К примеру скорость наших тестов на 12 тел iPhone
220 тестов за 25 мин. Те же Андроид тесты чуть медленнее. По итогу примерно 500 тестов за 30 мин (250 iOS / 250 Android) успевают пробежать на нашем конфиге.
Ну как же! А уметь применить regex запросы в поисках логах? Это все опят же - примитив для разбирающегося человека.
Да там половину и знать не надо. Что там в Чалзе нужно знать, кроме как настроить, смотреть да иногда редактировать запросы/ответы? Это все из разряда - есть башка, разберешься на месте.
Не, тут все просто. Такой фулл КА отвечать может только за кусок функционала. Скажем заказ карт. Вот он его и тестит манульно и автотесты пишет, по образу и подобию имеющегося фреймворка. Тогда это возможно. Речь не идет о написании с нуля тест фреймворка. А только о его наполнении авто тестами.
В большинстве случаев более сложные задачи в коде отданы чистым автоматчикам.
Речь идет о больших проектах. Маленькие вполне может осилить такой фулл стак КА.
Тут все зависит:
Какая сложность и временные затраты на подготовку теста (Setup)
Возможно ли проверить что то еще без продолжения теста. Например проверяется сразу несколько параметров в ответе.
Читаемость. Будет ли сохранена читаемость теста при обьединении.
Очень часто тест состоит из тескольких частей. И часто мелкие ошибки не фатальны для продолжения теста. В таких случаях очень удобно проверять мягкими ассертами (Soft Assert поддерживаются с jUnit5 и в testNG). Которые не останавливают тест, но фейлят в самом конце. Таким образом можно ловить сразу несколько ошибок.
Какая чушь. ИИ стоит больше использовать в сложных ситуациях, а не при каждом случае. Тестировщик просто отупеет если все будет за него делать ИИ.
уж если про сравнение картинок то лучше https://opencv.org/ ничего нет. только отчеты надо самому делать.
это получается 1 тест за 4 мин 20 сек. как то немало.... особенно для андроида.
2) Android Studio теперь имеет удобный UI инспектор (Layout Inspector)
3) не вижу редакторов, например IntelliJ
а почему просто увеличить количество параллельных тредов в наборе?