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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

Забавно, в 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 изначально не задан.)

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

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

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

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

 

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

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

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

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

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

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

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

Добрый день

Вы имеете в виду 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? 

Спасибо

 

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

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

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

Сохранить во временную папку и открыть как 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);

 

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

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

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

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

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

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

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

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

Добрый день!

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

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

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

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

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

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

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

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

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

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

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

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

Условие:

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

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

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

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

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

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