четверг, 30 ноября 2017 г.

Общее описание инфраструктуры для работы с Селениумом

Для работы с Селениумом нужны:
- браузеры;
- дополнительный вспомогательный исполняемый файл (chromedriver, geckodriver, IEDriverServer);
- чтобы писать тесты на каком-либо ЯП, нужна клиентская библиотека, которая будет соединяться со вспомогательными исполняемыми файлами и через них управлять браузерами.



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

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


среда, 29 ноября 2017 г.

Инфраструктура для JavaScipt

IDEA (WebStorm).











Изначально язык JS использовался для того, чтобы писать какие-то скрипты внутри браузера. Ща это полноценный ЯП и программы могут запускаться вне браузера, как любые другие.
Когда мы пишем тесты или сценарии автоматизации для тестов, мы это так и делаем, отдельно, т.е. на уровне ОСи, чтобы управлять браузером.
Есть несколько различных реализаций интерпретатора JS. Здесь будем юзать NodeJS.
Дополнительные библиотеки обычно для него распространяются через сайт npmjs.com - это репозиторий, хранилище пакетов, а менеджер пакетов называется npm - node package manager.
Тестовый фреймворк - Mocha.
В общем, необходимо установить дополнения. Причем отдельно, которое поддерживает интерпретатор NodeJS и отдельно JS.
Специального типа модуля, который ориентирован на разработку тестов здесь нет, поэтому придется выбрать тип модуля, который подходит максимально, но не совсем точно, а потом выкинуть из него все лишнее.
Оставить только package.json  и подкаталог node_modules library tool, которая содержит установленные дополнительные библиотеки.
В клиентскую библиотеку селениума для JS уже включены примеры.



+ нужен исполняемый файл для того браузера, которым собираемся управлять. Они там лежат и могут быть найдены ОСью, когда надо.
Он сам не знает, что это тест, поэтому надо создать конфигурацию запуска, чтобы запускалось с mocha.
Надо выставить время, т.к. mocha используется в основном для разработки модульных тестов и там есть ограничение на время работы теста в 2 сек. Если модульный тест работает > 2 sec., это подозрительно. Но для тестов, которыми управляет реальный браузер, это слишком маленький таймаут, надо его увеличить.



пятница, 24 ноября 2017 г.

Заметки по работе с Селениумом

Если обращение к:
- css-селектору, пишем через точку: .form-field
- к тегу и атрибуту внутри него с каким-либо значением: input[type = "hidden"]
- к тегу и классу:  span.button__text

Все вместе вот так:


.getAttribute() тут тестик у Никиты был написан с обращением через xpath.

Ща пробану прописать через css-селектор.
Итак, переделываем.
Никитын варик был такой:

Я переделала и получилось отакэ:




четверг, 23 ноября 2017 г.

npm, selenium, linux, openvpn selenium-standalone

Кароч, ща для меня тут были магические действия. Шоб не потерять попробую как-то восстановить.
В общем, есть такой сайтец с npm. Я так поняла, здесь можно искать любые шняги нпмные.
Серега нашел здесь в поисковике 'selenium-standalone'. Там же был ман по его установке. Как я поняла, это пакет, который позволяет визуально увидеть шо происходит в браузере, когда мы запускаем тесты. Там прямо видно как оно прокликивается.
У меня перед этим не хотела эта шняга устанавливаться, ибо это Крым, детка, санкции.
Серега установил openvpn.
Про впн потом и ключи впн потом тады, ахха, если смогу восстановить хоть что-то.
Итак, после того, как Серега установил standalone, он перешел в папку с проектом. И, я так поняла, оно там запустило мои тесты и шо-та все вывалилось в консоль. Ну, результат прохождения тестов. Получилась откая шняга (Длинное, есичо, это та код картинки, который я просматриваю на этом сайте):


А вот с впн тоже ща пробану восстановить.
В общем, Серега скинул keys.tar.gz файлик с ключами vpn.
Мы его распаковали в домашней папочке. Я открыла, там всякие шняги, я так понимаю, страны, через которые можно заходить. На всякий пожарный заскриню:


Воот.

