소프트웨어 테스팅 수명 주기(STLC)

✨ 핵심 요점: 소프트웨어 테스팅 라이프사이클(STLC)은 요구사항 분석부터 테스트 사이클 종료까지 일련의 체계적인 단계로, 검증 및 확인 과정을 통해 소프트웨어 품질을 보장합니다. 제가 QA 팀을 이끌어 온 경험에 따르면, 체계적인 STLC를 기반으로 테스트를 진행하면 결함 누출을 최대 30%까지 줄이고, RTM을 통한 추적성을 향상시키며, 테스트부터 릴리스까지 원활한 인계를 보장합니다.

소프트웨어 테스팅 수명주기

소프트웨어 테스팅 수명주기(STLC)란 무엇입니까?

소프트웨어 테스팅 라이프사이클(STLC)은 요구사항 분석, 테스트 계획, 테스트 케이스 개발, 테스트 환경 설정, 테스트 실행, 테스트 사이클 종료로 이어지는 구체적이고 구조화된 테스트 활동의 연속으로, 소프트웨어 품질을 체계적으로 검증하도록 설계되었습니다. 임시 테스트와 달리, STLC는 각 단계에 검증(verification)과 확인(validation)을 모두 포함하므로 테스트가 체계적이고 테스트 가능하도록 보장합니다.

실제로 STLC를 통해 출시 후 결함이 거의 40% 감소하는 것을 확인했습니다. 특히 팀이 요구 사항 담당자와 조기에 협력하고 견고한 RTM을 구축했을 때 더욱 그렇습니다. 이러한 단계를 통해 테스트 커버리지의 명확성을 확보하고 개발팀, QA팀, 그리고 이해관계자 간의 소통을 개선할 수 있습니다. RTM 기반 테스트를 사용하면서 승인 주기가 20% 단축되는 것을 확인했습니다.

전문가 조언: 항상 정의하세요 ENTRY 그리고 EXIT 조기 전환을 방지하기 위한 기준. 예를 들어, 테스트 계획이 공식적으로 검토되고 승인될 때까지 계획 단계에서 실행 단계로 진행하지 마십시오.

👉 소프트웨어 테스팅 배우기

STLC는 SDLC와 어떻게 다른가요?

STLC는 더 광범위한 소프트웨어 개발 수명 주기(SDLC)의 일부로, 테스트에만 집중합니다. SDLC가 요구사항 수집, 설계, 개발, 테스트, 배포 및 유지 관리를 포괄하는 반면, STLC는 계획, 실행 및 종료를 포함한 검증 단계만 다룹니다.

제 관점에서, V-모델 SDLC 내에 STLC를 구현하면 미러링 활동이 가능합니다. 예를 들어, STLC의 요구사항 분석은 요구사항 설계와 일치하고, 테스트 계획은 시스템 설계와 일치합니다. 이러한 추적성은 격차를 크게 줄여줍니다. 한 V-모델 프로젝트에서 STLC와 SDLC 단계를 일치시킴으로써 결함 포착률이 25% 향상되었고 테스트 재작업은 15% 감소했습니다.

각 SDLC 단계에 STLC를 내장하면 QA 영향력이 강화되고 조기 테스트 가능성 고려 사항이 보장되며 "황금의 길” 편견을 없애줍니다. 모든 개발 결과물이 테스트 결과물과 매칭되는 환경을 조성합니다.

소프트웨어 테스팅의 STLC에 대한 비디오

STLC의 6단계는 무엇입니까?

소프트웨어 테스팅 라이프사이클(STLC)은 포괄적인 소프트웨어 검증을 보장하는 체계적인 단계 순서입니다. 소프트웨어 개발 라이프사이클(SDLC)과 연계되어 품질을 보장합니다. 6가지 연속적인 단계는 다음과 같습니다.

STLC 단계
STLC 모델 단계
  1. 요구 사항 분석 : QA팀은 테스트 가능한 요구 사항을 분석합니다.
  2. 테스트 계획: 전략, 목표 및 테스트 결과물을 정의합니다.
  3. 테스트 케이스 개발: 자세한 테스트 사례와 스크립트를 만듭니다.
  4. 테스트 환경 설정: 테스트 실행을 위한 하드웨어/소프트웨어 구성.
  5. 테스트 실행 : 테스트 실행, 결과 기록, 결함 보고.
  6. 테스트 사이클 종료: 회고를 실시하고 보고서를 마무리합니다.

