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

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

О том, как можно Unit-тестировать JavaScript я писал ранее, сейчас же расскажу о процессе интеграционного тестирования, применяемого в команде.

Geb на практике

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

Browser.drive(driver: new InternetExplorerDriver()) {

    go "http://www.google.com"

    $('form', action:endsWith('/search')).q = 
                    'тестирование при помощи geb и spock'
    $('button', value:'Поиск').click()
    waitFor { $('#search') }
    assert $('#search').size() == 1
    assert $('#search').find('li.g a.l').size() > 0
    println "Первый результат: " + $('#res').find('li.g a.l', 0).text()
}.quit()

Мне кажется, у таких тестов высокая степень читаемости — неважно даже, какой это язык. Можно по такому вот образцу написать еще несколько подобных же тестов, не имея вообще никакого понятия о Geb, Groovy и о том, как это работает. Но для полного понимания немного углубимся в основы.

Наконец-то мы завершили и опубликовали перевод на русский язык документации по инструменту Selenium, пожалуй, наиболее популярному в последнее время инструменту автоматизации тестов для веб-приложений.

Русская версия в определенном смысле даже лучше, чем оригинальная, потому что в нее включены дополнительные главы, скомпилированные из статей в Selenium Wiki, которые заполняют «белые пятна», имеющиеся в официальном руководстве пользователя.

Мы надеемся, что теперь, благодаря преодолению языкового барьера, число поклонников Selenium будет расти ещё быстрее, и мы будем рады видеть Вас в наших рядах!

(Под катом — благодарности спонсорам и участникам проекта по переводу)

Взаимодействие с браузерами никогда не было работой для слабонервных: около полудюжины различных API, различные механизмы IPC, и разные возможности у разных поставщиков. Такие проекты, как WebDriver, пытаются абстрагироваться от этой сложности, к тому же в Сети можно найти десятки других «безголовых» драйверов, использующих WebKit или иные движки. В настоящее время в работе даже находится спецификация W3C на WebDriver.

Инструментирование Google Chrome

Тем не менее, в то время, как создание общего решения является сложной задачей, оказалось, что инструментирование Chrome очень просто, — как я недавно обнаружил при исследовании некоторых вопросов, связанных с сетевыми задержками. Начиная с 18 версии, Chrome теперь поддерживает протокол удалённой отладки v1.0, который предоставляет все возможности браузера с помощью обычного WebSocket!

/Applications/Path To/Google Chrome --remote-debugging-port=9222 # OSX
$> curl localhost:9222/json

[ {
   "devtoolsFrontendUrl": "/devtools/devtools.html?host=localhost:9222&page=1",
   "faviconUrl": "",
   "thumbnailUrl": "/thumb/chrome://newtab/",
   "title": "New Tab",
   "url": "chrome://newtab/",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/1"
} ]

Итак, вы задались целью отладить своё веб-приложение. Вам хочется, чтобы браузер «сам тыкал» на кнопочки, ходил по ссылкам и при этом ещё и проверял состояние элементов. Словом хочется вам интеграционного тестирования, чтобы некий скрипт задавал сценарий действий пользователя и при этом параллельно проверял состояние элементов и изменения в базе данных.

Допустим вы находите или где-то уже слышали, или даже давно хотели попробовать специальный инструментарий для этих дел, зовущийся Selenium WebDriver. Вы идёте на сайт Selenium и радостно прыгаете от восторга: поддерживается ваш любимый скриптовый язык Python! Но увы, как и в случае с Django у разработчиков ещё не дошли руки до Python 3.x. Так что все вкусные синтаксические куски рафинада, а также встроеная поддержка UTF-8 по умолчанию не поддерживаются.

Однако, вооружившись знаниями о различиях между Python 2 и 3, а также стандартной утилитой 2to3.py мы в два счёта поборем всё то, что мешает нашему счастью и всеобщему прогрессу в разработке тестовых скриптов для интеграционного тестирования.

