Как тестируют в Google
Шрифт:
Самый главный плюс метода RPF в том, что он избавляет инженера по тестированию от хлопотного просмотра модели DOM приложения и пересчетов путей XPath, когда элементы меняются. Мы вложили много усилий в написание кода, который останавливает тест. Если элемент не найден в процессе воспроизведения, код сделает паузу, чтобы тестировщик выбрал новый элемент, автоматически обновит скрипт и продолжит работу. Еще мы реализовали так называемое «ленивое выполнение»: вместо того чтобы придирчиво проверять, соответствует ли элемент ожидаемому XPath, RPF проверяет все атрибуты элемента HTML, в том числе и его родительские и дочерние элементы в DOM. Во время воспроизведения RPF сначала ищет точное совпадение. Если
Первой RPF опробовала команда тестирования Chrome Web Store. RPF успешно отработал в 90% тестовых сценариев. Проблемы возникли только с диалоговыми окнами загрузки файлов, которые по сути — встроенные окна ОС, а не браузера, и с некоторыми функциями Google Checkout: нельзя автоматизировать финансовые сценарии через Web API из-за безопасности. Правда, тестировщиков не сильно захватила идея «ленивого» поиска совпадений или возможность поставить работу на паузу для исправления. Им было проще и быстрее переписать тест с нуля. Все тесты мы поначалу разрабатывали параллельно на два фронта, для WebDriver и для RPF. Оказалось, что RPF в семь раз эффективнее для генерации и сопровождения тестов, чем Selenium или WebDriver. Показатели могли меняться, но это уже был хороший признак.
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 часто говорят, что «дефицит приносит ясность». Это работает в мире тестирования, как нигде больше. Это сработало и для нас в тот момент. Хорошенько оценив ситуацию, мы поняли, что решение было так себе. По сути, мы не тестировали реальный продукт в том виде, в котором им будет пользоваться наш
Рис. 3.41. Лаборатория тестирования ранних версий Chrome OS
Вскоре нужное решение пришло. Мы вспомнили про проект нашего коллеги По Ху по автоматизации тестирования веб-страниц с использованием JavaScript через расширения Chrome. Это могло сработать. Он назывался Puppet, и это был внутренний API, похожий на WebDriver и работающий только на JavaScript. Правда, из-за межсайтовых ограничений он должен был развертываться вместе с тестируемым веб-приложением. Мы рискнули поместить сценарий Puppet в расширение Chrome, чтобы оно работало для любых сайтов. И — о чудо! — установив только это расширение и сохранив тесты в облаке, мы смогли выполнять браузерные тесты в Chrome OS даже на компьютере Chromebook, только что купленном в магазине. Реализация этой идеи заняла бы у нас больше времени, чем у нас было до выпуска Chrome версии 1, и мы подвинули этот проект в список инструментов, которые нужно разработать к следующей версии.
Кстати, исходная версия BITE называлась Web Test Framework, или WTF, и нам сошло это с рук. Официально считалось, что сокращение происходит от названия, а не наоборот. А вот метод RPF изначально назывался Flux Capacitor, [58] так как она позволяла двигаться назад в будущее.
Ручные и исследовательские тесты в BITE
Мы в Google опробовали уйму способов распределения тестов между инженерами: от недружелюбного TestScribe до электронных таблиц совместного использования, где вручную вводились имена людей напротив тестов, которые они должны провести.
58
Деталь машины времени из фильма «Назад в будущее». — Примеч. перев.
BITE поддерживает подписку тестировщиков на пакеты тестов в Google Test Case Manager для многих продуктов Google. Схема работы проста: когда тест-менеджер хочет начать серию тестов, он нажимает на кнопку на сервере BITE, и тесты доставляются участникам через пользовательский интерфейс BITE. К каждому тесту можно привязать URL-адрес. Если тестировщик принимает запрос на выполнение теста, BITE открывает URL-адрес в браузере и выводит тестовую страницу с последовательностью действий и критериями проверки. Всего одним кликом можно пометить тест как пройденный, после чего автоматически открывается URL-адрес для следующего теста. Если тест не проходит, это записывается в базу, и открывается интерфейс для создания баг-репорта.
Мы успешно опробовали этот метод на краудсорс-тестировщиках. Они выполняли тесты с установленным BITE, причем они и тесты получали через это приложение. Больше не нужно было пристально следить за работой тестировщиков и оперативно распределять между ними тесты — за нас все делал BITE. Те, кто быстро выполнял тесты, автоматически получали новые. Если тестировщик делал перерыв или прекращал работу, его задания просто передавались другому участнику команды. С исследовательским тестированием BITE тоже здорово помог: описание каждого высокоуровневого тура мы оформили как тест, после чего их распределили между тестировщиками, которые уже заводили баги с помощью BITE.