테스트를 위한 아키텍처 전략

이 Azure 잘 설계된 프레임워크 운영 우수성 검사 목록 권장 사항에 적용됩니다.

워크로드를 변경하는 경우 의도한 대로 작동하고 새로운 문제가 발생하지 않도록 해야 합니다. 테스트는 이러한 변경 내용을 평가하는 방법입니다. 품질을 유지하고 워크로드에 대한 신뢰를 구축하기 위한 필수 사례입니다.

효과적인 테스트는 안정적이고 고품질의 워크로드를 제공합니다. 결함이 프로덕션에 도달하지 못하게 하고, 비용이 많이 드는 재작업 및 지연을 줄이며, 개발 수명 주기 동안 비즈니스 목표에 맞게 작업을 유지합니다.

이 문서에서는 효과적인 테스트 사례를 통해 고품질 워크로드를 제공하는 데 도움이 되는 전략을 제공합니다. 성능, 안정성 및 보안과 같은 다른 핵심 요소의 특수한 테스트 지침에 대한 기본 지침으로 사용됩니다.

테스트 전략 및 계획 공식화

테스트 전략 및 테스트 계획은 필수 아티팩트입니다. 테스트 작업에 대한 명확한 로드맵을 제공하고 모든 사용자가 동일한 품질의 목표를 향해 작업할 수 있도록 합니다.

테스트 전략 정의

테스트 전략은 전반적인 테스트 접근 방식을 안내하는 개략적인 청사진입니다. 테스트 목표, 범위, 방법론, 도구, 역할 및 책임을 정의합니다. 우선 순위 테스트, 리소스 할당 및 위험 관리에 대한 정보에 입각한 결정을 내리는 데 도움이 됩니다. 또한 이해 관계자와 통신하고 결과를 보고하는 방법도 캡처합니다.

잘 정의된 테스트 전략은 이해 관계자로부터 구매를 가져오고 모든 팀 구성원이 일관된 품질 표준을 따르도록 합니다. 방향과 구조를 제공하고, 테스트를 비즈니스 목표에 맞게 조정하며, 장기적인 품질을 보호합니다.

일반적으로 테스트 전략은 지정된 워크로드에 대한 릴리스에서 일관성을 유지합니다. 그러나 항상 해당 워크로드의 특정 요구 사항 및 비즈니스 목표를 반영하도록 사용자 지정합니다.

계획 만들기

팀과 테스트 전략에 동의하면 비즈니스 목표에 맞는 사용 사례를 사용하여 테스트 계획에서 공식화합니다.

테스트 계획은 특정 릴리스에 대한 테스트 실행을 안내하는 자세한 문서입니다. 테스트 범위, 특정 테스트 사례, 결함 보고서, 타임라인, 리소스 할당, 테스트 작업의 진입 및 종료 기준에 대해 간략하게 설명합니다.

잘 구성된 테스트 계획은 테스트를 효율적이고 릴리스의 목표 및 타임라인에 맞게 조정합니다. 진행 상황을 추적하고 테스트 전체에서 정보에 입각한 결정을 내리기 위한 참조 지점입니다.

예: 전자 상거래 체크 아웃 시스템의 경우 테스트 전략은 모든 릴리스에서 일관된 접근 방식을 설정합니다. 결제 흐름이 항상 우선 순위가 지정되도록 정의하고, UI 테스트를 위한 Selenium, 부하 테스트를 위한 JMeter 및 보안 테스트를 위한 OWASP ZAP와 같은 시스템에 대한 테스트 도구를 지정하고, 다양한 테스트 유형에 대한 팀의 책임을 명확히 합니다. v2.5 릴리스에 대한 테스트 계획은 Apple Pay 지원을 추가하는 데 중점을 둡니다. 이 릴리스에서 Apple Pay를 테스트할 대상을 정확히 정의하고, 리소스(엔지니어 2대와 iOS 디바이스 3개)를 할당하고, 4주 일정을 설정하고, 명확한 진입 조건(코드 완료 및 환경 구성) 및 종료 조건(모든 테스트 통과, 중요한 버그 없음 및 2초 SLA)을 설정합니다.

