Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Про Selenuim и один «велосипед»

Anna | 4.06.2014 | нет комментариев
Всем здравствуй!

Я бы хотел рассказать о задачах, с которыми я сталкивался в процессе освоения Selenuim WebDriver, c их решением и тем, как эти решения, в тезисе, дозволено применять. Все это представлено в виде прототипа фрэймворка, ссылка на тот, что будет в конце статьи.

В этом посте я хочу поделиться своими идеями реализации образца Page Object, о том как дозволено обрабатывать ошибки, возникающие в процессе выполнения тестов, рассказать немножко о логгинге. А так же поделиться сведениями о некоторых инструментах, которые реализованы с применением Selenuim WebDriver, и своими наработками.

План моей статьи дальнейший:

1. Капитан очевидность, взамен введения.
2. Немножко о себе, нужно представиться…
3. Отчего Selenium?
4. О Page Object…
5. Не баг, а фича!
6. И вновь про логгинг и отчетность.
7. А разве нет аналогов?
8. Обещанные ссылки.
9. В завершение.

Выходит, поехали!

1. Капитан очевидность, взамен введения.

image

Не думаю, что есть толк пояснять, что такое тестирование программного обеспечения, какие стратегии и модели существуют, какова его роль в процессе разработки софта и обеспечении качества, и какому риску подвергаются планы и пользователи, если данный процесс отсутствует. К тому же, теперь программирование является не искусством, а ремеслом для многих миллионов экспертов. Планы реализуются в сжатые сроки и с ограниченными бюджетами, и Зачастую могут из себя представлять монстров с легко необхватной функциональностью. Причем продукты могут насыщенно меняться от версии к версии, скажем так улучшаться. И всякое такое «совершенствование» может оказаться неизбежным.

В таких условиях автоматизированное тестирование играет одну из ключевых ролей. Какие модели, стратегии и способы существуют отменнее поискать в других источниках. Моя же статья не об этом. Она посвящена инструментам автоматизации тестирования клиентской части вэб-приложений.

2. Немножко о себе, нужно представиться…

Я занимаюсь регрессионным автоматизированным тестированием теснее четыре года. Мы тестируем десктопный заказчик продукта и классы, которые описывают его бизнес-логику. Об инструменте, тот, что применяется на нашем плане дозволено почитать здесь. За это время было автоматизировано уйма UI-тестов, unit – тестов, много чего было… Именно здесь я отслеживал процесс эволюции автоматизации тестирования, и сам в нем принимал участие.

image

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

Дальше возникла надобность применять программные интерфейсы взаимодействия с продуктом и базами данных, потому как того, что показывали формы диалогов, было недостаточно…

Однако, что-то я увлекся. Но именно здесь я и осознал, насколько значимо продумывать с самого началатактику и стратегию взаимодействия с продуктом разработчиков для его высокоэффективной автоматизированной проверки.

Тенденцию перехода приложений от своих десктопных заказчиков к вэб-заказчикам не может подметить либо слепоглухонемой, либо человек, родившийся и живущий где-нибудь в Антарктиде. Да и разработка для вэба теперь мейнстрим, это ни для кого не секрет.

Я решил не оставаться в стороне и испробовать в свободное время освоить что-нибудь, что применяют для автоматизации функционального тестирования frontend – части и для проверки ее совместимости с разными клиентскими платформами. Да и к тому же, есть некоторая вероятность, что вэб-заказчику на нашем плане быть…

Я предпочел Selenium Webdriver.

3. Отчего Selenium?

image

Отчего же Selenuim?

Когда-то давным-давно это был небольшой инструмент, тот, что применяли лишь отчаянные энтузиасты из мира вэб-разработки. Теперь же это суровое оружие, которое взяли на вооружение для борьбы с недостатками не только многие тысячи автоматизаторов по каждому миру, но даже frontend – разработчики.
image