Инструмент автоматизации функционального тестирование веб-интерфейсов Selenium 2 включает в себя два продукта: Selenium Remote Control (Selenium 1) и Webdriver.
Отличаются RC и Webdriver тем, что RC взаимодействует с браузером с помощью Selenium Core — специального инструмента, который может работать с любым браузером через JavaScript. Webdriver же использует нативный интерфейс, что позволяет более точно повторять действия пользователя, однако для взаимодействия с каждым отдельным браузером нужен специальный драйвер (т.к. у каждого браузера свой собственный нативный интерфейс), но при этом скорость прохождения теста повышается. На данный момент существуют такие драйвера:

Эта статья является продолжением более общей статьи «Что такое Selenium?», в которой объясняется, какое положение занимает Selenium WebDriver среди других инструментов автоматизации веб-приложений.

Здесь я постараюсь рассказать более подробно о том, что такое Selenium WebDriver, и почему его бессмысленно сравнивать с TestComplete, QuickTest Pro и другими инструментами автоматизации тестирования. И дело не только в том, что Selenium WebDriver бесплатный и открытый – его столь же бессмысленно сравнивать с другими бесплатными инструментами, такими как Sahi или Robot Framework.

Почему?

Потому что Selenium WebDriver – это не инструмент для автоматизации тестирования.

А что же это такое?

На этот вопрос можно дать несколько разных ответов, сначала я дам короткие ответы, а потом – более подробные.

Кроме того, я объясню, почему Selenium WebDriver имеет такой убогий и неудобный в использовании интерфейс (набор команд), почему он не генерирует красивые отчёты и почему несмотря на всё это он настолько популярен :)

На всякий случай оговорюсь, что хотя в этой статье речь идёт про WebDriver, многие аргументы справедливы и в отношении Selenium RC, но я не буду ничего говорить специально про эту устаревшую версию, потому что её место – на свалке истории.

Недавняя статья про WebDriver напомнила мне немного рассказать об используемом нами комплексе для автоматизации тестирования Web-приложений.

Итак, в основе тестов лежит лежит связка RSpec + Watir WebDriver (для Rails-приложений более уместно будет взглянуть в сторону Capybara). При поддержке Bundler и локальных WebDrivers осуществляется лёгкая инсталляция на рабочем месте тестировщика (установить Ruby 1.9, Rubygems, Bundler, и выполнить bundle install). Исходник Gemfile:

source :rubygems

gem "watir-webdriver", "~>0.6.1"
gem "rspec-core", "~> 2.0"
gem "rspec-expectations", "~> 2.0"
gem "rr", "~> 1.0"
gem "ci_reporter", "~> 1.7"

За счет гема ci_reporter осуществляется интеграция с Jenkins CI, а за счёт гема parallel_tests и Selenium Grid распараллеливание тестов (на сегодня parallel tests пока не используются в production).

Вот пример теста:

describe "FirstSite" do
  before(:all) do
    site! "first"
  end

  # returns true on success; otherwise false.
  def login_as(data)
    browser.rel_goto "/"
    browser.title.should include 'example.com'
    browser.text_field(:id => 'login').set data[:login]
    browser.text_field(:id => 'password').set data[:password]
    submit_button = browser.button(:id => 'submit')
    submit_button.click
    browser.url =~ %r{/welcome$}
  end

  def logout
    browser.rel_goto "/"
    browser.button(:id => 'logout').click
  end

  describe :login do
    auth = fixture :auth

    describe :successful do
      after(:each) do
        logout
      end

      auth.keys.select { |key| key.kind_of?(Symbol) }.each do |key|
        next  if key == :wrong

        it "Logging in as #{key} should be OK" do
          login_as(auth[key]).should be_true
        end
      end
    end

    describe :wrong do
      it "Logging in with wrong credentials should fail" do
        login_as(auth[:wrong]).should_not be_true
      end
    end
  end
end

Тестируемые сайты и способ тестирования определяются в настройках.

Решил написать эту статью, т.к. считаю данный подход наиболее эффективным для организации структуры проекта по автоматизации тестирования.
К сожалению не работал с другими инструментами по автоматизации кроме Webdriver или Selenium. Но, не смотря на это, мне кажется, что данный подход может быть использован и с другими инструментами.