Потом он ввел вот такую команду, чтобы приконнектиться(?) ИМХО, ошибочно, ибо мы сам openvpn не установили еще на тот момент.
Вот скрин этой команды, нижняя строчка:


Потом мы установили: ХЗ, почему оно в папочке '~/open', которая синенькая. Так вот мы установили этот openvpn.



Потом снова, я так поняла, ввел чтобы приконнектиться такую команду:


Потом перешел в папочку с ключами:



Потом пробанул подконнектиться к Молдове:




Че-та не получилось и он снова пробанул через Германию, но уже Франкфурт:




Вроде заработало. Ну, а потом он стартанул Селениум-стендэлон:



И, как я понимаю, эти слэши между Страной и городом - это экранирование символов. В первом случае экранируется запятая, во втором случае экранируется пробел.
Хз, так ли оно, но, думаю, так, ибо файлик впновский выглядит вот так:



В общем, как-то так, угу.

Заметки по работе с гермионой. Так, для себя, шоб не забыть.

Шоб оно выдавало скриншоты в таком, кодовом виде. Дописываем булеановскую (?) переменную и даем значение тру, ну, и каунтер ставим в 0. Я так поняла, чтобы потом оно нумеровало скриншоты.



Потом идем в то место, которое хотим заскриншотить, пишем там этот кусочек кода. Я хз шо оно там шо означает, но могу сделать предположение.

.screenshot() - я так понимаю, это мы обращаемся к переменной, которую создали там, в самом начале.
Потом
.then вызываем метод(?) - хз, не нашла его в WebdriverIO и пишем
.then(screen => {
  if(screenshot) {
    scrShotCount++;
    console.log('Screenshot' + scrShotCount + ': \n' + screen.value)
  }
})


Типа, перенаправляем поток (если встречаем нашу переменную скриншот, а еще делаем инкрементацию, шоб было видно, какой именно это скриншот по счету) в консоль.
console.log('Screenshot' + scrShotCount + ': \n' + screen.value) - отэта, я так понимаю, в скобочках, типа, как оно доложно отображаться на экранчике в консольке.
Шо-та вроде, типа, Скриншот1:, прыгаем на новую строку и выдаем его значение. А значение в закодированной картинке, хз, как оно там называется.
Угу, в консольке отакэ:




И берем потом эту длинную хрень, закодированную картинку, вставляем на этот сайт, шоб оно показало скрин.

среда, 15 ноября 2017 г.

DB, создание таблиц

Шоб создать таблицу, мы пишем команду
CREATE TABLE name_of_table
(
категория тип данных(количество символов),
категория тип данных(количество символов),
категория тип данных(количество символов),
категория тип данных(количество символов),
категория тип данных(количество символов),
);

вот скринчик с терминала:

понедельник, 13 ноября 2017 г.

Необходимость написать грамматику. DTD. XML

Мы почти никогда не будем с ним работать.
Смысл ДТД - прост. Это просто набор правил. Правил для кого? Для анализатора, объсняющих ему, в каком виде выглядит ваш документ.
Например, у нас есть документ:



У нас есть прайслист с элементом бук. Мне надо описать грамматику. В ДТД - это декларативная тема. Это набор инструкций, деклараций, правил, каждая начинается с восклицания "Пусть будет элемент букс!" Я объявляю элемент такой-то. В скобочках указываем их наполнение.

Пусть будет элемент прайслист, у него будет элемент букс, в котором будет тайтл, автор, прайс. Пусть будет элемент тайтл, а там #PCDATA (т.е. текст).


В ДТД много элементов, но нам ща нужны три:



ELEMENT - описывает тег, элемент.
ATTLIST - спиоск атрибутов (attribute list)
ENTITY - определяет сущность.

+, ? - модификаторы - они объясняют повторения этих элементов.

Скрин с примером ДТД:
У меня есть прайслист, в нем одна или более книг.  Если я хочу ноль или более - звездочка.
Элемент книга: в нем есть 1 тайтл по умолчанию, ноль или более авторов, одна цена и возможно есть, возможно нет, описание.
и т.д.

 А как сказать анализатору о том, что документ нужно проверять по этому описанию.
