Добрый день, я действительно выбирал между "Простым" и "Средним" уровнем сложности, смотрел доку хабра, по этой части, как по мне оно где-то между, поэтому остановился на среднем.
Приводятся аналогии и какие-то вещи в сравнение с веб-тестированием, кажется что без понимания процессов в целом, общее понимание статьи может пострадать.
Это да, такие вещи присутствуют. Я очень удивлюсь, если кто-то в целом не подразумевает такое в разработке, ведь бывают критичные обновления не сопоставимые со старыми версиями.
Я почему не добавлял информацию про подобные вещи? Статья больше про тестирование в целом, как будто такие нюансы уже больше к разработке относятся или к углубленному пониманию жизненного цикла, что придет само в моментах обучения и работы как таковой.
Стоит ли это обсуждать конкретно в контексте данной статьи, как будто нет, но в общем и целом, согласен, что знание о такой возможности должно присутствовать =)
Добрый день. Спасибо за комментарий, правда есть неточности, исправлю.
Про xPath спорно, потому-что при условии наличия WebView забыть пока не получается, да и к сожалению, в нативе не всегда есть возможность оперативно разметку получить, поэтому в моменты безисходности, все равно случается его использование. =)
Тут плюс наверное в наличии осей. Если в ClassChain еще как-то можно интерпретировать, то UIAutomator2 c его .fromParrent() уже не на столько гибок.
Flutter, Espresso - да. Можно отдельно ознакомиться, у нас в частности тоже ведутся работы по интеграции. Статья писалась на основании исторически сложившихся технологий, поэтому только то, что полноценно используется.
Вендоры Android и iOS пока не предлагают встроенных инструментов для глубокого визуального тестирования, так как фокусируются на базовой функциональности и безопасности платформ.
Однако экосистема мобильной разработки активно заполняет этот пробел через AI-платформы, облачные сервисы и кастомные решения, по аналогии с нашим, представленным в статье.
Проекты вроде Appium, которые поддерживается сообществом, постепенно добавляют функции для работы с графикой, но они всё ещё требуют доработки и имеют множество ограничений т.к. визуальные требования сильно варьируются между приложениями. Универсальный инструмент потребовал бы гибких настроек сравнения (например, допустимых отклонений в пикселях, исключение областей при сравнении и т.д.), что в целом сложно реализовать.
Со временем может что-то и появится универсальное и кросс-платформенное, но на текущий момент проще развивать свое и интегрироваться с AI в каких-то моментах чтоб снизить процент ручной работы
Добрый день, я действительно выбирал между "Простым" и "Средним" уровнем сложности, смотрел доку хабра, по этой части, как по мне оно где-то между, поэтому остановился на среднем.
Приводятся аналогии и какие-то вещи в сравнение с веб-тестированием, кажется что без понимания процессов в целом, общее понимание статьи может пострадать.
Это да, такие вещи присутствуют.
Я очень удивлюсь, если кто-то в целом не подразумевает такое в разработке, ведь бывают критичные обновления не сопоставимые со старыми версиями.
Я почему не добавлял информацию про подобные вещи?
Статья больше про тестирование в целом, как будто такие нюансы уже больше к разработке относятся или к углубленному пониманию жизненного цикла, что придет само в моментах обучения и работы как таковой.
Стоит ли это обсуждать конкретно в контексте данной статьи, как будто нет, но в общем и целом, согласен, что знание о такой возможности должно присутствовать =)
Huawei, Honor - тоже проблем хватает самых разных, начиная от ADB взаимодействия заканчивая всевозможными отвалами в самых неожиданных местах =)
Несомненно, так и сторов сейчас прибавилось в кол-ве, не только Google и Apple, а скорость обработки обновлений везде разная.
Плюс сюда же, еще один не маловажный фактор, что даже если обновление и пройдет проверку, не все пользователи регулярно обновляют их на телефонах.
Можно даже выделить это, как еще одно отличие с веб 🙃
Спасибо за рекомендацию! 🤗
Добрый день.
Спасибо за комментарий, правда есть неточности, исправлю.
Про xPath спорно, потому-что при условии наличия WebView забыть пока не получается, да и к сожалению, в нативе не всегда есть возможность оперативно разметку получить, поэтому в моменты безисходности, все равно случается его использование. =)
Тут плюс наверное в наличии осей. Если в ClassChain еще как-то можно интерпретировать, то UIAutomator2 c его .fromParrent() уже не на столько гибок.
Flutter, Espresso - да.
Можно отдельно ознакомиться, у нас в частности тоже ведутся работы по интеграции. Статья писалась на основании исторически сложившихся технологий, поэтому только то, что полноценно используется.
Вендоры Android и iOS пока не предлагают встроенных инструментов для глубокого визуального тестирования, так как фокусируются на базовой функциональности и безопасности платформ.
Однако экосистема мобильной разработки активно заполняет этот пробел через AI-платформы, облачные сервисы и кастомные решения, по аналогии с нашим, представленным в статье.
Проекты вроде Appium, которые поддерживается сообществом, постепенно добавляют функции для работы с графикой, но они всё ещё требуют доработки и имеют множество ограничений т.к. визуальные требования сильно варьируются между приложениями. Универсальный инструмент потребовал бы гибких настроек сравнения (например, допустимых отклонений в пикселях, исключение областей при сравнении и т.д.), что в целом сложно реализовать.
Со временем может что-то и появится универсальное и кросс-платформенное, но на текущий момент проще развивать свое и интегрироваться с AI в каких-то моментах чтоб снизить процент ручной работы
Цвет и бальная система с простыми фигурами типа звезд наверное самое простое к осознанию и пониманию
У нас стажировки не только на тестировщиков.
Три направления сейчас:
Тестирование
Разработка
Аналитика
Главное, чтоб студенческий был
Коллеги дальше сориентируют в индивидуальном порядке =)