조기 테스트, 자주 테스트, 중요한 사항 테스트

소프트웨어 개발 수명 주기의 초기 단계에서 테스트를 시작합니다. 중요한 문제가 늦게 발견되면 재작업이 증가하고 릴리스 속도가 느려집니다. 설계자는 디자인 단계에서 테스트 요구 사항을 간과하는 경우가 많기 때문에 전반적인 품질에 부정적인 영향을 미칩니다.

개발자는 품질 보증 사고 방식을 수용해야 합니다. 디자인하는 동안에도 테스트에 대해 생각해 보세요. 요구 사항을 명확히 하고 잠재적인 제한 사항을 파악하는 데 사용합니다. 테스트를 개발 프로세스의 필수적인 부분으로 만듭니다. 코드와 함께 테스트 작성 및 유지 관리의 소유권을 가져옵니다.

문제를 조기에 감지하면 신속하게 대응할 수 있습니다. 예를 들어 일상적인 버그 수정보다 사용자 환경에 영향을 주는 필수 디자인 변경의 우선 순위를 지정할 수 있습니다. 일찍 행동하면 막판의 놀라움과 지연이 줄어듭니다.

테스트는 일회성 이벤트가 아닙니다. 지속적인 테스트 사고방식의 일환으로 출시 후에도 테스트를 계속합니다. 테스트 제품군을 정기적으로 검토, 업데이트 및 확장하여 새로운 기능을 다루고 프로덕션에서 발견된 버그를 해결하여 장기적인 품질을 유지합니다.

절충. 초기 및 지속적인 테스트는 운영 비용을 증가시킬 수 있으며, 처음에는 개발 속도가 느려지거나 팀 내 마찰이 생길 수 있습니다. 균형을 맞추고, 초기에 필수적인 테스트 및 변경 내용을 식별하고, 이후 단계로 연기할 수 있습니다. 이렇게 하면 품질을 손상시키지 않고 효율성을 보장합니다.

안전 장치를 사용하여 프로덕션 환경에서 테스트

강력한 테스트 및 유효성 검사 사례를 사용하더라도 일부 문제는 실제 프로덕션 트래픽에서만 나타납니다. 시뮬레이션할 수 없는 문제를 찾으려면 사용자 노출을 제한하고 위험을 줄이는 안전 장치를 사용하여 프로덕션 환경에서 제어된 테스트를 수행합니다.

프로덕션 테스트를 계획, 격리 및 모니터링합니다. 이러한 방식으로 실제 사용자 피드백 및 성능 데이터를 수집하면서 광범위한 사용자 기반의 중단을 최소화할 수 있습니다.

워크로드가 종료 기준을 충족하고 강력한 품질을 보여 주는 경우에만 카나리아 릴리스와 같은 점진적 노출 전략을 고려합니다. 이 방법은 먼저 소규모의 대상 사용자 그룹에 대한 업데이트를 릴리스하여 시험판 환경에 나타나지 않을 수 있는 문제를 신속하게 파악할 수 있도록 합니다. 이 방법을 사용하면 테스트 프로세스를 가속화하고 관련 비용을 줄일 수 있습니다.

위험: 실제 고객에게 직접적인 영향을 주기 때문에 프로덕션 환경에서 테스트할 때는 주의해야 합니다. 항상 보호 장치를 구현하고 노출을 제한하여 비즈니스에 잠재적인 부정적인 영향을 최소화합니다.

테스트 검사에서 계층화된 접근 방식 적용

계층화된 테스트 검사 전략을 통해 신속한 피드백, 이전의 결함 감지 및 더 빠른 릴리스를 제공합니다. 레이어에서 테스트를 구조화할 때 결함을 신속하게 격리하고 디버그하여 문제를 보다 쉽게 파악하고 해결할 수 있습니다.

