Привет!

Они присылают извещение за 5 дней. То есть, если экзамен в субботу, то письмо будет только в понедельник.

Если письма не будет, то надо писать по обратной связи, которая есть на сайте. Они обычно отвечают.

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

В адекватных конторах цель одна: посмотреть, как кандидат будет рассуждать.

Если возникают варианты, так и напишите, что в разных условиях будут разные варианты.

Если нет времени проработать разные, выберите какой-то один и обоснуйте, почему.

Можно наоборот: открыть Селениумом, сделать паузу (например, вывести окошко с кнопкой "продолжить", или просто поставить брекпойнт), и в паузе сделать всё руками.

Еще проще, если использовать интерпретируемый язык (например, Python) и запускать сценарии в режиме REPL.

А вообще, по стандарту расширения капабилити должны передаваться с префиксом.

Попробуйте, может быть, распознает в виде "appium:deviceName".

Возможно, никто на форуме еще не пробовал так делать, или они не успели сюда заглянуть.

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

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

Давайте начнем с того, что называется скриптами, а что кейсами.

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

Тут можно предположить, например, такие варианты:

• Вы называете кейсами что-то другое
• Вместо вызова раннера у вас написан просто последовательный вызов тестов в main (не надо так)
• Настроена остановка после первой ошибки

Не обязательно руководство. Я вполне готов понять такое стремление у тестировщика.

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

Мысль красивая, но есть проблемы:

- Рисовать макетик только сначала увлекательно, потом это осточертеет больше, чем набор кейсов вручную. Тект набирать приятнее, чем заполнять разнообразные поля в разнообразных формах.

- Очень быстро столкнетесь, что придется описывать сложное поведение системы, и поддержка такого решения обойдется дорого.

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

Статья - прекрасный пример того, что проверять перевод с носителями языка не менее важно, чем разметку. Speichere? Accuell? Вы серьёзно? И это я еще языки плохо знаю - просто то, что в глаза бросилось. Что уж говорить о переводах на какие-нибудь азиатские языки со своими системами письма, в которых даже просто сверить слова с образцом уже непросто.

Потому что надо добавлять не в виде

--tags "@production"

а в виде

-Dcucumber-options="--tags '@production'"

(Попробовать сам сейчас не могу, пишу по своим старым докам. Может быть, не сработает - тогда кавычки как-то по-другому надо поставить, или действительно cucumber.options с точкой, а не с дефисом.)

UPDATE:

Нашел еще такой вариант: всё, передаваемое кукумберу, стоит в кавычках. И да, там с точкой.

"-Dcucumber.options= --tags @T5555 --tags ~@longRunning"

1. а. Вы не отказываетесь от тест-кейсов. В стандартном подходе автоматизация - это те же тест-кейсы, только в виде скрипта.
   б. С гуглотаблицами может быть проблема. Это не общепринятый формат, придется клепать свои адаптеры или договариваться с заказчиком, чтоб принял ваш формат.
2. Наверное, вот именно. Даже на моем текущем сильно забюрократизированном проекте считается, что автоматические кейсы могут служить документацией сами для себя.
3. Непонятно. Вы собрались делать 100% автоматизацию? Так обычно не делают, хотя зависит от специфики продукта.

Есть известные подходы, и это:

• BDD (или keyword-driven, с использованием тех же инструментов)
• Allure
• Robot Framework

Из личного опыта: на одном проекте писали на Gherkin, и был самописный скрипт по импорту-экспорту этих скриптов между репозиторием и системой управления проектом. Не прижилось: в итоге решили, что можно всё оставить в репозитории и не синхронизировать.

Сейчас на другом проекте у нас свой велосипед, который сразу экспортирует результаты тестов в отчеты нужного вида.

На всякий случай, стандарт устарел.

Смотрите википедию.

 