Есть 2 способа:
декларативно - в самом доке в XML ему указывается прямо в прологе  - восклицание
<!DOCTYPE - декларация, объяснение, объяснение нашей структуры.
А как для всего документа структуру описать, это же описание тега.
Что такое документ? Это корневой тег. Т.е. достаточно прописать структуру корневого тега - и мы описали весь документ.


В этом скирне первый блок - это все декларация. Т.е. декларирую прайслист. И дальше в квадратных скобочках указываю что может быть в прайслисте. Начинаю описывать ДТД самого прайслиста, доктайп, декларацию.
Т.о. мы анализатору объясняем что у нас должно быть в доке. Такой документ называется  самодостаточным - standalone.
В старых есть еще вверху такое: standalone="yes" - это кагбэ объясняет анализатору, что это самодостаточный документ, у него есть и ДТД, и сами данные.
Самодостаточными бывают редко, почти никогда, ибо много занимает 100-200 килобайт описания. Документ получается огромный, поэтому и юзают редко.
В html то же самое.
Т.о. у нас есть два способа указать документу ДТД:
1. Доктайп, имя корневого элемента, квадратные скобочки, а в них перечисление описания.
2. Мой-то стандарт никто не знает, поэтому паблик не юзаем никогда? - если парсер сам знает.
Пишем system, а затем указание на файл или урл.
Т.е. имеется books, описывается в файле books.dtd. Там может быть урл.
Вот два файлика, с описанием и сама books.dtd.




Возникает вопрос, ок, а как теперь он будет проверять?
В хтмл браузеры, когда открываем эти вещи, ничего не загружают. Это просто декларация, которую используют для того, чтобы переключить браузер в другой режим. Реально никакой файл не загружается.
Просто разработчики сделали так: если есть декларация - 1 режим, если нет декларации - другой режим работы браузера. Реально браузер ничего не загружает.

Когда открываем в эксплорере, на самом деле отрабатывает не эксплорер, а парсер msxml, входящий в состав ОС винда. У эсплорера xmlного парсера нет, он юзает стандартный виндовый парсер.
Здесь все зависит от самого парсера, от конкретного производителя.



Чаще всего так: стандартно парсеры при загрузке документа ничего не проверяют, чтобы сделать это как можно быстрее. Если речь идет о майкрософтовском парсере, у него есть специальное свойство, которое можно включить программно - валидэйтн парс. То же самое в пхп. Т.е. если оно программно включено до загрузки документа, то в этом случае он попытается проверить прямо на загрузке документа, но по умолчанию оно выключено.
У любого парсера есть специальная команда - проверяй. И вот тогда он уже пытается сделать соответствие между грамматикой и реальным документом. Браузер - это же не штука для работы c XML.
Это можно посмотреть в XML Tools. У браузера нет задачи проверки наших документов.
XML Tools - это инструмент для работы с XML. В т.ч. сюда входит свой парсер и у него есть команда 'validate now'.

DTD позволяет определить:
1. Какие теги допустимы.
2. Их повторение.
3. Их атрибуты.
4. Сущности.
ДТД - это грамматика.


















Атрибуты объявляются с помощью специального декларативного описания attlist - attribute list, т.е. список атрибутов. Он может объявить сразу несколько атрибутов.
Т.е. сначала название.
price - название элемента, для которого определяем атрибут.
currenty - атрибут.
CDATA - тип.
#REQUIRED - обязателен/необязателен.
хм... implied - необязателен, че-та не помню, шоб встречала это слово, забавно) А еще думаю, шо английский как-то знаю) Видимо, родственное implification, но там вроде совсем другой смысл.
В ДТД, когда мы объявляем содержимое элемента, мы всегда пишем PCDATA - парсируемые символьные данные. Т.е. анализатор обязан разбирать то, что находится внутри этих данных на наличие других элементов или сущностей. В других языках возможно - XJML - там допускались и другие элементы.
В атрибуте - CDATA, т.е. анализатор не должен разбирать то, что написано внутри атрибута.
Объявление ENTITY.





























Сущности XML

