Повторите попытку теста автоматизации с ошибкой из логической точки для автоматизации E2E

Question

Мы пытаемся автоматизировать тестовые наборы E2E для приложения бронирования, которое включает в себя около 60+ шагов для каждого тестового случая.Всякий раз, когда на последних этапах происходит сбой, мы тратим очень много времени, если мы перейдем к традиционному варианту повтора, поскольку тестовый пример будет выполнен снова с шага 1.В приложении у нас есть несколько логических шагов, которые можно как-то пометить, с помощью которых мы хотим добиться возобновления тестового примера с логической точки до неудачного шага.Скажем, например, среди 60 шагов, скажем, каждый 10-й шаг - это логическая точка, в которой сценарий может быть возобновлен вместо повторения с шага 1. Скажем, если сбой произошел в строке № 43, то с помощью контрольного номера бронирования проверяетсяможет быть возобновлен с этапа № 41, поскольку проверка была завершена до этапа 40 (этап 40 является логической точкой закрытия).Возможно, вы можете предложить вариант разбить тестовый набор на более мелкие модули, что мне не подойдет, поскольку это тестовый пример E2E для приложения, которое мы хотели бы иметь в одной спецификации Geb.Фреймворк построен с использованием Geb & Spock для автоматизации веб-приложений.Пожалуйста, поделитесь своими мыслями / логикой о том, как мы можем построить сценарии восстановления для этого случая.Спасибо за вашу поддержку.!

На данный момент я не могу найти решение этой проблемы.

Answer 1

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

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

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

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

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

Answer 2

Возможное решение вашей проблемы - сначала определить, каким образом вы хотите написать свои тесты. Я бы рекомендовал рассматривать один тест Spec (класс) как один тест E2E, содержащий несколько функций. Кроме того, после реализации RetryOnFailure

рекомендуется использовать проект с открытым исходным кодом Spock Retry , доступный на GitHub.

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

@RetryOnFailure(times= 2) // times parameter is for retry attempts, default= 0
class MyEndtoEndTest1 extends GebReportingSpec {
def bookingRefNumber

def "First Feature block which cover the Test till a logical step"()
{
// your test steps here
bookingRefNumber = //assign your booking Ref here
}

def "Second Feature which covers a set of subsequent logical steps "()
{
//use the bookingRefNumber generated in the First Feature block
}

def "Third set of Logical Steps"()
{ // your test steps here
}

def "End of the E2E test "()
{ // Your final Test steps here
}

Передача всех функциональных блоков (методов) будет означать успешное выполнение теста E2E.

Answer 3

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

Теперь, если вам нужно добиться этого, тогда

Создавайте журнал каждый раз, когда вы достигаете контрольной точки, который может быть простым текстовым файлом с указанием имени тестового набора и номера контрольной точки, затем используйте анализатор повторных попыток для запуска неудачных тестов, внутри теста ищите текстовый файл с тестом имя дела, если оно существует, просто пропустите код до контрольной точки, указанной в текстовом файле. Его можно использовать по-разному, например, если ваш e2e тестирует 3 приложения, то файл может иметь имя тестового примера и имя последнего переданного приложения, если вы использовали объекты страницы, вы можете записать последнее успешное имя объекта страницы в текстовый файл и использовать его для продолжения тест.

Вышеупомянутое решение - просто идея, потому что я не думаю, что существуют какие-либо решения для этой проблемы.

Надеюсь, это даст вам представление о том, как начать работать над этой проблемой.