Автоматизированное интеграционное тестирование

В этой статье я пытаюсь обобщить мой опыт тестирования интеграции. Я расскажу о следующих темах:

• Автоматический запуск интеграционных тестов и избежание ошибок, допущенных человеком.

• Сделать результаты теста повторяемыми.

• Выполнение тестов в системе в различных условиях.

• Получение исчерпывающих результатов испытаний, пригодных для дальнейшего анализа.

• Разработайте прочный испытательный стенд, который восстанавливается до чистого состояния.

Тестируемая система

Сначала рассмотрим предмет интеграционного тестирования — тестируемую систему. Наша команда занимается системами поддержки операций (OSS) для телекоммуникаций.

Решение OSS обычно состоит из нескольких приложений, работающих на разных компьютерах; каждое приложение предоставляет подмножество некоторых доменных функций. Например, система управления ошибками (FMS) объединяет сигналы неисправностей от нескольких систем управления элементами (EMS), затем экспертная система анализирует эти сигналы и принимает решение о выдаче заявки на устранение неисправностей в системе регистрации неисправностей (TTS).

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

Читатель, знакомый с сегодняшними практиками непрерывной интеграции (CI), может сказать: «Эй, парень, разделите свое решение на атомарные микросервисы, упакуйте эти сервисы в контейнеры, управляйте ими с помощью любого инструмента оркестровки, мгновенно разверните все в облаке, независимо для каждого выполнения теста … «Если это ваш случай, значит, вы достаточно счастливы в своей жизни, и эта статья для вас бесполезна. Эта статья о решениях, построенных на унаследованных приложениях, о старом и спагетти-разработанном программном обеспечении. Я принимаю на себя задачу применения методов КИ для интеграционного тестирования таких решений.

Модель испытательного стенда

Для простоты я рассмотрю простую модель, а не реальное решение. Давайте иметь модель, состоящую из трех компонентов:

1. Производитель данных

2. Система обмена сообщениями

3. Потребитель данных

Каждый компонент работает на отдельном хосте. Практика, разработанная для этого упрощенного испытательного стенда, применима к реальной системе, состоящей из множества компонентов.

Результат, которого мы хотим

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

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

Второй вид результатов испытаний — это показатели производительности. Такие показатели могут включать

• Статистика использования процессора и памяти,

• Статистика чтения / записи диска,

• Статистика отправки / получения по сети.

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

• Сквозная задержка сообщения — время передачи сообщения от источника к потребителю,

• Задержка доставки — как долго сообщение остается в Системе сообщений, ожидая потребления,

• Отправить оценку для продюсера,

• Получите тариф для потребителя,

• Отправить статистику размера очереди для производителя,

• Обработка статистики размера очереди для потребителя,

• Статистика размера сообщения.

Мы можем захотеть, чтобы некоторые из этих метрик были полностью накоплены, а некоторые усреднены по скользящему окну.

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

Кнопка сброса для тестового стенда

Вы можете использовать любой инструмент автоматизации для реализации. Это может быть инструмент автоматического управления конфигурацией, такой как Ansible, или язык сценариев, такой как Python. Наша команда использует скрипты Groovy для автоматической установки. Инструмент не имеет значения, результат имеет значение — испытательный стенд находится в исходном состоянии.

Как мы можем реализовать кнопку Reset для нашей модели испытательного стенда? Позвольте мне выразить это в Groovy-подобном псевдокоде:

// Stop
atHost 'host1', { stopProducer }
atHost 'host3', { stopConsumer }
atHost 'host2', { stopMessagingSystem }
// Uninstall
atHost 'host1', { uninstallProducer }
atHost 'host3', { uninstallConsumer }
atHost 'host2', { uninstallMessagingSystem }
// Install
atHost 'host2', { installMessagingSystem }
atHost 'host3', { installConsumer }
atHost 'host1', { installProducer }
// Start
atHost 'host2', { startMessagingSystem }
atHost 'host3', { startConsumer }
atHost 'host1', { startProducer }

[producer]
host1

[messaging_system]
host2

[consumer]
host3

---

- hosts: producer
  roles:
  - configure_producer

- hosts: messaging_system
  roles:
  - configure_messagingsystem

- hosts: consumer
  roles:
  - configure_consumer

- hosts: producer
  roles:
  - send_messages

- hosts: all
  roles:
  - collect_results

- hosts: all
  roles:
  - cleanup

ansible-playbook -i test_bed_inventory \
  -e producer_message_rate=10 \
  -e producer_message_size_kb=1 \
  -e message_buffer_size_kb=1024 \
  -e consumer_enrichment=true \
  -e test_interval_min=60 \
  test-scenario.yml

- hosts: producer
  roles:
  - send_messages

try {
    // Run test scenario
    ansiblePlaybook extras: "… test parameters …",
                                    inventory: "test_bed_inventory",
                                    playbook: "test-scenario.yml"
} finally {
    try {
        // Either success or failure - collect test results
        ansiblePlaybook extras: "… test parameters …",
                                        inventory: "test_bed_inventory",
                                        playbook: "collect-results.yml"
    } finally {
        // In any case, cleanup the test bed
        ansiblePlaybook extras: "… test parameters …",
                                        inventory: "test_bed_inventory",
                                        playbook: "test-bed-cleanup.yml"
    }
}

for (rate in producerMessageRates) {
    for (size in messageSizes) {
        …
    }
}