각 단계에는 명확한 시작 및 종료 기준, 이와 관련된 활동 및 결과물이 있습니다.

1단계) 요구 사항 분석

STLC의 요구 사항 분석이란 무엇입니까?

요구사항 분석은 소프트웨어 테스팅 수명 주기(STLC)의 첫 번째이자 가장 중요한 단계입니다. 요구사항 단계 테스팅이라고도 하는 이 단계는 테스트 팀이 테스트 관점에서 요구사항을 연구하여 테스트 가능한 구성 요소를 파악하는 기반을 형성합니다. 이 중요한 단계에서 QA 팀은 비즈니스 분석가, 제품 관리자, 개발자를 포함한 이해관계자들과 상호 작용하여 기능적 및 비기능적 요구사항을 포괄적으로 이해합니다.

주요 활동은 다음과 같습니다.

산출물 : RTM 및 타당성 보고서.

이 단계에서는 테스트 노력이 비즈니스 목표에 부합하는지 확인하여 이후 범위 확장과 재작업을 방지합니다.

필수 소프트웨어 테스트 PDF 다운로드

2단계) 테스트 계획

테스트 계획은 어떻게 STLC의 성공을 이끄는가?

이 단계에서는 수석 QA 관리자 포괄적인 것을 개발합니다 테스트 계획 정의하는 범위, 목표, 예산 및 일정. 도구에 대한 결정(예: Selenium, JUnit, TestNG) 및 프레임워크가 완성되어 프로젝트 요구 사항과의 호환성이 보장됩니다. 이 단계에서는 테스트 범위, 방법론 및 일정을 결정하고 후속 단계를 안내하는 테스트 프레임워크를 구축합니다.

주요 활동은 다음과 같습니다.

  • 테스트 전략 문서 초안 작성.
  • 자원 및 역할 할당.
  • 자동화/수동 접근 방식 선택.
  • 노력 추산 및 이정표 일정 수립.

산출물 : 승인된 테스트 계획 및 노력 추정 보고합니다.

이 단계는 다음과 같은 역할을 합니다. 테스트 라이프사이클의 청사진실행을 시작하기 전에 위험, 종속성 및 우발적 사태가 해결되도록 보장합니다.

3단계) ​​테스트 케이스 개발

품질 보증을 위해 테스트 케이스 개발이 중요한 이유는 무엇입니까?

테스트 케이스 개발 단계에서는 테스트 케이스와 자동화 스크립트를 체계적으로 생성, 검증, 개선하여 테스트 계획을 실행 가능한 작업으로 전환할 수 있습니다. 이 단계에서는 요구 사항을 자세한 테스트 케이스 및 자동화 스크립트각 케이스는 입력, 예상 출력, 그리고 사전/사후 조건을 명시합니다. 강력한 테스트 스위트는 커버리지를 보장하고 결함 누락을 최소화합니다. 대부분의 소프트웨어 장애는 부적절한 테스트에서 기인하기 때문에 이는 매우 중요합니다. 이 단계에서는 전략적 계획과 실제 구현을 연결하여 포괄적인 테스트 커버리지를 보장합니다.

주요 활동은 다음과 같습니다.

  • 테스트 케이스 설계 및 검토.
  • 만들기 테스트 데이터 비즈니스 시나리오에 맞춰 조정됨.
  • 가능한 경우 반복적인 테스트 흐름을 자동화합니다.

산출물 : 기준 테스트 케이스/스크립트 및 테스트 데이터 세트.

동료 검토와 버전 관리는 정확성을 보장하고 중복을 줄입니다. 이 단계가 끝나면 QA 팀은 검증되고 재사용 가능한 저장소 테스트 아티팩트를 통해 구조적이고 효율적인 실행을 보장합니다.

4단계) 테스트 환경 설정

효과적인 테스트 환경을 구축하는 방법은?

테스트 환경 설정은 테스트가 수행되는 소프트웨어 및 하드웨어 조건을 정의하며, 최적의 효율성을 위해 테스트 케이스 개발과 병행하여 실행됩니다. 이 단계에는 테스트가 수행될 배포 인프라를 준비하는 과정이 포함됩니다. 이는 QA 팀의 요구 사항에 따라 DevOps 또는 시스템 관리자가 처리하는 기술적인 작업입니다.

