Comments 9
Мы вот год его использовали, и нам не очень понравилось. Постоянно проблемы с xpath были, тех.поддержка их подтверждала, через 2-3 месяца фиксилось, но появлялись новый проблемы. С SQLite — приложение вообще падало. В итоге — отказались.
Почему тесты занимают такое упоротое (2-4 минуты per test) количество времени на этом скриншоте?
Гоняете ли вы их на CI как часть проверок для каждого пулреквеста и с каким серверным окружением они у вас работают? (я подозреваю, что бекенд вы не мокаете)
Например, самый популярный фреймворк Appium — open-source решение, поддерживающее платформы Android и iOS, — нам не подошел. Наши разработчики использовали много модных библиотек, и взаимодествовать с приложением иногда приходилось на более низком уровне. UI Automator и UI Automation оказались более сложными в развертывании, каждое приложение использовало свой язык для написания тестов, из-за чего возникали проблемы при перераспределении между платформами в команде автотестирования.
И все таки непонятно, почему вам не подошел Appium? Он так же позволяет писать тесты на одном языке программирования для разных платформ и вот это всё, разве что нельзя вызывать нативный код, но это обходится, да и вообще странно брать тул для по сути black-box тестирования и вызывать руками код приложений :) Я не люблю Appium если что, просто интересно.
Спасибо за статью!
1) Каждый тест на скрине это целый тестовый сценарий, в него входит авторизация, оплата, создание шаблона, редактирование, поэтому и 2 минуты (ну и время теста может увеличиваться, когда мы ждем каких-либо экранов и нотификаций)
2) Вот именно вызов нативного кода — очень важно. По-другому в наших приложениях мы не можем получить баланс, суммы оплаты, а без этого тестировать банковское ПО невозможно
3) Запускаем тесты через Jenkins каждую ночью на выделенной машине на реальных девайсах, поскольку взаимодействие идет со всеми тестовыми системами, а по ночам они наиболее стабильны. Так же есть наборы smoke тестов, которые запускаются во время регресса после каждой новой сборки
2) Вот именно вызов нативного кода — очень важно. По-другому в наших приложениях мы не можем получить баланс, суммы оплаты, а без этого тестировать банковское ПО невозможно
3) Запускаем тесты через Jenkins каждую ночью на выделенной машине на реальных девайсах, поскольку взаимодействие идет со всеми тестовыми системами, а по ночам они наиболее стабильны. Так же есть наборы smoke тестов, которые запускаются во время регресса после каждой новой сборки
А как обстоят дела с переходом IOS на XCUITest и, соответственно, с изменением всех локаторов у элементов с UITable, например, на XCUIElementTable? У вас же все xpath станут непригодными. Тот же Appium умеет подстраиваться под это автоматически, достаточно указать automationName = XCUITest, чем ответит SeeTest Automation?:)
У SeeTest нет способа перейти на XCUITest. Зато SeeTest позволяет тестировать iPhone без компьютера с Mac OS. А что вам дал этот переход?
Xpath у вас генерится на основе UIAutomation, он заменен на xcuitest в xcode 8+, значит ли это, что ваши тесты не работают на ios10 (ведь сборку для ios10 поддерживает только xcode 8)?
Вам же все равно нужна макось, чтобы собрать свое приложение перед тестированием:)
Зато SeeTest позволяет тестировать iPhone без компьютера с Mac OS.
Вам же все равно нужна макось, чтобы собрать свое приложение перед тестированием:)
А выбора нет, на ios 10 других способов не имеется, только xcuitest.
Я не сторонник этого подхода для автотестов: простота написания таких тестов иллюзорна.
Но всё равно выбрали такое решение? Неужели профит на столько высокий? Во что выливаются изменения экранов и дерева элементов на них? А изменение flow различных процессов в приложении? Чем не устроил какой-нибудь WDA от Facebook'а в купе с кастомными PageObject'ами?
Sign up to leave a comment.
Автоматизация мобильных приложений с SeeTest Automation