Проверьте, если я ошибаюсь.

IF [Container] = "RTPT" THEN [TypeRT] = "listRT" OR [TypeRT] = "formRT" OR [TypeRT] = "operationRT";
IF [Container] = "RTPT" THEN [TypePT] = "listPT" OR [TypePT] = "operationPT";

Это означает, что валидно [Container] = "RTPT", [TypeRT] = "listRT", [TypePT] = "listPT".

Далее по модели:

IF [TypeRT] = "listRT" THEN [AccessTypeRT] = "RUD" OR [AccessTypeRT] = "RU" OR [AccessTypeRT] = "UD" OR [AccessTypeRT] = "R";
IF [TypeRT] = "listRT" THEN [AccessTypePT] = "0";

и:

IF [TypePT] = "listPT" THEN [AccessTypePT] = "RUD" OR [AccessTypePT] = "RU" OR [AccessTypePT] = "UD" OR [AccessTypePT] = "R";
IF [TypePT] = "listPT" THEN [AccessTypeRT] = "0";

Похоже на противоречие.

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

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

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

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

Добрый день!

Задача проверить, что кейс выполнен успешно и перешел по успешному 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 и всё такое.

 

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

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

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

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

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

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

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

- Если нужно проверить, что разные действия приводят к разным последствиям в зависимости от набора входных параметров, а комбинаций с параметрами много, то включать все эти варианты в схему переходов не нужно. Ищите тему "таблица решений" или "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);

Добрый день

Вы имеете в виду 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'у) имеет смысл регулярно просматривать, что заведено за прошедший цикл. Даже если это не скрам, какая-то цикличность в больших проектах обычно присутствует.

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

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

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

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

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

Забавно, в 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().

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

У Яндекс.Карт есть описание API, которым пользуются ваши разработчики. Там на выбор маркера навешивается некоторый обработчик события. Поэтому разумно сначала написать тест, где этот обработчик будет вызываться самим тестом в JavascriptExecutor. Конечно, с точки зрения бизнеса еще необходимо проверить вручную, что это всё работает с точки зрения пользователя. Но эту ручную проверку можно делать разово при приёмке и перед релизом.

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

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

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

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

 

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

 

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

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

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

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

Когда передаете в body объект, он автоматически пытается преобразовать его в XML с помощью JAXB. JAXB требует определенных аннотаций.

Если хотите форматировать строку самостоятельно, так и пишите: dc.toString().getBytes()

Здравствуйте!

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

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

Может быть, вы или ваши коллеги с таким сталкивались? Как справляетесь?

(Алкоголь не предлагать, мне же еще работать надо )