Выполнение интеграционных тестов на нескольких машинах

Question

У меня есть n-уровневое приложение с различными уровнями, работающими на разных машинах. Мне нужно выполнить закодированные интеграционные тесты на этих разных машинах, предпочтительно используя структуру MSTest, так как это то, что написано на всем остальном.

Проблема с оркестровкой заключается в том, что перед тем, как тесты на машине «B» могут запускаться, A "необходимо настроить правильно. VS из коробки, похоже, не справляется с этим сценарием, поэтому мне нужно что-то еще.

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

Так

а) Кто-нибудь успешно использовал TFS менеджер лаборатории для развертывания тест с помощью кода, который вышел из другой системы управления версиями? Если да, то как вы его настроили?

или

б) Существуют ли какие-либо альтернативные механизмы тестирования, которые позволят мне развернуть код на несколько машин, выполнить кодированные тесты и собрать результаты успех/провал?

Answer 1

Я собираюсь ответить на свой вопрос тем, что я на самом деле сделал: отказался от идеи лаборатории как слишком много работы для работы под рукой!

Сначала это выглядело многообещающе, и я уверен, что это возможно с достаточными усилиями, но, как отметили другие ответы, это означало бы существенные изменения в рабочем процессе лаборатории для достижения моей цели - путь больше, чем я могу оправдать. Не только возникла проблема с тем, что код не был построен с TFS, но я также столкнулся с проблемами, пытаясь сказать лабораторному/тестовому менеджеру, как запускать те тесты, где.

В конце концов я собрал половинное решение для дома, используя сценарий powershell для настройки среды (верните снимки гипер-v, скопируйте несколько файлов и запустите некоторые удаленные установки) и стандартную среду MSTest, встроенную в VS для выполнение тестов против среды.

Answer 2

a) Я не делал этого с различным контролем источника, но я думаю, что это возможно с TFS Lab Manager. Рабочий процесс TFS & Модель тестового контроллера/агента работает на основе диспетчера Windows Workflow в Lab, поэтому вы хотите изменить рабочий процесс для сборки (используя редактор XAML или пользовательский интерфейс Workflow в VS) и заменить любые вызовы управления источником TFS на свои собственные Задача установлена ​​для извлечения/версии/проверки кода. Фактически рабочий процесс TFS Lab отделен от рабочего процесса сборки и может просто собирать встроенные двоичные файлы из UNC-пути или что-то еще. Если вы выбрали последнее, вы можете создать код с помощью MSBuild и другого драйвера, например Jenkins, а затем использовать TFS Lab Manager для правильного выполнения тестов на каждом уровне.

b) И наоборот, вы можете полностью использовать Jenkins и подключаемые модули VMWare для вращения виртуальных машин вверх и вниз для тестирования. Вы можете использовать плагин Powershell и удаленную удаленную проводку или какой-либо другой плагин MSTest для выполнения удаленных тестов. Этот вариант мне кажется сложнее, но я думаю, что оба могут работать.

Answer 3

на основе ваших комментариев

код, я тестирование построен на месте с помощью VS. Тесты интеграции вручную запускаются.

Я ожидаю, что любая платформа CI будет работать с помеченной конструкцией в качестве входных данных.
На самом деле на ваши (оба) вопроса: я думаю, что пока вы не инвестируете усилия на обновление до стабильной среды сборки, вы обречены делать это вручную/самими сценариями.

Наличие сервера сборки - действительно вещь good, и, если вы собираетесь создать современную среду разработки, вы в принципе не можете обойтись без нее.

Если вас привлекла менеджер TFS Lab Manager, переходить с TFS-Build является обязательным. Если вы пойдет по этому пути, вы должны рассмотреть возможность переключения на все TFS - включая управление версиями.

Я бы сказал, что использование Perforce в качестве источника управления & TFS для сборки/тестирования абсолютно возможно, но это может быть головная боль, чтобы правильно настроить сборку (буквально все, что выходит из коробки относительно контроля источника, необходимо реорганизовать для p4-дружественных вызовов).