작업 중인 UI 변경 사항이 검토를 통과했습니다. 버튼이 정렬되었고 새로운 복사본이 승인되었으며 빌드는 팀의 선호하는 전화에서 깨끗하게 보입니다. 그러나 사용자들은 다른 장치에서 체크아웃이 실패하고, 권한 요청이 잘못된 시점에 나타나고, 백그라운드에서 돌아오면 장바구니가 비어있다고 보고합니다. 변경된 화면에서 구매와 관련된 것이 보이지 않았지만 릴리스는 중요한 여행을 깨트렸습니다.
리그레션 테스트는 이러한 위험을 제어하기 위해 설계되었습니다. 모바일 앱은 상태를 런칭 간에 보존하고, 운영 체제의 동작에 의존하고, 다양한 하드웨어와 네트워크에서 작동하고, 점점 더 웹-배달 업데이트를 받는 전통적인 앱 스토어 릴리스 주기 외에. 신뢰할 수 있는 전략은 새로운 code이 작동하는지 여부를 테스트하는 것 외에도, 모든 배포 경로에서established 동작이 살아남는지 여부를 테스트해야 합니다.
목차
- 리그레션 테스트 이해
- 리그레션 테스트 목표, 유형 및 모바일 문제
- Regression 테스트의 효과적인 전략
- CI/CD Pipe라인에 Regression 테스트 통합
- Regression 테스트 성능 및 관찰성 측정
- Regression Testing Workflow를 위한 Capacitor 및 Electron의 Capgo
- Regression 관행을 통합하는 방법
애플리케이션 Regression 테스트 이해
Regression 테스트는 애플리케이션의 기존 동작이 변경 후 여전히 작동하는지 확인하는 것입니다. 변경은 버그 수정, 라이브러리 업데이트, 시각적 조정, 네이티브 구성 변경 또는 remotely delivered JavaScript bundle일 수 있습니다. 중앙적인 질문은 간단합니다: 이 변경이 누구도 의도하지 않은 변경을 방해한 것이 무엇인지 알아내야 합니다.
쇼핑 앱을 예로 들어서, 체크아웃 아이콘을 교체한 경우, 새로운 아이콘의 렌더링과 탭 반응을 확인하는 포커스된 기능 테스트를 진행한다. 이전에 보고된 체크아웃 버그가 수정되었는지 확인하기 위해 다시 테스트를 진행한다. 회귀 테스트는 체크아웃을 수정한 컴포넌트와 관련된 다른 경로를 확인한다. 예를 들어, 체크아웃과 관련된 화면, 로그인, 장바구니 저장, 할인 처리, 결제 전환, 취소, 오프라인 복구, 배경 및 전면 전환, 체크아웃을 окруж하는 화면 등이다. 이러한 경로는 수정된 컴포넌트와 공유하는 네비게이션 상태, 저장소, 분석, 네트워크 서비스를 공유할 수 있다.
실용적인 규칙: 다시 테스트하는 것은 알려진 버그가 수정되었는지 확인하는 것이다. 회귀 테스트는 예상치 못한 다른 피해를 찾는 것이다.
이 distinction은 중요하다. 변경된 컴포넌트에 대한 녹색 테스트는 오해를 불러일으킬 수 있다. UI 선택자는 여전히 버튼을 찾을 수 있지만, 상태 복원 버그로 인해 결제 화면이 올바른 장바구니를 받지 못하는 경우가 있다. Wi-Fi에서 테스트가 통과하는 경우, 혼잡한 연결에서 지연된 응답이 경쟁 조건을 드러내는 경우가 있다. 회귀 테스트 스위트는 안전망을 제공하지만, 사용자가 앱을 사용하는 방식에 따라야 한다.
반복 가능한 여행에 대한 자동화된 검사는 가치가 있다. 그러나 자동화는 품질과 동일하지 않다. 앱 팀에 대한 자동화된 테스트의 실용적인 개요는 기초를 설정하는 데 도움이 될 수 있지만, 모바일 회귀 작업은 생명 주기, 장치, 네트워크, 릴리스 채널 시나리오를 추가해야 한다. 이 дисцип인은 오랜 연구 역사を持고 있다. 2016년 회귀 테스트 연구를 조사한
연구 460개의 논문 을 추출 31 가지 기술과 25 가지 연구를 통해 field는 초기 경험적 평가에서 비용 및 오류 감지 효율성에 대한 광범위한 초점으로 발전했습니다. 배달 팀에게는 실용적인 교훈이 있습니다. regression testing은 선택 논리, 유지 보수 및 증거가 필요하며, 출시 전에 마지막으로 체크박스로 완료하는 것이 아닙니다.
Regression Testing 목표, 유형 및 모바일 문제 정의
강력한 regression 프로그램은 세 가지 결과를 보호합니다. 보고된 결함이 해결되었는지 확인하고, 영향을 받지 않는 영역에 새로운 결함이 들어가지 않도록 방지하고, 사용자가 이미 의존하는 기능의完整성을 유지합니다. 이러한 결과를 층별로 가정 보안과 같은 것입니다. 연기 감지기는 위험을 빠르게 감지하고, 잠금 장치가 일반적인 위험을 차단하고, 모니터링 시스템은 발생한 원인을 조사하는 데 도움이 됩니다.
각 테스트 유형을 작업에 맞춰 매치하세요
단위 테스트 작은 논리 조각을 고립된 상태에서 검사합니다. 예를 들어, 가격 계산기나 허가 상태 매핑기와 같은 것들입니다. 그들은 빠르고 정확하지만, 저장소에서 오래된 데이터를 받는지 여부를 밝히지 않습니다.
통합 테스트 컴포넌트 간의 경계를 검사합니다. 유용한 예는 지역 데이터베이스, 인증 서비스 및 동기화 층 사이의 연결입니다. 이러한 테스트는 완전한 장치 여행이 시도되기 전에 계약 및 데이터 흐름 문제를 노출합니다.
기능 테스트 사용자의 관점에서 완전한 기능성을 검증하세요. "아이템을 추가하고 앱을 닫고 다시 열고 체크아웃을 완료하세요"는 여러 시스템을 실행시키고 하나의 기능만 테스트하는 것보다 더 강한 자신감을 제공합니다.
UI 테스트 사용자 인터페이스와 상호 작용하는 화면, 제스처, 키보드 동작, 다이얼로그, 및 네비게이션. 이들은 모바일 경험에 필수적이지만 타이밍, 렌더링, 및 환경 차이로 더 민감합니다.
팀도 범위 선택합니다. 전체 회귀 전체 테스트 스위트를 실행합니다. 부분 회귀 영향받은 영역에만 집중합니다. 선택적 회귀 변경 영향에 따라 테스트를 선택합니다. 흡입 회귀 필수 경로를 확인하여 더 깊은 테스트가 필요할지 여부를 결정합니다. 이 범위들은 서로 경쟁하지 않아야 합니다. 좋은 PIPELINE은 이들을 다른 지점에서 사용합니다.
모바일 조건을 고려합니다.
모바일 회귀 테스트는 앱 주변 환경이 변경될 때 어려워집니다. 기기 및 운영 체제 분산은 레이아웃, 권한, 키보드 동작, WebView 렌더링 및 하드웨어 백업 기능에 영향을 미칩니다. 네트워크 변동성은 지연된 응답, 연결이 끊어짐, 캡티브 게이트웨이 및 연결 및 연결되지 않은 상태 간의 전환을 유발합니다.
앱 라이프 사이클은 또 다른 위험 계층을 만듭니다. 사용자는 전화 통화를 받을 때 결제 흐름 중에, 화면을 잠그면 문서 업로드 중에, 요청이 대기 중일 때 앱을-switch, 또는 운영 체제가 메모리를 회수한 후 다시 돌아올 수 있습니다. 테스트는 배경 및 전면 전환, 상태 복원, 중단된 다운로드 및 다시 시도 동작에 대한 명시적 체크포인트가 필요합니다. 배경 전환과 전면 전환더 광범위한 품질 계획을 위해 팀은
앱 품질 보증 지침
품질 계획을 보다 광범위하게 관리하기 위해 팀은 사용할 수 있습니다. 회귀 테스트는 앱의 안정성을 보장하는 데 중요합니다. 회귀 테스트는 앱의 안정성을 보장하는 데 중요합니다.
Regression 테스트의 효과적인 전략
회귀 테스트 스위트가 신뢰할 수 있는 feedback을 지속 가능한 비용으로 제공할 때 유용해집니다. 모든 테스트를 모든 편집 후 실행하는 것은 안전해 보이지만, 실행 속도가 느리고 무관한 실패로 신호가 묻힐 수 있습니다. 스위트를 영향력, 위험, 자동화 품질, 유지 보수에 따라 구축하세요. 4 가지 전략을 위한 정보 그래픽을 보여주는 infographic..
변경 맵을 통해 모든 회귀 결정의 시작점으로 시작하세요. 수정된 파일, 영향을 받은 모듈, 공유 서비스, 데이터 저장소, 네이티브 브리지, 사용자 여행을 식별하세요. 재사용 가능한 네비게이션 컴포넌트에 대한 변경은 단일 화면에 대한 복사 편집보다 더 광범위한 커버리지가 필요합니다.
pipeline이 지능적으로 선택할 수 있도록 명시적인 테스트 레이블을 생성하세요:
중요 경로:
- 로그인, 체크아웃, 결제 확인, 데이터 제출, 계정 복구. 라이프 사이클:
- Lifecycle: 플랫폼:
- Platform: 권한 요청, 키보드 동작, 깊이 있는 링크, 카메라 접근, 푸시 처리.
- 시각적: 레이아웃, 타이포그래피, 반응형 간격, 동적 콘텐츠, 다크 모드 동작.
- 업데이트 경로: 탐지, 다운로드, 설치, 런칭, 호환성, 롤백.
2023년 논문은 모바일 앱 전략을 설명하는데 이전 테스트를 분류하는 방식을 제시한다. obsolete, 재테스트 가능, 또는 재사용 가능 파일 이름만으로는 충분하지 않습니다. 공유 __CAPGO_KEEP_0__ 클라이언트의 변경이 편집되지 않은 화면에 영향을 줄 수 있습니다. 개발자에게 영향을 받은 여행을 포함하는 pull request를 요청하고 QA가 위험을 검토할 수 있도록 하세요. 위험을 우선시하세요. code
API
__CAPGO_KEEP_0__
위험에 따른 우선순위는 가장 큰 손실을 입힐 수 있는 실패를 먼저 처리합니다. 다음 질문을 사용하여 시나리오의 점수를 질적으로 평가합니다.
- 이 경로가 수익, 안전, 개인 정보, 또는 규제 데이터를 보호하는지 여부를 확인합니다.
- 변경이 컴포넌트 몇 개를 건너뛰는지 확인합니다.
- 이 영역이 이전에 실패한 적이 있는지 여부를 확인합니다.
- 시나리오가 장치, OS, 네트워크, 또는 라이프 사이클 조건에 의존하는지 여부를 확인합니다.
- 릴리스가 잘못되면 팀이 빠르게 복구할 수 있는지 여부를 확인합니다.
중요한 스모크 체크를 먼저 실행합니다. 로그인이나 앱 런칭이 실패하면 더 깊은 스위트를 중단하고 빌드를 고치세요. 통합 및 기능적 여행을 다음으로 실행하고, 넓은 장치 및 시각적 커버리지를 예약하세요. 스크립트가 잘못된 것을 판단할 수 없는 새로운 상호 작용, 모호한 요구 사항, 및 사용성 결정에 대한 수동 탐색적 테스트는 여전히 해당합니다.
안정적인 여행을 자동화하지 마세요. 모든 동작을 자동화하지 마세요.
반복할 수 있는, 관찰할 수 있는, 및 가치 있는 자동화 대상만 선택하세요. 단위 테스트는 비즈니스 규칙을 처리할 수 있고, Jest는 자바스크립트 모듈을 검증할 수 있으며, 장치 프레임워크는 네이티브 동작 및 UI 흐름을 실행할 수 있습니다. 자바스크립트 논리를 처리하는 팀은 Jest 단위 테스트 관행 를 사용하여 빠른 체크를 code 근처에 유지하세요.
유지 보수 가능한 끝-끝 테스트는:
- 안정적인 접근성 식별자 대신 취약한 텍스트나 위치 선택자 사용하지 마세요.
- 실행 전에 데이터를 생성하거나 fixture를 초기화하세요.
- 의미 있는 결과를 확인하세요. 단지 탭이 완료된 것만 확인하지 마세요.
- 실패 시 로그, 스크린샷, 장치 정보 및 네트워크 컨텍스트 캡처하세요.
- 비즈니스 확인과 네비게이션 헬퍼를 분리하세요. UI 변경으로 불필요한 재작성으로부터 보호하세요.
예를 들어, 주문 확인 후 주문 식별자가 나타나야 하고, 성공 후 카트만 비워야 하며, 실패한 결제는 회복 가능한 카트 상태를 보존해야 합니다. 그런 확인은 팀이 무엇이 깨졌는지 알려주지만, 최종 '화면 로드' 확인은 손상된 흐름을 통과할 수 있습니다.
원천에서 불안정성을 줄이세요.
재시도는 일시적인 인프라 실패와 반복 가능한 제품 결함을 구별할 수 있지만, 재시도는 불안정성을 숨기지 마세요. 첫 번째 실패를 기록하고, 아티팩트를 보존하고, 다른 시도 후에만 통과할 때 테스트를 의심스럽게 표시하세요.
테스트를 안정화하기 위해 애플리케이션 신호를 기다리세요. 대기 시간이 아닌 네트워크 요청이 settle, 로딩 상태가 사라지거나 도메인 이벤트가 발생할 때까지 기다리세요. 시계, 랜덤 값, 기능 플래그 및 테스트 계정 제어하세요. 네트워크 시나리오에서, 결정적인 서비스 응답을 사용하여 핵심 기능 확인을 수행하고, 이후에 지연성과 실패를 의도적으로 연습하는 별도의 테스트를 유지하세요.
테스트 시스템에서 불안정한 테스트를 결함으로 검토하십시오. 예측할 수 없는 테스트는 조정 시간을 소비하고 개발자들을 빨간 pipe line에 무시하도록 훈련합니다. 이 테스트를 재구성하십시오, 환경 원인을 분리하십시오, 또는 의미 있는 동작을 보호하는 경우가 더 이상 없을 때 제거하십시오.
팀 표준: 테스트는 팀이 실패 신호를 이해하고 그에 따라 행동할 수 있을 때만 블로킹 스위트에 포함되어야 합니다.
마지막으로, 동일한 확인을 반복하는 테스트를 제거하십시오. 각 동작에 하나의 강력한 확인을 유지하고 위험이 높을 때 에지 케이스를 추가하고, 넓은 탐색적 커버리지를 예약된 장치 세션으로 옮기십시오. 명확한 소유권을 가진 작은 스위트는 nobody가 신뢰하지 않는 큰 컬렉션보다 유용한 보호를 제공합니다.
CI/CD Pipe line에 Regression Testing 통합
Regression testing은 CI/CD 내에서 승진 결정에 영향을 미치지 않아야 하며, 배포 후에 수동 작업으로 나타나서는 안 됩니다. 실용적인 pipe line은 빠른 feedback와 신뢰가 증가할 때 커버리지 확장을 시작합니다.
pull request는 linting, 단위 테스트, 그리고 smoke regression set를 트리거할 수 있습니다. 성공적인 머지에는 Capacitor 또는 Electron 패키지를 빌드하고, 깨끗한 테스트 환경을 제공하고, 테스트 데이터를 시드하고, 통합 및 중요 end-to-end 여행을 실행할 수 있습니다. 예약된 작업은 더 광범위한 장치, 시각, 라이프 사이클, 및 네트워크 스위트를 실행할 수 있으며, 릴리스 후보는 가장 깊은 검증을 받습니다.
테스트 환경을 재현할 수 있도록 유지하세요. 애플리케이션 빌드, 테스트 데이터 버전, 서비스 스텁, 기능 플래그 및 장치 구성이 고정되어야 합니다. 실패가 발생했을 때, 팀은 앱이 변경되었는지 또는 환경이 변했는지 알 수 있어야 합니다.
유용한 홍보 패턴은 다음과 같습니다:
Pull request → fast checks → build → targeted regression → staging validation → release approval → production monitoring
Independent한 테스트를 병렬화하세요, 그러나 setup 및 destructive scenario의 의존성 순서를 보존하세요. GitHub Actions, GitLab CI 및 Jenkins는 모두 이 패턴을 조율할 수 있습니다, 조건이 pipeline이 artifact를 발행하고 blocking 테스트가 실패한 경우에만 stage를 실패시키는 것입니다.
2023년 실증 연구에서 발견한 바에 따르면 기능 그룹 커밋의 81.83%가 2시간 이상 떨어진 시간에 발생했습니다,에 따르면 2–24 시간 범위 내의 32.57%가 발생했습니다 그리고 24 시간 이상의 49.26%가 발생했습니다. Android regression-testing 연구 커밋 타이밍 및 클러스터링을 rerun 빈도 및 테스트 결과 신선함과 연결합니다. 모바일 팀에게는 따라서 의미 있는 빌드 또는 릴리스 이벤트와 연결된 스케줄된 스위트가 있어야 하며, 시간이없는 증거로 다루어지지 않아야 합니다.
업데이트 경로가 전용 PIPELINE 작업을 deserve합니다. 스테이징 채널에 업데이트를 배포하고 대표적인 장치에 설치한 후, 시작 및 중요 흐름을 검증하고, 번들 및 롤백 동작이 통과한 후에만 승격합니다. CI/CD 통합 테스트 지침 테스트 결과를 배달 자동화와 연결하는 방법
회귀 테스트 성능 및 관찰성 측정
회귀 테스트 프로그램이 건강한지 자동으로 판단하는 것은 아니다. 팀은 테스트가 관련성, 안정성, 시간, 그리고 사용자가 경험하는 실패와 연결되어 있는지 측정해야 한다. 테스트 시스템의 건강도와 애플리케이션의 품질을 분리하여 추적해야 한다.
| 지표 | 목적 | 중요 지표 |
|---|---|---|
| 테스트 통과율 | 선택한 스위트가 성공적으로 완료되는지 보여줍니다. | 업데이트 code 후에 지속적인 실패 또는 갑작스러운 변경 |
| 불안정성 퍼센트 | 임시 실패와 반복적 결함을 분리한다 | 관련된 애플리케이션 변경 없이 실패하는 테스트 |
| 실행 시간 | 팀이 피드백이 곧 도착하는지 결정하는 데 도움이 된다 | 총 또는 중요 경로의 지속 시간 증가 |
| Code 커버리지 | code 경로를 테스트하는 부분 | 위험도가 높은 모듈의 논리적 부분 |
| field 실패율 | 이전 릴리스 결과와 생산 동작을 연결한다 | 사용자와 관련된 릴리스 또는 업데이트 |
이러한 것들을 트렌드처럼 다루세요. 높은 통과율은 나쁜 보장을 숨길 수 있고, 광범위한 code 보장은 여전히 권한 시간, 장치별 렌더링, 또는 중단된 라이프 사이클을 놓칠 수 있습니다. field 실패율은 특히 유용합니다. 이는 테스트 스위트 뒤에 있는 가정들을 테스트합니다.
독립적인 분석 결과에 따르면 많은 모바일 리그레션 스위트는 사용자에게 도달하는 버그의 30%에서 40%만 잡을 수 있습니다. 30%에서 40%까지 사용자에게 도달한 버그의 30%에서 40%모바일 리그레션 테스트 커버리지 분석 사용자 실제 사용을 대표하는지 여부를 ауд팅할 때. 실제 사용 패턴을 반영하는 테스트 스위트가 있는지 감사하는 경우.
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 __CAPGO_KEEP_0__ 및 Electron에 대한 리그레션 테스트 워크플로우 __CAPGO_KEEP_1__
Regression Testing Workflows for Capacitor 및 Electron과 함께 Capgo
Capgo 팀의 한 팀은 Capacitor 변경을 마쳤습니다. 네이티브 셸은 수정이 필요하지 않지만 자바스크립트 번들을 수정해야 합니다. 원격 배포를 테스트를 피하는 단축키로 대신하는 대신, 팀은 배포 항목으로 추가하고 promotion 및 rollback 계획을 추가합니다.
CI에서 워크플로우가 시작됩니다. 단위 및 통합 테스트는 변경된 code에 대해 실행되고, 인증, 카트 상태, 결제, 저장소 및 네비게이션에 대한 기능 테스트가 실행됩니다. 빌드는 웹 번들을 생성하고 커밋, 의존성 상태, 네이티브 호환성 기대치 및 테스트 결과를 기록합니다. Electron 팀은 같은 원칙을 따르되, 윈도우 라이프 사이클, 파일 시스템 권한, 자동 업데이트 동작 및 플랫폼 렌더링과 같은 데스크톱 전용 커버리지도 추가합니다.
번들은 스테이징 채널로 이동합니다. 테스트 장치에서는 일반 업데이트 경로를 통해 설치합니다. 수트는 클라이언트가 업데이트를 감지하고, 다운로드한 패키지를 설치하고, 예상된 라이프 사이클 지점에서 성공적으로 시작되며, 사용자 상태를 보존하는지 확인합니다. 또한 다운로드가 중단되거나 시작이 불일치하는 경우 안전하게 회복 경로가 작동하는지 확인하기 위해 실패 조건을 강제합니다.
프로덕션 프로모션 전에 롤백 계획이 시작됩니다. 롤백을 위한 신호를 정의하고, 누구의 결정에 따라 롤백이 이루어지는지, 어떤 버전이 복원될 수 있는지, 그리고 지원 팀이 영향을 받은 사용자를 식별하는 방법을 정의합니다. 서버가 이전 버전의 패키지를 참조하는 것만으로는 롤백이 완료된 것은 아닙니다. 장치들은 신뢰할 수 있는 방법으로 명령을 받고, 복원된 버전을 실행하고, 제품이 허용하는 경우 사고 이전에 생성된 데이터를 유지해야 합니다.
대상 타겟팅은 위험을 제한하는 데 도움이 됩니다. 내부 또는 베타 사용자부터 시작하여 로그와 실패 패턴을 검사한 후, 증거가 프로모션을 지원하는 경우 더 광범위한 채널로 확장합니다. 배포 기록과 릴리스 노트를 연결하여 사고 대응자들이 관련된 앱 스토어 빌드와 무관한 빌드를 검색하지 않고 변경된 내용을 식별할 수 있도록 합니다.
시각적 커버지는 특별한 주의가 필요합니다. 최근 토론에서 모바일 시각적 회귀 테스트는 수십 개의 장치 및 OS combination, 그리고 스크린샷 비교에서 거짓 양성 결과를 생성할 수 있는 렌더링 차이를 고려해야 합니다. 모바일 시각적 회귀 테스트 토론 또한 동적 콘텐츠, 애니메이션 타이밍, 메모리, 화면 크기, 네트워크 상태 및 배터리 상태를 변동 요소로 강조합니다.
Capacitor와 Electron 애플리케이션에 대해, 의미 있는 렌더링 환경으로 분리된 시각적 기준선, 타임스탬프와 개인화된 콘텐츠를 마스킹하고 안정적인 애니메이션 상태를 기다리며, diffs를 무조건 받아들이지 말고 리뷰하십시오. native shell과 remotely delivered layer를 함께 테스트하십시오. 그들의 계약이 만나는 곳에서. 이 접근 방식은 팀이 패키지된 릴리스에서 기대하는 동일한 discipline를 보장하면서 빠르게 집중된 hotfix를 배포할 수 있도록 합니다.
Regression Practices를 통합하는 것
강력한 애플리케이션 회귀 테스트 프로그램은 테스트 디자인, 변경 영향, CI/CD, 관찰성, 롤백을 연결합니다.. 중요한 사용자 여행에서 시작하여 라이프 사이클과 환경 조건을 추가하고, 모든 차단 테스트에 명확한 소유자를 할당하십시오. 선택적 실행을 사용하여 빠른 feedback를 얻고, 더 광범위한 스위트를 사용하여 릴리스에 대한 신뢰도를 얻고, 인간 판단이 여전히 중요할 때는 탐색적 테스트를 사용하십시오.
Capacitor와 Electron 앱에 대해, 모든 live update을 제어된 릴리스로 다루십시오. 배포본, 설치 경로, 영향을 받은 장치 집합, 복구 작업을 검증하고 프로덕션 승격 전에 검사하십시오. 실패를 빌드, 장치, OS, 채널, 라이프 사이클 상태별로 리뷰하고, 사용자와 엔지니어가 만나는 것을 기반으로 스위트를 개선하십시오.
다음 실제 단계는 하나의 고위험 여행, 예를 들어 로그인 또는 결제를 단위, 통합, UI, 라이프 사이클, 시각적, 롤백 확인에 걸쳐 매핑하는 것입니다. CI에 그 지도 넣고, 그 증거를 캡처하고, 개발, QA, 지원, 릴리즈 소유자와 함께 검토한 후 다음 여행으로 확장하세요.
Capgo는 CapacitorJS 및 Electron 앱에 대한 서명된 라이브 업데이트 전송을 제공하며, 대상 채널, 버전 기록, 장치별 로그, 수용 및 실패 메트릭, 자동 롤백 보호를 제공합니다. 사용자 지정 제어를 사용하여 원격 번들을 규칙적인 회귀 및 릴리즈 워크플로우의 일부로 만들고, 다음으로 방문하세요. Capgo 플랫폼을 평가하세요.
