Текст книги "Как тестируют в Google"

Автор книги: Джеймс Уиттакер

Соавторы: Джефф Каролло,Джейсон Арбон
сообщить о нарушении

Текущая страница: 26 (всего у книги 26 страниц)

Тур неблагополучных районов

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

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

Неблагополучные районы в Chrome OS

В тур неблагополучных районов в Chrome входят:

– Онлайн-видео: Hulu, YouTube, ABC, NBC, полноэкранный режим, высокое разрешение.

– Flash-контент: игры, реклама и презентации.

– Расширения: расширения, требующие усложненного тестирования.

– Апплеты Java: проверка успешного запуска апплетов Java (например, игр Yahoo!)

– Технология O3D: проверка контента, написанного с использованием технологии Google O3D (например, в видеосвязи Gmail).

– Множественный запуск: попытка открыть несколько экземпляров с «тяжелым» контентом в разных вкладках и окнах.

Тур персонализации

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

Применение: исследование различных способов настройки Chrome для предпочтений конкретного пользователя с помощью тем оформления, расширений, закладок, настроек, ярлыков и профилей.

Способы настройки Chrome

В тур персонализации Chrome входят:

– Темы: использование тем для настройки внешнего вида Chrome OS.

– Расширения: загрузка и установка расширений Chrome OS для модификации функциональности и оформления.

– Настройки Chrome: настройка взаимодействия пользователя с Chrome с помощью изменения конфигурации.

– Разделение профилей: проверка того, что настройки одного пользовательского профиля не будут распространяться на другие учетные записи.

Приложение В. Посты из блога об инструментах и коде

В этом приложении приведено несколько постов из Google Testing Blog.

Охотимся на баги и потерянное время вместе с BITE

Среда, 12 октября 2011 г. 9:21

http://googletesting.blogspot.com/2011/10/take-bite-out-of-bugs-and-redundant.html

Джо Аллан Мухарски

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

BITE (Browser Integrated Testing Environment) – расширение Chrome с открытым кодом ( http://code.google.com/chrome/extensions/index.html), которое помогает упростить ручное веб-тестирование (рис. В.1). Чтобы расширение заработало, нужно связать его с сервером, на который он будет отправлять информацию о багах и тестах вашей системы. Тогда через BITE можно будет регистрировать баги в контексте веб-сайта, используя подходящие шаблоны.

Рис. В.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. Все вопросы и предложения присылайте по адресу [email protected].

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

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

QualityBots идет в атаку

Вторник, 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/). Будем рады обратной связи по адресу [email protected].

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

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

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

RPF: Record Playback Framework

Вторник, 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. Мы решили, что это сократит ложноположительные срабатывания и ускорит обновление.

Мы ошиблись, но в хорошую сторону!

Мы оставили тестировщика наедине с RPF, а потом поговорили с ним через несколько дней. Он уже воссоздал большинство своих тестовых пакетов Selenium в RPF, причем тесты уже начали ломаться из-за изменений в продукте (тестировщикам в Google нелегко угнаться за темпами поставки изменений разработчиками). Он выглядел вполне довольным, и мы спросили, как справляется новый хитрый механизм нечеткого поиска соответствий. «А, это? Даже не знаю. Я не пользовался…» – ответил Венси. Мы начали подозревать, что наш интерфейс обновления тестов был непонятным, не работал или его было трудно найти. Но Венси сказал, что для упавших ему тестов было проще записать сценарий заново. Все равно нужно повторно тестировать продукт, так почему бы не начать запись во время ручной проверки рабочего элемента, затем удалить старый тест и сохранить вновь записанный сценарий?

За первую неделю использования RPF Венси узнал следующее.

– 77% функций веб-магазина можно было тестировать в RPF.

– Генерация регрессионных тест-кейсов в этой, ранней версии RPF шла примерно в восемь раз быстрее, чем в Selenium/WebDriver.

– Сценарии RPF обнаружили шесть функциональных регрессионных багов и много непостоянных багов серверной части.

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

– RPF работает на Chrome OS, где Selenium не может работать в принципе, потому что требует наличия бинарных файлов на стороне клиента. RPF работает, потому что это облачное решение, которое полностью выполняется в браузере и взаимодействует с бэкенд-системой через веб.

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

– Венси высказал пожелание, чтобы технология RPF работала не только для Chrome, ведь люди все-таки использовали разные браузеры для посещения сайтов.

Итак, мы поняли, что вырисовывается кое-что интересное, и продолжили разработку. Правда, тестирование веб-магазина Chrome скоро вернулось на технологию Selenium, потому что оставшиеся 23% функциональности требовали локального кода Java для поддержки отправки файлов и безопасного входа. Оглядываясь назад, мы понимаем, что небольшое улучшение тестируемости на сервере решило бы проблему с AJAX-вызовами на клиенте.

Мы проверили, как RPF ведет себя на популярных сайтах. Вся информация доступна в открытой вики проекта BITE. Сейчас она немного устарела, многое исправлено по сути, но можно сформировать общее представление о том, что не работало. Считайте, что показано качество альфа-версии. Итак, RPF работал для большинства сценариев, но оставались еще серьезные нестандартные случаи.

