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 минут.

Верификация чужих багов - или не рой яму ближнему своему

Вот такая ситуация, я думаю, не редкость и на других больших проектах:
- есть куча тестировщиков, работающих в разных часовых поясах и не знакомых друг с другом лично.
- есть общая баг-трекинг система с описанием багов. Все могут заводить баги и менять их статусы.

И вот ты сидишь и читаешь "шаги воспроизведения" к чужому багу:
иногда фича №4405 работает не очень хорошо.....
И комментарии программиста, который это исправил:
было исправлено в версии 1.3.4.55554 от 02.03.2004.

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

Понятно, что либо для этого тестировщика такой баг был очевиден, и он решил, что его описание будет очевидно другим (и тогда программисты тоже помучились, чтобы понять в чём проблема) либо тестировщик договорился с программистом и завёл баг, описание которого будет понятно только этим двоим.
Как бы там ни было. Верифицировать третьему.

Господа тестировщики, будьте людьми. Сэкономив себе время, написав слишком короткое описание к багу и не приложив скриншоты, вы тратите время своих коллег (у которых на это уходит больше времени)

Тестировщики - где их обучают?

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

Так вот о чем я.

Всему, что может знать тестировщик о тестировании, он намного более быстрее и результативнее обучается на реальных проектах. После чего покупает пару хороших книжек, читает блоги и занимается тестированием, постепенно наращивая мастерство.

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

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