Слияние 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 Capacitor,[58] так как она позволяла двигаться назад в будущее.
Ручные и исследовательские тесты в BITE
Мы в Google опробовали уйму способов распределения тестов между инженерами: от недружелюбного TestScribe до электронных таблиц совместного использования, где вручную вводились имена людей напротив тестов, которые они должны провести.
BITE поддерживает подписку тестировщиков на пакеты тестов в Google Test Case Manager для многих продуктов Google. Схема работы проста: когда тест-менеджер хочет начать серию тестов, он нажимает на кнопку на сервере BITE, и тесты доставляются участникам через пользовательский интерфейс BITE. К каждому тесту можно привязать URL-адрес. Если тестировщик принимает запрос на выполнение теста, BITE открывает URL-адрес в браузере и выводит тестовую страницу с последовательностью действий и критериями проверки. Всего одним кликом можно пометить тест как пройденный, после чего автоматически открывается URL-адрес для следующего теста. Если тест не проходит, это записывается в базу, и открывается интерфейс для создания баг-репорта.
Мы успешно опробовали этот метод на краудсорс-тестировщиках. Они выполняли тесты с установленным BITE, причем они и тесты получали через это приложение. Больше не нужно было пристально следить за работой тестировщиков и оперативно распределять между ними тесты — за нас все делал BITE. Те, кто быстро выполнял тесты, автоматически получали новые. Если тестировщик делал перерыв или прекращал работу, его задания просто передавались другому участнику команды. С исследовательским тестированием BITE тоже здорово помог: описание каждого высокоуровневого тура мы оформили как тест, после чего их распределили между тестировщиками, которые уже заводили баги с помощью BITE.
Как и любое приложение, внутренние проекты всегда нужно делать расширяемыми. В BITE есть возможность размещения произвольных сценариев и их внедрения в тестируемую страницу. То есть в архитектуре есть несколько логических уровней: один из них, к примеру, позволяет разработчику удалять элементы со страницы в поисках причины бага. Уровни могут включаться и отключаться со специальной консоли. Мы исследуем, какие еще полезные уровни можно добавить. Сейчас, например, мы работаем над включением сценариев от команды безопасности.
BITE был создан как универсальное средство помощи всем тестировщикам. Сначала его фичи были реализованы отдельными расширениями, но команда решила, что целое — это не просто совокупность частей, и мы потратили немало усилий на то, чтобы эффективно свести все воедино в BITE.
Как и в случае с другими экспериментами, команда надеется вскоре открыть доступ к проекту широкому сообществу тестирования.
Проект BITE был переведен на модель открытого кода (подробнее в приложении В). Первым техническим руководителем был Алексис О. Торрес; сейчас проектом руководит Джейсон Стредвик. С ним работают Джо Мухарски, По Ху, Дэниел Дрю, Джулия Ральф и Ричард Бастаманте, когда им удается выкроить минутку в своих текущих проектах. На момент написания книги некоторые внешние компании внедряли BITE в свою инфраструктуру. Сейчас мы работаем над добавлением поддержки Firefox и Internet Explorer.
Несмотря на то что анализ рисков нужен разработке как воздух, этот процесс часто происходит как попало. Если данным вообще удается покинуть головы участников команды, то часто они просто фиксируются в таблицах. Что в этом плохого?
— У данных нет единой схемы, потому что каждая таблица создается под конкретную ситуацию. Данные нельзя связать между собой, а это очень неудобно, если вы следите за несколькими проектами.
— Простые, но важные вещи, например четырехбалльная шкала оценки и общая схема названий из ACC-анализа, порой теряются при попытках сократить количество полей в таблицах.
— Данные не хранятся централизованно, поэтому недоступны всегда и всем. Командам приходится запрашивать друг у друга информацию устно при каждой необходимости.
— Разработка скриптов, которые связали бы анализ рисков с метриками продукта, обычно обходится дорого, поэтому редко сочетается с таблицами.
Google Test Analytics (GTA) — наша попытка решить эти проблемы. В интерфейс GTA встроены методы ACC-анализа, это простое приложение упрощает ввод данных и работу с рисками. Все данные представлены по одной схеме — менеджеры и директора могут легко получить сводку рисков по всем своим проектам, чтобы перераспределить ресурсы в более опасные области.
Итак, GTA поддерживает модель анализа рисков ACC. Атрибуты и компоненты вводятся в простые формы и формируют таблицы (рис. 3.42 и 3.43), а интерфейс позволяет добавлять возможности в ячейки при планировании тестирования (рис. 3.44). Чтобы добавить риск, нужно просто выбрать частоту и степень воздействия из выпадающих списков для каждой возможности. Все эти значения сводятся в общую витрину рисков. Итоговый риск для каждой области (рис. 3.45) считается простым усреднением рисков по ней.[59]
Рис. 3.42. Test Analytics: ввод атрибутов для Google+
Рис. 3.43. Test Analytics: ввод компонентов для Google+
Рис. 3.44. Test Analytics: ввод возможностей в ячейке. Обратите внимание: вводится количество возможностей на пересечении, а не величина риска
Рис. 3.45. Test Analytics: карта рисков для Google+
Возможность связать расчет рисков с текущими данными проекта — это опциональная экспериментальная возможность GTA. Вы добавляете новые тесты, пишете новый код, находите новые дефекты, и оценка риска меняется. Как инженеры по тестированию, мы и так всегда держали все эти изменения в голове, эта фича просто позволяет опираться на фактические данные и делать это более системно. Тест-планы, даже основанные на рисках ACC, часто хороши в начале планирования тестирования. Но скоро они могут устареть и покрыться пылью. Хотя в GTA всегда можно внести любые изменения при получении любых новых данных, мы хотим автоматизировать и эту сторону планирования тестирования.