Джо Аллан Мухарски проделал огромную работу над нашим неуклюжим пользовательским интерфейсом, чтобы превратить его из чисто гиковской вещи для разработчиков в нечто интуитивно понятное. Он попробовал скрывать пользовательский интерфейс до тех пор, пока в нем не возникнет необходимость, и сделать все простым и удобным для поиска. Мы не проводили формальных исследований удобства использования, но мы наблюдали за сообществом тестировщиков, которые использовали эти инструменты почти без инструкций, и внутренними пользователями, которые сообщали о багах Google Maps без особых проблем. В более сложных частях RPF обнаружились неприятные сюрпризы, но базовая функциональность записи и воспроизведения, похоже, для большинства людей оказалась вполне понятной.

Со временем проект RPF вырос из экспериментального проекта команды тестирования в формальную часть всей команды Chrome, где его теперь используют для регрессионного тестирования. Команда работает над тем, чтобы дать возможность тестировщикам, которые не умеют программировать, возможность генерировать регрессионные сценарии с помощью BITE/RPF.

Присоединяйтесь к нашей работе по сопровождению BITE/RPF ( http://code.google.com/p/bite-project/). Не забудьте поблагодарить По Ху и Джоэла Хиноски, которые двигают проект вперед.

Google Test Analytics – теперь с открытым кодом

Среда, 10 октября 2011 г., 13:03

http://googletesting.blogspot.com/2011/10/google-test-analytics-now-in-open.html

Джим Рирдон

Тест-план мертв!

Ну, мы на это надеемся. Неделю назад на семинаре STAR West Джеймс Уиттакер выяснил мнение профессиональных тестировщиков о тест-планах. Его первый вопрос был такой: «Кто из присутствующих пишет тест-планы?». Поднялось около 80 рук – подавляющее большинство. «Кто из вас получает от тест-планов практическую пользу или возвращается к ним через неделю?» Руки подняли ровно три человека.

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

Мы в Google решили создать методологию на замену тест-планам. Она должна быть полной, быстрой, действенной и приносить постоянную пользу проекту. Не так давно Джеймс уже писал в нашем блоге об этой методологии, которую мы назвали ACC. У нас получился инструмент, который разбивает продукт на составные части, и метод, который помогает составлять «10-минутные тест-планы» (вообще-то это занимает около 30 минут!).

Полнота

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

Скорость

Методология ACC работает быстро: создание классификации ACC даже в сложных проектах занимало у нас меньше получаса. Это намного быстрее составления тест-планов.

Действенность

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

Польза

Мы создали несколько экспериментальных фич, которые воплощают в жизнь тест-план ACC, показывая данные, по которым можно количественно оценить риск в проекте (баги, тестовое покрытие).

Сегодня я с радостью объявляю, что мы открываем исходный код Test Analytics ( http://code.google.com/p/test-analytics/) – инструмент, созданный в Google для упрощения ACC-анализа.

Test Analytics состоит из двух основных частей: первая часть – это пошаговый инструмент для создания матрицы ACC (рис. В.5). Он работает быстрее и проще электронных таблиц, которые мы использовали до этого (убедитесь, взглянув на рис. В.6). Наш инструмент визуализирует матрицу и риски, связанные с возможностями ACC, чем тоже не могли похвастаться обычные электронные таблицы (рис. В.7).

Рис. В.5. Определение атрибутов проекта в Test Analytics

Рис. В.6. Отображение возможностей проекта в Test Analytics

Рис. В.7. Отображение рисков в матрице атрибутов и компонентов в Test Analytics

Вторая часть Test Analytics превращает ACC-таблицу в живую, автоматически обновляемую матрицу рисков. Для этого Test Analytics импортирует из вашего проекта данные о качестве: баги, тест-кейсы, результаты тестов и изменения в коде. С этими данными риски становятся визуально понятными, основанными на количественных значениях, а не на догадках. Если некоторый компонент или возможность вашего проекта содержат многочисленные изменения в коде или открытые баги, то и риск в этой части выше. Проведенные тесты могут снизить риски. Если выполнить тесты и импортировать их результаты, показатели рисков в этой области снижаются по ходу тестирования.

Эта часть все еще остается экспериментальной. Мы пробуем разные способы вычисления риска по полученным результатам (см. рис. В.8). Тем не менее мы решили выпустить этот инструмент как можно раньше, чтобы узнать у сообщества, насколько хорошо наше решение подходит для команд тестировщиков. Мы хотим постоянно улучшать инструмент и делать его более полезным. Например, мы хотим импортировать больше информации о качестве: показатели сложности кода, результаты статического анализа кода, покрытие, обратная связь от внешних пользователей – это лишь часть идей, которые можно было бы включить в тест-план.

Рис. В.8. Test Analytics, привязанный к данным багов и тестовых примеров

Вы можете поэкспериментировать с живой версией продукта ( http://goo.gl/Cv2QB), посмотреть код ( http://code.google.com/p/test-analytics/) вместе с документацией ( http://code.google.com/p/test-analytics/wiki/AccExplained), и, конечно, мы будем рады вашим отзывам.

Для обсуждения продукта создана команда Google Group ( http://groups.google.com/group/test-analytics-discuss), в которой мы активно отвечаем на вопросы и обмениваемся впечатлениями по поводу использования Test Analytics.

Тест-план мертв, да здравствует тест-план!