среда, 15 июня 2016 г.

Тесты на python

Возникла необходимость собрать из глины и палок тесты на python.

До этого никогда с ним дела не имела. Поделюсь логами процесса.

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


1. Запускаем тесты


Нам понадобятся: питон с пакетами pytest и allure.

Установка:
  •  Питон и pytest поставила вместе с anaconda. Посоветовали, но пока не освоила.
  •  Можно ставить и отдельно.
  •  Аллюр ставится через командную строку: python -m pip install pytest pytest-allure-adaptor

Собственно запуск:

Сделала демо-файл с разными тестами.

Открываем консоль, переходим по пути куда положили файлик, запускаем:
python -m pytest sample.py -s --alluredir rep

Видим результат погона в консоли + xml отчета с появившемся подкателоге rep.


2. Генерируем из xml красивый аллюровский отчет


Нам понадобится: allure command line.

Качаем, распаковываем, запускаем: allure.bat generate -o rep\ rep\

Получаем отчет в том же подкаталоге rep.

Открываем index.html в браузере и смотрим, как разложились наши тесты и все что понаписано в аннотациях.


3. Подводные камни


1)  Пока гуглила как все это собрать, нашла на стековерфлоу инструкцию с устаревшей ссылкой. Пишут что allure cli устарел, попытка его использовать приводит к ошибке.

2) Allure command line требует джавы, тут у меня есть любимые грабли. Нужно чтобы была установлена
 переменная окружения JAVA_HOME: C:\Program Files\Java\jdk1.... (путь зависит от версии). И в кавычки путь заключать не нужно. И заработает это только после ребута.

3) Отчет открытый как локальный файл работает не во всех браузерах. Забыла нормальное объяснение, что это и как лечить. В качестве прикрепленного артефакта тимсити открывается прекрасно. А локальная версия работает в фаерфоксе.


Ссылки:

понедельник, 28 июля 2014 г.

Java библиотека для работы с джирой

Делюсь находкой.

Понадобилось настроить синхронизацию двух джир: в одной проект ведется, в другой регулярно обновляется его "зеркало".

Судя по гуглу, наш запрос не уникальный, но готовых решений нет. Да и не надо, ведь и у джиры открыт API.

Так мы познакомились с jira-client.

Библиотека умеет работать с тикетами, в т.ч. с custom fields. По ссылке подробнейший пример и код для мавена.

вторник, 27 мая 2014 г.

Allure. Отчет о подключении и лучи любви

Прошло ровно 2 недели со встречи в баре KLЮTCH, где Артем Ерошенко рассказывал о тестировании вообще и фреймворке allure в частности. Кстати, вот видео. И вот наконец рапортую: полноценно прикрутила allure к своему велосипеду.

Всем рекомендую: фреймфорк предоставляет удобные отчеты, и прост в использовании.

Если у вас еще нет тестов, allure вам подходит. Можно скачать один из проектов с гитхаба, наполнить своими локаторами-шагами - и в бой.

Если есть, то с высокой вероятностью тоже подходит. К моим Java + TestNG + Maven - оказалось возможно "пришить" allure, дополнив pom файл. Результат в TeamCity выглядит так:

рис 1. отчет allure в teamcity

Важные фичи

Сравниваю со стандартным репортом TestNG, а также ReportNG
  • удобно структурирована информация 
    • фильтрация тестов по результату
    • сортировка
    • вложенность окон тесты - > тест -> шаг -> приложение
  • различие результатов fail (завалился assertion) и broken (exception не доходя до конца теста)
  • возможность делать атачменты: текст и картинки

Пара примеров мега-полезности лога allure

Вот тест с результатом fail: полученный результат не совпадает с ожидаемым. Так как сравниваются большие объемы данных, удобно и ожидаемый и фактический результат приатачить - чтобы можно было пробежаться по ним глазами.
рис 2. пример атача с текстом

Вот тест с результатом broken: он свалился не доходя до финальной проверки, а пошаговый лог показывает, на каком именно шаге. Вебдрайвер не нашел искомый элемент. Я переопределила класс Exception, чтобы при каждом краше делался скриншот. Можно оценить визуально: на той ли мы странице, и прогрузился ли элемент вообще?
рис 3. пример атача с изображением

Послание себе в прошлое

