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