Comments 8
Для быстрой работы того же эмулятора Android требуется x86 сервер с поддержкой HAXVM
Все же эти данные немного устарели. Смотрим например
android-developers.googleblog.com/2018/07/android-emulator-amd-processor-hyper-v.html
Например на машине разработчика с AMD Ryzen и Win10 Pro — вполне себе работает и быстро.
Так на чём вы по итогу остановились?
Вообще очень часто слышу мнение, что автотесты надо переводить в облака, локальная ферма — дорого. Но пока что не нашёл ни одной калькуляции именно в плане цены.
По удобству понятно, не надо поддерживать, можно использовать по запросу и т.д.
Вообще очень часто слышу мнение, что автотесты надо переводить в облака, локальная ферма — дорого. Но пока что не нашёл ни одной калькуляции именно в плане цены.
По удобству понятно, не надо поддерживать, можно использовать по запросу и т.д.
BrowserStack — я отметил как раз, что наш кейс.
1) Специальные функции нам не нужны
2) Нет ограничения по времени, что очень хорошо, так отлаживать тесты можно будет в облаке, не бояться запускать по 5 раз на день тесты во время последнего дня перед релизом.
3) Для нас бонус, но если появится необходимость — то и всё браузерное тестирование удобно перенести на него, например это частично снимет постоянную головная боль из-за Safari (своими кривыми обновлениями) или Edge (необходимость содержать Windows-машины, которыми мы по сути не пользуемся).
Что же касается локальной фермы — смотря что вам надо. Как я уже сказал, большинство ошибок у нас — это общие ошибки, которые легко ловятся на референсных устройствах. А референсное устройство — это либо оно само, либо эмулятор (ну почти). Купить скажем Mac Mini + два телефона — это $2k с небольшим, то есть полгода-год сервиса. В то время как с этим железом легко прожить года 2-3 (если брать последние модели). Ну и локальные устройства — это и возможность параллельного тестирования, и скорость почти втрое большая, чем в облаке.
Но как только появляется необходимость поддерживать специфичные платформы или требуются последние версии устройств (например когда я работал, собственно, над компилятором для Android), то вы столкнётесь с тем, что устройства будут бысто устаревать, нужно будет их постоянно покупать, переустанавливать разные версии ОС на девайс(ы) и прочая. Когда есть сервис, который берёт такую головную боль за себя — это хорошо.
Скажем так, когда у вас людей, проектов и финансов много, свой большой офис — то лучше локальный вариант. Если работа удалённая, и скажем, это стартап, в котором неочевидны сроки, — то лучше сервис.
1) Специальные функции нам не нужны
2) Нет ограничения по времени, что очень хорошо, так отлаживать тесты можно будет в облаке, не бояться запускать по 5 раз на день тесты во время последнего дня перед релизом.
3) Для нас бонус, но если появится необходимость — то и всё браузерное тестирование удобно перенести на него, например это частично снимет постоянную головная боль из-за Safari (своими кривыми обновлениями) или Edge (необходимость содержать Windows-машины, которыми мы по сути не пользуемся).
Что же касается локальной фермы — смотря что вам надо. Как я уже сказал, большинство ошибок у нас — это общие ошибки, которые легко ловятся на референсных устройствах. А референсное устройство — это либо оно само, либо эмулятор (ну почти). Купить скажем Mac Mini + два телефона — это $2k с небольшим, то есть полгода-год сервиса. В то время как с этим железом легко прожить года 2-3 (если брать последние модели). Ну и локальные устройства — это и возможность параллельного тестирования, и скорость почти втрое большая, чем в облаке.
Но как только появляется необходимость поддерживать специфичные платформы или требуются последние версии устройств (например когда я работал, собственно, над компилятором для Android), то вы столкнётесь с тем, что устройства будут бысто устаревать, нужно будет их постоянно покупать, переустанавливать разные версии ОС на девайс(ы) и прочая. Когда есть сервис, который берёт такую головную боль за себя — это хорошо.
Скажем так, когда у вас людей, проектов и финансов много, свой большой офис — то лучше локальный вариант. Если работа удалённая, и скажем, это стартап, в котором неочевидны сроки, — то лучше сервис.
Добрый день, а использовали mobile center? Он тоже есть в облаке aws
Вы, видимо говорите о Microfocus Mobile Center? Нет, не пробовал.
Сами устройства он все равно использует из AWS. По сути, он предоставляет схожий фронтенд из других облачных сервисов, возможно вместе с API, но опять-таки, судя по описанию, снова нужно будет завести парк private devices. То есть, это просто дополнительная плата за фронтенд, который, по сути, нам и не нужен вовсе.
Mobile Center software is a mobile testing and monitoring solution enabling you to test and monitor any mobile app or mobile web page using real devices or emulators. With the small package you can use up to 4 concurrent devices hosted on-premise or by Amazon Device Farm (sold separately).
Сами устройства он все равно использует из AWS. По сути, он предоставляет схожий фронтенд из других облачных сервисов, возможно вместе с API, но опять-таки, судя по описанию, снова нужно будет завести парк private devices. То есть, это просто дополнительная плата за фронтенд, который, по сути, нам и не нужен вовсе.
Microfocus Mobile Center предоставляет гибридное решение с возможностью подключения как локальных устройств, так и облачных ферм типа ADF (Amazon Device Farm). Т.е. можно создать платформу на основе уже имеющихся локальных устройств для их использования всеми пользователями в корпорации, так и арендовать частные устройства в облаке.
Для нас это было критично (банковская среда, облако только в отдельных сегментах). Развернули у себя порядка 50 устройств, в нескольких офисах. Облачные пока не арендовали.
Для нас это было критично (банковская среда, облако только в отдельных сегментах). Развернули у себя порядка 50 устройств, в нескольких офисах. Облачные пока не арендовали.
Да, пример использования Mobile Center я представляю, но в нашем случае оно скорее лишняя надстройка. То есть дополнительное управление устройствами ни локальными, ни удалёнными нам не нужно. По сути, все подключенные устройства \ эмуляторы — лишь параметр вызова тестов. А-ля:
Устройства и их параметры хранятся в конфиг-файлах, так что в зависимости от запрошенного устройства просто выбираются настройки (локальное, эмулятор, удаленное или облачное) и на нем запускаются тесты. Так что логика, которую реализует Mobile Center в какой-то части уже написана нами.
tox py37-stage -- --emulator=False --deviceName="Google Pixel" --browser="Chrome" -k='' -m='critical'Устройства и их параметры хранятся в конфиг-файлах, так что в зависимости от запрошенного устройства просто выбираются настройки (локальное, эмулятор, удаленное или облачное) и на нем запускаются тесты. Так что логика, которую реализует Mobile Center в какой-то части уже написана нами.
Sign up to leave a comment.
Облачные платформы для мобильного тестирования