Тесты на огурцы - повторные неудачи в Jenkins

мы запускаем набор тестов Frank/oucumber через сервер jenkins для тестирования приложения iOS.Тесты на огурцы - повторные неудачи в Jenkins

Тестирование выполняется локально просто отлично, а также при запуске вручную на сервере jenkins. Тем не менее, когда мы проходим через jenkins, мы получаем случайные ошибки, из-за которых сборка выходит из строя, и тогда она работает нормально, когда мы снова запускаем jenkins (т. Е. Нажимаем кнопку «Build now»), ничего не меняя.

мы запускаем следующий код для запуска тестов:

cucumber features/ipad --tags [email protected]

Затем я добавил повторно запустите параметр, чтобы сбросить неудачных тестов в текстовый файл:

-f rerun -o rerun.txt

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

cucumber features/ipad --tags [email protected] -f rerun -o rerun.txt; cucumber @rerun.txt

Это прекрасно работает, i t ловит неудачные тесты и повторно запускает их после других тестов.

Однако, дженкинс по-прежнему отмечает сборку как неудачу, несмотря на то, что повторная передача прошла.

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

Или есть более аккуратный способ вокруг этого?

Благодаря

источник

2013-09-26 MichalT

Скрипт jenkins довольно прост. Сбой сборки при сбое скрипта, то есть имеет ненулевой код выхода.

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

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

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

источник

2013-09-26 17:31:03 Sulthan

Я думаю, что вы и Питер верны в том, что тесты необходимо переписать/перепроверить, чтобы эти ошибки не возникали. Это разочаровывает, когда тесты проходят нормально локально, но не проходят через дженкинсов по очевидной причине. Я проверю, действительно ли мы используем junit. Благодаря! – MichalT

@MichalT Проверьте журнал консоли, который должен показать вам, почему сборка не удалась. Во всяком случае, у Фрэнка есть проблемы с жестами, они ненадежны. Если вы используете только простые штрихи, есть несколько причин, по которым тест может потерпеть неудачу, например. небольшая задержка между действиями (используйте «wait_for_nothing_to_be_animating» вместо сна). У меня была та же проблема, мои тесты выполнялись локально отлично. Однако оказалось, что неудачи денкинсов были почти всегда вызваны проблемой в тестах - или реальной ошибкой, которая проявлялась случайным образом. Всегда пытайтесь понять, почему тест не удался. – Sulthan

Извините, если я не знаю, или просто не понимаю философии огурца, но неудовлетворительные тесты обычно есть причина. В общем, узнайте, почему ваши тесты терпят неудачу, а затем исправляют эту проблему (или ваши тесты).

Чтобы ответить на ваш вопрос более непосредственно, вы можете зарегистрироваться в Log Parser Plugin. Чувство моего чувства говорит мне, что Дженкинс правильно отмечает работу как неудачную (или лучше нестабильную), когда тестовый тест терпит неудачу.

источник

2013-09-26 16:10:36

Спасибо. Тесты выполняются нормально, но иногда сбой при симуляторе iOS, или любое число (похоже) других мелких проблем, не связанных с кодом.В большинстве случаев при сбое сборки мы просто перезапускаем сборку, и она работает. Я надеюсь, что есть способ автоматизировать повтор без него, что приведет к сбою сборки в первую очередь. – MichalT

Вы когда-нибудь находили для этого работу, у меня такая же проблема, как и вы. @MichalT –

Не совсем я боюсь. Мы сделали это немного более стабильным, убедившись, что рубин и соответствующие драгоценные камни были a) обновлены, и б) то же, что и на локальных машинах (где у нас не было проблем). Мы также делаем обычную перезагрузку, которая, похоже, помогает ... @ deluded12ga – MichalT

почему вы не пытаетесь получить результаты тестирования с помощью заводной

def getResults(){ 
AbstractTestResultAction testResultAction = currentBuild.rawBuild.getAction(AbstractTestResultAction.class) 
       def failCount = null 
       def failureDiffString = null 
       def totalCount = null 
       def passed = null 
       def passrate = null 
       if (testResultAction != null) { 
        failCount = testResultAction.failCount 
        totalCount = testResultAction.totalCount 
        passed = totalCount - failCount 
        passrate = (passed/totalCount*100).toInteger() 
        } 

      return passrate 
}

и вы можете использовать что-то вроде этого:

if(getResults() >= 95){ 
    currentBuild.result="SUCCESS" 
    } else { 
     currentBuild.result="FAILED" 
     throw new Exception("Pass rate lower than 95%") 
    }

источник

2017-04-10 16:08:57 skaliber

Тесты на огурцы - повторные неудачи в Jenkins

ответ

Смежные вопросы