Test Design and Test Execution Automation
1️⃣ Core Concepts of Test Automation
2️⃣ Test Design Automation
3️⃣ Test Execution Automation
1️⃣ Core Concepts of Test Automation
테스트 자동화의 학습목표 (Learning Objectives of Test Automation)
이번 강의의 목표는 테스트 자동화(Test Automation)의 개념과 적용 범위를 이해하는 것이다. 테스트 자동화란 사람이 반복적으로 수행하던 테스트 활동을 도구나 프로그램을 이용해 자동으로 처리하거나 지원하는 것을 말한다. 자동화는 테스트 시간을 줄이고, 반복 테스트를 일관되게 수행하며, 테스트 효율을 높이기 위해 필요하다.
테스트 자동화는 테스트 프로세스의 여러 단계에 적용될 수 있다. 그중 대표적인 것이 테스트 설계 자동화(Test Design Automation)이다. 이는 테스트 케이스(Test Case), 테스트 데이터(Test Data), 테스트 조건(Test Condition) 등을 자동으로 생성하거나 설계 과정을 지원하는 것이다.
또 다른 핵심 영역은 테스트 수행 자동화(Test Execution Automation)이다. 이는 작성된 테스트를 자동으로 실행하고, 실제 결과(Actual Result)와 기대 결과(Expected Result)를 비교하며, 테스트 결과를 기록하는 과정을 지원한다.
결국 테스트 자동화는 단순히 테스트를 실행하는 것만이 아니라, 테스트 설계부터 수행까지 테스트 활동 전반의 효율성과 정확성을 높이는 데 목적이 있다.
테스트 자동화 핵심 개념 (Core Concepts of Test Automation)
테스트 자동화(Test Automation)는 테스트 프로세스의 전체 또는 일부를 도구(Tool)를 활용해 자동으로 수행하거나 지원하는 것을 의미한다. 테스트 프로세스에는 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 테스트 평가(Test Evaluation), 테스트 개선(Test Improvement) 등이 포함되며, 이 중 필요한 부분을 자동화할 수 있다.
일반적으로 자동화(Automation)는 사람이 직접 수행하던 반복적인 절차를 시스템이나 도구가 대신 수행하도록 만드는 것이다. 사람이 직접 모든 단계를 수행하면 입력 실수, 절차 누락, 결과 확인 오류 등이 발생할 수 있고, 시간과 비용도 많이 든다. 반면 자동화를 적용하면 반복 작업에서 발생하는 실수를 줄이고, 사람은 더 창의적이고 중요한 업무에 집중할 수 있다.
예를 들어 로그인 기능을 매뉴얼 테스트(Manual Testing)로 수행하는 경우, 테스터는 웹사이트 주소를 입력하고, 아이디와 비밀번호를 입력한 뒤, 로그인 버튼을 클릭하고, Welcome 페이지가 정상적으로 나타나는지 직접 확인해야 한다.
Selenium과 JUnit을 활용한 로그인 테스트 자동화 예시
(Login Test Automation with Selenium and JUnit)
문법을 자세히 이해하는 것보다 중요한 것은 각 코드가 어떤 역할을 하는지 이해하는 것이다. 예를 들어 로그인 기능을 자동화하는 테스트 메소드가 shouldVisitWelcomePage()라고 하면, 이 메소드는 사용자가 로그인했을 때 Welcome 페이지로 정상 이동하는지를 확인하는 역할을 한다.
먼저 Selenium의 driver.get() 메소드는 테스트할 웹사이트 주소로 이동하는 기능을 한다. 매뉴얼 테스트(Manual Testing)에서는 테스터가 매번 웹사이트 주소를 직접 입력해야 하지만, 자동화 테스트(Automated Testing)에서는 driver.get("웹 사이트 주소")처럼 주소를 코드로 한 번 작성해두면 반복 실행할 때마다 동일한 주소로 접속할 수 있다. 이를 통해 주소 입력 실수를 줄일 수 있다.
다음으로 driver.findElement().sendKeys()는 웹페이지에서 특정 입력란을 찾아 값을 입력하는 역할을 한다. 예를 들어 아이디 입력란을 찾아 사용자 아이디를 입력하고, 비밀번호 입력란을 찾아 비밀번호를 입력할 수 있다. 웹페이지의 id 속성이나 xpath 등을 이용해 원하는 요소(Element)를 찾고, sendKeys()를 통해 값을 넣는 방식이다.
로그인 버튼을 누르는 과정은 click() 메소드를 통해 자동화할 수 있다. 예를 들어 로그인 버튼 요소를 찾은 뒤 click()을 실행하면, 사람이 직접 버튼을 클릭하는 것처럼 자동으로 로그인 버튼이 눌린다. 이렇게 웹사이트 접속, 아이디 입력, 비밀번호 입력, 버튼 클릭 과정을 코드로 작성해두면 같은 테스트를 여러 번 반복해도 동일한 절차로 실행할 수 있다.
마지막으로 JUnit의 assertEquals() 메소드는 기대 결과(Expected Result)와 실제 결과(Actual Result)를 비교하는 역할을 한다. 테스트에서는 예상한 결과와 실제 실행 결과가 같은지 확인하는 과정이 중요하다. 예를 들어 로그인 후 나타나야 하는 “웰컴 메시지”를 기대값으로 두고, 실제 웹페이지에서 getText()로 가져온 메시지와 비교한다. 두 값이 같으면 테스트가 정상적으로 통과한 것이고, 다르면 결함(Defect)이 발생했을 가능성이 있다고 볼 수 있다.
정리하면 Selenium은 웹페이지를 열고, 입력란에 값을 넣고, 버튼을 클릭하는 등 사용자의 행동을 자동화하는 데 사용된다. JUnit은 그 결과가 예상한 값과 같은지 검증하는 데 사용된다. 따라서 Selenium과 JUnit을 함께 사용하면 로그인 기능처럼 반복적으로 확인해야 하는 테스트를 효율적으로 자동화할 수 있다.
이러한 과정을 Selenium이나 JUnit 같은 테스트 도구를 활용해 자동화할 수 있다. Selenium은 웹 애플리케이션(Web Application)의 동작을 자동으로 제어하고 테스트할 수 있는 프레임워크이며, JUnit은 Java 기반의 테스트를 지원하는 도구이다. 예를 들어 Selenium을 이용하면 웹사이트 접속, 아이디 입력, 비밀번호 입력, 로그인 버튼 클릭 과정을 코드로 작성할 수 있다.
또한 JUnit의 assertEquals()와 같은 메소드를 사용하면 기대 결과(Expected Result)와 실제 결과(Actual Result)를 비교할 수 있다. 로그인 후 나타나야 하는 Welcome 메시지를 기대값으로 설정하고, 실제 웹페이지에서 가져온 메시지와 비교하여 두 값이 같으면 테스트가 정상적으로 수행된 것으로 볼 수 있다.
결국 테스트 자동화는 사람이 반복적으로 수행하던 테스트 절차를 코드와 도구로 자동화하여, 테스트 시간을 줄이고 실수를 줄이며 효율성을 높이는 방법이다. 특히 반복 테스트(Repeated Testing), 회귀 테스트(Regression Testing), 입력 데이터가 많은 테스트에서 효과적으로 활용된다.
테스트 자동화의 필요성 (Necessity of Test Automation)
테스트 자동화(Test Automation)가 필요한 이유는 반복적인 테스트를 효율적으로 수행하고, 사람의 실수를 줄이며, 일관된 방식으로 테스트를 진행하기 위해서이다.
첫 번째 필요성은 반복적인 작업을 효율적으로 수행할 수 있다는 점이다. 소프트웨어는 요구사항이 계속 변경될 수 있기 때문에, 기존 기능이 여전히 정상적으로 동작하는지 반복해서 확인해야 한다. 이때 테스트 절차를 코드화해두면, 입력값만 바꿔가며 같은 테스트를 쉽게 반복할 수 있다. 특히 회귀 테스트(Regression Testing)처럼 기존 기능을 계속 다시 확인해야 하는 경우 자동화의 효과가 크다.
또한 부하 테스트(Load Testing)에서도 테스트 자동화가 필요하다. 예를 들어 시스템이 100명의 동시 접속자를 허용해야 한다면, 실제 사용자 100명을 모집해서 동시에 접속시키는 것은 비용과 시간이 많이 든다. 대신 테스트 스크립트(Test Script), 스레드(Thread), 프로세스(Process) 등을 이용해 여러 사용자가 동시에 접속하는 상황을 가상으로 만들 수 있다. 이를 통해 시스템이 많은 부하를 받는 상황에서도 안정적으로 동작하는지 확인할 수 있다.
두 번째 필요성은 실수를 줄이고 일관되게 테스트할 수 있다는 점이다. 사람이 직접 테스트를 수행하면 잘못된 데이터를 입력하거나, 정해진 절차를 빠뜨리는 실수가 발생할 수 있다. 하지만 테스트 자동화를 적용하면 미리 작성된 테스트 코드(Test Code)에 따라 동일한 절차가 반복적으로 실행되기 때문에, 테스트를 더 일관성 있게 수행할 수 있다.
예를 들어 로그인 기능을 테스트할 때 아이디 입력, 비밀번호 입력, 로그인 버튼 클릭, 결과 확인 과정을 코드로 작성해두면 매번 같은 방식으로 테스트할 수 있다. 이를 통해 입력 실수나 절차 누락을 줄일 수 있다.
다만 테스트 자동화가 모든 테스트에 항상 적합한 것은 아니다. 테스트 자동화는 테스트 프로세스 전체에 적용될 수도 있지만, 필요한 일부 과정에만 적용될 수도 있다. 특히 반복적으로 수행되는 부분, 실수가 자주 발생하는 부분, 많은 데이터를 다루는 부분이 자동화 대상이 된다.
반대로 반복이 거의 없거나, 화면 전환이 자연스러운지처럼 사람이 직접 보고 판단하는 것이 더 적절한 테스트도 있다. 예를 들어 e북에서 페이지가 부드럽게 넘어가는지 확인하는 경우에는 자동화보다 사람이 직접 확인하는 것이 더 명확할 수 있다.
결론적으로 테스트 자동화는 무조건 많이 적용하는 것이 아니라, 비용 대비 효과가 큰 부분에 집중해서 적용해야 한다. 반복이 많고 실수 가능성이 높은 테스트를 자동화할 때, 테스트 시간과 비용을 줄이고 테스트 품질을 높일 수 있게 된다.
테스트 프로세스에서 자동화 가능한 부분
(Automation Areas in the Test Process)
테스트 자동화(Test Automation)는 테스트 프로세스 전체에 적용될 수도 있고, 필요한 일부 단계에만 적용될 수도 있다. 따라서 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 테스트 평가(Test Evaluation), 테스트 개선(Test Improvement) 등 여러 단계에서 자동화가 가능하다.
먼저 테스트 계획(Test Planning) 단계에서는 테스트 일정, 인력, 범위 등을 관리해야 한다. 이 과정은 사람이 직접 계획할 수도 있지만, 일정 관리 도구나 테스트 관리 도구(Test Management Tool)를 사용하면 일부 작업을 자동화하거나 체계적으로 관리할 수 있다.
테스트 설계(Test Design) 단계에서는 테스트 케이스(Test Case), 테스트 데이터(Test Data), 테스트 조건(Test Condition) 등을 만드는 과정에서 자동화가 많이 활용될 수 있다. 특히 반복적으로 작성해야 하는 테스트 케이스나 다양한 입력값을 기반으로 하는 테스트 데이터 생성은 자동화의 효과가 크다.
테스트 수행(Test Execution) 단계는 테스트 자동화가 가장 많이 적용되는 부분 중 하나이다. 작성된 테스트 케이스를 자동으로 실행하고, 기대 결과(Expected Result)와 실제 결과(Actual Result)를 비교하며, 테스트 결과를 기록하는 과정이 자동화될 수 있다.
테스트 평가(Test Evaluation)와 테스트 개선(Test Improvement) 단계에서도 자동화가 가능하다. 테스트 수행 결과로 나온 데이터를 도구를 통해 분석하면, 결함 발생률, 테스트 성공률, 반복적으로 실패하는 기능 등을 파악할 수 있다. 이러한 데이터는 이후 테스트 프로세스를 개선하는 데 활용될 수 있다.
다만 테스트 자동화에서 특히 집중하는 부분은 테스트 설계(Test Design)와 테스트 수행(Test Execution)이다. 테스트 케이스를 만들고, 이를 실제로 실행하며 결과를 확인하는 과정에서 자동화의 효과가 크기 때문이다.
정리하면, 테스트 자동화는 테스트 프로세스의 여러 단계에 적용될 수 있지만, 모든 단계를 무조건 자동화하는 것은 아니다. 필요성과 효과를 고려하여 자동화할 부분을 선택해야 하며, 특히 테스트 설계와 테스트 수행 단계가 핵심적인 자동화 대상이 된다.
테스트 설계 자동화의 개념 (Concept of Test Design Automation)
두 번째 시간에는 테스트 설계 자동화(Test Design Automation)의 개념과 적용 방법을 간단한 예시를 통해 살펴본다.
테스트 설계 자동화란 테스트 설계 프로세스(Test Design Process)의 전체 또는 일부를 도구(Tool)를 활용해 자동화하는 것을 의미한다. 특히 테스트 케이스(Test Case)를 개발하거나, 테스트 수행을 위한 환경(Test Environment)을 준비하는 과정에서 반복적이고 실수가 발생하기 쉬운 작업이 자동화 대상이 된다.
테스트 설계 단계에서는 테스트할 조건을 정리하고, 그 조건을 바탕으로 테스트 케이스와 테스트 데이터를 만든다. 이 과정이 매번 수작업으로 이루어지면 누락이나 입력 오류가 발생할 수 있다. 따라서 도구를 사용해 테스트 케이스 생성, 테스트 데이터 준비, 테스트 환경 구성 등을 지원하면 더 효율적이고 일관된 테스트 설계가 가능하다.
ISO/IEC/IEEE 29119의 동적 테스트 프로세스(Dynamic Test Process)를 기준으로 보면, 테스트 설계 자동화의 주요 대상은 테스트 설계 및 구현(Test Design and Implementation)과 테스트 환경 구성 및 유지(Test Environment Set-up and Maintenance) 단계이다. 즉, 테스트를 실제로 수행하기 전에 필요한 테스트 케이스, 테스트 데이터, 테스트 환경을 준비하는 부분이 테스트 설계 자동화의 핵심 범위라고 볼 수 있다.
정리하면, 테스트 설계 자동화는 테스트를 실행하기 전에 필요한 준비 과정을 도구로 지원하거나 자동화하는 것이다. 이를 통해 반복적인 설계 작업을 줄이고, 실수를 줄이며, 테스트 준비 과정을 더 체계적으로 관리할 수 있다.
테스트 케이스 개발 자동화 (Test Case Development Automation)
테스트 케이스 개발 자동화(Test Case Development Automation)는 테스트 설계 기법(Test Design Technique)을 도구에 적용하여 테스트 케이스(Test Case)를 자동으로 생성하거나 지원하는 것이다.
테스트 케이스는 보통 블랙박스 테스트 설계 기법(Black-box Test Design Technique)이나 화이트박스 테스트 설계 기법(White-box Test Design Technique)을 적용해 만든다. 하지만 사람이 직접 테스트 케이스를 만들면 커버리지(Coverage)를 충분히 만족하는 케이스를 빠짐없이 설계하기 어렵고, 누락이나 실수가 발생할 수 있다. 따라서 테스트 설계 기법이 적용된 도구를 활용하면 더 효율적으로 테스트 케이스를 만들 수 있다.
예를 들어 성적에 따라 학점을 부여하는 요구사항이 있다고 하자. 90점 이상 100점 이하는 A, 80점 이상 90점 미만은 B, 70점 이상 80점 미만은 C를 부여하는 방식이다. 이때 각 점수 구간은 같은 결과를 기대할 수 있는 동치 클래스(Equivalence Class)로 볼 수 있다.
동등 분할 테스트(Equivalence Partitioning)는 이러한 입력값의 범위를 의미 있는 구간으로 나누고, 각 구간에서 대표값을 선택해 테스트하는 블랙박스 테스트 기법이다. 예를 들어 90100 구간에서는 95를 대표값으로 선택하고, 8090 구간에서는 85를 대표값으로 선택해 예상한 학점이 나오는지 확인할 수 있다.
이러한 요구사항 명세서(Requirement Specification)를 테스트 설계 도구에 반영하면, 도구가 각 구간의 대표값을 찾아 테스트 케이스를 생성할 수 있다. 더 나아가 생성된 테스트 케이스를 기반으로 실제 테스트 수행까지 연결할 수도 있다.
정리하면, 테스트 케이스 개발 자동화는 테스트 설계 기법을 도구로 지원하여 테스트 케이스를 더 빠르고 일관성 있게 만들기 위한 방법이다. 특히 동등 분할 테스트처럼 일정한 규칙이 있는 테스트 설계에서는 자동화의 효과가 크다.
택배 예약 시스템 예시와 동등 분할의 한계 (Parcel Reservation System Example and Limitation of Equivalence Partitioning)
이번 예시는 테스트 케이스 개발 자동화(Test Case Development Automation)를 이해하기 위한 것이다. 택배 예약 시스템(Parcel Reservation System)에서는 주요 입력 요소(Input Factor)로 택배 무게(Parcel Weight), 배송 지역(Delivery Area), 배송 기간(Delivery Period)이 있다.
동등 분할 테스트(Equivalence Partitioning)를 적용하면 각 입력 요소를 의미 있는 구간이나 값으로 나누고, 각 구간에서 대표값(Representative Value)을 선택한다. 예를 들어 택배 무게는 여러 무게 구간으로 나누고, 배송 지역은 A, B, C, 배송 기간은 일반 배송과 익일 배송으로 나눌 수 있다. 이렇게 나누어진 동치 클래스(Equivalence Class)에서 대표값을 뽑아 테스트 케이스를 만들 수 있다.
이러한 요구사항이 명확하게 정의되어 있다면, 도구를 활용해 테스트 케이스를 자동으로 생성할 수 있다. 택배 무게처럼 범위가 있는 값은 각 구간의 대표값을 선택하고, 배송 지역이나 배송 기간처럼 선택지가 정해진 값은 해당 값을 그대로 테스트 데이터로 사용할 수 있다.
하지만 동등 분할 테스트의 한계는 입력값들의 조합(Combination)을 충분히 고려하지 않는다는 점이다. 동등 분할은 각 입력 요소가 개별적으로 잘 동작하는지를 확인하는 데 초점을 둔다. 예를 들어 택배 무게, 배송 지역, 배송 기간을 각각 테스트할 수는 있지만, 특정 무게와 특정 지역, 특정 배송 기간이 함께 조합되었을 때 발생하는 문제는 놓칠 수 있다.
이 문제를 해결하는 가장 단순한 방법은 모든 조합을 테스트하는 것이다. 예를 들어 택배 무게가 5개 구간, 배송 지역이 3개, 배송 기간이 2개라면 전체 조합은 5 × 3 × 2 = 30개가 된다. 모든 조합을 테스트하면 조합으로 인한 결함을 더 많이 발견할 수 있지만, 테스트 케이스 수가 많아져 시간, 비용, 자원이 많이 필요하다.
따라서 현실적인 대안으로 페어와이즈 테스팅(Pairwise Testing)을 사용할 수 있다. 페어와이즈 테스팅은 모든 입력값의 전체 조합을 테스트하는 대신, 두 입력 요소 사이의 값 조합을 최소 한 번 이상 포함하도록 테스트 케이스를 설계하는 방법이다. 이를 통해 테스트 케이스 수를 줄이면서도 조합으로 인해 발생할 수 있는 결함을 어느 정도 확인할 수 있다.
정리하면, 동등 분할 테스트는 각 입력값의 대표값을 선택해 효율적으로 테스트하는 데 유용하지만, 입력값 간 조합 문제를 충분히 다루기 어렵다. 이 한계를 보완하기 위해 전체 조합 테스트나 페어와이즈 테스팅 같은 방법을 고려할 수 있으며, 이러한 테스트 케이스 생성 과정도 도구를 통해 자동화할 수 있다.
페어와이즈 테스팅 (Pairwise Testing)
페어와이즈 테스팅(Pairwise Testing)은 모든 입력값의 전체 조합을 테스트하기 어려울 때 사용하는 조합 테스트 기법(Combinatorial Testing Technique)이다. 시간과 비용의 제약 때문에 모든 조합을 테스트할 수 없는 경우, 두 개의 입력 요소(Input Factor) 값들이 최소 한 번 이상 함께 조합되도록 테스트 케이스(Test Case)를 설계한다.
전체 조합 테스트(Exhaustive Testing)는 가능한 모든 입력값 조합을 확인하기 때문에 결함을 찾을 가능성은 높지만, 입력 요소가 많아질수록 테스트 케이스 수가 급격히 증가한다. 반면 페어와이즈 테스팅은 모든 조합을 다 확인하지는 않지만, 두 입력값 간의 주요 조합을 포함하도록 하여 테스트 케이스 수를 줄이면서도 일정 수준의 효과를 얻을 수 있다.
예를 들어 입력 요소가 A, B, C 세 개이고, 각 요소에 두 개의 값이 있다고 하자. A는 A1, A2, B는 B1, B2, C는 C1, C2를 가진다. 모든 조합을 테스트하면 2 × 2 × 2 = 8개의 테스트 케이스가 필요하다.
하지만 페어와이즈 테스팅에서는 세 요소 전체의 모든 조합을 확인하는 대신, 두 요소씩 묶은 조합을 고려한다. 즉 A와 B, A와 C, B와 C의 값 조합이 최소 한 번 이상 포함되도록 테스트 케이스를 구성한다.
예를 들어 다음과 같이 테스트 케이스를 만들 수 있다.
이렇게 구성하면 전체 8개 조합을 모두 테스트하지 않아도, A-B, A-C, B-C 사이의 가능한 값 조합을 최소 한 번씩 확인할 수 있다. 예를 들어 TC1에서는 A1-B1, A1-C1, B1-C1 조합이 확인되고, TC2에서는 A1-B2, A1-C2, B2-C2 조합이 확인된다.
즉 페어와이즈 테스팅은 전체 조합을 모두 테스트하지 않는다는 한계가 있지만, 테스트 케이스 수를 줄이면서 입력값 간 조합 문제를 효율적으로 확인할 수 있는 방법이다.
다만 입력 요소나 값의 개수가 많아지면 사람이 직접 페어와이즈 테스트 케이스를 설계하기 어려워진다. 예를 들어 A1, A2뿐 아니라 A3, A4처럼 값이 늘어나고 입력 요소도 많아지면 조합이 복잡해진다. 이때는 페어와이즈 테스트 케이스를 자동으로 생성해주는 도구를 활용하는 것이 효과적이다.
택배 예약 시스템의 페어와이즈 테스팅 적용
(Applying Pairwise Testing to a Parcel Reservation System)
택배 예약 시스템(Parcel Reservation System)에서는 입력 요소(Input Factor)로 택배 무게(Parcel Weight), 배송 지역(Delivery Area), 배송 기간(Delivery Period)이 있다.
이 예시에서 택배 무게는 5개의 대표값(Representative Value), 배송 지역은 A, B, C의 3개 값, 배송 기간은 일반과 익일의 2개 값으로 나뉜다. 모든 조합 테스트(All Combination Testing)를 수행하면 5 × 3 × 2 = 30개의 테스트 케이스(Test Case)가 필요하다.
모든 조합을 테스트하면 입력값들의 조합을 가장 넓게 확인할 수 있지만, 테스트 케이스 수가 많아져 시간, 비용, 자원이 많이 필요하다. 따라서 현실적으로는 비효율적일 수 있다.
이때 페어와이즈 테스팅(Pairwise Testing)을 적용하면 테스트 케이스 수를 줄일 수 있다. 예시에서는 전체 30개의 테스트 케이스 대신 15개의 페어와이즈 테스트 케이스를 만든다. 이 15개 케이스는 모든 조합을 전부 확인하지는 않지만, 택배 무게와 배송 지역, 택배 무게와 배송 기간, 배송 지역과 배송 기간 사이의 주요 쌍 조합(Pair Combination)을 포함하도록 구성된다.
즉 페어와이즈 테스팅은 전체 조합을 모두 테스트하지 않으면서도, 두 입력 요소 간의 조합을 최대한 효율적으로 확인하는 방법이다. 이를 통해 테스트 케이스 수를 줄이고, 테스트 수행에 필요한 시간과 비용을 줄일 수 있다.
하지만 입력 요소와 값이 많아지면 사람이 직접 페어와이즈 테스트 케이스를 만드는 것은 헷갈리고 어렵다. 그래서 이런 경우에는 페어와이즈 테스트 케이스를 자동으로 생성해주는 도구(Test Case Generation Tool)를 활용할 수 있다. 이처럼 테스트 케이스 수를 줄이면서도 중요한 조합을 확인할 수 있는 부분이 테스트 설계 자동화(Test Design Automation)가 필요한 이유이다.
PICT를 활용한 테스트 케이스 자동 생성(Automatic Test Case Generation with PICT)
이번 예시는 페어와이즈 테스팅 도구(Pairwise Testing Tool)인 PICT를 활용해 테스트 케이스(Test Case)를 자동으로 생성하는 방법이다.
예시에서는 스마트폰 제품 명세(Smartphone Product Specification)를 기준으로 테스트 케이스를 만든다. 입력 요소(Input Factor)는 크기(Size), 무게(Weight), 저장 공간(Storage), 메모리(Memory), 배터리(Battery) 총 5가지이다. 각 요소는 2개의 값을 가진다. 예를 들어 크기는 6.1 inch와 6.8 inch, 무게는 220g과 240g, 저장 공간은 256GB와 512GB, 메모리는 8GB와 12GB, 배터리는 16hrs와 18hrs로 나눌 수 있다.
이 모든 값을 전체 조합(All Combination)으로 테스트하면 2 × 2 × 2 × 2 × 2 = 32개의 테스트 케이스가 필요하다. 하지만 모든 조합을 테스트하면 시간과 비용이 많이 들기 때문에, 페어와이즈 테스팅(Pairwise Testing)을 적용해 테스트 케이스 수를 줄일 수 있다.
이 예시에서 중요한 점은 제품의 각 요소가 독립적으로만 문제를 일으키는 것이 아니라, 서로 조합되었을 때 품질 문제(Quality Issue)가 발생할 수 있다는 것이다. 예를 들어 스마트폰의 크기(Size)가 커지면 무게(Weight)가 증가할 수 있고, 무게나 배터리 사용 시간(Battery Life)에 따라 사용자의 불편함이 생길 수도 있다. 따라서 각 요소를 따로 보는 것뿐만 아니라, 요소들 간의 조합도 함께 고려해야 한다.
PICT는 이러한 입력 요소와 값들을 기반으로, 두 요소 간의 조합(Pair Combination)이 포함되도록 테스트 케이스를 자동으로 생성해주는 도구이다. 사람이 직접 조합을 계산하면 복잡하고 실수하기 쉽지만, PICT를 사용하면 더 적은 수의 테스트 케이스로 주요 조합을 확인할 수 있다.
정리하면, PICT를 활용한 테스트 케이스 자동 생성은 전체 조합 테스트보다 테스트 케이스 수를 줄이면서도, 입력 요소 간의 중요한 조합을 확인하기 위한 방법이다. 이는 테스트 설계 자동화(Test Design Automation)의 대표적인 예시라고 볼 수 있다.
PICT 도구 적용 과정 (Applying the PICT Tool)
PICT는 페어와이즈 테스팅(Pairwise Testing)을 적용하여 테스트 케이스(Test Case)를 자동으로 생성해주는 도구이다. 이번 예시에서는 스마트폰 제품 명세(Smartphone Product Specification)를 테스트 데이터(Test Data)로 만들고, 이를 PICT에 입력하여 테스트 케이스를 생성한다.
먼저 11주차 자료에서 PICT 도구(PICT Tool)와 테스트 데이터(Test Data) 파일을 PC로 다운로드한다. 테스트 데이터 파일은 스마트폰의 요구사항이나 제품 명세를 바탕으로 작성된 예시 파일이다. 여기에는 크기(Size), 무게(Weight), 저장 공간(Storage), 메모리(Memory), 배터리(Battery)와 같은 입력 요소와 각 요소의 값들이 정리되어 있다.
다운로드가 끝나면 명령 프롬프트(Command Prompt, cmd)를 실행하고, PICT 도구와 테스트 데이터 파일이 있는 경로로 이동한다. 이후 pict.exe testdata.txt 명령어를 입력하면, testdata.txt에 작성된 입력값을 바탕으로 페어와이즈 테스트 케이스가 자동으로 생성된다.
PICT 내부에는 테스트 케이스를 생성하는 알고리즘이 포함되어 있지만, 이번 강의에서는 알고리즘 자체를 자세히 이해하는 것보다 입력 요소들 사이의 두 값 조합(Pair Combination)을 어떻게 만들어내는지 이해하는 것이 중요하다. 즉, PICT를 활용하면 사람이 직접 복잡한 조합을 계산하지 않아도, 주요 조합을 포함하는 테스트 케이스를 효율적으로 만들 수 있다.
정리하면, PICT 적용 과정은 테스트 데이터를 준비하고, 명령 프롬프트에서 PICT를 실행하여 테스트 케이스를 자동 생성하는 방식이다. 이는 테스트 설계 자동화(Test Design Automation)의 실제 적용 예시라고 볼 수 있다.
PICT를 활용한 테스트 케이스 자동 생성 결과
(Test Case Generation Result with PICT)
스마트폰 제품 명세(Smartphone Product Specification)는 테스트 데이터(Test Data) 파일에 정리되어 있다. 이 파일에는 크기(Size), 무게(Weight), 저장 공간(Storage), 메모리(Memory), 배터리(Battery)와 같은 입력 요소와 각 요소의 값이 포함된다.
이 테스트 데이터를 PICT 도구(PICT Tool)에 입력하면, 페어와이즈 테스팅(Pairwise Testing)을 만족하는 테스트 케이스가 자동으로 생성된다. 예시에서는 전체 조합을 모두 테스트하면 32개의 테스트 케이스가 필요하지만, PICT를 적용하면 7개의 테스트 케이스만으로 주요 쌍 조합(Pair Combination)을 확인할 수 있다.
즉 Size와 Weight, Size와 Storage, Size와 Memory, Size와 Battery뿐만 아니라, Weight와 Storage, Memory와 Battery처럼 각 입력 요소들 사이의 두 값 조합을 고려한 테스트가 가능하다. 이를 통해 모든 조합을 테스트하지 않더라도 중요한 조합을 효율적으로 확인할 수 있다.
테스트 설계(Test Design) 단계에서는 테스트 설계 기법(Test Design Technique)을 이용해 직접 테스트 케이스를 만들 수도 있다. 하지만 사람이 직접 만들 경우 불필요한 테스트 케이스가 많아지거나, 반대로 중요한 조합을 빠뜨려 커버리지(Coverage)를 충분히 확보하지 못할 수 있다.
이때 PICT와 같은 도구를 사용하면 커버리지를 일정 수준 유지하면서도 테스트 케이스 수를 줄일 수 있다. 따라서 테스트 케이스를 더 효율적이고 체계적으로 생성할 수 있으며, 이는 테스트 설계 자동화(Test Design Automation)의 대표적인 예시라고 볼 수 있다.
테스트 환경 준비 자동화 (Test Environment Preparation Automation)
테스트 환경 준비 자동화(Test Environment Preparation Automation)는 테스트를 수행하기 위한 시스템 환경을 수동으로 구성하는 대신, 스크립트(Script)나 도구(Tool)를 사용해 자동으로 구성하는 것을 의미한다.
예를 들어 웹 테스트(Web Testing)를 수행한다면 웹페이지 주소, 포트 번호(Port Number), 설정값(Configuration Value), 필요한 도구와 라이브러리 정보 등을 미리 스크립트에 기록해둘 수 있다. 이후 이 스크립트를 실행하면 테스트에 필요한 환경을 자동으로 구성할 수 있다.
테스트 환경을 수동으로 구성하면 개발 환경(Development Environment)에서는 잘 동작하던 애플리케이션이 테스트 환경(Test Environment)이나 운영 환경(Production Environment)에서는 제대로 동작하지 않는 경우가 생길 수 있다. 이는 각 환경에 설치된 도구, 라이브러리(Library), 버전(Version), 설정값 등이 다르기 때문에 발생할 수 있다.
이러한 문제를 줄이기 위해 테스트 환경도 가능한 한 개발 환경, 테스트 환경, 운영 환경이 동일하거나 유사하게 구성되도록 관리해야 한다. 이를 위해 인프라(Infrastructure)를 코드처럼 관리하는 IaC(Infrastructure as Code) 개념을 활용할 수 있다.
IaC는 서버, 네트워크, 설정값, 라이브러리 등 인프라 구성 정보를 코드로 작성하고 관리하는 방식이다. 이를 사용하면 개발자, 테스터, 운영 담당자가 같은 환경을 기준으로 작업할 수 있고, 환경 차이로 인한 오류를 줄일 수 있다.
정리하면, 테스트 환경 준비 자동화는 테스트 환경을 일관되게 구성하고, 수동 설정에서 발생할 수 있는 실수를 줄이기 위한 방법이다. 특히 여러 환경에서 동일한 조건으로 테스트해야 할 때 효과적이다.
도커 기반 개발 및 운영 환경 자동 구성 예시
(Docker-based Environment Automation Example)
개발 및 운영 환경을 자동으로 구성하는 대표적인 도구 중 하나가 도커(Docker)이다. 도커는 애플리케이션 실행에 필요한 라이브러리(Library), 미들웨어(Middleware), 시스템 도구(System Tool), 런타임 환경(Runtime Environment) 등을 컨테이너(Container)라는 단위로 패키징하여 관리한다.
기존의 가상 머신(Virtual Machine)은 하나의 컴퓨터 안에 또 다른 운영체제(OS)를 설치하고, 그 위에 빌드 도구, 테스트 도구, 애플리케이션 등을 설치하는 방식이다. 이 경우 OS 위에 또 다른 OS가 올라가기 때문에 비교적 무겁고, 많은 컴퓨터 자원이 필요하다.
반면 도커는 호스트 운영체제(Host OS)를 공유하면서 필요한 실행 파일과 설정 파일만 컨테이너 단위로 묶어 실행한다. 따라서 가상 머신보다 가볍고, 자원을 더 효율적으로 사용할 수 있다.
예를 들어 개발 환경에서는 빌드(Build), 테스트(Test), 지속적 통합(Continuous Integration)을 위해 Jenkins, Git, 테스트 도구 등을 사용할 수 있다. 이러한 도구들을 각각 컨테이너로 구성하면 환경을 더 쉽게 관리할 수 있다. 빌드 환경에 문제가 생기면 빌드 컨테이너만 수정하면 되고, 테스트 환경에 문제가 생기면 테스트 컨테이너를 수정하면 된다.
테스트 환경도 도커를 활용해 자동으로 구성할 수 있다. 테스트를 수행하기 위해 필요한 도구와 설정을 컨테이너로 만들어두면, 매번 서버를 직접 설정하지 않아도 동일한 테스트 환경을 빠르게 실행할 수 있다. 이를 통해 개발 환경과 테스트 환경의 차이를 줄이고, 테스트 자동화(Test Automation)를 더 효율적으로 수행할 수 있다.
정리하면, 도커는 컨테이너(Container)를 이용해 개발, 빌드, 테스트, 운영 환경을 일관되게 구성할 수 있도록 돕는 도구이다. 테스트 환경 준비 자동화(Test Environment Preparation Automation)에서도 도커를 활용하면 환경 구성의 실수를 줄이고, 자원을 효율적으로 사용하며, 반복 가능한 테스트 환경을 만들 수 있다.
테스트 수행 자동화의 개념 (Concept of Test Execution Automation)
이번 챕터에서는 테스트 자동화(Test Automation) 중 실제 테스트를 실행하는 단계인 테스트 수행 자동화(Test Execution Automation)를 살펴본다.
테스트 수행 자동화란 이미 설계된 테스트 케이스(Test Case)를 실행하고, 테스트 결과(Test Result)를 판정하며, 결과를 기록하거나 보고하는 과정에서 반복적이고 실수가 발생하기 쉬운 작업을 도구(Tool)를 활용해 자동화하는 것을 의미한다.
ISO/IEC/IEEE 29119 표준의 동적 테스트 프로세스(Dynamic Test Process)를 기준으로 보면, 테스트 수행 자동화의 주요 대상은 테스트 수행(Test Execution)과 테스트 결과 보고(Test Result Reporting) 단계이다. 즉, 테스트를 실제로 실행하고 그 결과를 확인·기록·보고하는 부분이 자동화 대상이 된다.
다만 테스트 수행 자동화가 제대로 이루어지기 위해서는 그 전에 테스트 설계(Test Design)와 테스트 환경 구성(Test Environment Set-up)이 적절하게 준비되어 있어야 한다. 테스트 케이스가 명확하지 않거나 테스트 환경이 불안정하면, 자동화된 테스트 수행도 신뢰하기 어렵기 때문이다.
정리하면, 테스트 수행 자동화는 준비된 테스트 케이스를 도구를 통해 반복 실행하고, 기대 결과(Expected Result)와 실제 결과(Actual Result)를 비교하며, 테스트 결과를 체계적으로 기록하는 과정이다. 이를 통해 테스트 수행 과정의 시간과 실수를 줄이고, 반복 테스트를 더 일관되게 수행할 수 있다.
Selenium IDE를 활용한 회원가입 웹페이지 반복 테스트
(Repeated Web Page Testing with Selenium IDE)
이번 예시는 회원가입 웹페이지(Sign-up Web Page)를 대상으로 Selenium IDE를 적용해 테스트 수행을 자동화하는 과정이다. Selenium IDE는 웹 애플리케이션(Web Application)의 동작을 녹화하고 재실행할 수 있는 테스트 자동화 도구(Test Automation Tool)이다.
테스터가 직접 웹페이지에서 아이디를 입력하고, 도메인을 선택하거나 입력하고, 화면을 클릭하는 과정을 Selenium IDE로 녹화하면, 이후 같은 절차를 반복 실행할 수 있다. 즉 사람이 매번 같은 테스트 절차를 수행하지 않아도, 녹화된 테스트 시나리오(Test Scenario)를 도구가 대신 실행할 수 있다.
예시에서는 위메프 회원가입 화면의 이메일 ID 입력 기능을 테스트 대상으로 한다. 전체 회원가입 기능이 아니라, 이메일 ID와 도메인 입력이 정상적으로 처리되는지만 확인한다.
테스트 케이스명(Test Case Name)은 “이메일 ID 입력 정상”이다. 시나리오는 먼저 이메일 ID 입력 영역을 클릭하고, 이메일 ID에 cuk을 입력한다. 그다음 @ 기호 다음의 도메인 영역을 클릭하면, 아직 도메인이 입력되지 않았기 때문에 “이메일 형식을 다시 확인해 주세요.”라는 빨간 메시지가 표시되어야 한다.
이후 사용자가 도메인 영역을 다시 클릭하고 cuk.edu를 입력한 뒤, 회원가입 페이지의 빈 영역을 클릭하면 더 이상 이메일 형식 오류 메시지가 표시되지 않아야 한다. 즉 올바른 이메일 형식인 cuk@cuk.edu가 완성되었기 때문에 오류 메시지가 사라지는 것이 정상적인 예상 결과(Expected Result)이다.
이 테스트의 입력값(Input Value)은 이메일 ID인 cuk과 도메인인 cuk.edu이다. 예상 결과는 이메일 형식이 정상적으로 입력되었을 때 아무 오류 메시지도 표시되지 않는 것이다.
정리하면, 이 예시는 사람이 직접 반복해야 하는 회원가입 입력 절차를 Selenium IDE로 녹화하고 재실행하여 테스트 수행 자동화(Test Execution Automation)를 적용하는 사례이다. 간단한 이메일 입력 테스트처럼 보이지만, 실제로는 클릭, 입력, 오류 메시지 확인, 재입력, 결과 확인이라는 여러 단계가 필요하기 때문에 자동화의 효과를 확인하기 좋은 예시이다.
📌Selenium IDE 설치 관련 변경 사항
(Change in Selenium IDE Installation)
강의 예시에서는 크롬 브라우저(Chrome Browser)에서 Selenium IDE를 설치하고, 회원가입 웹페이지의 테스트 과정을 녹화하여 반복 실행하는 방식으로 설명한다.
하지만 현재 공지에 따르면 크롬 웹스토어(Chrome Web Store)에서 Selenium IDE가 정상적으로 지원되지 않아, 강의와 동일한 방식으로 직접 설치하고 실행하기는 어렵다. 따라서 해당 실습은 실제 설치보다는 녹화 영상을 참고하여 Selenium IDE의 동작 방식과 테스트 수행 자동화(Test Execution Automation)의 개념을 이해하는 데 초점을 두면 된다.
대신 Selenium IDE와 유사하게 웹 브라우저에서 사용자의 동작을 녹화하고 재생할 수 있는 대체 도구로 Katalon Recorder를 사용할 수 있다. Katalon Recorder도 웹 애플리케이션(Web Application)의 클릭, 입력, 검증 과정을 기록하고 반복 실행하는 데 활용할 수 있으므로, Selenium IDE 실습의 대안으로 적절하다.
정리하면, 이 예시는 특정 도구 설치 자체보다 웹 테스트 과정을 녹화(Record)하고 재생(Playback)하여 반복 테스트를 자동화하는 개념을 이해하는 것이 핵심이다. Selenium IDE를 직접 사용하기 어렵다면 Katalon Recorder와 같은 대체 도구를 통해 비슷한 방식의 테스트 수행 자동화를 경험할 수 있다.
