Microsoft AZ-400: Стратегия тестирования и инженерия качества — Руководство по подготовке

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Часть Microsoft DevOps Engineer Expert AZ-400 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Стратегия тестирования и инжиниринг качества в Azure DevOps — это повышение уверенности в программном обеспечении за счёт быстрой, детерминированной обратной связи на протяжении всего жизненного цикла поставки, с использованием встроенных возможностей платформы для внедрения барьеров качества и прослеживаемости. Эффективные стратегии сочетают сбалансированную пирамиду тестирования, раннюю и непрерывную валидацию (TDD/BDD), надёжную автоматизацию в конвейерах, строгое управление тестовыми данными и передовые методы, такие как нагрузочное тестирование, хаос-инжиниринг, проверки доступности и развёртывания с контролем покрытия. Azure Test Plans, Azure Pipelines, Azure Load Testing и Azure Chaos Studio предоставляют инструменты для масштабной реализации этих практик.

Основы стратегии тестирования

Прагматичная пирамида тестирования снижает риски за счёт быстрых и недорогих тестов в основании и меньшего количества высокоточных тестов на вершине:

• Модульные тесты проверяют изолированную логику и должны составлять основную часть набора тестов. Стремитесь к быстрому выполнению и высокой детерминированности. Для большинства продуктов устанавливайте целевые показатели покрытия модульными тестами в диапазоне 70–90% для критически важных сервисов, признавая, что покрытие является косвенной метрикой, а не гарантией качества.
• Интеграционные тесты проверяют контракты между компонентами (например, база данных, система обмена сообщениями, внешние сервисы), используя реалистичные границы и эфемерные зависимости. По возможности запускайте их параллельно в контейнеризированных или изолированных средах и стремитесь к покрытию 30–60% критически важных путей кода, проверяемых в сценариях на уровне интеграции.
• Сквозные тесты (E2E) проверяют пользовательские сценарии во всём стеке. Делайте их минимальными и сфокусированными на наиболее ценных путях (обычно 5–15% от всего набора тестов), чтобы избежать хрупкой и медленной обратной связи.

Практики тестирования со сдвигом влево позволяют выявлять дефекты на более ранних этапах:

• Разработка через тестирование (TDD) обеспечивает циклы «красный–зелёный–рефакторинг», влияет на проектирование и повышает уверенность на уровне модулей. Сделайте TDD практичным, предоставив инженерам быстрые локальные средства запуска тестов и поддерживая тесты герметичными и детерминированными.
• Разработка через поведение (BDD) фиксирует намерения с помощью общего словаря на языке Gherkin. Команды .NET могут использовать SpecFlow; команды Java и JavaScript часто используют Cucumber. Связывайте сценарии BDD с критериями приёмки в Azure Boards и публикуйте их результаты в Azure Test Plans для прослеживаемости.

Управление тестовыми данными устраняет недетерминированность:

• Синтетические данные предоставляют детерминированные и безопасные с точки зрения конфиденциальности наборы данных для модульных и интеграционных тестов. Генерируйте их с помощью специфичных для языка библиотек-генераторов (faker) и начальных значений (seed), обеспечивающих воспроизводимость.
• Маскирование данных позволяет создавать реалистичные наборы тестовых данных, не раскрывая личную или конфиденциальную информацию. Используйте инструменты маскирования баз данных или конвейеры данных, которые применяют необратимые преобразования. Для Azure SQL Database экспортируйте снимки в промежуточную подписку и применяйте маскирование перед использованием в тестах.
• Паритет сред гарантирует значимость результатов тестирования. Подготавливайте тестовые среды с помощью инфраструктуры как кода (ARM/Bicep/Terraform), чтобы системные компоненты, конфигурация и топология сети соответствовали производственной среде настолько близко, насколько это возможно. Синхронизируйте миграции схем между средами.

Обнаружение и управление нестабильными тестами защищают циклы обратной связи:

• Причины включают гонки по времени, внешние зависимости, связанность тестов по порядку выполнения и конкуренцию за ресурсы. Используйте задачу Visual Studio Test в Azure Pipelines с включённой опцией

undefined

, чтобы уменьшить временный шум во время расследования.

