Привет!

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

А что это дает? В бэклоге лежат задачи для разных команд с разных проектов? Или несколько изолированных команд работают над одним бэклогом?

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

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

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

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

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

 

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

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

Ну что же, подождем специалистов по Selenium IDE. Я предполагал, что раз Вы используете такую команду, то она существует, и отвечал только про регулярки. Сейчас немного почитал - да, текущая версия не поддерживает регулярки. Для этого есть какие-то альтернативные сборки.

Да, неправильно. "*" - повторение последнего символа/группы 0 и более раз. ".*" - повторение любого символа/группы 0 и более раз. Но в Вашем случае правильнее использовать "06:\d\d" или "06:[0-5]\d".

https://www.w3school...xp_zeromore.asp

Добрый день!

Задача проверить, что кейс выполнен успешно и перешел по успешному url. Стек webrdriver+python

Есть страница, после заполнения и отправки данных, если все ок, то браузер переходит на success_url

Я сохраняю текущий url, нажимаю кнопку отправить и жду перехода на новую страницу. В проверке сравниваю страницы

Скрытый текст

driver = self.app.driver
self.submit()
WebDriverWait(driver, 20).until(
EC.url_changes)
current_url = driver.current_url
assert (current_url.startswith("http://yandex.ru"))

 

Тест не проходит. Смотрю в отладчике и почему-то в current_url сохранена ссылка до редиректа. А в driver.current_url хранится нужный url. Почему так происходит? Что нужно сделать, чтобы страница взяла верный url. Может нужно изменить ожидание? 

Смотрим реализацию в гитхабе:

@property
def current_url(self):
    return self.execute(Command.GET_CURRENT_URL)['value']

https://github.com/S...te/webdriver.py

Т.е., в отладчике, когда смотрите driver.current_url, команда драйверу посылается заново, и видно обновленное значение.

Почему оно не обновляется сразу после ожидания? Возможно, ожидание срабатывает на какую-то другую, более раннюю смену ссылки.

Что делать? Ну, например, написать своё ожидание. Explicit is better и всё такое.

Добрый день

Вы имеете в виду Lee Copeland. A Practitioner's Guide to Software Test Design?

Посоветуйте, для новичка, после Савина и Куликов х2, что  лучше начать Patton R. - Software Testing или Lee Copeland. A Practitioner's Guide to Software Test Design? 

Спасибо

 

Это разные книги, обе могут быть полезны.

Пэттон - больше о процессах и документации (как Савин, только в другом разрезе и более деловым тоном).

Коупленд - больше о техниках.

 

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

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

А вообще да, куратору продукта (product owner'у) имеет смысл регулярно просматривать, что заведено за прошедший цикл. Даже если это не скрам, какая-то цикличность в больших проектах обычно присутствует.

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

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

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

В реальности новички будут описывать баг совсем другими словами, чем опытные, и не будут понимать, что там вообще написано в трекере.

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

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

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

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

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

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

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

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

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

--tags "@production"

а в виде

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

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

UPDATE:

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

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

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

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

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

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

Забавно, в Python прекрасно работает вот это:

from selenium.webdriver import Chrome

d = Chrome()
d.get('http://software-testing.ru/forum/index.php?/topic/37942-ne-mogu-poluchit-dannye-iz-inputa-cherez-gettext/')
main_search = d.find_element_by_id('main_search')
main_search.send_keys('12345')
print('Value=' + main_search.get_property('value')) # Value=12345
d.quit()

А в Java реализии аналогичной команды в интерфейсе WebElement не нашел. Хотя до сих пор думал, что реализация на Java наиболее полная.

(Поправочка: get_attribute тоже работает. Это при том, что атрибут в DOM изначально не задан.)

Скорее всего, нужен не getText(), а getValue().

https://docs.pytest....rizing-fixtures

вроде всё прокликали, что могло пойти не так?

 

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

 

Это говорит только о неполноте регрессии. У нас на проекте, где лид был строго убежден в неэффективности автоматизации, все точки доступа всё равно проверяли руками через Fiddler.