Книга: Как тестируют в Google
Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс
Тестирование на скоростях и в масштабах Google
Пуджа Гупта, Марк Айви и Джон Пеникс
Системы непрерывной интеграции — главные герои обеспечения работоспособности программного продукта во время разработки. Типичная схема работы большинства систем непрерывной интеграции такая.
1. Получить последнюю копию кода.
2. Выполнить все тесты.
3. Сообщить о результатах.
4. Перейти к пункту 1.
Решение отлично справляется с небольшой кодовой базой, пока динамичность изменений кода не выходит за рамки, а тесты прогоняются быстро. Чем больше становится кода, тем сильнее падает эффективность подобных систем. Добавление нового кода увеличивает время «чистого» запуска, и в один прогон включается все больше изменений. Если что-то сломается, найти и исправить изменение становится все сложнее.
Разработка программных продуктов в Google происходит быстро и с размахом. Мы добавляем в базу кода всего Google больше 20 изменений в минуту, и 50% файлов в ней меняются каждый месяц. Разработка и выпуск всех продуктов опираются на автотесты, проверяющие поведение продукта. Есть продукты, которые выпускаются несколько раз в день, другие — раз в несколько недель.
По идее, при такой огромной и динамичной базе кода команды должны тратить кучу времени только на поддержание сборки в состоянии «зеленого света». Система непрерывной интеграции должна помогать с этим. Она должна сразу выделять изменение, приводящее к сбою теста, а не просто указывать на набор подозрительных изменений или, что еще хуже, перебирать их все в поисках нарушителя.
Чтобы решить эту проблему, мы построили систему непрерывной сборки (рис. 2.6), которая анализирует зависимости и выделяет только те тесты, которые связаны с конкретным изменением, а потом выполняет только их. И так для каждого изменения. Система построена на инфраструктуре облачных вычислений Google, которая позволяет одновременно выполнять большое количество сборок и запускать затронутые тесты сразу же после отправки изменений.
Примером ниже мы показываем, как наша система дает более быструю и точную обратную связь, чем типичная непрерывная сборка. В нашем сценарии используются два теста и три изменения, затрагивающие эти тесты. Тест gmail_server_tests падает из-за изменения 2. Типичная система непрерывной сборки сообщила бы, что к сбой случился из-за изменения 2 или 3, не уточняя. Мы же используем механизм параллельного выполнения, поэтому запускаем тесты независимо, не дожидаясь завершения текущего цикла «сборка–тестирование». Анализ зависимостей сузит набор тестов для каждого изменения, поэтому в нашем примере общее количество выполнений теста то же самое.
![Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс](https://img-lib.wm-help.net/2502678000/i_009.jpg)
Рис. 2.6. Сравнение систем непрерывной интеграции
Наша система берет данные о зависимостях из спецификаций сборки, которые описывают, как компилируется код и какие файлы входят в сборку приложения и теста. Правила сборки имеют четкие входные и выходные данные, объединив которые получим точное описание процесса сборки. Наша система строит в памяти график зависимостей сборки, как на рис. 2.7, и обновляет его с каждым новым изменением. На основании этой схемы мы определяем все тесты, связанные прямо или косвенно с кодом, вошедшим в изменение. Именно эти тесты нужно запустить, чтобы узнать текущее состояние сборки. Давайте посмотрим на пример.
![Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс](https://img-lib.wm-help.net/2502678000/i_010.jpg)
Рис. 2.7. Пример зависимостей сборки
Мы видим, как два отдельных изменения в коде, находящихся на разных уровнях дерева зависимостей, анализируются, чтобы подобрать минимальный набор тестов, который определит, дать ли зеленый свет проектам Gmail и Buzz.
Сценарий 1: изменение в общей библиотеке
Для первого сценария возьмем изменение, которое модифицирует файлы в common_collections_util, как показано на рис. 2.8.
![Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс](https://img-lib.wm-help.net/2502678000/i_011.jpg)
Рис. 2.8. Изменение в common_collections_util.h
Отправив изменение, мы перемещаемся по линиям зависимостей вверх по графику. Так мы найдем все тесты, зависящие от изменений. Когда поиск завершится, а это займет лишь доли секунды, у нас будут все тесты, которые нужно прогнать, и мы получим актуальные статусы наших проектов (рис. 2.9).
![Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс](https://img-lib.wm-help.net/2502678000/i_012.jpg)
Рис. 2.9. Тесты, на которые влияет изменение
Сценарий 2: изменение в зависимом проекте
Во втором примере возьмем изменение, которое модифицирует файлы в youtube_client (рис. 2.10).
![Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс](https://img-lib.wm-help.net/2502678000/i_013.jpg)
Рис. 2.10. Изменение в youtube_client
Проведя аналогичный анализ, мы определим, что изменение влияет только на buzz_client_tests и что нужно актуализировать статус проекта Buzz (рис. 2.11).
![Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс](https://img-lib.wm-help.net/2502678000/i_014.jpg)
Рис. 2.11. Buzz нужно обновить
Примеры показывают, как мы оптимизируем количество тестов, прогоняемых для одного изменения, без потери в точности результатов. Уменьшение количества тестов для одного изменения позволяет выполнить все нужные тесты для каждого зафиксированного изменения. Нам становится легче выявлять и отлаживать проблемы в проблемном изменении.
Умные инструменты и возможности инфраструктуры облачных вычислений сделали систему непрерывной интеграции быстрой и надежной. И мы постоянно стараемся ее улучшить, хотя она уже используется в тысячах проектов Google, чтобы выпускать проекты быстрее и проводить больше итераций. И — что важно — наш прогресс замечают пользователи.
- Жизнь разработчика в тестировании
- Как организованы процессы разработки и тестирования
- Кто такие разработчики в тестировании на самом деле?
- Ранняя стадия проекта
- Структура команды
- Проектная документация
- Интерфейсы и протоколы
- Планирование автоматизации
- Тестируемость
- Как появились очереди на отправку и непрерывная сборка Джефф Карролло
- Пример работы разработчика в тестировании
- Выполнение тестов
- Определения размеров тестов
- Как мы используем размеры тестов в общей инфраструктуре
- Преимущества разных размеров тестов
- Требования к выполнению тестов
- Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс
- Тест-сертификация
- Как мы собеседуем на позицию разработчиков в тестировании
- Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс
- Тестирование Web-сервиса XML с помощью WebDev.WebServer.exe
- Разработка через тестирование и разработка с тестами
- Глава 12 Краткость – искусство маркетинга
- Рост и преимущества прямого маркетинга
- CPC или CPM: показатель оптимизации № 11 – CPC как инновация компании Google
- Маркетинг для государственных и общественных организаций
- Zag: манифест другого маркетинга
- 5.2. Классификация собственных торговых марок и маркировка товаров
- 6.2. Заработок на контекстной рекламе Google AdSense
- Конкурентный бенчмаркинг в GE Real Estate
- Часть III. Шаблоны разработки через тестирование