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%)에 집중하세요.

쉬프트-레프트(Shift-left) 테스트 프랙티스는 결함을 더 일찍 줄여줍니다.

테스트 주도 개발(TDD)은 레드-그린-리팩터(red–green–refactor) 사이클을 강제하고, 설계를 구체화하며, 단위 수준의 신뢰도를 높입니다. 엔지니어에게 빠르고 로컬에서 실행 가능한 테스트 러너를 제공하고, 테스트를 밀폐되고(hermetic) 결정적으로 유지하여 TDD를 실용적으로 만드세요.
행동 주도 개발(BDD)은 Gherkin을 사용하여 공유된 어휘로 의도를 포착합니다. .NET 팀은 SpecFlow를, Java 및 JavaScript 팀은 종종 Cucumber를 사용합니다. BDD 시나리오를 Azure Boards 인수 기준에 연결하고 그 결과를 Azure Test Plans에 게시하여 추적성을 확보하세요.

테스트 데이터 관리는 비결정성을 제거합니다.

합성 데이터는 단위 및 통합 테스트를 위해 결정적이고 개인 정보 보호에 안전한 데이터셋을 제공합니다. 언어별 페이커(faker) 라이브러리와 재현성을 허용하는 시드(seed) 값을 사용하여 생성하세요.
데이터 마스킹은 개인 정보나 민감한 정보를 노출하지 않고 현실적인 테스트 데이터셋을 사용할 수 있게 합니다. 비가역적 변환을 적용하는 데이터베이스 마스킹 도구나 데이터 파이프라인을 사용하세요. Azure SQL Database의 경우, 스냅샷을 스테이징 구독으로 내보낸 후 테스트에 사용하기 전에 마스킹을 적용하세요.
환경 동등성(parity)은 테스트 결과가 의미 있도록 보장합니다. 인프라스트럭처 애즈 코드(Infrastructure as Code, ARM/Bicep/Terraform)로 테스트 환경을 프로비저닝하여 시스템 구성 요소, 설정, 네트워크 토폴로지가 가능한 한 프로덕션과 가깝게 일치하도록 하세요. 환경 간에 스키마 마이그레이션을 긴밀하게 동기화하여 유지하세요.

변덕스러운(Flaky) 테스트 탐지 및 관리는 피드백 루프를 보호합니다.

원인으로는 타이밍 경쟁(race condition), 외부 종속성, 테스트 순서 결합, 리소스 경합 등이 있습니다. 조사하는 동안 일시적인 노이즈를 줄이기 위해 Azure Pipelines의 Visual Studio Test 태스크에서 rerunFailedTests를 활성화하여 사용하세요.
파이프라인을 그린(green) 상태로 유지하기 위해 비결정적인 테스트를 격리(quarantine)하세요. 이들을 태그하고 별도의 스위트로 분리하여 실행 및 보고는 되지만 빌드를 실패시키지는 않도록 합니다. 격리된 테스트 부채는 Azure Boards 작업 항목으로 추적하세요.
근본 원인 분석에는 계측(instrumentation)이 필요합니다. 실행 중에 로그, 타이밍 메트릭, 환경 세부 정보를 캡처하세요. 동일한 시드와 종속성으로 로컬에서 재현하세요. 모의(mock) 처리되지 않은 시스템 시계, 네트워크, 파일 시스템에 대한 의존성을 제거하고, 소스에서 비결정성을 수정하세요.

Azure DevOps 및 Azure 테스팅 기능

Azure Test Plans는 최고 수준의 수동 및 탐색적 테스팅과 추적성을 제공합니다:

테스트 케이스는 단계, 예상 결과, 매개변수를 정의합니다. 공유 단계와 매개변수화된 테스트 케이스는 중복을 줄여줍니다. 요구 사항 기반 스위트는 케이스를 Product Backlog Item이나 사용자 스토리에 맞추고, 정적 및 쿼리 기반 스위트는 실행을 위해 테스트를 그룹화합니다.
테스트 실행은 테스터에게 스위트와 구성을 할당하고, 결과와 기간을 기록하며, 진단 정보를 캡처합니다. 풍부한 버그 리포팅에는 스크린샷, 비디오, 환경 데이터, 작업 로그가 포함됩니다.
탐색적 테스팅은 Test & Feedback 브라우저 확장 프로그램을 사용하여 애드혹 탐색 중에 차터, 세션 노트, 아티팩트를 캡처합니다. 발견된 사항을 작업 항목에 연결하고 요구 사항 및 테스트 세션의 커버리지를 분석합니다.

자동화된 테스팅은 파이프라인에 직접 통합됩니다:

