카카오스타일이 지그재그 앱의 UI 테스트를 Appium과 Jenkins로 자동화한 구성 기록이다. E2E 범위의 반복 테스트를 자동화해 수동 QA 인력이 복잡한 문제에 집중하도록 하고, 데이터독 같은 지표로는 안 잡히는 체감 문제를 상시 감지하는 것이 목표다. 하이브리드 앱이라 네이티브와 웹뷰를 오가는 테스트 코드까지 포함한다.
핵심 포인트- 목표는 두 가지다. 회귀·스모크처럼 단순 반복 테스트를 대체하는 것과 주요 지면을 상시 모니터링하는 것이다.
- 지그재그는 네이티브와 웹을 섞은 하이브리드 구조라 Appium으로 context를 전환하며 상호작용까지 검증한다.
- Jenkins 파이프라인이 코드 체크아웃, Maven 빌드, 테스트 실행, Extent 리포트 생성, Slack 알림까지 담당한다.
- AWS Device Farm에서 로컬 실기기로 전환해 비용을 줄이고 장치 구성의 유연성과 프로세스 통제력을 얻었다.
- 같은 도구를 성능 측정으로도 확장해 페이지 진입 시간과 adb 기반 메모리·네트워크 사용량을 잰다.
- 한계도 명시한다. 초기 구축과 유지보수 비용, 자동화 불가능한 영역, 비결정적으로 실패하는 스크립트다.
상세 정리- 위치: 여기서 말하는 UI 테스트는 단위·통합·E2E 중 E2E에 해당한다.
- 환경 구성: IntelliJ로 코드를 쓰고 GitHub으로 관리하며, Jenkins가 스케줄링으로 주기 실행하고, 실제 Android·iOS 기기와 브라우저를 연동해 Appium으로 실행한다.
- 시나리오 기반: 로그인, 데이터 입력, 결과 확인처럼 실제 사용자 경로를 따라가며 주요 기능이 의도대로 도는지 확인한다.
- 하이브리드 테스트: getContextHandles로 컨텍스트 목록을 받아 WEBVIEW로 전환해 웹 요소를 조작하고, 다시 NATIVE_APP으로 돌아와 네이티브 요소에 결과가 반영됐는지 검증한다.
- Jenkins 파이프라인 1: git 스테이지에서 main 브랜치를 체크아웃하고 동시 빌드 비활성화와 30일 보관 정책을 건다.
- Jenkins 파이프라인 2: mvn clean package로 빌드한 뒤 TestRunner를 기기·포트 파라미터와 함께 실행하고 surefire 리포트의 failCount로 성패를 가른다.
- 리포트: extentreports 의존성을 넣고 ExtentHtmlReporter로 HTML 리포트를 만든 뒤 publishHTML 플러그인으로 Jenkins 대시보드에 띄운다.
- Slack 알림: 실패면 danger, 성공이면 good 색으로 스레드를 열고 summary 텍스트, 엑셀 리포트, 성공·실패 스크린샷 png, 재현 영상 mp4까지 같은 스레드에 올린다.
- 로컬 기기 전환 이유: 클라우드 사용료 절감이 가장 직접적이고, 장치와 OS 버전을 자유롭게 추가·변경할 수 있으며, 문제 발생 시 즉시 확인하는 빠른 피드백 루프를 만들 수 있다.
- 결과 전달 경로 세 가지: 즉시성 있는 슬랙 알림, 케이스별 상세가 담긴 리포트 파일, 성공률·실패 원인·실행 시간을 모아 보는 젠킨스 대시보드다.
- 성능 측정 확장: adb 셸 명령 결과에서 RX bytes와 TOTAL 값을 파싱해 네트워크·메모리 사용량을 수치화하는 유틸을 붙였다.
- 남은 과제 1: UI가 바뀌면 스크립트도 따라 바뀌어야 해 유지보수에 생각보다 많은 시간이 든다.
- 남은 과제 2: 모든 시나리오를 자동화할 수는 없다. 감성적 피드백이 대표적이다.
- 남은 과제 3: 환경에 민감한 스크립트가 비결정적으로 실패하면 결과가 일관되지 않아 신뢰를 주기 어렵다.
- 현재 범위는 단순 반복적인 기본 기능 위주이며 점진적으로 넓혀갈 계획이라고 밝힌다.
왜 읽나하이브리드 앱 E2E 자동화를 Appium과 Jenkins로 세우려 할 때 파이프라인 스테이지 구성과 결과 전파 경로를 그대로 참고할 수 있다.