не подтвердилось ?

на реплай твоего сообщения тоже собачка светиться будет, пока прочитанным не отметится

Всем привет. Коллеги, кто шардит/параллелит мобильные тесты на апиуме? Что для этого используете ?

Grid + testng

И сильно с бубном плясать приходится?

Ну сейчас уже нет) (про андроид), ios не трогал ещё.

Как я понимаю, ты просто кормишь пачку тестов под определенные настройки гриду, а он уже сам там раскидывает? Или на уровне testng раскидывается и кидается через грид уже на нужную ноду?

К гриду цепляются аппиум сервера сконфигуренные под каждый девайс, в тестнг файлике у сьюта прописываются что тесты выполняются параллельно , где каждый тест это девайс + классы с выполняемыми тест кейсами. Когда инициализируется драйвер указывается порт грида, он там уже раскидывает действия между всеми

ок, спасибо

Пасибо, как раз тоже искал такую инфу!

рад помочь

А есть извращенцы, кто делал все тоже самое, но с Jbehave?)

Друзья, а кто где фрилансит? Возможно эта тема обсуждалась, но поиск по чату ничего кроме "фриланс плохо и нигде не найдёшь" не нашёл. Пытался откликаться на upwork, но там что-то совсем глухо. Прошу прощенья, если эта тема уже была

utest ?

там вообще дико специфичные вакансии вроде "QA with <некий очень специфичный девайс> from <далёкая страна> needed

Мне кажется upwork - самый живой вариант

Друзья, а кто где фрилансит? Возможно эта тема обсуждалась, но поиск по чату ничего кроме "фриланс плохо и нигде не найдёшь" не нашёл. Пытался откликаться на upwork, но там что-то совсем глухо. Прошу прощенья, если эта тема уже была

Привет, test io, ещё можно попробовать.

Друзья, а кто где фрилансит? Возможно эта тема обсуждалась, но поиск по чату ничего кроме "фриланс плохо и нигде не найдёшь" не нашёл. Пытался откликаться на upwork, но там что-то совсем глухо. Прошу прощенья, если эта тема уже была

Upwork. Но нужно постараться, чтобы попасть с заказом, конечно. Дальше можно остаться с одним заказчиком надолго

Друзья, а кто где фрилансит? Возможно эта тема обсуждалась, но поиск по чату ничего кроме "фриланс плохо и нигде не найдёшь" не нашёл. Пытался откликаться на upwork, но там что-то совсем глухо. Прошу прощенья, если эта тема уже была

Ещё есть топтэл, вдруг пройдёшь :)

это что?

Ещё есть топтэл, вдруг пройдёшь :)

это что?

а телеге есть реплаи )

это что?

Это ресурс випфрилансеров высокого профиля так сказать. Всякие индусы на 30 баксов/ведро не проходят.

это что?

Это такая иностранная "элитная" галера.

Это ресурс випфрилансеров высокого профиля так сказать. Всякие индусы на 30 баксов/ведро не проходят.

Я бы не назвал топтап ресурсом для фрилансеров. Это обычный такой бодишоп.

это что?

А t-systems уже не устраивает?)

А t-systems уже не устраивает?)

ну почему же, выходных пока слишком много)

Дамы и господа, возможно подскажете, adb logcat в txt файл в какой кодировке пишет ?

utf-8 вроде

предполагаю что нет, ибо если читать лог через BufferedReader, он может кинуть эксепшен на кодировку

Есть вопрос к вам. Синтаксис Oracle Sql отличается от MySql?

да

