Используем TFS API для формирования сводных отчетов по автоматическим тестовым запускам

Совсем недавно я закончила проект по созданию автоматических CodedUI-тестов и внедрению их автоматического прогона в рамках выпуска сборки, используя инструментарий TFS. Запуск автоматических тестов происходит по следующей схеме:

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

2. Успешная сборка автоматически запускает ее выпуск, в рамках которого происходит восстановление базы данных, с которой работает приложение; на сервере клиента устанавливается агент тестирования и запускаются автоматические тесты пользовательского интерфейса (запуск тестов настроен в рамках задачи Run Functional Test Task, источник тестов - План тестирования, содержащий тестовые случаи со связанной автоматизацией, тип тестов - Coded UI Test).

3. Результаты тестового прогона анализируются, для каждого Failed-теста определяется тип сбоя (новая проблема, известная проблема и др.), способ разрешения (результатом сбоя может служить проблема приложения, неполадка теста или конфигурации) и создается комментарий.

Автоматический запуск тестов пользовательского интерфейса в рамках пункта 2 имеет следующую особенность. Тесты (всего их около 100) представляют собой некоторый end-2-end сценарий, согласно которому пользователь последовательно работает с разделами (их 8) приложения. Так как при работе с приложением возникает много зависимостей, связанных с текущим наполнением базы данных, то сделать тесты независимыми (учитывая их количество) оказалось невозможным. Кроме того, при проведении анализа автоматического запуска тестов оказалось весьма удобным иметь промежуточные копии состояний базы данных после работы "виртуального" пользователя с каждым разделом. 

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

Эта особенность приводит к тому, что TFS отображает не один тестовый запуск в рамках выпуска сборки, а восемь. В отчете TFS по каждому релизу можно увидеть сводный количественный результат по успешным тестам и тестам со сбоем в рамках выпуска. Однако, при проведении анализа каждого тестового случая со сбоем, нужно открыть его запуск в рамках конкретного релиза и провести анализ сбоя, те же действия нужно сделать, чтобы просмотреть детали по каждому сбою. Нам же хотелось иметь на выходе сводный отчет, где на одной странице можно было бы увидеть как общую сводную картину по количеству успешных и не успешных тестов, так и список всех тестовых случаев, со статусами, причинами сбоев, путями разрешения и комментариями. Так возникла идея создать приложение (остановились на обычном WinForm), которое позволило бы выбирать существующие в системе TFS тестовые запуски (причем как ручные, так и автоматические) и получать сводный Excel-отчет, который можно передать начальникам других отделов для ознакомления с результатами тестирования.

Сейчас я заканчиваю реализацию WinForm приложения, осталось поработать с внешним видом отчета, детально проработать его шаблон. Но уже сейчас отчет отображает следующую информацию:

1. Название отчета, дата построения отчета.

2. Общее количество тестов. Количество тестов со статусом "Пройден, "Сбой", "Другие". Добавлена диаграмма для наглядности.

3. Процент прохождения.

4. Общая длительность прохождения.

5. Таблица с тестовыми случаями, каждая строка которой отображает следующие данные: "№пп", "Идентификатор тестового случая", "Название тестового случая", "Тип запуска" (ручной, автоматический), "Статус" (Passed, Failed), "Тип сбоя", "Разрешение", "Комментарий". Последние 3 столбца - это информация по проведенному анализу сбоя в рамках конкретного запуска.

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

WinForm приложение получает информацию по тестовым запускам и их тестовым случаям средствами TFS API. 

1. Сначала отправляется запрос на сервер TFS для получения всех тестовых запусков.

Для GET запроса используется ссылка:

http://tfsserver:8080/tfs/DefaultCollection/{project}/_apis/test/runs/

2. Пользователь выбирает интересующие его запуски. 

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

Для GET запроса используется ссылка:

http://tfsserver:8080/tfs/DefaultCollection/{project}/_apis/test/runs/{runId}/results