О линейке продуктов плана Selenium дозволено прочитать здесь либо вот тут.

Но должен сказать, что это не средство непринужденно автоматизированного тестирования. Скажем, Selenium Webdriver предоставляет уйма программных средств и интерфейсов для эмуляции пользовательского взаимодействия с браузером и загруженным в его окне контентом. Эти средства покрывают примерно 100% допустимых вариантов такого взаимодействия. Все это может обнаружить больше широкое использование. Но, скажем, он не может, по умолчанию, формировать отчет о прохождении того либо другого теста.

Дальше, есть некоторые другие задачи. Ниже часть из них:

Интерфейсы WebDriver и WebElement предоставляют дюже ограниченную функциональность. В основном она направлена на поиск элементов энергичной страницы и выполнение самых примитивных действий над элементами (ввод значений, клик и т.п.). Многие другие пригодные функции предоставляются такими интерфейсами, как HasInputDevices, Locatable, Options, Alert и т.д. И применение только WebDriverи WebElement крепко ограничит вероятности автоматизированных тестов.

Под всякий браузер существует свой драйвер. Теперь это:
ChromeDriver; 
FirefoxDrive;
HtmlUnitDriver (для Unit – тестов на ярусе html-документа);
InternetExplorerDrive;
OperaDriver;
RemoteWebDriver (мой любимый, отличен для запусков тестов на удаленных машинах);
SafariDriver;
IphoneDriver;
AndroidDriver;
PhantomJSDriver (какой-то экзотичный браузер, у меня терпенья не хватило, Дабы его собрать на своей машине).

Я думаю, что команда Yandex’a тоже скоро выпустит свой драйвер.

Богатенький выбор, на всякий вкус и под всякие нужды. Но если в тестовом плане очевидно применяется какой-то либо какие-то из перечисленных, это сделает задачи, когда необходимо стремительно переходить с браузера на браузер либо применять сразу несколько.

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

Написание классов, которые бы были ответственны за интерактивную работу со страницами.PageFactory – восхитительный инструмент. Впрочем, его применение становится неудобным из-за потери наглядности кода классов, описывающих дюже крупные страницы, а повторяющиеся элементы чреваты копипастой. Выход – выделять повторяющиеся элементы в отдельные блоки (классы) и применять теснее блоки. Но это не решает задачу до конца. Что если ваш сервис может трудиться, открывая страницы на отдельных вкладках либо окнах браузера, на всех этих окнах есть повторяющиеся блоки? А часть из них лежит еще и на фрэймах! Я экспериментировал на этом и этом, и сразу жнице обслуживания вызывает диалог настройки всеобщего доступа;
4 из открытого документа вызывается тот же самый диалог.

Для наглядности, каждая последовательность действий показана в виде скриншотов. Энергичные элементы выделены:
image
image
image
image
image

Необходимо: как-нибудь обработать оба экземпляра этого диалога в различных окнах. И вот что получилось у меня. Это описанное предусловие.

Сейчас я сделаю клик по полю, в которое просят ввести имена, адреса электронной почты и т.д., в появившемся всплывающем элементе нажму «Отмена», позже чего будет произведен клик по кнопке «Готово». Действия будут исполнены в обоих окнах. Для наглядности, ниже последовательность в виде картинок.

image
image
image

Вот так играючи мы совладали с задачей. Это код способа getCustomizingAccessDialog() для документа и основной страницы.

Т.е. есть некоторый всплывающий блок элементов, расположенных внутри фрэйма, которым мы воспользовались как объектом, тот, что существует как бы самосильно и подхватывается когда надо… Мы знаем, что он есть на странице всякого документа и на основной странице обслуживания, от них и получаем.

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

Видимо, что необходимо группировать элементы страниц в блоки для повторного применения. Эти блоки дозволено даже передать наружу под видом независимых объектов и с ними непринужденно трудиться. Если этого не делать, то у класса разрастется число признаков и способов. Необходима декомпозиция.Напротив, вы получите вот такие объекты:
image