참고로 테스트 환경 설정 단계를 나열해 보겠습니다.

  • 단계 1) 필요한 하드웨어, 소프트웨어 및 네트워크 구성을 식별합니다.
  • 단계 2) 운영 체제, 데이터베이스, 애플리케이션 서버를 설치합니다.
  • 단계 3) 테스트 데이터와 연결을 구성합니다.
  • 단계 4) 환경 준비 상태를 확인하기 위해 연기 테스트를 실시합니다.

산출물 : 환경 설정 체크리스트, 스모크 테스트 결과, 완전히 검증된 테스트 환경.

5단계) 테스트 실행

테스트 실행 단계를 성공적으로 만드는 요인은 무엇인가?

테스트 실행 단계에서 테스터는 준비된 환경에서 빌드된 애플리케이션에 대해 개발된 테스트 케이스를 실행하여 결함을 식별합니다. 실행에는 다음이 포함됩니다. 수동 실행, 자동화 스크립트 및 회귀 테스트각 테스트 결과는 통과/실패로 기록되며, 불일치 사항은 로그 및 스크린샷과 같은 증거를 포함한 상세 버그로 보고됩니다. 테스트가 실패하면 버그가 기록되고 개발자에게 할당되어 수정 후 다시 테스트됩니다.

테스트 실행은 종종 여러 사이클로 발생합니다.

  1. 제정신
  2. 리그레션
  3. 재시험

이는 새로운 코드 변경으로 인해 기존 기능이 손상되지 않도록 하기 위한 조치입니다. 통과율 및 결함 밀도와 같은 지표가 추적됩니다.

주요 활동은 다음과 같습니다.

  • 계획된 테스트를 실행합니다.
  • 심각도 및 우선순위 태그와 함께 결함을 기록합니다.
  • 수정 사항을 다시 테스트하고 회귀 검사를 수행합니다.

산출물 : 실행 상태, 테스트 결과 로그 및 RTM 업데이트 결함 보고합니다.

이 단계에서는 소프트웨어가 기능적 및 비즈니스 요구 사항을 충족하는지 검증합니다.

6단계) 테스트 주기 종료

테스트 주기를 마감하면 향후 테스트가 어떻게 최적화되나요?

테스트 주기 종료는 포괄적인 평가, 보고 및 지식 확보를 통해 테스트 활동을 마무리합니다. 테스트 목표 달성 및 결과의 공식적인 문서화를 보장합니다. 이 단계는 테스트 경험을 지속적인 프로세스 개선 및 향후 프로젝트 성공을 위한 실행 가능한 통찰력으로 전환합니다. Less여기서 배운 내용은 향후 테스트 주기를 크게 개선하는 데 도움이 됩니다.

주요 활동은 다음과 같습니다.

  • 테스트 요약 및 종료 보고서를 준비합니다.
  • 병목 현상을 파악하기 위해 회고를 실시합니다.
  • 결함 밀도, 심각도 지수, 실행 추세 등의 측정 항목을 포착합니다.

산출물 : 테스트 종료 보고서 및 메트릭 대시보드.

이 단계에서는 이해 관계자들에게 다음을 제공합니다. 양적 통찰력 소프트웨어 품질에 대한 투명성과 책임을 보장합니다.

STLC의 진입 및 퇴출 기준은 무엇입니까?

진입 및 종료 기준은 각 STLC 단계에 규율을 부여하는 필수적인 체크리스트입니다. 이는 "품질 관문" 역할을 하여 필요한 투입 없이 단계가 시작되거나 검증된 산출물 없이 끝나는 것을 방지합니다. 또한, STLC 단계 진행 전 준비 상태와 완료 기준을 보장합니다. 

  • 참가 기준 (시작하기 위해 필요한 것) 각 STLC 단계에 진입하기 전에 반드시 충족해야 하는 전제 조건입니다. 예를 들어테스트 케이스 개발을 시작하려면 테스터는 최종 요구사항 문서, 워크플로우에 대한 명확한 이해, 그리고 완성된 테스트 계획을 갖춰야 합니다. 이를 통해 조기 작업과 재작업을 방지할 수 있습니다.
  • 종료 기준(종료하기 위해 전달해야 하는 내용) 단계를 종료하고 다음 단계로 넘기기 전에 무엇을 완료해야 하는지 정의해야 합니다. 예를 들어 테스트 케이스 개발에서는 모든 테스트 케이스를 작성 및 검토하고, 테스트 데이터를 준비하고, 자동화 스크립트(해당하는 경우)를 준비해야 합니다. 이를 통해 테스트 케이스의 완성도와 전환 준비를 보장합니다. 이러한 엄격한 핸드오프는 간과된 결과물을 방지하여 결함을 최대 30%까지 줄입니다(업계 평균 QA 주기 연구 기준). 예시: 테스트 케이스, 데이터, 자동화 아티팩트가 모두 승인된 경우에만 단계를 래핑합니다.