но всё равно он не запускается(((

И снова, этого делать не нужно. Тесты, собранные с помощью мавена, запускать предполагается с помощью мавена, а не из джарника. По вашей же ссылке всё написано.

Дайте угадаю, у вас много тестировщиков и единое на всех тестовое окружение?

Если проблема переиспользования данных не в этом, то тогда в чём? База данных очищается при деплое или что-то подобное?

Мы проблему с одним порталом на команду так, что каждый создает свои личные группы объектов (на тестируемом портале такое было), и никто в чужие не лезет. Соответственно, всегда можно переиспользовать свои исходные данные. Или можно как-то имена/номера резервировать.

Конечно, я готов представить, что функциональность системы не позволит это сделать (например, какое-то действие должно выполняться над всеми объектами, и не затронуть чужое невозможно). Но это уже надо как-то разруливать внутри команды.

Так а почему вот этот код то не работает????

 

Так а где в этом коде собственно сохранение и восстановление куки, то есть "Блок-2"?

Смутно помню, что поиск по классу тоже сбоил. Попробуйте поискать по XPath ".//*[@ClassName='TfrmMain']". По крайней мере, в моем проекте остались локаторы именно такого вида. Если никак, то придется искать другие признаки для поиска.

Этого всего писать не нужно. Maven сам умеет запускать тесты и подсчитывать результаты.

Если честно, пытался вспомнить, когда и где я его начинал изучать, но не вспомнил. Явно не по документации - она слишком мутная для начального этапа.

Ищите в сети уроки и статьи по ключевым словам "maven surefire junit" - их там много.

На скриншоте не видно, что за ошибка, и в каком месте она появляется.

Если в том месте, которое помечено комментарием ("//Здесь проверяем, что элемент mainWindowBy существует"), то зависит от того, было уже окно на экране или только что появилось.

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

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

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

Еще локаторы с div, конечно, малочитаемые. Сложно понять, тот ли элемент они находят. Если еще не видели, рекомендую посмотреть доклад.

Запускать scrollTo() в JS.

Да, здесь та проблема, что динамическому контенту в списке ID не задашь заранее.

Можно найти сам список по ID и перебором отыскать элемент с нужными свойствами.

Можно придумать хитрый поиск по XPath. Там хитрость в том, что имена нодов задавать часто бесполезно, и приходится использовать звёздочку, а условия поиска задавать в атрибутах. Пример есть тут: https://github.com/2...ts/FindTests.cs

Что такое "при сборке"? Таргет какой вызываете? (по логу не видно).

Idea, может быть, просто compile делает, а надо package.

Взялся за задачу, т.к. до сих пор не приходилось опробовать на практике этот инструмент на чем-то достаточно сложном.

Во-первых, насчет Restrictive constraints. Противоречия в последнем варианте снова есть. Я больше не буду ни на что указывать, лучше найдите сами.

Во-вторых, результаты экспериментов. Вот максимальная модель, которая у меня заработала (некоторые обозначения поменял для своего удобства). Контейнеры выкинул, т.к. в них и была проблема. Всё же, для системы первичны значения AccessRT/PT/AT, а контейнеры - это просто их комбинация.

Solution:       Solution, None
AccessSolution: F, R, CRUD, CRU, CRD, None
AccessRT:       F, R, CRUDE, CRUD, CRU, CR, RUDE, RUE, RUD, None
AccessPT:       F, R, CRUDE, CRUD, CRU, CR, RUDE, RUE, RUD, None
AccessAT:       F, R, CRUDE, CRUD, CRU, CR, RUDE, RUE, RUD, None
TypeRT:         L, F, O, LFO, None
TypePT:         L, O, LO, None
TypeAT:         L, F, O, LFO, None
AccessTypeRT:   RUD, RU, R, None
AccessTypePT:   RUD, RU, R, None
AccessTypeAT:   RUD, RU, R, None

IF [Solution] = "None"
 THEN [AccessSolution] = "None"
 ELSE [AccessSolution] <> "None";

IF [AccessRT] = "None"
 THEN [TypeRT]  = "None" AND [AccessTypeRT]  = "None"
 ELSE [TypeRT] <> "None" AND [AccessTypeRT] <> "None";

IF [AccessPT] = "None"
 THEN [TypePT]  = "None" AND [AccessTypePT]  = "None"
 ELSE [TypePT] <> "None" AND [AccessTypePT] <> "None";

IF [AccessAT] = "None"
 THEN [TypeAT]  = "None" AND [AccessTypeAT]  = "None"
 ELSE [TypeAT] <> "None" AND [AccessTypeAT] <> "None";

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

Итого, есть 2 идеи:

1. На каждый тип контейнера вручную делать свою модель, и в ней лишние поля просто удалять. Пока получится 5 файликов, не страшно.
2. Тестов всё равно очень много - сотни. Это явно неподходящая техника для создания ручных тестов. А если автоматизируем, то можно вообще выкинуть pairwise и тестировать всё подряд. Здесь 2 "но": это можно сделать, если тесты быстрые (всё же, сплошным перебором их будет на порядок больше), и если технически возможно написать оракул для проверки любой комбинации.

Если не ограничивать модель, то он пытается построить пары "все со всеми".

Условие:

IF [Solution] = "Solution" THEN [TypeRT] = "0" OR [TypePT] = "0" OR [TypeAT] = "0";

фактически означает, что не может быть Solution и RTPTAT. Соответственно, нельзя построить пары RTPTAT со всеми значениями AccessSolution.

Про RTPT так сразу не видно, но наверняка, тоже что-то не стыкуется.

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

Я не знаю исходных требований, поэтому подсказывать сложно.

Но последний вариант уже несовместим с первым.

И в последнем вообще запутались, например, "IF [Container] = "RTPTAT" THEN [TypeRT] = ..." определено 2 раза по-разному, да и не только это.

Поправочка. Конечно, можно сказать, что пара [TypeRT] = "listRT" и [TypePT] = "listPT" будет невозможна по исходным данным.

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