Автоматические тесты в облаке

Если вы хоть немного тестируете, то знаете, как не просто создать среду с новым билдом для проверки. Если решение не сложное, то можно сделать все руками — стерли старые файлы, почистили реестр, базу, скопировали новый билд. Но если у вас серьезное многозвенное решение, то лучше, чтобы все операции были автоматизированы. Так можно уменьшить влияние человеческого фактора. Если вы обнаружите проблему, то достаточно поправить скрипты чтобы устранить ошибки и запустить всё заново. В Team Foundation Server входит полный комплект инструментов для организации Lab Management – среды управления тестовыми окружениями. Интересным является то что вы можете организовать лабораторию тестирования без всяких инфраструктурных инвестиций. Все что для этого необходимо – уже есть в Azure и Team Foundation Service. Это тот самый случай новомодного IaaS когда вы смело можете вынести часть инфраструктуры в облако.

Сценарий.

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

Под автоматизированными тестами подразумевается тест, который сам запускает программу, кликает по кнопкам, в общем повторяет интерактивные действия реального тестировщика.

Подготовка

Регистрируемся на http://tfs.visualstudio.com и создаем проект. После этого спроектируем наш тестовый стенд. Он будет состоять из двух виртуальных машин.

1. Десктоп клиент: машина на которой будет запускаться наше десктоп приложение и выполняться интерактивные тесты.
2. Сервер: машина на которой работают сервисы для нашего десктоп клиента, может быть это база данных, может веб-приложение.

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

Для того чтобы эти машины могли взаимодействовать между собой первым шагом в портале управления Azure необходимо создать виртуальную сеть:

Затем создаем две виртуальные машины для стенда и одну машину для билд-сервера:

При создании машин надо обязательно указать виртуальную сеть, которая была создана шагом ранее.

Для удобства можно взять готовую виртуальную машину для билд-сервера, в библиотеке есть машина с предустановленным Visual Studio 2013 Ultimate. Остальные машины пустые, это Windows Server 2012 или 2008 R2.
Для того чтобы вся наша облачная инфраструктура функционировала корректно, надо добавить дополнительные endpoints для соединений между клиентами (Visual Studio, Microsoft Test Manager), сервером TFS, и самими этими машинами.

Соответственно для остальных машин следует указать:

1. ct-lab: 137,138,139,6901,6910
2. ag-lab: 137,138,139,6910

Дополнительно, необходимо обеспечить видимость имен между этими виртуальными компьютерами в виртуальной сети. Для этого необходимо создать (или использовать существующий) DNS сервер и зарегистрировать его в нашей виртуальной сети. Для нужд моего сценария хватит и редактирования hosts. Более детально о настройке DNS можно почитать на портале Azure. Если DNS сервера нет, то при конфигурации Test Controller и Test Agent можно столкнуться с ошибкой CreateControllerObject: attempt 0, System.Net.Sockets.SocketException (0x80004005): No such host is known. Для ее разрешения прописываем в адаптерах машин DNS суффикс сloudapp.net.

Конфигурация

На машины ct-lab и ag-lab надо установить Test Controller и Test Agent. Вообще, не рекомендуется устанавливать на машину Test Controller еще и Test Agent, но делать это не возбраняется. Весь сценарий, который здесь приведен для инфраструктуры из трех компьютеров может быть установлен и на одну виртуальную машину (при этом упрощаются танцы с DNS и портами endpoints).

Компьютер ct-lab у нас будет в первую очередь Test Controller. После непродолжительной установки файлов из дистрибутива, наступит шаг конфигурации:

Соответственно далее устанавливаем и конфигурируем Test Agent на машине ag-lab:

Если вы все сделали правильно, то предварительные проверки перед конфигурацией покажут зеленые отметки на всех пунктах.

Конфигурация Test Manager

После того как вы создали инфраструктуру среды, следует сконфигурировать Lab Environment в Microsoft Test Manager.

Добавляем туда наши виртуальные компьютеры (с полными именами – ag-lab.cloudapp.net), Указываем роли из выпадающего меню (Desktop Client, Server) и конфигурируем контроллер:

После процедуры верификации конфигурации у вас через некоторое время (3-5 минут) должен включиться статус Ready в вашем окружении. Машина ag-lab при этом сконфигурирована в интерактивном режиме и там должен запуститься тестовый агент:

Конфигурация билд-сервера.