Если посмотреть на описанный выше пример, то к способам работы с основным контентом, добавляются способы работы с всяким типом всплывающего диалога – настройки доступа, модальные формы переименования, выбора опций, комментарии в документах.

Указанное выше решение дозволено реализовать безболезненно, когда тестируется то, что загружено в исключительном окне (исключительной вкладке) браузера.

Но в случае описанного довольно трудного поведения придется каким-то образом переключать webdriver cо страницы на страницу, не забывая переключаться в необходимый фрэйм.

И здесь появилась идея! А что если обучить всякий такой объект помнить путь к самому себе и механически переключать webdriver при вызове способа интерактивного взаимодействия со страницей.

Такое, мне показалось, допустимо, если несколько отойти от представления «страница». Т.е. под ней я буду подразумевать не загруженный контент, а окно браузера с загруженным в нем контентом. У этого окна есть строковый неповторимый идентификатор, по которому дозволено легко опознать его среди прочих. Ок! Т.е перед вызовом способа будет протекать переключение в необходимое окно.

Так. А что делать с фрэймами? Дозволено сделать еще и так, Дабы всякий блок элементов знал, добавочно, в какой фрэйм следует переключиться.

Таким образом я выстраиваю путь.

Как видно из приведенного списка конструкторов класса, тот, что я назвал Page (наименование дюже условное, допустимо, класс следует переименовать), дозволено составить изложение загруженной страницы целиком, а дозволено по частям, в дополнение к этому указывая иной сходственный ему объект в качестве родителя (parent) когда это нужно. Таким образом дозволено выстроить связанный граф блоков элементов. Может первое. Способы работы с приведенным списком тогда бы выглядели так ( допустимые вариации):

try
{
//some actions
}
catch (StaleElementReferenceException e)
{
//same actions again
}

Да, это работает. Но легко ли поддерживать класс, у которого всякий способ описан таким образом? А если это отслеживается в всякий тестируемой фиче?

Решение созрело еще до того, как я испробовал «протестировать» Google Drive.

Я придумал интерфейс ITestObjectExceptionHandler. А это реализующий его отвлеченный класс. Конструкторы и признак throwableList добавлены для облегчения процесса допустимой обработки исключений. Предназначение объекта класса, тот, что будет его наследовать – попытаться обработать исключительную обстановку и воротить-таки какое-нибудь значение, либо выкинуть новое исключение.

Дальше.

Возвратимся к ранее описанным классам Page и Entity. У них есть класс – прародитель с этими признаками. Прародитель перехватчиков для Page и Entity имеет такую реализацию. И еще раз напомню, что так работает перехватчик для класса Page и его преемников, необходимое выделено /**/. Дюже схожа реализация для класса Entity.

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

Для Google Drive я сотворил такой класс, тот, что описывает, что следует делать, когда появляется StaleElementReferenceException. А конструктор абстрактного класса, что описывает работу со списком Google Drive, я решил сделать таким.

Итог: StaleElementReferenceException вообще перестало себя проявлять при работе с таблицей. Со списком документов на основной странице обслуживания тоже (Ура!). По каждой видимости, для Google этого было довольно.

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

Скажем. Есть обстановка:
1. Мы по очереди создаем документы на Google Drive
2. Закрываем всплывающие модальные формы
3. Переименовываем
4. На некоторых ставим «звездочку»
5. Закрываем

Дабы каждому было ясно, каждая последовательность продемонстрирована в виде скриншотов, на которых выделены энергичные элементы:
Создание
image
image

Работа с модальной формой
image

Переименование
image
image

Метка в виде звездочки. Табличный документ
image

