Как сделать тестирование на разных средах?

Если вы сгенерировали тесты с помощью построителя тестов по умолчанию, вы можете попробовать написать что-то подобное в своем классе [CodedUITest]:

[TestInitialize()] 
public void MyTestInitialize() 
{ 
    // the url I could read from a config file
    string url = "http://stackoverflow.com/"; 

    this.UIMap.RecordedMethodXXParams.XXChWindowUrl = url; 
}

Где RecordedMethodXXParams и XXChWindowUrl генерируются автоматически. Вы можете проверить сгенерированные имена в классе UIMap.

Это слишком поздно, но на всякий случай это поможет читателям.

Для этого вам не нужно создавать несколько планов тестирования или наборов тестов в MTM. Что вам нужно, так это то, что сборки должны быть достаточно умными, чтобы выбрать правильную конфигурацию в зависимости от целевой среды. Как предложил Киаран, вы можете использовать конфигурацию xml, в которой есть все сведения о каждой среде, а затем написать некоторый фильтрующий код, чтобы отфильтровать детали на основе целевой среды, но ремонтопригодность может стать немного болезненной. В идеале вы хотели бы иметь один XML-макет для app.config, который будет загружать разные значения для каждой конфигурации в зависимости от целевой среды. т.е. xml в app.config преобразуется в зависимости от целевой среды.

SlowCheetah сделает это за вас. для реализации этого требуется немного чтения и понимания.

После того, как у вас есть все преобразования, используйте «Диспетчер конфигураций» в Visual Studio, чтобы описать все целевые среды. Вы можете найти его в раскрывающемся списке рядом с зеленой кнопкой запуска/запуска в Visual Studio.

Создайте отдельную сборку CI (т. е. триггер = регистрация) тестового кода (т. е. проект закодированных тестов пользовательского интерфейса), предназначенный для каждой тестовой среды, используя раздел «Процесс»> «Сборка»> «Конфигурации» определения сборки.

Создайте сборку лабораторного теста (т. е. с использованием LabDefaultTemplate) для каждой целевой среды, в которой используется один и тот же набор тестов из диспетчера тестов. убедитесь, что каждая сборка сопоставляется с соответствующей сборкой CI в разделе сборки мастера рабочего процесса процесса.

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

Вам, вероятно, потребуется отредактировать закодированные тесты пользовательского интерфейса, чтобы изменить URL-адрес браузера, который запускается при запуске тестов. Когда я выполнял автоматические тесты закодированного пользовательского интерфейса в разных браузерах, когда тесты начинались, я читал из файла конфигурации XML в каждой тестовой среде, чтобы получить правильный URL-адрес браузера (и любые другие соответствующие данные конфигурации). Другими словами, вам понадобится хотя бы немного кода для обработки разных URL-адресов или любых данных конфигурации для каждой тестовой среды.

Для фактического запуска тестов в удаленных средах вам следует загрузить Microsoft Test Controller и Test Agents (Ссылка для скачивания). И вот документация по установке и настройке агентов.

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

Microsoft Test Manager также имеет параметры командной строки, чтобы вы могли планировать автоматические тесты (например, вы могли запускать сценарий из планировщика задач Windows).

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

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

ОБНОВИТЬ:

Прошло много времени с тех пор, как я работал с автоматизацией тестирования, поэтому я не помню подробностей своей реализации, но, насколько я помню, в моей системе у меня был файл конфигурации XML, хранящийся в тестовой среде (например, C: \MyTestConfig\config.xml со значениями XML для различных параметров конфигурации, важным из которых является URL-адрес, который я хочу запустить, например.

<browserUrl>http://localhost:1659/whatever</browserUrl>

Затем у меня был класс в тестовом проекте, который при создании экземпляра получал XML-файл конфигурации (он хранился в одном и том же месте в каждой тестовой среде) и считывал значения. Прошло много времени с тех пор, как я это сделал, поэтому я не могу вспомнить свою точную реализацию, но в Интернете есть много документации для чтения XML в С# .NET. Затем из моих тестовых классов я унаследовал класс, который считывает значения конфигурации, а затем из методов настройки тестов в тестовых классах запускал браузер с URL-адресом браузера из XML-файла и запускал тесты. Если вы не знаете, как создавать методы настройки тестов, я бы посмотрел документацию по используемой вами тестовой среде (которая, скорее всего, будет средой модульного тестирования Visual Studio, поскольку она используется по умолчанию с закодированными тестами пользовательского интерфейса).