Готовая виртуальная машина Visual Studio 2013 Ultimate из библиотеки Azure не содержит Team Foundation Server 2013, поэтому скачиваем веб-инсталлер с сайта MSDN и устанавливаем TFS на машину bc-lab. Далее пропускаем шаги конфигурации сервера и выбираем только пункт конфигурации Build Server.
В нем указываем необходимые параметры и запускаем билд-контроллер и билд-агентов на машине bc-lab. К сожалению, Lab Management инфраструктура работает только с выделенными билд-контроллерами, виртуальный контроллер который входит в Team Foundation Service для этой цели не подойдет (нельзя создать больше чем один билд-агент).

Конфигурация билдов.

Для того чтобы наш сценарий заработал необходимо создать два определения билда привязанные к контроллеру bc-lab.

1. Собственно билд сборки: этот билд забирает последнюю версию нашего проекта, компилирует, и запускает модульные тесты.
2. Билд развертывания и запуска тестов: Далее эстафету подхватывает этот билд, копирует бинарные файлы на тестовые машины, и запускает автоматические тесты.

Думаю, у вас не будет никаких проблем с конфигурацией первого варианта, более подробно остановимся именно на втором. После заполнения стандартных параметров (откуда брать исходники, кто билд-контроллер) следует изменить шаблон билда на вкладке Process:

Нажимаем на кнопку конфигурации Lab Process Settings и далее по шагам проходим визард. Указываем в качестве имени окружения CloudEnv (мы создали его на шаге работы с Microsoft Test Manager) и наш билд компиляции. Далее ответственный шаг где следует указать скрипты развертывания:

Первый скрипт будет запущен на роли Desktop Client (компьютер ag-lab), второй соответственно на роли Server (это сt-lab). Скрипты следует положить в каталог c:\tools на этих машинах. Первый скрипт берет параметр $(BuildLocation) и копирует из сетевого диска собранные бинарники билда:

SET «inputpath=%1»
xcopy %inputpath% c:\Calculator /E /R /Y

Второй ничего не делает, просто Echo параметра, и здесь приведен в качестве иллюстрации. На самом деле мы ничего на Server не развертываем.
Пользователь, от лица которого по умолчанию запускается скрипт развертывания — это системный аккаунт. С одной стороны это позволяет делать что угодно внутри скрипта не опасаясь за access violation, но с другой несколько ограничивает сетевое взаимодействие.
Чтобы не пришлось вручную присоединять сетевой диск где находится билд, прописывая пароли в cmd, проще всего переделать параметры сервиса «Visual Studio Lab Agent Service» на машинах где устанавливается билд-агент:

Последний шаг визарда – это конфигурация того, какие тесты следует запускать:

Тестовый план, тестовую конфигурацию и настройки тестов нужно создавать в Microsoft Test manager.

Создаем автоматический тест

Финальный шаг – это создание и конфигурация тестов. Добавьте к вашему проекту тестов новый Coded UI Test. Его можно создать с нуля или же взять за основу то что записали в качестве Action Recording тестировщики. После того как тест создан, его нужно привязать к тест-кейсу, делается это в Visual Studio:

После чего этот тест-кейс добавляется в набор тестов (в нашем случае он называется Auto-BVT):

Для того чтобы CodedUITest не запускался во время модульного тестирования можно воспользоваться категориями тестов. Просто добавляем атрибут прямо в коде теста:

А затем производим фильтрацию в параметрах билда:

Как это всё работает вместе.

Теперь разработчику достаточно инициировать сборку билда Calculator-BVT и произойдет следующее:

1. Билд Calculator-BVT вызовет билд Calculator
2. Билд Calculator на контроллере bc-lab получит последние исходники нашего проекта из облачного TFS
3. Далее проект будет скомпилирован
4. Проведены модульные тесты
5. Если все ок, то управление возвращается билду Calculator-BVT
6. Этот билд запускает скрипты развертывания
7. А затем и автоматические тесты из тестового плана

Если все прошло нормально то в отчете билда будут указаны все эти шаги:

Что дальше.

Существует большое множество вариантов того как собираются проекты и проводятся тесты. Например, ваш билд может собирать проект для веб-роли Azure и автоматически развертывать его. А затем можно проводить автоматические тесты для веб-проектов. В тестовом окружении может быть большее или меньшее количество машин. При этом часть из них может вообще находиться в сети вашей организации. Так же вы можете оставить «у себя» билд-сервер вместе с контроллером. В общем вариантов конфигурации очень много, что позволяет получить необходимый уровень гибкости.

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