질문의 역사
**진화된 웹 애플리케이션 (PWA)**의 확산은 웹 애플리케이션이 오프라인 또는 저연결 환경에서도 안정적으로 작동해야 하는 패러다임 전환을 가져왔습니다. 전통적인 웹 자동화는 오로지 온라인 상태 검증에만 집중했지만, 현대 PWA는 페이지 생명 주기를 넘어 지속되는 백그라운드 프로세스 검증을 요구합니다. 조직들이 유지보수 비용 절감을 위해 네이티브 모바일 앱에서 PWA로 전환하면서, QA 팀은 서비스 워커, 캐시 저장소 API, 비동기 백그라운드 동기화 이벤트와 관련한 자동화 시나리오에서 예전의 우리가 경험하지 못했던 도전에 직면하게 되었습니다. 이 질문은 애플리케이션 상태가 브라우저, 캐시 레이어, 그리고 서버에 동시에 존재하는 복잡한 오프라인 우선 아키텍처를 검증할 필요성에서 발생했습니다. 이로 인해 비결정적 네트워크 조건에 대한 결정론적 테스트 전략이 필요하게 되었습니다.
문제점
PWA 테스트는 표준 셀레니움이나 웹 드라이버 프레임워크가 충분히 해결하지 못하는 독특한 기술적 장애물을 제시합니다. 서비스 워커는 메인 자바스크립트 실행 맥락과 독립적인 별도의 스레드에서 작동하여 업데이트를 트리거하기 위한 DOM 조작이 불가능하게 만듭니다. 캐시 저장소 API는 Chrome, Safari, 그리고 Firefox에서 다르게 동작하며, 저장소 쿼타와 캐시 만료 정책의 구현이 다양합니다. 백그라운드 동기화 이벤트는 연결이 복원될 때 예측 불가능하게 발생하며, 이는 기존의 단언 모델이 포착하지 못하는 경쟁 조건을 만들어냅니다. 게다가, 모바일 장치에서 브라우저 종료를 시뮬레이션하여 큐의 지속성을 테스트하기 위해서는 운영 체제 수준의 이벤트를 다룰 필요가 있으며, 대부분의 자동화 스택은 이러한 접근을 지원하지 않습니다. 이 모든 요소들은 자동화 회귀 커버리지가 없는 상태로 중요한 오프라인 기능이 배송되는 테스트 가능성의 격차를 만듭니다.
해결책
강력한 PWA 테스트 아키텍처는 Puppeteer 혹은 Playwright를 사용한 헤드리스 서비스 워커 조작, **Chrome DevTools Protocol (CDP)**와 함께하는 웹 드라이버를 통한 네트워크 조건 시뮬레이션, 그리고 네이티브 모바일 자동화 프레임워크를 결합한 다국어 접근 방식을 요구합니다. 이 솔루션은 navigator.serviceWorker.controller와 caches.open()에 접근하여 직접 캐시 검증을 수행하기 위해 브라우저 스코프 내에서 자바스크립트를 실행하는 서비스 워커 내비게이션 레이어를 구현합니다. 네트워크 제한은 CDP 명령인 Network.emulateNetworkConditions를 활용하여 오프라인 상태, 3G 속도, 그리고 간헐적인 패킷 손실을 시뮬레이션합니다. 모바일 별 검증을 위해서는 BrowserStack이나 Sauce Labs와 같은 장치 클라우드 제공업체와 통합하여 물리적 하드웨어에서 테스트를 수행하고, ADB (Android Debug Bridge) 명령을 사용하여 브라우저 프로세스를 강제 종료하고 IndexedDB 지속성을 검증합니다. 이러한 기능을 제공하기 위해 사용자 정의 Jest 환경이 통합되어, 각 테스트 케이스 사이에 서비스 워커를 등록 해제하고 캐시 저장소를 지워 단위 테스트 격리를 제공합니다.
맥락 및 문제 설명
우리의 핀테크 클라이언트는 사용자가 오프라인 상태에서 거래를 대기열에 올릴 수 있도록 하는 PWA를 개발했습니다. 이 거래는 연결이 복원될 때 자동으로 동기화됩니다. 베타 테스트 중 사용자들은 브라우저를 오프라인 상태로 전환한 직후에 닫았을 때 거래가 소실되었다고 보고했습니다. 이에 따라 서비스 워커가 백그라운드 동기화를 처리하고 있어야 한다고 주장했습니다. 우리의 기존 자동화 스위트는 표준 Cypress 테스트를 사용하고 있었으며, Cypress는 브라우저 컨텍스트 내에서 실행되므로 진정한 브라우저 종료를 시뮬레이션할 수 없었으며 IndexedDB에서 큐의 지속성을 검증할 수 없었습니다. 이 버그는 사용자가 최근 앱 트레이에서 Chrome 앱을 종료할 때 물리적 Android 장치에서만 재현되었으며, 이는 기존의 웹 전용 프레임워크로 자동화하기 불가능한 시나리오였습니다.
고려된 다양한 해결책
해결책 1: Workbox 시뮬레이션을 이용한 목업 기반 단위 테스트
우리는 서비스 워커 로직을 분리하고 Node.js 환경에서 workbox 테스트 유틸리티를 사용하여 실행하는 것을 고려했습니다. 이 접근 방식은 밀리초 단위의 빠른 실행과 캐시 이벤트에 대한 결정적인 제어를 제공했습니다. 그러나 이는 Chrome의 캐시 저장소 구현과 삼성 인터넷 브라우저의 백그라운드 동기화 권한 처리에서 브라우저 특정의 변칙을 포착하지 못했습니다. 또한, 목업은 실제 웹 앱 매니페스트 설치 조건이나 스플래시 스크린 동작을 검증할 수 없었습니다.
해결책 2: 장치 실험실을 통한 수동 QA
수동 테스터를 고용하여 장치의 비행기 모드를 활성화하고 브라우저 프로세스를 종료시키며 연결을 복원하는 방법은 현실적인 행동에 대해 높은 신뢰성을 제공했습니다. 이 방법은 다양한 장치 제조사 간의 사용자 경험을 정확하게 포착했습니다. 그럼에도 불구하고, 이는 매 빌드마다 45분을 추가로 소요하였고, 모든 커밋에 대해 실행할 수 없으며, 동기화 큐의 논리에 Regression을 도입한 특정 커밋을 분리할 수 있는 세분성이 부족했습니다.
해결책 3: Appium 및 Chrome DevTools Protocol을 이용한 하이브리드 자동화
우리는 Appium이 시스템 수준에서 브라우저를 강제 종료하는 등의 작업을 수행하도록 물리적 장치를 제어하고, WebSocket 연결을 통해 CDP가 종료 전에 서비스 워커 상태를 검사하는 프레임워크를 설계했습니다. 사용자 정의 자바스크립트 실행자는 캐시 저장소 API를 조회하여 거래 페이로드의 무결성을 검증했습니다. 이 솔루션은 물리적 장치의 현실성과 자동화된 단언의 속도 및 신뢰성을 결합했습니다.
선택한 솔루션 및 이유
우리는 단일한 엔드 투 엔드 데이터 지속성 보장을 검증할 수 있는 접근 방식이었던 솔루션 3을 선택했습니다. 이는 인프라 비용 측면에서 비싸지만, 중요한 경로를 직접 테스트했습니다: 거래 생성 → 서비스 워커 가로채기 → IndexedDB 저장 → 브라우저 종료 → 재시작 → 백그라운드 동기화 실행. Appium 레이어는 메모리 압력 및 앱 생명 주기 상태와 같은 운영 체제 수준의 현실을 처리했고, CDP 통합은 디버깅 중 개발자가 수동으로 검사했던 애플리케이션 패널 데이터를 프로그래밍 방식으로 접근할 수 있게 해주었습니다.
결과
이 구현은 **Android 11+**의 Chrome이 오프라인 감지가 발생한 직후 Doze 모드로 들어갈 때 백그라운드 동기화 등록을 지연시키는 경쟁 조건을 발견했습니다. 이는 우리의 단위 테스트에서 전혀 포착되지 않은 버그였습니다. 장치 실험실 시나리오를 자동화함으로써 회귀 탐지 시간을 수동 테스트 주기에서 3일에서 8분으로 단축했습니다. 이 프레임워크는 이제 큐에 올린 거래가 브라우저 종료는 물론, 장치 재시작 시나리오에서도 생존하도록 검증하여 오프라인 거래에 대해 99.99% 데이터 내구성 보장을 보장합니다.
테스트 실행 중에 캐시 저장소의 내용을 프로그램적으로 검사하고 특정 자산이 올바른 버전 헤더로 캐시되었는지를 검증하는 방법은?
대부분의 후보자들은 Puppeteer에서 네트워크 요청 가로잡기를 체크하는 것을 제안하지만, 이는 요청만을 검증할 뿐 캐시 상태는 검증하지 않습니다. 올바른 접근 방식은 브라우저 컨텍스트 내에서 자바스크립트를 실행하여 캐시 저장소 API에 직접 접근하는 것입니다. page.evaluate()를 사용하여 caches.keys()와 cache.match()를 호출하여 x-sw-cache-version과 같은 헤더를 검사해야 합니다. 후보자들은 대개 서비스 워커가 불투명한 응답(크로스 오리진)을 캐시할 수 있음에 따라 헤더에 접근할 수 없는 경우를 놓치며, 이로 인해 메타데이터를 병렬 IndexedDB 인스턴스에 저장하는 것과 같은 우회적인 조치가 필요합니다. 또한, 후보자들은 캐시 쓰기의 비동기적 특성을 처리하는 것을 잊어버려 명시적인 대기 또는 폴링 메커니즘을 필요로 합니다.
페이지 새로 고침 간에 서비스 워커가 지속될 때 테스트 격리를 처리하는 방법은?
후보자들은 종종 쿠키나 로컬 저장소를 지우는 것에 대해 언급하지만, 서비스 워커는 도메인 수준에서 존재하며 표준 정리 방법을 통해서는 소멸되지 않습니다. 해결책은 navigator.serviceWorker.getRegistrations()를 사용하여 모든 서비스 워커를 명시적으로 등록 해제한 다음 caches.keys()와 cache.delete()를 통해 모든 캐시 저장소 항목을 지우는 것입니다. 그러나 중요하게 놓친 세부사항은 서비스 워커 등록 해제가 비동기적이며 탐색하기 전에 완료되지 않을 수 있으므로 unregister()의 약속을 기다리고 navigator.serviceWorker.controller가 null임을 검증한 후 애플리케이션을 로드해야 한다는 점입니다. 완전한 격리를 위해, IndexedDB 데이터베이스를 indexedDB.deleteDatabase()를 사용하여 지워야 하며 이를 통해 테스트 간의 백그라운드 동기화 큐가 누출되지 않도록 해야 합니다.
최신 Chrome 버전이 사용자 참여 지표와 같은 휴리스틱을 기반으로 이 이벤트를 억제할 때 beforeinstallprompt 이벤트 및 홈 화면 추가 (A2HS) 기능을 검증하는 방법은?
주니어 후보자들은 일반적으로 합성 DOM 이벤트를 사용하여 이벤트를 트리거하려고 하지만, 이는 Chrome이 진정한 사용자 제스처와 특정 참여 기준(도메인 빈도, 세션 기간)을 요구하기 때문에 실패합니다. 자동화 전략은 Puppeteer 또는 Playwright와 Chrome DevTools Protocol을 사용하여 Emulation.set lighthouse run을 통해 참여 데이터를 무시하거나 --disable-features=CalculateNativeWinOcclusion 및 --enable-features=DesktopPWAs-installed-apps와 같은 특정 플래그를 사용하여 Chrome을 시작해야 합니다. 그러나 강력한 솔루션은 Lighthouse CI 감사 프로그램을 통해 웹 앱 매니페스트 구문 분석을 프로그램적으로 테스트하고, 매니페스트에 필수 필드(icons, start_url, display)가 포함되어 있는지 확인하며, window.matchMedia('(display-mode: standalone)')를 사용하여 standalone 표시 모드가 올바르게 활성화되는지를 검증하는 것입니다. 대부분의 후보자들은 iOS Safari가 스플래시 스크린에 대해 매니페스트 대신 <meta> 태그를 사용한다는 점을 놓쳐 플랫폼별 검증 경로가 필요합니다.