Да — фраза не самая упорядоченная ) На деле речь про то что помимо end 2 end тестов в эту систему загружаются и интеграционные rest тесты и некоторые тесты, написанные и запускающиеся как java unit тесты, но являющиеся на деле интеграционными. Отдельный разговор — насколько правильно писать такие тесты, но пока мы стремимся к тому, чтобы получить полную картину по нашим автотестам
Тут на самом деле несколько аспектов
1. Хаб так или иначе держит таблицу доступных нод и постоянно обменивается с ними данными, пишет логи итп. (видимо действительно что-то из этого он делает неоптимально). Наш прокси, при этом, крайне легковесный, и его реализация изначально позволяет бесконечно масштабироваться за балансером.
2. При этом, как показали наши опыты, действительно есть предел производительности хаба, который, видимо, пропорционален железу. На небольших машинках в облаке 2хядерный хаб плохо держит более 20 нод. (ранее у нас была клиентская балансировка и хабы стояли на железе, тогда было просто 16 хабов и отдельные ноды)
3. Мы не изучали подробно внутреннюю архитектуру хаба, тк на данном этапе переписывать и оптимизировать хаб своими силами не входило в наши планы. Держать свою кастомную реализацию хаба мы не хотели тем более.
4. При этом одной из задач, которую мы решали, являлась задача повышения надежности. Один хаб, выходя из строя, тащит за собой весь грид. Два — половину.
5. Организовав конфигурацию с большим количеством машин, содержащих хаб и 5 изолированных нод, мы решили сразу три задачи — строго лимитировали нагрузку на один хаб, убрали фактор хаба как точки отказа и при этом остались в рамках стандартных непатченных selenium артефактов.
Этот подход про регрессионное тестирование, про то чтобы заменить или писать меньше регрессионных автотестов.
Когда много изменений неизбежно придется проверять иначе
нормально настроенный HAXM не дает какого-то такого проигрыша в производительности чтобы целенаправленно переходить на Genymotion. Но это вовсе не значит что вам или еще кому-то надо переходить на SDK эмулятор если вам подходит и удобен genymotion
По опыту с автотестированием, SDK и Genymotion — это практически одно и тоже по части скорости и совместимости с приложениями.
Вот BlueStack интересен тем что у него при той же скорости выше совместимость, например в отличие от любого другого андройдного эмулятора BlueStack умеет принимать звук на вход без искажения. Но вот управлять приложением из тестов в BlueStack у нас не получилось
В общем-то в сравнении скриншотов меньше магии чем кажется. В рамках одного браузера в фиксированном окружении процесс вполне детерминированный и одинаковые скриншоты стабильно совпадают. При этом, конечно, сравнивать скриншоты, сделанные в разных браузерах, так просто не удастся, но и не очень нужно.
Обычно достаточно сравнения старой и новой версии в рамках одного браузера, при этом можно провести такое сравнение отдельно для каждого браузера.
Селениум/Вебдрайвер просто использует реальные браузеры. Для различных браузеров есть драйверы и при запуске тестов можно выбрать с каким браузером взаимодействовать
Занятно, что в интернете в основном и встречаются по этой теме SaaS предложения. При этом, если на сервисе есть автотесты и есть кому их писать, то сделать такую систему у себя не представляется слишком уж сложной задачей.
Так или иначе основные интересные вопросы — это
1. Выбор функциональности для мониторинга, не все имеет смысл мониторить
2. Работа с большим потоком результатов и их фильтрация
3. Интеграция информации от таких мониторингов в общую картину
Ну и, как я уже писал ранее, интересно как такой вид проверок приживается в различных командах разработки и как дополняет/конкурирует с более низкоуровневыми мониторингами
Друзья-коллеги подсказывают что существует понятие Synthetic monitoring, хотя не похоже что термин основательно укоренился.
Также в статьях есть такие ключевые слова как Top Down monitoring и Real user monitoring
Про опыт в различных проектах и компаниях было бы очень интересно прочитать в комментах.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
1. Хаб так или иначе держит таблицу доступных нод и постоянно обменивается с ними данными, пишет логи итп. (видимо действительно что-то из этого он делает неоптимально). Наш прокси, при этом, крайне легковесный, и его реализация изначально позволяет бесконечно масштабироваться за балансером.
2. При этом, как показали наши опыты, действительно есть предел производительности хаба, который, видимо, пропорционален железу. На небольших машинках в облаке 2хядерный хаб плохо держит более 20 нод. (ранее у нас была клиентская балансировка и хабы стояли на железе, тогда было просто 16 хабов и отдельные ноды)
3. Мы не изучали подробно внутреннюю архитектуру хаба, тк на данном этапе переписывать и оптимизировать хаб своими силами не входило в наши планы. Держать свою кастомную реализацию хаба мы не хотели тем более.
4. При этом одной из задач, которую мы решали, являлась задача повышения надежности. Один хаб, выходя из строя, тащит за собой весь грид. Два — половину.
5. Организовав конфигурацию с большим количеством машин, содержащих хаб и 5 изолированных нод, мы решили сразу три задачи — строго лимитировали нагрузку на один хаб, убрали фактор хаба как точки отказа и при этом остались в рамках стандартных непатченных selenium артефактов.
Когда много изменений неизбежно придется проверять иначе
Вот BlueStack интересен тем что у него при той же скорости выше совместимость, например в отличие от любого другого андройдного эмулятора BlueStack умеет принимать звук на вход без искажения. Но вот управлять приложением из тестов в BlueStack у нас не получилось
Обычно достаточно сравнения старой и новой версии в рамках одного браузера, при этом можно провести такое сравнение отдельно для каждого браузера.
Так или иначе основные интересные вопросы — это
1. Выбор функциональности для мониторинга, не все имеет смысл мониторить
2. Работа с большим потоком результатов и их фильтрация
3. Интеграция информации от таких мониторингов в общую картину
Ну и, как я уже писал ранее, интересно как такой вид проверок приживается в различных командах разработки и как дополняет/конкурирует с более низкоуровневыми мониторингами
Также в статьях есть такие ключевые слова как Top Down monitoring и Real user monitoring
Про опыт в различных проектах и компаниях было бы очень интересно прочитать в комментах.