Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Перезапуск проваленных UI тестов - какова технология?

coded-ui
csharp
visual-studio
execution
web
java
Теги: #<Tag:0x00007f7b6518f370> #<Tag:0x00007f7b6518f230> #<Tag:0x00007f7b6518f0f0> #<Tag:0x00007f7b6518efb0> #<Tag:0x00007f7b6518ee70> #<Tag:0x00007f7b6518ecb8>

(Vitaly Ignatov) #1

Начал тестировать совсем недавно. По просьбе начальника написал набор UI тестов для #web -приложения.
С помощью #coded-ui test.
И тут столкнулся с проблемой. Тесты могут закончиться успешно, а могут и упасть.
В качестве решения посоветовали перезапускать упавшие тесты.
Но про перезапуск тестов нашел только применительно к #java .
Не подскажите ли, как эта проблема решается на #c-sharp::tag ?


(Nik Sidorenko) #2

Такого быть не должно. Тесты должны быть стабильными и проходить если должны и падать если не должны.
Если тест то работает, то падает - надо разбираться с тестом и устранять причины нестабильности.

Что даст если Вы перезапустите упавший тест? Если он при первом запуске упал, а при перезапуске нет?
Будет ли считаться, что тест пройден и Ваша система работает правильно?

А что если тест упал при первом запуске и при повторном запуске? Запустить третий раз?

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


(Vitaly Ignatov) #3

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

"Вечной проблемой каждого тестировщика при запуске автотестов является “падение” отдельных сценариев от запуска к запуску рандомно. И речь идет не о падении наших тестов по объективным причинам (т.е. действительно имеет место ошибка в работе тестируемого функционала, или же сам тест написан не корректно), а как раз о тех случаях, когда после перезапуска ранее проваленные тесты чудом проходят. Причин такого рандомного падения может быть масса: отвалился интернет, перегрузка CPU / отсутствие свободной RAM на устройстве, таймаут и др. Вопрос — как исключить или хотя бы уменьшить количество таких не объективно проваленных тестов?
Реализовать перезапуск проваленного теста testng позволяет из коробки… "

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


(Nik Sidorenko) #4

Так и есть. Написать тест это половина дела. Сложнее сделать его стабильным.
Очень много времени тратиться на то, чтобы поймать, понять и устранить причины нестабильности.

Если речь идёт именно о таких причинах, то попробовать перезапустить тест имеет смысл.
Но необходимо убедиться, что проблема именно в этом, а не баг в приложении или отсутствие ожидания в тесте.
Хотя даже такие причны можно решать организационно. Например, путём создания отдельного тестового сденда где будут гонятся только тесты. Это поможет минимизировать проблему с перегрузкой CPU/RAM другими процессами.

Заметьте что Таймаут я исключил из списка, так как это отдельная история. Если это таймаут связи с БД, то по аналогии с отдельным тестовым стендом можно использовать отдельную БД, с которой работают только тесты или даже in-memory БД, которая существует только в памяти во время тестов. Если это таймаут из-за того, что тест чего-то не дожидается (например, элемента на странице), то это можно предусматреть в тесте и указать таймаут для операции. Но опять таки с такими таймаутами надо аккуратно. Не стоит ставить заведомо огромный таймаут. Таймаут должен быть приемлем с точки зрения пользователя. Если страница загружаеться 5 минут при свободных ресурсах, то это проблема, с которой надо бороться не в тестах. Это ошибка производительности приложения. Никакой пользователь не будет ждать 5 минут пока загрузится страница.

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

Теперь непосредственно о перезапуске.
Вы используете Coded UI Test. Это инструпент взаимодействия с интерфейсом приложения. А какой тестовый фреймворк (инструмент для запуска тестов) Вы используете? Для С# довольно популярен Nunit. Довольно удобный по личному опыту. Рекомендовал бы использовать его и обязательно в более новой версии начиная с 3.0. Как раз начиная с этой версии появилась возможность перезапуска тестов при падении.
Для этого достаточно пометить тест атрибутом Retry.
Но эта фича ещё на стадии совершенствования и есть кое-какие ограничения https://github.com/nunit/docs/wiki/Retry-Attribute


(Vitaly Ignatov) #5

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

Моя задача, как я ее для себя понимаю, состоит в следующем:

  1. Обнаружить текущие баги
  2. Приобрести опыт
  3. Наладить технологию, которой впоследствии могли воспользоваться другие сотрудники отдела

Начал я с запуска тестов на своей машине, но скоро понял, что за ней становлюсь третьим лишним. Нашлась старенькая машина, на которой я запустил SQL Server с тестовой базой, IIS с тестируемым сайтом и агента тестирования (только для того, чтобы запускалась MSTest.exe).
Но тут оказалось, что набор тестов, проходивший на моей машине (после многочисленных вставок WaitForControlReady) на этой машине проходит полностью крайне редко.
В такой ситуации мне показалось разумным научиться отделять те тесты, которые “не проходят никогда” от тех, которые иногда проходят.

А какой тестовый фреймворк (инструмент для запуска тестов) Вы используете?

Поскольку я начал с запуска тестов из Visual Studio, то естественным на тот момент было воспользоваться MSTest.exe. Но как перезапускать тесты с его помощью, выяснить пока не удалось.

Для С# довольно популярен Nunit. Довольно удобный по личному опыту.

Спасибо, попробую разобраться.


(Nik Sidorenko) #6

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

Как перезапускать тесты непосредственно средствами MSTest.exe пока не нашёл. Есть врапер, который может это сделать http://www.codeproject.com/Articles/883305/MSTest-Rerun-Failed-Tests-Through-MSTest-exe-Wrapp
Но я бы советовал всё-таки перейти на Nunit


(Vitaly Ignatov) #7

Спасибо. Видимо последую Вашему совету.


(Vitaly Ignatov) #8

Вот тут
https://social.msdn.microsoft.com/Forums/en-US/ef77627b-6802-44e3-928e-434f1901e152/running-coded-ui-tests-with-resharpernunit-will-not-locate-silverlight-components?forum=vsautotest
пишут:
• Running a Coded UI Test with NUnit is not supported.
Coded UI Test is a Unit Test extension and has a lot of dependency on the Visual Studio Unit Test framework.
Действительно ли Coded UI Test и NUnit не совместимы?


(Sergey QA) #9

Немного не в тему, но как я реализовывал перезапуск заваленных тестов в связке Selenium+Java+TestNG+Gradle(в качестве сборщика).

Прописывал в build.gradle файле такие таски и запускал из консоли таск allTests.

test{
    useTestNG() {
        suites 'src/test/resources/TestNG.xml'
        useDefaultListeners = true
    }
    ignoreFailures = true
}
task secondTry(type:Test){
    onlyIf{
        file("build/reports/tests/testng-failed.xml").exists()
    }
    dependsOn test
    testClassesDir = sourceSets.test.output.classesDir
    classpath = sourceSets.test.runtimeClasspath
    testSrcDirs = sourceSets.test.java.srcDirs as List
    //outputDirectory = file("$buildDir/reports/secondTry")
    useTestNG(){
        suites("build/reports/tests/testng-failed.xml")
    }
}
task allTests(dependsOn: tasks.withType(Test))

(Nik Sidorenko) #10

Исследую… Вернусь с результатами поже


(Nik Sidorenko) #11

Для TestNG перезапуск делается нативными средствами http://stackoverflow.com/questions/8713564/restart-failed-test-case-automatically-in-testng-selenium


(Sergey QA) #12

Пробовал, как-то не особо взлетало и стал пользоваться вышепреведенным способом, как менее замороченным.