테스트 피라미드를 가이드로 사용

테스트 피라미드 모델은 테스트 자동화에 대한 이 계층화된 접근 방식을 보여 줍니다. 실행 시간 및 유지 관리 비용을 최소화하면서 검사를 최대화하기 위해 여러 계층에 테스트를 분산합니다.

• 기본 계층: 단위 테스트는 개별 구성 요소를 격리된 상태로 확인합니다. 신속하게 실행하고 즉각적인 피드백을 제공합니다.
• 중간 계층: 통합 테스트는 구성 요소와 서비스 간의 상호 작용을 확인합니다. 단위 테스트보다 더 느리게 실행되지만 시스템 동작에 대한 광범위한 범위를 제공합니다.
• 최상위 계층: 엔드 투 엔드 테스트는 전체 시스템을 통한 사용자 경험의 유효성을 검사하여 실제 시나리오를 시뮬레이션합니다. 이러한 테스트는 가장 느리지만 전반적인 품질에 대해 가장 높은 신뢰도를 제공합니다.

기본 및 중간 계층 테스트는 최소한의 종속성을 가지므로 파이프라인에 더 쉽게 통합할 수 있습니다. 이 통합은 테스트가 실패할 때 신속한 피드백을 가능하게 하고 빌드 프로세스를 즉시 중지하여 잘못된 코드가 더 이상 진행되지 않도록 합니다.

테스트 범위가 증가함에 따라 파이프라인 실행 시간이 크게 증가할 수 있습니다. 병렬 및 분산 테스트 실행 전략을 사용하여 빠른 피드백 루프를 유지 관리하여 범위가 증가하는 경우에도 파이프라인을 효율적으로 유지합니다.

절충. 테스트 커버리지와 파이프라인 효율성 간에는 절충이 있습니다. 테스트 제품군이 클수록 적용 범위가 늘어나지만 실행 시간과 비용도 증가합니다. 항상 의미 있는 투자 수익을 제공하는 것은 아닙니다.

별도의 애플리케이션 및 인프라 테스트

애플리케이션 코드 테스트와 인프라 코드 간에 명확한 구분을 만듭니다. 소프트웨어를 배포하고 이에 대한 테스트를 실행하여 애플리케이션 동작을 관찰하여 인프라의 유효성을 검사합니다.

애플리케이션 스모크 테스트를 실행하면 프로덕션에 영향을 주기 전에 네트워크 오류, DNS 구성 오류 또는 리소스 제약 조건과 같은 인프라 문제가 발생할 수 있습니다. 예를 들어 API 상태 엔드포인트의 유효성을 검사하는 스모크 테스트는 인프라 프로비전 문제 또는 네트워크 정책 문제를 신속하게 검색할 수 있습니다.

이 접근 방식을 사용하면 애플리케이션별 테스트가 인프라 문제를 사전에 식별하고 해결하여 별도의 인프라 유효성 검사의 필요성을 줄입니다. 코드와 기본 인프라가 모두 올바르게 함께 작동한다는 확신을 줍니다.

다양한 유형의 테스트 통합

워크로드 전체에서 다양한 테스트 방법을 사용합니다. 단위 테스트를 완료해도 테스트가 완료된 것은 아닙니다. 워크로드의 모든 측면에는 고유한 접근 방식이 필요합니다. 여러 테스트 유형은 전반적인 품질을 향상시키고 시스템이 의도한 대로 작동하는 신뢰도를 구축합니다.

워크로드 완성도 및 위험 프로필에 따라 올바른 테스트 유형을 선택합니다. 테스트 피라미드 계층을 통해 기능 유효성 검사로 시작한 다음 성능, 보안 및 복원력과 같은 비기능 테스트를 추가합니다. 테스트 유형 선택을 워크로드의 중요한 시나리오 및 위험에 맞춥니다.