4. Ответ на запросы приходит в формате JSON. На его основе создан класс, объекты которого и являются источником полученной информации для приложения. Согласно этим данным и заполняется шаблон Excel-отчета.

Признаюсь, что это был мой первый опыт работы с TFS API и JSON-файлами именно в рамках разработки, собственно, как и создание WinForm-приложения ;) Однако, это, несомненно, полезный опыт для меня, как развивающегося автоматизатора. Я не буду приводить исходный код своего приложения, но хочу поделиться некоторыми идеями и той информацией, которую я нашла на просторах Интернета, так как она оказалась весьма полезной и интересной.

Выше я уже изложила схему работы WinForm-приложения - оно отправляет GET-запрос TFS API и получает ответ в формате JSON.

Fiddler Extension - Request to Code

Каждый уважающий себя тестировщик должен уметь работать с Fiddler-ом или другими ему подобными инструментами. Пару дней назад я полюбила этот инструмент еще больше!

Дополнение Request to Code позволяет генерировать код на C#, VB или Python, который можно использовать для отправки запроса, вставив его в исходный код своего приложения (возможно, с некоторыми модификациями).

Для установки расширения нужно скачать его архив тут, распаковать и разместить FiddlerRequestToCode.dll в папку Scripts самого Fiddler-а, например, в моем случае это C:\Program Files (x86)\Fiddler2\Scripts. После перезапуска Fiddler-а появится вкладка Code.

Теперь, нужно отправить запрос серверу TFS (например, открыв ссылку http://tfsserver:8080/tfs/DefaultCollection/{project}/_apis/test/runs/ в браузере), найти этот запрос в журнале Fiddler-а. На вкладке Inspectors можно увидеть полученный от сервера TFS ответ.

Чтобы конвертировать запрос к API, например, в код C#, необходимо "захватить" требуемый запрос и "перетащить" его в область вкладки Code. Далее, выбрать требуемый язык программирования, установить флаг ReadResponse и  выбрать Copy Runnable Code.

Теперь можно вставить скопированный в буфер обмена фрагмент кода в свой проект. Чтобы понять как это работает, я создала пустой проект консольного приложения в среде разработки Visual Studio, удалила добавляемый по умолчанию код (кроме блока using) и вставила сгенерированный Fiddler-ом код (чтобы код выполнился, мне пришлось внести некоторые правки в блок using).

Если в методе makeRequest() установить точку останова после получения ответа от сервера TFS (ответ хранится в переменной responceText), то видно, что он приходит в формате JSON.

JSON десериализация

Следующий шаг - десериализация JSON с целью получить на его основе класс, объекты которого будут предоставлять данные из полученного ответа.

Для этого в Fiddler-е нужно перейти на вкладку Inspectors, раздел TextView, выделить и скопировать в буфер обмена текст (если ответ отображается "кракозябрами" - в строке меню выбрать пункт Rules и установить флаг Remove All Encodings).

В Visual Studio выполнить команду Edit → Paste Special → Paste JSON as Classes. Текст JSON будет конвертирован в класс C#.

Если пункт меню Paste JSON as Classes отсутствует, то необходимо установить расширение (Tools → Extensions and Updates), генерируюещее C# классы из JSON.

Теперь сама десериализация. Первое, что необходимо, добавить в References проекта ссылку на Newtonsoft.Json.dll. Для этого в Solution Explorer из контекстного меню для References выбрать Add Reference и ввести в поле поиска Json. Установить флаг напротив Json.NET и нажать OK.

В методе makeRequest(), после получения ответа с сервера TFS в переменную responseText, добавить строку 

                

Rootobject results = Newtonsoft.Json.JsonConvert.DeserializeObject<Rootobject>(responseText);

Теперь ответ сервера, например, на запрос результатов тестового запуска, состоящего из двух тестов, будет выглядеть примерно так:

А это значит, что теперь мы можем использовать эти данные для формирования Excel-отчета!