Дело в том, что при выполнении описанных действий без каких-либо ожиданий, когда документ будет синхронизирован с сервером, появляется алерт. Если его не обработать, тест упадет. Повод: UnhandledAlertException. Я-то с вами знаю, что это неверный тест. Но я хочу выдать обстановку за некритичный, но отвратный с точки зрения автоматизации баг приложения. Его поправят позднее, но тест, идущий до конца, теснее должен быть теперь.

По плану, позже этих действий:

1. Проверка переименования всякого сделанного документа (всякий различного типа) на основной страницы обслуживания;
2. Проверка вероятности удалить все эти документы.

Если эти действия не будут исполнены, то есть риск пропустить дюже важные баги, и пользователи будут в ужасе.

Я решил задачу так:
1. Сам обработчик.
2. Его применение (в тесте).

Итог: тест проходит до конца. Его ранг: FAILED TESTS BUT WITHIN SUCCESS PERCENTAGE. И вот как он сигнализирует об имеющейся задаче:
image

Внимание (!!!). Такие обработчики следует реализовывать максимально легко. Желанно, Дабы всякий класс таких обработчиков имел неповторимый комплект исключений, на тот, что следует реагировать.

6. И вновь про логгинг и отчетность.

imageimageimage

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

От того что для экспериментов я применял java, моя голова крепко болела при выборе надобного фрэймворка для логгинга. А выбирать было из чего! Автор этой статьи дюже отлично описал обстановку с логированием в java. Да и на первых порах я сам еще не знал того, что хотел получить. К тому же необходимо, Дабы по этому логу дозволено было возвести отчет.

В выводе:
— мне необходим примитивный логгер, тот, что бы мог регистрировать сообщения, их ярус, выводить данные на консоль – как минимум;
— дюже отлично, Дабы к нему дозволено было «цеплять» объекты исключений, если они появляются;
— и вовсе отлично – вероятность прикрепить к записи лога ссылку на какой-нибудь файл, тот, что получился в процессе прохождения теста;
— Писать видео со спецэффектами. 

Думаю, с первыми двумя пунктами все ясно. 3-й. Файлом может быть все что желательно, xml-файл, набранный текст либо даже скриншот, снятый с браузерного окна. Это может быть комфортным при, скажем, обработке записей лога.

Что касается отчетов:
— мне необходим отчет, тот, что бы формировался как при прогоне одного теста, так и позже запуска каждой съюты;
— В этом отчете я бы хотел видеть изложение исполненных шагов по выбранному тесту;
— Желанно, Дабы такая детализация могла отображать скриншоты либо какую-либо иную визуальную информацию.

Не позабуду упомянуть, что в качестве фрэймворка для проведения самих тестов я предпочел TestNG. Отчего? Вначале, потому что в нем есть вероятность образования отчетов о прохождении тестов. Но при больше детальном постижении я осознал, что у него много других превосходств, таких как интегрируемость сmaven и ant, вероятность быть использованным такими continuous integration системами, как jenkins и hudson, многопоточная работа… Дюже отлично данный восхитительный фрэймворк описан в этой статьеКому увлекательно, дозволено посмотреть документацию.

Но, что-то я отвлекаюсь…

В качестве логгера я решил применять java.util.logging.Logger. Отчего?

— он есть в всякий java’е начиная с 1.4, лишние зависимости на плане ни к чему;
— его легко интегрировать с логами браузера (Mozilla Firefox, для других баузеров извлечение логов пока не реализовано);
— в случае применения других библиотек логирования (log4jslf4j либо logback, скажем), неизменно есть вероятность направлять сообщения в их логгеры.

Но:

— хотелось бы избавиться от очевидной инициализации логгера;
— есть усложненные варианты применения – построение иерархии сообщений. Огромное число ярусов, которые, в тезисе, обязаны соответствовать отладочной информации – FINE, FINER, FINEST… Необходимо все лишнее как-то отсечь.
— выбранный логгер, а так же перечисленные выше, не умеют прикреплять файлы к своим сообщениям. Речь идет не о FileHandler’ах либо о чем-то схожем.

Сейчас решение.