다음 표에서는 테스트 주기 내내 다양한 테스트 유형을 적용하는 시기를 보여 줍니다. 각각은 특정 위험을 해결합니다. 이 테이블은 가능한 모든 테스트 형식의 전체 목록은 아니지만 설명 예제로 사용됩니다.

각 기능을 평가하거나 비즈니스 영향 및 위험에 따라 변경합니다. 이 평가에 따라 테스트 형식의 우선 순위를 지정합니다. 고객 관련 워크로드의 경우 엔드투엔드 및 UI 테스트를 강조합니다. API 기반 워크로드의 경우 통합 및 계약 테스트에 집중합니다. 고가용성 시스템의 경우 복원력 및 혼돈 테스트에 투자합니다.

절충. 릴리스 프로세스 시작 시 보안 테스트를 우선시하십시오. 이 방법은 취약성을 방지하고 더 안전한 배포를 보장하는 데 도움이 됩니다. 그러나 이 우선 순위는 프로덕션에 새로운 기능을 제공하는 속도를 늦출 수 있습니다.

테스트 자산을 코드 자산만큼 중요하게 처리

테스트 자산은 필수 비즈니스 규칙, 에지 사례, 기록 결함 패턴 및 중요한 조직 지식을 캡처합니다. 테스트 품질이 저하되면 팀은 실제 결함을 찾는 대신 신뢰할 수 없는 테스트를 디버깅하는 데 시간을 낭비합니다. 이 경우 좌절이 발생하며 개발자는 테스트 프레임워크에 대한 신뢰를 잃게 됩니다.

테스트 자산을 코드 자산과 동일한 엄격함으로 처리합니다. 테스트 자산에 대한 모든 책임을 맡으면 테스트 프레임워크의 안정성과 전반적인 품질이 모두 향상됩니다.

테스트 구조화 및 보안

애플리케이션 코드와 동일한 아키텍처 원칙을 사용하여 테스트 코드를 구성합니다. 가능하면 동일한 리포지토리에 코드와 함께 테스트를 유지하여 유지 관리를 간소화하고 일관성을 촉진합니다.

자동화 도구 모음이 별도의 리포지토리에 있는 경우 필수 코드 검토, 끌어오기 요청 정책 및 품질 표준을 유지하기 위한 유효성 검사 파이프라인 빌드와 같은 동등한 거버넌스 컨트롤을 구현합니다.

테스트는 종종 프로덕션 데이터 및 시스템과 상호 작용하여 가져온 라이브러리 또는 취약한 테스트 코드의 위험을 초래할 수 있습니다. 취약성을 방지하기 위해 테스트 코드에서 보안 코딩 사례를 구현합니다. 프로덕션 코드와 동일한 보안 표준으로 테스트를 처리합니다.

테스트 데이터를 코드와 함께 버전 관리합니다. 데이터 스키마 또는 비즈니스 규칙을 변경하는 경우 현재 워크로드 상태와 일치하도록 테스트 데이터를 업데이트합니다.

사용자 고유의 테스트에 대한 기준 유효성 검사를 수행하여 예상대로 작동하는지 확인합니다. 모든 오류는 테스트 결함이 아니라 실제 애플리케이션 문제를 가리킵니다. 테스트가 적절하게 실패하고 워크로드가 정상일 때 일관되게 통과하는지 확인합니다. 신뢰할 수 없는 테스트를 즉시 처리하고 테스트 어설션이 각 테스트의 의도를 강화하도록 합니다.

테스트 데이터 격리, 공유 상태 방지, 적절한 설정 및 해체 프로세스 구현과 같은 테스트 독립성 및 안정성을 보장하는 사례를 설정합니다. 테스트 데이터의 자동화된 정리를 구현합니다. 병렬 테스트 실행을 활용하려면 결과에 영향을 주지 않고 순서대로 실행할 수 있도록 테스트를 독립적으로 디자인합니다. 독립 테스트는 항상 자체 데이터 및 종속성을 설정하고 분해해야 하므로 상태는 다음 테스트 실행으로 이월되지 않습니다.