Мы сталкивались по HTML, что есть такой простой способ в XML описания т.н. спецсимволов. Когда я хочу написать, что а > b, в том же хтмл, мы говорили, что знак "больше" юзать нельзя, это зарезервированный символ и в HTML, и в XML. Обозначает он именно закрывание тега, а не больше.
В хтмл есть целый набор специальных знаков, который просто так на клаве не наберешь. Либо сложно, либо проще набрать по-другому.
Они записываются так:
&lt; - less then - меньше.
&gt - больше
&amp - амперсанд.
Эти три символа срабатывают в XML.
В хтмл таких сущностей много, например:
&nbsp; - неразрывный пробел, &copy - копирайт. В хтмл они определены, а в XML - нет. Это язык более абстрактный, универсальный.
Он ща рассматривается анализатором хтмла, т.е. их нет.
Мы уже объявили, что это типа хтмл, парсер это объявление увидел, он не знает, что в хтмл. Он не лазает вот сюда, вовнутрь. Необходимость объявления сущностей.



&nbsp - это не спецсимволы. В XML - это сущности. На самом деле - это константы. Впоследствии, когда я буду использовать &nbsp - это константа неразрывного пробела. Т.е. когда я начинаю его использовать, мы выдаем команду анализатору подставить вот сюда реальный байт или набор байтов.

&lt; &gt, &amp - это константы, которые заменяют запрещенные символы. А для этих:  &nbsp; &copy - констант нет. Но XML - расширяем. Мы можем запилить что угодно. Например, компания, семейная компания.  Я в тексте пишу - вот сюда подставить название компании, оно раз - и подставило. Эти сущности могут быть не просто строками, они могут быть куском документа. В XML это все расширяемо. Где это описывается? В грамматике.

Как сделать так, чтобы сейчас анализатор понял, что грамматические сущности из другого стандарта. Подстегнуть грамматику другого стандарта. Не просто сказать ему, ну, типа, здесь это. А сказать, что вот она, грамматика, на, читай. И он прочитает ее и тогда уже поймет что с ней делать.



четверг, 9 ноября 2017 г.

Установка вайбер в убунту

wget http://download.cdn.viber.com/cdn/desktop/Linux/viber.deb - шоб качнуть из Интернета.

Но можно и просто качнуть.
Надо будет потом нагуглить, откуда берется такого рода ссылка.



 sudo dpkg -i viber.deb - (debian package -install) - установить

sudo apt-get install -f - установить все зависимости с помощью force.


Потом, чтобы открыть, надо сначала узнать, где лежит, для этого:
sudo find / -name viber

/opt/viber - лежало тут.

Потом надо создать линку, чтобы оно перенеслось в usr/bin/viber и открывалось из терминала просто, если написать viber.

sudo ln -s /opt/viber/Viber /usr/bin/viber

Т.е. мы создали линку в той директории.




XML, способы программного анализа документа.

Как работает анализатор?
XML в воздухе не висит.
Чтобы работать с XML существует программные анализаторы, т.е. синтаксические разборщики XML.
Программа, которой дали файл, он его прочитал и что-то с ним сделал.
Анализатор - парсер (разборщик). Их очень много. Почти во все программные средства парсер входит: в PHP несколько парсеров, в винде (msxml), java, flash, java script.

2 подхода у XML по сбору:
SAX - Simple API of XML - простой программный интерфейс по работе с доступа к XML-файлов. Старый, быстрой, мало юзается.
DOM - document object model. Задача анализатора прочитать такой файл (документ с данными) для того, чтобы как-то его представить, например, занести документ в базу данных или чтобы мы могли его модифицировать, обработать.
Он воспринимает так: то, что мы написали - это текст. Когда анализатор его прочитает, он его прдставляет в виде дерева объектов. С этим деревом все и работает.
ДОМ - это целая спецификация, причем не одна.
Идея представления в виде дерева.
Фактически вся обработка XML делается в виде дерева. Смысл очень простой. Куда ни плюнь в XML - это объект.
Когда документ в виде текста - это набор строчек.
Как только загружается машиной, он становится набором объектов, которое представляет собой дерево, от некоего родоначального корневого, главного узла подвложенные и прочее. Что является объектом XML? Все.
Тег, элемент - дерево.
Текст - узел дерева.
Атрибут - узел дерева.
Коммент - узел дерева.
Процессинговая инструкция - узел дерева.
ВСЕ является узлом дерева.
Мы смотрим на XML, представляем дерево.
Например, файлик (аттач ниже). Есть сам документ - это объект. У него есть дочерние узлы. Это процессинговая инструкция, корневой элемент, вложенный в корень узел, в общем, все, включая сам текст.














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





