Основы CI и AQA

Все темы QA

Что такое CI?

CI или Непрерывная интеграция (Continuous Integration) — это практика в разработке программного обеспечения, при которой разработчики регулярно, часто несколько раз в день, интегрируют свои изменения в общий репозиторий проекта. После каждой интеграции автоматически выполняются различные тесты и процессы для проверки нового кода. Вот ключевые аспекты CI:

1. Автоматическое тестирование:

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

2. Быстрая обратная связь:

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

3. Уменьшение риска:

   • Частая интеграция сокращает риски, связанные с объединением больших объемов изменений, упрощает устранение конфликтов и предотвращает “эффект дрейфа кода”.

4. Улучшение производительности процесса разработки:

   • Помогает поддерживать высокую производительность процесса разработки благодаря автоматизации рутинных задач и раннему выявлению проблем.

5. Интеграция с инструментами:

   • CI обычно интегрируется с другими инструментами, такими как системы управления версиями, инструменты непрерывной доставки (CD), системы мониторинга и т.д.

Популярные инструменты для непрерывной интеграции включают Jenkins, Travis CI, GitLab CI, CircleCI и другие. Эти инструменты помогают автоматизировать процесс CI, делая его более эффективным и менее подверженным ошибкам, которые могут возникнуть при ручном выполнении процессов.

Как автоматическое тестирование интегрируется в CI?

Автоматическое тестирование играет ключевую роль в процессе непрерывной интеграции (CI), обеспечивая быструю и надежную проверку кода, который разработчики регулярно сливают в общий репозиторий. Вот как автоматическое тестирование интегрируется в процесс CI:

1. Интеграция с системой контроля версий:

   • Процесс CI начинается с того, что система контроля версий (например, Git) оповещает CI-сервер (например, Jenkins, GitLab CI) о новом коммите в репозитории.

2. Автоматический запуск тестов:

   • CI-сервер автоматически запускает процесс сборки, который включает в себя компиляцию кода, запуск юнит-тестов, интеграционных тестов, и других видов тестирования, чтобы убедиться в корректности и стабильности вносимых изменений.

3. Использование тестовых сценариев:

   • Тестовые сценарии, написанные на таких инструментах, как Selenium, JUnit, TestNG и другие, выполняются для проверки функциональности и производительности приложения.

4. Отчеты и уведомления:

   • После выполнения тестов CI-система генерирует отчеты о результатах тестирования, которые могут включать информацию об ошибках, проблемах с производительностью и других потенциальных проблемах. В случае обнаружения ошибок разработчики получают уведомления.

5. Фиксация ошибок:

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

6. Регрессионное тестирование:

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

Автотесты в CI дают быструю обратную связь и уменьшают риск регрессий. Для доверия к результату нужны подходящие проверки, стабильное окружение и анализ падений; зелёный статус не доказывает отсутствие всех ошибок.

Как настроить Job или Pipeline на знакомом вам CI-инструменте?

Для настройки Job или Pipeline на одном из самых популярных CI-инструментов — Jenkins — можно следовать следующему пошаговому процессу. Jenkins предоставляет гибкие возможности для настройки заданий (jobs) и пайплайнов (pipelines), позволяя автоматизировать широкий спектр задач, от сборки проектов до их тестирования и развертывания.

Настройка Job в Jenkins:

1. Установка и запуск Jenkins:

   • Сначала необходимо установить Jenkins на сервер или локальную машину. После установки Jenkins будет доступен через веб-интерфейс, обычно на порту 8080.

2. Создание нового Job:

   • В веб-интерфейсе Jenkins перейдите в “New Item” на главной панели.

   • Введите имя для новой задачи (job) и выберите тип задачи, например, “Freestyle project” для простой задачи или “Pipeline” для более сложных сценариев.

3. Конфигурация Job:

   • Source Code Management: Настройте доступ к репозиторию, указав URL и метод аутентификации для Git или других систем контроля версий.

   • Build Triggers: Определите, когда должна запускаться сборка — например, при каждом коммите в репозиторий или по расписанию (cron syntax).

   • Build Environment: Настройте окружение, например, определите переменные окружения.

   • Build Steps: Добавьте шаги сборки, такие как сборка проекта с помощью Maven, выполнение скриптов shell или запуск тестов.

4. Сохранение и запуск:

   • Сохраните настройки и запустите задачу вручную, нажав “Build Now”, или дождитесь, пока триггер автоматически инициирует сборку.

Настройка Pipeline в Jenkins:

1. Создание Pipeline:

   • Также начните с “New Item”, но выберите “Pipeline” в качестве типа проекта.

2. Конфигурация Pipeline:

   • Pipeline Definition: Вы можете настроить пайплайн напрямую в Jenkins через “Pipeline script” или “Pipeline script from SCM”, что позволяет управлять скриптом пайплайна через систему контроля версий.

   • Введите скрипт Pipeline, используя язык описания пайплайна Groovy. Пример простого скрипта:

     pipeline {
         agent any
         stages {
             stage('Build') {
                 steps {
                     echo 'Building..'
                     // команды сборки
                 }
             }
             stage('Test') {
                 steps {
                     echo 'Testing..'
                     // команды тестирования
                 }
             }
             stage('Deploy') {
                 steps {
                     echo 'Deploying..'
                     // команды развертывания
                 }
             }
         }
     }

3. Сохранение и выполнение:

   • Сохраните настройки и запустите Pipeline, используя “Build Now” или дождитесь автоматического запуска.

Эти шаги предоставляют основу для настройки автоматизированных задач в Jenkins, позволяя эффективно интегрировать CI в процессы разработки и развертывания программного обеспечения.

Какие инструменты для генерации репорта после выполнения автоматических тестов вы знаете?

Генерация отчётов о результатах тестирования является ключевым аспектом автоматизации тестов, поскольку она обеспечивает обратную связь, необходимую для оценки качества ПО. Вот несколько популярных инструментов для генерации отчётов после выполнения автоматических тестов:

1. Allure Framework:

   • Мощный инструмент для визуализации результатов тестирования, поддерживает множество языков и тестовых фреймворков. Allure генерирует подробные отчёты, включая шаги выполнения, вложения, и историю изменений.

2. Extent Reports:

   • Расширяемый генератор отчетов, который может быть интегрирован с фреймворками, такими как TestNG и JUnit. Extent Reports предоставляет интерактивные отчёты с графиками, логами и скриншотами.

3. ReportPortal:

   • Открытый и масштабируемый инструмент управления результатами тестирования с AI-поддержкой для анализа результатов. ReportPortal собирает данные из разных источников и предоставляет аналитику в режиме реального времени.

4. Serenity (ранее Thucydides):

   • Инструмент, который помогает писать чистый и поддерживаемый автоматизированный тестовый код и генерирует богатые, информативные отчёты о выполнении тестов.

5. TestNG Reports:

   • Встроенная функциональность в TestNG, которая автоматически генерирует HTML-отчёты о результатах тестов. Отчёты включают информацию о пройденных, проваленных и пропущенных тестах.

6. JUnit Reports:

   • JUnit может генерировать XML-отчёты, которые затем можно визуализировать с помощью других инструментов, таких как Jenkins, для просмотра результатов тестирования.

7. Cucumber Reports:

   • Cucumber поддерживает создание отчётов в форматах JSON, HTML, и XML. Эти отчёты могут быть дополнительно обработаны для получения более детализированных визуальных представлений.

8. Jest:

   • Для JavaScript и React-приложений Jest может генерировать покрытие кода и результаты тестирования в удобочитаемых форматах.

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

Какую информацию должен содержать отчет о выполнении автоматических тестов?

Отчёт о выполнении автоматических тестов должен предоставлять подробную и легко интерпретируемую информацию, которая помогает командам быстро оценить состояние тестируемого ПО. Вот основные элементы, которые должны быть включены в такой отчёт:

1. Общая статистика:

   • Количество выполненных тестов.

   • Количество успешных (пройденных) тестов.

   • Количество неудачных (проваленных) тестов.

   • Количество пропущенных тестов.

2. Детализация по каждому тесту:

   • Название теста и краткое описание его цели.

   • Результат выполнения теста (успешно, не успешно, пропущено).

   • Время запуска и продолжительность теста.