애플리케이션에서 테스트에서 시퀀싱이 필요한 경우 순서가 지정된 테스트 실행을 지원하는 테스트 프레임워크를 사용합니다.

테스트 유지 관리 및 발전

테스트 자산을 유지 관리하는 것은 워크로드 품질을 유지하는 데 중요합니다. 이러한 자산에는 중요한 조직 지식이 포함되어 있는 경우가 많습니다. 정기적으로 유지 관리하지 않으면 빠르게 구식이 되어, 그 효율성과 고품질 릴리스를 제공할 수 있는 당신의 능력을 저해합니다.

워크로드가 발전함에 따라 비즈니스 목표에 맞게 테스트 자산이 병렬로 진화해야 합니다. 프로덕션 코드와 동일한 아키텍처 원칙을 테스트 디자인에 사용합니다.

회귀 테스트 도구 모음에는 가장 중요하고 안정적인 테스트가 포함되어야 합니다. 작게 시작하고 의도적으로 회귀 제품군을 확장합니다. 프로덕션 인시던트가 발생할 때, 중요한 버그를 수정할 때 및 위험 수준이 높은 변경 내용을 도입할 때 테스트를 추가합니다. 사용자의 개입 없이 일관되게 실행되도록 회귀 제품군을 자동화합니다. 모든 커밋에서 실행되는 빠른 스모크 테스트와 야간 또는 릴리스 전에 실행되는 광범위한 회귀 테스트를 만듭니다.

테스트 사례는 의도, 범위 및 예상 결과를 캡처합니다. 테스트 자동화 스크립트와 테스트 사례를 모두 동기화 상태로 유지하는 것이 중요합니다. 자동화 스크립트가 해당 테스트 사례와 다른 경우 유효성 검사되는 내용을 추적하기가 어려우며, 이로 인해 적용 범위와 책임의 격차가 발생합니다.

워크로드에 새로운 기능과 향상된 기능을 도입할 때 테스트 사례에 대한 정기적인 업데이트를 사전에 계획합니다. 테스트 케이스 자동화 시, 원래 테스트 케이스에 자동화를 연결하여 커버리지를 추적할 수 있도록 하십시오.

테스트 기술 부채 관리

정기적인 테스트 유지 관리 스프린트를 예약하여 부채가 과도해지기 전에 누적 부채를 해결하세요.

신뢰할 수 없는 테스트, 중복 커버리지, 구식 테스트 및 부실한 테스트 설계는 모두 테스트 부채에 기여합니다. 신뢰할 수 없는 테스트를 식별할 때 테스트 도구 모음의 무결성을 유지하기 위해 수정 또는 제거의 우선 순위를 지정합니다. 신뢰할 수 있는 테스트의 적은 수의 집합은 신뢰할 수 없는 테스트의 많은 수의 집합보다 더 가치가 있습니다.

테스트 건너뛰기 또는 지연에 대한 전략적 결정은 테스트하는 것만큼이나 중요합니다. 비즈니스 논리가 없는 간단한 getter 및 setter, 매우 드문 에지 사례, 타사 라이브러리 및 제거하도록 예약된 레거시 코드와 같은 사소한 또는 저위험 코드에 대한 테스트를 건너뛰는 것이 좋습니다. 팀이 컨텍스트 변경으로 다시 확인할 수 있도록 이러한 결정을 문서화합니다.

테스트 제품군을 평가하고 신뢰할 수 있고 일관된 테스트를 외부 변경 가능성이 있는 테스트와 분리합니다. 빈번한 UI 업데이트의 영향을 받는 UI 테스트와 같이 컨트롤 외부의 요인으로 인해 자주 중단되는 테스트는 자동화에 적합하지 않을 수 있습니다. 이러한 분리를 통해 자동화할 테스트와 수동으로 유지할 테스트를 결정할 수 있습니다.

