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

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

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

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

Эксперимент с Quality Bots

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

Завершив множество проектов по тестированию в Google и поговорив со многими командами, мы осознали, что блестящие умы наших инженеров часто растрачиваются на ручное построение и выполнение регрессионных тестов. Поддерживать автоматизированные тестовые сценарии и вручную проводить регрессионное тестирование – дорогое удовольствие. К тому же медленное. Добавляет масла в огонь то, что мы проверяем ожидаемое поведение, – а как же неожиданное?

Регрессионные тесты обычно проходят без ошибок в более чем 95% случаев. Скорее всего, так происходит потому, что практика разработки в Google заточена на качество. Но, что важно, эта рутинная работа притупляет способности инженеров, которых мы нанимали вообще-то за любознательность и изобретательность. Мы хотим освободить наших ребят для более сложного, исследовательского тестирования, для которого, собственно, мы их и брали в команду.

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

1. Обход.Боты работают в вебе [48]48
  Самые приоритетные обходы выполняются на виртуальных машинах Skytap.com. Это мощная сеть виртуальных машин. Она позволяет разработчику напрямую связаться с той машиной, на которой произошел сбой, и управлять отладкой, даже не выходя из браузера. Время и внимание намного ценнее вычислительных процессов. Skytap позволяет ботам работать полностью на сторонних виртуальных машинах и аккаунтах, открывая им доступ к непубличным промежуточным серверам.


[Закрыть]прямо сейчас. Тысячи виртуальных машин, вооруженные скриптами WebDriver, открывают в основных браузерах популярные URL-адреса. Перепрыгивая от одного URL-адреса к другому, словно обезьянки с лианы на лиану, они анализируют структуру веб-страниц, на которые приземляются. Они строят карту, которая показывает, какие элементы HTML отображаются, где и как.

2. Индексирование.Боты передают сырые данные серверам индексирования, где информация упорядочивается по типу браузера и времени обхода. Формируется статистика о различиях между обходами, например количество обойденных страниц.

3. Ранжирование.Когда инженер хочет посмотреть результаты для конкретной страницы по разным обходам или результаты всех страниц для одного браузера, система ранжирования вычисляет оценку качества. Проще говоря, система оценивает сходство страниц в процентах: 100% означает, что страницы идентичны. Соответственно, чем меньше процент сходства, тем больше различий.

4. Результаты.На информационной панели можно посмотреть сводку результатов (рис. 3.27). Подробные результаты строятся в виде простой таблицы оценок для каждой страницы с указанием сходства в процентах (рис. 3.28 и 3.29). Для каждого результата инженер может копнуть глубже и получить информацию о визуальных различиях. Они показаны с помощью наложения результатов разных проходов с указанием XPath-путей [49]49
  Пути XPath похожи на пути к файлам, но используются в веб-страницах, а не в файловых системах. Они идентифицируют отношения «родитель/потомок» и другие сведения, однозначно определяющие элемент в DOM-древе веб-страницы. См.: http://ru.wikipedia.org/wiki/Xpath


[Закрыть]элементов и их позиций (рис. 3.30). Инструмент показывает средние минимальные и максимальные исторические показатели этого URL-адреса и другую подобную информацию.

Рис. 3.27. Сводка информации для разных сборок Chrome

Рис. 3.28. Типичная таблица с подробной информацией от ботов

Рис. 3.29. Таблица информации от ботов, отсортированная для выявления наибольших различий

Рис. 3.30. Анализ визуальных различий для идентичных страниц

Первый же официальный запуск проекта нашел различие между двумя канареечными сборками Chrome. Боты провели проверку автоматически. Тестировщик оценил результаты и заметил, что этот URL-адрес потерял несколько процентов сходства. Тестировщик быстро сообщил о проблеме, ссылаясь на подробную картинку (рис. 3.31) с выделенной частью страницы с различиями. Раз боты могли протестировать все версии Chrome, [50]50
  Сборки Chrome появляются несколько раз в день.


