Друзья, всего 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 году.
При автоматизации тестирования очень часто приходится сталкиваться с вопросом «Что автоматизировать в первую очередь?» Автоматизация не делается ради автоматизации: хочется видеть результат процесса, который давал бы положительный ROI (подробнее о расчете ROI можно прочитать тут).
Почему важно использовать автоматизацию?
Принято считать, что автоматизация тестирования действует как инструмент поддержки ручного тестирования, но на самом деле важно понять, что автоматизация – это наилучший способ не просто сэкономить время, но и повысить эффективность, широту охвата и точность тестирования, ведь повторяющиеся задачи в условиях ручного подхода подвергаются риску человеческих ошибок. Автоматизация не превосходит и не заменяет ручное тестирование, но дополняет его. Подобно управлению тестированием автоматизация также нуждается в разработке стратегии с надлежащим планированием, мониторингом и контролем. Автоматизаторы не только изучают новые способы автоматизации, но и принимают много продуманных решений. Автоматизация при правильной реализации может стать преимуществом для команды, проекта и организации.
Работа с тестовыми инструментами обычно начинается с немедленной яростной обратной связи. Со временем программисты добавляют новые фичи, тестировщики – новые тесты, и тесты занимают все больше и больше времени. Чтобы чем-то себя занять, технический персонал работает над чем-нибудь еще, ожидая, пока тесты закончат работу.
Рано или поздно тест-результаты становятся такими медленными, что уже неактуальны – а даже если актуальны, нуждаются в археологах, чтобы разобраться, что в них вообще происходит. Все это можно предотвратить быстрой обратной связью.
Мои советы нацелены на ускорение петли обратной связи: тестируйте меньше, распределяя тесты во времени и пространстве. Для этого придется запускать расширенный набор инструментов, коммерческих или открытых, предоставляющих большее покрытие при более медленном темпе и быстрейшими, наиболее важными тестами, работающими непрерывно.
Привет, друзья-айтишники. Сегодня хочу поделиться с вами очередной порцией полезной
информации из мира автоматизации тестирования. Поговорим более детально о возможностях использования
Сhrome developer tools во время прогонов автотестов.
Записывать видео мы уже давно научились,
а вот использовать такой мощный инструмент, как devtools, пока еще нет.
Developer tools обладает обширным кругом возможностей. Мы с вами используем его каждый день: для поиска элеметов,
для того, чтобы посмотреть в network, возможно, даже попытаться замедлить браузер, чтобы посмотреть на поведение вашего сайта.
Использование devtools в тестах было невозможно, пока на одной из конференций не был
показан инструмент devtools proxy.
Сам прокси написан на Python, но это не ограничивает нас от использования его в Java проектах.
