이득:
- data-testid, open wait, 실제 사용자 결과를 확인하는 Assert 등 인공 지능을 사용하여 강력한 UI 테스트 코드를 생성하는 기능
- 취약한 테스트(잘못된 선택기, 블라인드 대기)를 방지하고 페이지 개체 모델 구조에서 테스트를 쉽게 유지 관리할 수 있는 기능
- 코드를 깨뜨려 생성된 모든 UI 테스트를 테스트하고 가짜 통과 테스트를 감지하고 수정하는 기능
사용자가 브라우저에서 수행하는 모든 클릭, 모든 양식 채우기, 모든 페이지 전환은 수동으로 반복해서 테스트할 수 없습니다. 이것이 바로 UI 테스트 자동화(사용자 인터페이스, 이러한 테스트가 실제 브라우저를 프로그래밍 방식으로 구동하여 사용자 동작을 모방하는 테스트)가 존재하는 이유입니다. Selenium, Playwright 및 Cypress는 이 작업에 가장 일반적인 도구입니다. 인공 지능(AI)은 이러한 도구에 대한 코드를 작성하는 데 매우 능숙합니다. 테스트 사례를 설명하면 AI는 실행 가능한 자동화 스크립트 초안을 제공합니다. 그러나 여기서 이 모듈의 핵심 경고가 다시 작동합니다. AI가 생성하는 UI 테스트 코드는 종종 "녹색으로 켜지지만 잘못된 것을 확인"하거나 바람에 펄럭이는 취약한 테스트일 수 있습니다. 당신의 임무는 이 코드를 실행하는 것이 아니라 실제로 올바른 것을 확실하게 검증하는 것입니다.
이 단원에서는 AI를 사용하여 강력하고 유지 관리가 가능하며 실제로 검증 가능한 UI 테스트를 생성하는 것을 목표로 합니다. 깨지기 쉬운 테스트를 피하는 방법을 배우게 됩니다.
견고한 UI 테스트의 세 가지 기둥
1. 올바른 요소 로케이터. 테스트에서는 선택기를 사용하여 페이지에서 요소를 찾습니다. AI는 긴 XPath 경로(페이지 구조에 지나치게 의존하는 주소), CSS 클래스 이름 기반 선택기(디자인 변경 시 중단됨) 등 취약한 선택기를 생성하는 경우가 많습니다. 강력한 방법은 개발자가 테스트를 위해 추가한 data-testid와 같은 안정적인 속성입니다. 이를 AI에 명시적으로 적용합니다.
2. 명시적인 대기. UI 테스트에서 취약점의 가장 큰 원인은 타이밍입니다. 끊임없는 수면(3)(무의식적 대기)은 나쁜 습관입니다. 때로는 충분하지 않을 때도 있고 시간을 낭비할 때도 있습니다. 올바른 방법은 "이 요소가 나타날 때까지 기다리십시오"라는 명시적 대기를 사용하는 것입니다. 극작가는 이 작업을 대부분 자동으로 수행합니다. Selenium에서는 명시적으로 요청해야 합니다.
3. 의미 있는 주장. 테스트에서는 단순히 '페이지가 로드됨'이 아니라 '화면에 표시된 주문 번호'와 같이 사용자가 실제로 보게 될 결과를 확인해야 합니다. AI가 생성한 테스트에 어설션이 없거나 중요하지 않은 경우 해당 테스트는 의사 통과(1번째 단위)를 생성합니다.
주의: AI 생성 UI 테스트를 처음 볼 때 선택기가 커밋되었는지(data-testid), 대기 중인지(블라인드 슬립 없음), 어설션이 실제 사용자 결과를 확인하는지 최대 세 가지를 확인하세요. 이 세 가지가 괜찮다면 테스트는 아마도 확실할 것입니다.
페이지 객체 모델
테스트 규모가 커짐에 따라 각 테스트 내에 선택기를 작성하는 것은 유지 관리가 악몽이 됩니다. 페이지 개체 모델(POM — 각 페이지/화면에 대한 선택기와 작업을 단일 클래스로 수집하는 디자인 패턴)은 선택기를 한 곳에 유지합니다. 인터페이스가 변경되면 단일 파일로 업데이트합니다. AI가 직접 테스트가 아닌 POM 구조에서 테스트를 생성하도록 하세요. 이로 인해 유지 관리가 근본적으로 쉬워졌습니다.
약한 프롬프트 / 강한 프롬프트
약함: "로그인 페이지에 대한 Selenium 테스트를 작성합니다."
Strong: "Playwright(TypeScript)를 사용하여 로그인 흐름 테스트를 작성합니다. 선택기는 data-testid만 사용합니다. 페이지 제목이 아닌 사용자에게 표시되는 내용을 제어하는 데 사용하지 않습니다."
강력한 프롬프트; 이 도구는 언어, 선택기 정책, 대기 전략, 아키텍처(POM) 및 표현적 주장 기대치를 제공합니다.
테스트 데이터 및 환경 독립성
견고한 UI 테스트는 올바르게 작성될 뿐만 아니라 자체 테스트 데이터를 구축하고 정리합니다. AI 생성 테스트는 종종 환경에 이미 존재한다고 가정되는 사용자 또는 기록(“관리 사용자로 로그인”)에 연결됩니다. 이 가정은 테스트가 다른 환경에서 실행되거나 다른 테스트 후에 실행될 때 깨집니다(단위 9의 순서 종속성 문제). 사실 모든 테스트는 테스트 시작 시 필요한 데이터를 생성하고(또는 API 호출로 준비) 마지막에 정리합니다. AI에게 "이 테스트가 의존하는 모든 데이터를 테스트 내에서 설정하고 외부에서 이미 만들어진 데이터를 가정하지 마십시오"라고 명시적으로 지시합니다.
또 다른 중요한 점은 실제 사용자 데이터로 UI 테스트를 수행하지 않는 것입니다. 프로덕션 데이터베이스 복사본이 테스트 환경에서 사용되는 경우 이러한 기록은 실제 인물의 데이터입니다. 스크린샷과 테스트 기록을 통해 이 데이터가 드러날 수 있습니다. 합성(가상) 테스트 계정을 사용하세요. 이는 기밀성을 보호하고 테스트를 재현 가능하게 만듭니다. 실제 고객 계정으로 "주문 취소" 테스트를 수행하는 것은 윤리적, 운영적 실수입니다.
팁: UI 테스트를 가능한 한 적게 유지하세요. 실제 검증은 빠르고 안정적인 API와 단위 테스트에 맡기세요. UI 테스트는 비용이 많이 들고 불안정합니다. 진정한 엔드투엔드 사용자 흐름(테스트 피라미드 로직)을 검증하는 데에만 사용하세요.
차량 비교
특징
셀레늄
극작가
사이프러스
언어
자바, C#, 파이썬, JS
JS/TS, Python, .NET, 자바
자바스크립트/타입스크립트
자동 대기
아니요(손으로)
예(강함)
예
멀티 브라우저
넓은
크롬/파이어폭스/웹킷
크롬 우세
부서지기 쉬운 경향
높음(수동 대기)
낮음
낮음
학습의 용이성
중간
쉬운
쉬운
병렬 운전
그리드 필요
내장
거주자/유료
AI에게 코드를 요청할 때 해당 코드가 속한 차량을 명확하게 명시하십시오. 그렇지 않으면 혼란스럽고 작동하지 않는 코드가 생성될 수 있습니다.
복사 가능한 템플릿 4개
1) 견고한 UI 테스트 생성:
귀하의 역할: 수석 테스트 자동화 엔지니어. 다음 흐름에 대해 [도구 + 언어]를 사용하여 테스트를 작성하십시오. [흐름].규칙:- 데이터 테스트 ID만 선택합니다. XPath/CSS 클래스를 사용합니다. - 맹목적인 잠은 없습니다. 명시적/자동 대기를 사용하십시오. - 페이지 개체 모델을 적용합니다. - 각 주장이 실제 사용자 결과를 확인하게 하세요. 각 테스트 시작 부분에 어떤 승인 기준을 검증하고 있는지 설명하세요.
2) 취약성 제어:
취성에 대해 다음 UI 테스트를 검사하십시오. - 불안정한 선택기가 있습니까(긴
3) 페이지 개체로 변환:
다음 일반 테스트 코드를 페이지 개체 모델 구조로 변환합니다. 선택기와 작업을 페이지 클래스로 이동합니다. 테스트 파일이 시나리오 흐름만 읽도록 합니다. [도구/언어].코드: [코드 붙여넣기]
4) 의사 전이 증명:
이 UI 테스트가 실제로 유효성을 검사함을 증명하십시오. 이 테스트를 빨간색으로 바꾸려면 애플리케이션 코드에 어떤 단일 변경 사항을 적용해야 합니까? 테스트를 중단시키는 변경 사항을 찾을 수 없다면 테스트가 부적절한 것입니다. 누락된 어설션을 추가합니다.테스트: [테스트 붙여넣기]
세 개의 미니 케이스
사례 1 — 취약한 선택기에서 해방. 한 팀이 AI로 제작한 40개의 테스트 중 70%가 인터페이스 업데이트 후에 깨졌습니다. 그것들 중 어느 것도 실제 버그가 아니었고 모두 취약한 XPath 선택기였습니다. 팀은 "취약성 검사" 템플릿을 사용하여 테스트를 데이터 테스트 기반으로 변환했습니다. 다음 세 번의 인터페이스 업데이트를 통해 잘못된 중단 횟수가 0으로 떨어졌습니다. 유지 관리 시간이 주당 6시간에서 30분으로 단축되었습니다.
사례 2 — 가짜 통과 UI 테스트. AI는 "장바구니에 추가" 테스트를 진행했습니다. 테스트는 녹색이었습니다. "가짜 통과 증명" 템플릿이 실행되었을 때 테스트에서는 버튼 클릭과 페이지 제목만 확인하고 장바구니 카운터가 증가했는지 여부는 확인하지 않는 것으로 나타났습니다. 카트 로직이 완전히 깨졌더라도 테스트는 통과되었습니다. 실제 주장이 추가되었습니다(장바구니 배지가 "1"임).
사례 3 — 블라인드 대기 트랩. AI가 생성한 셀레늄 테스트에서는 각 단계마다 수면(2)이 있었습니다. 60개 테스트에는 14분이 걸렸지만 여전히 가끔 실패했습니다. 열기 대기(요소를 클릭할 수 있을 때까지 대기)로 전환한 후 시간이 5분으로 단축되고 취약성이 사라졌습니다. 맹목적인 기다림은 느리고 신뢰할 수 없었습니다.
일반적인 실수
- 취약한 선택자에 동의합니다. AI가 생성한 긴 XPath를 그대로 사용합니다. 첫 번째 인터페이스 변경 시 테스트가 충돌합니다.
- 눈먼 채로 '수면'. 고정된 대기 시간으로 타이밍을 "해결"합니다. 느리고 우유부단합니다.
- 사소한 주장. 페이지가 로드되었는지 확인하세요. 실제 사용자 결과를 확인하지 않습니다(fake-pass).
- POM 없이 성장하세요. 각 테스트에 선택기를 배포합니다. 인터페이스가 변경되면 수십 개의 파일을 수동으로 업데이트합니다.
- 도구를 지정하지 않습니다. AI에게 원하는 도구/언어를 알려주지 않습니다. 지저분하고 작동하지 않는 코드가 발생합니다.
- 생성된 코드를 실행하고 통과하면 신뢰됩니다. 코드를 깨뜨려 테스트하지 않습니다.
요약하면
UI 테스트 자동화는 프로그램으로 실제 브라우저를 구동하여 사용자 행동을 검증합니다. AI는 이 코드를 빠르게 생성하지만 취약한 테스트(잘못된 선택기, 블라인드 대기)와 가짜 통과 테스트(불완전/사소한 어설션)라는 두 가지 큰 함정이 있습니다. 견고한 UI 테스트의 세 가지 기본 요소는 커밋 선택기(data-testid), 명시적 대기 및 실제 사용자 결과를 확인하는 어설션입니다. 페이지 개체 모델에서 테스트를 생성하면 유지 관리가 근본적으로 단순화됩니다. 생성된 각 테스트를 "어떤 변경 사항이 이를 깨뜨릴까요?"라는 질문으로 테스트합니다.
응용과제
자신의 프로젝트에서 사용자 흐름을 선택하세요(예: 로그인 또는 검색). AI가 "강력한 UI 테스트 생성" 템플릿을 사용하여 테스트를 작성하게 하세요. 그런 다음 (1) 선택기를 확인하고 수정한 다음 "취약성 검사"를 기다리고, (2) 각 테스트가 "의사 통과 증명"으로 실제로 유효성을 검사하는지 증명하고, (3) 코드를 깨고 테스트가 빨간색으로 바뀌는 것을 관찰합니다. 생성되고 수정된 테스트 수와 발견한 취약점 및 의사 통과 수를 보고합니다.
체크리스트
- [ ] AI에 도구, 언어, 선택기 정책 및 아키텍처(POM)를 명확하게 제공했습니다.
- [ ] 선택기가 데이터 테스트 ID인지 확인했습니다.
- [ ] 맹목적인 절전 모드 대신 명시적/자동 대기를 사용했는지 확인했습니다.
- [ ] 각 주장이 실제 사용자 결과를 확인하는지 확인했습니다.
- [ ] 코드를 깨뜨려 각 테스트를 테스트했습니다. 빨간색으로 변하는 걸 봤어요.
- [ ] 페이지 개체 모델 구조에서 테스트를 수집했습니다.