Все библиотеки DLL, необходимые для запуска тестов, попадают в одну папку, поэтому, если любой файл DLL с таким же именем, он будет перезаписан. MTM

Question

Поэтому моя проблема заключается в следующем. (Microsoft Test Manager, тестовый контроллер, тестовый агент)

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

Сервисы с другой версией имеют одинаковые имена на своих клиентских dll. Скажем, person.client.dll

Итак, здесь возникает проблема.

Когда я запускаю тесты (весь план тестирования), тест первой версии дает сбой, но не происходит, когда я запускаю их отдельно.

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

Копирование удаленного файла: C:\Users\service.tfstestcontr\AppData\Local\VSEQT\QTController\746\Deployment\Hogia.Person.Client.dll в: C:\Users\fredrik.almen\AppData\Local\VSEQT\QTAgent\746\isptest2013.hogia.local\Deployment\Hogia.Person.Client.dll

Так вот в чем проблема, если я точно определил это. Он скопирует все файлы в одну и ту же папку "развертывание". Сначала появится ранняя версия person.client.dll, затем вторая, перезаписав первую.

Это приведет к сбою в тестах Версии 1, потому что это идет вразрез с неправильной DLL.

Итак, моя первая мысль была. Разработчики должны переименовать свои библиотеки. Но вот другая проблема.

Наш клиент хочет простой способ перейти на новую версию, поэтому наличие такого же имени в DLL упростит их обновление.

Так что это не вариант.

Я строю все perproject, все они разные решения, но в одном определении сборки.

Мой вопрос

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

(Структура папок)

applicationServiceTests

PersonserviceTests

PErsonserviceTestsV2
см. ссылку вместо: http://prntscr.com/54vm0a

Вот так выглядит droplocation, поэтому они все разделены. Затем, когда я запускаю все тесты вместе, все dll-файлы из всех этих папок помещаются в одну папку для папки развертывания, то есть когда dll-файлы с одинаковыми именами переписываются.

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

(таким образом, решение иметь другое build_definition, вероятно, не будет работать для меня)

Есть ли в любом случае настроить testcontroller/testagent для разделения dll при выполнении копирования в тестовом прогоне. Это решило бы проблему для меня?

Answer 1

Вы не можете развертывать тестовые библиотеки и их зависимости в подпапках так, как вам этого хочется.
Если вы запускаете тестовый случай, автоматизированный с помощью модульного теста (или веб-теста, или упорядоченного теста), агент тестирования ищет dll, содержащую тест. Невозможно указать, какую подпапку развертывания использовать при запуске конкретного тестового примера.

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

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

Предложите, как продолжить запуск теста и собрать результат просто:
(см. комментарии ниже, описывающие, как в настоящее время осуществляется запуск тестов)

1. Создайте отдельный набор тестов Test Suite для каждой версии тестируемых сервисов.
2. Расширьте реализацию службы REST следующим образом:
   • переберите новые созданные наборы тестов и поставьте в очередь столько тестов, сколько вам нужно
     Эти тестовые прогоны будут выполняться один за другим
   • дождитесь завершения всех тестовых прогонов
   • отправить одно электронное письмо, содержащее отчет для всех тестовых прогонов