...для моей конфиурации Java + TestNG + Maven можно:

  • скачать готовый проект с гитхаба
  • научиться запускать
  • далее по вкусу
    • накрутить прямо в него свои тесты-пейджобджекты
    • по образу и подобию, дополнить собственный pom.xml
  • для красоты - расставить аннотации аллюра, сделать атачи 
У Артема Кошелева есть гайд для тех же и Junit, а на гитхабе еще несколько готовых конфигураций.

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

Еще полезные ссылки

Итого 

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


четверг, 8 мая 2014 г.

С новым Firifox WebDriver стал быстрее? 0_o

Тесты раньше выполнялись 14-16 минут, теперь 12.

Кроме версии Firefox вроде бы ничего не менялось. Ни тесты, ни машина.

Кто-нибудь еще заметил аналогичный эффект?

понедельник, 5 мая 2014 г.

Перевод проекта на maven. Магия и жизнь

Воскресным вечером перенесла проект на maven. Встретила три проблемы. Одну решила, одну - решила, но блин не понимаю как. Одну продолжаю наблюдать с безразличием.

Зачем вообще maven? Зависимости всего три. Testng, hamcrest и webdriver. Держать ссылки на jar файлы в Build Path было вполне приемлемо. Однако:

Steps to reproduce (в Eclipse)

Конвертируем проект

  • Удаляем зависимости из Build Path
  • Понадобится плагин m2e
  • Кликаем на проект -> Configure -> Convert to Maven Project и проходим визард
В итоге в корне появится файл pom.xml, куда нужно добавить зависимости.

Добавляем в POM файл зависимости

  • Все нужные библиотеки находим на http://mvnrepository.com/. В моем случае это
  • Выбираем версию, и mvnrepository подскажет код который нужно добавить в POM файл
рис 1. mavenrepository подсказывает код


Проблемы

Ошибка при сборке проекта (с решением)

После подключения новых зависимостей, при первой сборке возникла ошибка вида "Archive for required library cannot be read or is not a valid ZIP file". Применительно к случайной библиотеке.

Гугл ответил что это - баг эклипса, нужно удалить с диска злополучный jar файл и сделать Maven -> Update Project. Файл скачается снова, ошибки не будет.

Так и оказалось. Пришлось повторять несколько раз, так как ошибка повторялась несколько раз для новых файлов.

Правильное указание зависимости вебдрайвера (с решением, без понимания)

Если взять код из mvnrepository / с официального сайта:
рис 2. зависимость, как ее рекомендует прописать офсайт вебдрайвера. версия 1
Или даже так:

рис 3. зависимость, как ее рекомендует прописать офсайт вебдрайвера. версия 2


...то при запуске тестов - падение при попытке обращения к FirefoxDriver. "java.lang.NoClassDefFoundError: com/google/common/base/Function":
рис 4. печальный результат запуска


В итоге помогло взять код отсюда.
рис 6. магический код, почему работает не знаю

И на том спасибо, но... Что за шаманство?? Это та же самая зависимость от selenium-java, плюс драйвер оперы (которую не использую), плюс исключения для него.

Пробовала удалить вроде-как-ненужный кусок с оперой. Магия ломается и снова летит NoClassDefFoundError при вызове FirefoxDriver().

Я в смятении.

Запускается неправильный браузер (без решения)

После баловства с maven, тесты запускаются в дефолтном браузере системы. До баловства - запускались в недефолтном FF.

Код, запускающий браузер, не менялся:
рис 6. для протокола, как запускаю браузер

Само по себе не мешает, но еще один индикатор что я чего-то не поняла.

Итог

Работать можно. Но осадочек остался.

Upd: с момента написания поста, объяснение нашлось всему. Нет больше осадочка.

По пункту 2, Vyacheslav Klevchenya подсказал в комментариях.

По пункту 3: ложная тревога, запускался Firefox. Просто с последним обновлением он стал сам на себя не похож - не признала. "Извините, был напуган" (с)

воскресенье, 27 апреля 2014 г.

Немного о собственном фреймворке

Начну с поклона Алексею Баранцеву, с его тренингом "Программирование для тестировщиков".

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

Испорчу рекламный эффект: тренинг проходила N лет назад, нынче в сети больше информации на эту тему, и приобрести навык можно без таких затрат.

Исправлюсь: зато во время тренинга за вами проверят ДЗ, ответят на все вопросы на консультации и все такое прочее. 

Это я к чему? К тому, что выбор инструментов и технологий обусловлен только причинами "так было на тренинге" и "это бесплатный инструмент":

  • Java + TestNG + Selenium (который быстро был заменен на WebDriver)
  • Eclipse

Риторические вопросы

Какой он, мир автотестов на Python? А вот если бы JUnit? А вот Idea была бы удобнее?
Экспериментировать пока не собираюсь.

Что у меня работает

Тесты независимы. Тесты отделены от описания локаторов. Не уверена, укладывается ли это в рамки шаблона Page Objects (тм). Но дух "мухи отдельно, котлеты отдельно" соблюден.

Класс ScrEle - обертка вокруг вебдрайвера.

Содержит методы типа click, type и т.п. 
скриншот
рис 1. класс ScrEle - обертка вокруг вебдрайвера
Если я захочу работать с кнопкой OK, я должна где-то описать ее как ScrEle, указав в качестве параметра - локатор.  А потом вызывать нужные методы объекта.

NB Объект вебдрайвера нужно передавать каждому методу как параметр исключительно в силу моего нубства.

Классы страницы/формы

скриншот
рис 2. класс описывающий форму логина
Здесь описаны как элементы на странице -объекты ScrEle, так и методы для стандартных последовательности действий на странице.

NB Объект вебдрайвера нужно передавать каждому методу как параметр исключительно в силу моего нубства.

Тесты

рис 3. тест
В классе из примера заведен метод с последовательностью действий, каждый тест дергает его с разными параметрами.

Если мы не делаем одно и то же с разными параметрами - вся логика будет с методе с аннотацией @Test, доп. метод не понадобится.

Масштабы бедствия

  • реализовано около 50 тестов
  • время выполнения - около 15 минут
  • ручное выполнение тестов занимало бы 5 часов
  • тесты проверяют отчеты, сами не меняют данные в системе. данные в систему внесены предварительно
  • создать новый тест - недолго. создать данные для него - до нескольких часов 
  • 4% ложноотрицательных результатов, причина "не получилось кликнуть" - об этом расскажу подробнее
  • такой ложный fail в логе легко отличим от реального, тест можно быстро перезапустить

Чего остро не хватает

  • 5 часов ручной регрессии уже превращены в 15 минут работы автоматики. Но осталось еще около 15 часов регрессии. Есть куда расширять покрытие.
    • часть грядущих тестов будут аналогичны существующим: вся трудоемкость в заготовке тестовых данных
    • часть будет активно изменять данные. CUD и все такое. тут мне нужно понимание, в какой среде их запускать чтобы были независимыми и "убирали за собой"
Это - todo на ближайшее время, причем рабочее.

Чуть менее остро не хватает

  • Многопоточности.
  • Не все ок со стабильностью.
  • Очень раздражают стандартные отчеты. От того, что видела в thucydides, просто слюнки текут.

Шаблон проектирования Singletone

Ну и стыдное: драйвер инициализируется в родительском классе теста, и передается как параметр через все слои до самого нижнего, ScrEle...  Вроде жить не мешает, но неаккуратно выглядит. 2 недели назад узнала слово "синглтон", надо бы переделать.
скриншот
рис 4. мой маленький позор

Хочу чтобы строка
sTabReports.clientFuture.click(driver);
превратилась в 
sTabReports.clientFuture.click();

Аналогичный образом попробую избавиться от инициализации элементов UI в тестах:
STabReports sTabReports = new STabReports()
 ...пусть будет вынесено за кулисы, а не вызывается в самом тесте.

Тогда все объекты, описывающие UI будут инициализироваться всегда - а не строго перед тем как они понадобятся. Не очень экономно - но думаю не приведет к замедлению тестов. Если приведет, замечу.

Интро. Я и мой велосипед

Всем привет,

Меня зовут Любовь,  работаю тестировщиком в крупной питерской IT компании. Этот блог создан, чтобы систематизировать мои эксперименты с автоматизацией тестирования.



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

Автоматизация у нас это WebDriver + Java + TestNG.

Все собрано в hand-made фреймворк, которому я посвящу часть постов. То есть да, я занимаюсь сборкой своего велосипеда. Тем, что приличные люди делают с 0 за 20 минут.

Ценность продукта для мирового сообщества - не предвидится. Зато процесс поучителен.

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