Тестируем API на Python.

Для тестирования API сервиса раньше на проекте использовался Soup UI (а до него ещё одна программа, но лучше о ней не вспоминать)

SoupUI, конечно, хорошо.
Но:
1. Бесплатная версия заставляет делать множество лишних движений (например, нельзя скопировать и вставить несколько повторяющихся действий из теста в тест или получить список всех входящих и выходящих параметров для вызываемых функций, когда передаём значение от одной к другой)
2. Результат приходится проверять вручную, т.к. даже если тест 'passed' - вполне вероятно, что было возвращено какое-нибудь исключение, которое программа посчитала за корректный ответ.
3. Как показывать отчёт? Сколько тестов и на какие функции было запущено? Сколько из них пройдено и не пройдено?

Если коротко: в такой автоматизации слишком много приходится делать руками.
Поэтому, встречайте: Python !

Что он даёт:
1. Удобная библиотека работы с API позволяет в одну строчку вызывать любую функцию, получать ответ и адекватно его проверять (я использовал suds, но есть и другие, можно здесь найти: ссылка на stackoverflow )
2. Возможность генерировать отчёт в HTML (например http://tungwaiyip.info/software/HTMLTestRunner.html )
3. Полная автоматизация: запустил скрипт, через пол часа пришёл и забрал готовый отчёт.

Недостатка два:
1. Для работы с такими тестами (например, чтобы понять почему какой-нибудь тест упал) вам нужен человек, знающий Python (но вам достаточно одного человека).
2. Большой объем Python кода. если у вас, скажем, 30 функций, у каждой функции в среднем по 3 параметра, то с учётом проверки возможных классов эквивалентности (в идеале мы хотим протестировать как можно больше) получаем 4 * 3 * 30 тестов, каждый в строчек 10-20. Итого: 3600+ строк Python кода. Поэтому важно обзавестись хорошим редактором, который позволяет, например, сворачивать текст отдельных функций, а так же удобно подсвечивает питон код.


Пример того как генерировать HTML отчёт: ещё одна ссылка на stackoverflow

Selenium. Start.

Начало работы с Selenium.

Давно мечтал начать работать с этим фрэймворком для автоматизации тестирования веб приложений.

Чтобы начать:
1. Смотрим видео файл
    Спасибо авторам этого видео. Бесплатно выложенный видео-урок для того чтобы начать. Отлично, то, что нужно. Дальше - уже сами.
    Подробно расскажут как поставить selenium и python/java к нему. Научимся делать простые тесты, поговорим о полезной утиле Mind - теперь я знаю как делать красивые, эффектные презентации.

2. Ещё: cтатья в блоге о бесплатных лекциях по selenium

3. Установка в Linux Ubuntu была проста:
sudo apt-get install python-pip
pip install selenium
и далее работаем с любимым браузером.

В Windows надо будет как всегда допиливать:
 - скачиваем питон: http://www.python.org/download/
 - скачиваем setup tools: http://pypi.python.org/pypi/setuptools#Credits
 - прописываем ручками пути в переменную окружения Path к папке с питоном и папке с easy_install:  C:/python27/   & C:/python27/Scripts/
 - устанавливаем pip:  easy_install pip   (не забываем каждый раз закрывать окно консоли и открывать заново, чтобы виндовс увидел сделанные ранее изменения)
 - устанавливаем селениум:  pip install selenium

да, на експлорер надо скачать дополнительный компонент, версия которого зависит от битности операционной системы:
http://code.google.com/p/selenium/downloads/list
и да, необходимо запускать IE-сервер для корректной работы драйвера и прописать путь к нему в переменной окружения.

4. Покатили:
    from selenium import webdriver
    browser = webdriver.Firefox()
    browser.get("http://google.com")
    ...

   Welcome to Selenium )

дополнительно, по вопросам о локаторах:
http://selenium2.ru/docs/webdriver.html
http://autotestgroup.com/ru/blog/85.html
https://addons.mozilla.org/en-US/firefox/addon/xpath-checker/