[Закрыть]инженер мог быстро справляться с новыми регрессионными багами. Каждая сборка содержала всего несколько изменений, и заливку с проблемным кодом оперативно изолировали. Оказалось, что коммит [51]51
  О том, что вызвало эту регрессию, можно узнать по URL-адресу http://trac.webkit.org/changeset/81691


[Закрыть]в репозиторий WebKit (ошибка 56859: reduce float iteration in logicalLeft/RightOffsetForLine) вызвал регрессионный баг, [52]52
  URL-адрес проблемы WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=56859. Адрес ошибки в Chromium: http://code.google.com/p/chromium/issues/detail?id=77261


[Закрыть]из-за которого средний элемент div на этой странице стал отображаться ниже границы страницы. Тестировшик завел баг 77261: Макет страницы ezinearticles.com неправильно отображается в Chrome 12.0.712.0.

Рис. 3.31. Первый баг, обнаруженный при первом запуске ботов

Как мы прогнозировали (и надеялись), данные от ботов оказались очень похожи на данные, получаемые от их одушевленных аналогов, и во многом даже лучше. Большинство веб-страниц оказывались идентичными в разных версиях браузеров, и даже если находилось различие, инженер быстро просматривал его и понимал, есть ли что-то серьезное.

Машины теперь могли автоматически подтвердить отсутствие регрессионных багов. Это маленький шаг для машины, но огромный для всего мира тестировщиков – им больше не нужно пробираться через тернии не самых интересных страниц. Тесты теперь можно прогонять за минуты, а не за несколько дней, как раньше. Их можно проводить ежедневно, а не еженедельно. У тестировщиков наконец освободились руки и время и стало возможным заняться багами посложнее.

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

А как насчет веб-сайтов, управляемых данными? Возьмем, например, сайты YouTube и CNN – их контент огромен и изменяется со временем. Не запутаются ли боты? Они справятся, если будут предупреждены о нормальных колебаниях данных этого сайта. Например, если в нескольких последовательных сериях изменился только текст статьи и картинки, то боты посчитают изменения уместными для данного сайта. Если показатели выйдут за рамки (допустим, при нарушении IFRAME или при переходе сайта на другой макет), боты могут подать сигнал тревоги и сообщить об этом веб-разработчику, чтобы он определил, нормально ли новое состояние или пора заводить соответствующий баг. Пример небольшого шума можно увидеть на рис. 3.32: на сайте CNET есть реклама, которая во время проверки

Рис. 3.32. Анализ визуальных различий для страниц с шумовыми различиями

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

А что происходит дальше со всеми этими сигналами? Должен ли тестировщик или разработчик просматривать их все? На самом деле нет, мы уже ведем эксперименты по прямой передаче информации о различиях краудсорс-тестировщикам, [53]53
  Наши друзья из http://www.utest.com помогли в организации этих экспериментов. Тестировщики из этого сообщества чрезвычайно наблюдательны и отзывчивы. Иногда они находили больше ошибок, чем внутренние многократные запуски регрессионных тестов.


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

Как мы получаем данные от сообщества? Гениальное – просто: мы построили инфраструктуру, которая транслирует необработанные данные ботов на обычную страницу голосования для тестировщиков. Разумеется, мы сравнивали работу краудсорсеров со стандартными методами ручного рецензирования. Схема была следующая: боты пометили только шесть URL-адресов как требующие дополнительной проверки. Помеченные URL-адреса получили тестировщики из сообщества. Имея в арсенале данные ботов и инструменты визуализации различий, краудсорсеры определяли, ошибка ли это, в среднем за 18 секунд. А проверка всех 150 URL-адресов на регрессию ручными методами заняла около трех дней. Тестировщики из сообщества успешно определили все шесть различий как несущественные. Результаты работы краудсорсеров и ручной затратной формы проверки совпали! А зачем платить больше?

Звучит здорово! Правда, этот метод подходит только для статических версий веб-страниц. А как насчет интерактивных элементов – раскрывающихся меню, тестовых полей и кнопок? Мы ведем работу по решению этой проблемы, можно сказать, мы открыли киностудию: боты автоматически взаимодействуют с интересующими нас частями веб-страницы и снимают на каждом шаге кадр DOM. Затем «фильмы» каждой серии сравниваются покадрово с помощью той же технологии анализа различий.

