기능 자동화 기술조사부터 환경 구성까지

기능 자동화 환경 구성을 위해 필요했던 기술 조사부터 어떤 방식으로 환경을 구성했는지 정리하는 포스팅입니다.
처음부터 끝까지 직접 작업한 내용이고, 더 나은 방법이 있을 수 있습니다 !

이전에 정리했던 포스팅들의 종합적인 내용이 포함되어 있습니다 :)

 

안녕하세요 오랜만에 돌아온 자동화 관련 포스팅입니다.

 

올해는 기능 자동화를 위한 한 해가 되었던 느낌인데, 사내 발표를 진행한 내용을 바탕으로 블로그에도 포스팅해보려고 합니다. 자동화를 진행 중이거나, 어떤 방식으로 구성했는지 궁금하시다면 제 포스팅을 참고해 주세요 😎

 

 

사내에서 발표했던 내용을 바탕으로 PPT를 정리해 보도록 하겠습니다. 몇몇 자료는 제외하고 포스팅 가능한 부분만 추려서 설명해보려고 합니다.

 

작년부터 QA 컨퍼런스에서 자동화 관련된 얘기가 몇몇 보이기 시작했는데, 올해는 QA 컨퍼런스 절반이 자동화와 관련된 내용으로 구성되어 있었습니다. QA에 있어서 테스팅은 필수적이고, 이것을 자동화할 수 있는 환경이 구성되어 있다면 반복적으로 테스트를 수행하기 때문에 안정성을 높여주면서 테스트에 투입되는 비용을 감소할 수 있기 때문에 많은 관심이 있던 것 같습니다.

 

사내에서 자동화 환경 구성은 올해 초부터 진행하였으니 너무 늦지 않게 대세를 따라간 듯합니다 😏

 

 

사실 기술 조사를 하기 전 제품 브라우저 사양 때문에 선택 권한이 없었습니다. 

하지만 팀 간 협의를 통하여 자동화에 필요한 라이브러리에 대한 제약조건이 없어지고 자유롭게 선택할 수 있었는데, 그림처럼 Selenium, Cypress, Puppeteer, Playwright 네 가지 라이브러리를 비교 분석하게 되었습니다.

 

 

네 가지 툴 비교는 더 상세하게 분석을 하였지만 간략하게는 그림처럼 평가하고 측정하여 Playwright를 선정하게 되었습니다.

상세한 내용은 아래 링크를 확인해 주세요 :)

 

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

기능 테스트 자동화, 왜 Playwright를 선정했을까? (1)

 

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

기능 테스트 자동화, 왜 Playwright를 선정했을까? (2)

 

 

 

1~2월에 걸쳐서 기술조사를 진행하였고, Playwright를 선정하였는데, 현재 npm trand를 확인한 결과 네 가지의 라이브러리 중 가장 많이 다운로드하여서 사용하고 있는 라이브러리가 되어있네요! 나쁘지 않았던 채택이라는 것을 증명하는 자료였습니다 😎

 

 

자동화 환경은 위 그림처럼 설계해서 구현하였습니다.

 

우선 Playwright는 다른 영향을 받지 않고 테스트만 수행할 수 있는 별도의 서버가 필요했습니다. 물론 성능이 좋은 서버가 있다면 상관없겠지만, 브라우저 테스트는 생각보다 리소스를 많이 잡아먹기 때문에 별도로 구성하였고, Worker node 값을 5로 설정하여 5개의 테스트가 동시에 수행되는 환경을 구성하였고 다른 서버에 구성한 Jenkins에서 이를 호출하고 응답을 받을 수 있는 환경을 구성하였습니다.

 

그래서 Jenkins만으로 시스템을 전체 관리를 주도하는 그림을 구상하였고, Jenkins에서 자동화 수행에 필요한 파라미터 값을 입력하고 빌드를 수행하면 Playwright가 설치된 서버에서 Git을 통해 자동화 스크립트를 내려받고 Playwright를 수행하도록 하였습니다.

 

자동화를 수행하려는 브라우저를 파라미터 값으로 받으면 Playwright는 선택된 브라우저를 통해 제품 도메인 링크로 접속하여 스크립트를 수행하고, 수행 결과를 종합하여 Allure Report 환경으로 결과를 정리하였습니다.

리포트 작성이 완료되면 Jenkins에 결과를 전달하고 Jenkins는 이 결과를 토대로 성공, 실패 여부를 Slack으로 전달하게 하였습니다.

 

 

테스트 수행 방식은 두 가지로 구분하여 구성하였습니다.

먼저, 시나리오 테스트의 경우 시나리오 기반의 테스트 자동 수행 시나리오입니다. 사용자가 특정 동작을 하기 위해 시작부터 끝까지 수행하는 사용자 시나리오를 구성하였습니다. 여러 가지의 상황의 시나리오 목록을 만들고 제공하여 원하는 시나리오를 동작할 수 있도록 하였습니다.

 

두 번째, 데이터 자동 설정 시나리오는 시나리오 테스트를 응용하여 만들게 되었습니다.

제품 특성상 사전 데이터를 설정해야 하는 작업들이 빈번하게 필요했습니다. 하지만 데이터를 쌓고 나면 서버 DB를 초기화해야 하는 상황이 왔을 때 다시 계정에 데이터를 쌓는 과정은 정말 귀찮은 작업이었거든요... 

그래서 데이터 자동 생성 스크립트를 만들어서 제공한다면, 매뉴얼 테스트를 수행하는 테스터에게 테스트를 수행하기 위해 필요한 데이터 설정 같은 사전 작업들에 들어가는 공수를 조금이라도 줄일 수 있지 않을까?라는 생각으로 만들게 되었습니다.

 

그래서 이 스크립트는 제품 테스트를 하거나, 제품을 써보기 위해 필요한 사전 데이터들을 알아서 설정해 주는 스크립트를 작성하였습니다. 

데이터 자동 설정 스크립트를 만든 후로는 데이터를 밀어야 하는 상황에도 큰 스트레스를 받을 필요가 없어졌습니다. 

 

자동화를 사용하는 개발자, 기획, PM 분들은 TestRail에서 시나리오 목록과 동작 방식을 확인하고 원하는 시나리오와 테스트를 수행할 도메인을 설정 후 Jenkins 빌드를 수행하면 테스트가 수행되는 프로세스를 구성하였습니다.

자동화 스크립트 동작 시 발생하는 오류는 직접 수정해 주고 필요한 시나리오를 제공해 주면서 자동화를 사용하는 사용자는 Playwright를 전혀 몰라도, Jenkins 수행만으로 안정성을 높일 수 있는 환경을 제공할 수 있었습니다.

 

데이터 자동 설정 스크립트도 동일한 방식으로 사용할 수 있도록 구성하였습니다.

데모 영상도 있고 다른 자료들도 많이 포함되어 있으나, 회사 제품이 포함된 부분이 있기에 제외하였습니다.

 

테스트 자동화 스크립트 제공뿐만 아니라 이것을 응용해서 보다 편리한 매뉴얼 테스트 환경을 제공할 수 있는 방식도 생각하면서 업무를 진행했습니다. 물론 자동화 환경이 많은 테스트 케이스를 커버할 수 있는 환경이 된다면 필요하지 않을 수 있는 기능일 수 있으나, 아직 매뉴얼 TC 대비 자동화 TC는 부족한 편이라 조금이라도 도움 줄 수 있는 부분을 생각하다보니 이런 스크립트도 작성해본 것 같습니다.

 

나중엔 API와 연계해서 기능 자동화 환경을 구성하려고 하는데 많은 학습이 필요할 것 같네요..

기능 자동화 환경 구성에 조금이라도 도움이 되었다면 포스팅 공감 한번 부탁드리겠습니다 :)