Всё оказалось не так здорово, как виделось при прочтении множества статей о возможностях селениума в качестве фрэймворка для автоматизации. Идентификация простейшего объекта, который QTP распознаёт на раз, для selenium оказалась невыполнимой, даже с несколькими вариантами xpath. Оказывается, когда страница состоит из нескольких фреймов и встроенных страниц со структурой "таблица в таблице", xpath не так уж и силён. Selenium IDE видит объект, а Selenium Web Driver - нет. Читаю про локаторы, проникаюсь дао автоматизации.

вкусности:
http://automated-testing.info/forum/razbiraemsya-v-zapuske-testov-v-jenkins-maven-testng-webdriver-na-java

Soup UI free и все все все

Автоматизированное  тестирование. Тестирование API. Soup UI.

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

Soup UI - программа для функционального / регрессионного / нагрузочного тестирования, а так же для тестирования безопасности. Строго говоря вряд ли качество тестирования безопасности при помощи этого инструмента находится на достаточном уровне, но безопасность - дело тонкое, и, на мой взгляд, в этом деле лучше ничем не пренебрегать. В том числе - необходимо использовать максимум доступного (тем более есть бесплатная версия) программного обеспечения для автоматического сканирования и обнаружения известных типов уязвимостей, вдруг да что-нибудь обнаружится.

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


Тема сегодняшнего дня - Soup UI в тестировании REST API.
Тестируемое устройство: Cisco ANM 6.1
Версия программы Soup UI 4.5.1 free.
Сайт: www.soapui.org

Раньше использовали SOAtests 9.0. Жуткая штука - тормозная и достаточно сложная. При разрастании тест кейсов больше чем на 25 мегабайт - будьте добры создать новый проект, иначе всё начинает тормозить, появляются артефакты. В атоматизированном тестировании они ни к чему.
Ко всему этому ещё скажем о проблемах с лицензией, которая располагается на сервере лицензий и настройки постоянно сбиваются. Всё это не лучшим образом сказывалось на скорости и качестве проведения тестирования. И вот однажды мы подсмотрели как этот же функционал тестируют его разработчики... бесплатным плагином Soup UI для Eclipse!

Создаём новый проект, щёлкаем на имени проекта правой кнопкой мыши и выбираем "добавить схему WSDL".
Выбираем заранее сохранённый файл с WSDL схемой.
Создаём New Test Suite
Это сьют, в который мы будем складывать все тест-кейсы.
Щелкаем правой кнопкой по сьюту, выбираем New Test Case, задаём имя нового тест кейса.

Теперь у нас есть Test Case 1, принадлежащий Test Suite 1.
Щелкаем два раза левой кнопкой по тест кейсу, открывается список его шагов, он сначала пуст.
Щелкаем правой кнопкой мыши в списке шагов тест кейса, выбираем Append Step > Test Request.

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






Вопрос, который меня мучил несколько дней - как в бесплатной версии Soup UI передавать параметр Sesion ID от Login к Logout.
Рассмотрим структуру ответа Login и запроса Logout:

Ответ на запрос Login:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
  <ns2:loginResponse xmlns:ns2="http://anm.cisco.com">
    <SessionToken>
      <sid>-2124210123754741170</sid>
    </SessionToken>
  </ns2:loginResponse>
</S:Body>
</S:Envelope>

Запрос на Logout:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:anm="http://anm.cisco.com">
<soapenv:Header/>
<soapenv:Body>
  <anm:logout>
    <sessionToken>
      <sid>?</sid>
    </sessionToken>
  </anm:logout>
</soapenv:Body>
</soapenv:Envelope>

Хочется не копировать каждый раз параметр sid из ответа одной функции в запрос другой, хочется чтобы значение передавалось автоматически - и мы сразу видели результат работы всей цепочки шагов.
Оказалось всё просто. Между двумя шагами тест кейса надо вставить экшен Property Transfer.

В Property Transfer создаём новый элемент, SessionID.
Указываем следующие свойства:

Source: login     Property: Response

В текстовом поле пишем:
//SessionToken/sid

Target: logout   Property: Request

В текстовом поле пишем:
//sessionToken/sid

Готово, запускаем - работает.

 Выход найден:
1. Soup UI бесплатен, не надо мучиться с сервером лицензий и запускать его где-то на виртуалке, можно запускать прямо на свое машине.
2. Soup UI работает быстро, без артефактов.
3. Soup UI помогает делать то же самое и даже больше. Правда, разобраться в нём тоже не просто, подвох тут в том, что большая часть документации охватывает... платную версию, в которой, конечно, есть специальные удобные штуки для того чтобы не ломать голову как же добраться до свойств функций и другие вещи.

Вдохновение

Есть такие видео, которые заставляют нас задумываться о том, что мы делаем.

(С) Видео файл позаимствован с сайта pyvideo.org

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

Уменьшение количество кода и улучшение его качества, читаемости, логичности, точности - это отлично. Это здорово. Как будто и не может быть лучше.

Есть отличная идея про разработку программного обеспечения будущего.
Разработка в таком стиле, чтобы все баги бросались в глаза и были уникальными.
Идея в том, что при этих условиях их легче заметить.
Если он виден, если он буквально размахивает красным флагом с надписью "БАГ" - тут-то его и поймают.
Вопрос в том каковы принципы написания кода, который выводит все баги на чистую воду.
Паттерны отлично тестируемых приложений. Идеальный цикл разработки с исправлением багов до их внесения. Надо будет подумать об этом чуть дольше.

Идея как раз в том, чтобы не плодить новые проблемы, решая имеющиеся проблемы. Чтобы ставить цель и достигать её кратчайшим путём. И делать программы так просто, как это только возможно. Легко. Качественно.

DevCon 2012 online

DevCon 2012. Online трансляция.
2 дня отличных мыслей, отличного настроения. Полный мотивацией видеоряд.

Плюсы:
их куча - выступление реально классных людей о реально классных вещах. Жаль, многие интересные доклады пропустил, надеюсь, у меня будет возможность посмотреть запись чуть позже.
Много мыслей, новых классных, воодушевляющих на что-то великое. Так и хочется сразу сесть и сделать всё хорошо на своем проекте.
Microsoft TFS вновь радует (не смотря на постоянное её упоминание, даже не приедается, интересно - т.к. множество разных классных штук туда напихали)
ну и конечно же классные обзоры возможностей Visual Studio 2011, которой я сейчас активно пользуюсь и очень этому рад - очень классно сделанный софт.

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

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

Выводы:
1. Стоит посетить.
2. Надо ехать "вживую".

жду записей всех докладов, обещали выложить на сайте - будет здорово посмотреть )
кстати сайт конференции: http://www.msdevcon.ru/online

Microsoft QA Day 2012

Москва. Microsoft QA Day 2012.
Я посетил это мероприятие, после чего решил дать своим мыслям немного упорядочиться, перед тем как записывать их в блог.

... Москва встретила меня снегом с дождём, время на часах 5:30 утра, начало конференции в 9:00.
Метро, поиски центра "Инфопространство", о котором, похоже, не знает ни один москвич.
Но я его всё же нашёл.

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

10:00. Начало выступления Рэкса Блэка.
Большой человек. В прямом смысле этого слова. Выше всех нас )
Рассказывал про баги, про то, как они переходят от этапа к этапу при разработке программного обеспечения. О стоимости ликвидации багов на этапе планирования и разработки. И о том, сколько может стоить баг в продукте, который был отдан пользователю.
От синхронного перевода пришлось отказаться, с первых минут наслушался про "дикие баги" в продукте, которые на самом деле являются всего лишь необнаруженными деффектами в программном обеспечении.
Выступление всем понравилось. Действительно, поговорили об интересном.

