В первая часть этой статьи Я полностью описал процесс настройки автоматизации тестирования с помощью RM. Во второй (и заключительной) части статьи я расскажу о некоторых проектных решениях, проблемах, с которыми мы столкнулись при настройке системы, и способах их преодоления.
Один или несколько пулов агентов?
Вопрос : Как перенаправить определение выпуска на соответствующий компьютер агента, т. е.на компьютер с ресурсами, необходимыми для этого определения выпуска? Решение : Когда мы начали создавать определения выпусков, стало очевидно, что каждое определение выпуска необходимо направить соответствующему агенту, поскольку у каждого набора тестов разные требования.
Первоначально мы создали отдельный пул агентов для каждого определения выпуска, но управлять большим количеством пулов агентов оказалось сложно.
В конечном итоге мы воспользовались советом Криса Паттерсона из команды разработчиков и разработали систему, в которой использовался единый пул агентов под названием RMAgentPool. Все агенты в этом пуле отличались друг от друга пользовательскими возможностями.
Каждое определение выпуска и определение сборки теперь выполняется соответствующим агентом с использованием возможности RmCdpCapability. Например, компьютер, подготовленный для RM.CDP.TfsOnPrem, имеет возможность RmCdpCapability=TfsOnPrem: 
RM.CDP.TfsOnPrem RD направляет свое выполнение этому агенту, используя требование RmCdpCapability=TfsOnPrem: 
JIT-отладка
Вопрос : Как отладить периодические сбои, когда файлы журналов не содержат достаточно данных? К тому моменту, когда разработчики обнаружат проблему, следующий тестовый запуск устранит «неисправное состояние» с тестового компьютера.
Решение : Если поведение набора тестов непредсказуемо, мы включаем задачу «Приостановить агент при сбое теста» в определении выпуска: 
Эта задача приостанавливает выпуск, если в непредсказуемом тесте возникает ошибка.
В этой ситуации разработчик может удаленно подключиться к компьютеру-агенту, состояние которого будет точно соответствовать состоянию на момент возникновения ошибки.
Обратите внимание, что это возможно только в том случае, если значение тайм-аута среды равно 0 (тайм-аут отсутствует).
Задача «Пауза» принимает следующие аргументы (выделены на рисунке выше): -AlternateCredentialsUserName $(release.alternateusername) -AlternateCredentialsPassword $(release.alternatepassword) -ReleaseId $(Release.ReleaseId) -TaskName $(TaskToDebugName) -NumberOfSeconds $(TaskToDebugTimeInSeconds) Ключевой аргумент здесь — $(TaskToDebugName): это важно.
«Запустить тесты RMCDPOnPrem» для RM.CDP.TfsOnPrem, т. е.
имя задачи, в которой возникают периодические сбои.
Все определения выпуска RM.CDP.* включают одну и ту же задачу с одинаковыми аргументами, но значение $(TaskToDebugName) в каждом определении выпуска соответствует задаче, периодические сбои которой мы хотим отладить.
Исходный код этой задачи можно найти Здесь (вместо «Ваша учетная запись» следует подставить имя учетной записи и использовать ее).
Как запустить тесты в режиме администратора на компьютере с агентом?
Вопрос : Даже если агент запущен с правами администратора, он выполняет задачу в режиме, отличном от режима администратора.Это делает невозможным выполнение задачи, которую необходимо выполнить в режиме администратора (например, установку службы на компьютер агента).
Решение : Мы решили эту проблему, используя задачу «Powershell на целевых машинах» и удаленно получив доступ к текущему компьютеру агента от имени администратора.
Например, мы устанавливаем службу TFS в RM.CDP.RmEqTfs следующим образом: 
Тесты, которые не могут повторно использовать задачу VsTest.
Вопрос : Некоторые тесты созданы относительно давно (назовем их «устаревшими») и несовместимы с задачей VsTest. Как в таких ситуациях можно воспользоваться преимуществами отчетности, которые предоставляют тесты, совместимые с задачами VsTest? Решение : Для решения этой проблемы мы предприняли следующие шаги:- Мы запустили устаревшие тесты с помощью пакетного сценария или задачи PowerShell (в зависимости от того, что удобнее) и нашли выходной файл журнала.
- Мы добавили задачу VsTest, которая анализировала выходные данные файла журнала, найденные на предыдущем шаге, и определяла, было ли выполнение теста успешным.
Затем запускается задача VsTest для анализа файла журнала и проверки наличия в нем ошибок.
Примечание.
До недавнего времени тестовый код RM.CDP.DevFabricUpgrade, совместимый с VsTest, просто записывал в файл журнала «Ожидалось истинное, но найдено ложное», что очень затрудняло отладку.
Разработчики были вынуждены открыть выходной лог-файл RunAOConfigTest.ps1, что само по себе занимало много времени, так как файл был довольно большим, и искать в нем настоящую ошибку, как показано на скриншоте ниже: 
Недавно мы изменили этот код, чтобы более тщательно проанализировать выходной файл журнала RunAOConfigTest.ps1. Теперь при неудачном тестировании отображается более подробная информация об ошибке: 
Как устранить узкие места при выполнении тестов?
Вопрос : Некоторые определения выпуска занимают очень много времени, что приводит к образованию очереди и значительному увеличению времени их обработки.Что можно улучшить в этой ситуации? Решение : Поскольку большая часть нашего тестирования разработана с развертыванием службы и выполнением тестов на машине с агентом, мы можем просто установить дополнительное оборудование (с правильным RmCdpCapability) в определениях проблемных выпусков.
Как проводить UI-тесты?
Вопрос : Как запустить тесты пользовательского интерфейса на машине с агентом? Решение : Быстрый и примитивный способ решения этой проблемы — запустить агент в интерактивном режиме (не в сервисном), так как в сервисном режиме агент не может взаимодействовать с настольным компьютером.Недостаток этого метода заключается в том, что функция автоматического обновления не поддерживается, когда агент работает в интерактивном режиме: для обновления агента требуется войти в компьютер агента и перезапустить агент. Более автоматизированный подход — запустить агент в сервисном режиме и использовать задачи «Развертывание агента тестирования Visual Studio» и «Тестирование Visual Studio с использованием агента тестирования».
агент") соответственно.
Мы используем метод, аналогичный описанной выше задаче "Powershell на целевых машинах", при котором мы удаленно входим на текущий компьютер агента с правами администратора.
Эти задачи выполняются на агенте службой тестирования, настроенной для взаимодействовать с настольным компьютером.
Чтобы использовать этот метод, сначала создадим группу подходящих компьютеров в разделе «Тест»: 
Затем мы используем эту группу компьютеров в двух упомянутых выше задачах VS Test Agent. В задаче «Развертывание агента VsTest» необходимо выбрать «Интерактивный процесс»: 
Наконец, задача «Проверка Vs с использованием агента тестирования» запускает тесты на нашей группе компьютеров, используя те же фильтры, что и стандартная задача VsTest: 
Стоит отметить, что в ближайшем будущем этот процесс станет более последовательным; нам больше не нужно будет создавать группы компьютеров для задач агента тестирования и достаточно будет указать имя компьютера в параметре $(Agent.MachineName).
Какие переменные доступны во время выполнения?
Вопрос : Какие переменные доступны во время выполнения? Решение : переменные, доступные во время выполнения и которые можно использовать в определении выпуска, перечислены в начале следующих журналов:
Можно ли масштабировать RM для удовлетворения потребностей нашей группы?
Вопрос : По мере приближения к концу спринта количество обзоров в нашей группе увеличивается в геометрической прогрессии, и у нас возникают сомнения, что RMO справится с такими нагрузками.Выполнение 15 проверок в день на этапе выпуска является обычной практикой и подразумевает 15 * 9 = ~135 развертываний в день (поскольку каждая проверка активирует девять определений выпуска).
Решение : Сервис RMO изначально проявлял некоторую нестабильность при высоких нагрузках, но мы устранили это с помощью серии стресс-тестов во второй половине 2015 года.
Сейчас RMO легко справляется с задачами нашей группы.
На снимке экрана ниже показано около 20 выпусков RM.CDP.DevFabircUpgrade, завершенных за последние 24 часа, что соответствует 20 * 9 = 180 выпускам нашей группы за тот же период времени.
Заключение
Надеюсь, этот пост поможет вам решить большинство проблем, возникающих при автоматизации тестирования с помощью RM. Теги: #разработка веб-сайтов #тестирование #тестирование ИТ-систем #Visual Studio #тесты #управление релизами #управление релизами #mstesting-
Цифровые Шпионские Камеры
19 Oct, 24 -
Основы Решений Резервного Копирования
19 Oct, 24 -
Гравитационные Накопители Энергии
19 Oct, 24