Примеры кода будут на C# + NUnit.

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

Почему же он так эффективен?

Наверное потому, что он вносит этот бесценный порядок в структуру проекта. Следуя принципам этого подхода, мы создаем структуру с четко разграниченными логическими модулями. А каждый такой модуль будет являться отражением логических модулей тестируемого приложения.
Это значительно облегчает поиск и переиспользование методов и, как следствие, облегчает обслуживание проекта. Также, в значительной мере сокращает время, необходимое новому участнику, для «вливания» в проект.

Если вы занимаетесь тестированием веб-интерфесов, то наверняка задумывались о том, как сделать взаимодействие с веб-страницами в тестах максимально удобным. Среди тестировщиков очень широко известен шаблон проектирования Page Object. Но, несмотря на множество плюсов, у этого подхода есть и некоторые недостатки, которые сильно затрудняют его применение.

Наиболее существенные из них:

• невозможность повторного использования кода page-объектов для страниц с одинаковыми элементами;
• плохая читаемость и отсутствие наглядности кода для страниц с большим количеством элементов;
• отсутствие типизации элементов.

Из этого поста вы узнаете, как мы в Яндексе решаем эти проблемы с помощью фреймворка с открытым исходным кодом HTML Elements. Он расширяет концепцию шаблона Page Object и позволяет сделать взаимодействие с элементами на веб-страницах простым, гибким и удобным.

Мы не будем останавливаться на описании самого паттерна и его принципов, поскольку большинству из вас он наверняка хорошо знаком. Если же кто-то с ним не встречался, то узнать о нём можно из этого поста или мастер-класса. Также, говоря о применении паттерна Page Object, мы будем подразумевать его Java-реализацию в фреймворке Selenium WebDriver.

Повторное использование кода

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

Введение

Последние три месяца мне пришлось работать с Selenium 2.0 (WebDriver).
В данной статье я опишу свои впечатления, мысли и опыт, который я приобрел.
Так же я опишу основные действия, которые чаще всего вызывают проблемы и покажу наиболее удачные решения, которые я смог реализовать для них. Возможно есть более правильные подходы — буду рад если оставите их в комментариях.

Больше четырёх лет назад мы озаботились созданием удобной системы для автоматического выполнения Selenium-тестов наших продуктов на разных браузерах. Тогда ещё никто не слышал о Sauce Labs, и все придумывали что-то своё. Мы тоже придумали — сделали свою систему, которая умеет самостоятельно запускать тесты Selenium на выбранных браузерах и ОС по расписанию. Ну, и хранит результаты выполнения, конечно.

В какой-то момент мы решили, что система может пригодиться не только нам, и решили сделать сервис, доступный всем.

Не так давно этот сервис — Nerrvana — открылся для всех желающих.

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

Несмотря на то, что HTML5 всё ещё находится в процессе разработки, он уже появляется в веб-интерфейсах. Одним из основных нововведений этой версии HTML стал элемент Canvas, который используется для отрисовки двухмерной графики. Например, всё, что вы видите и с чем взаимодействуете в игре MMORPG от компании Mozilla или старом-добром Command and Conquer, отрисовывается и обрабатывается с помощью Canvas. Самые изощрённые умы даже реализуют полноценные формы на Canvas. Или интерактивную модель солнечной системы.

Фреймворки для работы с этим элементом растут как грибы после дождя; про то, как начать программировать, используя Canvas, написано огромное количество статей. Но есть один пункт, о котором, по-видимому, из-за узкой специфики говорят редко и мало. Речь идёт о тестировании приложений на Canvas. В каком-то смысле оно становится проблемой для инженера по тестированию, который привык обращаться к элементам на странице по их css или xpath селекторам, а затем выполнять с объектом какие-то действия. С Canvas такой подход не работает, ведь DOM элемент один, а объектов в нём — много.



Под катом на примере автоматизации тестирования API Яндекс.Карт я расскажу вам о том, как мы решили эту проблему в Яндексе.

