тестирование мобильных приложений selenium
Тестирование android приложений с использованием selenoid. Поиск location в мобильном приложении с помощью Appium
Я из компании Luxoft.
Предисловие из поста:
Selenoid — это программа, которая позволяет управлять браузерами и Android-эмуляторами с помощью специальных драйверов. Умеет запускать каждый из них изолированно в Docker-контейнере.
Основная идея Selenoid состоит в том, чтобы запускать новый контейнер для каждой сессии (запуска нового браузера или эмулятора) и останавливать его сразу же после закрытия сессии.
Selenoid позволяет поддерживать высокую нагрузку без дополнительных ресурсозатрат.
В этом посте будет запуск простых тестов в Android-эмуляторе.
Подготовка
Предварительно проверьте что ваша система может запускать виртуальные машины.
Аппаратная виртуализация должна поддерживаться вашим процессором. Это означает, что требуются расширения процессора IntelVT или AMDV. Чтобы убедиться, поддерживает ли процессор одно из них, выполните команду:
Docker
На вашей операционной системе обязательно должен быть установлен и запущен Docker.
Установка Selenoid
Если у вас Redhat-based операционная система, вы можете использовать мой репозиторий для установки Configuration manager.
Если у вас не Redhat-based операционная система, то вы можете скачать и использовать бинарник Configuration manager.
Запуск Selenoid используя Configuration manager и формирование browsers.json
Если у вас нет прямого доступа в инет и docker образы вы скачиваете через registry:
Если у вас есть прямой доступ в инет.
Так как Selenoid Configuration manager пока что не умеет формировать browsers.json для мобильного Chrome, то его нужно поправить самостоятельно.
По умолчанию browsers.json формируется в директории
Итоговый файл browsers.json для тестирования Android приложений и Chrome внутри Android эмулятора.
Пока что версия мобильного хрома отстает от версии обычного хрома.
Скачиваем образ мобильного хрома
Изменение browsers.json
При изменении файла browsers.json нужно перезагрузить selenoid
Reloading configuration
Можно сделать Reloading configuration. Подробности по ссылке:
https://aerokube.com/selenoid/latest/#_reloading_configuration
Проверяем что docker контейнер запустился и образы скачались.
Запуск Selenoid UI используя Configuration manager
Проверяем что docker контейнер запустился и образы скачались.
Заходим в selenoid-ui по адресу ip-где-вы-запускали-selenoid-и-selenoid-ui:8080
У вас должно быть гореть зеленым 2 слова CONNECTED и написано android и chrome.
Чтобы получить доступ из Android на хостовую нужно в тестах использовать полное или короткое имя виртуальной машины, где запускается selenoid.
DEMO TEST
Во всех трех java файлах меняем путь в RemoteWebDriver на полное или короткое имя виртуальной машины, где запускается selenoid (надо поменять скриншот).
или на другой адрес, там где вы запустили selenoid.
В файле AndroidRemoteApkTest.java меняем путь где можно скачать вашу APK.
По этой ссылке http:/полное-или-короткое-имя-виртуальной-машины-где-запускается-selenoid/ваша-apk вы должны скачивать APK как с виртуальной машины так внутри docker образов (в том числе и android).
Можно протестировать так:
Если вы будете ссылаться на localhost из docker, то у вас будет вот такая ошибка, так как вы из сети docker пытаетесь обратиться к localhost основного сервера:
Как сделать доступной для скачивания ваши локальные файлы будет ниже.
В файле DemoTest.java добавляем setCapability для запуска chrome на Android чтобы получилось примерно так.
В каждом файле java вы можете включить или выключить запись видео, удаленный просмотр или управление через VNC и запись логов в файл. Чтобы выключить опцию нужно добавить 2 слеша в начало строки.
Чтобы сделать доступной для скачивания файлы из текущей директории, можно запустить в текущей консоли сервис static-server-in-dir:
Запуск тестов
В директории demo-tests запускаем тесты:
Если вам нужно указать настройки и у вас используется maven-прокси (Nexus, Artifactory)
Если запускаем с прямым доступом в инет и без каких-либо настроек
Скорость
Общее время разворачивания android эмулятора и запуск 1 теста занимает меньше 1 минуты.
Selenium, Selenoid, Selenide, Selendroid… Что все это значит?
В мире автоматизации новичку ориентироваться довольно сложно. Приходится узнавать множество понятий, разбираться в особенностях существующих инструментов. Например, вот: Selenium, Selenide, Selenoid, Selendriod — что это, чем отличается? Да и можно ли их сравнивать?
Написал статью, чтобы помочь в этом разобраться. Кому интересно, добро пожаловать под кат!
Selenium
Selenium — это инструмент для автоматизированного управления браузерами.
В рамках проекта Selenium разрабатывается серия программных продуктов с открытым исходным кодом:
После установки Selenium Server к нему можно обращаться с другого компьютера для удаленного управления браузерами по специальному протоколу, который написан поверх HTTP.
Коротко — Selenium Server помогает управлять браузерами на определенной машине.
Более подробно можно почитать здесь: https://www.seleniumhq.org/
Selenium Grid устанавливается на одном компьютере и может работать удаленно с несколькими другим, на которых установлены Selenium Server.
Он создан для того, чтобы запускать тесты на большом количестве машин, обращаясь только к одной, на которой установлен Selenium Grid.
Для создания сессии (т.е. запуска браузера) мы всегда будем приходить на компьютер, где стоит Selenium Grid. Он уже сам решит, какая машина менее нагружена для этого и туда и перенаправит команду.
Все машины, с которыми работает Selenium Grid, могут работать под управлением разных операционных систем, на них могут быть установлены разные браузеры.
Коротко — Selenium Grid нужен для организации работы с несколькими машинами, где установлен Selenium Server.
Selenium IDE – это плагин к браузеру Firefox, с помощью которого можно записывать и воспроизводить действия пользователя.
Он не имеет особого отношения ни к Selenium Server, ни к Selenium Grid и позволяет работать только с локальным браузером.
Selenide
Selenide — это один из фреймворков для автоматизированного тестирования веб-приложений. С его помощью можно быстро и относительно просто писать код, который будет формировать и отправлять HTTP-команды на Selenium Server или Selenium Grid.
Он заточен под то, чтобы писать такие сценарии, которые будут проверять работу веб-приложения: поиск нужных элементов, проверка событий, взаимодействие с UI и так далее.
Несмотря на схожесть названия с линейкой программ Selenium, сам Selenide разрабатывают другие ребята.
Коротко — с Selenide проще писать код, который заточен именно под тестирование веб-приложения.
Более подробно можно почитать здесь: https://ru.selenide.org/
Selenoid
Selenoid — это программа, которая позволяет управлять браузерами и Android-эмуляторами с помощью специальных драйверов. Умеет запускать каждый из них изолированно в Docker-контейнере.
Selenoid представляет собой альтернативное решение Selenium Server, хотя суть та же — организация работы драйверов.
Основная идея Selenoid состоит в том, чтобы запускать новый контейнер для каждой сессии (запуска нового браузера или эмулятора) и останавливать его сразу же после закрытия сессии.
Selenoid позволяет поддерживать высокую нагрузку без дополнительных ресурсозатрат.
Selendroid
Selendroid — это фреймворк для автоматизированного тестирования мобильных приложений на базе Android.
Используется на ранних версиях Android — до 17 level api (android 4.2). Но не выше.
Коротко — это уже не очень актуальные фреймворк для работы с Android-приложениями.
Более подробно можно почитать здесь: http://selendroid.io
Итого
Инструментов много, каждый предназначен для своих задач. Постарался коротко и без воды рассказать про группу Selen-проектов. 🙂
Если такой формат будет интересен, далее сделаю обзор на инструменты для мобильной автоматизации.
Селениум: тестирование веб-приложений и другие полезные функции
Selenium — это не одиночный инструмент, как многие считают по ошибке. Селениум — это целый набор разношерстного инструментария, который решает задачи разного уровня по тестированию. Поэтому если говорить о Селениуме, то нужно коснуться всего набора инструментов.
Селениум: набор инструментов
Selenium IDE — это специализированный плагин для FireFox, который дает тестировщикам возможность проводить запись своих действий для будущего анализа. Он способен разработать тестовые случаи, но только в «Огненной Лисе», так как другие браузеры он не поддерживает. При этом записанные сценарии тестирования можно конвертировать в другие языки программирования, чтобы выполнить их в других браузерах. Это простой в использовании плагин. Он не требует для тестирования глубоких знаний языков программирования, так как способен сам остоятельно сформировать нужный код.
Selenium RC — это полноценная среда для тестирования, которая дает возможность применять популярные языки программирования: Java, C#, PHP, Python, Ruby, PERL и другие. Данная среда уже практически не применяется и не рекомендуется для использования.
Selenium WebDriver — это среда для тестирования, которая пришла заменить Selenium RC. По сути, WebDriver — это несколько специальных библиотек для разных языков программирования, которые можно применять для написания программ для управления браузером. Это свободный набор библиотек, поэтому их можно использовать в разных браузерах. Selenium WebDriver позволяет создать собственный фреймворк для тестирования.
Selenium Grid — это крутой инструмент, который позволяет одновременно запускать по несколько тестов на разных устройствах или разных браузерах, что ускоряет сам процесс тестирования.
Особенности инструментов Селениум
Каждый из существующих на рынке инструментов имеет свои особенности, что отличает один инструмент от другого. Набор инструментов Селениум имеет свои особенности:
Открытый исходный код.
Расширяет свои возможности при подключении дополнительных технологий.
Работает с разными браузерами.
Работает с разными операционными системами.
Функционирует на мобильных устройствах.
Проводит тестирования прямо в браузере.
Можно проводить тестирования на разных устройствах одновременно, применяя Selenium Grid.
Недостатки набора инструментов Селениум
У Селениум есть свои недостатки:
Тестирует только веб-приложения.
Отсутствуют сценарии восстановления и хранилище объектов.
Нет полноценной IDE.
Не дает возможность контролировать элементы управления в браузере.
По умолчанию не генерирует отчеты о тестировании.
Заключение
Селениум идеально подойдет для тех, кто уже устал все тестировать «руками», потому что Selenium — это эффективный набор инструментов для автоматизации тестирования.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
DevPoint: Selenium в тестировании веб-приложений
С такими ситуациями очень часто сталкивался и меня это не устраивало. При поиске подходящего метода/инструмента тестирования я наткнулся на Selenium. И применяю его уже более 3-х лет.
В Киеве 9-го апреля прошла конференция DevPoint, посвященная web — разработке. Организатором данного мероприятия была компания Uniweb. В рамках ее, решил поделиться впечатлением про Selenium.
Selenium состоит из множества подпроектов, но выделить хотел только три:
Selenium Core — JavaScript Framework для написание и выполнения тестов. Используется в Selenium IDE и Remote Control*.
Selenium IDE — плагин для Firefox, который позволяет записывать и воспроизводить тесты. Также может генерировать код тестов для использования в Selenium Remote Control.
Selenium Remote Control — клиент-серверная система, которая позволяет Вам управлять веб-браузерами локально, или на других компьютерах, используя практически любой язык программирования
В рамках этого доклада про Selenium Core не было времени акцентировать внимание, хотя этот проект наиболее интересен для написания тестов с нетривиальной логикой.
Selenium IDE
Применяем Selenium IDE на практике
Для примера взял живой старый проект, который покрыть тестами задача еще та. Это обычный интернет-магазин, который используется для внутренних оптовых закупок в одной компании, имен не называем…
Первый тест, который мы напишем будет просто авторизоваться в системе:
И последних два теста, которые покрывают логику создания и редактирования заказа:
И для проверки наших тестов было намерено испорчено сохранение заказа:
Selenium Remote Control
Selenium Remote Control — это http демон, который принимает команды через GET и выполняет их. API по общению с Selenium RC есть почти под все языки программирования. В данном докладе речь идет только про API для PHP, которое предоставляется c PHPUnit
Как уже говорилось ранние в Selenium IDE есть приятная опция по генерированию кода для *Unit:
Таким образом вы можете просто копировать код и выполнять его в своих PHPUnit suite.
Также в PHPUnit — Selenium есть возможность запускать тесты написанные в Selenium IDE:
Без напильника не обойтись…
Для решения проблемы с выполнением команд wait* нужно рассмотреть как они выполняются в PHPUnit:
Фактически мы зацикливаем выполнение команды, на определенный интервал и ждем пока наше условие не станет true. Реализация PHPUnit — Selenium посылая команду Selenium RC ждет от нее только два ответа, что все хорошо или что все плохо. Если пришел ответ ERROR, то он сразу закрывает браузер, пишет что произошла ошибка и соответственно наш цикл будет слать команды в уже закрытую сессию Selenium RC.
Код с решением этих проблем я выложил на github и не буду на нем останавливаться.
Еще из приятных вещей в Selenium RC то, что он умеет делать скриншоты при обнаружении ошибки:
Минус в том, что на скриншотах не подсвечивается место возникновения ошибки, но по тексту в PHPUnit обычно легко понять что не так.
Дергаем за ниточки не FireFox
Selenium для всех: как мы учим QA-инженеров работать с автотестами
Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo в отделе QA, занимаюсь автоматизацией тестирования, а иногда и автоматизацией автоматизации тестирования.
Сегодня я расскажу о том, как мы в Badoo упростили работу с Selenium-тестами, научили ребят из отдела ручного тестирования работать с ними и какой профит с этого получили. Прочитав статью, вы сможете оценить трудозатратность каждого из этапов и, возможно, захотите частично перенять наш опыт.
Введение
Со временем количество автотестов становится довольно внушительным, и приходит понимание, что система, в которой количество автоматизаторов – константа, а количество тестов непрерывно растёт, – неэффективна.
В Badoo серверная часть наравне с Desktop Web релизится два раза в день. Об этом очень подробно и интересно рассказал мой коллега Илья Кудинов в статье «Как мы уже 4 года выживаем в условиях двух релизов в день». Я советую ознакомиться с ней, чтобы дальнейшие примеры в этой статье были вам более понятны.
Вполне очевидно, что чем выше покрытие автотестов, тем бóльшее их количество окажется затронутым в процессе релиза. Где-то изменили функционал, где-то поменяли вёрстку и локаторы перестали находить нужные элементы, где-то включили A/B-тест и бизнес-логика для части юзеров стала другой и так далее.
В какой-то момент мы оказались в ситуации, когда правка тестов после релиза занимала почти всё время, которое было у автоматизатора до следующего релиза. И так по кругу. Не оставалось времени на написание новых тестов, на поддержку и развитие архитектуры и решение каких-то новых задач. Что делать в такой ситуации? Первое решение, которое приходит в голову, — нанять ещё одного автоматизатора. Однако у такого решения есть существенный минус: когда тестов снова станет в два раза больше, мы снова будем вынуждены нанимать ещё одного автоматизатора.
Поэтому мы пошли по другому пути, мы решили научить ребят из отдела ручного тестирования работать с тестами, условившись, что в своих задачах они будут самостоятельно править тесты до релиза. Какие плюсы у этого решения?
Во-первых, если тестировщик способен поправить автотест, он тем более способен разобраться в причине его падения. Таким образом, повышается вероятность, что он найдет баг на максимально раннем этапе тестирования. Это хорошо, потому что исправить проблему в этом случае можно быстро и просто, а задача уедет на продакшн в назначенный due date.
Во-вторых, наши автотесты для Desktop Web написаны на PHP, как и сам продукт. Следовательно, работая с кодом автотестов, тестировщик развивает в себе навык работы с этим языком программирования, и ему становится легче и проще понять дифф задачи и разобраться, что там было сделано и куда стоит в первую очередь посмотреть при тестировании.
В-третьих, если ребята правят тесты, они иногда могут выделять время для написания новых. Это и интересно самому тестировщику, и полезно для покрытия.
И последнее, как вы уже поняли, у автоматизатора появляется больше времени, которое он может тратить на решение архитектурных вопросов, ускоряя прохождение тестов и делая их проще и понятнее.
С плюсами разобрались. Теперь давайте подумаем, какие могут быть минусы.
Тестирование задачи начнет занимать больше времени, потому что QA-инженеру придется помимо проверки функционала исправлять тесты. С одной стороны это действительно так. С другой стороны стоит понимать, что маленькие задачи у нас в Badoo превалируют над масштабными рефакторингами, где затрагивается всё или почти всё. О том, почему это так и как мы к этому пришли, хорошо рассказал глава отдела QA Илья Агеев в статье «Как workflow разработки влияет на декомпозицию задач». Следовательно, исправления должны сводиться к нескольким строчкам кода, а это не займет много времени.
В крупных же задачах, где сломалось большое количество тестов, и багов тоже может быть много. Не раз мы сталкивались с ситуацией, когда в процессе починки тестов после таких рефакторингов находились баги, пропущенные при ручном тестировании. А как мы помним, чем раньше мы найдём баг, тем легче его исправить.
Итак, дело за малым – сделать тесты пригодными для того, чтобы в них мог разобраться человек, не имеющий опыта написания автотестов.
Рефакторинг тестов
Первый этап был довольно скучным. Мы принялись за рефакторинг наших тестов, стараясь максимально отделить логику работы теста со страницей от логики самого теста, так, чтобы при изменении внешнего вида проекта было достаточно поправить несколько констант-локаторов, не трогая при этом код самого теста. В итоге у нас получились классы наподобие PageObject. Каждый из них описывает элементы, относящиеся к одной странице или одному компоненту, и методы взаимодействия с ними: дождаться элемент, подсчитать количество элементов, кликнуть по нему и так далее. Мы договорились, что никаких логических проверок типа assert в таких классах быть не должно – только взаимодействие с UI.
Благодаря этому мы получили тесты, которые читаются довольно просто:
И простые UI-классы, которые выглядят примерно так:
Теперь, если локатор для пароля изменится, и тест сломается, не найдя нужное поле ввода, будет понятно, как его поправить. Более того, если метод enterPassword() используется в нескольких тестах, изменение соответствующего локатора починит сразу всё.
В таком виде тесты уже можно показывать ребятам. Они читаемые, и с ними вполне можно работать, не имея опыта написания кода на PHP. Достаточно рассказать основы. Для этого мы провели ряд обучающих семинаров с примерами и заданиями для самостоятельного решения.
Обучение
Обучение велось постепенно, от простого к сложному. После первого занятия была задача починить сломанный тест, где нужно было поправить несколько локаторов. После второго занятия требовалось расширить существующий тест, дописав несколько методов в UI-класс и использовав их в тесте. После третьего ребята уже вполне могли написать новый тест самостоятельно.
На основе этих семинаров были написаны статьи в нашу внутреннюю Wiki о том, как правильно работать с тестами и с какими подводными камнями можно столкнуться в процессе. В них мы собрали best practices и ответы на часто задаваемые вопросы: как правильно составить локатор, в каком случае стоит создавать новый класс под тест, а в каком – добавлять тест в уже существующий, когда создавать новый UI-класс, как правильно называть константы для локаторов и так далее.
Сейчас, когда в компанию приходит новый QA-инженер, он получает список тех самых статей из Wiki, с которыми необходимо ознакомиться для работы с автотестами. И когда он в процессе тестирования впервые сталкивается с падающим тестом, он уже во всеоружии и знает, что делать. Само собой, в любой момент он может подойти ко мне или к другому автоматизатору и что-то уточнить или спросить, это нормально.
У нас есть договорённость, что умение QA инженера работать с автотестами, в том числе писать новые – это одно из требований для роста внутри компании. Если ты хочешь развиваться (а кто же не хочет, верно?), надо быть готовым к тому, что придётся заниматься и автоматизацией в том числе.
TeamCity
Наши Selenium-тесты лежат в том же репозитории, где и код проекта. Когда мы только начинали писать первые Selenium-тесты, у нас уже был PHPUnit и некоторое количество unit-тестов. Чтобы не плодить технологии, мы решили запускать Selenium-тесты, используя тот же PHPUnit, и положили их в соседнюю с unit-тестами папку. Пока тестами занимались только автоматизаторы, мы могли вносить правки в тесты сразу в Master, поскольку делали это уже после релиза. И, соответственно, запускали в TeamCity тесты тоже с Master.
Когда ребята начали работать с тестами в своих задачах, мы договорились, что правки будут вноситься в ту же ветку, где лежит код задачи. Во-первых, это обеспечивало одновременную доставку правок для тестов в Master с самой задачей, во-вторых, в случае отката задачи из релиза правки для неё также откатывались без дополнительных действий. В итоге мы начали запускать тесты в TeamCity с ветки релиза.
Таким образом, мы получили систему, в которой автоматизатор может следить только за тестами для релиза, а новая задача при этом приходит в релиз сразу с правками для тестов. В такой системе пожизненный зелёный билд обеспечен. 🙂
Запуск тестов по диффу задачи
Гонять все тесты для каждой задачи крайне затратно как по времени, так и по ресурсам. Каждый тест необходимо обеспечить браузером, следовательно, нужно поддерживать мощную Selenium-ферму. Также нужен мощный сервер, на котором будет развёрнут проект и по которому параллельно будет ходить большое число автотестов. А это – дорогое удовольствие.
Мы решили, что было бы круто вычислять динамически для каждой задачи, какие именно тесты стоит запускать. Для этого мы каждому тесту присвоили набор групп, которые привязаны к проверяемым фичам или страницам: Search, Profile, Registration, Chat, и написали скрипт, который отлавливает тесты без групп и пишет соответствующие нотификации автоматизаторам.
Далее перед запуском тестов на задаче мы при помощи Git научились анализировать изменённые файлы. Они по большей части тоже называются как-то похоже на фичи, к которым имеют отношение, или лежат в соответствующих папках:
Мы придумали пару правил для файлов, которые не соответствуют названию ни одной группы. Например, у нас часть файлов называется, скажем, не chat, а messager. Мы сделали карту алиасов и, если натыкаемся на файл, который называется messager, запускаем тесты для группы Chat, а если файл лежит где-то в core-папках, то мы делаем вывод, что стоит запустить полный набор тестов.
Конечно, универсального алгоритма решения такой задачи не существует – всегда есть вероятность, что изменение в каком-то классе затронет проект в самом неожиданном месте. Но это нестрашно, поскольку на стейджинге мы запускаем полный набор тестов и обязательно заметим проблему. Более того, мы придумаем правило, как в следующий раз не пропустить подобную проблему и обнаружить её заранее.
Нестабильные и сломанные тесты
Последнее, что осталось сделать, — это разобраться с нестабильными и сломанными тестами. Никто не захочет возиться с сотней упавших тестов, разбираясь, какие из них сломаны на Master, а какие – просто упали, потому что проходят в 50% случаев. Если доверия к тестам нет, тестировщик не будет внимательно их изучать и тем более править.
Бывает, что при релизе больших задач допускается некоторое количество мелких багов, которые незаметны пользователю (например, JS-ошибка, которая не влияет на функционал) и которые можно исправить в следующем релизе, не задерживая выкладку важных изменений на продакшн.
И если с тестировщиком можно договориться, то с тестами всё сложнее – они честно будут находить проблему и падать. Причём, когда баг окажется в Master, тесты начнут падать на других задачах, что совсем плохо.
Для таких тестов мы придумали следующую систему. Мы завели MySQL-табличку, где можно указать название падающего теста и тикет, в котором проблему исправят. Тесты перед запуском получают этот список, и каждый тест ищет себя в нём. Если находит, помечается как Skipped с сообщением, что такой-то тикет не готов, и тест запускать нет смысла.
В качестве багтрекера мы используем JIRA. Параллельно по cron’у гоняется скрипт, который через JIRA API проверяет статусы тикетов из этой таблицы. Если тикет переходит в статус Closed, мы удаляем запись, и тест автоматически начинает снова запускаться.
В итоге сломанные тесты исключаются из результатов прогонов. С одной стороны, это хорошо – на них больше не тратится время при прогоне, и они не «засоряют» результаты этого прогона. С другой стороны, тестировщику приходится постоянно открывать SeleniumManager и смотреть, какие тесты отключены, чтобы при необходимости проверять кейзы руками. Так что мы стараемся не злоупотреблять этой фичей, у нас редко бывает больше одного–двух отключенных тестов.
Теперь вернёмся к проблеме нестабильных тестов. Поскольку речь в статье идёт о UI-тестах, нужно понимать, что это тесты высокого уровня: интеграционные и системные. Такие тесты по определению нестабильны, это нормально. Однако хочется всё же ловить эти нестабильности и отделять от тестов, явно падающих «по делу».
Мы довольно давно пришли к выводу, что стоит логировать запуски всех тестов в специальную MySQL-таблицу. Название теста, время прогона, результат, для какой задачи или на стейджинге был запущен этот тест и так далее. Во-первых, нам это нужно для статистики; во-вторых, эта таблица используется в SeleniumManager – веб-интерфейсе для запуска и мониторинга тестов. О нём однажды я напишу отдельную статью. 🙂
Помимо вышеперечисленных полей, в таблицу было добавлено новое – код ошибки. Этот код формируется на основе трейса упавшего теста. Например, в задаче А тест упал на строке 74, где он вызвал строку 85, где был вызван UI-класс на строке 15. Почему бы нам не склеить и не записать эту информацию: 748515? В следующий раз, когда тест упадёт на какой-то другой задаче Б, мы получим код для текущей ошибки и простым select’ом из таблицы узнаем, были ли ранее похожие падения. Если были, то тест очевидно нестабильный, о чём можно сделать соответствующую пометку.
Само собой, тесты иногда меняются, и строки, на которых они падают, тоже могут измениться. И какое-то время старая ошибка будет считаться новой. Но, с другой стороны, это происходит не так часто, поскольку, как вы помните, логика теста отделена от логики UI и меняется редко. Так что бóльшую часть нестабильных тестов таким образом мы действительно отлавливаем и помечаем. В SeleniumManager есть интерфейс, позволяющий перезапускать нестабильные тесты для выбранной задачи с целью убедиться, что функционал работает.
Я постарался подробно, но без излишней дотошности описать наш путь от точки А, где автотестами занималась только группа «избранных» ребят, до точки Б, где тесты стали удобными и понятными всем.
Этот путь состоял из следующих этапов:
В итоге мы пришли к системе, в которой ручным тестировщикам довольно комфортно работать с Selenium-тестами. Они понимают, как они устроены и как их запускать, умеют их править и могут при необходимости писать новые.
В то же время автоматизаторы получили возможность и время заниматься сложными задачами: создавать более точные системы для отлавливания нестабильных тестов и править их, создавать удобные интерфейсы для запуска тестов и интерпретации результатов прогонов, ускорять и улучшать сами тесты.
Совершенствуйте свои инструменты и делайте их проще в использовании и будет вам «щасте». Спасибо за внимание!