• Помещайте в карантин недетерминированные тесты, чтобы конвейеры оставались «зелёными», помечая и изолируя их в отдельный набор, который запускается и отчитывается, но не приводит к сбою сборки. Отслеживайте «долг» по тестам в карантине с помощью рабочих элементов в Azure Boards.
• Анализ первопричин требует инструментации. Собирайте логи, метрики времени и детали окружения во время запусков; воспроизводите проблему локально с тем же начальным значением и зависимостями; устраните зависимость от незамоканных системных часов, сети и файловой системы; устраняйте недетерминированность в источнике проблемы.

Возможности Azure DevOps и тестирования в Azure

Azure Test Plans предоставляет полноценные возможности для ручного и исследовательского тестирования, а также обеспечивает прослеживаемость:

• Тестовые случаи (test cases) определяют шаги, ожидаемые результаты и параметры; общие шаги и параметризованные тестовые случаи сокращают дублирование. Наборы тестов на основе требований (requirement-based suites) связывают тестовые случаи с элементами бэклога продукта или пользовательскими историями, в то время как статические и основанные на запросах наборы (static and query-based suites) группируют тесты для выполнения.
• Тестовые прогоны (test runs) назначают наборы и конфигурации тестировщикам, записывают результаты и продолжительность, а также собирают диагностические данные. Расширенные возможности регистрации ошибок включают скриншоты, видео, данные об окружении и журналы действий.
• Исследовательское тестирование использует браузерное расширение Test & Feedback для фиксации установок (charters), заметок сессии и артефактов во время нерегламентированного исследования. Связывайте найденные проблемы с рабочими элементами (work items) и анализируйте покрытие требований и тестовых сессий.

Автоматизированное тестирование интегрируется непосредственно в конвейеры:

• Используйте задачу Visual Studio Test (VsTest) для запуска тестов MSTest, NUnit и xUnit и публикации результатов в формате TRX. Для .NET часто используется команда dotnet test с соответствующим логгером (trx, junit).
• Для Java запускайте JUnit через Maven или Gradle и публикуйте результаты в формате JUnit XML с помощью задачи Publish Test Results. Для JavaScript настройте средства запуска тестов (Jest, Mocha) для вывода результатов в формате JUnit XML.
• Задача Publish Test Results консолидирует результаты и отслеживает тенденции по всем прогонам. Стандартизируйте форматы результатов (TRX или JUnit XML) для унификации отчетности и включения аналитики нестабильных тестов.
• Свяжите прогоны автоматизированных тестов с Azure Test Plans, сопоставив тестовые случаи с методами автоматизированных тестов, чтобы обеспечить сквозную прослеживаемость от требования до выполнения и дефекта.

Покрытие кода — это измеримый барьер качества:

• Собирайте данные о покрытии с помощью Coverlet (для .NET), JaCoCo (для Java) или Cobertura/lcov (для JavaScript). Преобразуйте их в форматы, понятные Azure DevOps, и публикуйте с помощью задачи Publish Code Coverage Results для отображения тенденций и изменений.
• Устанавливайте минимальные пороговые значения на этапе сборки. Для .NET используйте флаги пороговых значений Coverlet, чтобы сборка завершалась сбоем, если покрытие строк или ветвей падает ниже установленного уровня. В качестве альтернативы используйте расширение Build Quality Checks для применения политик на основе покрытия и тенденций.
• Развертывания, контролируемые покрытием (coverage-gated deployments), предотвращают продвижение релиза при падении качества. В YAML-конвейерах завершайте сбоем этап контроля качества, если покрытие ниже целевого; для классических релизов используйте шлюзы (gates), которые вызывают Azure Function или REST-проверку для валидации измеренного покрытия перед продвижением.

Производительность, хаос-инжиниринг и отказоустойчивость

Нагрузочное и перформанс-тестирование проверяют нефункциональные требования на ранних этапах и на постоянной основе:

