Начал тестировать совсем недавно. По просьбе начальника написал набор UI тестов для #web -приложения.
С помощью #coded-ui test.
И тут столкнулся с проблемой. Тесты могут закончиться успешно, а могут и упасть.
В качестве решения посоветовали перезапускать упавшие тесты.
Но про перезапуск тестов нашел только применительно к #java .
Не подскажите ли, как эта проблема решается на #c-sharp::tag ?
Такого быть не должно. Тесты должны быть стабильными и проходить если должны и падать если не должны.
Если тест то работает, то падает - надо разбираться с тестом и устранять причины нестабильности.
Что даст если Вы перезапустите упавший тест? Если он при первом запуске упал, а при перезапуске нет?
Будет ли считаться, что тест пройден и Ваша система работает правильно?
А что если тест упал при первом запуске и при повторном запуске? Запустить третий раз?
Тест, который то падает, то нет, сигнализирует о том, что либо тест написан неправильно и проблема в нём, либо в тестируемом приложении есть ошибка, которая воспроизводиться при пока точно неисвестной последовательности шагов скорее всего связанной с ожиданием.
Например, тест кликает на кнопку, а страница ещё не догрузилась и клик приводит к падениюю страницы, что руками к примеру не повторяется потому что Вы не умеете кликать так же быстро как тест.
Как я написал выше, я - начинающий. Но в поисках ответа на вопрос, нормально ли нестабильное поведение тестов,
я обнаружил немало подобных утверждений:
"Вечной проблемой каждого тестировщика при запуске автотестов является “падение” отдельных сценариев от запуска к запуску рандомно. И речь идет не о падении наших тестов по объективным причинам (т.е. действительно имеет место ошибка в работе тестируемого функционала, или же сам тест написан не корректно), а как раз о тех случаях, когда после перезапуска ранее проваленные тесты чудом проходят. Причин такого рандомного падения может быть масса: отвалился интернет, перегрузка CPU / отсутствие свободной RAM на устройстве, таймаут и др. Вопрос — как исключить или хотя бы уменьшить количество таких не объективно проваленных тестов?
Реализовать перезапуск проваленного теста testng позволяет из коробки… "
Хотелось бы понять, действительно ли можно добиться устойчивости UI тестов?
И как организовать процесс автоматизированного тестирования?
Так и есть. Написать тест это половина дела. Сложнее сделать его стабильным.
Очень много времени тратиться на то, чтобы поймать, понять и устранить причины нестабильности.
Если речь идёт именно о таких причинах, то попробовать перезапустить тест имеет смысл.
Но необходимо убедиться, что проблема именно в этом, а не баг в приложении или отсутствие ожидания в тесте.
Хотя даже такие причны можно решать организационно. Например, путём создания отдельного тестового сденда где будут гонятся только тесты. Это поможет минимизировать проблему с перегрузкой CPU/RAM другими процессами.
Заметьте что Таймаут я исключил из списка, так как это отдельная история. Если это таймаут связи с БД, то по аналогии с отдельным тестовым стендом можно использовать отдельную БД, с которой работают только тесты или даже in-memory БД, которая существует только в памяти во время тестов. Если это таймаут из-за того, что тест чего-то не дожидается (например, элемента на странице), то это можно предусматреть в тесте и указать таймаут для операции. Но опять таки с такими таймаутами надо аккуратно. Не стоит ставить заведомо огромный таймаут. Таймаут должен быть приемлем с точки зрения пользователя. Если страница загружаеться 5 минут при свободных ресурсах, то это проблема, с которой надо бороться не в тестах. Это ошибка производительности приложения. Никакой пользователь не будет ждать 5 минут пока загрузится страница.
Устойчивости тестов можно добиться. Самое главное докопаться до причины и устранить её. Перезапуск теста должен применятся временно, чтобы устранить ложное срабатывание пока ищется и устраняется причина. Если просто ставить перезапуск тестов для каждого теста, который то падает то нет, не разбираясь в причинах, то можно прийти к тому, что половина тестов будет перезапускаться, а это уже будет влиять на общее время прохождения тестов.
Теперь непосредственно о перезапуске.
Вы используете Coded UI Test. Это инструпент взаимодействия с интерфейсом приложения. А какой тестовый фреймворк (инструмент для запуска тестов) Вы используете? Для С# довольно популярен Nunit. Довольно удобный по личному опыту. Рекомендовал бы использовать его и обязательно в более новой версии начиная с 3.0. Как раз начиная с этой версии появилась возможность перезапуска тестов при падении.
Для этого достаточно пометить тест атрибутом Retry.
Но эта фича ещё на стадии совершенствования и есть кое-какие ограничения Retry Attribute · nunit/docs Wiki · GitHub
Если просто ставить перезапуск тестов для каждого теста, который то падает то нет, не разбираясь в причинах, то можно прийти к тому, что половина тестов будет перезапускаться, а это уже будет влиять на общее время прохождения тестов.
Моя задача, как я ее для себя понимаю, состоит в следующем:
Начал я с запуска тестов на своей машине, но скоро понял, что за ней становлюсь третьим лишним. Нашлась старенькая машина, на которой я запустил SQL Server с тестовой базой, IIS с тестируемым сайтом и агента тестирования (только для того, чтобы запускалась MSTest.exe).
Но тут оказалось, что набор тестов, проходивший на моей машине (после многочисленных вставок WaitForControlReady) на этой машине проходит полностью крайне редко.
В такой ситуации мне показалось разумным научиться отделять те тесты, которые “не проходят никогда” от тех, которые иногда проходят.
А какой тестовый фреймворк (инструмент для запуска тестов) Вы используете?
Поскольку я начал с запуска тестов из Visual Studio, то естественным на тот момент было воспользоваться MSTest.exe. Но как перезапускать тесты с его помощью, выяснить пока не удалось.
Для С# довольно популярен Nunit. Довольно удобный по личному опыту.
Спасибо, попробую разобраться.
В Вашей ситуации я бы действительно сначала попробывал поставить перезапуск для всех сомнительных/проблемных тестов, а потом разбираться с причинапи один за другим.
Как перезапускать тесты непосредственно средствами MSTest.exe пока не нашёл. Есть врапер, который может это сделать MSTest Rerun Failed Tests Through MSTest.exe Wrapper Application - CodeProject
Но я бы советовал всё-таки перейти на Nunit
Спасибо. Видимо последую Вашему совету.
Вот тут
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 не совместимы?
Немного не в тему, но как я реализовывал перезапуск заваленных тестов в связке Selenium+Java+TestNG+Gradle(в качестве сборщика).
Прописывал в build.gradle файле такие таски и запускал из консоли таск allTests.
testomat.io управление авто тестами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))
Исследую… Вернусь с результатами поже
Для TestNG перезапуск делается нативными средствами Restart failed test case automatically in TestNG/Selenium - Stack Overflow
Пробовал, как-то не особо взлетало и стал пользоваться вышепреведенным способом, как менее замороченным.