Robot Framework와 QA팀 동행기: 웹 테스트 자동화 (2)

권영민Lucian (루시안)/QA팀여기어때

2025년 3월 28일

안녕하세요. 여기어때컴퍼니 QA1팀 루시안입니다. 앞서 같은 팀 요셉이 QA팀에 도입하게 된 Robot Framework를 통한 테스트 자동화에 대해 소개했었습니다.(Robot Framework와 QA팀 동행기: 시작과 도전(1))

이번엔 Robot Framework를 통해 여기닷컴(http://www.yeogi.com)에 적용한 웹 테스트 자동화에 대해 소개하겠습니다.

웹 테스트 자동화의 장점 파악

웹 테스트 자동화를 시작하면서 먼저 진행한 것은 장점 파악이었습니다. 웹 테스트 자동화에 대한 장점을 먼저 파악 후, 이 부분들을 최대한 살리면서 자동화를 진행 해보려고 했습니다. 저희는 아래의 장점들로 여기닷컴에 먼저 웹 테스트 자동화를 적용했습니다.

첫째, 다양한 플랫폼에서 테스트가 가능합니다.

웹은 크로스 플랫폼을 지원하기에 윈도우, 맥, 리눅스 등 다양한 운영체제에서 동일한 브라우저 기반 테스트가 가능합니다. 그로인해 웹에서는 동일한 테스트 스크립트를 여러 플랫폼에서 쉽게 실행할 수 있습니다. 또한, PC, 태블릿, 스마트폰에서 동일한 인터페이스로 접근할 수 있어, 다양한 기기와 해상도를 고려한 테스트 자동화를 실행할 수 있습니다.

이번에 웹 테스트 자동화를 진행하는 인원들이 윈도우, 맥과 같은 다른 운영체제에서 각각 스크립트를 작성하였지만 모두 동일한 브라우저 기반 테스트가 가능한 점도 이 부분 때문이었습니다. 그리고 현재 여기닷컴은 반응형 웹으로써 태블릿과 스마트폰 해상도를 지원하고 있습니다. 해상도 변경을 통해 다양한 해상도에서 자동화 테스트가 가능합니다.

둘째, 브라우저 호환성 테스트에 활용할 수 있습니다.

웹 테스트 자동화는 하나의 스크립트로 여러 브라우저(크롬, 파이어폭스, 사파리 등)에서 호환성 테스트를 쉽게 수행할 수 있습니다. 브라우저 호환성 테스트가 쉽다는 건 동일 시간내 이전보다 테스트를 더 많이 수행 할 수 있고, 더 많은 브라우저, 더 많은 버전에 대한 테스트가 가능해져 원하는 만큼의 브라우저별/버전별 호환성 확인이 가능하다는 걸 의미합니다.

현재 구축 해놓은 웹 테스트 자동화 스크립트는 위의 장점을 활용해 하나의 스크립트로 크롬, 파이어폭스, 사파리 브라우저 환경만 변경 해서 테스트 할 수 있도록 구성해 두었습니다.

셋째, 브라우저의 개발자 도구를 활용할 수 있습니다.

웹 테스트 자동화는 브라우저 개발자 도구를 통해 네트워크 요청, 콘솔 로그, 성능 측정 등의 추가적인 디버깅 정보를 쉽게 얻을 수 있고 스크립트 작성을 위한 Locator의 정보도 얻어낼 수 있습니다. 그리하여 테스트 스크립트를 작성하면서 각 Element에 대한 Locator 값을 얻어낼 수 있었습니다. 이 Locator값을 유니크한 값으로 축약시킨 후, 브라우저 개발자 도구에서 DOM 검색을 통해 축약한 Locator값이 맞는지 확인 또한 가능했습니다. 축약한 Locator값을 적용함으로써 테스트 코드에 대한 가독성을 증가시킬 수 있었고 유지보수가 쉬워졌습니다. 그리고 팀 협업 시 표준화 효과 또한 얻을 수 있었습니다.

넷째, 리소스 소비를 줄인 경량화 테스트가 가능합니다.

Headless 모드를 사용하면 실제 브라우저를 렌더링하지 않고 테스트를 실행할 수 있어 리소스 소비를 줄이면서 동시에 빠른 테스트가 가능합니다.

현재, 여기닷컴에 적용한 웹 테스트 자동화는 Jenkins 서버에서 Headless 모드를 통해 UI 없이 모니터링 테스트를 수행하고 있습니다. 이로 인해 더욱 빠르게 테스트 할 수 있습니다.

위 네 가지 장점들을 자사의 시스템안에서 최대한 활용할 수 있는 방법을 찾아 저희는 웹 테스트 자동화를 시작하였습니다.

자동화 영역에 대한 고민

두번째로 위의 장점들을 토대로 저희가 진행하고 있는 검증 영역 중 테스트 자동화가 가능한 영역에 대한 구분이 필요했습니다. 현재 여기닷컴 영역에 대한 검증은

여기닷컴 업데이트 검증 프로세스

총 3단계로 나뉩니다. 해당 업데이트 버전에 포함된 Feature의 단위 검증 후, 웹 영역 전체에 대한 통합 검증을 진행하고, 마지막으로 배포 이후 배포 검증을 하고 있습니다.

이 중 업데이트 버전마다 수행 중인 통합 검증은 3 ~ 4일의 일정이 월 2 ~ 3회 씩 필요합니다. 그리고 통합 검증은 Testcase를 고도화 하지 않는다면 매번 동일한 내용을 반복적으로 테스트해야만 하기 때문에, 테스트 자동화를 적용하기에 적합하다고 판단하였습니다.

위 이미지는 웹 업데이트 검증시마다 반복적으로 수행하고 있는 통합 검증 TestCase입니다. 이 시트에 Auto/Manual 컬럼을 추가해 테스트 자동화가 된 영역은 Auto로 기입하였습니다. 그리하여 통합 검증시 Manual 영역만 검증하고 나머지 영역은 테스트 자동화를 통해 검증하였습니다. 이렇게 기존의 통합 검증 TestCase를 활용하여 테스트 자동화를 진행하게되니 별도의 TestCase가 필요하지 않아 추가적인 리소스가 들어가지 않았고 실제 통합검증시 활용도도 높아졌습니다.

테스트 스크립트 작성

테스트 스크립트는 영역별 담당자를 지정해서 작성을 시작했습니다. 테스트 스크립트를 작성하면서 저희는 아래의 부분들을 기준으로 잡았습니다.

첫째, 현재 통합 검증에 대한 영역을 각각 나눠서 진행하되, 공통적으로 사용 되는 스크립트에 대해선 키워드화 하였습니다.

*** Keywords ***
Login
    [Documentation]    이메일 로그인
    [Arguments]    ${email}    ${password}
    Click Element    xpath://span[text()="로그인/회원가입"]
    Wait Until Element Is Visible    xpath://a[@class="btn email-login"]
    Click Element    xpath://a[@class="btn email-login"]
    Sleep    2s
    Input Text    xpath://input[@name="userEmail"]    ${email}
    Input Text    xpath://input[@name="userPassword"]    ${password}
    Click Element    xpath://button[@type="submit"]

Logout
    [Documentation]    로그아웃
    Click Element    xpath://*[@aria-label="여기어때 로고"]/../..//img
    Wait Until Element Is Visible    xpath://a[text()="로그아웃"]
    Click Element    xpath://a[text()="로그아웃"]

예시로 위의 스크립트는 모든 페이지에서 반복적으로 수행되는 로그인/로그아웃에 대해 키워드화한 내용입니다. 이처럼 다수의 영역에서 공통적으로 반복되는 작업에 대해선 리소스 파일에 키워드화하여

국내숙소_PDP_헤더_005. 로그인
    [Documentation]    로그인 후 PDP 노출 확인
    Login    ${login_id}    ${login_pw}
    Wait Until Location Contains    ${url}

해당 스크립트처럼 키워드만 불러오도록하고, 불필요하게 반복되는 작업을 줄였습니다.

둘째, 필요한 영역만 테스트 할 수 있도록 모듈화 했습니다.

각 영역별로 모듈화를 해놓아 특정 영역에 대한 검증 필요시 해당 부분만 빠르게 검증할 수 있습니다. 또한, variable 파일을 통해 Staging서버 / 상용 서버에 대한 변수 값을 컨트롤 하도록 해두어, 변수 파일을 통해 Staging 서버에서의 통합 검증과 상용 모니터링을 돌릴 수 있도록 해두었습니다.

셋째, Headless를 사용하여 테스트 자동화시 리소스를 절약하고 속도를 향상 시켰습니다.

위 이미지와 같이 해당 옵션을 통해 Headless 모드를 사용하게 되면, 실제로 브라우저 UI를 렌더링하지 않으므로, 메모리와 CPU 사용량이 적습니다. 이는 특히 서버 환경에서 리소스를 효율적으로 사용할 수 있고, CI/CD 파이프라인에 적합하여, 젠킨스 CI 서버에서와 같이 UI가 없는 환경에서도 쉽게 테스트를 실행할 수 있습니다. 그리고 추후 병렬 테스트가 필요할 시 여러 브라우저 인스턴스를 동시에 실행할 때도 Headless 모드가 유리할 것으로 기대하고 있습니다.

다음으로 소개할 모니터링 테스트에도 이 부분을 적용하여, 현재 모니터링 테스트는 Headless로 테스트 하고 있습니다. Headless로 진행하더라도 Fail이 생기는 부분은 이에 대한 스크린 샷이 저장되고 있어 그 원인을 파악할 수 있습니다.

웹 서비스 UI 모니터링 구축

이렇게 작성된 테스트 스크립트들은 GitLab을 통해 형상 관리하였고, 통합 검증 뿐만이 아닌 웹 서비스 UI 모니터링에도 재활용하기로 결정했습니다. 단, 실시간 모니터링은 아니고 Jenkins의 스케줄링 기능을 활용하여 4시간 단위로 실행하도록 하였습니다.

여기닷컴 UI 모니터링 자동화 프로세스

현재 웹 서비스 UI 모니터링은 QA 엔지니어가 작성한 테스트 스크립트를 도커를 이용하여 Robot Framework, Selenium과 같이 패키징하였고, 이를 실행하는 프로세스로 되어 있습니다. 또한, 모니터링이 완료되면 Slack 통해 테스트 결과 Report를 공유하여, 팀원들이 빠르게 대응할 수 있습니다.

위의 프로세스 적용으로 얻은 장점을 꼽자면,

별도의 시스템 환경 설정없이 실행할 수 있는 웹 서비스 UI 모니터링을 자동화한 것입니다.

이 프로세스로 웹 서비스 UI 모니터링을 위한 Job을 주기적으로 실행할 수 있고, QA 엔지니어 뿐만아니라 PO와 개발자에게도 그 권한을 부여할 수 있게 되었습니다.

테스트 자동화 도입 이후

이렇게 통합 검증 및 모니터링 업무에 테스트 자동화를 도입하였고, 아래는 Robot Framework 자동화 도입 이후 변화된 점들 입니다.

첫번째는 리소스를 더욱 효율적으로 배분합니다.

여기닷컴의 정기 업데이트는 2주단위로 진행되고 있고 여기에 반복적으로 검증하고 있는 통합 검증이 3d 정도 소요 되고 있었습니다. 이번에 목표하고 있는 커버리지까지 통합 검증을 자동화 했을 때 일정을 최대 1.5d로 줄일 수 있을것으로 예상하고 있습니다. 그래서 통합 검증보다 버전에 반영 예정인 Feature 검증에 더욱더 리소스를 투입할 수 있게 될 것 입니다.

두번째로 모니터링을 통해 빠르게 이슈를 파악하고 대응합니다.

여기닷컴은 현재 Jenkins를 통해 4시간 단위로 모니터링하고 있고, 이를 통해 이슈 발생시 신속하게 파악하여 대응할 수 있게 되었습니다. 현재의 웹 모니터링 채널은 QA담당자들 뿐만 아니라, 웹 담당 PO 및 개발자 모두 확인 하고 있으며, 이슈 발생시 함께 원인을 파악하고 있습니다.

마치며…

현재, 웹 서비스 UI 모니터링 자동화는 여기닷컴 내의 국내숙소 및 해외숙소 카테고리까지 적용하였고, 계속해서 커버리지를 확장하고 있습니다. 또한 PC 웹을 기반으로 모니터링을 수행하고 있지만, 곧 스마트폰 및 태블릿 해상도까지 확장해 나갈 예정입니다.

물론, 테스트 자동화가 모든 영역을 커버할 순 없습니다. 웹 업데이트에 따라 수시로 유지 보수를 진행해야 하고, 검증 업무와 병행해야 하는 등 어려움도 따르고있지만 더 나은 품질을 위해선 꼭 필요한 과정이라 생각합니다. 앞으로도 여기어때 품질의 보증, 개선을 위해 테스트 자동화를 고도화하고 확장해 나갈 예정입니다.

감사합니다.