Перейти к содержимому

Эффективное использование TestNG и JUnit
онлайн, начало 20 апреля
Логи как инструмент тестировщика
онлайн, начало 23 апреля
Тестирование производительности (HP Load Runner)
онлайн, начало 20 апреля
Управление требованиями
онлайн, начало 20 апреля
Фотография

Selenium Wait для пустой таблицы (ну или просто хороший Wait)

selenium wait

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 12

#1 Spock

Spock

    Специалист

  • Members
  • PipPipPipPipPip
  • 819 сообщений
  • ФИО:Роман

Отправлено 14 Март 2017 - 15:15

как правильно ждать загрузку пустой таблицы? 

 

есть страница, на ней таблица, которая заполняется отдельным запросом и затем скриптами

 

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

 

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

 

где вообще надо брать хороший код для селениумовских вейтов?

 

пробовал вариант отсюда - http://stackoverflow...versal-approach

не помогает, так как у нас не используется jquery


  • 0

#2 user12

user12

    Специалист

  • Members
  • PipPipPipPipPip
  • 738 сообщений
  • ФИО:Виктор
  • Город:Минск


Отправлено 14 Март 2017 - 15:50

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

 

 

Тогда ты ждешь в течении нескольких секунд, что в таблице нет первой записи

 

т.е. у тебя должен быть какой-то булевский метод isElementPresent куда ты передаешь локатор элемента, а он тебе вернет true или false


  • 0

#3 Spock

Spock

    Специалист

  • Members
  • PipPipPipPipPip
  • 819 сообщений
  • ФИО:Роман

Отправлено 15 Март 2017 - 09:19

 

 

Тогда ты ждешь в течении нескольких секунд, что в таблице нет первой записи

это уже замедление теста, плюс тест получается хрупким, так как неясно сколько же ждать надо


  • 0

#4 user12

user12

    Специалист

  • Members
  • PipPipPipPipPip
  • 738 сообщений
  • ФИО:Виктор
  • Город:Минск


Отправлено 15 Март 2017 - 10:52

Стабильность теста - намного важнее, чем замедление.

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


  • 0

#5 Spock

Spock

    Специалист

  • Members
  • PipPipPipPipPip
  • 819 сообщений
  • ФИО:Роман

Отправлено 15 Март 2017 - 14:26

 

 

Стабильность теста - намного важнее, чем замедление.

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

 

3 секунды? а если появится за 4 секунды, что тогда?

30 секунд? уже реально медленные тесты будут

 

откуда знать сколько ждать чтобы тест 100% работал правильно?


  • 0

#6 user12

user12

    Специалист

  • Members
  • PipPipPipPipPip
  • 738 сообщений
  • ФИО:Виктор
  • Город:Минск


Отправлено 15 Март 2017 - 14:49

откуда знать сколько ждать чтобы тест 100% работал правильно?

 

 

требования(если они есть) и здравый смысл.


  • 0

#7 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 310 сообщений
  • Город:Н.Новгород

Отправлено 16 Март 2017 - 07:17

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

#8 Spock

Spock

    Специалист

  • Members
  • PipPipPipPipPip
  • 819 сообщений
  • ФИО:Роман

Отправлено 17 Март 2017 - 09:57

 

 

требования(если они есть) и здравый смысл.

 

 

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

вот тесты и получатся гарантированно медленными и хрупкими, так как придётся использовать фиксированные ожидания

 

типа "загружаешь пустую таблицу? - подожди используя фиксированное ожидание"


  • 0

#9 Alex

Alex

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Алексей

Отправлено 17 Март 2017 - 11:34

 

 

 

требования(если они есть) и здравый смысл.

 

 

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

вот тесты и получатся гарантированно медленными и хрупкими, так как придётся использовать фиксированные ожидания

 

типа "загружаешь пустую таблицу? - подожди используя фиксированное ожидание"

 

Так а руками это как проверяется? Также? Открыть и подождать, что ничего не подтянулось? Или есть какой-то loader отражающий процесс загрузки.

Если и руками только ждать, то значит и автотестам ждать

Если есть loader, ожидаем его появления и затем его исчезновения, чекаем свою таблицу


  • 0

#10 Spock

