3차 데모데이
- 실제 동작과 유사한 동작을 하기에 신뢰성 있는 테스트 제공
- Unit Test 와 Android Test 에서 재사용 가능
- Fake 객체에서 실제 예외를 발생시키는 시나리오, 로직을 추가함. (신뢰성 ↑)
-
테스트용 객체 파일 (FakeRepository, Fixture) 들의 중복 생성을 막기 위해 모듈 분리
-
Testing모듈에서 한 번에 관리할 수 있도록 설정
-
- 테스팅 모듈 분리로 인한 의존성 관리를 위해 전체 프로젝트를 멀티 모듈화 진행
- 장점
- 패키지 구조 컨벤션을 정했음에도, 생각보다 지켜지지 않았다. 하지만 모듈화를 통해 컨벤션을 강제적으로 지킬 수 있었다.
- 모듈이 분리되어 있어 DX 향상.
- 모듈 분리의 이점으로 빌드 속도가 빨라진다는 것도 있음 하지만 실제로 확인(경험)하지 못함.
-
가로 모드 대응을 하고 있기에, 화면별 Portrait, Landscape 테스트는 필수적으로 진행
-
UI Test 에서 프래그먼트, 액티비티에서 가짜 객체를 갈아 끼워야 하기 때문에 서버 통신을 가지는 UI test 는 아직 미완.
- Service Locator 패턴 사용,
- viewModel 레지스트리 접근해서 가짜 객체를 넣는다.
-
기기 별로 테스트를 진행할 수 있도록 설정
- api 30 미만에서는 터지는 이슈 있었음 -> 모든 버전 기기에서 테스트 필요 => 자동화
- API levels 27 - 34 까지 설정
- 질문할 것: github action CI 시에 자동으로 UI test 를 avd 로 직접 돌릴 수 있는 방법이 있을까요?🕯️
-
UI Test 에서 프래그먼트, 액티비티에서 가짜 객체를 갈아 끼워야 하기 때문에 서버 통신을 가지는 UI test 는 아직 미완
해결책)
- Service Locator 패턴 사용
- ViewModel 레지스트리 접근해서 가짜 객체를 넣는다.
- 데이터 캐싱 (InMemory, Repository)
- API 요청을 통해 불러온 포켓몬, 특성 정보들을 캐싱하여 속도 개선 및 안정화
- Event Throttle
- 클릭 이벤트에 Throttle 처리를 적용하여 불필요한 네트워크 요청을 줄임
- 화면 별 가로 모드 전용 레이아웃 설정
- 포켓몬, 특성 검색 시 초성으로 검색할 수 있도록 구현
- 개발서버에 문제가 생겼을 경우 로컬 호스트로 자동으로 리다이렉션 하도록 설정
- okhttp interceptor 를 활용
- 라벨링 자동화
- 특정 키워드를 입력하여 안드로이드 채널에 알림을 보낸다
QA를 통해 받은 피드백을 토대로 개선하는 작업 진행
- 이미지 PlaceHolder 설정
- 이미지가 없는 포켓몬이 있는 경우 일관성있게 시각화 할 수 있도록 대응
- 상성 설정 탭의 위치 변경
- 내 타입과 상대 타입 탭 위치를 수정
- 로딩 창 개선
- 페이지 이동 개선
- 홈 버튼 추가
- Toolbar 개선
- 포켓몬 도감 상세 정보 색상 설정
- 각 능력치에 대한 정보의 가독성을 높임
- 특성 목록 화면의 최대 줄 수(MaxLine) 지정
- 일관성 있는 디자인을 통해 화면의 복잡성을 줄임
앱이 비정상 종료되지 않도록 에러 핸들링
- ViewModel 에서 CoroutineExceptionHandler를 공통 예외 처리기로 사용 => 추후, data Layer 에서 처리할 예정
- 네트워크 에러
- 네트워크에 연결되지 않은 경우, 사용자에게 안내 메세지를 보여주도록 설정
- 일반적인 예외 및 UnKnown 예외
- 토스트 메세지를 띄워서 처리
Debug, Alpha, Beta, Release 모드로 분리하여 로깅 툴 설정
-
Debug: 개발 버전 -
Alpha: 팀 내 QA 버전 -
Beta: 특정 테스터 그룹(e. 우테코 크루)을 대상으로 QA 버전 -
Release: 실제 출시하는 제품
Firebase Crashlytics를 사용하여 어떤 예외로 인하여 비정상 종료가 발생했는지 파악
- 예시 소개 하기 ) 🪀
- QA를 진행하며 비정상 종료 상황을 파악한 후 안드로이드, 백엔드 각각 우선적으로 대응
- 비정상 종료 원인
- NetworkConnection
- 404 error
- 429 error
- 비정상 종료 원인
- 비정상 종료 비율 비교
- 알파 0.1.0 / 0.1.1
- 비정상 종료
70%대 - Crash (111번)
- 429 error
- 비정상 종료
- 베타 0.1.1.
- 비정상 종료 27%
- Crash 를 경험한 유저 6명(22번)
- NetworkConnection
- 404 error
- 베타 0.1.2
- 비정상 종료
0% - Crash 를 경험한 유저 0명(0번)
- 비정상 종료
Firebase Analytics 를 사용하여 사용자들의 행동을 파악
-
사용자가 어떤 흐름으로 앱을 사용하는지
- 홈 화면에서 어떤 화면으로 이동을 가장 많이 하는가?
- 포켓몬 상세 화면과 특성 화면 간의 이동을 자주 하는가?
-
사용자가 의도한 대로 기능을 잘 이용하는 지
- 포켓로그 바로가기 기능의 위치 선정이 잘 되었는가?
- 앱 상단의 더보기 버튼을 잘 인지하여 눌러보는가?
- 결과 예시 하나 구체적으로 있으면 좋으려나? 근데 뭐가 있나..?
- 질문할 것: github action CI 시에 자동으로 UI test 를 avd 로 직접 돌릴 수 있는 방법이 있을까요?
-
페어 활동해서 좋았던 점 ?
-
로컬호스트로 띄워서 도움이 되었는지 ?
⇒ too many request로 ip밴 되었을 때 로컬 호스트로 작업할 수 있었음
-
BETA와 RELEASE는 같은 로거를 사용하고 있는건가? → BETA와 RELEASE를 나눌 필요가 있나?
-
기술 + QA 후기
-
기술적으로 ?
⇒ 어떤 이유로 시도했고, 대응에 실패했을 때 차선책을 잘 찾음
- 테스트 전략
⇒ 자동화 전략 및 모듈분리
⇒ 상당히 이상적인 테스트 전략을 사용하고 있음 굿 대박
⇒ api버전별로 테스트하고 CI에 반영하는게 어려운데 시도한 부분 대박임 블로그나 발표할 때 쓰면 좋을듯
⇒ 별도의 의존성 추가 해야함 파이어베이스 테스트랩? 어떤 디바이스 어떤 컨디션에서 할 수 있음 (유료임)
- 모니터링 환경 구축
⇒ 정량적인 데이터로 어떻게 분석을 해야할지 감이 오지 않아서, 정성적인 방법을 시도한것도 좋았음
⇒ 나중에 고도화할때는 터널식으로, 어떤 액티비티에서 어떤 버튼
⇒ 시나리오를 세우고 어디서 이탈을 하는지??
- 이유가 너무 잘 보여서 좋았다
인메모리캐시 → 변경사항이 발생하지 않으면
로컬DB → 오프라인 실행될 가능성, 화면전환으로 인한 앱이 꺼질 때, 스택이 쌓여 있는데 refresh
-
엘크로 로깅 시스템을 선택한 이유?
-
구축한 api에서 네트워크 리소스를 가장 많이 사용하는 부분?
-
봇 공격 보안을 했는데, 여러번 요청을 다 막아야 하는..?
⇒ 아직 안드에서 디스크 캐싱으로 한게 아니고, 메모리 캐싱으로 했음
-
ec2에서만 쓸 용도라면, 자동화의 영역이 아닐 수도
-
FAIL2BAN 엔진엑스에도 있는데, 도커로 띄운 이유?
-
포켓몬 정보가 DB에 들어가있으면, 백엔드에서도 캐싱전략
-
CI와 CD가 동시에 실행되도록 한 이유??