Как тестируют в Google

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

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

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

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

Сингулярность: [54] легенда о происхождении ботов Джейсон Арбон

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

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

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

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

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

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

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

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

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

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

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

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