Все правильно! Надо ждать нужный экран, а не ставить слипы. Со временем это придет. Когда тестов станет 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
iOS медленнее соглашусь, Android скорость такая что пытается тапать кнопку на экране, пока она еще появляется. Решается отрубанием анимации. Это кстати и для iOS помогает немного.
У нас 900+ тестов, 25 тел (12 iOS + 13 Андроид). По ночам бегают около 700 (1400 на две платформы) при релизах все. У нас много долгих тестов (например 2 платежа в тесте с заполнением кучи полей). Вообщем вполне сносно все 1800 (900 на обе платформы) бегут за 3.5 часа Андроид и немного дольше iOS.
C фермами типа browserstack заморачиваться не стали (наша ферма окупается за 3 месяца если выбирать планы с 20+ параллельными тел против самой дешевой фермы).
Я бы порекомендовал добавлять описание ошибки. Вот у нас я автомачу мобильные тесты один, а юзают их все манульщики. И писать 2 <> 3 не совсем ясно, что такое 2 и почему 3. Ошибки должен понимать человек кто видит продукт первый раз.
И еще я не вижу мягкие ассерты, которые не останавливают тест. Это очень удобно когда тест флоу бежит до конца и накапливает сбор мелких ошибок.
2) это не НА каждый, а ПОСЛЕ каждого. нету смысла искать мгновенно элементы другой страницы
3) Аппиум аннотации типа @iOSXCUITBy, @AndroidBy и т.д. (их много) также имеют ожидания. Не помню по умолчанию, я заменяю его на свое 20сек. Ну а когда мне нужно короче (часто проверить что нету элемента) то уменьшаю и потом восстанавливаю. Пример
только после
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
а почему просто увеличить количество параллельных тредов в наборе?
Сейчас самый важный плагин это - ChatGPT for Google!
интересно, а в чем у вас состояла " настроили ферму на Mac OS хосте " ?
мы просто подключили хаб на 20 портов к макМини.
iOS медленнее соглашусь, Android скорость такая что пытается тапать кнопку на экране, пока она еще появляется. Решается отрубанием анимации. Это кстати и для iOS помогает немного.
У нас 900+ тестов, 25 тел (12 iOS + 13 Андроид). По ночам бегают около 700 (1400 на две платформы) при релизах все. У нас много долгих тестов (например 2 платежа в тесте с заполнением кучи полей). Вообщем вполне сносно все 1800 (900 на обе платформы) бегут за 3.5 часа Андроид и немного дольше iOS.
C фермами типа browserstack заморачиваться не стали (наша ферма окупается за 3 месяца если выбирать планы с 20+ параллельными тел против самой дешевой фермы).
Молодцы!
У нас примерно тоже только Appium + Java + TestNG + Allure.
Из плюсов на Java можно писать умопомрачительные локаторы
пример теста:
Видео всех тестов вставляем в отчет тоже.
Поделитесь для сравнения количеством тестов и скоростью выполнения. Спасибо.
аааааа. ну это прямо основы математики которые в банке должен знать каждый!
ЗЫ Про Excel или расчеты на калькуляторе пару значений это вы точно сказали. Отвык народ работать руками.
что то не понятно... почему сразу не использовать?
и подобно остальные переменные. тогда никаких "хвостов" не будет.
Я бы порекомендовал добавлять описание ошибки. Вот у нас я автомачу мобильные тесты один, а юзают их все манульщики. И писать 2 <> 3 не совсем ясно, что такое 2 и почему 3. Ошибки должен понимать человек кто видит продукт первый раз.
И еще я не вижу мягкие ассерты, которые не останавливают тест. Это очень удобно когда тест флоу бежит до конца и накапливает сбор мелких ошибок.
1) Step это от Allure - https://docs.qameta.io/allure/#_testng
2) это не НА каждый, а ПОСЛЕ каждого. нету смысла искать мгновенно элементы другой страницы
3) Аппиум аннотации типа @iOSXCUITBy, @AndroidBy и т.д. (их много) также имеют ожидания. Не помню по умолчанию, я заменяю его на свое 20сек. Ну а когда мне нужно короче (часто проверить что нету элемента) то уменьшаю и потом восстанавливаю. Пример
где isLoaded проверяет за МАКС время есть или нет + восстанавливает значение по умолчанию. Понятно что максимум искать будет только если нету.