2) все tap(el), setInput(el, value), getText(el)... со всех страниц ведут в 1 единственную функцию для каждого действия. например все tap ведут одну функцию. Это супер удобно. Во первых можно поправить в одном месте КАК тап делаем и везде меняется. Во вторых после ACTION действий типа тап, которые приводят к изменениям удобно добавить маленькую паузу (я использую 150ms). Это значительно повышает надежность.
3) как видно из примера оборачивание дает также название действия для Allure отчета + логирования. это все крайне полезно особенно если бегут много тестов одновременно.
пример в Allure как видно
все действия понятны любому QA
плюс в обертке мы пишем человекочитаемые ошибки типа:
т.е. это не ХЗ какой-то элемент со стактрейсом который мануальщикам ничего не говорит, а понятная ошибка.
Эти действия приводят в легкому чтению результатов тестов любым сотрудником.
А вы аппелируйте к тому, что тесты НЕ должны все все покрывать. Ибо система которая тестирует любое приложение на 100% всегда сложнее самого приложения.
Кому надо, чтобы затраты на тестирования были больше создания? Есть конечно варианты: космос, медицина, системы управления - если ваша апка к ним не относится, вы не должны покрывать все случаи. Это дорого.
Это проблема того, что девы не видят выхлопа тестов. В противном случае они сохраняют идшки, зная что могут быть причиной падений тестов.
Ну а поправить идшки в форме это вообще не проблема. Вот если меняется флоу, то сложнее. Тут все зависит как написаны тесты, поправить в 1 месте не проблема.
Вначале я сам ставил идшки в ios коде. Через пол года, когда авто тесты стали находить быстро регресии, програмисты сами стали помогать и сохранять идшки.
Сейчас у нас 870 тестов мобильных тестов под ios и столько же под android.
Представьте как обслуживать это? Так вот у нас всего 2 авто тестера на эти мобильные, апи (сейчас очень много его), веб и т.д.
Все зависит от того как написано, так и обслуживаться будет.
все верно! я видел толпы автоматчиков, работу которых никто в фирме не понимает, кроме них самих.
1) любые тесты должны быть такими, чтобы их запускали ВСЕ члены команды. Мануальщики в первую очередь, программеры во вторую, а сами автоматчики в последнюю.
2) качество описания ошибки в тесте должно быть таким, чтобы ваша жена (врач, учитель и т.д.) поняли не зная вашего продукта. Не поняли, вы показываете стактрейс или строку кода, где упало - это никому не понятно и не нужно кроме вас самих.
3) наличие видео крайне повышает комфортность и полезность (хотя вначале так не кажется пока не начнешь пользоваться). Ясно, что с АПИ так не получится, а вот web + mobile видео обязательно давно.
4) большинство регрессий должно быть найдено, до того как мануальщики пытаются скачать новый билд и запустить (грубо. понятно что скажем мобильные тесты помедленнее).
Я начал проставлять айдишки в приложении iOS сам. Позднее девелоперы увидев помогли сделать генерацию всех айдишек автоматически если билд не релиз или не продакшн.
Мы выбрали тел Nokia. Простые тел с чистым Андроидом. Мин проблем и дешевые (150-300 Евро у нас).
Тел стоят на алюминивых подствках. Не перегреваются. На всех тел вырублена анимация. На всех установлен один гуугло эккаунт где уже синхронизируются данные тестирования (контакты например) + отрублены все сервисы как запоминания паролей, перевод и т.д.
Хотя иногда некоторые (в основном отваливаются. редко но бывает.) вышеописанные проблемы бывают.
Модель не указана но! Вот такое заметил: была стиралка на 6кг сломалась и поменял на 10кг. У новой вес 97.5кг. Стоит мертво. Если старая еще пыталась перемещатся, то новая как монолит. Вибрации вообще не чуствую.
Привет.
1) по скроллу я написал гайд -> http://appium.io/docs/en/writing-running-appium/tutorial/swipe-tutorial/ . только немного уже устарел сам тап. правильнее уже использовать http://appium.io/docs/en/commands/interactions/actions/
2) все tap(el), setInput(el, value), getText(el)... со всех страниц ведут в 1 единственную функцию для каждого действия. например все tap ведут одну функцию. Это супер удобно. Во первых можно поправить в одном месте КАК тап делаем и везде меняется. Во вторых после ACTION действий типа тап, которые приводят к изменениям удобно добавить маленькую паузу (я использую 150ms). Это значительно повышает надежность.
3) как видно из примера оборачивание дает также название действия для Allure отчета + логирования. это все крайне полезно особенно если бегут много тестов одновременно.
пример в Allure как видно
все действия понятны любому QA
плюс в обертке мы пишем человекочитаемые ошибки типа:
т.е. это не ХЗ какой-то элемент со стактрейсом который мануальщикам ничего не говорит, а понятная ошибка.
Эти действия приводят в легкому чтению результатов тестов любым сотрудником.
Ну и видео дополняет картину.
Красивее я имел ввиду чтобы действия вели или на ту же страницу или на следующую. Таким образом очень удобно писать тесты не прерывая типа:
по статик импорту не понял вопроса. не вижу его. вот пример всех импортов с какого-то теста:
а вот пример импортов с PageObject (тут только логирование из статиков):
Kaspresso представил удобную обертку, зато за Аппиумом поддержка всех платформ.
За что мне нравится Аппиум:
поддержка всех платформ. пишем тест 1 раз
поддержка умопомрачительных возможностей поиска элементов
видео тоже есть
у нас 900 тестов под обе платформы (iOS + Android)
кол-во автотестеров сейчас 1 (было 2. второй ушел на другой проект сейчас)
запускают тесты все мануальщики
ноль проблем со стабильностью. у нас больше проблема в стабильности сервера из-за наличия многих ThirdParty сервисов.
Пример поиска элементов прям с кода:
PS ах да. я бы посоветовал код писать чуть красивее типа -> (сек прям с кода...)
где например:
Мне симпатизирует ваша точка зрения, но иного выхода как блокада ресурсов я не вижу.
Вот вы как предлагаете действовать в данном случае?
Неправда. Мы недавно джуниора из Пакистана вытащили. Уже почти месяц у нас. Всем довольны. Толковый, быстро учится, минимальный надзор.
Сейчас конечно больше кандидатов толковых с России едет и стало временно проще.
Многие знакомые годами народ у нас в Эстонии найти не может. Слишком много стартапов у нас и бегают по кругу все подымая зарплаты и плюшки.
oi пропустил.
java + maven + testNG + appium + allure reporter.
А вы аппелируйте к тому, что тесты НЕ должны все все покрывать. Ибо система которая тестирует любое приложение на 100% всегда сложнее самого приложения.
Кому надо, чтобы затраты на тестирования были больше создания? Есть конечно варианты: космос, медицина, системы управления - если ваша апка к ним не относится, вы не должны покрывать все случаи. Это дорого.
Это проблема того, что девы не видят выхлопа тестов. В противном случае они сохраняют идшки, зная что могут быть причиной падений тестов.
Ну а поправить идшки в форме это вообще не проблема. Вот если меняется флоу, то сложнее. Тут все зависит как написаны тесты, поправить в 1 месте не проблема.
Вначале я сам ставил идшки в ios коде. Через пол года, когда авто тесты стали находить быстро регресии, програмисты сами стали помогать и сохранять идшки.
Сейчас у нас 870 тестов мобильных тестов под ios и столько же под android.
Представьте как обслуживать это? Так вот у нас всего 2 авто тестера на эти мобильные, апи (сейчас очень много его), веб и т.д.
Все зависит от того как написано, так и обслуживаться будет.
все верно! я видел толпы автоматчиков, работу которых никто в фирме не понимает, кроме них самих.
1) любые тесты должны быть такими, чтобы их запускали ВСЕ члены команды. Мануальщики в первую очередь, программеры во вторую, а сами автоматчики в последнюю.
2) качество описания ошибки в тесте должно быть таким, чтобы ваша жена (врач, учитель и т.д.) поняли не зная вашего продукта. Не поняли, вы показываете стактрейс или строку кода, где упало - это никому не понятно и не нужно кроме вас самих.
3) наличие видео крайне повышает комфортность и полезность (хотя вначале так не кажется пока не начнешь пользоваться). Ясно, что с АПИ так не получится, а вот web + mobile видео обязательно давно.
4) большинство регрессий должно быть найдено, до того как мануальщики пытаются скачать новый билд и запустить (грубо. понятно что скажем мобильные тесты помедленнее).
это проблема кривых рук автотестеров (чаще) и окружения (реже).
у крупных городах не у всех дома есть возможность ставить на зардку на ночь. замена батареи решает кучи проблем:
батарея меняется за 1-3 мин
легко заменить 50 - 70 -100 - 150 kW (как пожелаешь на станции)
легко утилизировать - не надо разбирать машину
нет проблем с гарантией на батарею
А у нас был похожий опыт!
Я начал проставлять айдишки в приложении iOS сам. Позднее девелоперы увидев помогли сделать генерацию всех айдишек автоматически если билд не релиз или не продакшн.
пример:
таким образом автоматом были доступны мне (я на аппиуме пишу) хоть какие-то ид чтобы писать не зализая в код iOS.
сейчас я уже не часто меняю сгенеренную идшку на свою (тут в примере - `balanceLabel`).
метод уже прижился в нескольких фирмах. реализация правда сделана чуть по разному.
но в обоих меняю ид (если надо) крайне удобно добавив '.id("myID")' к любому элементу:
вот такой опыт.
Кстати по поводу одиноковых элементов в Аппиуме прекрасные варианты как искать типа:
Так они регулярно каждую неделю новый слепок в staging делают.
кстати идею подсказали! сделал ребуут телефонов джобу на 7 утра. все одной проблемой меньше.
есть но шарить не могу без согласия фирмы. частично как это было давно тут
сейчас уже у нас 24 тел: 12 iPhone + 12 Nokia на том же столе.
Мы выбрали тел Nokia. Простые тел с чистым Андроидом. Мин проблем и дешевые (150-300 Евро у нас).
Тел стоят на алюминивых подствках. Не перегреваются. На всех тел вырублена анимация. На всех установлен один гуугло эккаунт где уже синхронизируются данные тестирования (контакты например) + отрублены все сервисы как запоминания паролей, перевод и т.д.
Хотя иногда некоторые (в основном отваливаются. редко но бывает.) вышеописанные проблемы бывают.
Некоторые фирмы просто делают зеркало прода, только с обфускацией данных пользоветелей. Тоже выход.
Модель не указана но! Вот такое заметил: была стиралка на 6кг сломалась и поменял на 10кг. У новой вес 97.5кг. Стоит мертво. Если старая еще пыталась перемещатся, то новая как монолит. Вибрации вообще не чуствую.
Фирма - AEG.
Не знаю какие у вас требования но где я работал максимум анинимизированный прод клали на тест и уже на нем тестили.
Еще прокатывало создание счета без каких либо транзакций.
Все остальное боялись проверок.
Я говорю о больших скандинавских банках.
Это все крайне скудный набор. А я упомянул как раз про сильные ограничения. Создания пользователей, выдача карт и т.д.
Поэтому и сказал что не разгонишься.
А перевод и лирика это конечно легко и на Проде. Но этого крайне мало и не проверяет важную бизнес логику.