К основному контенту

Запуск Unit test VS на build сервере TFS

1. Для дальнейшей работы в TFS необходимо наличие соответствующих прав
2.     На билд сервере потребуется установить Visual Studio.
3.     После установки VS в списке возможностей билд-агентов  должно появиться (или добавить вручную) VS, VSTest, msbuild, dotNetFramework и прочие capabilities с адресом расположения на сервере
4.     В TFS, на вкладке сборка, необходимо собрать следующие шаги (первые 2 не обязательны):

5.     В NuGet installer необходимо заполнить поля Path to Solution и NuGet arguments (если используется локальный нагет сервер)
Причем в NuGet arguments нужно указать 2 адреса: локальный (-Source http://локальное расположение/Packages/nuget) и внешний (-Source https://api.nuget.org/v3/index.json).
6. В шаге VSTest нужно указать адрес $(build.sourcesDirectory)/Папка_автотестов/**/UnitTest.dll;-:**\obj\**
 Но предварительно нужно собрать MSBuild ($(build.sourcesDirectory)/папка_автотестов/Test.sln )
         В advanced поле Path to MSBuild заполняется в том случае, если не подходят стандартные версии MSBuild (Version).

Также необходимо указать путь на сервере. Например: $Папка_проекта$(BuildConfiguration)/папка_ваших_автотестов.
7.     После подготовки данных шагов осталось поставить сборку в очередь и ожидать результата. Шаг VSTest выполнится последним и запустит все unit test. Просмотреть результат можно по любому из методов.





Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н...
Отправить комментарий
Далее...

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут по...
3 комментария
Далее...

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия ...
1 комментарий
Далее...