E2E 테스트 시나리오 설계 및 구현 - 100-hours-a-week/KTB4-16th-Cloud GitHub Wiki
어떤 클라우드 환경에서 진행할 것인가?
-
개발 서버, 스테이징 서버, 운영 서버로 나뉘어져있는데
-
나는 개발 서버와 스테이징 서버가 100% 같다고 생각함 왜냐하면
-
배포하기전 운영환경과 실제로 비슷하게 만들어두고 테스트를 하는게 개발서버, 스테이징 서버 아니였는가?
-
라고 생각했는데 달랐다.
-
개발 서버는 테스트용 서버로 개발자들이 맘대로 테이블이나 서비스를 추가, 수정, 삭제하면서 여러가지 서비스를 테스트할 수 있는 서버이다. 말 그대로 개발자들 놀이터
-
기능 개발 위주로 하기 때문에, 서버의 환경은 production보다 훨씬 작다.
-
스테이징 서버는 운영 서버의 클론 서버처럼 똑같이 운영되는 서버로서 스테이징에서 문제가 없으면 운영서버에 그대로 배포하기 위해 최종 검수하는 테스트 서버이다.
- 개발 팀 뿐 아니라 기획팀이나 어떤 클라이언트 업체에게 공유하고 중간 보고나 스테이징 도메인으로 시연하기도 한다고함
-
운영 서버
- 실제 스테이징 서버에서 정상 반영된 경우 운영서버에 해당 부분들 반영하는 운영 서버이다.
E2E 테스트 도구 선택
- E2E 자동화 도구를 선정하기 전 우리 서비스는 어떤 사용자 경험을 자동으로 검증해야 하는지를 고민했다.
- 사용자가 장소를 선택하고 음악과 사진을 담아 자물쇠를 만든 뒤, 지도에서 다시 찾아 열어볼 수 있어야 한다.
- 국내 좌표에서는 자물쇠를 생성할 수 있고, 해외 좌표에서는 생성이 차단되는지 확인해야 한다.
- 위치에 따라 추천 플레이리스트와 지역별 음원 랭킹이 올바르게 표시되는지 확인해야 한다.
- 모바일 화면에서 지도 조작, 위치 권한, 사진 업로드가 문제없이 동작해야 한다.
- CI workflow에 추가할 것이기 때문에 빠르면 빠를 수록 좋다.
- 이를 기준으로 위치 설정, 파일 업로드, 네트워크 응답 제어, 모바일 화면 테스트, CI 실행과 실패 원인 확인을 지원하는 도구를 찾기로 했다.
- 현재 가장 많이 사용되는 도구 3가지를 비교한다.
| 기능/특징 | Cypress | Playwright | Selenium |
|---|---|---|---|
| 실시간 디버깅과 명령 로그 | 브라우저 화면에서 테스트 진행 상황을 실시간으로 확인 가능, 명령 로그로 애플리케이션 상태 추적 | 기본 디버깅 지원(개발자 도구 연동 가능) | 로그 기반 디버깅 제공 |
| 자동 대기와 비동기 처리 지원 | DOM 요소와 비동기 작업이 완료될 때까지 자동 대기, 타이밍 문제 최소화 | DOM 요소 로드와 비동기 작업에 대한 스마트 대기 지원 | 수동으로 wait 명령 설정 필요 |
| 시각적 피드백 | 스크린샷과 동영상을 자동 기록, 실패 시점과 전체 실행 과정 저장 가능 | 스크린샷 및 동영상 기록 가능 | 스크린샷 기록 가능(별도 설정 필요) |
| 간단한 설치와 사용 용이성 | 설치와 설정이 간단하여 빠르게 테스트 환경 구축 가능 | 비교적 간단(추가 설정이 필요할 수 있음) | 설치와 설정이 복잡하며 초기 도입 비용이 높음 |
| 속도 및 성능 | 상대적으로 빠르지만, Playwright보다 약간 느림 | 매우 빠른 테스트 실행 속도 및 경량화 | 다양한 환경 지원으로 유연하지만, 속도가 느림 |
- 결론은 Playwright를 선택했다.
- 위치와 위치 권한을 설정해 국내·해외 좌표에서 자물쇠 생성 흐름을 검증할 수 있다.
- 사진 업로드와 모바일 화면 테스트를 한 도구에서 작성할 수 있다.
- 팀이 테스트 코드를 익히기 쉽고, 테스트 실패 시 실행 과정을 확인할 수 있다.
- V2에서 채팅 기능을 추가하면 서로 다른 사용자 세션을 만들어 두 사람 간의 대화를 한 테스트에서 검증할 수 있다.
E2E 테스트 시나리오 설계
-
테스트 시나리오 기준
- 이 테스트는 무엇을 보장하고, 무엇은 생략하고 있는가?
- 실패했을 때 원인을 빠르게 좁혀나갈 수 있는 구조인가?
- 변경에 강한 테스트인가, 아니면 자주 깨지는가?
-
기준이 없으면 비슷한 테스트만 늘어나거나, 정작 중요한 흐름을 놓칠 수 있다.
-
그렇다고 처음부터 모든 경우를 설계하면 구현이 늦어진다.
-
따라서 자물쇠 생성, 재조회, 해외 생성 차단처럼 핵심 흐름부터 테스트하고, 발견한 위험에 따라 시나리오를 추가하기로 했다.
-
E2E 테스트 시나리오는 기획단계의 페르소나를 참고하여 작성했다.
페르소나 1 (음악과 사진으로 순간을 기록하는 대학생)
-
과제와 인턴 준비로 바쁜 4학년이다. 좋아하는 노래를 들으며 동네를 걷고, 인상적인 순간은 사진으로 남긴다. 친구들과 음악을 공유하며 새로운 노래를 발견하는 것도 좋아한다
-
사용자 흐름
- 로그인한 뒤 국내 지역을 선택한다.
- 지역별 음원 랭킹을 확인하고, 다른 지역을 선택해 랭킹이 바뀌는지 확인한다.
- 장소를 선택하고 음악, 사진, 내용을 입력해 자물쇠를 만든다.
- 지도에서 새 자물쇠를 찾아 열어본다.
- 내 자물쇠만 보기를 선택한다.
-
기대 결과
- 랭킹에 현재 선택한 지역의 곡이 표시되고, 지역을 바꾸면 표시 내용도 바뀐다.
- 자물쇠 생성이 완료되고 지도에 새 자물쇠가 나타난다.
- 자물쇠를 열면 저장한 음악, 사진, 내용이 올바르게 표시된다.
- 내 자물쇠만 보기를 켜면 내 자물쇠만 표시된다. 이 검증이 의미 있으려면 테스트 지도에 다른 계정이 만든 자물쇠도 미리 준비해야 한다.
페르소나 2 (혼자만의 기록을 쌓는 직장인)
-
퇴근 후 음악을 들으며 산책하는 시간을 좋아한다. SNS에 공유하기보다는 자신의 기록을 차분히 쌓고, 가끔 지난 추억을 꺼내 보며 그때의 감정을 되새긴다.
-
사용자 흐름
- 퇴근 후 로그인해 현재 위치에 맞는 추천 플레이리스트를 확인한다.
- 대시보드 메뉴에서 내가 어디서 자물쇠를 남겼는지 기록을 확인한다.
- 이전에 남긴 자물쇠를 찾아 열어본다.
-
기대 결과
- 플레이리스트 추천 버튼을 클릭하면 추천 플레이리스트가 표시된다.
- 내 자물쇠만 보기를 켜면 본인의 자물쇠만 지도에 표시된다.
- 이전 자물쇠를 열면 저장한 음악, 사진, 내용을 다시 확인할 수 있다.
https://josh-dev.tistory.com/21
https://gs.statcounter.com/browser-market-share/mobile/south-korea
https://developers.kakaomobility.com/techblogs/e2e-testing.html