STLC 단계별 진입 및 종료 기준

참가 기준 종료 기준
요구 사항 분석
  • 요구 사항 문서 사용 가능
  • 사업 사양 확정
  • RTM이 생성되었습니다
  • 테스트 전략 정의
테스트 계획
  • 요구사항 분석 완료
  • 테스트 전략 승인됨
  • 테스트 계획 승인됨
  • 할당된 리소스
테스트 케이스 개발
  • 테스트 계획 승인됨
  • 요구사항 이해됨
  • 테스트 케이스 검토됨
  • 테스트 데이터 준비됨
테스트 환경 설정
  • 환경 요구 사항 정의
  • 이용 가능한 인프라
  • 환경 준비 완료
  • 연기 테스트 통과
테스트 실행
  • 테스트 케이스 준비 완료
  • 빌드 배포됨
  • 환경 안정
  • 테스트 케이스 실행됨
  • 중요한 결함이 해결되었습니다
테스트 마감
  • 테스트 실행 완료
  • 종료 기준 충족
  • 마감 보고서 서명 완료
  • 보관된 유물

STLC의 자동화: 무엇, 언제, ROI

STLC의 자동화 수동 개입 없이 특수 도구와 스크립트를 사용하여 테스트 사례를 자동으로 실행하는 것을 말합니다. 테스트 자동화 테스트 실행 단계 동안 기존 수동 테스트 프로세스를 자동화된 워크플로로 변환하여 인적 노력을 크게 줄이는 동시에 증가시킵니다. 테스트 범위 그리고 일관성.

The 자동화 타당성 분석 테스트 자동화는 요구 사항 단계에서 발생하며, 팀은 어떤 테스트를 효과적으로 자동화할 수 있는지 평가합니다. 주요 요소로는 테스트 안정성, 재사용성, 복잡성 등이 있습니다. 제 분석에 따르면, 기업의 72%가 전체 QA 예산의 10%에서 49%를 테스트 자동화 관련 지출에 할당합니다.

자동화를 구현해야 하는 경우: 여러 환경에서 일관된 실행이 필요한 회귀 테스트, 스모크 테스트, 그리고 반복적인 기능 테스트에 집중하는 것을 추천합니다. 자동화된 테스트는 예측 가능한 결과와 높은 실행 빈도를 가진 안정적인 기능에 가장 효과적입니다.

테스트 자동화의 ROI 매력적인 비즈니스 가치를 제공합니다. 현재 업계 상황을 면밀히 조사한 결과, 테스트 자동화를 사용하는 기업의 79%가 ROI에 만족하고 있으며, 50% 이상의 기업이 자동화 테스트 도구 도입 후 70년 이내에 ROI를 달성했습니다. 자동화된 테스트는 테스트 단계에서 발견된 버그의 80~20%를 식별하며, 전체 테스트 작업을 최대 XNUMX%까지 줄일 수 있습니다. 자동화 ROI를 보여주는 주요 지표로는 실행 시간 단축, 테스트 커버리지 증가, 조기 결함 감지를 통한 수정 비용 절감 등이 있습니다.

STLC의 Agile/CI/CD 변형

애자일 STLC 기존의 순차적 폭포수 방식에서 벗어나 반복적인 개발 스프린트 내에 테스트 활동을 통합합니다. 애자일 환경에서는 STLC 단계가 겹쳐지고 지속적으로 실행됩니다.요구 사항 분석, 테스트 계획 및 테스트 사례 개발이 개발 활동과 동시에 진행됩니다.

주요 특성: 애자일 STLC는 2~4주 스프린트에 맞춰 더 짧은 테스트 주기, 개발자와 테스터 간의 지속적인 협업, 그리고 즉각적인 피드백 루프를 제공합니다. 기존의 폭포수형 모델과 달리 애자일은 실시간 협업을 가능하게 하여 출시 속도를 높이고 소프트웨어 품질을 향상시킵니다.

CI / CD 통합 자동화된 테스트를 배포 파이프라인에 직접 내장하여 STLC를 혁신합니다. DevOps에서 지속적인 테스트는 소프트웨어 개발 라이프사이클 전반에 걸쳐 테스트를 자동으로 실행하여 모든 단계에서 품질과 기능을 보장하는 방식입니다. 테스트 실행은 코드 커밋에 의해 트리거되고 빌드 프로세스와 통합되어 완전히 자동화됩니다.

DevOps STLC 자동화된 테스트 스크립트를 통한 지속적인 테스트를 강조하고 CI/CD 파이프라인 내에서 배치를 찾습니다. Jenkins와 GitHub은 모든 코드 업데이트 시 테스트 실행을 자동화하여 팀이 문제를 조기에 발견할 수 있도록 지원합니다. 이러한 접근 방식은 신속한 피드백을 제공하고, 수동 테스트 오버헤드를 줄이며, 개발 라이프사이클 전반에 걸쳐 일관된 품질 검증을 보장하여 소프트웨어 안정성을 유지하면서도 배포 주기를 단축합니다.

메트릭 및 품질 보고서(중앙 집중식)

중앙 집중식 대시보드는 현대 테스트 팀에 매우 중요합니다. 테스트 커버리지, 결함 밀도, 이탈률과 같은 주요 지표를 단일 데이터 소스로 통합하여 제공합니다. 중앙화된 품질 보고 모든 STLC 단계의 테스트 지표를 통합 대시보드와 종합 보고서로 통합합니다. 이러한 체계적인 접근 방식을 통해 이해관계자는 개발 라이프사이클 전반에 걸쳐 테스트 진행 상황, 결함 추세 및 전반적인 소프트웨어 품질 상태를 실시간으로 파악할 수 있습니다.

주요 STLC 지표: 주요 STLC 지표에는 테스트 실행률, 결함 밀도, 테스트 커버리지 비율, 결함 해결 시간이 포함됩니다. 이러한 지표는 팀이 테스트 효과를 평가하고 출시 준비 및 품질 개선에 대한 데이터 기반 의사 결정을 내리는 데 도움이 됩니다.

테스트 종료 보고서 완료된 테스트 활동, 테스트 케이스 실행 결과, 결함 통계 및 품질 평가를 요약하는 중앙 집중식 품질 보고의 주요 결과물로 활용됩니다. 체계적인 STLC 보고를 도입한 조직은 출시 후 결함을 40개월 이내에 XNUMX% 감소시키고 고객 만족도를 높이는 성과를 달성했습니다.

고품질 대시보드 요소 일반적으로 실시간 테스트 실행 상태, 심각도 분류를 통한 결함 추적, 기능 영역별 테스트 커버리지 지표, 그리고 시간 경과에 따른 품질 개선 추세 분석을 제공합니다. 최신 테스트 도구는 자동화된 보고서 생성 기능을 제공하여 품질 지표를 지속적으로 모니터링하고 프로젝트 이해관계자와 관리팀의 사전 예방적 의사 결정을 지원합니다.

일반적인 함정 및 최고의 사례

