Меня зовут Даниил Охлопков, и я расскажу про свой подход к написанию скриптов, извлекающих данные из интернета: с чего начать, куда смотреть и что использовать.
Написав тонну парсеров, я придумал алгоритм действий, который не только минимизирует затраченное время на разработку, но и увеличивает их живучесть, робастность, масштабируемость.
Привет! Мы в Wrike тестируем новые форматы технических мероприятий и приглашаем всех посмотреть видео нашего первого онлайн-митапа на английском. Поговорили про DevOps инфраструктуру для тестирования веб-приложений, кубы, Selenium и его альтернативы.
Этой статьей мы продолжаем серию публикаций о том, как мы автоматизировали в одном из крупных проектов ЛАНИТ процесс ручного тестирования (далее – автотесты) большой информационной системы (далее – Системы) и что у нас из этого вышло.
Как эффективно организовать иерархию классов? Как распределить пакеты по проектному дереву? Как сделать так, чтобы забыть о мердж-конфликтах при команде в 10 человек? Эти вопросы всегда стоят при старте новой разработки и на них никогда не хватает времени.
В этой статье мы описываем структуру классов и организацию кода, которая позволила нам небольшими силами разработать более полутора тысяч end-2-end UI тестов на базе Junit и Selenium для крупной системы федерального значения. Более того, мы ее успешно поддерживаем и постоянно дорабатываем существующие сценарии.
Здесь вы сможете найти практическое описание структуры иерархии базовых классов автотестов, разбиения проекта по функциональной модели java-packages и шаблоны-образцы реальных классов.
Статья будет полезна всем разработчикам, которые разрабатывают автотесты на базе Selenium.
Читать полностью »
Этой статьей мы продолжаем серию публикаций о том, как мы автоматизировали в одном из крупных проектов ЛАНИТ автопроцесс ручного тестирования (далее – автотесты) большой информационной системы (далее – Системы) и что у нас из этого вышло.
Вторая часть публикации ориентирована в первую очередь на лидеров групп автоматизации UI end-2-end тестирования и ведущих тест-автоматизаторов. Здесь они найдут конкретные рецепты по архитектурной организации кода и развертывания, которая поддерживает массо-параллельную разработку больших групп тестов в условиях постоянной изменчивости тестовых спецификаций. В этой части приведен полный состав необходимых для UI-тестов функций с некоторыми деталями реализации, а также есть перечень сюрпризов, с которыми вы можете столкнуться.
Вот здесь вы найдете Часть 1. (Зачем нам была нужна автоматизация. Организация процесса разработки и управления. Организация использования)
Этой статьей мы открываем серию публикаций о том, как автоматизировали в одном из крупных проектов компании ЛАНИТ процесс ручного тестирования большой информационной системы и что у нас из этого вышло.
Первая часть – организационно-управленческая – должна быть полезна в первую очередь тем, кто отвечает за автоматизацию тестирования и создает такие системы в целом. Руководители проектов, лидеры групп и владельцы сервисов функционального и автоматического тестирования, все, кого волнует вопрос «как построить экономически эффективное end-2-end тестирование своей ИТ системы», найдут здесь конкретный план и методику.
Наше подразделение создает полностью автоматические пайплайны для вывода новых версий приложений в прод-среду. Разумеется, для этого требуются автоматизированные функциональные тесты. Под катом — история о том, как, начав с тестирования в один поток на локальной машине, мы дошли до многопоточного запуска автотестов на Selenoid в пайплайне сборки с Allure-отчетом на GitLab pages и в итоге получили крутой инструмент для автоматизации, который смогут использовать будущие команды.
15 марта в питерском офисе Wrike прошла встреча автотестировщиков. Поговорили о новых эффективных подходах и инструментах в сфере автоматизации тестирования, оценили их применимость в тех или иных кейсах и спешим поделиться записью докладов и презентациями.
