В любой команде, которая уделяет тестированию должное время, наступает момент, когда задается вопрос об автоматизации этого процесса.
Как это произошло? Путей разработки несколько: либо тестировщики сами начинают автоматизировать, либо нанимают специально обученного человека, который как панацея должен решить все проблемы.
Независимо от того, как это произойдет, в конечном итоге мы все сталкиваемся с тем, что нам нужно как-то показать, что происходит, какова реальность – что сделано.
Как сказал один мой коллега, «автоматизация ради автоматизации — это подобие культа Карго», так как бывает, что отдел автоматизации есть, а результата нет. Итак, основная задача инженера по автоматизации – облегчить жизнь.
На этот раз мы собираемся облегчить жизнь отделу ручного тестирования (если он есть) или себе, если весь процесс тестирования доверить нашим плечам.
Некоторые структурные данные
В нашей компании есть отдел ручного тестирования и отдел автоматизации.В качестве системы организации тестов используется достаточно популярный инструмент TestRail. На мой взгляд, это удобно и достаточно функционально.
Автоматизация также построена на достаточно стандартном наборе Ruby + Cucumber + Watir/Selenium (можно упомянуть паттерн Page Object) + TeamCity. Что происходит, когда на тестирование отдают новый билд (в нашем случае каждый раз, когда мы имеем дело с регрессией)? Тестер создает новый прогон теста, который включает в себя все тестовые случаи из определенного набора тестов и — начинается самое интересное.
Уверен, всем знакомо это чувство, когда вручную запускаешь регрессию или в 4-й раз куришь на машине, кликая/такая по всем элементам и устанавливая статус для следующего теста.
В этот момент перед твоими красными глазами наверняка все плывет и картинка в голове повторяет известную: 
И иногда: 
Именно сейчас мы приходим на помощь.
Так уж случилось, что возникла идея.
Если у нас есть автоматизация, то почему мы до сих пор не используем результаты нашей работы, чтобы облегчить себе жизнь? Идея состоит в том, чтобы использовать отчет из TestRail вместо громоздких и запутанных отчетов из Cucumber. Довольно интересная задача — заставить тесты в TestRail сами менять свой статус в зависимости от того, как прошел автотест. Путем поиска во всемогущем Google было обнаружено, что документация по TestRail API помогает реализовать эту благую цель.
Мы решили начать с того, что при запуске наших автотестов вся информация о текущем состоянии тестов отображалась в TestRail. Собственно, цель была достигнута — нажав на кнопку запуска тестов в RubyMine, мы автоматически создали новый тестран и отправили результаты на сервер.
Довольно просто, учитывая существующую информацию на сайте TestRail. Как оказалось, это было только начало.
В итоге нам удалось создать довольно неплохой функционал, а именно настроить интеграцию TestRail + TeamCity + Automation Framework. Теперь подробности, уважаемые дамы и господа.
ТестРейл
Нашей первой остановкой будет TestRail. TestRail — программное обеспечение для управления данными, полученными в результате тестирования.Этот инструмент помогает вам отслеживать процессы, управлять программным обеспечением и организовывать свою команду.
С TestRail вы можете создавать тестовые сценарии, управлять тестовыми примерами и координировать весь процесс тестирования программного обеспечения.
TestRail предоставляет возможность повысить производительность и получить полную прозрачность вашего процесса тестирования.
Начнем с того, что первое, что должен сделать наш пользовательский/ручной тестер, — это создать собственно тестран, который мы в дальнейшем будем использовать для обновлений.
Требования: Особенность: Запуск автотестов.
Использовать автоматизацию в реальной жизни.
Я как пользователь хочу, чтобы была волшебная кнопка «запустить прогон с автотестами».
Сказано - сделано.
К счастью, функциональность TestRail позволяет нам интегрировать собственный код.
В результате у нас есть вот такая кнопка: 
Да-да - Начать Тесты.
Собственно код этой кнопки.
Поскольку у нас есть тест-кейсы для веба и мобильного для одного пакета, на первом этапе мы проверяем по названию тестрана, какой фреймворк используется.name: Trigger tests for run description: Triggers automated tests for a test run author: Gurock Software version: 1.0 includes: ^ runs / view excludes: js: $(document).ready( function() { /* Create the button */ var button = $('<div id="start_auto_test" class="toolbar content-header-toolbar"><a class="toolbar-button toolbar-button-last toolbar-button-first content-header-button button-start" href=" javascript:void(0) ">Start Tests</a></div>'); /* Add it to the toolbar */ //if ($('.
toolbar-button.content-header-button.button-edit').
length > 0) { $("#content-header .
content-header-inner").
prepend(button); //} /* Disable test run button */ if (uiscripts.context.run.name.indexOf('in progress') >= 0 || (uiscripts.context.plan != undefined && uiscripts.context.plan.name.indexOf('in progress') >= 0)) { $("a", button).
addClass('toolbar-button-disabled button-add-disabled'); } /* Bind the click event to trigger the automated tests */ $("a", button).
click( function() { if (!$("a", button).
hasClass("button-add-disabled")) { App.Dialogs.message( 'The tests are being processed in the background and the results are automatically posted back to TestRail.', 'Confirmation' ); platform = uiscripts.context.run.name.split(" ")[0]; ventures = uiscripts.context.run.name.split(" ")[1]; if (platform == 'OMS') { var teamcity_oms_build_trigger_url = ' http://TeamCityServer/httpAuth/action.htmlЭadd2Queue=BuildName&name=reverse.dep.*.
test_run_id&value= ' + uiscripts.context.run.id; } popup = window.open(teamcity_build_trigger_url, "windowName", "height=200,width=200"); setTimeout(function() { popup.close(); }, 1000); /* Change the test run/test plan name to disable button */ var api_url, new_data; if (uiscripts.context.plan == undefined) { api_url = uiscripts.env.page_base + '/api/v2/update_run/' + uiscripts.context.run.id; new_data = JSON.stringify({ "name": uiscripts.context.run.name + ' (in progress)' }); } else { var entries = []; $.
ajax({ url: uiscripts.env.page_base + '/api/v2/get_plan/' + uiscripts.context.plan.id, type: 'GET', dataType: 'json', contentType: "application/json; charset=utf-8", data: new_data, success: function(data) { entries = data.entries; var selected_entry; $.
each(entries, function(index, entry) { if (entry.name == uiscripts.context.run.name) { return selected_entry = entry; } }); api_url = uiscripts.env.page_base + '/api/v2/update_plan_entry/' + uiscripts.context.plan.id + '/' + selected_entry.id; new_data = JSON.stringify({ "name": uiscripts.context.run.name + ' (in progress)' }); $.
ajax({ url: api_url, type: 'POST', dataType: 'json', contentType: "application/json; charset=utf-8", data: new_data, success: function(data) { $("a", button).
addClass('toolbar-button-disabled button-add-disabled'); } }); } }); }; $.
ajax({ url: api_url, type: 'POST', dataType: 'json', contentType: "application/json; charset=utf-8", data: new_data, success: function(data) { $("a", button).
addClass('toolbar-button-disabled button-add-disabled'); } }); } } ); } );
В зависимости от того, для чего предназначен тестран, запускаем сборку на TeamCity. Чтобы пользователь не нажимал на кнопку слишком часто, у нас есть надежная защита — после нажатия на кнопку мы добавляем к названию тестрана ключ «в процессе», это блокирует волшебную кнопку до тех пор, пока наши автотесты не завершат свою работу.
Платформа автоматизации
На заключительном этапе был создан гем/библиотека, которая при развертывании дает нам интеграцию с TestRail на любом из наших подпроектов.Создание гема – это совсем другая история, достойная отдельной статьи.
Короче говоря, наша библиотека test_rail_integration Имеет небольшой функционал, которым мы пользуемся сами, но мне кажется, что он тоже может кому-то пригодиться.
Сначала вам нужно установить его: gem install test_rail_integration
Далее добавьте: TestRail::Hook.update_test_rail(scenario)
После |сценария| крючки.
И в файле env.rb:
if ENV['TESTRAIL'] == '1'
puts 'Option : TestRail [ON]'
require "test_rail_integration"
require 'test_rail_integration/generator/test_rail_hooks'
end
Вот команды для запуска: test_rail_integration check_test_run_and_update
В нашем случае тесты проводились для 6 разных локализаций и все результаты отображались в 1 тестовой стране.
Иногда возникала ситуация, когда одновременно приходили два обновления.
Оказалось, что они не видели друг друга и после сбоя пришёл статус пропуска.
Эта опция изменила общую картину статуса теста.
По сути, эта команда проходит все тесты и проверяет их согласованность, отсутствие красных результатов в зеленых тестах.
Если есть, то статус теста меняется на красный.
test_rail_integration create_test_run
Здесь все просто, этой командой мы создаем тестран с указанным именем в наборе проектов, который мы прописали в конфиге.
Команда возвращает номер созданного скалывателя: test_rail_integration perform
Прописывать ее нужно при первом запуске, так как эта команда генерирует файл конфигурации, в который нужно указать необходимую информацию о TestRail: test_rail_integration shoot
Это основная функциональность с флагами: --test_run_id
Здесь все понятно, нужно указать номер тестового рана: --venture
И --env
Конкретные атрибуты, которые будут использоваться при составлении команды для запуска (если, например, вам нужно запускать свои тесты через определенную команду, то в конфиге нужно прописать ее с использованием этих переменных, тогда при запуске мы должны указать их ): --showroom
Этот флаг тоже специфичен и, думаю, никому больше не пригодится: --command
Здесь вы можете указать новую команду для текущего запуска: --auto
Так как мы используем всю интеграцию для 6 локализаций, то ищем имя по номеру тестрана и разбираем его на параметры, чтобы у тестрана было имя, например, DT SG staging. Здесь мы находим необходимую информацию для начала работы.
--simple
Запуск без поиска и проверки каких-либо параметров — самая полезная команда для вас, дорогой читатель.
--type
Вы также можете определить количество типов тестов, которые будут запущены.
Полная команда для запуска тестов с существующим тестовым запуском будет выглядеть так: test_rail_integration shoot --test_run_id 1 --simple
Или: test_rail_integration shoot --test_run_id 1 --simple --command <cucumber -t > --type 3
TeamCity
Здесь, строго говоря, все просто.Мы просто пишем команду так же, как запускали бы ее локально, за исключением того, что для удобства можем добавить несколько переменных и объединить порядок запуска команд (если мы запускаем сборку автоматически, то сначала нужно указать команду для создать тестран, чтобы потом запускать тесты с номером, который пришел к нам ранее).
Вот и все.
Поскольку это мой первый опыт написания статьи, критика приветствуется.
Надеюсь, что я все это достаточно понятно написал и данное руководство будет кому-то полезно.
Время профессиональных оценок Я хотел бы поблагодарить следующих людей за помощь и руководство: Любовь Шишову, Евгения Пустовита, Сливку Василия, Дмитрия Коновалова, Никиту Никон, Игоря Роздобудько, Андрея Толпеева и Алексиса Грохара, а также мою любимую команду 24/7 Entertainment and IT Labs. .
Ссылка на репозиторий: github.com/Kirikami/test_rail_integration Ссылка на библиотеку: Rubygems.org/gems/test_rail_integration Теги: #автоматизация тестирования #testrail #ruby #Тестирование веб-сервисов #Тестирование мобильных приложений
-
Fap Turbo — Торговый Робот Форекс
19 Oct, 24 -
Возьмите Ipad Для Редактирования Файлов Avi
19 Oct, 24 -
Торрент Бред Сибирьтелекома
19 Oct, 24 -
Данные На Сервере Marklogic [Часть 1]
19 Oct, 24