В своем плане я сотворил класс, тот, что назвал коротко и ясно – Log. Его основные способы:
— debug(String) – генерирует сообщения с ярусом FINE, предлагаю применять в целях отладки
— error(String) – генерирует сообщения с ярусом SEVERE, сигналы о серьезных ошибках;
— message(String) – генерирует сообщения с ярусом INFO, сигналы о типичном состоянии;
— warning(String) – генерирует сообщения с ярусом Warning, сигналы о допустимых загвоздках;
— log(Level, String) — для тех, кто все-таки хочет сгенерировать сообщение с любым из этих ярусов.

Те же способы с дополнительным параметром в виде объекта пойманного исключения:

— debug(String, Throwable);
— error(String, Throwable);
— log(Level, String, Throwable);
— message(String, Throwable);
— warning(String, Throwable).

Дальше (внимание!), способы с вероятностью связи файла и записи лога:

— debug(String, File);
— error(String, File);
— log(Level, String, File);
— message(String, File);
— warning(String, File).

На самом деле, все это простая обвертка вокруг java.utils.logging.Log и java.utils.logging.LogRecord. Все это статические public способы, которые могут быть доступны в любом месте плана.

Пример применения. Дозволено применять взамен комментариев. Впрочем, этим врятли кого-то поразишь.

Выходит, каким образом я «цепляю» файл к логу? Дело в том, что данный логгер создает не объекты LogRecord, а его преемника, тот, что я назвал LogRecWithAttach. Все легко! Кто обнаружит 10 различий от «прародителя», тому 5 баллов и прибавку к карме.

Ок! Но у кого-то теснее, допустимо, возник вопрос: «Автор, а для чего тебе такое излишество?» Испробую ответить…

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

Функции снятия скриншотов у меня исполняет класс, названный Photographer. Список его способов дозволено посмотреть тут:
image

Его функции следующие:
1. Снятие скриншота с энергичной страницы, сохранение его в файл;
2. Создание записи лога с необходимым ярусом значимости, добавление к ней ссылки на сохраненный скриншот;
3. Вероятно, вы подметили, что в качестве параметров у некоторых способов указан WebElement. Эти способы выделяют элемент на странице, делают ее фото и возвращают элемент в начальное состояние. Примеры таких скриншотов были показаны ранее. Причем, цвет подсветки зависит от «правильности» состояния выделенного фрагмента страницы. Так, на скриншоте сфотографировано некорректное (ну, типа) состояние:
image

Список документов с некорректным содержимым (по условию «теста» текстовый документ и база данных MS Access не обязаны загружаться) выделен ясно оранжевым. Такая фотография сделана одним из вызовов способа Photographer.takeAPictureOfAWarning(WebDriver, WebElement, String).

Правда, есть одно НО (!!!) – элементы выдаются при помощи javaScript’а. Была идея делать проекции на скриншотах по координатам элементов. Это даже получилось. Впрочем,для элементов, которые сидят внутри фрэймов либо находятся на страницах со скроллами, такие проекции (обведенные области) получались со смещением. От идеи пришлось отказаться. Но с иной стороны – сейчас есть вероятность записывать видео со спецэффектами!..

В всеобщем – мой фотограф как бы дополняет лог.

Вторая, недурная, вероятность – прикреплять всякий файл, в тезисе. Скажем, разве нехорошо в отчете, тот, что отображает детализацию, построенную на основе собранных сообщений, обнаружить ссылку на файл? Скажем тот, что загружали в Google Drive из примера выше. И по этой ссылке его открыть на просмотр.

Так, я плавно перехожу к построению оперативных отчетов о прохождении одного либо нескольких тестов.

Начну с того, что для тех случаев, когда необходима конвертация лога с учетом описанных выше особенностей, я придумал интерфейс, тот, что я назвал IlogConverter.