탄탄한 계획이 있더라도 팀은 몇 가지 일반적인 어려움에 직면할 수 있습니다. 다음 모범 사례는 이러한 함정을 효과적으로 헤쳐나가는 데 도움이 될 수 있습니다.

  • 함정 1: STLC에서 테스트가 너무 늦게 시작되어 결함을 조기에 발견하는 것에 비해 수정하는 데 드는 비용이 5~10배 더 많이 듭니다.
    최고의 연습: 좌측 이동 방식을 적용합니다. 즉, 요구 사항 및 설계 검토 중에 테스트를 시작하여 결함을 더 일찍 포착하고 비용과 노력을 줄입니다.
  • 함정 2: 요구 사항이 명확하지 않거나 오해되면 잘못된 테스트 케이스와 낭비된 사이클이 발생합니다. 
    최고의 연습: 위험 기반 테스트를 사용하여 결함이 비즈니스에 가장 큰 영향을 미치는 영역에 초점을 맞춰 사례의 우선순위를 지정합니다.
  • 함정 3: 리소스가 제한적이거나 테스터의 기술이 부족하면 테스트 범위와 품질이 저하됩니다.
    최고의 연습: 테스트-종료 단계에서는 얻은 교훈을 문서화하고, 전략을 개선하고, 향후 주기를 위해 기술 격차가 해소되도록 합니다.
  • 함정 4: 자동화를 간과하면 반복적인 수동 작업이 발생하고, 출시 주기가 늦어집니다.
    최고의 연습: 회귀 테스트를 가속화하고 빌드 전체의 일관성을 개선하기 위해 테스트 자동화 프레임워크를 조기에 통합합니다.
  • 함정 5: 개발자, 테스터, 비즈니스 분석가 간의 의사소통이 부족하면 서비스 범위에 차이가 생기고 지연이 발생합니다.
    최고의 연습: Jira나 Confluence와 같은 도구를 사용하여 기능 간 협업을 장려하여 테스트 목표를 비즈니스 요구 사항에 맞춥니다.

제품 개요

소프트웨어 테스팅 라이프사이클은 품질 보증의 초석으로 자리 잡고 있으며, 기존의 순차적 프로세스에서 최신 개발 방법론과 완벽하게 통합되는 적응형 프레임워크로 진화하고 있습니다. 요구 사항 분석부터 테스트 종료까지 STLC의 체계적인 접근 방식을 따르면 포괄적인 커버리지를 확보하고 결함이 프로덕션 환경에 도달할 가능성을 줄일 수 있습니다. 이 방법론의 효과는 측정 가능합니다. 자동화된 테스트는 수동 테스트에 비해 시간과 비용을 최대 40% 절약할 수 있습니다. 소프트웨어 테스팅 분야의 고용 기회는 XNUMX년까지 증가할 것으로 예상됩니다. 22 년 ~ 2020 년 2030 %이는 구조화된 품질 보증 관행에 대한 수요가 증가하고 있음을 반영합니다.

자주 묻는 질문

아니요. 소프트웨어 개발 수명 주기(SDLC)는 요구 사항부터 배포까지 소프트웨어 구축의 전체 프로세스를 포괄하는 반면, 소프트웨어 테스팅 수명 주기(STLC)는 제품 품질 보장을 위한 테스트 단계에만 집중합니다. 두 수명 주기는 병렬적으로 진행되지만 서로 다른 목표를 다룹니다.

네. 프로젝트 규모에 관계없이 STLC는 체계적인 테스트 계획, 실행 및 결함 추적을 보장합니다. 이를 생략하면 결함 누출이 더 심해지는 경우가 많은데, 연구에 따르면 운영 환경에서 결함을 수정하는 데 테스트보다 최대 30배 더 많은 비용이 소요될 수 있습니다.

네. Agile에서는 STLC 단계가 더 짧고 반복적이며, 각 스프린트에 테스트가 통합되어 있습니다. 다음과 같은 도구가 있습니다. JUnit, Selenium및 Cypress 팀이 회귀 주기를 자동화하고 빠르게 품질을 유지할 수 있도록 지원합니다.

네. STLC는 버그를 조기에 발견하고 테스트를 비즈니스 목표에 맞춰 조정함으로써 재작업 비용을 줄이고 출시 기간을 단축합니다.

네. 자동화에서도 테스트 케이스 설계, 환경 설정, 실행과 같은 STLC 단계는 매우 중요합니다. 자동화는 실행 속도를 높일 뿐이며, STLC 원칙이 없으면 테스트 커버리지가 저하됩니다.

네. 실제로 테스트 계획 및 테스트 설계와 같은 단계가 겹치는 경우가 많은데, 특히 Agile 및 DevOps 파이프라인에서 그렇습니다. 겹치는 단계를 통해 유휴 시간을 줄이고 피드백 루프를 빠르게 진행하여 팀이 결함을 조기에 감지할 수 있도록 지원합니다. 이러한 적응성 덕분에 STLC는 기존 워크플로와 최신 워크플로 모두에 적합합니다.

네. STLC는 다양한 OS 버전, 화면 크기 및 기기 구성으로 인해 모바일 테스트에 매우 중요합니다. 실행 단계에서는 에뮬레이터와 클라우드 기반 기기 팜을 활용하여 더 넓은 커버리지를 확보합니다.