질문의 역사
프로그레시브 웹 앱(PWAs)은 서비스 워커를 사용하여 네트워크 요청을 가로채고 오프라인 용도로 자산을 캐시하여 네이티브와 웹 애플리케이션 간의 경계를 모호하게 만듭니다. 초기 웹 테스트 방법론은 지속적인 연결성을 가정했지만, 현대 애플리케이션은 비행기 모드, 지하철 터널 및 시골 연결성 사각지대에서도 작동해야 합니다. 이러한 발전은 IndexedDB와 같은 클라이언트 측 데이터베이스가 임시 버퍼가 아닌 기본 데이터 소스 역할을 하게 되면서 복잡한 상태 관리 문제를 유발했습니다. 이를 위해 브라우저 저장소 제거 정책 및 비동기 동기화 큐를 고려하는 새로운 검증 접근 방식이 필요합니다.
문제
전통적인 수동 테스트는 이상적인 네트워크 조건에서 기능 검증에 집중하여 캐시 업데이트 중 경쟁 조건과 Safari가 저장소를 지울 때의 데이터 손실, 또는 장치 배터리를 소모하는 백그라운드 동기화 API의 무한 재시도 루프와 같은 주요 실패 모드를 놓치는 경우가 많습니다. 테스터는 오프라인 사용의 "행복한 경로"뿐만 아니라 네트워크 파티션 중 여러 장치 인스턴스가 동일한 장바구니나 문서를 수정할 때 발생하는 병합 충돌을 검증해야 합니다. 또한, 서비스 워커 생애주기 관리는 적절히 트리거되지 않으면 업데이트가 무한히 대기하게 되어 사용자가 구식 애플리케이션 버전에 갇히게 하는 독특한 복잡성을 불러옵니다.
해결책
포괄적인 방법론은 간헐적인 연결성을 시뮬레이션하기 위해 프로그래머블 네트워크 프록시를 사용하여 다중 장치 테스트 시나리오를 조정하는 것을 포함하며, Chrome DevTools 애플리케이션 패널에서 서비스 워커 상태 및 IndexedDB 변화를 모니터링합니다. 테스터는 장치 용량을 인위적으로 채워 QuotaExceededError 처리를 일으키는 "저장소 압박" 테스트를 실행하고, 여러 일에 걸쳐 Safari의 지능형 추적 방지 기능이 중요한 사용자 데이터를 조기에 지우지 않도록 검증하는 장기 테스트를 수행해야 합니다. 또한, 충돌 해결 알고리즘을 검증하려면 이종 브라우저 간의 동시 작업을 보장하여 Chrome의 백그라운드 동기화 구현과 Safari의 보다 제한적인 저장소 정책 간의 운영 일관성을 보장해야 합니다.
문제
전자 상거래 PWA에 대해 사용자들이 모바일과 데스크탑 장치 간에 전환 후 장바구니를 잃어버리거나 애플리케이션 업데이트 후 제품 카탈로그 캐시가 새로 고침되지 않는다는 불만이 sporadically 보고되었습니다. 조사를 통해 서비스 워커가 CacheStorage에서 오래된 HTML 외관을 제공하고 있는 동안 IndexedDB는 사용자가 브라우저를 강제 종료할 때 백그라운드 동기화 이벤트가 드롭되어 동기화되지 않는 장바구니 상태를 보유하고 있다는 것이 밝혀졌습니다. 이와 함께 iOS 16의 iOS Safari 사용자는 지능형 추적 방지 정책으로 인해 7일간 비활동이 발생한 후 완전한 데이터 손실을 경험했지만, 애플리케이션은 이 조용한 제거를 감지할 수 있는 백업 메커니즘이 부족했습니다.
해결책 1: 고립된 장치 테스트
이 접근법은 네트워크 간섭 없이 깨끗한 브라우저 프로필에서 각 장치를 독립적으로 검증하는 방식을 포함합니다. 주요 장점은 표준 브라우저 DevTools를 사용하여 간단히 실행할 수 있으며 쉽게 문서화된 재현 가능한 단계가 포함된다는 것입니다. 그러나 이 방법은 두 클라이언트가 동시에 충돌하는 장바구니 수정을 동기화하려고 할 때 발생하는 시간 의존적인 경쟁 조건을 포착하지 못하며, 실제 사용 패턴에서만 나타나는 Safari의 고유한 저장소 제한을 완전히 무시합니다. 결과적으로 이 접근법은 충돌 해결 로직에 대한 잘못된 부정(False Negative)을 생성했기 때문에 기본 방법론으로 채택되지 않았습니다.
해결책 2: 자동 네트워크 제한
자동 네트워크 제한은 Puppeteer 또는 Playwright 스크립트를 사용하여 지연에 대한 정확한 제어 하에 프로그램적으로 오프라인 상태를 시뮬레이션합니다. 비록 이것이 회귀 테스트에 대한 높은 재현성을 제공하지만, Safari의 독점 저장소 제거 휴리스틱이나 사용자가 주도하는 "기록 지우기" 작업을 복제할 수는 없습니다. 또한 자동 스크립트는 저전력 조건에서의 백그라운드 동기화 재시도 백오프와 같은 배터리 관련 동작을 놓칩니다. 이 솔루션은 스모크 테스트에 채택되었지만, 실제 장치 제한을 모델링할 수 없기 때문에 릴리스 인증에 불충분하다고 판단되었습니다.
해결책 3: 제어된 혼돈 실험실
제어된 혼돈 실험실은 패킷 손실을 주입하기 위해 Linux tc를 실행하는 프로그래머블 Wi-Fi 라우터를 갖춘 물리적 장비 실험실을 조성하고, iPhone, Android, Desktop 장치 전반에 걸쳐 동기화된 수동 테스트 프로토콜을 결합합니다. 이 접근법은 실제 네트워크 파티션 및 저장소 압박을 진짜로 재현하며, Safari의 실제 ITP 동작을 장기간 테스트하는 것을 가능하게 합니다. 또한, 두 테스터가 동시에 동일한 장바구니 항목을 수정할 때 실시간 충돌 해결 UI를 검증합니다. 자원 집약적이지만, 이는 연결이 불안정할 때 백그라운드 동기화가 중복 결제 요청을 대기열에 추가하는 중대한 결함을 발견했기 때문에 선택되었습니다.
결과
이 방법론을 구현한 후 팀은 장바구니 병합을 위한 "Last-Modified" 벡터 시계 알고리즘을 도입하고 모든 장치에서 볼 수 있는 지속적인 "동기화 대기 중" 배지를 추가했습니다. 또한 중복 청구를 방지하기 위해 서버 측에서 무효 가능성 키를 도입했습니다. 배포 후 장바구니 포기율은 40% 감소했으며, 후속 고 트래픽 이벤트 기간 중 중복 거래 불만은 제로로 보고되었습니다.
브라우저가 "대기" 상태에서 이전 버전을 유지할 때 서비스 워커를 강제로 업데이트하는 방법은 무엇입니까?
많은 후보자들은 페이지를 새로 고침(F5)하면 새로운 서비스 워커가 즉시 설치된다고 생각하지만, 실제로 브라우저는 버전 일관성을 보장하기 위해 모든 탭이 닫히기 전까지 이전 워커를 활성 상태로 유지합니다. 올바른 수동 테스트는 Chrome DevTools 애플리케이션 > 서비스 워커를 열고 "대기 건너뛰기"를 클릭하여 업데이트를 시뮬레이션한 후, 활성화 이벤트가 오래된 CacheStorage 항목을 지우고 IndexedDB 사용자 데이터를 보존하는지 확인하는 것입니다. 테스터는 또한 사용자 경험을 검증하여 "업데이트 가능" 토스트가 나타나고 페이지가 양식 입력을 잃지 않고 새로 고침되는지 확인해야 합니다. 이 생애주기 뉘앙스를 놓치면 새 버전이 활성화된 것으로 믿으면서도 테스트 중인 코드는 여전히 구식이 됩니다.
백그라운드 동기화와 주기적 백그라운드 동기화 테스트 시 구별되는 점은 무엇이며, 왜 Safari 동작이 다릅니까?**
백그라운드 동기화는 연결이 복원되면 체크아웃 제출과 같은 개별 작업을 지연시키며 브라우저가 네트워크를 감지할 때 즉시 작동하는 반면, 주기적 백그라운드 동기화는 사용자 상호작용 없이 참여 휴리스틱에 기반하여 콘텐츠를 능동적으로 가져옵니다. 백그라운드 동기화를 테스트하기 위해 Chrome DevTools 네트워크를 "오프라인"으로 설정하고 작업을 수행한 다음 연결을 복원하고 애플리케이션 패널에서 동기화 이벤트가 성공적으로 완료되었거나 지수 백오프 재시도를 클릭하는 것을 모니터링합니다. 주기적 백그라운드 동기화를 위해서는 Chrome 플래그를 활성화하고 높은 사이트 참여 점수를 시뮬레이션한 다음, 프리패치를 확인하며 iOS가 API가 사용 불가능할 때 우아하게 저하되는지 확인해야 합니다. 후보자들은 종종 이러한 API를 혼동하거나 Safari가 주기적 백그라운드 동기화를 지원한다고 가정하여 테스트되지 않은 백업 코드 경로로 이어집니다.
Safari의 지능형 추적 방지가 저장소를 삭제할 때 IndexedDB 동작을 어떻게 검증합니까?**
Safari의 ITP는 교차 사이트 추적을 방지하기 위해 사용자가 비활성 상태인 7일 후에 스크립트에서 쓸 수 있는 저장소를 지웁니다. 이는 Chrome에서 발생하지 않으며 시스템 시계를 조정하거나 WebKit 디버그 API를 사용하지 않고는 시뮬레이션하기 어렵습니다. 후보자들은 종종 단일 세션 내에서만 IndexedDB를 테스트하여 "7일 제거" 시나리오를 완전히 놓치고, 제거 후 서버에서 데이터의 우아한 재가져오기를 검증하지 못합니다. 적절한 테스트에는 제거를 수동으로 트리거한 다음 애플리케이션이 데이터베이스 상태가 비어 있음에 따라 적절한 사용자 메시지를 표시하고 오류 없이 데이터를 재구성하는지 확인하는 것이 포함됩니다. 또한 QuotaExceededError 예외를 처리하는 데 있어 애플리케이션이 충돌하지 않도록 하는 StorageManager.persist() API 요청을 테스트해야 하며, 이는 Firefox에서 영구 저장소 권한을 요청하지만 Safari에서는 다르게 동작합니다.