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

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

Слияние BITE с RPF

Джеймс Арбон

В первые дни тестирования Chrome OS мы обнаружили, что главное качество платформы — безопасность — сильно осложняет тестирование. Тестируемость часто конфликтует с безопасностью, а ведь в Chrome OS очень большой упор сделан именно на безопасность.

В ранних сборках еще была частичная поддержка виртуальных Java-машин (JVM) с ограниченной сетевой функциональностью и поддержкой других базовых библиотек. Так как основные сценарии пользователя основаны на просмотре веб-страниц, мы решили написать несколько тестов с использованием Selenium, чтобы проверить базовую функциональность браузера, и надеялись, что получится просто портировать все уже готовые тесты Selenium для регрессионного тестирования.

Простейшие тесты заработали, но радоваться было рано: мы столкнулись с отсутствием полноценной поддержки Chrome в Selenium и WebDriver. Вернувшись к работе после праздников, мы обнаружили, что из базовой ОС Linux исключили поддержку Java, чтобы повысить уровень безопасности Chrome OS. Конечно, это осложнило выполнение тестов на Java, но мы решили проблему, построив специальную сборку Chrome OS с встроенной поддержкой Java. Это, конечно, было обходное решение, и мы не были им довольны на все сто.

В Google часто говорят, что «дефицит приносит ясность». Это работает в мире тестирования, как нигде больше. Это сработало и для нас в тот момент. Хорошенько оценив ситуацию, мы поняли, что решение было так себе. По сути, мы не тестировали реальный продукт в том виде, в котором им будет пользоваться наш клиент. Мы строили образы Chrome OS, которые содержали Java, артефакты тестирования (jar-файлы), и отключали некоторые средства безопасности. Посмотрите на фотографию нашей лаборатории автоматизации тестирования ранних версий Chrome OS (рис. 3.41).

Рис. 3.41. Лаборатория тестирования ранних версий Chrome OS

Вскоре нужное решение пришло. Мы вспомнили про проект нашего коллеги По Ху по автоматизации тестирования веб-страниц с использованием JavaScript через расширения Chrome. Это могло сработать. Он назывался Puppet, и это был внутренний API, похожий на WebDriver и работающий только на JavaScript. Правда, из-за межсайтовых ограничений он должен был развертываться вместе с тестируемым веб-приложением. Мы рискнули поместить сценарий Puppet в расширение Chrome, чтобы оно работало для любых сайтов. И — о чудо! — установив только это расширение и сохранив тесты в облаке, мы смогли выполнять браузерные тесты в Chrome OS даже на компьютере Chromebook, только что купленном в магазине. Реализация этой идеи заняла бы у нас больше времени, чем у нас было до выпуска Chrome версии 1, и мы подвинули этот проект в список инструментов, которые нужно разработать к следующей версии.

Кстати, исходная версия BITE называлась Web Test Framework, или WTF, и нам сошло это с рук. Официально считалось, что сокращение происходит от названия, а не наоборот. А вот метод RPF изначально назывался Flux Capacitor58, так как она позволяла двигаться назад в будущее.

Ручные и исследовательские тесты в BITE

Мы в Google опробовали уйму способов распределения тестов между инженерами: от недружелюбного TestScribe до электронных таблиц совместного использования, где вручную вводились имена людей напротив тестов, которые они должны провести.

BITE поддерживает подписку тестировщиков на пакеты тестов в Google Test Case Manager для многих продуктов Google. Схема работы проста: когда тест-менеджер хочет начать серию тестов, он нажимает на кнопку на сервере BITE, и тесты доставляются участникам через пользовательский интерфейс BITE. К каждому тесту можно привязать URL-адрес. Если тестировщик принимает запрос на выполнение теста, BITE открывает URL-адрес в браузере и выводит тестовую страницу с последовательностью действий и критериями проверки. Всего одним кликом можно пометить тест как пройденный, после чего автоматически открывается URL-адрес для следующего теста. Если тест не проходит, это записывается в базу, и открывается интерфейс для создания баг-репорта.