Visual Studio Test 태스크(VsTest)를 사용하여 MSTest, NUnit, xUnit 테스트를 실행하고 TRX 결과를 게시합니다. .NET의 경우, 적절한 로거(trx, junit)와 함께

undefined

를 사용하는 것이 일반적입니다.

Java의 경우, Maven이나 Gradle을 통해 JUnit을 실행하고 Publish Test Results 태스크로 JUnit XML을 게시합니다. JavaScript의 경우, 러너(Jest, Mocha)가 JUnit XML을 생성하도록 구성합니다.
Publish Test Results는 여러 실행에 걸친 결과와 추세를 통합합니다. 결과 형식(TRX 또는 JUnit XML)을 표준화하여 리포팅을 통일하고 불안정한(flaky) 테스트 분석을 활성화합니다.
테스트 케이스를 자동화된 테스트 메서드에 매핑하여 자동화된 테스트 실행을 Azure Test Plans에 연결하고, 요구 사항에서 실행, 결함에 이르는 엔드투엔드 추적성을 보장합니다.

코드 커버리지는 측정 가능한 품질 가드레일입니다:

Coverlet(.NET용), JaCoCo(Java용), Cobertura/lcov(JavaScript용)로 커버리지를 수집합니다. Azure DevOps가 이해하는 형식으로 변환하고 Publish Code Coverage Results를 통해 게시하여 추세와 차이를 확인합니다.
빌드 시점에 최소 임계값을 강제합니다. .NET의 경우, Coverlet의 임계값 스위치를 사용하여 라인 또는 브랜치 커버리지가 정책 아래로 떨어지면 빌드를 실패시킵니다. 또는 Build Quality Checks 확장 프로그램을 사용하여 커버리지 및 추세 기반 정책을 적용할 수 있습니다.
커버리지 기반 배포 게이트는 품질이 저하될 때 진행을 막습니다. YAML에서는 커버리지가 목표 미만이면 품질 단계를 실패시킵니다. 클래식 릴리스의 경우, 승격 전에 측정된 커버리지를 검증하기 위해 Azure Function이나 REST 체크를 호출하는 게이트를 사용합니다.

성능, 카오스, 그리고 복원력

부하 및 성능 테스트는 비기능적 요구 사항을 조기에 그리고 지속적으로 검증합니다:

Azure Load Testing은 Application Insights의 백엔드 원격 분석 데이터와 상관관계를 분석하면서 대규모 JMeter 기반 부하를 오케스트레이션합니다. JMX 테스트 계획을 가져오고, 통과/실패 기준(예: p95 지연 시간, 오류율)을 설정하며, 결과를 파이프라인에 표시합니다. 기준선이 충족되지 않으면 Azure Monitor 게이트나 환경 검사를 사용하여 진행을 차단합니다.
Apache JMeter는 프로토콜 수준의 부하 테스트를 위한 다목적 선택지로 여전히 유효합니다. 스레드 그룹과 단언문(assertion)은 CI를 위해 매개변수화된 상태로 유지합니다. JMX 및 CSV 데이터셋은 코드와 함께 저장하고 시나리오와 함께 버전을 관리합니다.
k6는 개발자 친화적인 ‘코드형 부하 테스트(load testing as code)‘를 가능하게 합니다. Azure Pipelines에서 컨테이너나 Node 런타임을 통해 k6를 실행하고, 결과를 캡처하며, 게시를 위해 JUnit이나 JSON으로 내보냅니다. k6 스크립트 내의 임계값 표현식을 사용하여 실행을 확정적으로 실패시킬 수 있습니다.
기준선 관리는 매우 중요합니다. 환경별로 지연 시간, 처리량, 리소스 사용률 추세를 추적합니다. SLO를 설정하고 대표적인 데이터 볼륨 및 구성 하에서 테스트가 실행되도록 보장합니다.

카오스 엔지니어링은 장애 상황에서의 복원력을 검증합니다:

Azure Chaos Studio는 제어된 영향 반경(blast radius)과 안전 장치를 사용하여 Azure 리소스에 장애를 주입합니다. 실험 유형에는 VM의 CPU/메모리 압박, 네트워크 지연/블랙홀, 프로세스 종료, 서비스 제한(throttling) 등이 포함됩니다.
먼저 프리프로덕션 환경에서 실험을 실행하고 Application Insights와 Azure Monitor로 계측하여 장애 모드, 오류 예산, 자동 복구 동작을 캡처합니다.
복원력 검증은 카오스 실험을 상태 프로브 및 합성 트랜잭션과 결합하여 사용자의 핵심 경로가 계속 사용 가능하거나 정상적으로 성능이 저하되는지 확인합니다. 복원력 가설이 확인되고 경고가 설계된 대로 동작할 때만 승격합니다.

← 보안 · 모든 도메인 · 모니터링 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →