자동화된 테스트 스크립트를 작성하는 것은 쉽습니다. 6개월 후에도 여전히 제 역할을 하는 스크립트를 작성하는 것이 어려운 부분입니다. 많은 테스트 스크립트가 작성되어 한 번은 성공적으로 실행되지만, 이내 조용히 퇴색하여 관련 없는 변경사항에 깨지고, 의미 있는 것을 검증하지 못하며, 팀이 실패한 빌드를 무시하도록 훈련시킵니다. 좋은 테스트 스크립트는 정밀하고, 독립적이며, 내구성이 뛰어납니다.
이 가이드는 자동화된 테스트 스크립트가 무엇인지, 신뢰할 수 있는 스크립트를 만드는 구조, API 테스트 스크립트를 작성하는 두 가지 방법, 그리고 Apidog에서 단계별로 스크립트를 구축하는 방법을 다룹니다.
자동화된 테스트 스크립트란 무엇인가
자동화된 테스트 스크립트는 사람이 직접 단계를 실행하지 않고도 소프트웨어의 일부를 실행하고 결과를 확인하는 정의되고 반복 가능한 지침 집합입니다. 스크립트는 입력을 보내고, 작업을 수행하며, 결과를 예상과 비교합니다. 일치하면 통과하고, 그렇지 않으면 실패하며 이유를 보고합니다.
테스트 스크립트는 테스트 케이스의 실행 가능한 형태입니다. 테스트 케이스는 의도, 입력, 작업 및 예상 결과를 사람이 이해할 수 있는 용어로 설명합니다. 스크립트는 그 의도를 기계가 모든 커밋에서 실행할 수 있는 것으로 바꿉니다. 하나의 테스트 케이스가 하나의 스크립트가 될 수 있으며, 테스트 시나리오는 일반적으로 여러 스크립트가 연결된 형태로 구성됩니다.
자동화된 테스트 스크립트의 전체 가치는 매번 동일한 방식으로 실행된다는 점입니다. 이는 스크립트가 결정론적으로 작성된 경우에만 유효합니다. 다른 스크립트가 실행된 순서나 이전 실행에서 남겨진 데이터에 의존하는 스크립트는 신뢰할 수 있는 자동화가 아니며, 불안정한 책임이 됩니다.
신뢰할 수 있는 테스트 스크립트의 구조
거의 모든 잘 작성된 테스트 스크립트는 어떤 언어나 도구를 사용하든 동일한 4단계 형태를 따릅니다. 이는 종종 Arrange-Act-Assert라고 불리며, 클린업이 추가됩니다.
준비(Arrange). 테스트에 필요한 모든 것을 설정합니다: 입력 데이터, 인증, 모든 전제 조건. 스크립트는 상태가 존재한다고 가정하기보다는 자체 상태를 생성해야 합니다. 테스트에 사용자 계정이 필요한 경우, 데이터베이스에 있는 무엇이든 사용하는 대신 사용자 계정을 생성하거나 알려진 픽스처를 사용합니다.
실행(Act). 테스트 대상인 단일 작업을 수행합니다. 좋은 스크립트는 하나의 동작을 테스트합니다. 요청을 보내거나, 함수를 호출하거나, 이벤트를 트리거하는 것이 실행 단계이며, 스크립트당 정확히 하나의 실행 단계가 있어야 합니다.
검증(Assert). 결과를 예상과 비교합니다. 이 부분은 팀들이 투자를 덜 하는 경향이 있습니다. "오류가 발생하지 않았다"거나 "상태 코드가 200이었다"고만 검증하는 스크립트는 거의 아무것도 테스트하지 않습니다. 강력한 검증은 실제 값, 즉 응답 본문, 스키마, 부작용, 응답 시간을 확인합니다.
정리(Cleanup). 스크립트가 생성한 것을 되돌려 놓아 깨끗한 상태에서 다시 실행할 수 있도록 합니다. 테스트 데이터를 남겨두는 스크립트는 결국 자신 또는 다른 스크립트와 충돌하게 됩니다.
견고한 스크립트와 취약한 스크립트를 구분하는 세 가지 습관이 있습니다. 스크립트당 한 가지를 테스트하여 실패의 원인을 명확하게 합니다. 스크립트를 독립적으로 유지하여 어떤 순서로든 실행할 수 있게 합니다. 그리고 생성된 ID나 타임스탬프와 같이 휘발성 데이터가 아닌 안정적인 값에 대해 검증하여, 스크립트가 실제 이유 없이 실패하는 일을 방지합니다.
API 테스트 스크립트를 작성하는 두 가지 방법
특히 API 테스트의 경우, 두 가지 일반적인 접근 방식이 있으며, 이는 다양한 팀에 적합합니다.
코드 우선 접근 방식은 범용 언어로 테스트 스크립트를 작성합니다. Python에서는 pytest와 같은 프레임워크와 HTTP 라이브러리를 의미하며, JavaScript에서는 테스트 러너와 fetch를 의미합니다. 요청, 검증 및 설정을 실제 코드로 작성하며, 스크립트는 애플리케이션과 함께 저장소에 존재합니다.
이 접근 방식은 완전한 프로그래밍 제어를 제공합니다. 복잡한 로직, 사용자 정의 픽스처 및 특이한 검증은 모두 코드일 뿐입니다. 단점은 모든 스크립트가 작성하고 유지 관리해야 하는 코드이며, 팀에 언어 기술이 필요하고, 많은 상용구 코드, 인증 처리, 요청 구성, 응답 파싱 등이 스크립트 전체에 걸쳐 재작성된다는 것입니다. 이는 코드로 테스트 버전을 관리하고 해당 유지 관리에 익숙한 엔지니어링 팀에 적합합니다.
시각적 접근 방식은 전용 API 테스트 도구에서 테스트 스크립트를 구축합니다. 일반적인 경우에 스크립트 코드를 작성하거나 유지 관리할 필요 없이, 클릭만으로 요청을 정의하고, 검증을 추가하며, 요청을 시나리오로 연결합니다. Apidog와 같은 도구가 이 방식을 따릅니다.
이 접근 방식은 상용구 코드를 제거하고, 스크립트를 해당 언어를 아는 사람뿐만 아니라 팀의 모든 사람이 읽을 수 있도록 만듭니다. 시각적 빌더가 표현할 수 없는 드문 로직의 경우 여전히 사용자 정의 코드를 작성해야 합니다. 이는 혼합 팀, QA 주도 테스트, 그리고 스크립팅 프로젝트 없이도 테스트 스위트를 빠르게 실행하고 싶은 모든 사람에게 적합합니다.
어떤 것도 틀리지 않습니다. 결정적인 질문은 누가 스크립트를 유지 관리하는지, 그리고 스크립트가 애플리케이션 저장소에 있어야 하는지 여부입니다. 대부분의 API 테스트에서는 시각적 접근 방식이 유지 관리할 것이 적으면서도 안정적인 스위트를 더 빠르게 실행할 수 있게 합니다.
Apidog에서 자동화된 API 테스트 스크립트 작성하기
다음은 내구성 있는 API 테스트 스크립트를 시각적으로 구축하기 위한 전체 흐름입니다.
1단계: 요청 정의. OpenAPI 파일에서 Apidog로 엔드포인트를 가져오거나 직접 정의합니다. 이것이 준비(Arrange) 단계이며, 요청은 메서드, 경로, 헤더 및 본문을 포함합니다.
2단계: 테스트 데이터 추가. 테스트하려는 케이스에 대한 입력 페이로드를 설정합니다. 하나의 스크립트로 많은 입력을 다루려면, CSV 또는 JSON 파일을 첨부하여 스크립트가 행당 한 번씩 실행되도록 합니다. 데이터 기반 테스트는 거의 동일한 수십 개의 스크립트를 하나로 대체합니다.
3단계: 검증 작성. 이것이 핵심입니다. 시각적 검사를 추가합니다: 상태가 예상 코드와 일치하는지, 주요 본문 필드가 존재하고 올바른 값을 가지는지, 응답이 스키마를 준수하는지, 응답 시간이 예산 범위 내에 있는지 등입니다. 부정적인 케이스의 경우, 단순히 실패 코드뿐만 아니라 오류 형태를 검증합니다. 휘발성 데이터를 검증하려는 충동을 억제하십시오.
4단계: 요청을 시나리오로 연결. 실제 워크플로우는 여러 호출에 걸쳐 있습니다. 로그인하고, 리소스를 생성하고, 다시 읽어들이고, 삭제하는 시나리오를 구축하여 한 단계에서 다음 단계로 값을 전달합니다. 각 단계는 스크립트이며, 이들이 함께 완전한 흐름을 테스트합니다.
5단계: 필요할 때만 사용자 정의 스크립트 로직 추가. 시각적 검증으로는 표현할 수 없는 검사, 조건부 로직, 계산된 값, 교차 요청 비교를 위해 JavaScript 사전 또는 사후 처리기를 추가합니다. 이것을 최소화하십시오. 대부분의 스크립트에는 전혀 필요하지 않습니다.
6단계: 실행 및 보고서 읽기. 시나리오를 실행합니다. Apidog는 모든 스크립트를 실행하고, 모든 검증을 평가하며, 실패한 정확한 검사를 예상 값과 실제 값을 나란히 보여주며 보고합니다.
7단계: 실행 자동화. 모든 커밋에서 실행되도록 시나리오를 CI/CD에 연결합니다. 누군가 기억할 때만 실행되는 테스트 스크립트는 진정한 자동화가 아닙니다. 첫 번째 시나리오를 구축하려면 Apidog를 다운로드하십시오.
테스트 스크립트 건강하게 유지하기
테스트 스위트는 살아있는 것입니다. 릴리스 시에는 완벽했던 스크립트도 API가 변경됨에 따라 구식이 됩니다. 다음 세 가지 관행이 스위트를 신뢰할 수 있게 유지합니다.
API와 함께 스크립트를 업데이트하고 나중에 하지 않습니다. 엔드포인트의 계약이 변경되면 동일한 커밋에서 스크립트도 변경됩니다. 오래된 스키마를 검증하는 스크립트는 잘못된 이유로 실패하며 다른 모든 스크립트에 대한 신뢰를 떨어뜨립니다.
불안정한 스크립트는 실제 버그로 취급합니다. 대부분의 경우 통과하는 스크립트는 스크립트가 없는 것보다 나쁩니다. 왜냐하면 팀에게 빨간색이 깨졌다는 의미가 아니라고 가르치기 때문입니다. 원인(대개 공유 상태 또는 타이밍 가정)을 찾아 수정하십시오.
운영 코드처럼 스크립트를 검토합니다. 약한 검증, 200만 확인하는 스크립트는 거의 아무것도 테스트하지 않으면서도 녹색으로 보이고 안전하다고 느껴집니다. 두 번째 독자가 이를 알아차립니다.
자주 묻는 질문
테스트 케이스와 테스트 스크립트의 차이점은 무엇입니까? 테스트 케이스는 사람이 이해할 수 있는 용어로 의도, 입력, 작업, 예상 결과를 설명합니다. 테스트 스크립트는 기계가 실행하는 실행 가능한 버전입니다. 케이스는 계획이고, 스크립트는 구현입니다.
자동화된 테스트 스크립트를 작성하려면 코딩하는 방법을 알아야 합니까? 시각적 도구를 사용한 API 테스트의 경우에는 필요하지 않습니다. Apidog에서는 클릭하여 요청, 검증 및 시나리오를 구축하며, 특이한 로직에 대해서만 코드를 작성합니다. 코드 우선 프레임워크는 언어 기술을 요구합니다.
테스트 스크립트가 계속 깨지는 이유는 무엇입니까? 일반적인 원인은 휘발성 데이터에 대한 검증, 스크립트가 서로의 상태에 의존하는 것, 그리고 API 변경 시 스크립트를 업데이트하지 않는 것입니다. 테스트 데이터를 격리하고, 스크립트를 독립적으로 유지하며, 계약과 함께 업데이트하십시오.
하나의 테스트 스크립트에 몇 개의 검증이 있어야 합니까? 결과를 진정으로 검증하기에 충분한 수여야 합니다. 일반적으로 상태, 주요 본문 필드, 스키마 및 타이밍입니다. 단일 상태 코드 검증은 너무 적습니다. 응답이 잘못되었는데도 통과할 수 있습니다.
테스트 스크립트는 애플리케이션 저장소에 있어야 합니까? 코드 우선 접근 방식에서는 일반적으로 예, 테스트가 코드와 함께 버전 관리되기 때문입니다. 시각적 도구를 사용하면 스크립트는 테스트 플랫폼에 있으며 API 정의와 동기화됩니다. 둘 다 작동하며, 선택보다 일관성이 더 중요합니다.
API가 구축되기 전에 테스트 스크립트를 어떻게 작성합니까? API 설계를 기반으로 작성합니다. OpenAPI 사양이 있다면 이를 통해 요청과 검증을 정의한 다음, 실제 엔드포인트가 존재할 때까지 모의 서버를 대상으로 실행할 수 있습니다. 구현이 완료되는 순간 스크립트가 준비됩니다.
테스트 스크립트와 테스트 스위트의 차이점은 무엇입니까? 테스트 스크립트는 하나의 검사를 실행합니다. 테스트 스위트는 함께 실행되도록 그룹화된 스크립트 모음이며, 종종 전체 API 또는 기능을 다룹니다. 스위트는 늘어나는 스크립트 세트를 체계적으로 유지하고 단일 명령으로 광범위한 커버리지를 실행할 수 있게 합니다.
자동화된 테스트 스크립트는 얼마나 길어야 합니까? 준비, 실행, 검증, 정리의 네 부분을 수행하면서도 최대한 짧아야 합니다. 스크립트가 길다면, 일반적으로 한 가지 이상을 테스트하고 있으므로 분할해야 합니다. 스크립트당 하나의 동작은 실패 진단을 쉽게 유지합니다.