절충. 취약한 테스트를 제거하면 자동화 커버리지가 줄어듭니다. 자주 변경되는 UI 요소에 대한 수동 테스트를 수락하면서 안정적인 인터페이스 및 중요한 워크플로에 자동화를 집중하여 이 감소의 균형을 맞춥니다.

모든 테스트가 지속적인 유지 관리를 받을 자격이 있는 것은 아닙니다. 제거한 기능, 중복 검사 테스트 및 더 이상 가치를 제공하지 않는 테스트에 대한 테스트를 사용 중지합니다. 팀에서 결정을 명확하게 할 수 있도록 테스트를 제거하는 이유를 문서화합니다.

테스트 프레임워크로 관찰성 확장

테스트의 가시성은 테스트 프레임워크가 안정적으로 작동하도록 보장하고 워크로드의 품질과 상태에 대한 지속적인 가시성을 제공하는 두 가지 주요 목표를 달성합니다. 관찰 사례를 테스트 프레임워크에 통합하면 진단 기능을 강화하고, 안정성을 실시간으로 모니터링하며, 테스트 프로세스의 지속적인 개선을 추진합니다.

이러한 가시성이 없으면 문제를 진단하는 데 상당한 어려움이 있고, 시스템을 실시간으로 모니터링하는 기능이 제한되며, 자동화 적용 범위 효율성에 대한 명확하고 실행 가능한 인사이트를 얻을 수 없습니다.

테스트 도구 모음은 시간이 지남에 따라 악화되거나, 테스트가 불안정해지거나, 관련성을 잃거나, 워크로드 변경을 따라잡지 못합니다. 가시성을 통합하면 테스트 도구 모음의 상태를 효과적으로 모니터링하고, 오류를 신속하게 파악하고 해결하며, 유지 관리 우선 순위 및 개선 사항에 대한 정보에 입각한 결정을 내릴 수 있습니다. 검사 보고서를 생성하면 자동화의 격차를 더 쉽게 식별할 수 있습니다. 테스트 검사가 프로덕션 인시던트에서 관찰 가능성 데이터와 일치하면 팀은 적절한 유효성 검사가 부족한 시나리오에 대한 인사이트를 얻습니다.

프레임워크 내에서 업계 표준 테스트 검사 및 보고 도구를 사용하여 다음을 수행합니다.

• 테스트된 코드 경로에 대한 명확한 가시성 제공
• 일관되게 실패한 테스트 식별
• 테스트 안정성의 장기 추세 분석
• 대상 개선에 대한 오류의 원본 추적

위험: 로그가 일관되지 않고 지나치게 세부적인 경우 값보다 더 많은 노이즈가 생성되어 디버깅이 더 어려워질 수 있습니다. 명확하고 실행 가능한 메시지와 다양한 세부 정보 수준을 사용하여 구조화된 로깅을 구현하여 로그가 팀을 압도하지 않고 의미 있는 인사이트를 제공하도록 합니다.

실제 조건 시뮬레이션

최종 사용자 관점에서 워크플로를 평가하여 고객의 요구와 기대치를 진정으로 충족하는지 확인합니다. 워크로드에 대한 명확한 수용 기준을 정의하고 격리된 시스템 동작뿐만 아니라 실제 사용자 흐름과 환경을 정확하게 반영하는 테스트를 디자인합니다.

전략적으로 범위 크기 조정

위험 및 가치에 따라 테스트 검사 크기를 조정합니다. 고객 환경에 직접적인 영향을 주는 고부가가치 사용자 경험 및 중요한 경로에 대한 적용 범위의 우선 순위를 지정합니다. 워크로드 복잡성이 증가함에 따라 워크로드 품질 및 안정성에 대한 가장 높은 신뢰를 제공하는 시나리오를 평가하여 테스트 범위를 확장합니다.

