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

Рисунок 3.39 показывает, как выглядит страница карты с наложенной панелью багов BITE. Один клик на номер бага откроет полную страницу отчета в Buganizer или Issue Tracker. На рис. 3.40 показана панель багов на странице YouTube.

Запись и воспроизведение сценариев в BITE

Тестировщики и разработчики в тестировании трятят значительную часть своего рабочего времени на автоматизацию больших, сквозных регрессионных тест-кейсов. Именно эти тесты показывают, могут ли все части продукта работать слаженно на благо конечного пользователя. Подавляющее большинство таких тестов пишется на Java с использованием Selenium для управления браузером и хранения логики тест-кейсов. Но у этого подхода есть недостатки.

— Трудности перевода.Логика теста пишется на одном языке, а выполняемое приложение на другом (Java вместо JavaScript). Разработчики и тестировщики в Google часто жалуются на эту разницу, потому что она значительно замедляет отладку, и не каждый инженер хочет учить дополнительный язык.

— Место жительства.Код тестов живет за пределами браузера, поэтому приходится делать дополнительный шаг для сборки и развертывания тестовых бинарных файлов на компьютерах. Централизованная инфраструктура автоматизации тестирования Matrix, к сожалению, не решает проблему полностью.

— Окружающая среда. Тестировщик работает в установленной локально среде разработки, отделенной от браузера и настроенной только для тестируемого проекта.

— Потерянное время.Тестировщики тратят много времени на постоянное переключение между страницей приложения и средой Eclipse. Они ищут XPath-пути нужных элементов, а потом вручную добавляют их в Java-код. Потом сборка, запуск, проверка работоспособности. Все это требует времени и достаточно утомительно.

— Ничто не вечно.Веб-приложения Google часто меняют свою модель DOM. Это значит, что тест-кейсы падают при каждом изменении положения элемента на странице или его атрибутов. Поэтому команды сначала тратят много времени на сопровождение тестов, а потом и вовсе игнорируют полученные результаты из-за обилия ложноположительных срабатываний.

Мы придумали веб-решение этих проблем: Record and Playback Framework (RPF) на основе JavaScript, а еще мы серьезно поработали над хранением сценариев тест-кейсов в облаке. Это решение отлично работает и в Chrome OS, которая не поддерживает выполнение тест-кейсов Selenium или WebDriver.

Чтобы записать тест, просто нажмите Record and Playback в BITE-меню в браузере. На экране появится окно записи, в котором запишутся все операции мышкой в основном окне браузера. Клик правой кнопкой мыши на любом элементе запустит режим проверки, в котором можно проверить конкретную строку, картинку, значение конкретного элемента. Можно даже проверить относительную позицию элемента на странице. Это полезно при работе с YouTube: не всегда известно, где именно будет располагаться видео на домашней странице, но общий макет страницы мы знаем.

Самый главный плюс метода RPF в том, что он избавляет инженера по тестированию от хлопотного просмотра модели DOM приложения и пересчетов путей XPath, когда элементы меняются. Мы вложили много усилий в написание кода, который останавливает тест. Если элемент не найден в процессе воспроизведения, код сделает паузу, чтобы тестировщик выбрал новый элемент, автоматически обновит скрипт и продолжит работу. Еще мы реализовали так называемое «ленивое выполнение»: вместо того чтобы придирчиво проверять, соответствует ли элемент ожидаемому XPath, RPF проверяет все атрибуты элемента HTML, в том числе и его родительские и дочерние элементы в DOM. Во время воспроизведения RPF сначала ищет точное совпадение. Если не находит, начинает искать максимально похожие элементы. Может быть, например, изменился только ID, а все остальное осталось прежним. Точность совпадений поиска настраивается. Если различие в пределах допустимого, тест переходит к следующему шагу и просто записывает предупреждение в логи. Мы надеялись, что этот метод сэкономит много времени разработки.

Первой RPF опробовала команда тестирования Chrome Web Store. RPF успешно отработал в 90% тестовых сценариев. Проблемы возникли только с диалоговыми окнами загрузки файлов, которые по сути — встроенные окна ОС, а не браузера, и с некоторыми функциями Google Checkout: нельзя автоматизировать финансовые сценарии через Web API из-за безопасности. Правда, тестировщиков не сильно захватила идея «ленивого» поиска совпадений или возможность поставить работу на паузу для исправления. Им было проще и быстрее переписать тест с нуля. Все тесты мы поначалу разрабатывали параллельно на два фронта, для WebDriver и для RPF. Оказалось, что RPF в семь раз эффективнее для генерации и сопровождения тестов, чем Selenium или WebDriver. Показатели могли меняться, но это уже был хороший признак.