Автоматизация тестирования – место встречи двух дисциплин: разработки и тестирования. Наверное поэтому, я отношу эту практику к сложным, но интересным.

Путем проб и ошибок мы пришли к следующему технологическому стеку:

1. SpecFlow (опционально): DSL
2. NUnit: тестовый фреймворк
3. PageObject + PageElements: UI-абстракиця
4. Контекст тестирования (информация о целевом окружении, пользователях системы)
5. Selenium.WebDriver

Для запуска тестов по расписанию мы используем TFS 2012 и TeamCity.
В статье я опишу, как мы к этому пришли, типовые ошибки и пути их решения.

Уверен, что бывалые автоматизаторы из мира веб-тестирования на Selenium WebDriver, уже успели попробовать на вкус все достоинства использования паттерна PageObject в своем ремесле. Да, это и сокращение времени на обслуживание кода автоматизации, и более читабельный простой и надежный код. К сожалению, всё еще тратится слишком много рутинных усилий на создание новых PageObject-классов и поддержку существующих.

К счастью, есть инструменты, которые помогут сократить этот рутинный «ручной труд» автоматизатора.
SWD Page Recorder – это попытка создать один из таких инструментов.

Всем привет!

Я бы хотел рассказать о проблемах, с которыми я сталкивался в процессе освоения Selenium WebDriver, c их решением и тем, как эти решения, в принципе, можно использовать. Все это представлено в виде прототипа фрэймворка, ссылка на который будет в конце статьи.

В этом посте я хочу поделиться своими идеями реализации шаблона Page Object, о том как можно обрабатывать ошибки, возникающие в процессе выполнения тестов, рассказать немного о логгинге. А так же поделиться сведениями о некоторых инструментах, которые реализованы с использованием Selenium WebDriver, и своими наработками.

План моей статьи следующий:

1. Капитан очевидность, вместо вступления.
2. Немного о себе, надо представиться…
3. Почему Selenium?
4. О Page Object…
5. Не баг, а фича!
6. И снова про логгинг и отчетность.
7. А разве нет аналогов?
8. Обещанные ссылки.
9. В заключение.

Итак, поехали!

Трудно одним заголовком сформулировать, чем же является Galen Framework. Все началось с того, что у меня возникла потребность тестировать сайты в различных браузерах и проверять: не поехала ли разметка, например, в том же Internet Explore или Chrome. Затем возникла мода на Responsive Web-Design, и пришлось вручную менять ширину браузера и проверять, как отображаются сайты. И, хотя все это время были WebDriver и Selenium Grid под рукой, так и не получалось нормально тестировать верстку сайта в Java коде. Одна из идей была: делать скриншоты в разных браузерах в Selenium Grid и затем собирать их все в один большой отчет, по которому один из тестировщиков обязан пробежаться глазами и, в случае обнаружения несоответствий, рапортовать о дефекте. К сожалению, вся эта затея долго не продержалась. Тестировщикам стало лень листать огромный отчет и сравнивать скриншоты, и они все равно пропускали мелкие дефекты. А затем пошли требования внедрения во всех сайтах Responsive Design. И вот тут появился Galen Framework. Решение оказалось простым: проверять размер и расположение элементов относительно друг друга. Для этого понадобился специальный язык Galen Specs, который было бы легко читать и понимать.



Если коротко, Galen Framework — это специальный язык и инструмент для тестирования отображения сайта в браузере. Он позволяет тестировать адаптивный дизайн, а также проводить кросс-браузерное тестирование сайта.

Статья расскажет о том, как настроить фреймворк автоматизированного тестирования пользовательского интерфейса на языке C#, вместе с Selenium WebDriver и паттерном PageObjects.

Стартовый набор с открытым исходным кодом – SWD.Starter – поможет написать и запустить ваш первый тест в течении 10 минут. Кроме этого, предлагая архитектуру фреймворка, основанную на хороших практиках автоматизации тестирования.
Весь код SWD.Starter может быть полностью настроен под ваши задачи.

Я расскажу как мы в компании работаем с приемочными тестами. В статье вас ждет ссылка на репозиторий с кодом и видео с примером работы.