Selenium Automation: Каким должен быть приемлемый диапазон неудачных тестовых случаев, кроме допустимых неудачных при запуске набора тестов?

Question

Наша компания разрабатывает инфраструктуру с Selenium, POM, Maven и Java для веб-приложения, и у нас есть около 35 тестовых случаев. Когда мы запускаем testng.xml , по крайней мере, от 4 до 5 тестовых случаев дают случайный сбой из-за исключения устаревшего элемента или элемента, который не активируется в этой точке и т. Д.

Часто ли некоторые тестовые случаи дают сбой при запуске testng.xml ? Сколько тестовых примеров проведено в вашей организации и какова оценка того, сколько неудачных попыток?

Answer 1

Спасибо, ребята, я мог бы решить вопрос

Шаги следуют 1) Исключение устаревшего элемента: Сценарий: на основе критериев поиска оглавление будет загружаться с кнопкой редактирования и удаления. Поиск был медленным, и элементы для редактирования кнопки стали бы устаревшими Решение: использовал приведенный ниже пример кода ожидания из предыдущих постов и приостановил его работу

public static void customewait(int seconds)
    {        Date start = new Date();
             Date end = new Date();
             while(end.getTime() - start.getTime() < seconds * 1000){
                 end = new Date();
             }
    }

Ранее использованный ниже код, но не работал

public void getVisibilityAllTableAddressBook() 
{
        WebDriverWait wait = new WebDriverWait(driver, 10);
        wait.until(ExpectedConditions.visibilityOfAllElements(driver.findElements(By.cssSelector("#data-table-items"))));

}

Answer 2

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

Элемент не активируется в точке - эта проблема может возникнуть по нескольким причинам

1. Страница все еще загружается
2. Существует наложение поверх элемента, по которому мы хотим щелкнуть, что препятствует его

Лучший подход Лучший способ устранить ошибки в тестах - это сделать снимки экрана в случае сбоя и поработать над ними. Платформа тестирования должна быть разработана для обработки всех этих крайних сценариев

Answer 3

Вам просто нужно немного подождать, прежде чем ваш driver.findElement (). Selenium работает очень быстро, и поэтому вы получаете этот устаревший элемент или элемент, а не видимые исключения. Добавление ожидания должно решить проблему.

Answer 4

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

Допустимый диапазон неудачных испытаний

Эта матрица может варьироваться от организации к организации или в соответствии с конкретными Требования к клиенту . Однако Критерии выхода должен содержать ключ для этого ограничения. Сказав это, как Автоматизация тестирования - Selenium автоматизирует Регрессионные тесты , поэтому в идеале должно быть Ноль сбоев. Я знал, что какая-то организация придерживается политики Zero Defect .

Ошибки, с которыми вы сталкиваетесь

• StaleElementReferenceException : указывает, что ссылка на элемент теперь "устарела" - элемент больше не отображается в DOM страницы.
• Подробное обсуждение StaleElementReferenceException можно найти в:
  • Исключение StaleElementReference в PageFactory
  • Селен assertFalse завершается ошибкой с исключением staleelementreference
  • Selenium Webdriver - исключение устаревшего элемента при нажатии на несколько раскрывающихся списков. DOM dint change
• ElementClickInterceptedException : указывает, что щелчок не может быть выполнен должным образом, поскольку целевой элемент каким-либо образом скрыт.
• Подробное обсуждение ElementClickInterceptedException можно найти в:
  • Selenium Web Driver & Java. Элемент не кликабелен в точке (x, y). Другой элемент получит клик
  • Selenium WebDriver создает исключение в потоке «main» org.openqa.selenium.ElementNotInteractableException
  • Селен: как решить org.openqa.selenium.InvalidElementStateException: недопустимое состояние элемента

Заключение

Таким образом, ошибки, которые вы упомянули, не являются ошибками как таковыми, но могут возникать при выполнении теста по следующим причинам:

• Несоответствие совместимости используемой вами версии двоичных файлов.
• Несоответствие синхронизации между экземпляром WebDriver и Браузером экземпляр.

Эту ошибку легко устранить, следуя рекомендациям, упомянутым выше.

Answer 5

Сбои из-за устаревших элементов, элемента, не реагирующего на щелчки в точке, проблем с синхронизацией и т. Д. должен обрабатываться и обрабатываться в вашей инфраструктуре автоматизации - методы, которые вы создаете и используете для построения случаев .
Они не должны распространяться и приводить к сбоям в кейсах - это технические проблемы, а не проблемы с продуктом или тестовые случаи. Как таковые они должны учитываться (например, блоки try / catch) и обрабатываться (механизмы повторных попыток или повторного получения веб-элемента).

По сути - обрабатывайте эти виды сбоев так же, как вы обращаетесь с ошибками синтаксиса - не должно быть таких .

---

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

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

Со временем я пришел к выводу, что с этими сбоями все в порядке, их исправление - повторный выбор наборов данных, обход таких внешних колебаний и т. Д. - это деятельность с уменьшающейся ценностью и сомнительной рентабельностью. Из нынешних ~ 10 000 случаев для этой системы около 1,5% отказывают из-за этого (отказ от ответственности: SUT работает исключительно с живыми / производственными данными).
Вряд ли это практическое правило - это просто число, которое я выбрал как приемлемое, учитывая контекст.

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