Коллеги, возвращаясь к утреннему вопросу. Есть Appium+Java+Selenium Hub. Есть условные 4 одинаковые мобилы с одной версией Андроид и есть условные 4 теста которые необходимо запустить по 1 на каждой мобиле. Кто-нибудь такое реализовывал? Если да, то как? Собрав в кучу всю инфу, складывается ощущение, что без написания своего сервиса управления всем этим зоопарком тут не обойтись(

не работал с аппиумом, но по теории тесты запускаются из специального апк в котором сидит инструментатион раннер и сами тесты. Для их запуска юзается что-то такое. adb shell am instrument -w -e class com.loloru.automation.$1#$2 com.loloru.automation/android.support.test.runner.AndroidJUnitRunner

adb можно передать айди девайса через ключ -s

Коллеги, возвращаясь к утреннему вопросу. Есть Appium+Java+Selenium Hub. Есть условные 4 одинаковые мобилы с одной версией Андроид и есть условные 4 теста которые необходимо запустить по 1 на каждой мобиле. Кто-нибудь такое реализовывал? Если да, то как? Собрав в кучу всю инфу, складывается ощущение, что без написания своего сервиса управления всем этим зоопарком тут не обойтись(

1. Под каждый девайс стартуется свой аппиум на своём порту. 2. Каждый аппиум регистрируется как нода в selenium hub 3. Параллелим тесты на тестраннере (Junit? TestNG? или что у вас), отправляем на Hub 4. ??? 5. Profit

1. Под каждый девайс стартуется свой аппиум на своём порту. 2. Каждый аппиум регистрируется как нода в selenium hub 3. Параллелим тесты на тестраннере (Junit? TestNG? или что у вас), отправляем на Hub 4. ??? 5. Profit

Вот у меня сейчас затык на п.3 У меня Jbehave (извращенный junit).

Логически я понимаю, что их нужно разделить на пачки с флагом какого-либо общего признака апиум нод, потом кинуть в грид и грид сам раскидает по нодам, которые соответствуют признаку

хм. а зачем этот признак? по-моему их просто запускаешь в N потоков и отправляешь на грид. Очередной поток приходит на грид и говорит «дай сессию». Грид смотрит, есть ли у него есть свободные ноды и отправляет поток на конкретную ноду либо ставит в очередь

или в гриде ещё браузеры?

ну как минимум чтобы разделять разные версии ОС

Например на гриде может висеть 15 абсолютно разных девайсов, я хочу только самсунги или только Android 7. Значит мой тестовый фреймворк должен знать, какие ноды отвечают этому признаку

И опять же получается, что нужно пилить отдельный сервис под зоопарк

при регистрации аппиума в гриде указываются browserName, version, platform - при создании сессии можно указывать в capabilities требуемые значения

если этого мало, можно custom capability matcher написать и в грид подключить, это не оч много писать

Вопрос по Jenkins'у и Groovy postbuild Раньше работал Groovy postbuild в post-actions, который запускался для всей матрицы и для matrix parent Сейчас заметил, что этот groovy postbuild больше не запусается для matrix parent, хотя галочка стоит и ничего не менялось. Для thread'ов самой матрицы запусается, а вот для matrix parent нет... Есть догадки почему такое может быть и почему перестало запускаться?

Кстати, небольшой статистический опрос, исключительно из любопытства. Скажите мне, господа тестировщики и сочувствующие, кто из вас намеренно (и осознанно) задействует в ходе тестирования своих продуктов legacy-данные? Ну, и как вы подходите к выборке (или генерации) подобных данных - тоже интересно было бы послушать.

что в твоем понимании legacy данные? которым пара лет?

есть подозрение , что retention rate ( для тестов - актуальность этих данных для вопроизводимости кейса на с прода на тестовом, например) данных для теста у каждого свой. Очень сильно зависит от специфики

Есть отдельная (и с большего неработающая :) ) группа тестов на перенос легаси-сущностей в новую версию решения. Данные есть живые, поэтому генерировать не надо, с выборками проблем нет. Есть проблемы с их валидностью, т.к. за время их существования - там образовалась полный колапсец.

что в твоем понимании legacy данные? которым пара лет?

Это тоже вопрос, который меня интересует. По сути это может быть от 1 релиза до N версий назад. Но да, на данных которым пара лет это особенно чувствуется.

Легаси данные? У нас каждый тест устанавливает свои данные перед тестом. После все очищает

Можешь подробнее кейс с тем что данные устаревают описать ?

в текущей ситуации чтобы функционально протестировать, я сам генерирую данные. Легаси данные в функциональных тестах не участвуют, но прокачиваются ими на стейджинге

Ну смотри, у тебя есть определенная модель, структура и флоу данных в приложении. Любое изменение, меняющее эти вещи, по сути требует или обработки обратной совместимости, или миграции старых данных на обновленный формат. Шанс того, что в определенный момент эти условия не были соблюдены - довольно высокий, следовательно есть шанс поиметь в базе неконсистентные данные. (Условно: null там, где поле обязательно, некорректное значение там, где потом прикрутили валидацию, некорректное положение в state machine и прочее)

Соответственно все дальнейшие изменения, вносимые в систему имеют шанс оказаться не рабочими на текущей версии приложения, и в идеальном мире этот кейс тоже должен как-то, вероятно, тестироваться.

для моего на 99% tsql проекта это исключено

А, ясно, у нас тестовые данные хранятся в json. Из него мапятся в thrift объекты и накатываются в базу. Если пошёл рассинхрон. Они просто не спамятся. Не накатятся, и тест упадёт

для моего на 99% tsql проекта это исключено

Мне кажется это весьма ложная уверенность, на самом деле. Если с nullable\not nullable все довольно просто, то с изменениями правил валидации и состояний - это, на мой взгляд, почти не решаемая боль, в плане того, что там иногда даже миграцию нет возможности корректно сделать.

А, ясно, у нас тестовые данные хранятся в json. Из него мапятся в thrift объекты и накатываются в базу. Если пошёл рассинхрон. Они просто не спамятся. Не накатятся, и тест упадёт

Ну, а данные для теста ты берешь откуда? Всмысле это production like данные, или какие-то синтетические, в которых такого и не должно возникать?

все возможно :) какие правила валидации, например?

Для функциональных тестов синтетические. Есть разные стресс тесты на основе прод данных. Но мы их так же раскладываем в json ы под thrift объекты. В случае изменения делаем миграцию данных

все возможно :) какие правила валидации, например?

Ну, самый банальный пример: у нас на одном из проектов не было валидации Date of Birth (т.е. оно должно было быть датой и not null), а потом появилось ограничение на over18. Или всякие min\max количество символов в имени.

Ну логично поправить все их :)

Ну, а как ты предлагаешь "поправить" DOB пользователю, у которого там, условно 01.01.0001?

Проставить минимально-требуемую - некорректно, с точки зрения бизнес логики.

Ну если это не функциональный тест , то да любую подходящую дату

Если функциональный то уже в зависимости от проверок

Ну, в тестах-то можно править всё, что угодно, это да. :)

Я имел ввиду, что в продакшене-то ты это не поправишь (т.к. это некорректно так данные корежить по своему усмотрению), следовательно по сути - такие изменения в прод катить нельзя.

окей, как проблема изменения бизнес требований помешает тебе протестировать это?

Вообще получается что во время тестирование выявлены данные которые нужно смигрировать по какой то бизнес логике

в конечном счете ты какой-то default на not null поле должен будешь проставить

И на проде тоже

прогнать UPDATE на таблицу и обновить null поля

окей, как проблема изменения бизнес требований помешает тебе протестировать это?

Чуть выше ответил: Про тестирование тут другой момент, что в рамках текущей (или N последних) версий Date of Birth из будущего некорректен. Следовательно в относительно "свежих" данных ты этого не найдешь.

дальше уже для актуализации данных на фронте маркером по минимальному трешолду времени проси\ не проси юзверей указать корректную дату

Вы радостно выкатываетесь, а потом выясняется что у пачки Legacy пользователей, которым N лет, в Date of Birth абы что (потому что валидации не было) и это ломает приложение.

для этого и делаются миграции

сначали миграции - потом накат логики. золотое правило деплоя

Ты можешь гарантировать что за весь жизненный цикл твоего продукта разработчики не пропустили ни одной миграции там, где менялась модель данных?

нет, конечно, если я не был на этом проекте когда фича релизилась