• Azure Load Testing организует масштабную нагрузку на основе JMeter, одновременно сопоставляя телеметрию бэкенда из Application Insights. Импортируйте планы тестов JMX, устанавливайте критерии прохождения/сбоя (например, задержка p95, уровень ошибок) и выводите результаты в конвейеры. Используйте шлюз Azure Monitor или проверки окружения, чтобы блокировать продвижение, если базовые показатели не достигнуты.
• Apache JMeter остается универсальным выбором для нагрузочных тестов на уровне протоколов. Параметризуйте группы потоков (thread groups) и проверки (assertions) для использования в CI. Храните наборы данных JMX и CSV вместе с кодом, версионируя их вместе со сценариями.
• k6 позволяет проводить нагрузочное тестирование в формате “тесты как код”, удобном для разработчиков. Запускайте k6 в Azure Pipelines через контейнер или среду выполнения Node, собирайте результаты и экспортируйте их в JUnit или JSON для публикации. Используйте выражения пороговых значений (thresholds) в скриптах k6 для детерминированного завершения прогонов сбоем.
• Управление базовыми показателями (baselines) имеет решающее значение. Отслеживайте тенденции задержки, пропускной способности и утилизации ресурсов для каждого окружения. Устанавливайте SLO и убедитесь, что тесты выполняются с репрезентативными объемами данных и конфигурациями.

Хаос-инжиниринг проверяет отказоустойчивость в условиях сбоев:

• Azure Chaos Studio внедряет сбои в ресурсы Azure с контролируемым радиусом поражения и защитными механизмами. Типы экспериментов включают нагрузку на CPU/память виртуальных машин, сетевую задержку/черную дыру, завершение процессов и регулирование (throttling) сервисов.
• Сначала запускайте эксперименты в предпроизводственной среде и инструментируйте их с помощью Application Insights и Azure Monitor для фиксации режимов отказа, бюджетов ошибок и поведения автоматического восстановления.
• Проверка отказоустойчивости сочетает хаос-инжиниринг с проверками работоспособности (health probes) и синтетическими транзакциями, чтобы убедиться, что критически важные для пользователя пути остаются доступными или корректно деградируют. Продвигайте релиз только тогда, когда гипотезы об отказоустойчивости подтверждены, а оповещения (alerts) ведут себя так, как было спроектировано.

Доступность, соответствие требованиям и управление

Доступность и соответствие требованиям — это основы качества:

• Соответствуйте как минимум стандарту WCAG 2.1 AA для общедоступных интерфейсов. Преобразуйте требования в критерии приемки в Azure Boards и Azure Test Plans со специальными тест-кейсами на доступность.
• Автоматизируйте проверки с помощью axe-core, интегрированного во фреймворки для UI-тестирования, такие как Playwright, Cypress или Selenium. Прерывайте сборки при обнаружении критических нарушений и публикуйте отчеты о доступности как артефакты конвейера.
• Дополняйте автоматизацию ручными проверками (навигация с клавиатуры, поддержка программ чтения с экрана, контрастность цветов в динамических контекстах) и фиксируйте результаты в исследовательских сессиях с помощью расширения Test & Feedback.
• Управление соответствием требованиям и качеством в Azure Pipelines использует проверки и шлюзы для сред. Для контроля производительности и доступности запрашивайте базовые показатели из Azure Monitor или Azure Load Testing перед развертыванием. Для контроля покрытия кода или доступности вызывайте функцию или REST-проверку, которая анализирует опубликованные отчеты и возвращает результат pass/fail. Это делает нефункциональное качество обязательным условием для релиза, а не второстепенной задачей.

Публикация результатов тестов и аналитика замыкают цикл обратной связи:

• Стандартизируйте форматы результатов и отчетов о покрытии для заполнения Test Analytics, отслеживания динамики успешных прогонов и автоматического выявления нестабильных тестов.
• Используйте политики сборок и защиту ветвей, чтобы требовать успешного прохождения тестов и достаточного покрытия кода перед слиянием. Обеспечьте быструю обратную связь: распараллеливайте этапы тестирования, разделяйте большие наборы тестов и кэшируйте зависимости для сокращения времени цикла.

Практический сценарий

Компания Adobe модернизирует платформу обработки документов, переводя ее на микросервисы в Azure. Руководство требует ускорить частоту релизов без регрессий, обеспечить доказуемые базовые показатели производительности, устойчивость к региональным сбоям сети и соответствие стандарту WCAG 2.1 AA. Текущие конвейеры страдают от нестабильных E2E-тестов и несогласованных тестовых данных.

1. Внедрить пирамиду тестирования и практики сдвига влево

