В аудитории Хабра электронщики есть. Сходите на Тостер.

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

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

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

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

падения нет, но и скриншот нигде не появляется

Так это же логично, правда? Откуда он должен появиться без падения?

 

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

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

 

Главное же идея, а как именно оформить - смотрите сами.

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

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

Для этого должна быть определенная культура обеспечения качества в компании.

Вокруг меня, как правило, разработчики считают, что на тесты нужно тратить минимум времени. Пишут для формального покрытия кода, и пишут в стиле "2+2=4" вместо проверки хотя бы граничных значений.

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

 

Я пытаюсь сохранить скриншот при падении теста в python с 'splinter'

<...>

 

2) Так же не получается прикрутить функцию splinter_make_screenshot_on_failure из pytest-splinter  https://github.com/p...pytest-splinter

Есть кто шарит? :)

А как пытаетесь прикрутить, что не получается? Если такая функция есть, свои способы вообще можно выключить.
 

Документация для Splinter какая-то бедная.

Конструктор для Browser выглядит так:

def Browser(driver_name="firefox", retry_count=3, *args, **kwargs)

Почему вы пытаетесь вставлять путь вместо driver_name или retry_count, непонятно.

Но и в документации добавочные аргументы нигде толком не описаны.

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

Для этого и привложу к str: str(),+ это значение добавляю в буфер

А где в документации pyperclip сказано, что copy что-то возвращает?

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

Значит искать надо в сторону нагрузочного тестирования. Понятно. Это территория Jmeter?) Можете что-то подсказать по этому поводу?

Да, это в некотором роде стандарт. Возможно, поймете, что в JMeter что-то вам не хватает.

 

наверное можно так:

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

 

вы потом эту аналитику проанализируйте, постройте там графики разные

 

 

Очень интересный ход мыслей. А какая есть литература/мануалы на эту тему?

 

Из недавно виденного на эту тему:

1 (как в Mail.ru мониторят свой фронтенд для почты)

2 (не самый удачный для прослушивания доклад, но некоторые идеи для аналитики почерпнуть можно)

Сомнения автора вопроса понятны - речь не только о цене, но и о любой информации, которая публикуется о приложении.

Это даже не вписывается в классификацию атрибутов качества продукта. Можно за уши притянуть к тестированию развертывания или конфигурации.

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

Вы рискуете написать тесты, на которые потратите кучу сил, и которые не будут давать нужной информации: что именно фиксить?

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

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

Ух как забористо... Запрос, который нажимает кнопку.

Рекомендую сначала что-то почитать или послушать по теме "Тестирование API".

Сначала надо отправить запрос(ы) на выборку этих данных.

Дальше, к примеру, в Regex Extractor'е есть плюшка, которая позволяет получить случайное значение из списка подходящих.

Это на самом деле может быть ошибка на сайте. Если то же самое делать в браузере (естественно, с открытой вкладкой Network), можно увидеть, выдает ли этот запрос 404 в нормальном состоянии.

У IDE одна страница документации по командам (https://selenium.dev...en/api/commands).

1. Переходим на нее.
2. Ищем слово "frame".
3. PROFIT!

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

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

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

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

vugen - это vugen. Может, он полностью движок браузера имитирует.

Вы смотрите, что в Jmeter в response приходит.

Действительно ли в теле ответа на первый запрос есть такой элемент? (Может быть, там идет редирект, или value заполняется скриптом.)

Соответствует ли то, что приходит, регулярке на 100% (пробелы и т.д.)?

Всем доброго времени суток! Не первый раз слышу от многих (более опытных) коллег в сети, что нужно строить архитектуру автотестов так же как и архитектуру основного ПО, в том смысле, что (внезапно) автотесты - это точно такое же ПО (только более узкоспециализированное) и оно подвержено точно таким же проблемам и особенностям как и обычное ПО. Есть наиболее распространенные паттерны проектирования, такие как, например, PageObject'ы, DataProvider'ы, etc. Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

Рассмотрим альтернативу выбрасыванию

Если ПО развивается, тесты придется развивать параллельно с ним. Тесты, работаюшие через N лет - это фантастика.

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

А если по теме вопроса - "Как это всё более-менее грамотно построить", то этого не рассказать на форуме.

Читайте книги, например Р. Мартин "Чистый код" и "Чистая архитектура", и черпайте из них то, что кажется уместным для тестирования.

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

Ну, каждый видит то, что хочет.

В первом же абзаце раздела 1.4, посвященного тестовому процессу (в Foundation!):

"The proper, specific software test process in any given situation depends on many factors. Which test activities are involved in this test process, how these activities are implemented, and when these activities occur may be discussed in an organization’s test strategy."

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

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

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

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

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

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

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

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

@checo привет, спасибо за ответ! прислали уже мейл, я спокойна :) экзамен в субботу. как давно ты сдавал? сложный был экзамен?

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

Может быть, вот этот доклад чем-то поможет.