checo

В первом случае @class="..." - четкое совпадение. Во втором - может быть больше классов в атрибуте, или другой порядок классов.

Тогда как корректно скопировать в буфер и потом вставить с "paste"?

Вот тут есть пример, как нажимать сочетания клавиш:

https://selenium-pyt...Chains.key_down

Что и требовалось доказать. Куча редиректов, и настоящая разметка приходит по факту совсем с другого адреса.

Теперь вопрос: а к чему в этом дереве применяется постпроцессор?

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

Если настройка "Apply to sub-samples" не поможет, тогда делайте запрос именно на тот адрес, с которого приходят данные.

ISTQB вообще не учит, с чего начинать тестирование. Они описывают набор разных практик. Нужно к этому относиться как к багажу знаний и унификации некоторых понятий.

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

Уровень Foundation - "как бы" для начинающих (хотя у нас его часто сдают как раз после нескольких лет опыта). Поэтому там формальной стороне уделяется больше внимания.

Почитайте силлабусы для Advanced.

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

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

Есть другая проблема: при подготовке к ISTQB может возникнуть искажение целей. Они дают набор методик, и у человека появляется цель знать все эти методики, чтобы пройти экзамен. А потом кажется, что всё это непременно в той же пропорции надо применять на работе.

Привет!

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

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

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

 

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

покрыть все варианты развития событий?

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

Что можно сделать:

- Для начала, отделить те проверки, которые не относятся к "развитию событий", а проверяют единовременное влияние каких-то условий ("Сама сумма предоплаты (полная/частичная) зависит от суммы заказа", "от места нахождения товара и суммы заказа зависит, включена ли в стоимость доставка" и т.п.)

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

- Если есть много времени и возможность делать подробные проверки, то да - можно нарисовать диаграмму состояний и пройти по ней все пути.  Только не нужно переусердствовать и включать туда всё, что есть в бизнесе. Нужно выделить какой-то ограниченный набор состояний. (Например, отдельно - статусы резервирования. Если какое-то действие приводит к переходу в следующий набор состояний, не относящийся к резервированию, то это будет последнее действие в тесте.) Способов обхода такой схемы множество. Например, отметить два состояния как "начальное" и "конечное" и сделать такой набор тестов, которые начинаются с "начального" и заканчиваются "конечным". При этом нужно, чтобы этот набор тестов покрывал все возможные переходы. Если начальных и конечных состояний несколько, то это не значит, что надо проходить от каждого к каждому, просто на конечных надо заканчивать. Также, разумеется, не надо покрывать переходы, которые уже проверены пользовательскими сценариями.

- Если нужно проверить, что разные действия приводят к разным последствиям в зависимости от набора входных параметров, а комбинаций с параметрами много, то включать все эти варианты в схему переходов не нужно. Ищите тему "таблица решений" или "decision table".

Сохранить во временную папку и открыть как URI "file:///..."?

Богомерзкий трактор так не умеет :( у него там прошито, что открывается только урл как data, можно поменять на файл, но только для всех спек сразу, в onPrepare, а мне ведь это надо сделать вообще в середине одного теста.

Если еще актуально.

Я не знаю всех тонкостей настройки протрактора. Но вот такой хеллоуворлд у меня заработал:

var my_html = '<html><body><h1>MY PERFECT PAGE</h1><pre>1\n2\n3</pre></body></html>';
browser.waitForAngularEnabled(false);
browser.get('about:blank');
browser.executeScript('document.write(arguments[0]);', my_html);

Возможно, это и правда дефект в драйвере или в браузере.

Но это совершенно неважно. Неявные ожидания по минуте никто не использует. Что у вас за софт такой, где каждый, абсолютно каждый элемент нужно ждать по минуте? С таким софтом просто невозможно работать.

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

Привычка описания ОР -> ФР появляется так: Если баг найден в тесте, копипастим содержание теста, а внизу дописываем ФР.

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

Все привет. Подскажите пытаюсь в pytest_addoption в качестве второго параметра передать функцию которая передает значения из json файла, однако тесты не запускаются что не так :) 

В hookspec определен только один параметр: https://docs.pytest....ytest_addoption

Интересный вариант ответа про коммит в ветку: "... сделать коммит по тем же правилам, что и для ветки master". Правило для master - не делать туда локальные коммиты

Для начала, в каком контексте задан вопрос?

Если для общего понимания, тогда термин "аномалия" вам вообще не нужен, не слышал его и не видел на форумах.

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

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

File -> Settings -> Project: ... -> Project Interpreter указывает на тот же питон, который вызывается в Idle?

Сильно зависит от того, что ваши сервисы делают, и какой у них интерфейс взаимодействия с внешним миром.

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

Начинать можно со следующего:

1. Научиться вообще с этими сервисами работать. Разобраться с протоколом. Выбрать подходящий инструмент (код, SoapUI, JMeter) и попробовать написать пилотные тесты, чтоб они хоть что-то делали.

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

Фреймворки - зависят от выбранного инструмента и/или языка.

Например, для RESTful можно напрямую создавать HTTP-запросы стандартными средствами, для WCF можно нагенерить готовую клиентскую библиотеку инструментами .NET. А далее - что угодно может потребоваться в зависимости от того, что должны проверять тесты.

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

А как это будет тогда выглядеть с точки зрения структуры тестового приложения? ApplicationManager, получается, будет управлять и хелперами, и объектами страниц?

Можно для страниц сделать отдельный менеджер, если так удобнее.

Главное, чтобы зависимость была однонаправленная:

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

- драйвер используется только в страницах