작업 중인 인터페이스 변경이 검토를 통과했습니다. 버튼이 정렬되었고 새로운 복사본이 승인되었으며 팀의 선호하는 휴대폰에서 빌드가 깨끗합니다. 그런 다음 사용자들이 다른 장치에서 체크아웃이 실패한다는 보고가 들어오고, 권한 요청이 잘못된 시점에 나타나고, 배경에서 돌아오면 장바구니가 빈 상태로 남아있다는 보고가 들어옵니다. 변경된 화면에서 구매와 관련된 것이 보이지 않았지만 릴리스는 중요한 여행을 깨트렸습니다.
앱 회귀 테스트는 이러한 위험을 통제하기 위해 설계되었습니다. 모바일 앱은 런치 시 상태를 보존하고 운영 체제의 동작에 의존하며 다양한 하드웨어와 네트워크에서 작동하며 점점 더 웹 번들 업데이트를 тради적인 앱 스토어 릴리스 주기 외부에서 받습니다. 따라서 신뢰할 수 있는 전략은 새로운 code이 작동하는지 여부를 테스트하는 것뿐만 아니라 모든 전달 경로에서established 행동이 살아남는지 여부를 테스트해야 합니다.
목차
- 앱 회귀 테스트 이해
- 회귀 테스트 목표, 유형 및 모바일 도전
- 회귀 테스트를 위한 실질적인 전략
- CI/CD PIPELINE에 회귀 테스트 통합
- 회귀 테스트 성능 및 관찰성 측정
- Regression Testing Workflows for Capacitor 및 Electron과 함께 Capgo
- 회귀 테스트 관행을 통합
앱 회귀 테스트 이해
회귀 테스트는 애플리케이션의 기존 동작이 변경 후 여전히 작동하는지 확인합니다. 변경은 버그修정, 라이브러리 업데이트, 시각적 조정, 네이티브 구성 변경 또는 원격으로 전달된 자바스크립트 번들일 수 있습니다. 중앙적인 질문은 간단합니다: 이 변경이 누구도 의도하지 않은 변경을 방해한 것이 무엇인가?
쇼핑 앱이 체크아웃 아이콘을 교체하는 경우를 고려해 보겠습니다. 집중된 기능 테스트는 새로운 아이콘의 렌더링 및 탭 반응을 확인합니다. 다시 테스트하면 이전에 보고된 체크아웃 오류가 수정된 것을 확인할 수 있습니다. 회귀 테스트는 더 나아가서 체크아웃을 둘러싼 화면, 백그라운드 및 프레그라운드 전환, 오프라인 복구, 취소, 네비게이션 상태, 저장소, 분석, 네트워크 서비스와 공유하는 경로를 확인합니다.
실용적인 규칙: 재 테스트는 알려진 오류가 수정되었는지 확인합니다. 회귀 테스트는 예상치 못한 다른 피해를 찾습니다.
변경된 컴포넌트에 대한 녹색 테스트는 오남용된 자신감을 불러일으킬 수 있다. UI 선택자는 버튼을 찾을 수 있지만, 상태 복원 오류로 인해 결제 화면이 올바른 장바구니를 받지 못할 수 있다. 테스트는 와이파이에서 통과할 수 있지만, 혼잡한 연결에서 지연된 응답은 경쟁 조건을 드러낼 수 있다. 회귀 테스트 스위트는 안전망으로 작용하지만, 그만큼의 사용자가 앱을 사용하는 방식에 대한 커버리지만큼만 커버리지가 반영되어야 한다.
자동화된 검사는 반복 가능한 여행에 가치가 있다. 그러나 자동화는 품질과 다르다. 앱 팀을 위한 자동화된 테스트에 대한 실용적인 개요는 기초를 구축하는 데 도움이 될 수 있지만, 모바일 회귀 작업은 생명 주기, 장치, 네트워크 및 릴리스 채널 시나리오를 추가해야 한다. 회귀 테스트는 앱 팀을 위한 자동화된 테스트에 대한 실용적인 개요다. 2016년 회귀 테스트 연구 조사
조사 460편의 논문 31가지 기술 25개의 연구 회귀 테스트의 발전을 보여준다. 초기 경험적 평가에서 광범위한 비용 및 오류 감지 효율성에 대한 초점으로. 배포 팀에게는 실용적인 교훈이 있다. 회귀 테스트는 선택 논리, 유지 보수 및 증거가 필요하며, 릴리스 전에 마지막 체크박스로만 끝나지 않는 엔지니어링 관행이다.회귀 테스트 목표, 유형 및 모바일 난관 정의
회귀 테스트는 앱 팀을 위한 자동화된 테스트에 대한 실용적인 개요다.
강력한 회귀 테스트 프로그램은 세 가지 결과를 동시에 보호합니다. 보고된 결함이 해결되었는지 확인하고, 영향을 받지 않는 영역에 새로운 결함이 들어가지 않도록 방지하고, 사용자가 이미 의존하는 기능의完整성을 유지합니다. 이러한 결과를 층별로 가정한 집안 보안과 같은 방식으로 다루세요. 연기 감지기가 위험을 빠르게 감지하고, 잠금된 문은 일반적인 위험을 차단하고, 모니터링 시스템은 무슨 일이 일어났는지 조사하는 데 도움이 됩니다.
각 테스트 유형을 작업에 매칭하세요
단위 테스트 작은 논리 조각을 고립된 상태에서 검사합니다. 예를 들어, 가격 계산기나 허가 상태 매핑기와 같은 것들입니다. 그들은 빠르고 정확하지만, 저장소에서 오래된 데이터를 받는 계산기가 잘 작동하는지 확인하지 못합니다.
통합 테스트 컴포넌트 간의 경계를 확인합니다. 예를 들어, 지역 데이터베이스, 인증 서비스 및 동기화 층 사이의 연결입니다. 이러한 테스트는 완전한 장치 여행이 시도되기 전에 계약 및 데이터 흐름 문제를 노출합니다.
기능 테스트 사용자의 관점에서 완전한 기능을 검증합니다. '아이템을 추가하고 앱을 닫고 다시 열고 체크아웃을 완료'하는 것은 여러 시스템을 실행하고 더 강한 자신감을 제공합니다.
UI 테스트 visible 화면, 제스처, 키보드 동작, 대화상자 및 네비게이션과 상호 작용합니다. 모바일 경험에 필수적이지만, 타이밍, 렌더링 및 환경 차이에 더 민감합니다.
팀들은 범위도 선택합니다. 전체 회귀 전체 회귀 테스트는 모든 테스트 세트를 실행합니다. 부분 회귀 부분 회귀 테스트는 영향을 받은 영역에 집중합니다. 선택적 회귀 선택적 회귀 테스트는 변경 영향에 따라 테스트를 선택합니다. 흡연 회귀 흡연 회귀 테스트는 앱이 깊이 있는 테스트가 필요하다고 결정하기 위해 필수 경로를 확인합니다.
모바일 환경을 고려하세요.
모바일 회귀 테스트는 앱 주변 환경이 변경될 때 어려워집니다. 기기 및 운영 체제 분산은 레이아웃, 권한, 키보드 동작, WebView 렌더링 및 하드웨어 백업 기능에 영향을 미칩니다. 네트워크 변동성은 지연된 응답, 연결이 끊어짐, 캡티브 게이트웨이 및 연결된 상태에서 연결이 끊어짐으로 전환하는 등 지연된 응답을 유발합니다.
앱 라이프 사이클은 또 다른 위험 계층을 만듭니다. 사용자는 결제 흐름 중 전화 통화를 받을 수 있습니다. 업로드 중 문서를 잠금 화면으로 잠그거나 요청이 대기 중일 때 애플리케이션을-switch합니다. 또는 운영 체제가 메모리를 회수한 후 다시 돌아옵니다. 테스트는 명시적인 점검점을 필요로합니다. 배경과 전경 전환, 상태 복원, 중단된 다운로드 및 다시 시도 동작.
Live 업데이트 는 전통적인 앱 스토어 테스트에서 놓치기 쉬운 배포 경계를 추가합니다. 설치된 네이티브 셸은 JavaScript, CSS, 구성, 또는 자산이 원격으로 변경되어도 바뀌지 않을 수 있습니다. 따라서 regression 범위는 업데이트기능 자체를 다루어야 하며, 업데이트된 화면만 다루지 않아야 합니다. 업데이트 감지, 패키지完整성, 설치 타이밍, 네이티브 레이어와의 호환성, 새로운 패키지가 실패할 때 복구를 검증해야 합니다.
보다 광범위한 품질 계획을 위해 팀은 앱 품질 보증 지침 을 사용하여 테스트 디자인과 릴리즈 제어를 연결할 수 있습니다. 핵심 원칙은 사용자가 경험하는 제품의 일부로 모든 환경, 라이프 사이클 이벤트, 및 배포 채널을 다루어야 함을 의미합니다.
효과적인 Regression 테스트를 위한 작전 가능한 전략
Regression 테스트 스위트가 유용해질 때는 신뢰할 수 있는 feedback를 지속 가능한 비용으로 생산할 수 있습니다. 모든 테스트를 모든 편집 후 실행하는 것은 안전해 보이지만, 실행 속도가 느리고 무의미한 실패로 신호가 묻힐 수 있습니다. 테스트 스위트를 영향, 위험, 자동화 품질, 유지보수.
변경 영향에 따라 테스트를 선택
Regression 테스트를 시작하기 전에 변경 맵을 생성하세요. 변경된 파일, 영향을 받은 모듈, 공유 서비스, 데이터 저장소, 네이티브 브리지, 사용자 여행을 식별하세요. 재사용 가능한 네비게이션 컴포넌트의 변경은 단일 화면에 고립된 복사 편집보다 더 광범위한 커버리지가 필요합니다.
테스트 레이블을 명시적으로 생성하여 pipeline이 지능적으로 선택할 수 있도록 하세요:
- 중요 경로: 로그인, 결제, 결제 확인, 데이터 제출, 계정 복구.
- 라이프 사이클: 냉각 시작, 온도 시작, 배경 반환, 강제 종료, 중단된 작업.
- 플랫폼: 권한 요청, 키보드 동작, 깊이 링크, 카메라 접근, 푸시 처리.
- 비주얼: 레이아웃, 타이포그래피, 반응형 간격, 동적 콘텐츠, 다크 모드 동작.
- 업데이트 경로: 탐지, 다운로드, 설치, 시작, 호환성, 롤백.
2023년 논문은 모바일 앱 전략을 제시하며 이전 테스트를 분류합니다. 기존, 재테스트, 재사용 모델 변경에 따라 테스트를 분류하는 대신, 업데이트 후 모든 테스트를 다시 실행하는 대신, 연구 기초를 읽으려면 모바일 회귀 테스트 학위 논문을 참조하라. 모바일 회귀 테스트 학위 논문 실무에서는 팀이 변경-테스트 매트릭스를 유지하면서 같은 아이디어를 표현할 수 있다. code.
파일 이름만 의존하지 마라. 공유 API 클라이언트의 변경은 편집되지 않은 화면에 영향을 줄 수 있다. 개발자에게 영향을 받은 여행을 포함하는 pull request를 요청하고 QA가 위험을 검토할 수 있도록 하라.
실행 전 위험을 우선순위로 지정하라
위험 기반 우선순위 지정은 가장 손상된 실패를 우선순위로 지정한다. 다음 질문을 사용하여 시나리오를 질적으로 평가하라:
- 수익, 안전, 개인 정보, 규제 데이터를 보호하는 경로가 있는가?
- 변경이 몇 개의 컴포넌트를 건너가나?
- 이 영역이 이전에 실패한 적이 있는가?
- 시나리오가 장치, OS, 네트워크, 라이프 사이클 조건에 의존하는가?
- 팀은 잘못된 릴리스로 빠르게 복구할 수 있나요?
중요한 스모크 체크를 먼저 실행하세요. 로그인이나 앱 런칭이 실패하면 더 깊은 스위트를 중단하고 빌드를 고치세요. 통합 및 기능적 여행을 다음으로 실행하고, 넓은 장치 및 시각적 커버리지를 예약하세요. 스크립트가 잘못된 요구 사항을 판단하지 못하는 새로운 상호 작용, 모호한 요구 사항 및 사용성 결정에 대한 수동 탐색적 테스트는 여전히 해당합니다.
안정적인 여행을 자동화하세요, 모든 동작은 자동화하지 마세요.
반복 가능하고 관찰 가능하며 가치 있는 자동화 대상만 선택하세요. 단위 테스트는 비즈니스 규칙을 처리할 수 있고 Jest는 자바스크립트 모듈을 검증할 수 있으며 장치 프레임워크는 네이티브 동작 및 UI 흐름을 실행할 수 있습니다. 자바스크립트 논리 작업을 하는 팀은 Jest 단위 테스트 관행을 사용하여 빠른 체크를 __CAPGO_KEEP_0__ 근처에 유지하세요. 빠른 체크를 code 근처에 유지하세요.
안정적인 접근성 식별자를 사용하여 취약한 텍스트나 위치 선택자보다.
- 실행 전에 데이터를 생성하거나 fixture를 초기화하세요.
- 의미 있는 결과를 확인하세요, 단순히 탭이 완료된 것을 확인하지 마세요.
- 실패 시 로그, 스크린샷, 장치 세부 정보 및 네트워크 컨텍스트를 캡처하세요.
- 비즈니스 진술과 탐색 도우미를 분리하여 UI 변경이 불필요한 재작성을 강요하지 마세요.
- UI 변경으로 불필요한 재작성으로부터 비즈니스 논리와 네비게이션 헬퍼를 분리하세요.
예를 들어, 주문 확인 테스트는 주문 식별자가 확인 후에 나타나야 하며, 성공 후에만 장바구니가 비워져야 하며, 실패한 결제는 회복 가능한 장바구니 상태를 보존해야 한다고 주장해야 합니다. 그런 주장은 팀이 무엇이 깨졌는지 알려주지만, 최종 '화면 로드' 확인은 손상된 흐름을 통과할 수 있습니다.
원천에서 불안정성을 줄이기
재시도는 일시적인 인프라 오류와 반복 가능한 제품 결함을 구별할 수 있지만, 재시도는 불안정성을 숨기지 않도록 해야 합니다. 첫 번째 실패를 기록하고,_artifacts_를 보존하고, 다른 시도 후에만 통과할 때 테스트를 의심스럽게 표시하세요.
테스트를 안정화하기 위해 애플리케이션 신호를 기다리기보다 임의의 지연을 기다리지 마십시오. 네트워크 요청이 settle, 로딩 상태가 사라지거나 도메인 이벤트가 발생할 때까지 기다리십시오. 시계, 랜덤 값, 기능 플래그 및 테스트 계정의 제어를 위해, 네트워크 시나리오에서 핵심 기능 확인을 위해 결정론적인 서비스 응답을 사용하고, 나중에 지연성과 실패를 의도적으로 연습하는 별도의 테스트를 유지하십시오.
불안정한 테스트를 검토하기 위해 테스트 시스템의 결함으로 간주하십시오. 불안정한 테스트는 중재 시간을 소비하고, 개발자에게 빨간 pipe line을 무시하도록 훈련합니다. 그것을 재구성하십시오, 환경 원인을 분리하거나, 의미 있는 동작을 보호하는 경우에만 제거하십시오.
팀 표준: 테스트는 팀이 실패 신호를 이해하고 그것에 행동할 수 있을 때만 블록킹 스위트에 속해야 합니다.
마지막으로, 동일한 확인을 중복하는 테스트를 제거하세요. 각 동작에 대한 하나의 강력한 확인을 유지하고, 위험이 높은 경우에는 에지 케이스를 추가하고, 예약된 장치 세션으로 이동하여 광범위한 탐색적 커버리지를 예약하세요. 소규모의 명확한 소유권을 가진 테스트 세트는 nobody가 신뢰하지 않는 큰 컬렉션보다 더 유용한 보호를 제공합니다.
CI/CD PIPELINE에 Regression Testing 통합
Regression testing은 CI/CD 내에서 승인 결정에 영향을 미치고, 배포 후에 수동 작업으로 나타나서는 안 됩니다. 실제 pipeline은 빠른 feedback와 신뢰도가 증가할 때 커버리지 확장을 시작합니다.
pull request는 linting, 단위 테스트, 그리고 smoke regression 세트를 트리거할 수 있습니다. 성공적인 머지 후에는 Capacitor 또는 Electron 패키지를 빌드하고, clean test 환경을 제공하고, 테스트 데이터를 시드하고, 통합 및 중요 end-to-end 여행을 실행할 수 있습니다. 예약된 작업은 더 광범위한 장치, 시각, 라이프 사이클, 및 네트워크 테스트를 실행할 수 있습니다. 또한, 릴리스 후보는 가장 깊은 검증을 받습니다.
테스트 환경을 재현할 수 있도록 하세요. 애플리케이션 빌드, 테스트 데이터 버전, 서비스 스텁, 기능 플래그, 및 장치 구성에 대한 버전을 고정하세요. 실패가 발생할 때, 팀은 애플리케이션 변경 여부를 확인할 수 있어야 합니다.
유용한 승인 패턴은 다음과 같습니다:
Pull request → fast checks → build → targeted regression → staging validation → release approval → production monitoring
Independent 테스트를 병렬화 하되, 설정 및 파괴 시나리오의 의존성 순서를 보존하십시오. GitHub Actions, GitLab CI, 및 Jenkins는 모두 이 패턴을 조율할 수 있습니다. 단, pipeline은 artifact를 발행하고, 차단 테스트가 실패할 때 올바른 단계를 실패시켜야 합니다.
2023년 실증 연구에서 발견한 결과입니다. 기능 그룹 커밋의 81.83%는 2시간 이상 지난 시점에 발생했습니다., 2–24 시간 범위 내의 32.57% 그리고 24 시간 이상의 49.26%. 안드로이드 회귀 테스트 연구 커밋 타이밍 및 클러스터링을 rerun 빈도 및 테스트 결과 신선도와 연결합니다. 모바일 팀에게는, 예약된 스위트는 의미 있는 빌드 또는 릴리스 이벤트와 연결되어야 하며, 시간이없는 증거로 다루어지지 않아야 합니다.
업데이트 경로에는 자신의 pipeline 작업이 필요합니다. 스테이징 채널에 업데이트를 배포하고, 대표적인 기기에서 업데이트를 설치한 후, 런치 및 중요 흐름을 검증한 후에만 승격하십시오. 단, 번들 및 롤백 동작이 통과해야 합니다. CI/CD 통합 테스트 지침을 참조하십시오. context 배포 자동화와 테스트 결과를 연결하는 방법을 찾는 중입니다.
회귀 테스트 성능 및 관찰성 측정
성공한 테스트 스위트가 자동으로 건강한 회귀 테스트 프로그램을 의미하지는 않습니다. 팀은 테스트가 관련성, 안정성, 시간성 및 사용자가 경험하는 오류와 연결되어 있는지 측정해야 합니다. 테스트 시스템의 건강도와 애플리케이션의 품질을 분리하여 추적해야 합니다.
| 지표 | 목적 | 페이지/영역: Capgo 마케팅 웹사이트. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 메시지 키 `subprocessors_table_purpose` (Subprocessors Table Purpose). |
|---|---|---|
| 주요 지표 | 테스트 통과율 | Sustained failures or sudden changes after a code update |
| __CAPGO_KEEP_0__ 업데이트 후 지속적인 오류 또는 갑작스러운 변경 | 불안정한 테스트 실패율 | __CAPGO_KEEP_0__ |
| 실행 시간 | 팀이 피드백이 곧 도착하는지 결정하는 데 도움이 됩니다. | 총 또는 critical-path 지연 시간의 성장 |
| Code 커버리지 | code 경로를 테스트하는 테스트가 실행하는 경로를 보여줍니다. | 고위험 모듈 내의 논리적 결함 |
| field 실패율 | 이전 릴리스 결과와 프로덕션 동작을 연결합니다. | 릴리스 또는 업데이트와 관련된 사용자 사고 |
이러한 것들을 트렌드로 간주하십시오. 높은 통과율은 나쁜 커버리지가 숨길 수 있고, 광범위한 code 커버리지도 허가 시간, 장치별 렌더링, 또는 중단된 라이프 사이클을 놓치실 수 있습니다. field 실패율은 특히 유용합니다. 이는 테스트 스위트 뒤에 있는 가정에 대한 테스트입니다.
모바일 회귀 테스트 스위트 중 많은 수가 오직 사용자에게 도달한 버그의 30%에서 40%는happy-path 스크립트는 상태에 의존하는 실패, 운영 체제 인터럽트 및 실제 장치의 다양성을 놓치기 때문에 모바일 리그레션 테스트 커버리지 분석 사용자가 실제로 사용하는지 여부를 ауд이트할 때 테스트 스위트가 대표하는지 여부를 확인하는
Instrument every test run with build identifier, commit, device model, OS version, locale, network profile, test-data version, duration, retry count, and failure artifact links. In production, capture update version, startup result, crash context, failed API operation, and lifecycle state without collecting unnecessary personal data. Per-device dashboards make patterns visible, such as a failure limited to one rendering engine or a particular update cohort.
Use 필요한 개인 데이터를 수집하지 않고. 각 장치의 대시보드를 사용하여 패턴을 식별할 수 있습니다.
Regression Testing Workflows for Capacitor 및 Electron과 함께 Capgo
A Capacitor team has finished a payment-flow change. The native shell doesn’t need modification, but the JavaScript bundle does. Instead of treating remote delivery as a shortcut around testing, the team adds it as another release artifact with its own promotion and rollback plan.
{"text":"CI에서 workflow가 시작됩니다. 변경된 code에 대해 단위 테스트와 통합 테스트가 실행되고, 인증, 카트 상태, 결제, 저장소 및 네비게이션에 대한 기능 테스트가 수행됩니다. 빌드는 웹 번들을 생성하고, 커밋, 의존성 상태, 네이티브 호환성 기대치 및 테스트 결과를 기록합니다. Electron 팀은 같은 원칙을 따르며, 윈도우 라이프 사이클, 파일 시스템 권한, 자동 업데이트 동작 및 플랫폼 렌더링과 같은 데스크톱 전용 커버리지도 추가합니다.", "context":"blog"}
{"text":"번들이 스테이징 채널로 이동합니다. 테스트 장치에서는 파일을 수동으로 교체하지 않고 정상적인 업데이트 경로를 통해 설치합니다. 클라이언트가 업데이트 감지, 다운로드한 패키지를 설치하고 예상된 라이프 사이클 단계에서 성공적으로 시작되며 사용자 상태를 유지하는지 확인합니다. 또한 다운로드 중단 또는 시작 시 호환되지 않는 경우 안전하게 회복 경로가 작동하는지 확인하기 위해 실패 조건을 강제합니다.", "context":"blog"}
{"text":"프로덕션 승격 전에 롤백 계획을 시작합니다.", "context":"blog"} {"text":"롤백을 시작하기 전에 어떤 신호가 롤백을 멈추게 할지, 누가 결정권을 가지고 있는지, 어떤 버전이 롤백이 안전한지, 지원 팀이 영향을 받은 사용자를 식별하는 방법을 정의해야 합니다. 서버가 이전 버전의 번들을 참조하는 것만으로는 롤백이 완료된 것이 아닙니다. 장치가 신뢰할 수 있는 방법으로 롤백 버전을 받고, 롤백 버전을 실행하고, 롤백 전 생성된 데이터를 유지할 수 있어야 합니다.", "context":"blog"}
대상 지정 기능은 위험을 줄여준다. 내부 사용자나 베타 사용자부터 시작하여 로그와 실패 패턴을 검사한 후에, 증거가 프로모션을 지지할 때까지 더 광범위한 채널로 확장한다. 버전 기록과 릴리스 노트를 배포 기록과 연결하여 인시던트 리스폰더가 앱 스토어 빌드와 관련이 없는 빌드를 검색하지 않고 변경된 것을 식별할 수 있도록 한다.
시각적 커버리지가 특별한 관리를 필요로 한다. 최근 토론에서 모바일 시각적 회귀 테스트는 수십 가지 장치 및 OS combination, 그리고 스크린샷 비교에서 거짓 양성 결과를 발생시키는 렌더링 차이를 고려해야 한다. 모바일 시각적 회귀 토론 또한 동적 콘텐츠, 애니메이션 타이밍, 메모리, 화면 크기, 네트워크 상태 및 배터리 상태를 변동의 원천으로 강조한다.
For Capacitor and Electron applications, separate visual baselines by meaningful rendering environment, mask timestamps and personalized content, wait for stable animation states, and review diffs rather than blindly accepting them. Test the native shell and the remotely delivered layer together where their contract meets. This approach lets a team ship a focused hotfix quickly while preserving the same discipline expected from a packaged release.
회귀 테스트 관행을 연결하는 것
테스트 설계, 변경 영향, CI/CD, 관찰성, 롤백 회귀 테스트 관행을 연결하는 것기본적으로 중요한 사용자 경로에서 시작하여, 라이프 사이클 및 환경 조건을 추가하고, 모든 차단 테스트에 명확한 소유자를 할당하세요. 선택적 실행을 사용하여 빠른 feedback를 얻고, 더 광범위한 스위트를 사용하여 릴리즈 신뢰도를 높이고, 인간 판단이 필요한 경우 탐색적 테스트를 사용하세요.
Capacitor 및 Electron 앱의 경우, 모든 live update을 제어 릴리즈로 다루세요. 배포본, 설치 경로, 영향을 받는 기기 집합, 복구 동작을 검증하고, 프로덕션 승인 전에 검사하세요. 빌드, 기기, OS, 채널, 라이프 사이클 상태에 따라 실패를 검토하고, 사용자 및 엔지니어가 만나는 것을 기반으로 스위트를 개선하세요.
다음 실제 단계는 하나의 고위험 경로를 매핑하는 것입니다. 예를 들어, 로그인 또는 결제와 같은 경로를 단위, 통합, UI, 라이프 사이클, 시각적, 롤백 검사에 걸쳐 매핑하세요. 그 맵을 CI에 넣고, 증거를 캡처하고, 개발, QA, 지원, 릴리즈 소유자와 함께 검토하세요. 그 다음에 다음 경로로 확장하세요.
Capgo는 CapacitorJS 및 Electron 앱에 대한 서명된 라이브 업데이트 전송을 제공하며, 대상 채널, 버전 기록, 기기별 로그, 수용 및 실패 메트릭, 자동 롤백 보호를 제공합니다. 그 제어를 사용하여 원격 배포본을 규칙적인 회귀 및 릴리즈 워크플로우에 통합하고, 다음으로 방문하세요. Capgo __CAPGO_KEEP_0__
