Книга: Как тестируют в Google
Как мы используем размеры тестов в общей инфраструктуре
Как мы используем размеры тестов в общей инфраструктуре
Автоматизацию тестирования трудно сделать универсальной. Чтобы все проекты в большой IT-компании могли работать с общей тестовой инфраструктурой, она должна поддерживать множество разных сценариев запуска тестов.
Например, вот некоторые типичные сценарии запуска тестов, которые поддерживает общая инфраструктура тестирования Google.
— Разработчик хочет скомпилировать и запустить малый тест и тут же получить результаты.
— Разработчик хочет запустить все малые тесты для проекта и тут же получить результаты.
— Разработчик хочет скомпилировать и запустить только те тесты, которые связаны с последним изменением кода, и тут же получить результаты.
— Разработчик или тестировщик хочет собрать данные о покрытии кода в конкретном проекте и посмотреть результаты.
— Команда хочет прогонять все малые тесты для своего проекта каждый раз при создании списка изменений и рассылать результаты всем участникам команды.
— Команда хочет прогонять все тесты для своего проекта после отправки списка изменений в систему управления версиями.
— Команда хочет еженедельно собирать статистику о покрытии кода и отслеживать его прогресс со временем.
Может быть и так, что все вышеперечисленные задания отправляются в систему выполнения тестов Google одновременно. Некоторые из тестов могут захватывать ресурсы, занимая общие машины на целые часы. Другим будет достаточно миллисекунд для выполнения, и они могут благополучно исполняться на одной машине с сотнями других тестов. Когда тесты помечены как малые, средние и большие, гораздо проще планировать расписание выполнения запусков, так как планировщик понимает, сколько времени может занять запуск, и оптимизирует очередь.
Система выполнения тестов Google отличает быстрые задания от медленных по информации о размере тестов. У каждого размера есть верхняя граница времени выполнения теста (табл. 2.1). Размер определяет и потенциальную потребность в ресурсах (табл. 2.2). Система прерывает выполнение и сообщает об ошибке, если тест превышает выделенное для его категории время или доступный объем ресурса. Это мотивирует разработчиков в тестировании назначать правильные метки размеров тестов. Точное определение размеров тестов позволяет системе строить эффективное расписание.
- Жизнь разработчика в тестировании
- Как организованы процессы разработки и тестирования
- Кто такие разработчики в тестировании на самом деле?
- Ранняя стадия проекта
- Структура команды
- Проектная документация
- Интерфейсы и протоколы
- Планирование автоматизации
- Тестируемость
- Как появились очереди на отправку и непрерывная сборка Джефф Карролло
- Пример работы разработчика в тестировании
- Выполнение тестов
- Определения размеров тестов
- Как мы используем размеры тестов в общей инфраструктуре
- Преимущества разных размеров тестов
- Требования к выполнению тестов
- Тестирование на скоростях и в масштабах Google Пуджа Гупта, Марк Айви и Джон Пеникс
- Тест-сертификация
- Как мы собеседуем на позицию разработчиков в тестировании
- Выполнение тестов
- Требования к выполнению тестов
- Определения размеров тестов
- Ответный файл, используемый по умолчанию (csc.rsp)
- Корпуса, используемые в ПК и серверах
- Блоки питания, используемые в компьютерах
- Используем скрипты
- Модификаторы спецификации преобразования, используемые в функции printf( )
- Тестовые данные (Test Data)
- Листинг 8.2. Общий код, используемый во всех приведенных ниже вариантах тестов
- Пиктограммы, используемые в книге
- Ключевые слова, используемые для спецификации типа данных