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

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

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

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

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

Первый же официальный запуск проекта нашел различие между двумя канареечными сборками Chrome. Боты провели проверку автоматически. Тестировщик оценил результаты и заметил, что этот URL-адрес потерял несколько процентов сходства. Тестировщик быстро сообщил о проблеме, ссылаясь на подробную картинку (рис. 3.31) с выделенной частью страницы с различиями. Раз боты могли протестировать все версии Chrome50, инженер мог быстро справляться с новыми регрессионными багами. Каждая сборка содержала всего несколько изменений, и заливку с проблемным кодом оперативно изолировали. Оказалось, что коммит51 в репозиторий WebKit (ошибка 56859: reduce float iteration in logicalLeft/RightOffsetForLine) вызвал регрессионный баг52, из-за которого средний элемент div на этой странице стал отображаться ниже границы страницы. Тестировшик завел баг 77261: Макет страницы ezinearticles.com неправильно отображается в Chrome 12.0.712.0.

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

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

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

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

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

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

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