Джеймс Уиттакер - Как тестируют в Google

Рис. В.1. Меню расширения BITE в браузере Chrome

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

Обычно тестировщикам приходится запоминать и дотошно фиксировать свои действия, чтобы баг можно было воспроизвести. Используя BITE, инженер может быть уверен, что все его ходы записаны в коде JavaScript и их можно посмотреть позже. Теперь можно быстро определить, воспроизводится ли баг в конкретной среде или решилась ли проблема при изменении кода.

Чтобы записывать действия при ручном тестировании и потом воспроизводить их при автоматизированном, в BITE есть консоль Record Playback Framework (RPF). Она автоматически генерирует код JavaScript, который потом можно использовать для воспроизведения выполненных шагов. Механизм записи и воспроизведения BITE устойчив к ошибкам: автоматизированные тесты пользовательского интерфейса иногда могут не проходить, причем проблема часто в самом тесте, а не в продукте. При сбое воспроизведения BITE тестировщик может просто перезаписать свои действия на странице. Не нужно редактировать код или сообщать о сбое теста — если сценарий не может найти кнопку, которую нужно нажать, просто нажмите на нее сами, и сценарий исправится. Если все же без правки кода совсем не обойтись, мы используем редактор Ace (http://ace.ajax.org/), чтобы изменять код JavaScript в реальном времени.

Страница проекта BITE находится по адресу http://code.google.com/p/bite-project . Все вопросы и предложения присылайте по адресу bite-feedback@google.com .

Отправлено Джо Алланом Мухарски из команды технологий веб-тести­рования (продукт был создан участниками команды Джейсоном Стредвиком, Джулией Ральф, По Ху и Ричардом Бустаманте).

Рис. В.2. Интерфейс регистрации багов расширения BITE

Вторник, 06 октября 2011 г. 13:52

http://googletesting.blogspot.com/2011/10/unleash-qualitybots.html

Ричард Бустаманте

Вы разрабатываете веб-сайт и хотите знать, не сломают ли его работу обновления Chrome из дорелизных каналов? Вы хотите простой инструмент для сравнения работоспособности вашего сайта во всех каналах выпуска Chrome? Такой инструмент есть!

QualityBots ( http://code.google.com/p/qualitybots/) — это новый инструмент с открытым кодом, который создала команда веб-тестирования Google для веб-разработчиков. Он сравнивает веб-страницы в версиях разных каналов Chrome с помощью попиксельного DOM-анализа. Когда появляется новая версия Chrome, QualityBots помогает нам рано находить сбои. Кроме того, QualtityBots помогает разработчикам быстро и легко представить, как их страницы будут себя вести в версиях разных каналов Chrome.

Фронтенд-часть QualityBots построена на базе Google AppEngine ( http://code.google.com/appengine/ ), а бэкенд, который обходит веб-страницы, работает на базе EC2. Чтобы использовать QualityBots, у вас должна быть учетная запись в Amazon EC2. Тогда вы сможете запускать виртуальные машины, которые будут обходить веб-страницы с разными версиями Chrome. У инструмента есть веб-интерфейс, в котором пользователи входят в систему, вводят URL-адреса страниц для обхода, просматривают результаты последнего запуска на информационной панели и подробно анализируют информацию о проблемных элементах страницы (как показано на рис. В.3).

С помощью этих результатов разработчики и тестировщики определяют сайты, которым нужно повышенное внимание из-за большого объема изменений. Если страница отображается практически идентично во всех каналах Chrome, ее можно пропустить (рис. В.4). Это экономит время и избавляет от утомительного тестирования сайтов, на которых ничего не изменилось.

Надеемся, разработчики веб-сайтов заинтересуются продуктом и присоединятся к проекту на странице QualityBots ( http://code.google.com/p/qualitybots/ ). Будем рады обратной связи по адресу qualitybots-discuss@googlegroups.com .

Отправлено Ибрагимом Эль Фаром, команда технологий веб-тестирования (продукт был создан участниками команды Эриелом Томасом, Джейсоном Стредвиком, Ричардом Бустаманте и Теджасом Шахом).

Рис. В.3. Пример тестового запуска QualityBot. Результаты показывают различия в отображениях веб-сайтов в разных версиях

Рис. В.4. Информационная панель QualityBot с набором сайтов, протестированных в разных версиях Chrome

Вторник, 17 ноября 2011 г., 5:26

http://googletesting.blogspot.com/2011/11/rpf-googles-record-playback-framework.html

Джейсон Арбон

На конференции GTAC меня спросили, насколько хорошо Record Playback Framework работает в среде BITE. Мы были настроены скептически, но подумали, что кто-то должен попробовать это оценить. Сейчас я расскажу вам, как взялись оценивать качество RPF и что из этого вышло.

Идея была в том, чтобы пользователи могли использовать приложение в браузере, записывать свои действия и сохранять их в виде кода JavaScript для воспроизведения в ходе регрессионных тестов. Как и большинство инструментов, основанных на генерации кода, RPF работает, но не идеален. У По Ху была ранняя рабочая версия, которую он решил опробовать на реальном продукте. По, разработчик RPF, работал с командой веб-магазина Chrome, на котором проверялась работоспособность ранней версии. Почему именно веб-магазин Chrome? Большая часть пользовательского интерфейса этого сайта управляется данными, на нем используется аутентификация, поддерживается возможность отправки файлов, к тому же сайт часто меняется и постоянно ломает существующие сценарии Selenium. Это был крепкий орешек для тестирования.

Прежде чем обратиться к разработчику тестов веб-магазина Chrome Венси Лю, мы сделали то, что нам казалось разумным: провели нечеткий поиск соответствий и построково обновили тестовые сценарии. Selenium — отличная штука, но после создания стартового регрессионного пакета многие команды тратят кучу времени на простое сопровождение своих тестов, так как продукты постоянно меняются. Мы подумали: а что, если инструмент не будет просто проваливать тест, если не найдет нужный элемент, как это делает Selenium? А что, если нам не нужно будет анализировать DOM вручную и быстро менять код теста, а потом разворачивать его снова и запускать, и так по кругу? Что, если тестовый сценарий продолжит выполняться, а обновление кода сведется к простому клику на нужном элементе? Мы же можем брать значения атрибутов записанных элементов веб-страницы и, выполняя тест, просто вычислять процент их совпадений с теми, которые нашел тест во время выполнения. Если совпадение не стопроцентное, но лежит в допустимых пределах (например, изменился только родительский узел или атрибут класса), то мы запишем предупреждение и продолжим выполнение тест-кейса. Если следующие шаги теста проходят нормально, то тесты в сериях продолжают выполняться и только записывают предупреждения. Если запустить тесты в режиме отладки — они приостановятся, чтобы тестировщик мог быстро обновить условия совпадения через пользовательский интерфейс BITE. Мы решили, что это сократит ложноположительные срабатывания и ускорит обновление.