В Google некоторые команды уже заменили большую часть своей ручной работы по регрессионному тестированию ботами. У них появилось время для более интересной работы, например исследовательского тестирования, которой они не могли заниматься раньше. Команда поставила себе цель сделать сервис общедоступным, выложить исходный код для всех и добавить возможности собственного хостинга, чтобы команды могли тестировать внутри своей сети, если кто-то не хочет открывать свои URL-адреса наружу. Мы не торопимся с массовым внедрением новой технологии – нужно убедиться в ее стопроцентной надежности.

Базовый код проекта Bots работает в инфраструктурах Skytap и Amazon EC2. Код сервиса распространяется по модели открытого кода (подробнее в блоге тестирования Google и приложении В). Теджас Шах был техническим руководителем Bots с первых дней существования проекта; позднее к нему присоединились Эриэл Томас, Джо Михаил и Ричард Бустаманте. Присоединяйтесь и вы к этим ребятам, чтобы двигать эксперимент дальше!

Как оценить качество всего интернета

Чтобы измерить, насколько хорошо поисковая система справляется с запросами, для теста мы берем случайную репрезентативную выборку поисковых запросов. По результатам можно судить, как система будет работать со всеми запросами, – мы просто экстраполируем данные. А если мы используем Bots на репрезентативной выборке URL-адресов, мы можем судить о качестве интернета в целом.

