В моей компании мы внедрили автоматизированную визуальную регрессию в нашу стратегию тестирования для трех продуктов. Мы выбирали разные фреймворки для внедрения, и мы используем автоматизированное визуальное регрессивное тестирование с немного разными целями в каждой команде. В этой статье я делюсь концепцией автоматизированной визуальной регрессии и привожу конкретные примеры ее использования.
Что такое визуальная регрессия?
Внешний вид веб-приложения обычно определяется каскадной таблицей стилей (CSS). Ваш продукт может использовать другую разновидность CSS – например, SCSS, SASS, LESS. Все они описывают формат и развертку вашего пользовательского веб-интерфейса.
Когда вы вносите изменения в продукт, вы, скорее всего, меняете его внешний вид. Вы можете намеренно работать над задачей дизайна – к примеру, исправлять отображение модального диалогового окна – или же разрабатывать часть функциональности, которая проходит через пользовательский интерфейс, что означает, что вам придется менять содержание экрана – к примеру, добавлять поле логина к банковской учетной записи. В обоих случаях вам, возможно, нужно внести изменения в таблицу стилей.
Переход к модели непрерывной поставки ПО повлиял на растущую популярность автоматического тестирования. DevOps тоже голосуют за слом барьеров между традиционными ролями. Тестировщики, умеющие программировать (на самом деле этим автоматизаторы и являются) очень здорово встраиваются в эту новую парадигму.
Автоматизация тестирования предлагает множество потенциальных выгод, включая повышенную эффективность и предоставление работоспособного метода решения сложных задач тестирования. Автоматизирование тестов также дает повышенную систематичность, позволяя более эффективно использовать ресурсы в период провала нагрузки. Однако автоматизация – не панацея. Дабы осознать потенциал автоматизации, нужно быть в курсе трех распространенных ошибок автоматизации тестирования.
Друзья, всего 14 дней осталось до конференции TestCon Moscow 2018! Программа уже окончательно сформирована, спикеры во всеоружии. Вас ждут два полных дня докладов, целый день практических мастер-классов, игры, призы и сюрпризы.
А пока доклад Лилии Сапуриной «Разработка автоматизированной системы тестирования «с нуля»: основные проблемы и способы их решения», вызвавший в прошлом году много дискуссий.
В этом докладе автор описывает основные этапы построения автоматизированных систем тестирования. На основании своего опыта работы в крупной компании с установленной непрерывной интеграцией и разработанной практикой по использованию автоматизации Лилия рассказывает, как построить подобную систему в небольших компаниях, где весь процесс необходимо создавать с нуля.
В рамках прошедшей онлайн-конференции для тестировщиков КоТэ было проведено несколько мастер-классов.
Мы публикуем мастер-класс от Алексея Баранцева, на котором он показал как строить локаторы и рассказал о конкретных приемах и правилах, которыми он руководствуется при построении локаторов, чтобы они получались хорошими.
Автоматизация тестирования REST API на сегодняшний день является актуальной темой в интеграционном тестировании. В этой статье мы поговорим о программе Postman, применяемой для тестирования REST API, рассмотрим несколько интересных методов написания автотестов и на примере реального проекта API «Яндекс.Словарь» разберем несколько тестов.
Нам понадобится
Для того, чтобы начать тестировать «Яндекс.Словарь», нам понадобится:
Знание основ программирования. Достаточно владеть такими понятиями, как:
Проектируя автоматизированные UI-тесты, за годы работы я затвердил себе, что начинать надо с минимально валидными записями в системе. При таком подходе высвечиваются ложные предположения в различных частях системы, которые вряд ли были бы пойманы юнит-тестами.
Как я уже писал, я стараюсь настраивать тестовые данные для UI-тестов через системное API (даже если API – это чистый SQL, это все равно хорошая практика). В этом случае, когда ваш браузер стартует тест, все данные уже на местах.
К примеру (который большей частью правдив), предположим, что у вас есть запись в системе для Пользователя, и единственное необходимое поле для этой записи – это «Фамилия». Если вы начнете проектировать тесты с записями, где указана только «Фамилия», вы быстро обнаружите, где система предполагает наличие еще и «Имени», «Адреса, «Почты» или «Телефона». Чтобы узнать об этом больше, прочитайте хорошо известную статью "Falsehoods Programmers Believe About Names"
Недавно я столкнулся с особенно интересным подобным случаям, тестируя запись с полем, содержащим пустую строку. Я обнаружил, что часть системы, в которой я должен был иметь возможность удалить запись, не дает мне этого сделать: не хватает того самого поля. Система ожидала, что в этом поле будет текстовая строка, и собиралась произвести split() операцию над определенным символом этой строки, что вернуло бы массив символов, разделенных этим.
Друзья, до конференции TestConMoscow 2018осталось ровно три недели. Кроме тщательного отобранного контента, обещаем много драйва и сюрпризов. Так что приходите!
А пока еще один доклад прошлогодней конференции, привлекший огромное внимание: Вадим Зубович «Жизнь на костылях или Антипаттерны UI автоматизации»
На тему построения «правильной» автоматизации есть сотни докладов, однако, серебряной пули на все случаи жизни не существует и тут у многих начинаются проблемы. «Идеальные» подходы порой неприменимы, тогда в ход идут свои собственные решения, которые приводят к собственным ошибкам.
Именно об этих «ошибках», известных как «как НЕ надо делать» или «антипаттерны» говорится в докладе.
Автор рассматривает как антипаттерны в коде, так и в самом подходе к реализации автоматизации тестирования, с которыми ему доводилось регулярно сталкиваться и которые зачастую тормозили развитие проекта. Надеется, что вместе нам удастся впоследствии избежать этих расхожих неправильных представлений.
В рамках предстоящей конференции TestConMoscow 2018,которая пройдет в Москве 18-19 апреля,о каких только видах и инструментах тестирования не будет вестись речь. 33 доклада на выбор, программа готова.
Report Portal – open-source инструмент для отчетности в автоматизированном тестировании, созданный компанией EPAM. Построенный автоматизаторами, для автоматизаторов.
Каждый проект тратит время для того чтобы создать свою отчетность, она особенно важна для автоматизации тестов для распределенных систем, многопоточных запусков, большого количества тест кейсов, как для большой так и для маленькой команды. Report Portal предоставляет вам отчетность из коробки. Полнофункциональный инструмент для работы с отчетами, дэшбордами, виджетами, метриками, настраиваемыми типами дефектов, историей и автоматическому распознованию новых падений. Распознавание падений и дефектов, на основе алгоритмов машинного обучения, обучающегося с каждым новым прогоном. ReportPortal - это не только единое место для хранение всех результатов тестов автоматизированного тестирования, но и сокращает затраты команды на обработку и разбор результатов. В этом выступлении вы познакомитесь с основным функционалом, спецификами, бенефитами от использования, сравнение с конкурентами, и оцените применимость его в своем проекте. Не забывая что он бесплатен, и доступен в open source.
Среда автоматизированного модульного и интеграционного тестирования Cantata фирмы QA Systems (Германия) предназначена для тестирования программного обеспечения на языке C/С++ встраиваемых систем, подлежащих сертификации по стандартам безопасности ПО.
Новый основной релиз 8.0 включает ряд новых функций, главными из которых являются Code Change Analysis (управление внесением изменений в тесты при изменениях в исходном коде) и Target Deployment Switching (адаптация одного и того же набора тестов в случае использования ПО на различных аппаратных платформах с различными инструментальными средствами).
Новая версия 8.0 будет доступна с мая 2018г. Как и предыдущие версии 7.х она будет вскоре после выпуска сертифицирована SGS-TuV Saar GmbH на соответствие стандартам безопасности ISO 26262 (автоэлектроника), IEC 61508 (промышленное оборудование), EN 50128 (железнодорожные системы), IEC 60880 (системы безопасности атомных станций), IEC 62304 (медицинская техника). Так же, как версии 7.х, 8.0 будет сопровождаться комплектом квалификационных материалов по требованиям DO-178C (авионика).
Среда Cantata имеет более чем 20-летнюю историю. Она является развитием среды IPL Cantata ++, интеллектуальная собственность на которую была приобретена компанией QA Systems у компании IPL в 2012 году.