위험: 단일 사용자 흐름에 초과 투자하지 마세요. 중요한 경로에 대한 충분한 범위를 달성하면 다른 중요한 영역으로 포커스를 이동합니다. 한 흐름에서 완벽보다는 균형 잡힌 커버리지를 위해 노력합니다.

비즈니스 목표 및 SLO에 맞게 조정

비즈니스 목표와 SLO(서비스 수준 목표)를 모두 사용하여 테스트를 정렬합니다. 비즈니스 약정 및 사용자 기대치를 반영하는 측정 가능한 품질 임계값을 설정합니다. 이러한 임계값은 편차를 감지하고 오류를 해결하는 참조 지점을 제공하므로 동의합니다. 이 방법은 주요 서비스 품질 임계값이 손상되지 않도록 하여 사용자 환경을 보호합니다. 기준 메트릭을 정기적으로 검토하고 업데이트하여 현재 고객의 요구 사항과 기대치를 계속 충족하는지 확인합니다.

대표 테스트 데이터 사용

테스트 데이터는 가능한 한 밀접하게 실제 시나리오를 나타내야 합니다. 가상 데이터는 프로덕션 데이터 처리의 복잡성을 방지하면서 본격적인 사용자 시나리오를 시뮬레이션할 수 있습니다. 예를 들어 가상 테스트는 계획된 크기 조정 조건에서 워크로드가 수행하는 방식을 평가하기 위해 대표 데이터 세트를 생성하여 실제 시나리오를 복제할 수 있습니다.

테스트에 프로덕션 데이터를 사용해야 하는 경우 중요한 정보를 보호하기 위해 모든 정보를 올바르게 익명화해야 합니다.

가상 데이터를 기본 선택 항목으로 사용합니다. 가상 데이터가 데이터 마이그레이션 스크립트 테스트와 같이 필요한 복잡성을 복제할 수 없는 특정 시나리오에 대해 프로덕션 데이터를 예약합니다.

프로덕션 환경 시뮬레이션

프로덕션 환경은 실제 조건에서 워크로드가 어떻게 동작하는지 이해하기 위한 진실의 원천입니다. 프로덕션 환경에서 시스템이 예상대로 수행한다고 신뢰할 수 있도록 실제 조건을 밀접하게 반영하는 환경을 만듭니다.

워크로드의 특정 요구 사항에 맞게 프로덕션 환경을 미러링하는 방법을 조정합니다. 고가용성이 필요한 중요 업무용 워크로드의 경우 프로덕션과 매우 유사한 전용 환경에서 테스트합니다. 이러한 워크로드의 경우 강력한 유효성 검사의 필요성과 비용 최적화의 균형을 신중하게 조정합니다. 성능 및 부하 테스트를 위해 프로덕션과 유사한 전용 환경을 사용하여 서비스 동작이 현실적인 조건에서 정확하게 평가되도록 합니다.

다른 워크로드의 경우, 프로덕션 인프라와 유사하게 환경을 구성하여, 낮은 환경에서 테스트는 성공하지만 프로덕션에서 실패하는 경우와 같은 오류를 줄이도록 합니다. 코드가 파이프라인을 통해 진행됨에 따라 모든 환경에서 일관성을 목표로 합니다. 인프라, 데이터 및 보안을 비롯한 워크로드의 다양한 측면을 통해 프로덕션 조건을 시뮬레이션하여 안정적인 테스트 결과를 보장합니다.

환경을 프로덕션 환경으로 미러링하면 구성 드리프트가 품질에 대한 잘못된 신뢰도를 생성할 수 있습니다. 구성 드리프트에 대한 자동화된 유효성 검사를 구현하여 환경이 프로덕션에 맞게 유지되도록 하여 이를 방지합니다. 적절한 경우 테스트를 시작하기 전에 올바른 버전이 배포되었는지 확인하도록 배포 게이트를 설정합니다.

