Как лучше провести сквозное тестирование в распределенной системе, используя рабочий процесс github PR? - PullRequest
Новая
       4

Как лучше провести сквозное тестирование в распределенной системе, используя рабочий процесс github PR?

0 голосов
/ 17 января 2020

Моя команда использует внутреннюю среду тестирования e2e для проверки того, что все, от http-запроса до http-ответа, работает должным образом.

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

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

Как мы справляемся с этим, принимая, что задание e2e Jenkins будет временно красным, пока кто-то не объединит e2e PR с обновлением / добавлением теста / с.

Из-за Принятие задания e2e красным цветом «временно» приводит к другим изменениям, которые могут содержать или не содержать проскальзывания ошибок.

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

Итак, мой вопрос: что может сделать моя команда, чтобы решить эту проблему?

Я хочу, чтобы мы сохраните тесты e2e, поскольку они очень полезны, но ими можно пренебречь по указанным выше причинам.

Можем ли мы каким-то образом t ie сделать репозиторий e2e для каждой ветви функций, чтобы, когда кто-то отправляет код для ветви, ветвь функций с тем же именем в нашей сервисной службе e2e запускается против нее и блокирует PR до тех пор, пока они не обновят тесты e2e?

  • Для этого нужно как-то связать тестовое репо e2e так что изменения кода появляются в функции PR для соответствующего сервиса / лямбды. Не уверен, если это возможно.

Буду очень признателен за любые советы / примеры о том, как проводить e2e-тестирование с использованием рабочего процесса github для распределенной архитектуры микроуслуг / лямбда в AWS.

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

1 Ответ

1 голос
/ 17 января 2020

Обычная стратегия тестирования, которую вы можете принять для тестирования e2e, состоит в том, чтобы разделить их выполнение:

  • для запроса на извлечение: изолировать некоторые быстрые и непрочные тесты e2e и включить их в основной конвейер
  • для основной ветки (или ветки релиза в зависимости от вашей стратегии): выделите еще несколько непроблематичных тестов e2e, которые занимают больше времени. выполнить их вместе с тестом e2e, выполняемым с PR
  • , запланировать задание на выполнение всех тестов e2e ежедневно или два раза в день, например

Что касается вопроса о e2e когда тесты будут красными в момент их обновления, я бы предложил изменить стратегию доставки:

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

На самом деле нет идеального решения для теста e2e, но я надеюсь, что дал у вас есть некоторые идеи

PS: у вас есть внутренняя среда тестирования, построенная на Selenium? Если это так, я бы рекомендовал использовать решение Selenium Grid, например, zalenium https://opensource.zalando.com/zalenium/

...