기본적인 것부터 시작합시다! 두 가지 일반 테스트 모드와 세 가지 일반적인 테스트 자동화 유형을 살펴봅니다.
누구나 한 번쯤은 봤을 것입니다. 실생활에서 너무 자주 반복되는 코딩 밈에는 어떤 것이 있을까요?
이 밈은 이를 매우 잘 요약합니다. 각 창은 개별적으로는 완벽하게 작동하지만 다른 창과 함께 사용하면 서로를 가리며 작동하지 않습니다. 두 창이 서로 잘 연동되고 동시에 작동하기를 원합니다.
이를 웹 개발에 적용합니다. 몇 가지 테스트를 작성했거나 100% 테스트 적용 범위를 달성했을 수도 있지만 다른 부분이 제자리에 배치되면 애플리케이션이 계속 작동해야 합니다. 광고 단원은 그 자체로는 잘 작동하지만 서로 관련이 없을 수 있습니다. 몇 가지 테스트를 작성하는 것은 매우 중요하지만 이는 프로젝트에 이상적인 테스트 설정의 한 부분일 뿐입니다. 첫 번째 단계는 애플리케이션 품질에서 어떤 부분을 보장해야 하고 어떻게 달성할지 결정해야 합니다.
간단히 말해, 실제 테스트 코드 작성을 시작하기 전에 계획이 필요합니다. 실질적으로 테스트하는 방법에 관한 주제에 접근하기 위해 명확한 슬레이트에서 시작하여 다음 두 가지 기본 질문에 답해 봅시다.
- 테스트 방법
- 테스트하려는 항목을 선택하세요.
이 도움말에서는 첫 번째 질문에 답하기 위해 알아야 할 일반적인 사항을 중점적으로 설명합니다. 공통점에서 시작하기 위해 먼저 어떤 테스트 모드가 있는지 알아보고 그런 다음 일반적인 테스트 유형을 중점적으로 살펴보겠습니다. 이어지는 게시글에서는 두 번째 질문에 답하고, 답변을 취합하여, 프로젝트에 가장 적합한 테스트 전략을 찾을 것입니다. 시작하기 🙌
기본사항으로 시작하기: 일반 테스트 모드
테스트 방법에 관한 질문에 답할 때 가장 먼저 명확히 해야 할 점은 매우 추상적입니다. 수동으로 테스트해야 할까요, 아니면 컴퓨터에 맡겨야 할까요? 그러나 여기에서 이진적 사고에 빠지지 않는 것이 중요합니다.
수동 테스트와 자동 테스트 비교
품질 보증 엔지니어에게 테스트를 정의해 달라고 요청하면 아마도 먼저 테스트를 두 가지 '모드'로 나눌 것입니다.
- 수동 테스트. 이는 실제 사람이 수행하는 일반적인 테스트 방법입니다. 품질 보증 엔지니어가 애플리케이션을 클릭하고 작동하는지 확인하면서 동시에 중단하려고 합니다. 가장 일반적인 방법은 엔지니어가 사전 정의된 경로나 체크리스트에 따라 애플리케이션에 대한 지식을 사용하여 애플리케이션을 조사하는 탐색적 테스트입니다.
- 자동 테스트. 컴퓨터로 수행하는 일종의 테스트입니다. 품질 보증 엔지니어가 이를 구현하여 반복적이고 단조로운 테스트를 자동화합니다.
이 가이드 시리즈는 주로 자동 테스트에 중점을 둡니다. 그러나 한 가지 테스트 방법에만 집중해서는 안 됩니다. 자동화를 통해 많은 시간과 노력을 절약할 수 있더라도 수동 테스트와 수동 테스트가 항상 중요한 역할을 합니다. 오히려 테스트 자동화를 통해 사람들은 탐색적 테스트와 창의적인 문제 해결에 집중할 수 있습니다. 예를 들어 사용자 경험의 품질을 보장하거나 고위험 비즈니스 로직을 보호합니다. 즉, 자동화를 활용할 수 있습니다. ❤️
불투명 상자 vs. 투명한 상자
일반 테스트 모드를 정의했습니다. 하지만 아직은 충분하지 않습니다. 테스트 전략을 계획하려면 한 가지 질문이 더 있습니다. 애플리케이션이 내부적으로 어떻게 작동하는지 알고 있는가? 아니면 이 지식 없이 테스트하는 것이 더 나은가? 답변에 따라 테스트 사례를 도출하고 선택하기 위해 선택할 수 있는 두 가지 절차가 있습니다.
- 불투명 박스 테스트 (또는 블랙 박스 테스트). 내부 구조를 고려하지 않고 구성 요소 또는 시스템의 기능적 또는 비기능적 요구사항 (사양)을 분석한 결과를 기반으로 합니다.
- 클리어박스 테스트 (또는 화이트박스 테스트)는 상자의 내부 구조를 고려하는 절차입니다. 즉, 애플리케이션이 내부적으로 작동하는 방식입니다.
두 절차 모두 수동 및 자동 테스트에 적용할 수 있습니다. 그러나 일반 테스트 모드의 몇 가지 측면은 두 가지 중 하나에 더 중점을 둘 수 있습니다. 이에 대해서는 나중에 다루겠습니다. 지금은 테스트 자동화를 유형으로 더 자세히 살펴보겠습니다.
테스트 자동화 유형: 어떻게 테스트하고 싶으신가요?
'어떻게'라는 질문에 대한 답에 가까워질 때 이미 몇 가지 수동 테스트를 진행하기로 결정했습니다. 그러나 테스트 자동화 유형을 선택하고 적용하는 것은 조금 더 까다롭습니다. 자동화 테스트 유형은 프로젝트에서 만들려는 측정항목과 밀접한 관련이 있습니다. 이제 가장 중요한 것을 자세히 살펴보겠습니다.
앞서 언급한 밈에 설명된 것처럼 단위 테스트와 통합 테스트라는 두 가지 유형을 이미 접했습니다. 엔드 투 엔드 테스트는 중요하게 고려해야 할 세 번째입니다. 하지만 그게 전부는 아닙니다. 좀 더 자세히 살펴보겠습니다.
단위 테스트
단위 테스트는 애플리케이션의 테스트 가능한 사소한 부분이나 단위가 제대로 작동하는지 개별적으로 독립적으로 테스트하는 테스트 유형입니다. 이러한 단위는 함수, 클래스, 인터페이스부터 서비스 또는 전체 구성요소에 이르기까지 범위가 다양할 수 있습니다. 기본 속성은 실행 속도, 격리성, 편안한 유지보수성입니다. 단위 테스트에 관해 자세히 알아보려면 단위 테스트에 관한 가이드로 이동하세요.
통합 테스트
통합 테스트는 구성요소 또는 시스템 간의 상호작용에 중점을 둡니다. 즉, 서로 얼마나 효과적으로 연동되었는지를 평가합니다. 통합 테스트의 일반적인 예로는 API 또는 구성요소 테스트가 있습니다.
엔드 투 엔드 테스트
이러한 테스트를 UI 테스트라고 하는 경우가 많으며 이 이름에서 기능을 훨씬 더 잘 설명합니다. 이러한 테스트는 전체 애플리케이션 스택을 비롯하여 애플리케이션의 UI와 상호작용하며 애플리케이션의 한쪽 끝에서 다른 쪽 끝까지 애플리케이션을 테스트합니다.
품질 보증 이론을 언급하면 시스템 테스트와 유사합니다. 이 테스트는 실제 사용자와 사용자의 상호작용을 시뮬레이션합니다. 엔드 투 엔드 테스트는 전체 시스템이 관련되고 런타임이 늘어날수록 컴퓨팅 성능이 더 많이 필요하므로 런타임이 더 많이 걸립니다. 그 결과, 이러한 추가적인 노력으로 인해 유지보수 비용이 높아집니다.
시각적 UI 테스트
UI 테스트의 흥미로운 하위 카테고리는 시각적 테스트입니다. 이러한 테스트는 애플리케이션의 가시적 출력을 확인하는 수단을 제공하는 확장된 엔드 투 엔드 테스트입니다. 이러한 테스트는 변경 후 스크린샷과 '현상 상태'(또는 골든 파일)가 포함된 다른 스크린샷을 찍고 그 결과를 검토자가 검사하고 확인하도록 제공합니다. 즉, 어설션에 명시적으로 기록되지 않은 순수한 기능적 버그를 넘어 페이지 모양에서 '시각적 버그'를 찾는 데 도움이 됩니다.
정적 분석
여기서 소개할 또 한 가지 사항이 있습니다. 정적 분석입니다. 교과서 관점에서의 시험 유형은 아닙니다. 그러나 이는 향후 품질 보증 전략에서 필수적인 측면이 될 것입니다. 맞춤법 검사 함수처럼 작동한다고 생각해 보세요. 프로그램을 실행하지 않고 코드를 검사하여 더 심각한 결함과 구문 오류가 있는지 확인하여 코드 스타일 문제를 감지합니다. 이 간단한 방법으로 많은 버그를 방지할 수 있습니다. 정적 분석에 대해 자세히 알고 싶다면 이 분석에 대해 알아두면 좋습니다.
다양한 형태에서 실험하기: 이 실험들은 어떻게 연동될까요?
이 모든 질문에 대한 답을 검색하면서 일부 비유에서 가능한 해결책을 찾을 수도 있습니다. 특히 웹 및 테스트 커뮤니티에서 개발자는 이러한 비유를 사용하여 어떤 유형의 테스트를 얼마나 많이 사용해야 하는지 알 수 있습니다.
이 이미지에 표시된 5가지 전략은 가장 일반적인 전략입니다.
- 테스트 피라미드
- 테스트 다이아몬드
- 테스트 아이스콘 (테스트 피자)
- Honeycomb 테스트
- 테스트 트로피
처리해야 할 정보가 정말 많습니다. 이 모든 것을 바탕으로 매칭 테스트 전략을 어떻게 결정해야 할까요? 걱정하지 마세요. Google에서 도와 드립니다. 다음 도움말에서는 이러한 다양한 전략에 대해 자세히 설명하고 프로젝트에 가장 적합한 전략을 선택하는 방법을 설명합니다. 계속해서 지켜봐 주세요.