Когда мы работаем с XML к нам могут приходить в парсер совершенно разные документы. Если они не нарушают синтаксиса, т.е. well-formed, парсер честно строит деревья. Но это дерево узлов, документ, может быть не для нас. И просто огульно его обработать бывает не совсем правильно. Ведь документ может быть неполным, не все указано, не та структура, данные некорректные. Чтобы мы могли это отсеять (а это называется валидация, проверка) буквально на этапе его обработки, эта задача стоит в 9 из 10 случаев.
В XML необходимо иметь способ однозначно определить кому машине, не человеку, как эта структура, в каком виде документ вообще должен существовать. Т.е. по-другому - определить грамматику.
Грамматики нет, она у меня в голове, но я хочу, чтобы она была у программы, парсера.

Конечно, можно написать прогу, которая будет по этому дереву пробегаться и смотреть, все ли там в порядке, но это долго и некультурно, ибо для одной проги будет нужна одна структура, для другой - другая  и т.д. Поэтому разработчики пошли по принципу декларативности. Они говорят так: пускай сам парсер все проверяет. Нужен декларативный стандарт, т.е. набор правил, описанный ему один раз без всякого программировавния, без ничего, как должно быть. А он уже должен проверять, насколько это подходит к этому "как должно быть".
И этот способ описания структуры и есть. Их два:
DTD - Document Type Definition - очень древний способ. Это определение типов документов.
ДТД - набор сокращений, т.е. целый язык как XML, язык описания, который позволяет указать нам, какие теги мы ждем, т.е. какие элементы в нашем документе должны быть, насколько они имеют право повторяться, какие атрибуты есть, какие из них обязательны, какие сущности могут использоваться.





воскресенье, 5 ноября 2017 г.

Написать скрипт убунту, чтобы открыть браузер с нужными вкладками и проги

В общем, т.к. на предыдущей работе была винда, пришлось немного и ее освоить. Заморочилась я тогда с написанием батников, ибо иногда бываю ленивой жопой.

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

Сначала в домашней директории создала документик с расширением .sh.
Потом там надо прописать строку:
#!/bin/bash - этой строкой мы говорим, какая программа используется для запуска файла.
Потом я нашла с помощью терминала, где лежит мой браузер chromium.
Для этого в терминале ввела
whereis chromium-browser

Он мне показал директорию, которую я скопировала в свой скриптик:
/usr/bin/chromium-browser

Ну, и напротив этой строки написала линку, которую надо открыть:

Например, мне нужно трекать свои цели на смарте:
/usr/bin/chromium-browser https://smartprogress.do/user/149198/

Потом надо добавить в конце & - это шоб процесс отцеплялся от шелла и уходил в бекграунд.
Т.к. запущенный процесс без "&", например, наш браузер не вернет управление в терминал (bash). Он застопорится и будет ждать до тех пор, пока мы не закроем браузер. Потом поспит 5 сек и запустит следующую прогу.

Т.е. очень важно, чтобы в конце стоял амперсанд.

А потом прописала, чтобы через 5 сек. он открылся, например, слак:


/usr/bin/slack

Потом браузер выдает "Done" в терминале. Ну, это так, для красоты, типа, хозяюшка, дорогая, я исполнил твой скрипт)

Если надо шоб во вкладках все пооткрывалось, можно просто через пробел запилить несколько вкладок.

В итоге у меня получился такой батник для открытия треканья целей на смарте и для слака:

#!/bin/bash

/usr/bin/chromium-browser https://smartprogress.do/goal/194883/ https://smartprogress.do/goal/220532/  https://smartprogress.do/goal/250197/ &
sleep 5


/usr/bin/slack

echo "Done"

Ахха, я пошла дальше. Мне мало было "Done".

