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. Какой-то другой, революционный способ, который предложите именно вы.

Эмуляция сетей: dynamips & dynagen & Cisco GNS.

    За неимением реальных дорогостоящих и шумных железок Cisco, мы можем использовать эмулятор, для того чтобы протестировать некоторые функции реальных устройств.
    Ценность подобного программного продукта очень велика, особенно, когда тестовое окружение должно включать в себя множество различных роутеров, и топология сети постоянно изменяется. При этом эмулятор позволяет получать далеко не все функции реальных устройств, съедает много памяти и процессора (образы Cisco IOS загружаются прямо в оперативную память вашей машины). Но оно того стоит, в некоторых случаях.

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

    Но какие есть плюсы для тестировщиков кроме самых очевидных?
Это можно автоматизировать! На Python! ) (dynagen написан на питоне и вы можете непосредственно изменять его, редактируя текстовым редактором файл /urs/bin/dynagen ;) ну или на bash, кому что)
Полезное примечание: мы можем создавать конфигурацию оборудования и топологии сети в графическом редакторе Cisco GNS, сохраняя всю сеть в файл конфигурации, а потом в процессе тестирования подгружать различные конфигурации и получать по запросу различные топологии с уже настроенными устройствами. Этим данная технология вызывает у меня восторг ).

    Смотрим для начала:
1. http://unixadmins.su/index.php?topic=122.0

2. http://adminofsystem.net/2010/08/%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B5%D0%BC-%D0%BB%D0%B0%D0%B1%D0%BE%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%B8%D1%8E-cisco-%D1%81-%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5%D0%BC-dynamips/

3. http://7200emu.hacki.at/

4. http://unixadmins.su/index.php/topic,905.0.html

Используя эту технологию, мы можем создавать сложные сети, включающие виртуальные машины и роутеры Cisco. При этом роутеры cisco могут взаимодействовать с виртуальными машинами, если создать необходимые бриджи и виртуальные интерфейсы в системе.
Примечание: Для того, чтобы dynamips не съедал весь процессор, нужно использовать значения idlepc для каждого эмулируемого роутера.

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

sudo tunctl -t tap1
sudo ifconfig tap1 up
sudo brctl addif virt_br2 tap1

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

import time
from subprocess import Popen, PIPE
 

conf  = '/home/user/configuration_of_cisco_routers.conf'

Popen('killall dynamips', shell=True, stdout=PIPE, stderr=PIPE)

time.sleep(2)

Popen('dynamips -H 7200', shell=True, stdout=PIPE, stderr=PIPE)

time.sleep(5)

Popen('dynagen ' + conf, shell=True, stderr=PIPE, stdout=PIPE)

time.sleep(60)

Этот скрипт перезапускает dynamips и dynagen. (чтобы всё это работало, надо применить хак: sudo vi /usr/bin/dynagen  - строка 1521 - закомментировать несколько строчек кода, чтобы при загрузке конфигурации dynagen не запрашивал подтверждения) Можно и без этого, но тогда придётся через pexpect - кому как нравится.

Далее делаем конфигурацию dynagen:

autostart = True
[localhost:7200]
    workingdir = /tmp
    [[7200]]
        image = /home/user/CiscoIOS/cisco.bin
        ghostios = True
        sparsemem = True
        idlepc = 0x60507884
    [[ETHSW sw1]]
        1 = access 10 NIO_tap:tap1
        2 = access 10
        4 = access 20 NIO_tap:tap2
        5 = access 20
    [[ROUTER R1]]
        console = 2000
        f0/0 = sw1 2
        f0/1 = sw1 5
        model = 7200

вот и всё, теперь осталось только настроить cisco роутеры и сохранить конфигурацию.

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

у всего этого есть графический интерфейс, в котором можно "нарисовать сеть", мониторить состояние узлов, снимать трафик для анализа пакетов и многое другое - Cisco GNS. Есть под винду, линукс и мак.