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

Суджай: Покрытие кода — это метрика, которая показывает эффективность тестов для кода проекта. В традиционном подходе каждая команда должна выделить отдельные ресурсы (инженерные, аппаратные и программные) для измерения этого покрытия. А в Google есть специальная группа людей, находящаяся в Индии, которая следит за тем, чтобы все инженерные команды легко получали свои метрики покрытия кода. Для этого команда должна потратить всего пять минут, чтобы один раз настроить эту функциональность. После настройки у них будут все метрики проектов и сборок с централизованной системой просмотра и анализа отчетов.

Измерение покрытия поддерживается для тысяч проектов, всех основных языков программирования и миллионов файлов с исходным кодом. Инфраструктура покрытия интегрирована с облачной инфраструктурой Google для компилирования и сборки кода. Она масштабируется для постоянных изменений кода (происходящих ежеминутно!) и десятков тысяч сборок в день. Инфраструктура способна меняться вместе со стремительно растущей кодовой базой Google.

Еще в нашем арсенале есть вспомогательная система для назначения тестам приоритетов. С ее помощью определяются тесты, которые должны выполняться для конкретных изменений в коде. Это улучшает покрытие, прибавляет уверенности в качестве кода и ускоряет обратную связь. Тем самым мы экономим Google инженерные ресурсы.

— Похоже, это правильный подход к покрытию кода. А теперь расскажи о приложении Diagnostic Utility, которое ты упоминал.

Суджай: Diagnostic Utility задумали и реализовали разработчики в тестировании нашего центра в свое «двадцатипроцентное» время. Технических знаний обычного пользователя часто не хватает, чтобы дать нужную информацию для диагностики и отладки проблемы, а это приложение автоматически предоставляет эти данные.

Чтобы разобраться в проблеме пользователя, иногда нужны определенные технические данные. Это могут быть простые данные, которые клиент может предоставить (например, версия ОС), но бывает, что требуются подробности о версиях и конфигурациях приложений, поиск которых ставит пользователя в тупик.

Приложение Diagnostic Utility решает эту проблему. Теперь, когда службе поддержки нужна дополнительная информация о системе пользователя, они создают новую конфигурацию для этой утилиты, где перечисляют, какая информация требуется. Дальше пользователь получает по почте или скачивает с сайта поддержки небольшой (около 300 Кбайт) исполняемый файл, подписанный сертификатом Google. Этот файл диагностирует машину пользователя, собирает указанные в конфигурации данные и показывает их пользователю, чтобы он подтвердил их отправку в Google. Приложение хорошо воспитано — после отправки данных оно прибирает за собой и удаляется. Мы заботимся о конфиденциальности, поэтому все собранные данные отправляются только с согласия пользователя.

Служба поддержки пересылает данные разработчику для отладки. Приложение Diagnostic Utility делает работу команд клиентских приложений (например, Google Chrome и Google Toolbar) проще, а самому пользователю облегчает процесс получения технической поддержки.

— Ты пару раз упоминал тестирование нагрузки и производительности. Что здесь интересного расскажешь? Насколько мы понимаем, ваша команда активно участвует в тестировании производительности Gmail?

Суджай: Google выпускает очень много веб-приложений, и очень важно обеспечить быстрое взаимодействие пользователей с ними. А раз так, то тестирование производительности клиентской части — анализ скорости выполнения JavaScript и отображения страниц — обязательно должно проводиться перед каждым выпуском. Раньше на выявление причин задержек и последующую отладку могли уходить дни, а то и месяцы. Ребята из индийского отделения продуктивности разработки построили инфраструктуру для тестирования производительности фронтенда Gmail, чтобы покрывать самые важные действия пользователя. То, что пользователи делают чаще всего, должно проходить через тщательное тестирование производительности. Мы настраиваем специальные серверные конфигурации, тесты выполняются в контролируемой среде, которая минимизирует отклонения и помогает выявлять ухудшения в работе системы.

Наше решение состоит из трех частей:

— Предварительные тесты. Инженеры могут проводить тесты и измерять задержки перед отправкой изменений в коде в репозиторий. Это ускоряет обратную связь и снижает вероятность попадания багов в кодовую базу.

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