위험: 프로덕션 환경을 미러링하면 운영 비용이 크게 증가할 수 있습니다. 임시 환경 또는 영구 테스트 환경이 워크로드에 대한 비용 효율성과 품질 간의 최적 균형을 제공하는지 여부를 평가합니다.

용도 기반 테스트 환경 빌드

의도한 목적에 명확한 초점을 맞춘 환경을 디자인합니다. 테스트 수명 주기에서 각 단계의 고유한 요구 사항을 평가하고 환경이 해당 단계의 목표와 밀접하게 일치하는지 확인합니다.

기능 유효성 검사, 통합 테스트 또는 기타 용도에 관계없이 테스트의 특정 단계 및 목표에 맞게 모든 테스트 환경을 의도적으로 디자인합니다. 간소화된 환경이 테스트 요구 사항을 효과적으로 충족하는 경우 효율성을 극대화하기 위해 해당 접근 방식의 우선 순위를 지정합니다.

모의 서비스 사용

모든 테스트 시나리오에 대한 프로덕션 시스템의 전체 복제는 종종 실용적이지 않습니다. 중요한 비즈니스 워크플로를 손상시키지 않고 테스트를 위해 안전하게 복제할 수 있는 워크로드의 구성 요소를 평가합니다. 전체 복제가 가능하지 않은 경우 프로덕션 서비스 동작을 정확하게 시뮬레이션하는 모의 서비스를 사용하여 라이브 작업의 위험 없이 시나리오의 유효성을 효과적으로 검사합니다.

용도 기반 테스트 환경은 임시 환경에 모의 서비스를 배포하기 위한 이상적인 기반을 제공합니다. 임시 환경은 테스트를 위한 프로덕션 조건을 시뮬레이트하는 비용 효율적인 방법을 제공합니다. 모든 테스트 시나리오에 대해 전체 프로덕션과 유사한 환경을 유지 관리하는 오버헤드 없이 상호 작용 및 동작의 유효성을 검사할 수 있습니다. 이러한 주문형 환경은 특정 테스트 목적으로 만들어지고 사용 후 제거되어 테스트 품질을 유지하면서 인프라 비용을 절감합니다.

임시 환경을 구축하려면 워크로드가 IaC(Infrastructure as Code) 및 배포 파이프라인을 사용하는 자동화가 잘 설정된 더 높은 완성도 수준에 도달해야 합니다.

Azure 지원

Azure Test Plans 는 계획된 수동 테스트, 사용자 승인 테스트, 예비 테스트 및 관련자의 피드백 수집에 필요한 모든 기능을 제공하는 브라우저 기반 테스트 관리 솔루션입니다. 시간이 지남에 따라 테스트 품질을 추적하고 개선 영역을 식별하는 테스트 분석 이 포함됩니다.

Azure Pipelines를 사용하면 CI/CD 파이프라인에 테스트를 통합할 수 있습니다. Azure와 통합된 GitHub Actions 를 사용할 수도 있습니다.

Azure App Testing 은 기능 및 성능 테스트를 지원하는 서비스입니다. 이를 통해 Azure Load Testing을 사용하여 Playwright 작업 영역 및 성능 테스트를 사용하여 기능 테스트를 실행할 수 있습니다.

Azure 배포 환경은 보안을 극대화하면서 일관성과 모범 사례를 설정하는 프로젝트 기반 템플릿을 사용하여 앱 인프라를 스핀업하는 데 도움이 될 수 있습니다.

또한 Azure는 안정성, 성능 및 보안 테스트를 지원하는 플랫폼 네이티브 도구를 제공합니다.

관련 링크

• 성능 테스트에 대한 권장 사항
• 안정성 테스트에 대한 권장 사항
• 보안 테스트에 대한 권장 사항

운영 효율성 체크리스트

전체 권장 사항 세트를 참조하세요.