KnigaRead.com/
KnigaRead.com » Разная литература » Прочее » Уиттакер . - Как тестируют в Google

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

На нашем сайте KnigaRead.com Вы можете абсолютно бесплатно читать книгу онлайн Уиттакер ., "Как тестируют в Google" бесплатно, без регистрации.
Перейти на страницу:

— Ручные тест-кейсы Chrome OS. Выполняются все ручные тест-кейсы Chrome OS. Можно распределить их среди тестировщиков с разным оборудованием.

Ручное и автоматизированное тестирование

Ручное тестирование необходимо. Оно особенно важно на ранней стадии проекта, когда пользовательский интерфейс и другие фичи уже быстро развиваются, а работа по улучшению тестируемости и автоматизации только началась. Chrome OS делает ставку на простоту и интуитивную понятность своего интерфейса, поэтому ручное тестирование проводить обязательно. Машины до сих пор не умеют это тестировать.

Автоматизация — залог долгосрочного успеха и результативности тестовой команды и защита от регрессионных багов. Так как автоматизация встроена в браузер, бˆольшая часть ручных тестов (да здравствует продуктивность!) тоже автоматизируется.

Разработка и качество тестов

Команда разработчиков больше других групп по количеству людей и обладает гораздо большим знанием о компонентах и технических подробностях списков изменений. Мы хотим, чтобы разработчики обеспечивали полный набор модульных и узконаправленных системных тестов с помощью Autotest.

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

Каналы выпуска

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

Обратная связь

Отзывы пользователей очень важны для проекта. Нужно вложиться в то, чтобы им было предельно просто отправить нам обратную связь. И не забыть о том, что нам нужно будет обрабатывать данные.

— Расширение GoogleFeedback. Чтобы отправить сообщение, пользователи могут легко выделить и отправить ошибку для любого URL-адреса. Расширение группирует полученные от пользователей данные и выводит их на информационную панель для анализа. Команда тестирования приложит усилия, чтобы GoogleFeedback был интегрирован в Chrome OS, и расширит его отчетность на ChromeUX.

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

Команда тестирования будет настойчиво продвигать настройку такой системы, в том числе и для нестандартных конфигураций.

Репозитории тест-кейсов

Ручные: все ручные тест-кейсы хранятся в TestScribe. Идет работа над созданием репозитория тест-кейсов для code.google.com.

— Автоматизированные: все автоматизированные тест-кейсы находятся в хранилище кода в формате Autotest. Все тесты версионизированы, доступны и располагаются рядом с тестируемым кодом.

Панели мониторинга тестов

Нужно будет быстро обрабатывать и распространять большой объем данных, поэтому команда тестирования возьмет на себя создание специальных информационных панелей для метрик качества. Это позволит командам быстро получать высокоуровневые данные: индикаторы качества (зеленые/красные сигналы о прохождениях или падениях тестов), общие результаты ручного и автоматизированного тестирования. Если нужно — можно будет копнуть глубже и получить детальную информацию о багах.

Виртуализация

Очень важно, особенно на ранней стадии, вложиться в виртуализацию образов Chrome OS. Это уменьшит зависимость от физического оборудования, поможет проводить регрессионное тестирование с помощью Selenium и WebDriver на целых фермах серверов и облегчит поддержку тестирования и разработки Chrome OS прямо на рабочих машинах инженеров.

Производительность

В двух словах производительность — ключевая фича Chrome OS. Поэтому она выделена в отдельный проект в команде разработки. Команда тестирования старается помочь рассчитать, предоставить и проанализировать показатели продуктивности в лаборатории, но не занимается непосредственно тестированием производительности.

Нагрузочное тестирование, продолжительное тестирование и тестирование стабильности

Команда тестирования создает и выполняет продолжительные тесты на физическом оборудовании в лаборатории. Не забыть про внедрение неисправностей (fault injection).

Фреймворк выполнения тестов Autotest

Команды тестирования и разработки решили использовать Autotest как основной фреймворк для автоматизации тестов. Autotest удачно прошел проверку в сообществе Linux, использовался в нескольких внутренних проектах, и, кроме того, он распространяется с открытым кодом. Autotest поддерживает локальное и распределенное выполнение. Этот фреймворк умеет подключать и другие оснастки функционального тестирования (например, WebDriver), так что у нас будет единый интерфейс для выполнения, распределения тестов и отчетности.

Хотим отметить, что основная команда разработки инструментов тестирования работает над поддержкой Autotest в Windows и Mac.

Производители железа

Производители железа играют важную роль в проверке качества сборок Chrome OS. Команды тестирования и разработки создают релевантные ручные и автоматизированные тест-кейсы, при помощи которых производители проверяют сборки и оборудование на своей стороне. Кроме них команда тестирования сотрудничает с самыми популярными производителями и включает разные варианты железа в повседневное тестирование. Так мы сможем как можно раньше выявлять любые проблемы или регрессии, связанные с ним.

Лаборатория проверки оборудования

В лаборатории собрано много нетбуков и других устройств, на которых можно регулировать сетевые настройки (для проводного и беспроводного соединений), управлять питанием и т.д. Это инфраструктура для тестирования отдельных сервисов (например, беспроводной связи). Лабораторные машины в основном управляются инфраструктурой HIVE.

Фермы для сквозных автотестов

Команда тестирования создаст ферму нетбуков для прогона тестов и настроит передачу данных о состоянии матрицы аппаратных и программных средств. Фермы распределяются по офисам в Маунтин-Вью, Киркленде и Хайдарабаде для возможности локального доступа к лаборатории и организации практически круглосуточного выполнения тестов и отладки.

Тестирование AppManager в браузере

Основной браузер Chrome OS — это Linux-версия Chrome с пользовательским интерфейсом и фичами, специализированными для Chrome OS. Бˆольшая часть механизмов отображения страниц и функциональности такая же, однако есть значительные различия между базовым браузером и его разновидностью в Chrome OS. Например, закрепляемые вкладки, менеджер загрузки, запуск приложений, платформенные элементы управления, беспроводная связь и т.д.

— Chrome OS — главная платформа для основного тестирования браузера Chrome (ручного и автоматизированного).

— Команда разработки браузера определяет сборку, которую нужно интегрировать, на основании качества сборки и текущих фич Chrome OS.

— Для каждой «релиз-кандидат» версии OS команда браузера проводит стандартный набор тестов совместимости сайтов/приложений (топ-300 сайтов) с Chrome OS.

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

— Команда внешних тестировщиков создает и выполняет пакет ручных тестов для фич Chrome OS, связанных с браузером и менеджером приложений.

— Как только API будет реализован, внешние тестировщики автоматизируют пакет ручных тестов Chrome OS.

— Chrome OS Chromebot должен иметь версии для Linux и Chrome OS и запускаться на всей функциональности Chrome OS, а не только веб-приложений.

— Ручное исследовательское тестирование и туры помогут выявить пользовательские проблемы, связанные с функциональностью, удобством, простотой использования и т.д.

Тестируемость браузера

Перейти на страницу:
Прокомментировать
Подтвердите что вы не робот:*