Эта статья является продолжением. Первую часть смотри тут

Подход к реализации

Представьте что у вас команда специалистов, которая по принципу code-first делает систему с множеством бизнес-историй на базе микросервисов. Все люди опытные, всем есть что делать кроме того как писать документации или спецификации на разработанный API. И все изначально знают, что если захотел использовать какой сервис, то надо заглянуть в код и потом спросить в общем чате если что непонятно. Знакомая ситуация не так ли? -))) И в целом все нормально, если бы со временем не росла команда, не росло количество сервисов и функций, не появлялись баги от бизнеса и тестеров, не требовалось предоставлять API для интеграции смежным командам...

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

Есть задача нагрузочно потестировать фронтальные веб рест апи. Ресты защищены OAuth с Authorization Code Grant. Значит появляется необходимость наличия валидного токена для Authorization: Bearer TOKEN.
Вопрос — как его взять? И так это сделать красиво и правильно? Вот тут я не знаю.

В этой статье я описал то быстрое решение к которому я пришел и которое мне не вполне нравится. Выглядит костыльным, хотя я и не нагуглил ничего серебряного. Поэтому, если вы знаете лучшее решение — обязательно скажите об этом в комментарии… Итак…

Есть обычная типовая система с веб рест фронтом и типовым Single-Page-Application браузерным клиентом на JS. Аутентификация и авторизация — KeyCloak с Authorization Code Grant + brokering.

Надо обеспечить регулярное нагрузочное тестирование фронтовых рест сервисов.

Автоматизация End-2-End тестирования комплексной информационной системы
Часть 2-2. Реализация процесса выгрузки файла из контейнера с браузером в тестовый фреймворк. Поиск имени загруженного браузером файла

Автор: habr.com/ru/users/anrad
Хабы:
Теги: #autotest, #selenium, #selenoid, #headlessbrowser, #download

Когда мы в разработке End-2-End автотестов для UI столкнулись с вопросом “Как получить имя последнего загруженного браузером файла из WebDriver?”, нагуглить ничего по-быстрому не получилось. Поэтому я и написал эту статью, в которой заодно рассказал, в чем именно у нас была проблема и как мы ее решили.

Этой статьей мы продолжаем серию публикаций о том, как мы автоматизировали в одном из крупных проектов ЛАНИТ процесс ручного тестирования (далее – автотесты) большой информационной системы (далее – Системы) и что у нас из этого вышло.


source

Этой статьей мы продолжаем серию публикаций о том, как мы автоматизировали в одном из крупных проектов ЛАНИТ процесс ручного тестирования (далее – автотесты) большой информационной системы (далее – Системы) и что у нас из этого вышло.

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

Источник

В этой статье мы описываем структуру классов и организацию кода, которая позволила нам небольшими силами разработать более полутора тысяч end-2-end UI тестов на базе Junit и Selenium для крупной системы федерального значения. Более того, мы ее успешно поддерживаем и постоянно дорабатываем существующие сценарии.

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

Статья будет полезна всем разработчикам, которые разрабатывают автотесты на базе Selenium.

Этой статьей мы продолжаем серию публикаций о том, как мы автоматизировали в одном из крупных проектов ЛАНИТ автопроцесс ручного тестирования (далее – автотесты) большой информационной системы (далее – Системы) и что у нас из этого вышло.

Вторая часть публикации ориентирована в первую очередь на лидеров групп автоматизации UI end-2-end тестирования и ведущих тест-автоматизаторов. Здесь они найдут конкретные рецепты по архитектурной организации кода и развертывания, которая поддерживает массо-параллельную разработку больших групп тестов в условиях постоянной изменчивости тестовых спецификаций. В этой части приведен полный состав необходимых для UI-тестов функций с некоторыми деталями реализации, а также есть перечень сюрпризов, с которыми вы можете столкнуться.

Вот здесь вы найдете Часть 1.  (Зачем нам была нужна автоматизация. Организация процесса разработки и управления. Организация использования)

Источник

Этой статьей мы открываем серию публикаций о том, как автоматизировали в одном из крупных проектов компании ЛАНИТ процесс ручного тестирования большой информационной системы и что у нас из этого вышло.

Первая часть – организационно-управленческая – должна быть полезна в первую очередь тем, кто отвечает за автоматизацию тестирования и создает такие системы в целом. Руководители проектов, лидеры групп и владельцы сервисов функционального и автоматического тестирования, все, кого волнует вопрос «как построить экономически эффективное end-2-end тестирование своей ИТ системы», найдут здесь конкретный план и методику.

Источник