Тестирование IT-систем *

Атака клонов.
Эпизод: покер.

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

Это не эпизод легендарной саги «Звёздные войны» и не превью фантастической повести. Это описание нагрузочного тестирования сервера (построенного на технологиях Java), проведенного в ходе разработки игрового приложения «Покер» для социальных сетей.

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

За время, прошедшее с публикации первой статьи на хабрахабре, появилось желание поделиться с сообществом некоторыми мыслями, а так же более подробно описать процесс создания программного симулятора автоматизируемого оборудования. Желающих ознакомиться с предыдущим текстом, прошу сюда — Симулятор для тестирования ПО АСУТП.

Теперь на сайте проекта выложена полная версия программы. После некоторых размышлений, пришёл к выводу, что развить данную поделку до коммерческого продукта не получится. Буду рад отзывам от коллег по цеху, если кому-то пригодиться.

Задача, которая была выбрана в качестве примера, относится скорее к обработке сигналов, чем к АСУТП, и не имеет абсолютно ни какого практического смысла. Сделано это намеренно, для того чтобы не отвлекать читателя излишними подробностями предметной области и увеличить наглядность (все любят графики).

Перефразируя известную поговорку: «не делает багов тот, кто ничего не кодирует». Каждый разработчик умеет и любит делать баги, но не любит потом их исправлять. Ошибки в коде в одном случае приводят просто к некорректной обработке данных программой, а в другом — к исключениям (вылетам, падениям, крашам). В этом посте я расскажу о том, как можно автоматизировать сбор данных о краше программы, чтобы сильно облегчить себе жизнь при разборе и устранении ошибок.

Ответ на топик «Распространенные ошибки при составлении баг-репортов».

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

Если кратко, то хороший баг-репорт позволяет:
1. воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. понять, в чем проблема и какова ее важность.

Как написать хороший баг-репорт?
Для начала надо подготовиться. Если вы обнаружили баг, не стоит моментально бежать в баг-трекер и писать «ничего не работает!». Воспроизведите ошибку. Воспроизвелась? Отлично. Не воспроизвелась? Значит, что-то вы не учли. Вспоминайте, что делали.

На Хабре достаточно много написано про хороший стиль программирования, naming convention. А про хороший стиль написания баг-репортов?

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

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

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

Я работаю в нагрузочном тестировании относительно недолго, и одним из моих основных инструментов является Apache Jmeter. Тем не менее, большинство моих коллег не использовали Beanshell в JMeter, и в этой статье я хочу показать пару способов как он может упростить и сократить время подготовку к самим тестам. А покажу это на примере конвертации текста в base64-кодировку и простых стрельб в MongoDB.

Вдохновение.

Пока 55% ненавидит…

А я выбрал «другое». Потому что люблю. Но не за то, что считаю удобнее других, а за то, что…

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

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

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

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

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

Недавно Nokia представила две новые модели самой молодой своей линейки Nokia Asha Touch: 308 и 309. Физически эти телефоны до нас еще не добрались, зато предыдущие три модели: 305, 306 и 311 с конца августа уже продаются в РФ. Так что у меня была возможность познакомиться с этой линейкой, интересной не только ценовой категорией, к которой относятся ее продукты, но и изрядно переработанной под сенсорное управление программной платформой Series 40, на которой и работают девайсы этой линейки.

Доброго времени суток, любители зажать конструируемую систему в рамки разнообразных тестов! Многие из вас пользуются средствами для создания системных тестов. Кто-то даже использует FitNesse, о котором на Хабре немного рассказывали. Поэтому не буду повторяться и писать про то, что такое FitNesse и с чем его едят. Лучше расскажу про то, как заставить проект «заниматься фитнесом» в процессе сборки, которая протекает при помощи TeamCity.
Интересненько? Тогда добро пожаловать под кат.

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

Это подробный обзор двух крэдлов для смартфона HTC Desire S производства Mugen Power. Первая часть обзора посвящена десктопному крэдлу KDG-LXH-HTDS. Вторая часть обзора — автомобильному крэдлу KDG-CS1-HTDS.
Обзор включает не только внешний осмотр устройств с перечислением их характеристик, а и полную разборку устройств.

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

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

Удобен ли ваш сайт для регистрации в условиях зомби-апокалипсиса?

Недавняя статья про 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

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

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

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

Почему?

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

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

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

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

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

Первоисточник: T-Mobile introduces Tappy, the software testing robot
В настоящее время мы живем в мире, где существует достаточно большое количество различных операционных систем, в том числе и мобильных, используемых еще большим количеством производителей смартфонов и планшетных компьютеров. Вполне естественно, что все это вносит достаточно большую «фрагментацию» программного и аппаратного обеспечения мобильных устройств, что отрицательно сказывается в некоторых случаях на потребительских качествах мобильных устройств. Согласно информации от американского оператора мобильной связи T-Mobile подавляющее большинство зарегистрированных возвратов мобильных устройств произошло из-за затруднений, связанных с недоработками и ошибками в программном обеспечении, которе оставили неудовлетворенными потребности клиентов компании.

Время от времени мне приходится распутывать терминологические хитросплетения, связанные с употреблением словосочетаний, в которых встречается слово Selenium – Selenium 2.0, Selenium IDE, Selenium RC, Selenium WebDriver, Selenium Server, Selenium Grid.

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

Тестирование является важной составляющей процесса разработки приложения. Для Android тестирование особенно важно, так как устройства сильно отличаются друг от друга:

• Размером и разрешением экрана.
• Версией Android.
• Форм-фактором.
• Системой команд процессора.
• Наличием фронтальной камеры, NFC, внешней клавиатуры, и т.д.

Поэтому тестировать приложение приходится на множестве устройств.
В процесс тестирования входят различные виды тестирования. Рассмотрим, как происходит процесс функционального тестирования приложения вручную. Тестировщик устанавливает на устройство приложение, вдумчиво проверяет всю функциональность, затем возвращает устройство в первоначальное состояние. И так для каждого приложения и каждого устройства. Очевидный недостаток такого способа – большие затраты времени для регулярного тестирования.
Очевидный плюс автоматизированного тестирования – его можно регулярно проводить без особых затрат. Например, каждую ночь тестировать свежий билд приложения на всем множестве имеющихся устройств, а утром анализировать результаты и исправлять ошибки.
В данной заметке будут рассмотрены средства реализации автоматического тестирования. Рассматриваются только инструменты, входящие в Android SDK или распространяющиеся под Open Source лицензией.