이득:
- 테스트 피라미드에 맞춰 인공지능으로 단위, 통합, UI 테스트를 제작하고 한계 및 오류 상황은 물론 행복한 시나리오까지 커버하는 능력
- 생성된 각 테스트가 실제로 동작을 검증하는지 확인하여 비어 있거나 쓸모 없는 테스트와 부풀어 오른 적용 범위를 제거하는 기능
- 테스트에서 버그를 포착하고 코드가 수행해야 하는 작업을 AI에 알려줌으로써 버그 수정을 방지합니다.
코드 작성은 작업의 절반입니다. 코드가 올바르게 작동한다는 것을 증명하는 것이 나머지 절반입니다. 모바일 앱은 수백 가지의 다양한 장치, 화면 크기, 운영 체제 버전 및 사용자 행동을 접합니다. 이 모든 것을 수동으로 테스트하는 것은 불가능합니다. 이것이 바로 자동화된 테스트(코드 테스트 코드 - 사람의 클릭 없이 실행되는 테스트)가 모바일 품질의 중추인 이유입니다. 테스트 작성은 AI가 좋아하는 일종의 패턴 작업, 즉 특정 입력에 대한 특정 동작을 검증하는 것이기 때문에 AI는 테스트 작성에 매우 효율적입니다. 이번 단원에서는 AI를 사용하여 단위 테스트, 인터페이스 테스트 및 자동화를 가속화하는 방법을 배우면서 인간의 눈을 통해 테스트 품질을 보장합니다.
테스트 피라미드: 무엇을 테스트하고 얼마나 테스트할 것인가
건전한 테스트 전략은 피라미드와 유사합니다. 기본에는 다수의 단위 테스트(단일 기능이나 클래스를 개별적으로 테스트하는 빠른 테스트)가 포함되어 있습니다. 그들은 빠르고 저렴합니다. 중간에는 통합 테스트(여러 부분이 어떻게 함께 작동하는지 테스트)가 적습니다. 상단에는 최소한의 UI/종단 간 테스트(사용자가 하는 것처럼 화면을 클릭하여 테스트 수행)가 있습니다. 현실적이지만 느리고 취약합니다. AI는 모든 계층에서 도움을 주지만 가장 큰 가치는 비즈니스 로직의 단위 테스트를 신속하게 생성하는 기본에 있습니다.
테스트 유형
범위
속도
AI 효율성
단위 테스트
단일 함수/클래스
매우 빠르다
매우 높다
통합
중간층
중간
높다
UI / 엔드투엔드
모든 화면 스트림
천천히
중간(깨지기 쉬움)
팁: AI에게 "이 함수에 대한 테스트를 생성"하라고 지시할 때 빈 입력, null, 음수, 매우 큰 값, 네트워크 오류와 같은 극단적인 경우를 명시적으로 요청하십시오. AI는 쉽게 행복한 길을 만들어냅니다. 실제 실수는 테두리에 숨어 있고 원하지 않으면 튀어나옵니다.
AI로 테스트를 작성하는 단계
- 테스트할 동작을 정의합니다. "이 함수는 이 출력을 이 입력에 제공해야 합니다."
- 프레임워크를 지정합니다. Android의 JUnit + MockK, iOS의 XCTest, UI의 경우 Espresso(Android) 또는 XCUITest(iOS).
- 한계 상태를 요청하세요. 행복한 시나리오 + 오류 + 중단점.
- 모의 개체를 관리합니다. 네트워크 및 데이터베이스와 같은 외부 종속성은 테스트를 위해 에뮬레이트됩니다(모의 - 실제 서비스 대신 제어되는 모의).
- 테스트를 실행하고 확인하세요. 테스트가 통과되었나요? 정말 의미 있는 것이 확인되었나요?
다섯 번째 단계가 중요합니다. AI는 때때로 "항상 통과"하는 쓸모없는 테스트를 생성합니다. 예를 들어 아무것도 확인하지 않거나 자체적으로 가짜 데이터를 확인하는 테스트입니다. 합격한 시험과 가치 있는 시험은 다릅니다.
주의: AI가 생산할 수 있다고 해서 테스트가 정확하다는 의미는 아닙니다. 때때로 AI는 코드의 현재(아마도 잘못된) 동작을 "올바른" 것으로 받아들이고 그에 따라 테스트를 작성합니다. 이러한 테스트는 버그를 잡는 것이 아니라 버그를 수정합니다. 테스트에서 기대하는 바를 결정합니다. 코드가 무엇을 하는지가 아니라 AI가 무엇을 해야 하는지 알려주세요.
테스트 커버리지 측정 및 오류
테스트 적용 범위(테스트에서 실행되는 코드의 비율)는 유용하지만 오해의 소지가 있는 지표입니다. 90% 적용 범위는 코드의 90%가 실행되었음을 나타냅니다. 그러나 해당 라인이 올바르게 작동하는지 확인되지 않았습니다. 라인을 실행하고 결과를 확인하지 않는 테스트는 범위를 확장하지만 보안을 제공하지 않습니다. 목표는 높은 숫자가 아니라 의미 있는 검증입니다. AI를 사용하면 신속하게 확장할 수 있지만 각 테스트가 실제로 동작을 테스트하는지 확인하세요.
세 개의 미니 케이스
사례 1 - 국경 상황이 포착되었습니다. 은행 애플리케이션에서 자금 이체 기능에 대한 테스트를 AI에 요청했으며, 구체적으로 '마이너스 금액' 및 '잔고 이상' 시나리오가 추가되었습니다. 테스트 결과 이체가 마이너스 금액으로 차단되지 않은 것으로 나타났습니다. 이는 프로덕션 환경에서 주요 보안 취약점이 됩니다. 한 줄 컨트롤을 추가하여 닫힙니다. 교훈: 경계 테스트는 가장 가치 있는 테스트입니다.
사례 2 - 가짜 테스트. 한 팀은 AI가 생성한 40개의 단위 테스트를 통해 적용 범위를 85%로 늘려 안도했습니다. 검사 중에 대부분의 테스트에서는 실제로 출력을 확인하지 않고 함수를 호출하고 AssertTrue(true)를 작성했다는 사실이 확인되었습니다. 보장 범위는 높았지만 보호 수준은 0이었습니다. 테스트는 정밀 검사를 거쳐 실제 검증을 통해 다시 작성되었습니다. 교훈: 보장 번호는 거짓말을 할 수 있습니다.
사례 3 — UI 테스트가 가속화되었습니다. 전자 상거래 팀은 AI를 사용하여 장바구니에 추가 흐름의 XCUITest 스크립트를 20분 만에 작성했습니다. 손으로 쓴다면 반나절은 걸릴 것이다. AI가 추측한 화면 요소 식별자 팀에서는 이를 실제 코드와 일치시켜 수정했습니다. 초안 속도는 실제이지만 식별자 확인은 사람의 작업입니다.
약한 프롬프트 / 강한 프롬프트
약한 프롬프트: "이 함수에 대한 테스트를 작성하세요."
강력한 프롬프트: "JUnit5 + MockK를 사용하여 이 Kotlin 함수에 대한 단위 테스트를 생성합니다. 함수: 송금(금액, 소스, 목표). 테스트할 동작(코드가 수행해야 하는 작업):- 유효한 송금이 성공해야 합니다. - 음수 또는 0 금액이 거부되어야 합니다. - 잔액보다 큰 금액이 거부되어야 합니다. - 네트워크 오류는 적절한 예외를 발생시켜야 합니다. 각 테스트는 한 가지만 확인해야 하며, 해당 이름은 설명적이어야 하며, 외부 서비스를 조롱해야 합니다. 빈 어설션을 작성하지 마십시오."
복사 가능한 템플릿
단위 테스트 템플릿: "[언어]에 대해 이 함수에 대한 [JUnit/XCTest] 단위 테스트를 생성합니다. 예상 동작: [해야 할 일]. 포함: 행복한 시나리오, null 입력, 중단점, 오류 사례. 각 테스트에서 단일 동작을 확인하도록 하고 의미 있는 어설션을 사용합니다. 모의. [코드]"
UI 테스트 템플릿: "[Espresso/XCUITest]를 사용하여 다음 흐름의 UI 테스트를 작성합니다. [사용자 흐름 단계별]. 접근성 ID가 있는 화면 요소를 선택하고 텍스트 대신 ID를 사용합니다. 대기 전략을 추가합니다. 요소 ID를 실제 코드와 일치시키도록 알림."
테스트 감사 템플릿:"이러한 테스트를 조사하십시오:1) 실제로 출력/동작을 확인합니까, 아니면 null입니까?2) 제한 사례를 다루나요?3) 코드의 버그를 수정합니까, 아니면 올바른 동작을 기대합니까?약한 테스트에 플래그를 지정하고 강화합니다. [테스트]"
적용 범위 최적화 템플릿: "이 클래스의 테스트되지 않은 부분을 식별하고 의미 있는 테스트를 제안합니다. 적용 범위 수뿐만 아니라 실제 위험이 있는 경로의 우선 순위를 지정합니다. [코드]"
일반적인 실수
- 행복한 시나리오를 테스트하는 것뿐입니다. 오류는 한계 상태에 저장됩니다. 공개적으로 물어보세요.
- 비어 있거나 쓸모없는 테스트를 수락합니다. AssertTrue(true) 유형의 테스트는 범위를 확장하고 보호 기능을 제공하지 않습니다.
- AI가 코드가 수행하는 작업을 확인하도록 합니다. 테스트는 코드가 무엇을 해야 하는지 예상해야 합니다. 그렇지 않으면 버그가 수정됩니다.
- 목적에 맞게 범위 번호를 착각합니다. 90% 적용 범위는 90% 정확도를 의미하지 않습니다.
- UI 테스트에서 텍스트에 연결합니다. 텍스트가 변경되면 테스트가 중단됩니다. 안정적인 식별자(id)를 사용하세요.
- 모의 객체를 잘못 설정했습니다. 실제 서비스를 호출하는 "단위 테스트"는 느리고 취약합니다.
요약하면
테스트는 모바일 품질의 중추이며 AI는 이 영역, 특히 단위 테스트에서 매우 효율적입니다. 테스트 피라미드를 따르십시오: 많은 단위, 중간 규모의 통합, 작은 UI 테스트. AI에게 행복한 시나리오는 물론 제한된 사례와 오류 경로를 명시적으로 요청합니다. 생성된 각 테스트가 실제로 동작을 검증하는지 확인하세요. 빈 테스트와 부풀려진 적용 범위는 오해의 소지가 있습니다. 가장 중요한 것은 코드가 무엇을 하는지가 아니라 무엇을 해야 하는지 AI에게 알려 테스트가 버그를 수정하는 것이 아니라 잡아내는 것입니다.
응용과제
비즈니스 논리 기능(예: 할인 계산 또는 양식 유효성 검사)에 대한 "단위 테스트 템플릿"을 사용하여 AI에서 테스트를 요청하고 제한 사례(null, 음수, 너무 큼)를 명시적으로 지정합니다. 생성된 테스트를 실행한 다음 "테스트 감사 템플릿"을 사용하여 동일한 테스트를 감사합니다. 최소한 하나의 약한 테스트를 찾아 강화하고 테스트에서 함수의 실제 오류를 포착하는지 여부를 테스트합니다(작은 버그를 추가하여).
체크리스트
- [ ] 테스트 피라미드(우선순위 단위)에 적합한 레이어를 선택했습니다.
- [ ] 행복한 시나리오 외에 한계와 오류 사례를 원했습니다.
- [ ] 각 테스트에 의미 있는 주장이 포함되어 있음을 확인했습니다.
- [ ] AI에게 코드가 무엇을 하는지가 아니라 코드가 무엇을 해야 하는지 알려줬습니다.
- [ ] 보장 횟수가 아닌 실제 위험 경로에 중점을 두었습니다.
- [ ] UI 테스트에서 안정적인 식별자를 사용했지만 텍스트에 바인딩하지 않았습니다.