А вот пример применения. Скажем, мы добавочно используем библиотеку log4j. Нам необходимо, Дабы в этом логгере были данные о файлах. Дозволено сделать класс, объект которого бы проверял, есть ли у приходящего сообщения «аттач». И если он есть – генерируется дополнительное сообщение log4j. А Дабы данный объект мог «слушать» лог, я предлагаю такой способ – Log. addConverter(ILogConverter). Данный механизм работает вследствие этому коду.

И вот что происходит, когда возникает новое сообщение:
converting.convert(rec);

Я сделал для своего фрэймворка что-то как бы «стандартной» реализации названного интерфейса, которая отвечает за образование детализации отчета TestNG. Ее я назвал ConverterToTestNGReport. Что она делает? Она перехватывает сообщения от лога, по определенному html — образцу (тот, что я пока захардкодил в виде final-признака) формирует строку отчета:
Reporter.setEscapeHtml(false);
Reporter.log(htmlInjection);

Добавочно – если у сообщения есть прикрепленный скриншот – то мы его превращаем в “<img src=”, если какой-либо иной файл — “<a href= “. Правда, есть только ссылки на файлы. Пока сами файлы по этим ссылкам отчего-то не открываются. Но мне теперь (!!!) этого довольно.

Итог — приведенные ниже фрагменты отчетов. Хочу обратить внимание на то, что это не кастомизированные отчеты.
image
image
image
image
image
image

Безусловно, может и грубо, но на первое время сойдет. Я думаю, стоит разобраться, дозволено ли кастомизировать детализацию отчета TestNG. Если да, то дозволено сделать такой кастом и пользоваться им взамен захардкоденного образца.

И как бы пока все отлично. Но этого не довольно. Поясню…

Ок! У нас есть примитивный в применении логгер. У нас есть даже инструмент, тот, что разрешает строить отчет. Но необходимо еще позаботиться о том, Дабы ранг прошедшего теста был синхронизирован с максимальным ярусом сообщений лога.

Объясняю. Если ничего не предпринять, то тест будет иметь ранг SUCCESS если он прошел до конца и не упал. Если же в процессе его выполнения появилось непойманное исключение, то тест будет иметь рангFAILURE. Если тест зависимый, и определяющий тест не проходил — SKIP. А сейчас зададим себе вопрос: “А дозволено ли считать тест в полной мере прошедшим, если в ходе его выполнения случилось кое-что, из-за чего в лог попали записи с ярусом WARNING либо даже SEVERE?”. Т.е, миновавший тест имеет ранг SUCCESS, впрочем, глядя на его детализацию, мы видим желтые и красные строчки. Я считаю это, как минимум, дезинформацией.

Мое решение ниже.
Я реализовал класс, тот, что объединяет поток (а TestNG поддерживает многопоточность) с самим тестом. Дальше, реализовано хранение сообщений лога с привязкой к определенному тесту (экземпляру класса, реализующего ITestResult). На этом моменте я останавливаться не буду. Продемонстрирую, как происходит привязка сообщения лога к тестам. Ее изготавливает объект упомянутого ConverterToTestNGReport. И наконец, я реализовал интерфейс ITestListener в виде класса, тот, что:
— перед началом выполнения тестов (тестовых способов) добавляет в лог экземпляр ConverterToTestNGReport в качестве слушателя.
— позже выполнения всякого тестового способа синхронизирует ранг его прохождения с тем, что зафиксировал лог:
1. если тест прошел до конца, но в логе есть сообщения с ярусом SEVERE – ранг его прохождения меняется на FAILURE.
2. если тест прошел до конца и не было зафиксировано сообщений с ярусом SEVERE либо WARNING – его ранг остается непоколебимым – SUCCESS.
3. Если же были зафиксированы сообщения с ярусом WARNING, то я предлагаю сменить его ранг наSUCCESS_PERCENTAGE_FAILUREЛибо дозволить «пользователю» предпочесть подходящий ранг самому.

