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://show5116.tistory.com/entry/%ED%9A%8C%EC%9B%90%EA%B0%80%EC%9E%85%ED%95%98%EA%B3%A0-%EA%B8%80-%EC%93%B0%EA%B3%A0-%EC%82%AD%EC%A0%9C%EA%B9%8C%EC%A7%80-%ED%95%9C-%EB%B2%88%EC%97%90-%EB%B0%B1%EC%97%94%EB%93%9C-E2E-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%9E%91%EC%84%B1%EB%B2%95

https://josh-dev.tistory.com/21

https://qa-subi.tistory.com/9

https://gs.statcounter.com/browser-market-share/mobile/south-korea

https://haesolene.tistory.com/entry/Playwright%EC%99%80-CICD-%EC%9E%90%EB%8F%99%ED%99%94-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A1%9C-%ED%92%88%EC%A7%88-%EA%B4%80%EB%A6%AC%ED%95%98%EA%B8%B0#google_vignette

https://developers.kakaomobility.com/techblogs/e2e-testing.html