Далее доклады пошли один за другим, выступали ребята из Microsoft, показывали, что умеет их тулза Team Foundation Service - действительно очень впечатляющая вещь. Для команд, которые разрабатывают программное обеспечение в Visual Studio это действительно круто. Позволяет разрабатывать автоматические тесты на основе исходного кода, анализирует покрытие, сопоставляет тест кейсы с требованиями и исходным кодом, создаёт на основе этого отчёты. Так же создаёт отчеты на основе результатов прохождения автоматизированных тестов и блокирует возможность закоммитить код, который не прошёл автоматизированные тесты. Что ещё нужно для счастья? )
А, точно - ещё и позволяет определять изменения в коде с момента запуска предыдущих тестов и запускать регрессионные тесты только для того функционала, который был "задет" внесёнными в код изменениями. В общем это действительно качественный переход к другому процессу разработки и тестирования. Хочу попробовать поучаствовать в таком процессе, результаты и процесс интересны до жути )

Выступал Дмитрий Питунин из Intel с очень интересным докладом о том, как можно оптимизировать QA процессы. О том что надо автоматизировать всё что можно, а то что не автоматизировано выполнять пореже. И опять же - QA - должны давать информацию о продукте. Красивые отчёты, анализ, диаграммы. Тогда от тестирования будет толк.
В общем тоже очень полезный доклад. Бонусы: идея ботов, которые гоняют самосгенерённые тесты.

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

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

... После докладов: розыгрыш MSDN подписок и ноутбука Samsung, сессия вопросов к докладчикам.
Гуляем по вечерней Москве с трофейным рюкзаком, едем обратно в поезде почитывая две трофейные книжки )

Поездка удалась. Появились новые тестерские силы, новые мысли, новые идеи. Конференции, оказывается, очень полезная вещь.

Баги долгожители

Сегодня собираюсь написать о багах-долгожителях, о замыленном взляде, о долгом процессе тестирования...
О насущных проблемах, на которые есть пару способов управы, да всё нет времени взяться за них обеими руками.

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

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

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

Апельсин дольками.
Режьте пополам!
Так, вот, о чём мы. Лечится всё это легко. Тест-кейсы разрабатывает вся команда. Каждый выполняет тест-кейсы только те, которые не писал сам. при выполнении ты должен изменить тест-кейс - что-то добавить, исправить или удалить. Это надо сделать таким же обязательным пунктом, как предоставление результатов для каждого тест-кейса. Временно увеличивать количество тест кейсов на одну из функций приложения. Увеличить в несколько раз, провести тестирование, после нахождения всех возможных багов сократить количество тест кейсов до первоначального, основываясь на анализе найденных багов. Потом то же самое для другой функции. И по кругу.
И ещё одно правило, которое, к сожалению, тоже приходится писать - сообщать о всех выявленных дефектах/недочётах, которые были обнаружены в ходе проведения тест-кейса или в ходе ручного тестирования.

И да, ещё. Многим такая схема может прийтись не по вкусу. Что значит постоянно менять описание тест-кейса? Это значит постоянно отвлекаться. Терять много времени. И вообще "заниматься не тем". Это всё из отговорок, но они по-своему весомые.
Вообще говоря, не обязательно к паровозу прикручивать крылья. Такой режим работы можно задавать одному из членов группы и каждый раз менять "Избранного". Можно даже это обыгрывать переходящим Знаком Отличия. Кепка великого Исправителя тест-кейсов или кружка главного-тест-аналитика.
И да упасут те высшие силы в которые вы верите вас кого-то заставлять. На эту должность вам нужен человек с очень хорошим вниманием и памятью, с горящими глазами. Заставив править тест кейсы кого-то через силу, хорошего ожидать не приходится.

Ну и в конце-концов. Если вы вдруг не тим-лид - а большинство тестировщиков и QA именно из этой группы (как ни странно )) ) - и вы не особо можете командовать и менять порядки в группе - вы можете постоянно, даже не афишируя особо - брать эту роль на себя. Не забудьте только руководство уведомить о том, что собираетесь "лезть в тест кейсы" с исправлениями и дополнениями. А то мало ли.

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