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

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

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

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

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

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

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

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

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

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

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

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

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

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

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