Сингулярность: [54]54
  Термин «сингулярность» часто используется для описания момента, в который компьютеры превзойдут человеческий интеллект. Это будет интересное время, и мы уже сегодня видим его приближение (http://en.wikipedia.org/wiki/Technological_singularity).


[Закрыть]легенда о происхождении ботов
Джейсон Арбон

Давным-давно, в далеком-далеком офисе Google родилась… первая версия Chrome. Уже по первым поступившим данным было понятно, что Chrome отображает веб-страницы иначе, чем Firefox. В начале мы оценивали эти различия, только отслеживая объем поступающих сообщений о багах и подсчитывая количество жалоб на проблемы совместимости от пользователей, которые удаляли браузер после пробного использования.

Мне было интересно, есть ли более многоразовый, автоматизированный и объективный метод оценки того, насколько хорошо мы работаем в этой области. Были ребята до меня, которые пытались организовать автоматическое сравнение снимков веб-страниц между браузерами, а кто-то даже пытался использовать продвинутые методы распознавания изображений и границ. Правда, эти методы часто не работали, потому что между страницами всегда много различий, вспомните хотя бы о разных картинках в рекламе, меняющемся контенте и т.д. В базовых тестах макетов WebKit вычислялся хэш-код всего макета страницы (см. рис. 3.33). Поэтому когда обнаруживалась проблема, инженеры не имели понятия о том, что именно в приложении не работает, у них был только снимок ошибки. Многочисленные ложноположительные [55]55
  Ложноположительными (false positives) называются сбои тестирования, вызванные не ошибками самого продукта, а ошибками тестового программного обеспечения. Обычно такие сбои обходятся дорого, раздражают инженеров и быстро снижают производительность их труда из-за безрезультатных исследований.


[Закрыть]срабатывания только прибавляли работы инженерам, вместо того чтобы уменьшать ее.

Рис. 3.33. В ранних средствах тестирования макетов WebKit использовались хэши всего макета страницы. Теперь мы можем тестировать целые страницы и обнаруживать сбои на уровне элементов, а не на уровне страницы

Мысли постоянно возвращали меня к ранней простой реализации ChromeBot, которая обходила миллионы URL-адресов в запущенных копиях браузера Chrome на тысячах виртуальных машин. Она искала всевозможные сбои, используя для этого свободное процессорное время в центрах обработки данных. Это был ценный инструмент, который находил баги на ранней стадии, а функциональное тестирование взаимодействия с браузером добавлялось позже. К сожалению, технология утратила свою новизну и использовалась только для выявления редких сбоев. А что, если построить более серьезную версию этого инструмента, которая будет нырять во всю страницу целиком, а не только ходить по берегу? И назвать ее, например, Bots.

Я подумал об использовании другого подхода: работы в DOM. [56]56
  DOM (Document Object Model) – внутреннее представление всего кода HTML, образующего веб-страницу. Модель DOM содержит все маленькие объекты, представляющие кнопки, текстовые поля, изображения и т.д.


[Закрыть]Около недели ушло на подготовку эксперимента, в котором загружалось много веб-страниц одна за другой, а потом в них внедрялся код JavaScript, который извлекал карту внутренней структуры веб-страницы.

Многие умные люди скептически отнеслись к этому решению. Они считали, что моя идея была обречена на неудачу, потому что:

– реклама постоянно изменяется;

– контент на таких сайтах, как CNN.com, постоянно меняется;

– специфичный для конкретного браузера код будет по-разному отображаться в разных браузерах;

– баги в самих браузерах будут приводить к возникновению различий;

– работа потребует огромных объемов данных.

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

Чтобы запустить эксперимент, мне нужны были контрольные данные, с которыми я мог бы сравнивать полученные. Лучшим источником информации были тестировщики проекта Chrome, ведь они каждый день вручную открывали около 500 популярных сайтов в Chrome, пытаясь найти различия с Firefox. Я поговорил с подрядчиками, которые прогоняли вручную все эти сайты и сравнивали результаты с Firefox. Они рассказали, что сначала проблемы находились почти в половине популярных сайтов, но ситуация постепенно улучшалась, и сейчас расхождения встречаются редко – менее чем в 5% сайтов.

Я взял WebDriver (Selenium следующего поколения) и провел эксперимент. WebDriver лучше поддерживал Chrome, и его API куда более понятный. В первый прогон я собрал данные в разных версиях Chrome, от ранних до текущей, чтобы увидеть, найдет ли автоматизация такой же тренд. Тесты просто загружали те же веб-сайты, проверяли каждый пиксель, определяли, какой элемент HTML (не RGB-значение!) был видим в этой точке, [57]57
  getElementFromPoint(x,y) возвращал хэш элементов для секции веб-страницы размером 800 1000. С задачей можно было справиться более эффективно, но это решение было простым и хорошо иллюстрировало проблему.


[Закрыть]а потом отправляли данные на сервер. Выполнение на моем компьютере занимало около 12 часов, поэтому я запустил программу на ночь.

Полученные данные выглядели хорошо, поэтому я заменил Firefox на Chrome и снова запустил те же тесты на ночь. Конечно, мог появиться шум от изменения контента сайтов, но моя задача была только узнать, как выглядят данные, а потом выполнить обе серии параллельно. Когда я пришел утром в офис, я обнаружил, что мой компьютер выдернут из розетки. Мои соседи странно посматривали в мою сторону и сказали, что мне нужно поговорить со специалистами по безопасности. Я мог только догадываться, что они себе надумали. Оказалось, что во время обхода мой компьютер подхватил вирус с неизвестной сигнатурой, который и разбушевался ночью. Меня спросили, хочу ли я снять данные со своего компьютера, прежде чем диск будет уничтожен. К счастью, все мои данные хранились в облаке, и я отпустил свой компьютер с миром. После этого я стал запускать такие тесты только с внешних виртуальных машин.

За двое суток машины независимо выдали данные, которые были ужасно похожи на те, что мы получили примерно за год ручной тестовой работы (см. рис. 3.34). Подозрительно похожи.

Рис. 3.34. Первые данные, демонстрирующие сходство между метриками количества, вычисленными людьми и ботами

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

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

Bots: детство, отрочество и масштабирование на весь интернет
Теджас Шах

Я – технический руководитель проекта Bots, я хочу масштабировать технологии Bots на весь интернет и открыть их миру. Проект Bots вырос из ранних экспериментов в полноценную технологию, которую используют многие команды в Google.

В конце 2010 года я работал над средой автоматизации для Chrome, известной как SiteCompact. Она использовала тесты JavaScript, чтобы автоматически находить функциональные баги в Chrome при просмотре популярных сайтов. Она проверяла как поиск на google.com, так и отображение статей на CNN почти для всех сборок Chrome. Система работала на «отлично», выявляла регрессионные баги и дополняла автоматизированные функциональные проверки поведения сайтов.

В то же время интерны Джейсона работали над демоверсией крутейшего проекта Bots. Я присматривал за ходом дела, но когда они продемонстрировали результаты, мои представления о том, как следует проверять сайты, изменились навсегда. Увидев демоверсию ботов, созданную Еленой, с первыми данными, я был покорен. Я понял, что передо мной возможность фундаментального изменения подхода к веб-тестированию. Мои скриптовые тесты, конечно, были важны, но они масштабировались только линейно, и их нужно было сопровождать. А проект Bots содержал в себе что-то более универсальное. Я сразу влюбился в эту технологию. Практиканты ушли, и все знали, что их код был только демонстрацией. Чтобы сделать его частью базовой инфраструктуры и решением, пригодным для веба, нужно было еще много работать.

Первые несколько месяцев я работал над Bots один. Я хотел избежать лишних вопросов и скептицизма. Но я верил, что есть тот, кто справится с задачей.

Какое-то время я работал в одиночку, избегая вопросов и скептических взглядов. Это продолжалось около квартала. Я проделал большую работу, решая задачи масштабирования, производительности, методов оценки и удобства использования страниц с различиями – пока все фрагменты не начнут работать как единое целое, пользы от системы не будет. Трудно решать такую задачу в одиночку, тем более зная, что работа над таким неоднозначным проектом – это риск для твоей карьеры. Если ничего не выйдет – тебе нечего будет показать. Google поощряет эксперименты, но хочет видеть результаты. Мое место в структуре Google ограждало меня от скептических вопросов во время аттестации, пока я работал над этим долгосрочным проектом.

Потом мы представили первую демоверсию руководителю разработки Chrome. Идея настолько захватила его, что он включил результаты Bots в повседневную работу по тестированию Chrome. Это признание сыграло важную для меня роль и придало мне уверенности, чтобы продолжать работу. А еще я понял, что если Chrome может использовать нашу систему, чтобы обнаруживать сложные проблемы, значит то же самое может делать любое веб-приложение.

Сразу же после этого мы провели презентации во многих командах Google. Каждый, кому мы показывали Bots, хотел использовать эту систему. Мы убеждались в реальности нашей мечты об использовании этой технологии во всех веб-приложениях. Поработав над ней еще несколько месяцев, я смог построить графики и трендов и результатов для канареечной сборки Chrome. Теперь Bots не только работала как система раннего оповещения, но и обнаруживала реальные баги на ранней стадии цикла. Система предоставляла куда более точные данные о сбоях, так что разработчики могли принимать решения на основе точных фактов. Мой любимый баг нашла первая боевая версия Bots, сравнив две сборки в один день. Bots обнаружила баг через несколько часов после того, как разработчик из Apple изменил атрибут WebKit. Фича была покрыта юнит-тестами, но только технология Bots смогла поймать этот баг, потому что тестировала реально существующие веб-страницы.

После презентации мою команду часто спрашивали: «Смогу ли я отказаться от ручного тестирования?» Наш ответ – твердое «нет». Тестировщики теперь могут выполнять работу, для которой их нанимали: исследовательское тестирование, анализ рисков и интересов пользователя.

Успех в Chrome привлек ресурсы в наш проект. Теперь у нас была пара инженеров, которые активно работали над Bots и помогали нам поднять продукт на следующий уровень. Тогда же нас попросили помочь команде поиска, которая находилась в процессе выпуска новой классной фичи Instant Pages. Мы потратили на Instant Pages еще несколько недель, – нужно было научить систему запускать Chrome в разных режимах. Мы написали специальную серию тестов Bots, и теперь разработчики могли спокойно выпускать свой продукт, ведь они знали, что те же тесты пройдут автоматически для любых изменений, которые они внесут в будущем.

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