GUI 테스트: UI 테스트 케이스 및 예시
⚡ 스마트 요약
GUI 테스트는 애플리케이션의 모든 보이는 요소(버튼, 메뉴, 아이콘, 텍스트 상자, 레이아웃)를 검증하여 실제 사용자가 화면을 사용하기 전에 브라우저, 장치 및 화면 해상도에 관계없이 화면이 지정된 대로 정확하게 작동하고 표시되는지 확인합니다.

GUI 테스트를 이해하기 위해서는 먼저 GUI가 무엇인지 알아야 합니다.
GUI 란 무엇입니까?
컴퓨터 애플리케이션에는 두 가지 유형의 인터페이스가 있습니다. 명령줄 인터페이스는 텍스트를 입력하면 컴퓨터가 해당 명령에 응답하는 곳입니다. GUI는 텍스트가 아닌 이미지를 사용하여 컴퓨터와 상호 작용하는 그래픽 사용자 인터페이스(Graphical User Interface)를 의미합니다.
사용자와 애플리케이션 간의 상호작용에 사용할 수 있는 GUI 요소는 다음과 같습니다.
GUI 테스트는 위 요소를 검증하는 것입니다.
GUI 테스트란 무엇입니까?
GUI 테스트 소프트웨어의 그래픽 사용자 인터페이스를 확인하는 소프트웨어 테스트 유형입니다. 그래픽 사용자 인터페이스(GUI) 테스트의 목적은 메뉴, 버튼, 아이콘 등과 같은 화면과 컨트롤을 확인하여 소프트웨어 응용 프로그램의 기능이 사양에 따라 작동하는지 확인하는 것입니다.
GUI는 사용자가 보는 화면입니다. guru99.com에 접속하면 홈페이지가 나타나는데, 이것이 바로 사이트의 GUI입니다. 소스 코드는 숨겨져 있고, 인터페이스만 보입니다. 따라서 GUI 테스트는 디자인 구조와 이미지가 올바르게 렌더링되는지 여부에 중점을 둡니다.
위 스크린샷에서 GUI 테스트는 모든 이미지가 다양한 브라우저에서 완전히 보이는지 확인하는 것으로 시작합니다. 같은 페이지에서 수행되는 나머지 검사는 다음과 같습니다.
- 링크는 모두 사용 가능하며, 각 버튼은 클릭하면 정상적으로 작동합니다.
- 화면 크기를 조정해도 이미지나 텍스트가 축소되거나 잘리거나 겹치지 않습니다.
- 브라우저 창의 너비를 줄여도 레이아웃의 어떤 부분도 무너지지 않습니다.
💡 팁: 결함을 보고하기 전에 1920×1080, 1366×768 및 375×812 해상도에서 동일한 페이지를 실행해 보세요. 많은 "레이아웃 오류" 보고서는 단순히 테스트되지 않은 브레이크포인트 문제일 뿐입니다.
GUI 테스트의 필요성
이제 GUI 테스트의 기본 개념이 명확해졌습니다. 여러분의 머릿속에 떠오를 몇 가지 질문은 다음과 같습니다.
- GUI 테스트를 수행하는 이유는 무엇입니까?
- 정말 필요한가요?
- 애플리케이션의 기능과 논리를 테스트하는 것만으로는 충분하지 않은 걸까요? 인터페이스에 추가적인 시간을 투자해야 할 이유가 있을까요?
답을 얻으려면 테스터가 아닌 사용자의 입장에서 생각하세요. 사용자는 애플리케이션이 어떻게 만들어졌는지 알지 못합니다. 사용자가 애플리케이션을 계속 사용할지 아니면 포기할지는 인터페이스에 달려 있습니다.
일반 사용자는 먼저 애플리케이션의 디자인과 외관, 그리고 인터페이스가 얼마나 이해하기 쉬운지를 살펴봅니다. 인터페이스가 불편하거나 애플리케이션이 복잡하다고 느끼는 사용자는 다시는 해당 애플리케이션을 사용하지 않을 것입니다. 따라서 GUI는 중요한 요소이며, 인터페이스에 버그가 없는지 확인하기 위해 철저한 테스트를 거쳐야 합니다.
GUI 테스트 유형
인터페이스가 왜 중요한지 아는 것은 전체 그림의 절반에 불과합니다. GUI 테스트는 다섯 가지 유형으로 나뉘며, 각 유형은 동일한 화면에 대해 서로 다른 질문에 답합니다.
- 기능적 GUI 테스트: 모든 제어 기능이 약속한 대로 작동하는지 확인합니다. 밀접하게 관련되어 있습니다. 기능 테스트버튼을 누르면 제출이 되는지, 드롭다운 메뉴가 필터링을 하는지, 입력 필드가 유효한 입력을 허용하는지 등을 묻습니다.
- 사용성 테스트 : 실제 사람이 작업을 얼마나 쉽게 완료하는지 측정합니다. 사용성 테스트 탐색 깊이, 가독성, 그리고 오류 메시지가 실제로 도움이 되는지 여부를 살펴봅니다.
- 호환성 테스트: 브라우저, 운영 체제 및 기기 크기에 관계없이 동일한 화면을 반복해서 표시합니다. 크로스 브라우저 테스트 특정 엔진에서만 발생하는 렌더링 오류를 잡아냅니다.
- 접근성 테스트: 키보드 탐색, 화면 낭독기 레이블 및 색상 대비가 WCAG를 준수하는지 확인합니다. 접근성 테스트 이제 많은 시장에서 필수 준수 요건이며, 선택 사항이 아닙니다.
- 시각적 및 성능 테스트: 렌더링된 스크린샷을 기준선과 비교하여 인터페이스의 렌더링 및 반응 속도, 겹침 정도를 측정합니다.ping 과 성능 시험.
대부분의 팀은 다섯 가지 모두를 실행하지만 중요도는 다릅니다. 공개 웹사이트는 호환성과 접근성에 중점을 두고, 내부 대시보드는 기능 점검에 중점을 둡니다.
GUI 테스트에서 무엇을 확인하나요?
다음 체크리스트는 소프트웨어 테스팅에서 자세한 GUI 테스팅을 보장합니다.
- 모든 GUI 요소의 크기, 위치, 너비, 길이, 문자 또는 숫자 허용 여부를 확인합니다. 예를 들어, 입력 필드에 입력을 제공할 수 있어야 합니다.
- GUI를 사용하여 애플리케이션의 의도된 기능을 실행할 수 있는지 확인하세요.
- 오류 메시지가 올바르게 표시되는지 확인하세요
- 화면의 다양한 섹션이 명확하게 구분되어 있는지 확인하세요.
- 응용 프로그램에서 사용된 글꼴이 읽을 수 있는지 확인하세요
- 텍스트 정렬이 올바른지 확인하세요.
- 글꼴 색상과 경고 메시지가 미학적으로 만족스러운지 확인하세요.
- 이미지의 선명도가 좋은지 확인하세요.
- 이미지가 올바르게 정렬되었는지 확인하세요.
- 다양한 화면 해상도에 대한 GUI 요소의 위치를 확인하세요.
GUI 테스트 기술
체크리스트가 만들어지면 다음 단계는 그것을 어떻게 실행할지 결정하는 것입니다. GUI 테스트 기술 세 부분으로 분류될 수 있습니다:
수동 기반 테스트
이 접근 방식에서는 비즈니스 요구 사항 문서에 명시된 요구 사항에 따라 테스터가 그래픽 화면을 수동으로 확인합니다.
기록 및 재생
GUI 테스트는 자동화 도구를 사용하여 수행할 수 있습니다. 이 과정은 두 단계로 진행됩니다. 첫 번째 단계인 기록 단계에서는 자동화 도구가 테스트 단계를 캡처합니다. 두 번째 단계인 재생 단계에서는 기록된 테스트 단계를 테스트 대상 애플리케이션에서 실행합니다. 이러한 도구의 예는 다음과 같습니다. QTP.
모델 기반 테스트
모델은 시스템의 동작을 그래픽으로 표현한 것입니다. 모델을 통해 시스템의 동작을 이해하고 예측할 수 있습니다. 또한, 모델은 시스템 요구사항을 활용하여 효율적인 테스트 케이스를 생성하는 데 도움을 줍니다. 아래 그림은 모델을 통해 테스트 케이스가 생성되는 과정을 보여줍니다.
이 모델 기반 테스트를 위해서는 다음 사항을 고려해야 합니다.
- 모델 구축
- 모델에 대한 입력 결정
- 모델의 예상 출력 계산
- 테스트 실행
- 실제 출력과 예상 출력을 비교합니다.
- 모델에 대한 추가 조치에 대한 결정
테스트 케이스를 도출할 수 있는 일부 모델링 기술은 다음과 같습니다.
- 차트 – 시스템 상태를 표시하고 일부 입력 후 상태를 확인합니다.
- 결정 테이블 – 적용된 각 입력에 대한 결과를 결정하는 데 사용되는 테이블
모델 기반 테스트는 요구 사항에서 테스트 사례를 생성하기 위한 진화하는 기술입니다.. 위의 두 가지 방법과 비교할 때 이 방법의 주요 장점은 GUI가 달성할 수 있는 바람직하지 않은 상태를 결정할 수 있다는 것입니다.
수동 GUI 테스트 vs. 자동화된 GUI 테스트
이 세 가지 기술 중 두 가지는 수동 방식이고 한 가지는 자동화 방식인데, 이는 각각이 어디에 적합한지에 대한 실질적인 질문을 제기합니다. 수동 테스트 사람이 화면 앞에 서서 작업하기 때문에 어색한 작업 흐름, 서투른 표현, 부자연스러운 애니메이션 등을 잡아낼 수 있습니다. 이러한 판단은 어떤 스크립트도 할 수 없는 부분입니다.
자동화 된 테스트 동일한 상호 작용을 수천 번 반복해도 피로감이 느껴지지 않으므로 안정적인 회귀 경로와 여러 브라우저에서 동일한 테스트 스위트를 반복적으로 사용하는 데 적합합니다. 하지만 유지 관리 측면에서 단점이 있습니다. 자동화된 GUI 스크립트는 로케이터나 레이아웃이 변경될 때마다 작동이 중단됩니다. 따라서 대부분의 숙련된 개발팀은 반복적인 작업은 자동화하고 경험적인 부분에는 인력을 투입하는 하이브리드 방식을 사용합니다.
| 요인 | 수동 GUI 테스트 | 자동화된 GUI 테스트 |
|---|---|---|
| 가장 좋은 | 새로운 화면, 탐색적 점검, 디자인 및 사용자 경험 | 안정적인 회귀 테스트 스위트, 크로스 브라우저 실행 |
| 사이클당 속도 | 속도가 느리고, 테스터 근무 시간에 제한이 있습니다. | 빠르고, 밤새도록 무인으로 작동합니다. |
| 선행 비용 | 높음 | 높음 (스크립팅 및 프레임워크 설정) |
| 유지보수 | 체크리스트 업데이트 외에는 없습니다. | 인터페이스가 변경될 때 중요한 의미를 갖습니다. |
| 주관적인 문제를 포착합니다 | 가능 | 아니 |
GUI 테스트 테스트 케이스 예
GUI 테스트에는 기본적으로 다음이 포함됩니다.
- 요소의 크기, 위치, 너비, 높이를 테스트합니다.
- 표시되는 오류 메시지를 테스트합니다.
- 화면의 다양한 섹션을 테스트합니다.
- 글꼴이 읽을 수 있는지 테스트합니다.
- 640 x 480, 600 x 800 등 확대 및 축소를 통해 다양한 해상도에서 화면을 테스트합니다.
- 텍스트와 아이콘, 버튼 등과 같은 기타 요소의 정렬이 올바른 위치에 있는지 테스트합니다.
- 글꼴 색상을 테스트합니다.
- 오류 메시지, 경고 메시지의 색상을 테스트합니다.
- 이미지의 선명도가 좋은지 여부를 테스트합니다.
- 이미지 정렬을 테스트합니다.
- 철자 테스트.
- 사용자는 시스템 인터페이스를 사용하는 동안 좌절감을 느껴서는 안 됩니다.
- 인터페이스가 제대로 작동하는지 테스트 중trac긍정적이든 아니든.
- 페이지 크기에 따라 스크롤 막대를 테스트합니다.
- 비활성화된 필드가 있는 경우 테스트합니다.
- 이미지 크기 테스트.
- 제목이 제대로 정렬되었는지 여부를 테스트합니다.
- 하이퍼링크 색상 테스트.
데모: GUI 테스트 수행 방법
위 목록은 실제 화면에 적용될 때 훨씬 더 명확해지므로, 여기서는 다음 대화 상자에 대한 몇 가지 샘플 테스트 사례를 사용하겠습니다.
아래는 UI 및 사용성 테스트 시나리오로 구성된 테스트 케이스 예시입니다. 테스트 케이스 작성이 처음이시라면, 다음 내용을 참고하세요. 테스트 케이스를 작성하는 방법 먼저.
테스트 케이스 01 – 레이블이 "인 텍스트 상자가 올바른지 확인하십시오.소스 폴더"가 올바르게 정렬되었습니다.
테스트 케이스 02 – 레이블이 "인 텍스트 상자가 올바른지 확인하십시오.묶음"가 올바르게 정렬되었습니다.
테스트 케이스 03 – "라는 이름이 적힌 라벨을 확인하십시오.검색”는 텍스트 끝에 있는 버튼입니다.Box "라는 이름으로소스 폴더. "
테스트 케이스 04 – "라는 이름이 적힌 라벨을 확인하십시오.검색”는 텍스트 끝에 있는 버튼입니다.Box "라는 이름으로묶음. "
테스트 케이스 05 – 레이블이 "인 텍스트 상자가 올바른지 확인하십시오.이름"가 올바르게 정렬되었습니다.
테스트 케이스 06 – 라벨이 “수정 자”는 이름이 public, default, private, protected인 4개의 라디오 버튼으로 구성됩니다.
테스트 케이스 07 – 라벨이 “수정 자”는 일렬로 올바르게 정렬된 4개의 라디오 버튼으로 구성됩니다.
테스트 케이스 08 – 라벨이 “슈퍼 클래스' 라벨 아래 '수정 자”는 올바르게 정렬되어야 하는 드롭다운으로 구성됩니다.
테스트 케이스 09 – 라벨이 “슈퍼 클래스"는 "라는 라벨이 붙은 버튼으로 구성됩니다.검색”라는 메시지가 올바르게 정렬되어야 합니다.
테스트 케이스 10 – 라디오 버튼을 클릭했을 때 기본 마우스 포인터가 손 모양 마우스 포인터로 변경되는지 확인하십시오.
테스트 케이스 11 – 사용자가 드롭다운 메뉴에 입력할 수 없도록 확인해야 합니다.슈퍼 클래스. "
테스트 케이스 12 – 만약 어떤 항목이 잘못 선택되었을 경우, 적절한 오류 메시지가 생성되는지 확인하십시오.
테스트 케이스 13 – 오류 메시지가 필요한 경우 빨간색으로 표시되어야 함을 확인하십시오.
테스트 케이스 14 – 오류 메시지에 올바른 레이블이 사용되었는지 확인하십시오.
테스트 케이스 15 – 단일 라디오 버튼이 항상 기본적으로 선택되어 있는지 확인하십시오.
테스트 케이스 16 - 점프하는 동안 TAB 버튼이 제대로 작동하는지 확인하십시오.ping 이전 필드 옆의 다른 필드에.
테스트 케이스 17 – 모든 페이지에 올바른 제목이 포함되어 있는지 확인하십시오.
테스트 케이스 18 – 페이지 텍스트가 올바르게 정렬되었는지 확인하십시오.
테스트 케이스 19 – 필드를 업데이트한 후에는 적절한 확인 메시지가 표시되는지 확인하십시오.
테스트 케이스 20 – 라디오 버튼은 하나만 선택해야 하며, 체크박스는 두 개 이상 선택할 수 있는지 확인하십시오.
GUI 테스트의 과제
해당 사례를 작성하는 것은 간단합니다.ping 여러 릴리스에 걸쳐 그것들이 살아남는다는 것은 불가능합니다. 소프트웨어 엔지니어링에서 가장 흔한 문제는 다음과 같습니다. Regression Testing 애플리케이션 GUI가 자주 변경된다는 점입니다. 문제인지 개선 사항인지 테스트하고 식별하는 것은 매우 어렵습니다. GUI 변경에 관한 문서가 없을 때 문제가 나타납니다.
⚠️ 경고: 화면 좌표나 자동 생성된 ID를 사용하여 요소를 찾는 스크립트는 다음 빌드에서 실패합니다. 요소 위치 지정 전략은 설계 단계부터 고려해야 하며, 나중에 추가하는 부가적인 요소로 생각해서는 안 됩니다.
GUI 테스트 도구
적절한 도구를 사용하면 그러한 변동성을 상당 부분 흡수할 수 있습니다. 다음은 인기 있는 도구 목록입니다. GUI 테스트 도구 :
- Selenium
- QTP
- Cucumber
- 실크테스트
- TestComplete
- 스퀴시 GUI 테스터
배우려면 여기를 클릭하십시오 Selenium, QTP & Cucumber.
자동화된 UI 테스트를 실시하는 데 사용할 수 있는 오픈 소스 도구는 다음과 같습니다.
| 프로덕트 | 라이센스 |
|---|---|
| AutoHotkey | GPL |
| Selenium | 아파치 |
| Sikuli | MIT |
| 로봇 프레임 워크 | 아파치 |
| 물 | BSD |
| Dojo 툴킷 | BSD |
Sikuli 이미지 기반이며, 컨트롤에 신뢰할 수 있는 위치 정보가 없을 때 유용합니다. Selenium 기본값으로 유지됩니다. 웹 애플리케이션 테스트.






