GUI 기반 시스템 테스팅 기본 정리

GUI(Graphical User Interface)

• 계층 구조의 그래픽한 소프트웨어 시스템 프론트 엔드이며 사용자와 상호작용하는 수단으로 사용된다(오늘날 거의 모든 유형의 시스템과 기기에서 GUI를 찾아 볼 수 있음)
• GUI에는 위젯(widget)이라 불리는 그래픽 오브젝트가 포함되며, 각 위젯은 런타임에서 특정 값을 가지는 속성(properties)들의 집합으로 구성된다.
• 실행 중 각 위젯의 속성들의 값이 GUI 상태를 정의하며, 그래픽 이벤트(graphical events)는 GUI를 한 상태에서 다음 상태로 전환하는 상태 변환기(a state transducer) 역할을 한다.
• GUI는 메쏘드 호출 또는 메시지를 통하여 기반 코드(the underlying code)와 상호작용하며 원격 코드(remote code)의 실행도 가능하다.
• GUI는 사용자 이벤트(예, 마우스 클릭)에 반응하는 이벤트 기반 시스템(event-driven systems)이다.
• GUI의 정확성을 테스팅 하는 것은 시스템의 사용성(usability), 견고성(robustness), 안전성(safety) 측면에서 매우 중요하다.

GUI 테스팅

• 제품의 그래픽 사용자 인터페이스(graphical user interface)가 명세에 부합하는지 확인하는 테스팅 프로세스
• GUI 컴포넌트를 인식/식별하고, GUI 이벤트를 실행하고, GUI 컴포넌트에 입력을 제공하고, GUI 컴포넌트들이 지원하는 시스템 기능을 테스트하고, GUI 표현이 일관적인지를 체크하는 테스트 케이스가 요구됨 

GUI 테스팅의 어려운 점

• 도메인 규모 문제(The domain size problem): CLI(command line interface) 시스템과 달리 GUI 시스템은 테스트가 필요한 오퍼레이션 수가 너무 많다. 예를 들어 마이크로소프트 워드패드(WordPad) 같은 작은 프로그램도 가능한 GUI 오퍼레이션의 수가 325개나 된다. 이 문제는 더 나아가 GUI의 가능한 상태가 지나치게 많은 ‘UI 상태 폭발 문제(UI state explosion problem)’로 이어진다.
• 시퀀싱 문제(the sequencing problem): 시스템의 일부 기능은 반드시 GUI 이벤트의 특정 순서대로 수행되어야만 한다. 가능한 오퍼레이션 수가 증가하면 이 시퀀싱 문제도 기하급수적으로 증가하게 되며 수작업으로 테스트 케이스 생성 시 심각한 문제가 된다.
• 회귀 테스팅(Regression testing): GUI는 회귀 테스팅에서도 문제가 된다. 애플리케이션 버전마다 GUI가 크게 변할 수 있기 때문에 GUI의 특정 경로를 따르도록 설계된 테스트가 GUI(버튼, 메뉴 항목, 다이얼로그 등)의 위치나 모양이 변하면 더 이상 제대로 동작하지 않을 수 있다. 이 특성은 GUI의 외관에 의존하는 ‘capture and play’ 방식의 자동화를 어렵게 만드는 요인이기도 하다.
• 동일 윈도우 또는 서로 다른 윈도우에 놓인 오브젝트들간의 숨은 동기화(synchronization)나 의존관계(dependencies). 예) 윈도우에서 특정 체크박스가 참으로 설정되면 입력 값을 받기로 된 다른 텍스트박스가 비활성화되거나 보이지 않게 됨

GUI 관련 에러의 예

• 부정확한 기능 동작(Incorrect functioning)
• GUI 이벤트 같은 명령문 실종(Missing commands)
• 부정확한 GUI 스크린샷/상태(Incorrect GUI screenshots/states)
• 텍스트 필드나 버튼 같은 필수 UI 컴포넌트의 부재(The absence of mandatory UI components)
• 필드 또는 UI 오브젝트의 부정확한 디폴트 값(Incorrect default values for fields or UI objects)
• 데이터 검증 에러(Data validation errors)
• 사용자에게 부정확한 메시지 또는 에러 메시지 전달
• 의도에 맞지 않는 잘못된 UI 구축(Wrong UI construction)

사용자 인터페이스 테스팅 체크리스트

사용자 인터페이스 자체의 오퍼레이션과 기능을 확인하는 사용자 인터페이스(UI) 테스팅의 점검 항목으로 아래와 같은 것들이 있다. 

• 윈도우가 ‘모달(modal)’인가 아니면 ‘모달리스(modaless)’인가? 어느 쪽이어야 하는가?
• 필수 입력 필드와 선택 입력 필드 간의 시각적인 구별이 되어 있는가?
• 누락된 필드가 존재하지는 않는가?
• 제목, 레이블, 프롬프트명 등에 철자 오류가 있는가?
• 모든 대화 상자(dialog boxes)에서 명령 버튼(예, 확인, 취소, 저장, 지우기 등)이 일관성 있게 사용되었는가?
• 현재 하고 있는 작업(삭제 작업 포함)을 중단하는게 항상 가능한가?
• 모든 정적 필드가 사용자에 의한 편집으로부터 보호되어 있는가? 만일 애플리케이션이 정적 텍스트를 변경할 수 있는 경우라면, 이것이 정확하게 수행되고 있는가?
• 편집 상자(edit boxes)의 크기가 그것이 취할 수 있는 값의 범위와 일치하는가?
• 편집 상자에 입력되는 값의 유효성이 클라이언트 프로그램에 의해 검사되는가?
• 드롭 다운 목록(drop-down lists)이 데이터베이스로부터 받아온 정확한 값들로 채워지는가?