Spock

    Специалист

  • Members
  • PipPipPipPipPip
  • 819 сообщений
  • ФИО:Роман

Отправлено 17 Март 2017 - 11:55

 

 

Если и руками только ждать, то значит и автотестам ждать

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

 

а авто-тесты ведь должны крутиться быстро, и желательно без "фиксированных ожиданий"

 

 

 

Если есть loader, ожидаем его появления и затем его исчезновения, чекаем свою таблицу

вот в том и дело что нет ни лоадера, ни "состояние пустая таблица" - поэтому получается что нельзя определить текущее состояние таблицы


  • 0

#11 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 310 сообщений
  • Город:Н.Новгород

Отправлено 17 Март 2017 - 17:21

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

 

Но что такое окончание загрузки? Что должен определить Селениум? Если загрузка динамическая, значит, ходят какие-то запросы от клиентского кода. Они для каждого приложения разные, где-то даже могут использоваться вебсокеты. Мы можем ожидать прохождения определенных запросов (хотя и это не 100% гарантия: после получения данных могут быть проблемы с производительностью скрипта, занимающегося отображением).

 

Отлавливать сами запросы через прокси - тоже плохое решение. Например, BrowserMob сильно тормозит работу сайта вообще.

 

Здесь всё слишком специфично. Непонятно, какой должен быть стандартный Wait. Например, я недавно работал с приложением, которое пуляет запросы раз в 2 секунды, и если пришли изменения, может неожиданно в любой момент работы закрыть сраницу лоадером. Где в нем окончание загрузки? Мы делали специфичные вейты, в которых детектировалось появление лоадера буквально при работе с любым элементом.

 

Я бы в данном случае использовал одно из двух:

  1. Ожидаем, что новое содержимое не подгружается в первую ячейку (если это применимо), например, в течение двух секунд. Плохо, что задержка. Плохо, что гарантия опять же неполная. В "чистом" случае время работы будет неотличимо от фиксированного вейта. Ускорение будет только для негативного случая. Хорошо только в плане культуры кода.
  2. Копаемся в клиентском коде и ищем, какие объекты должны быть инициализированы, какие статусы установлены и т.д. по окончании загрузки. И пробуем получить эти данные с помощью JavascriptExecutor. Либо с помощью него же навесить какое-то свое событие на обработчик данных с сервера. Плохо: не всегда это возможно, особенно если код подвергся обфускации и минимизации. Плохо: зависимость от реализации. Хорошо: когда компонент стабилен, это будет самое "умное" решение. В случае ошибки выполнения скрипта, можно фоллбэчиться на тот же таймаут.

  • 0

#12 Spock

Spock

    Специалист

  • Members
  • PipPipPipPipPip
  • 819 сообщений
  • ФИО:Роман

Отправлено 18 Март 2017 - 16:35

 

 

Мы можем ожидать прохождения определенных запросов (хотя и это не 100% гарантия: после получения данных могут быть проблемы с производительностью скрипта, занимающегося отображением).

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

 

 

 

Отлавливать сами запросы через прокси - тоже плохое решение. Например, BrowserMob сильно тормозит работу сайта вообще.

тут интересно - прокси увеличивает время запросов-ответов и из-за этого сайт становится типа "медленным"? либо multithreading там не очень? либо прокси грузит процессор на машине и из-за этого браузер тормозит?

 

 

да, эти два решения наверное всё-таки приемлемые


  • 0

#13 DmitriyQA

DmitriyQA

    Постоянный участник

  • Members
  • PipPipPip
  • 181 сообщений
  • ФИО:Коваленко Дмитрий Владимирович
  • Город:Tel Aviv

Отправлено 20 Март 2017 - 10:47

Если таблица построена из HTML то даже в пустой таблице есть теги <tr> и <td>. Ищи эти тогда эти элементы командой getElementByTagName - и будет тебе счастье. А ожидание пока он станет видимым или просто exists


  • 0

Senior QA/ Wix.com / qaacademy.net



Selenium 2.0: стартовый уровень
онлайн, начало 13 апреля
Программирование на Java для тестировщиков
онлайн, начало 4 мая
Автоматизация функционального тестирования
онлайн, начало 25 мая
Selenium WebDriver: полное руководство
онлайн, начало 11 мая




Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале