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

помечайте тэгами какая проверка для какого устройства?

и параллельно открывайте например три списка при параллельном тестировании на трёх устройствах?

тест-кейсы поддерживать это и так уже головная боль, и без всяких интерактивных картинок

а с картинками тестировщик наверное 100% своего времени будет тратить на поддержку этой "красоты"

 

 

ну не парсер..

и не тест, и не парсер а неведома зверюшка

 

 

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

пробуйте Cypress, Puppeteer, TestCafe

попробуйте другие подходы чем Селениум

по описанию всё равно у Вас скорее всего парсер сайтов а не тест

не надо ничего останавливать

waitForElementPresent и потом делайте что надо

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

так что перед кликом просто скрольните страничку используя вызов джаваскрипта (гуглится)

 

Но с карточкой работают поочередно то юзер1, то юзер2:

юзер1 карточку создает

юзер2 на своей стороне её видит, заходит в нее, что-то в ней делает и продвигает дальше

юзер1 видит изменения, соглашается с ними и продвигает дальше.

И так далее по процессу.

вот и пишите отдельные тесты для каждого "продвижения по процессу"

в первом тесте юзер1 создает карточку, тут же после теста карточка удаляется через РЕСТ АПИ

во втором тесте через РЕСТ АПИ карточка создается, юзер2 что-то в ней делает и продвигает дальше, карточка удаляется через РЕСТ АПИ

в третьем тесте через РЕСТ АПИ карточка создается и продвигается в нужный статус, юзер1 соглашается и продвигает, карточка удаляется через РЕСТ АПИ

и так далее

 

 

Ведь при тестировании вручную мы так и делаем

автоматизированное тестирование очень сильно отличается от ручного

 

 

Соответственно, с одной карточкой могут работать 2 юзера одновременно

к всеобщему счастью Вашей команды, никакой одновременности тут нет

один тест проверяет например создание заказа клиентом, а другие тесты проверяют обработку уже созданного заказа, по одному тесту на каждый переход

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

вот их и пишите

ну и компонентные тесты для самих "карточек"

ОП наверное делает запускалку для парсера веб-сайтов, и пытается прикрутить фреймворки для тестов, которые конечно же для этой цели не подходят

 

 

Ну, если не использовать ассерты, то почему бы и нет? ))))

"нет" потому что это два совершенно разных подхода

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

а тесты запускаются по пушу и должны "падать" при фейле

может для одного парсера такой "колхоз" и прокатит, ведь можно "допилить", но когда парсеров много это уже будет серьёзная головная боль

ну если тестировщик может таскать мобилку, то наверное и планшет или небольшой ноут тоже сможет?

хотя вот даже приложение мобильное есть:

https://apps.apple.c...-qc/id663798484

можно просто выдать тестировщикам недорогие линуксовые ноутбуки либо Хромбуки, и с помощью веб-браузера через мобильный интернет через ВПН они бы открывали веб-интерфейс Quality Center и там бы работали

и изобретать ничего не надо :)

необязательно ставить именно НА устройство, можно просто поставить рядом

лайфак:

можно взять хромбук 2в1 типа Yoga и поставить его рядом с банкоматом на подставку для нот :) а благодаря возможности трансформации его можно использовать и как ноутбук и как планшет

 

 

Планшет и мобилку - может. А ноут - не сможет.

зайдите в магазин и покрутите в руках трансформер типа Lenovo Yoga Chromebook у которого экран открывается на 360 градусов, трансформируя в планшет. Очень удобно - когда надо например чекбоксики ставить на тестах его можно использовать как планшет, а когда надо завести баг - можно за секунду трансформировать в ноутбук. Есть компактные модели 11 дюймов, тот же планшет

ещё большой плюс что у них ARM процессоры, поэтому работать с таким ноутом можно 10 часов в поле на одном заряде

 

 

Но самое простое - прямой доступ в БД из Excel. И уж там... Такие отчеты можно строить!

а потом это решение упадет после первого же апгрейда Джиры

 

 

все img с alt

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

да тут не надо быть и экстрасенсом, эта ошибка легко гуглится

просто напишите компонентный тест, вот и все

 

 

Мне нужно написать автотест перетаскивания элемента. 

такого не бывает

если Вы действительно пишете автотесты, то фронтендер должен написать этот юнит тест

а если Вы пишете парсер вебсайтов, то в таком случае делайте запрос через РЕСТ АПИ

в обоих случаях нет никакой надобности для перетаскиваний

 

 

У меня есть функционал перетаскивания секций в браузере. Т.е. можно менять позицию секции относительно других секций. Делается это мышкой в браузере - drag and drop. Я пишу end-to-end тест с использованием Selenium. Т.е. существует кейс "Перетащить секцию", вот его я и хочу выполнить с использованием библиотеки Selenium, так как бы это делал пользователь из браузера.
И у меня возникают описанные проблемы. Ищу вариант решения.

Вы что-то можете подсказать по исправлению моего решения или предложить альтернативное решение? Как выполнить перетаскивание элемента в браузере средствами Selenium?

очень похоже на:

"у меня есть гвоздь. И у меня есть микроскоп. Вот этот вот гвоздь я и хочу забить этим микроскопом"

юнит тест для компонента, который тестируете

 

P.S.

Jmeter конечно бесплатен, но отсутствие централизованного исполнения тестов и хранения собранных метрик/репортов делает его "коныком бэз ногы". Это ни в коем разе не претензия, просто удивляет что за 20 лет с момента запуска проекта и 10-ти лет развития jmeter в его актуальной парадигме, не было придумано какого-то референсного инструмента управления тестированием (ну или плагинов для существующих инструментов) и сборку среды для тестирования надо костылить самому.

Дженкинс есть ведь для этого

 

 

Меня пугает это "сделать все что угодно". Я вообще не понимаю эту одержимость CI/CD, особенно применительно к НТ. Львиная доля осознанной активности по НТ это интерпретация результатов и поддержка\разработка скриптов тестирования. Чисто человеческая работа, с крайне малой долей какой-то внутренней автоматизации. Найти (корень проблемы), раскопать (зависимости), собрать (артефакты), описать (внятно).  На собственно настройку и запуски "прогонов" тратится от силы 5, а то и 1% времени. Работая безымянным пальцем левой ноги приглядывая левым глазом, чтобы не заснуть пока варится кофе(последнее не обязательно) ))) При этом в большинстве случае просто дичайшие зависимости от сторонних систем, когда приходится, чуть ли не в письменной форме согласовывать прогоны со всему вовлеченными сторонами. Чем тут поможет CI/CD? Что изменит автоматический запуск НТ после сборки билда? Что он покажет\докажет без человеческого анализа? Ответ: а ничего ))) Нету таких систем )))

всё это опять же устарело, и системы появились, вуаля

как работает: 

система непрерывной сборки после пуша раскладывает контейнеры аппликации в облаке, нагрузочные тесты опять же облачные нагружают аппликацию, генерируются все необходимые отчёты и опять же складываются в облаке. Огромным плюсом идёт отсутствие "дичайших зависимостей". Если "графики упали" то билд фейлится, программисты получают автоматическую нотификацию и начинают дебажить свой бранч

в это время инженер нагрузочного тестирования спокойно пьёт своё или свой кофе и читает хабр

это наверное пост из прошлого :)

версионирование например уже давно с помощью гита делают :)

все остальное тоже поменялось :)