3. Сообщения об ошибках и исключениях:

   • Подробные сообщения об ошибках для проваленных тестов.

   • Стек вызовов (stack trace), если это применимо.

4. Скриншоты и логи:

   • Скриншоты интерфейса в момент провала теста, если это применимо.

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

5. Метрики покрытия кода:

   • Статистика покрытия кода тестами, указывающая процентные соотношения покрытия различных участков кода.

6. Информация о тестовом окружении:

   • Версии операционной системы, браузеров, и другого ПО, используемого в тестах.

   • Конфигурация тестового стенда или параметры среды.

7. Исторические данные и тенденции:

   • Сравнение текущих результатов с предыдущими запусками для отслеживания прогресса и выявления тенденций.

8. Рекомендации и действия:

   • Предложения по исправлению ошибок и улучшению качества кода на основе результатов тестов.

   • Планы на дальнейшие тесты или испытания.

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

Какие Quality Gates ставить перед merge и релизом?

Перед merge обычно требуют сборку, unit и быстрые интеграционные тесты, статический анализ, проверку секретов и критичных уязвимостей. Перед релизом добавляют E2E или smoke на собранном артефакте, миграции, контрактную совместимость, критичные performance-SLO и отсутствие незакрытых дефектов выше согласованной тяжести. Пороги зависят от риска компонента: один процент coverage для всех создаёт формальную гонку за числом. Gate должен иметь владельца, понятную причину падения и процедуру исключения с ограниченным сроком. Нестабильный тест нельзя молча перезапускать до зелёного, иначе gate перестаёт что-либо доказывать.

Как оценить качество набора автотестов?

Качество набора видно по тому, какие значимые дефекты он ловит до релиза, насколько стабилен сигнал и сколько времени занимает обратная связь. Проверяют покрытие бизнес-рисков, мутационное тестирование или выборочный аудит assertions, долю flaky-тестов, время диагностики и стоимость изменений. Полезно разбирать escaped defects: мог ли разумный тест обнаружить их раньше и на каком уровне. Coverage строк показывает непосещённый код, но не подтверждает правильность проверок. Набор хорош, если быстро отличает безопасное изменение от опасного и остаётся понятным команде, а не просто содержит много тестов.

Какие проверки выгодно автоматизировать?

В первую очередь автоматизируют частые, повторяемые и стабильные проверки с чётким oracle: критичные регрессии, расчёты, API-контракты и наборы данных. Выгода выше, если ручной прогон дорог, риск ошибки велик, а тест быстро сообщает результат. Учитывают стоимость разработки, окружения, данных и последующей поддержки, а не только первый запуск. Редкие одноразовые сценарии, быстро меняющийся UI и субъективная оценка часто выгоднее для ручного или исследовательского тестирования. Решение пересматривают после стабилизации функции. ROI оценивают вместе с ценой пропущенного дефекта, а не простой экономией минут тестировщика.

Какие конфликты возникают при параллельных автотестах?

Параллельные тесты конфликтуют за общих пользователей, записи БД, очереди, файлы, порты, браузерные профили и лимиты внешней среды. Один тест может удалить данные другого или прочитать его сообщение, а ограниченный пул соединений создаст ложные таймауты. Решение состоит в уникальных идентификаторах и namespaces, отдельных consumer groups, динамических портах и экземпляре драйвера на worker. Cleanup должен удалять только данные своего теста. Параллелизм наращивают до измеренной ёмкости среды, иначе тестируют её лимит вместо продукта. Остаточные конфликты ищут повтором с разным числом workers и случайным порядком.

Как найти причину flaky-теста?

Сначала сохраняют seed, окружение, время, логи, trace, скриншоты и последнее состояние, затем повторяют тест отдельно, в наборе, в случайном порядке и под параллельной нагрузкой. Проверяют неконтролируемое время, общий state, данные, сеть, асинхронные ожидания и зависимость от порядка. Фиксированный sleep заменяют ожиданием условия с таймаутом. Карантин допустим временно, если он не блокирует релиз и имеет владельца со сроком исправления. Автоматический retry может собрать диагностику, но не делает тест стабильным. Исправляют источник недетерминизма, а не повышают число повторов до зелёного результата.