팀들은 종종 테스트 구성 방식에 대한 질문을 해결한 것처럼 "자동화를 사용한다"고 말합니다. 하지만 그렇지 않습니다. 두 스위트(suite)가 모두 자동화되어 있더라도 완전히 다른 방식으로 구성될 수 있으며, 유지보수 비용도 완전히 다를 수 있습니다. 구조는 프레임워크이며, 선택하는 프레임워크 유형에 따라 테스트가 얼마나 빠르게 증가하는지, 비코딩 사용자가 얼마나 쉽게 기여할 수 있는지, 그리고 작은 UI 변경이 코드 전체에 얼마나 큰 영향을 미치는지 결정됩니다.
이 글은 선형, 모듈형, 데이터 기반, 키워드 기반, 하이브리드, 행동 기반의 여섯 가지 고전적인 자동화 테스트 프레임워크 유형을 다룹니다. 각 유형이 무엇인지, 장점은 무엇인지, 단점은 무엇인지를 설명하여, 마지막 엔지니어가 설정한 것을 그대로 물려받는 대신 팀에 맞는 구조를 선택할 수 있도록 돕습니다. 이 개념들은 UI, API, 단위 테스트 모두에 동일하게 적용됩니다.
자동화 테스트 프레임워크란 무엇인가요?
자동화 테스트 프레임워크는 자동화된 테스트가 작성, 구성 및 실행되는 방식을 정의하는 일련의 지침, 규칙 및 재사용 가능한 구성 요소입니다. 이것은 설치하는 도구가 아닙니다. 테스트가 존재하는 아키텍처입니다.
프레임워크는 누군가 테스트를 작성하기 전에 구조적 질문에 답합니다. 테스트 데이터는 어디에 저장되나요? 재사용 가능한 단계는 어떻게 공유되나요? 코딩 사용자만 기여할 수 있나요, 아니면 분석가도 기여할 수 있나요? 결과는 어떻게 보고되나요? 프레임워크 유형마다 이러한 질문에 다르게 답하며, 이것이 유형을 구분하는 요소입니다. 이 광범위한 개념이 처음이라면, 아래 유형 분류에 앞서 자동화된 테스트란 무엇인가에 대한 개요가 유용한 배경 지식을 제공할 것입니다.
이것이 중요한 이유는 유지보수 때문입니다. 첫 백 개의 자동화 테스트를 작성하는 것은 쉽습니다. 애플리케이션이 매주 변경되는 동안 천 개의 테스트를 유지보수하는 것은 어렵고, 프레임워크 유형은 그 유지보수 비용에 가장 큰 영향을 미치는 단일 요소입니다.
구체적인 예를 들어봅시다. 로그인 화면의 필드 레이블이 변경되었습니다. 한 스위트에서는 이 변경으로 인해 두 개의 테스트가 실패하고 수정하는 데 10분이 걸립니다. 정확히 동일한 애플리케이션을 테스트하는 다른 스위트에서는 200개의 테스트가 실패하고 수정하는 데 이틀이 걸립니다. 애플리케이션은 동일합니다. 프레임워크 구조만 다릅니다. 이러한 차이점 때문에 코드를 작성한 후가 아니라 작성하기 전에 프레임워크 유형에 대해 고민할 가치가 있는 것입니다.
여섯 가지 프레임워크 유형
1. 선형 (기록 및 재생)
선형 프레임워크는 사용자의 동작을 기록하고 스크립트처럼 재생합니다. 각 테스트는 공유 함수가 없고 데이터와 로직이 분리되지 않은 평면적인 단계들의 시퀀스입니다. 도구가 스크립트를 생성해주므로 진입 장벽이 거의 없습니다.
작은 프로젝트, 빠른 데모 또는 일회성 스모크 테스트에는 속도가 매력적입니다. 비용은 빠르게 나타납니다. 아무것도 재사용되지 않기 때문에 동일한 로그인 단계가 모든 테스트에 복사-붙여넣기됩니다. 로그인 페이지가 변경되면 50개의 스크립트를 수정해야 합니다. 선형 프레임워크는 확장되지 않으며, 대부분의 팀은 몇 주 내에 이를 사용하지 않게 됩니다.
2. 모듈형
모듈형 프레임워크는 애플리케이션을 작고 독립적인 모듈로 나누고, 각 모듈에 대해 재사용 가능한 함수를 작성합니다. 그런 다음 테스트는 이러한 함수의 조합이 됩니다: 로그인, 검색, 장바구니에 추가, 결제. 로그인 화면이 변경되면 하나의 함수만 수정하면 모든 테스트가 혜택을 받습니다.
이것은 진정으로 확장 가능한 첫 번째 구조입니다. 단점은 초기 설계입니다. 테스트가 빠르게 진행되기 전에 누군가가 모듈 경계를 결정하고 추상화 계층을 구축해야 합니다. 대부분의 엔지니어링 팀에게 모듈형은 합리적인 기본값이며, 자동화된 테스트 스크립트 작성 가이드에 설명된 규율과 잘 어울립니다.
3. 데이터 기반
데이터 기반 프레임워크는 테스트 로직을 테스트 데이터와 분리합니다. 하나의 테스트 함수는 CSV 파일, JSON 파일, 스프레드시트 또는 데이터베이스에 저장된 입력 행을 대상으로 여러 번 실행됩니다. 커버리지는 코드를 작성하는 것이 아니라 행을 추가함으로써 증가합니다.
이 유형은 동일한 워크플로우를 수십 가지 입력 조합(유효한 로그인, 유효하지 않은 로그인, 경계값, 로케일 변형 등)에 대해 검증해야 할 때 이상적입니다. 특히 API의 경우, CSV 및 JSON을 이용한 데이터 기반 API 테스트 접근 방식은 하나의 요청을 수백 가지 케이스로 변환합니다. 단점은 테스트 로직 자체가 고정된다는 것입니다. 데이터 기반 구조는 입력값을 확장하지만, 동작을 확장하지는 않습니다.
4. 키워드 기반
키워드 기반 프레임워크는 Login, SearchProduct, VerifyTotal과 같은 이름의 키워드로 동작을 추상화합니다. 테스트는 키워드와 인수로 구성된 표 형식으로 작성되며, 종종 스프레드시트에 작성되어 비프로그래머도 코드를 건드리지 않고 테스트를 구성할 수 있습니다.
강점은 접근성입니다. QA 분석가와 비즈니스 담당자가 테스트를 직접 작성하고 읽을 수 있습니다. 비용은 키워드 라이브러리입니다. 엔지니어는 모든 키워드 뒤에 있는 구현을 구축하고 유지보수해야 하며, 잘못 설계된 키워드 세트는 그 자체로 유지보수 부담이 됩니다. 키워드 기반 구조는 테스트 작성과 테스트 구현이 다른 역할로 분리된 팀에 적합합니다.
5. 하이브리드
하이브리드 프레임워크는 위에 언급된 두 개 이상의 유형을 결합한 것으로, 가장 흔하게는 모듈형 재사용과 데이터 기반 입력, 그리고 키워드 추상화가 결합됩니다. 이는 별개의 유형이라기보다는 실제 프로젝트가 다른 곳에서 다른 구조를 필요로 한다는 실용적인 인식입니다.
대부분의 성숙한 테스트 스위트는 수천 개의 테스트에 도달할 때쯤이면 하이브리드 형태가 됩니다. 위험은 비일관성입니다. 조합이 의도적으로 설계되지 않으면 모든 유형의 유지보수 비용을 지불하면서도 명확성은 얻지 못하게 됩니다. 하이브리드 프레임워크는 조합이 의도적이고 문서화되었을 때 작동합니다.
6. 행동 기반 (BDD)
행동 기반 프레임워크는 Given-When-Then 패턴을 사용하여 거의 자연어에 가까운 언어로 테스트를 표현하며, 일반적으로 Gherkin으로 작성되고 Cucumber와 같은 도구에 의해 실행됩니다. 시나리오는 문장처럼 읽힙니다: 등록된 사용자가 유효한 자격 증명을 제출하면, 대시보드에 도달한다.
BDD의 가치는 공유된 이해에 있습니다. 제품, QA, 엔지니어링이 동일한 사양을 읽음으로써 요구된 것과 구축된 것 사이의 격차를 줄입니다. 비용은 두 계층에 있습니다: 읽기 쉬운 Gherkin과 이를 구현하는 스텝 정의. 제품 담당자가 실제로 시나리오를 읽지 않는다면, BDD의 혜택을 받지 못하면서 비용만 지불하는 셈입니다. BDD API 테스트를 위한 Gherkin 가이드는 API에 적용된 패턴을 보여줍니다.
프레임워크 유형 비교
| 프레임워크 유형 | 재사용 | 비코딩 사용자 작성 가능 | 설정 비용 | 확장성 |
|---|---|---|---|---|
| 선형 | 없음 | 예, 기록을 통해 | 매우 낮음 | 부실함 |
| 모듈형 | 높음 | 아니요 | 중간 | 양호함 |
| 데이터 기반 | 중간 | 부분적으로 | 중간 | 입력에 대해 양호함 |
| 키워드 기반 | 높음 | 예 | 높음 | 양호함 |
| 하이브리드 | 높음 | 때때로 | 높음 | 매우 양호함 |
| BDD | 높음 | 예, 읽고 작성 가능 | 높음 | 양호함 |
표를 통해 패턴이 명확해집니다. 설정 비용이 저렴할수록 확장성이 떨어지는 경향이 있으며, 비코딩 사용자를 포함하는 구조는 배후에서 더 많은 엔지니어링 투자가 필요합니다. 공짜 옵션은 없으며, 팀의 제약 조건에 맞는 옵션만 있을 뿐입니다.
흔한 프레임워크 실수
합리적인 유형을 선택한 팀조차도 실제로는 이를 훼손하는 경우가 많습니다. 세 가지 실수가 계속해서 나타납니다.
첫 번째는 성급한 추상화입니다. 팀이 15개의 테스트를 가진 스위트에 키워드 기반 또는 하이브리드 구조를 채택합니다. 추상화 계층은 그것이 서비스하는 테스트보다 구축하고 유지보수하는 데 더 많은 비용이 듭니다. 구조는 규모를 따라야 합니다. 실제 중복이 다음 재사용 계층을 정당화하게 하십시오.
두 번째는 그 반대입니다: 진화를 거부하는 것. 20개의 테스트에서는 잘 작동했던 선형 스위트가 400개에서도 여전히 선형이며, 이제 애플리케이션이 변경될 때마다 복사-붙여넣기된 스크립트를 고통스럽게 수정해야 합니다. 선형 상태를 유지하는 비용은 조용히 누적되다가 작은 변경 하나가 하루 일과를 망치게 됩니다. 하나의 제품 변경으로 많은 테스트를 수정해야 하는 신호를 주시하고, 고통이 일상이 되기 전에 모듈형으로 리팩토링하십시오.
세 번째는 해당 사용자가 없는 유형을 선택하는 것입니다. BDD는 비엔지니어가 실제로 Gherkin을 읽을 때만 효과를 발휘합니다. 키워드 기반은 분석가가 실제로 테스트를 작성할 때만 효과를 발휘합니다. 만약 그 사람들이 스위트를 전혀 건드리지 않는다면, 추가 계층의 비용만 지불하고 이점은 전혀 얻지 못하게 됩니다. 이론상으로 참여할 수 있는 사람이 아니라, 실제로 참여하는 사람에게 유형을 맞추세요.
프레임워크 유형 선택 방법
유행이 아니라 팀과 프로젝트에 맞춰 선택하십시오.
- 규모 및 수명. 일회성 스크립트는 선형일 수 있습니다. 분기 이상 유지보수되는 모든 것은 최소한 모듈형이어야 합니다.
- 누가 테스트를 작성하는가. 모든 엔지니어는 모듈형 또는 하이브리드를 지향합니다. 혼합된 역할은 키워드 기반 또는 BDD를 지향합니다.
- 입력 다양성. 안정적인 워크플로우에 대한 많은 입력 조합은 데이터 기반을 지향합니다.
- 커뮤니케이션 격차. 제품과 엔지니어링 간의 잦은 오해는 BDD를 지향합니다. 왜냐하면 공유된 사양이 BDD의 주요 이점이기 때문입니다.
- 기존 기술. 최고의 프레임워크 유형은 팀이 실제로 유지보수할 수 있는 유형입니다. 아무도 이해하지 못하는 우아한 구조는 모두가 이해하는 평범한 구조보다 더 빨리 실패합니다.
대부분의 팀은 하이브리드에 정착합니다. 모듈형 재사용을 백본으로, 높은 변동성 케이스에는 데이터 기반 입력을, 협업이 가장 중요한 곳에는 BDD를 사용합니다. 간단하게 시작하고, 이론이 아닌 실제 고통이 추가 구조를 정당화하게 하십시오. 프레임워크 유형을 넘어선 테스트 전략에 대해서는, 테스트 시나리오 vs 테스트 케이스 가이드의 구별이 각 테스트가 무엇을 다루어야 하는지 범위를 정하는 데 도움이 됩니다.
플랫폼이 도움이 되는 곳
프레임워크 유형을 선택하는 것은 아키텍처 결정입니다. 이를 잘 실행하려면 올바른 도구가 필요합니다. 특히 API 테스트의 경우, Apidog는 공유되고 매개변수화된 요청을 통한 모듈형 재사용, CSV 및 JSON 파일로부터의 데이터 기반 실행, 그리고 비코딩 사용자가 테스트를 조립할 수 있게 하는 시각적 테스트 빌더를 지원합니다. 이는 직접 구축한 키워드 라이브러리 없이도 키워드 기반 구조의 정신을 구현한 것입니다.
이는 프레임워크 유형이 팀이 이를 일관되게 따를 수 있는 능력만큼만 좋기 때문에 중요합니다. 구조를 내장한 플랫폼은 스위트가 성장하고 사람들이 합류하고 떠날 때 테스트의 일관성을 유지합니다. Apidog를 다운로드하여 이러한 패턴이 실제로 어떻게 느껴지는지 확인한 다음, 얼마나 많은 사용자 정의 프레임워크 코드가 여전히 필요한지 결정할 수 있습니다. 솔직한 답변은 일반적으로 예상보다 적을 것입니다. 왜냐하면 Apidog가 이미 직접 구축한 프레임워크가 다시 구현해야 할 요청, 데이터 및 보고 계층을 처리하기 때문입니다.
자주 묻는 질문
자동화 도구와 자동화 테스트 프레임워크의 차이점은 무엇인가요?
도구는 테스트를 실행합니다 (예: 브라우저 드라이버 또는 HTTP 클라이언트). 프레임워크는 이러한 도구를 둘러싼 구조입니다: 테스트 구성, 로직 공유, 데이터 공급 및 결과 보고를 위한 규칙들입니다. 프레임워크 없이 도구를 사용할 수는 있지만, 테스트 유지보수가 어려울 것입니다. 프레임워크는 자동화를 지속 가능하게 만드는 요소입니다.
어떤 자동화 테스트 프레임워크 유형이 가장 좋은가요?
보편적으로 가장 좋은 것은 없습니다. 선형은 일회성 스크립트에 적합하고, 모듈형은 대부분의 엔지니어링 팀에 적합하며, 데이터 기반은 높은 입력 다양성에 적합하고, 키워드 기반과 BDD는 혼합된 기술 팀에 적합하며, 하이브리드는 크고 성숙한 스위트에 적합합니다. 가장 인기 있는 옵션을 선택하기보다는 팀의 기술과 프로젝트의 수명에 맞춰 유형을 선택하세요.
BDD는 API 또는 UI 테스트에만 사용되나요?
둘 다 아닙니다. BDD는 계층이 아니라 구조적 패턴입니다. Given-When-Then 형식은 단위, API 및 UI 테스트 모두에 적용됩니다. 실제 요구사항은 테스트 계층이 아니라 대상입니다: BDD는 비엔지니어가 실제로 시나리오를 읽거나 작성할 때만 효과를 발휘합니다.
스위트를 구축한 후에 프레임워크 유형을 변경할 수 있나요?
예, 하지만 스위트 크기에 비례하는 노력이 필요합니다. 선형에서 모듈형으로 전환하는 것은 복사-붙여넣기된 스크립트에서 재사용 가능한 함수를 추출하는 것을 의미합니다. 교훈은 조기에 확장 가능한 구조를 선택하는 것입니다. 왜냐하면 수천 개의 테스트에 프레임워크 유형을 나중에 적용하는 것이 올바른 것으로 시작하는 것보다 훨씬 어렵기 때문입니다.
작은 프로젝트에도 프레임워크가 필요한가요?
진정으로 단명하는 프로젝트는 실제 프레임워크 없이 선형, 기록된 스크립트로 실행될 수 있습니다. 그러나 "작은" 프로젝트는 커지는 습관이 있습니다. 스위트가 몇 주 이상 지속되거나 한 명 이상이 건드릴 예정이라면, 가벼운 모듈형 구조라도 빠르게 그 가치를 증명할 것입니다.