А сейчас финал! 
Для построения описанных выше отчетов необходимо исполнить вот такое действие:
@Listeners({ReportBuildingTestListener.class})
public class NewTest {

В завершение к этой главе, я хотел бы сказать, что логирование теснее в существенной степени автоматизировано. Т.е. графически регистрируется всякое интерактивное действие – вводы значений (до ввода и позже ввода), клики и submit’ы (до выполнения действия), возникновения новых вкладок/браузерных окон, итоги переходов по ссылкам. Для каждого остального формируются некие «типовые» текстовые сообщения.

Часть этих функций берут на себя классы, которые являются прослойкой между инструментами, входящими в состав Selenium, и классами больше высокого яруса.

Это ExtendedEventFiringWebDriver – преемник EventFiringWebDriver, тот, что реально исполняет всю черную работу. Его «просушкой» занимается реализация интерфейса IExtendedWebDriverEventListener(расширенный WebDriverEventListener), входящая в состав WebDriverEncapsulation в качестве nested – класса. Часть функций логирования на себя берут WindowSwitcher и SingleWindow – администратор браузерных окон/вкладок и представление самого окна/вкладки.

Само логирование дозволено настроить для плана в целом. Впрочем о конфигурировании и названных классах я бы хотел рассказать в иной статье, которой допустимо быть…

7. А разве нет аналогов?

imageimageimageimage

Выходит! Одной из поставленных задач было попытаться обнаружить аналоги и испробовать с ними поработать. Это расширяет кругозор. Помимо того, многие пригодные функции бывают теснее реализованы. И тогда для чего писать велосипед, тот, что делает все тоже самое? Отменнее теснее все равно не получится! Значительно пригоднее посмотреть, как реализованы надобные функции, и обучиться их применять.

А собственно, в чем параллель?

Функциональность, которую я вовсе отказался реализовывать – работа с объектами, классы которых в том либо другом виде реализуют WebElement. Т.е. я решил вовсе ничего не предпринимать в этом направлении, т.к. наткнулся на видео – отчет об этом восхитительном фрэймворке. И скорее появился интерес испробовать его на практике. Это мне в полной мере удалось во время экспериментов с Google Drive. Причем наладить взаимодействие с yandex-qatools htmlelements удалось без каких-либо усилий. Скажем, вот так выглядят конструкторы абстрактного класса, от котороtor.html”>JavascriptExecutor и т.д. теснее исполнена. Примеры.

Если есть толк, о перечисленном выше я расскажу в иной статье.

— описанный в 4 и 5 метод организации объектов, реализующих интерактивное взаимодействие.
— описанный в 6 логгинг и метод построения отчетности на примере отчета TestNG.

Как видно из перечисленного, стержневой упор я попытался сделать на работу с WebDriver’ом и связанными с ним компонентами.

Чего нет у меня и есть в thucydides (ощущение при еще отдаленном знакостве) в этом плане:
— вероятность трэккинга и построения карты открываемых страниц. Классы Pages и PageUrls. У меня же допустим только прямой переход по ссылке, возврат вперед и назад;
— инструменты для работы с элементами, добавочный комплект ожиданийPageObject.

А сейчас идея в всеобщем:
1. Хочу применять свой механизм для открытия браузера.
2. Объект преемника описанного ранее класса Entity – wrapper для объекта Pages. Таким образом я попытаюсь объединить функциональности обоих классов.
3. Дозволено как-нибудь объединить функциональности преемников классов Page (глава 4) и PageObject (thucydides).
4. Возвратимся к отчету с номером 3. Как видите, шаги могут быть дюже крупными (самый 1-й прошел за минуту, есть идущие по 30 и больше секунд). Наверно это не атомарные шаги. Представленные в этом отчете скриншоты – состояния в конце выполнения шага. Что если шаг завершился неудачно? Я бы, скажем, хотел видеть иллюстрации того, что привело продукт в некорректное состояние.
Так вот, думаю, если провернуть фокус, описанный в главе 6, при условии что существует вероятность для создания детализации шага в отчете, которую дозволено вызвать извне в процессе его выполнения – это было бы здорово!
5. Все остальное делает thucydides.

Приблизительно так!

На данный момент, я считаю, безукоризненным вариантом является не разработка какой-то монстрообразной системы, функциональность которой немыслимо расширить за счет применения сторонних инструментов. Мне бы хотелось получить на выходе легкой в применении инструмент, тот, что:
— мог бы быть системообразующим компонентом;
— либо мог трудиться коллективно с другими инструментами за счет замены имеющихся функций на больше подходящие либо дополнения своими функциями то, чего нет в других инструментах для автоматизации тестирования, которые применяют Selenium Webdriver в качестве основы.
image
О некоторых мыслях по этому поводу я бы хотел рассказать в завершении.

8. Обещанные ссылки.

Итог моего эксперимента.
Пример плана для тестирования Google Drive. Реализовано с применением Yandex QA Tools Html Elements.Допустимо, что-то дозволено сделать и отменнее. Но я сам учился. В этом плане применяются FireFox, Chrome, Safari и RemoteWebDriver, дерзкий Chrome.
На каждый случай положил *.jar файл. Если кому-то увлекательно посмотреть на данный план в работе, то:
1. Применять jdk7.
2. Необходимо сделать maven project.
3. Добавить библиотеку. Не позабудьте про selenium (версия 2.35) и TestNG!
4. В файл pom.xml добавить зависимости.

Но предварительно предупреждаю, что могут быть задачи. Документация отсутствует. Допустимо, что каким-то ориентиром послужит это. Умоляю помилования за корявости, если есть. Все делалось на коленке. На момент публикации кое-что стало неактуальным. Постараюсь поправить. Легко на типичную документацию нет времени. Да и необходима ли она для плана, к которому сам относишься, как к эксперименту, пускай даже и увлекательному?

9. В завершение.

image
Выходит, моя статья теснее примерно закончилась. Теперь я ее конечный раз перечитываю…

Глядя назад, я вижу, что получился немаленький такой обзор, на тот, что я даже не рассчитывал. Я был бы дюже рад, если эта статья кому– то в чем–то помогла, либо кто-то сделал для себя малое открытие.

Что касается меня, то в любом случае я своей цели добился. Я испробовал самосильно копнуть в сторону ранее малоизвестных мне спецтехнологий автоматизированного тестирования, поделиться какими-то своими идеями и наработками. Данная статья охватывает не все задачи, с которыми пришлось столкнуться, и соответственно не все решения рассмотрены. Если данный пост кому-то показался увлекательным, я могу написать продолжение, но позднее.

Итогом стал больше либо менее рабочий прототип инструмента. Пока что это легко эксперимент, о потенциальной полезности которого я сам не имею представления. Хотелось бы его продолжить и развить до чего-нибудь серьезного. В этом случае:
— я бы испробовал усовершенствовать теснее имеющуюся кроссбраузерность. Теперь есть вероятность работы с:
FireFox (применял 21.0);
Chrome (26-30); 
Internet Explorer (использован 9.0.8112); 
Safari (5.1.7 для Windows); 
Opera (12.16) 
HTMLUnitDriver – добавил на каждый случай;
RemoteWebDriver c запуском всякого из перечисленных браузеров.
— я бы испробовал добавить поддержку мобильных браузеров iPhone и Android, а так же PhantomJS.
— постарался бы усовершенствовать отчетность для TestNG. Пробовал бы различные варианты их кастомизации.
— дозволено было бы двинуться в сторону интеграции с Junit.
— изучать и усовершенствовать интеграционные вероятности.

Это здорово, если кому-то идея понравилась. Рад буду узнать скептические суждения (но конструктивные), предложения, советы и пожелания.

До встречи!

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB