Python + BDD = Behave?

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

Есть множество готовых фреймворков, позволяющих реализовать данный подход, и они во многом схожи. К слову, сами истории использования при переходе от одного фреймворка к другому можно не менять (что тоже является плюсом данного подхода).

Давайте напишем простую историю использования в нотации Gherkin.

   Feature: Administrative web interface

     Scenario: Login
          When user opens browser and navigates on the page "site.com"
              and user "admin" enters login and password in the login form 
              and user clicks "Login" 
            Then user should see the administrative web interface 

Посмотрим, что у нас получилось.
В первой строчке мы видим описание функционала, который будет тестироваться.
Далее в этом же файле описываются сценарии использования данного функционала.
Каждый сценарий имеет имя и некоторые логические шаги, в нашем случае это When.. Then.
Т.е. "Когда пользователь делает вот так, то должно быть вот так". Все просто и понятно.

BDD. Тестирование на основе историй использования

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

Такими дополнительными требованиями можно назвать, например:
1. Скорость разработки и отладки тестов.
        Такие тесты необходимы как можно раньше, их приоритет выше остальных автоматизированных тестов. Запуск тестов после каждого нового изменения в продукте позволяет быстро реагировать на появление проблем и убедиться, что новая версия проходит хотя бы приемочное тестирование.
2. Легкость взаимодействия с системой непрерывной интеграцией и другими компонентами, задействованными на проекте.
        Необходима простота запуска тестов и анализа результатов. Взаимодействие с популярными фреймворками и плагинами и работа с привычными форматами файлов могут существенно облегчить жизнь и сохранить ваше время.
3. Стабильность тестов.
        Это требование применимо к любым тестам, но к приёмочным оно особенно строго оценивается. Автоматизированные приёмочные тесты должны сообщать о проблемах, которые действительно есть на проекте, у вас не будет времени анализировать результаты после каждого запуска тестов и проверять все упавшие тесты. Просто потому что они запускаются в час ночи, когда вы спите.
        Одновременно с этим мы должны помнить, что еще больше трудностей возникнет, если автоматизированные тесты будут ложно-положительными, потому что в этом случае мы теряем сразу все преимущества непрерывной интеграции, снова тратим время на обнаружение проблемы и поиска причин ее возникновения.

Selenium +

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

Сегодня мы говорим о Selenium и о том, как разрабатываются автоматизированные тесты с использованием таких языков программирования, как Java и Python.

Когда я экспериментировал с Selenium Web Driver на питоне, передо мной явно вставала проблема нечитаемого кода автоматических тестов. Я экспериментировал, писал простые тесты, но явно видел, что это не то, что я хотел бы использовать в своей работе.

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

А потом я посетил сайт pyvideo.org, с которого позаимствовал это видео с выступлением одного из экспертов Selenium

Что интересно тестировщикам?

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

Вы можете оставлять комментарии, у вас точно есть хорошие идеи на этот счёт.

SQA Days 2012 как это было

Вот и пришло время рассказать о конференции, на которой я недавно побывал.
Поводом поехать на неё стало то, что в прошлом году вместо неё поехал на Microsoft QA Day 2011 и пропустил SQA Days 2011, но пообещал себе "в следующем году" обязательно съездить.

Перелёт Саратов-Москва-Минск. Всё отлично, Минск шикарен.
Широкие улицы, дорожки для велосипедистов, всё как у людей.
Миллион в кармане ;) - там ведь цены другие.

Хожу по ночному городу ищу где бы поесть. А всё закрыто. Это вам не Москва и не Саратов.
Там редкое заведение работает до 12ти, а большинство в 8 уже закрываются.

Библиотека. По рассказам это должно было быть что-то нереально огромное и крутое) обычное здание.

Регистрация, доклады...

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

Фраза первого дня SQA Days 2012: за рабочий день лучше удалить несколько строчек кода, чем написать несколько строчек кода. Эта фраза выглядит очень интересно и имеет мало смысла, если только не является частью культуры разработки. Я определённо над ней ещё буду думать.

Встретил свою знакомую, с которой раньше работали за соседними столами ).
Конечно, некоторые доклады были хороши, сейчас достану листочек и пройдусь по самым лучшим:
Сервисы на базе автоматизации тестирования. Мне понравился этот доклад по тому, что мы у себя делали что-то похожее когда-то.
Ну и ребята из Яндекса, они вообще вносили некоторую нотку позитива в конференцию, в их докладах были профессионализм, легкость, уверенность, подготовленность. И слайды в стиле Яндекса, что меня позабавило. И конечно же тема, о которой они рассказывали, мне очень интересна, но больше меня всё же зацепил Яндекс-доклад второго дня, потому что он был более практическим.

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

день второй)

Второй день был наполнен ожиданиями чуда ещё с утра, доклад Алексея Баранцева был отмечен красным кружком в плане посещения, так же конечно же доклад сотрудника Яндекса и все доклады по автоматизации, т.к. было решено во второй день ходить только на практические доклады.
Собственно, ценными докладами второго дня можно назвать доклады про HTML Elements и про вектор развития Selenium.
Эти два доклада вселили в меня оптимизм и зарядили именно теми мыслями, которых я ждал от конференции. Закрепив в себе желание изучать Selenium с строить автоматизацию на его основе, я, чувствуя в себе силы свернуть горы, поехал в аэропорт.

Предстояло ночь провести в аэропорту, что я и сделал, сев с ноутбуком рядом с розеткой и кофейным автоматом. Отлично попрограммировал несколько часов. Полностью переделал автотесты на своём проекте, да так хорошо, что до сих пор в восторге) Теперь у меня на каждый тест кейс из тест плана есть тест кейс в excel, записанный в виде user-story, который скармливается фреймворком и поехали...

Потом еще день в Домодедово в ожидании того, что снеговые тучи рассеются.... самолёт.... и я дома.

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

конференция удалась )

Selenium - подборка материалов с комментариями

Конечно, первая ссылка - проект Алексея Баранцева:
http://www.software-testing.ru
Кстати, у него был отличный доклад по селениуму на конференции SQA Days 2012.

Так же стоит обратить внимание на бесплатные тренинги Михаила Поляруша:
http://www.youtube.com/watch?feature=player_embedded&v=IPraAY78jGY

Внимания так же заслуживают материалы с конференций, посвященных Selenium:

http://seleniumcamp.com/archive/selenium-camp-2011/materials/
http://seleniumcamp.com/archive/selenium-camp-2012/materials/

Сайт самого проекта Selenium:
http://seleniumhq.org

Сайт конференции Selenium Camp 2013:
http://seleniumcamp.com

Автоматизируем виртуальные машины на Python. Музей граблей.

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

Начал я с того что установил Virtual Box и пробовл рабораться с  vboxapi. Потратил день. Результат: смог создавать виртуальную машину без жесткого диска, как прикрутить жёстский диск так и осталось тайной за семью печатями. Более того, при попытке отправлять нажатия клавиш на VNC консоль виртуальной машины, отправлялся только символ '=' - при этом бесконечно. Собственно, залогиниться так и не удалось.

 Потом я вычитал про libvirt. Из плюсов: она поддерживает различные гипервизоры, такие как KVM, Xen, Virtual Box и другие (см википедию). Оказалось, вполне дружелюбная библиотечка, но и тут не всё гладко: нужно создавать XML конфигурацию виртуальной машины и сети, а для работы с vnc консолью приходится использовать subprocess, вызывая команды 'virsh ...'.
Но с перечисленными недостатками можно смириться, учитывая, что всё остальное просто прекрасно. В процессе моих поисков толкового документа по libvirt мне попался блог (который я и до этого читал, но о другом):
http://koder-ua.blogspot.com/2011/12/libvirt-co-1.html
где очень доходчиво описано "как начать работу с библиотекой". Собственно, это дало мне хорошую возможность начать, после чего я написал свой класс, который умеет создавать и настраивать виртуальную машину, т.е. можно его использовать для полной автоматизации работы со всеми виртуальными машинами.

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

import re, time, pexpect


class kvm_cmd:
    def __init__(self, vm_name):
        self.cmd = None
        self.i = 0
        while self.cmd == None:
            try:
                self.cmd = pexpect.spawn('virsh console ' \
                                            + str(vm_name))
            except:
                pass

    def flush(self, c='.*'):
        for i in range(3):
            try:
                self.cmd.expect(['.*', pexpect.EOF], timeout = 30)
            except:
                pass
            time.sleep(10)

        try:
            self.cmd.expect([c, pexpect.EOF], timeout = 120)
        except:

            pass

    def wait(self, s):
        if s != '':
            try:
                self.cmd.expect('.*' + s + '.*', timeout = 30)
                self.i = 0
            except:
                self.i += 1
                if self.i < 20:
                    self.wait(s)

    def wait_and_accept(self, s):
        try:
            self.wait(s)
        except:
            pass
        self.run('')

    def run(self, s, c=''):
        self.i = 0
        try:
            self.cmd.sendline(s)
        except:
            pass
        self.wait(c)

 Используя этот класс с виртуальными машинами работать просто и весело, например, вот так

console = kvm_cmd('Host1')
console.wait('login')
console.run('user')
console.wait('password')
console.run('secret')

Но иногда одного консольного интерфейса не достаточно, например, если мы не линукс без графической оболочки поднимаем, а свое приложение с графическим интерфейсом, которое надо устанавливать и запускать в системе с графической оболочкой. Здесь одной консолью не обойтись. Что мы можем сделать:
1. Подключаться к X серверу по ssh и таки запускать приложение на своей машине, после чего уже его тестировать.
2. VNC console. Старый проверенный, хотя и не сказать что дедовский ;) способ. К тому же, есть отличная готовая тулза для linux - vncdotool, которую смело можно использовать для таких целей. Умеет тыкать мышкой и посылать нажатия клавиш, делать скриншоты и сверять картинку на экране со скриншотами. Ну или Sikuli, тоже отличный выбор.
3. Какой-то другой, революционный способ, который предложите именно вы.