Fail률 감소 목표 집요하게 달성하기 — Android UI 자동화

안녕하세요. 29CM QA Engineer 홍해진입니다.

29CM QA팀에서는 모바일 앱 배포전 BVT(Build Verification Test : 빌드 검증 테스트)로 UI 자동화를 진행하고 있습니다.

Android UI 자동화를 만들며 겪었던 크고 작은 문제들 중 일부와 해결을 위한 시도와 개선해 나간 경험을 공유하고자 합니다.

발견

2023년 하반기 Android UI자동화 시나리오 완성으로 파이프라인을 통해 운영 배포 시 Android 자동화를 수행하였으나 다수의 시나리오에서 실패 현상이 발생하며 실패율이 높은 상태였습니다. 주 1회 배포 주기를 갖고 있는 상태에서 유지보수에 상당한 리소스를 쓰게 되며 다양한 원인으로 인한 오류들을 수정이 필요했고, 더 나아가 코드 리팩토링이 필요한 상황으로 판단되었습니다.

시도

(1) 빌드 앱에서 UI 변경으로 기존에 설정한 id 누락 또는 path 값 변경 발생

기존 코드에 작성된 path로 지정한 값들이 변경되어 실패 난 것을 확인하고 바로 변경된 path로 수정하거나 설정한 id 값이 누락되어 빌드된 경우에는 개발팀에 확인 요청하여 재적재된 빌드로 다시 진행했습니다. 자동화를 하게 된다면 아마 제일 많이 만나는 유지보수 건은 UI변경으로 인한 path 재 작업일 것으로 생각됩니다. 해당 이슈는 위 방법을 통해 처리 하긴 했지만, 궁극적인 예방은 아니라 다양한 예방법을 강구하고 실험해 나가고 있습니다.

(2) Window handler가 올바르게 전환되지 않아 Webview 시나리오 진행 실패

다음으로 발생하던 이슈는 네이티브에서 웹 뷰 전환 과정에서 윈도우 핸들러가 올바르게 전환되지 않아 웹 뷰 시나리오 진행 실패하는 케이스 였습니다. 아마 가장 오랫동안 저를 괴롭혔던 문제입니다.

여기서 잠깐, Webview 와 Window handler는 뭘까요?

그렇습니다. 29CM Android 앱에서는 웹 뷰로 여러 화면을 띄우고 있는데 각 화면별로 핸들러가 존재하고, 해당하는 화면의 핸들러로 전환되어야 화면 컨트롤이 가능해지는 것을 알게 되었습니다.

네이티브에서 웹 뷰로 전환 시 마지막 핸들러가 화면 최상단에 있는 페이지와 같으나 실제 29CM 앱에서는 핸들러가 여러 개 중첩된 형태로 발생하고 있었습니다.

1차 시도로는 웹 뷰 전환 시 마지막 핸들러가 아닌 마지막에서 2번째 핸들러로 전환 시도했고, 문제 발생한 시나리오에서는 해결된 듯했으나 전체 시나리오 진행상 여러 번 웹 뷰, 네이티브를 스위칭을 하며 시나리오 별로 다른 위치에 핸들러가 위치하는것을 확인하게 되면서 동일하게 제어가 불가능한 상태로 해결에 실패했습니다.

2차 시도로는 각 시나리오 별로 위치하는 핸들러로 지정하여 전환 시도해 보았고, 전체 시나리오를 수행하는 경우에는 실패율이 낮아졌으나 각각 시나리오로 돌리거나 일부 시나리오를 제외하고 수행 시에 핸들러가 다시 제각각 기존과 다른 위치로 쌓여있는 문제 발생하여 실패했습니다.

3차 시도로 리더에게 자문을 구하고 시나리오 별 핸들러 이슈 끊기 위해 일부 시나리오 진행 후 앱 재실행하여 핸들러 히스토리 없애도록 분리 작업도 진행해보았습니다. 발생하는 실패율은 낮아졌으나 근본적인 해결 안되고 중간에 시나리오 실패하면 이후부터는 다시 핸들러 제어 불가한 상태 발생과 더불어 기존에 슬랙 알림이 쪼개져서 노출되어 많아지게 되었습니다. (기존 1개 알림에서 ~ 최대 6개로 늘어남)

분할된 알림이 많아짐

이 상태가 되니 일부 수정으로는 점점 다른 문제만 발생하고 있어 대대적인 구조 리펙토링을 진행해 보게 되었습니다. 각 시나리오 별로 따로 케이스를 분리하여 종속성을 없애고, 시나리오 종료 시 앱 재실행하여 핸들러 히스토리를 삭제하여 핸들러 이슈 발생하지 않도록 수정, 해체된 알림 구조 개선으로 다시 1개로 합쳐서 보이도록 수정하게 되었습니다. 이렇게 다양한 시도 끝에 현재 핸들러로 인한 fail은 감소하게 되었습니다.

(3) 로컬 코드 직접 실행 시에는 정상이나 CI/CD 파이프 라인을 통해 실행 시 시나리오 실패 또는 앱 종료 발생

STF로 로컬 코드를 직접 실행 시에는 정상 수행하였으나, 파이프라인에서 실행 시 빈번하게 화면에서 element 탐색 실패 또는 앱 종료 발생하는 문제가 있었습니다.

여기서 또 잠깐, STF는 뭘까요?

현재 29CM QA 팀은 Android STF를 이용하여 여러 대의 단말기를 보유, 연결된 단말기에서 자동화를 수행하고 있습니다.

이 문제를 해결하기 위해 일단 파이프라인으로 실행 시 높은 빈도로 실패 나는 시나리오를 찾았고

1. 주로 자동화 실행 시 최초 시나리오에서 높은 빈도로 발생
2. 실제 화면에는 ID값이 있으나 화면전환 후 발견해야 할 요소를 못 찾고 실패

크게 2가지를 찾을 수 있었습니다.

iOS와 달리 Android에서는 드라이버의 수행 동작이 빨리 페이지 로딩 완료보다 요소 탐색을 먼저 진행하는 경우가 작업하면서 종종 발생했었는데 파이프라인에서는 직접 연결된 단말기에 수행, 연결된 PC 스펙이 높다 보니 제가 대비했던 코드에서보다 더 빠르게 진행하여 실패가 발생하였습니다.

이때는 화면 전환이나 액션 동작 시 코드로 시나리오 동작을 천천히 하도록 잠시 멈추고 기다리도록 코드를 수정해 보았고 일부는 해결되었으나, 역시 수행 중에 앱 종료나 실패 현상이 완벽하게 해결되지는 않았습니다.

결국 코드 수정 후 로컬에서 1차 확인, STF로 연결해서 2차 확인, 연결된 PC에서 3차 확인을 통해 문제 발생 지점은 재확인하는 순서로 수정,보완했습니다.

다양한 시도 끝에 현재는 초기 발생 시점보다 fail률이 현저하게 낮아지는 성과를 얻었습니다. 하지만 유지보수는 언제 또 어디서나 발생 할 수 있기 때문에 항상 예의 주시하며 트레킹 하고있습니다. 더 나아가 시나리오 시간 단축과 테스트가 필요한 시나리오를 보강하여 더욱더 견고히 하려고 노력 중입니다.

이번 Android 자동화 fail률 감소 시키기위한 시도를 통해 다양하며 크고 작은 어려움을 만나면서 개인적으로 자동화에 대한 희로애락을 맛보는 경험을 했던 것 같습니다.

어려움 속에도 끝까지 포기하지 않고, 오늘 안되면 내일, 내일도 안되면 모레 꺾이지 않는 마음으로 다양한 방법을 찾아보고 생각하며 많게 시도해보는 것이 저에게는 더 나은 성장을 할 수 있었던 것 같습니다. 그리고 그 안에서 많은 도움과 격려를 해주셨던 팀원분들에게 감사를 전하고 싶습니다.

마지막으로 저와 비슷하게 자동화에 어려움을 만나는 분들에게 힘내라고 응원하고 싶습니다. 꺾이지 않는 마음이면 해 낼 수 있습니다!

긴 글 읽어주셔서 감사합니다.