Написала, шоб скрипт обращался ко мне. Gedit еще заботливо выкрасил обращение в розовый цвет. Клево совпало, девочка такая девочка. Вот такой няшный скрпитик теперь у меня:




В общем, потом надо было сделать, шоб он был исполняемым.
Для этого в терминале написала

chmod +x chr.sh

Ну, и открываю сам файл:

./chr.sh

Мне помог в этом деле вот этот сайт:

https://testitquickly.com/2009/10/05/trageti-browserii-flacai-haaaaai/

А вот скриптик для изучения XML. Тут я сначала указываю, какое приложение использовать, а птом пишу полный путь к файлу.

#!/bin/bash

/usr/bin/totem /home/elena/Desktop/Lena/Learning/XML_XLST/video/1.flv
/usr/bin/chromium-browser http://kruglykot.blogspot.com &




среда, 1 ноября 2017 г.

Стандарт W3C WebDriver

Селениум - это не только инструмент, но и стандарт, который описывает единый унифицированный интерфейс драйвера, который позволяет управлять браузером.

Именно такой унифицированный единый интерфейс как раз и описан в стандарте W3C WebDriver.

С технической точки зрения - это сетевой протокол. Почему взаимодействие происходит по сети?
Потому что это самый простой способ, чтобы интерфейс был языковонезависимый. Есть универсальный сетевой протокол и для конкретного ЯП достаточно всего лишь написать несложную библиотеку, которая представляет собой клиент для этого сетевого протокола.
Т.е. она предоставляет набор классов или методов. При вызове этих методов формируется и отправляется запрос по протоколу W3C WebDriver, соответствующий вспомогательный исполняемый файл (chromedriver, geckodriver, IEDriverServer), он этот запрос принимает, преобразует в какое-то внутреннее представление (Remote Debug, Marionette, COM API). Это внутреннее представление понимает браузер. Взаимодействие между вспомогательным и исполняемым файлом и браузером происходит по некоторому внутреннему протоколу, стандарт это никак не описывает.
Каждый разработчик браузера имеет право сделать свой собственный протокол взаимодействия, открывать его или он может быть закрытым (проприетарным). Главное - чтобы существовал вспомогательный исполняемый файл (chromedriver, geckodriver, IEDriverServer), который умеет принимать команды по стандартному протоколу W3C WebDriver. Тогда любая клиентская библиотека, написанная на любом языке, которая умеет отправлять команды в соотвтствии с этим стандартом, будет работать с любым стандартным драйвером и соответственно можно будет управлять любым браузером.
Стандарт описывает именно протокол.
Когда мы как юзеры пишем сценарии с использованием инструмента Селениум, мы напрямую с этим протоколом не работаем. Мы берем библиотеку, например, Java, которая содержит какие-то методы и функции и вызываем эти функции. Набор функций и классов стандарт не описывает. Для некоторых ЯП существует несколько разных реализаций, которые представляют разные интерфейсы и у юзера есть выбор, та библиотека, которая больше нравится, та, которая предоставляет более удобный программный интерфейс, ту и можно использовать.
Главное, чтобы эта библиотека внутри поддерживала стандартный протокол W3C WebDriver.


Стандарт описывает:

https://www.w3.org/TR/webdriver/

Набор команд:

https://www.w3.org/TR/webdriver/#list-of-endpoints - каждая из этих команд в протоколе имеет свой уникальный адрес. Здесь перечислены адреса и для каждого адреса указана, какакя команда ему соответствует. В правой колонке - названия команд.

Алгоритмы:

Здесь выделены 3 самых важных и сложных.

https://www.w3.org/TR/webdriver/#element-displayedness - определение, является ли элемент видимым. Взаимодействовать с невидимыми элементами нельзя, т.к. реальный юзер тоже не может этого делать.

https://www.w3.org/TR/webdriver/#element-interactability - если элемент прозрачный.

https://www.w3.org/TR/webdriver/#get-element-text - определение текста документа.


Сетевой протокол.

БОльшая часть посвящена ему. Это важно для разрабов библиотек.

Механизм расширения протокола. 

Например, для тестирования мобильных или декстопных приложений.