• Применить TDD для ключевых библиотек и сервисов, чтобы создать большую, детерминированную базу модульных тестов, используя NUnit и xUnit для .NET-компонентов и JUnit для Java. Использовать BDD с SpecFlow и Cucumber для фиксации межкомандных критериев приемки в виде исполняемых спецификаций. Это обеспечивает быструю обратную связь и общее понимание.

2. Автоматизировать тесты и публиковать результаты в Azure Pipelines

• Использовать VsTest для .NET и Maven/Gradle для Java для запуска модульных и интеграционных тестов. Публиковать результаты с помощью задачи Publish Test Results и покрытие с помощью Publish Code Coverage Results для централизации отчетности и включения аналитики нестабильных тестов. Встроенные задачи обеспечивают тесную интеграцию с Azure DevOps и сокращают потребность в кастомных инструментах.

3. Установить пороговые значения покрытия кода и контролировать развертывания

• Настроить пороговые значения в Coverlet и JaCoCo так, чтобы сборка завершалась сбоем, если покрытие для критически важных сервисов падает ниже 80% по строкам и 60% по ветвям. Добавить проверку в релизе, которая вызывает Azure Function для чтения последнего артефакта покрытия и возвращает результат pass/fail, предотвращая развертывание, если покрытие не соответствует политике. Это формализует шлюзы качества без вмешательства человека.

4. Внедрить управление тестовыми данными для детерминизма

• Генерировать синтетические наборы данных для модульных и интеграционных тестов с помощью faker-библиотек. Для системных тестов клонировать маскированные копии баз данных Azure SQL через автоматизированный конвейер с использованием Data Factory для применения необратимого маскирования. Подготавливать среды с помощью Bicep для обеспечения их идентичности. Это устраняет риски для конфиденциальности и нестабильность, связанную с данными.

5. Изолировать и устранять нестабильные тесты

• Включить опцию rerunFailedTests в VsTest для смягчения временных сбоев и помечать нестабильные тесты маркером карантина, который исключает их из блокирующего набора, но продолжает запускать и собирать по ним отчеты. Создавать рабочие элементы в Azure Boards для каждого теста в карантине. Находить первопричину, собирая логи времени выполнения и сетевые логи, и устранять недетерминированные ожидания. Это поддерживает надежность конвейеров и способствует окончательному исправлению проблем.

6. Проверять производительность с помощью Azure Load Testing и k6

• Моделировать ключевые сценарии пользователей в виде планов JMeter и запускать их в Azure Load Testing после развертывания в промежуточной среде (staging), с критериями прохождения/непрохождения по задержке p95 и частоте ошибок. Для тестов на уровне API, выполняемых разработчиками, запускать скрипты k6 в CI со встроенными пороговыми значениями. Добавить шлюз Azure Monitor для блокировки развертывания в производственную среду, если базовые показатели в staging не достигнуты. Эти инструменты обеспечивают масштабируемый и измеримый контроль производительности в соответствии с концепцией шлюзов качества.

7. Подтверждать устойчивость с помощью Azure Chaos Studio

• Разрабатывать эксперименты, которые вносят задержки в сеть и создают нагрузку на ЦП для отдельных микросервисов в промежуточной среде (staging), в то время как Application Insights отслеживает бюджеты ошибок и восстановление. Требовать, чтобы все эксперименты на устойчивость соответствовали SLO перед переносом в производственную среду. Средства управления в Chaos Studio соответствуют потребности Adobe в контролируемом радиусе поражения и аудируемых экспериментах.

8. Обеспечить доступность и соответствие требованиям

• Интегрировать axe-core в UI-тесты на Playwright для автоматического обнаружения нарушений WCAG 2.1 AA на ключевых экранах. Публиковать отчеты о нарушениях как артефакты сборки и прерывать сборку при критических проблемах. Планировать исследовательские сессии по доступности с помощью Azure Test Plans и расширения Test & Feedback для ручной проверки. Это сочетает автоматизированное покрытие с проверками, ориентированными на человека.

9. Обеспечить прослеживаемость и аналитику

• Связывать автоматизированные тесты с Azure Test Plans, где это уместно, сопоставлять наборы тестов с требованиями и использовать Test Analytics для отслеживания динамики успешных прогонов, выявления нестабильных тестов и концентрации усилий на их исправлении. Это позволяет руководству наглядно видеть тенденции в качестве и готовность к релизу.

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

← Безопасность · Все домены · Мониторинг →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →