[정보처리기사] 실기 정리 - 6. 화면 설계 / 7. 애플리케이션 테스트 관리

6. 화면 설계

사용자 인터페이스(UI, User Interface)

 - 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어

 

사용자 인터페이스의 구분

 1) CLI(Command Line Interface) : 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스

 2) GUI(Graphical User Interface) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스

 3) NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스

 

사용자 인터페이스의 기본 원칙

 1) 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 함

 2) 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야 함

 3) 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 함

 4) 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 함

 

ISO/IEC 9126의 소프트웨어 품질 특성

 1) 기능성(Functionality)

     - 소프트웨어가 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부를 나타냄

 2) 신뢰성(Reliability)

     - 주어진 시간 동안 주어진 기능을 오류 없이 수행할 수 있는 정도를 나타냄

 3) 사용성(Usability)

     - 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 정확하게 이해하고 사용하며, 향후 다시 사용하고 싶은 정도를 나타냄

 4) 효율성(Efficiency)

     - 사용자가 요구하는 기능을 얼마나 빠르게 처리할 수 있는지 정도를 나타냄

 5) 유지보수성(Maintainability)

     - 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도를 나타냄

 6) 이식성(Portability)

     - 소프트웨어가 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도를 나타냄

 

HCI(Human Computer Interaction or Interface)

 - 사람이 시스템을 보다 편리하고 안전하게 사용할 수 있도록 연구하고 개발하는 학문

 

UX(User Experience, 사용자 경험)

 - 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총체적인 경험

 

7. 애플리케이션 테스트 관리

애플리케이션 테스트

 - 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차

 

기본 원리

 1) 완벽한 테스트 불가능 : 소프트웨어의 잠재적인 결함을 줄일 수 있지만 소프트웨어에 결함이 없다고 증명할 수는 없음

 2) 파레토 법칙(Pareto Principle) : 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙

 3) 살충제 패러독스(Pesticide Paradox) : 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상

 4) 테스팅은 정황(Context) 의존 : 소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황(Context)에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 함

 5) 오류-부재의 궤변(Absence of Errors Fallacy) : 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없는 것

 6) 테스트와 위험은 반비례 : 테스트를 많이 하면 할수록 미래에 발생할 위험을 줄일 수 있음

 7) 테스트의 점진적 확대 : 테스트는 작은 부분에서 시작하여 점점 확대하며 진행해야 함

 8) 테스트의 별도 팀 수행 : 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함

 

프로그램 실행 여부에 따른 테스트

 1) 정적 테스트

     - 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트

     - 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도, 남은 결함 등을 발견하기 위해 사용함

     - 종류 : 워크스루, 인스펙션, 코드 검사 등

 

 2) 동적 테스트

     - 프로그램을 실행하여 오류를 찾는 테스트

     - 소프트웨어 개발의 모든 단계에서 테스트를 수행함

     - 종류 : 블랙박스 테스트, 화이트박스 테스트

 

테스트 기반(Test Bases)에 따른 테스트

 1) 명세 기반 테스트

     - 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트

     - 종류 : 동등 분할, 경계 값 분석 등

 2) 구조 기반 테스트

     - 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트

     - 종류 : 구문 기반, 결정 기반, 조건 기반 등

 3) 경험 기반 테스트

     - 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트

     - 사용자의 요구사항에 대한 명세가 불충분하거나 테스트 시간에 제약이 있는 경우 수행하면 효과적임

     - 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅

 

시각에 따른 테스트

 1) 검증(Verfication) 테스트

     - 개발자의 시각에서 제품의 생산 과정을 테스트하는 것

     - 제품이 명세서대로 완성됐는지를 테스트함

 2) 확인(Validation) 테스트

     - 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것

     - 사용자가 요구한대로 제품이 완성됐는지, 제품이 정상적으로 동작하는지를 테스트함

 

목적에 따른 테스트

 1) 회복(Recovery) 테스트

     - 시스템에 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트

 2) 안전(Security) 테스트

     - 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트

 3) 강도(Stress) 테스트

     - 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지를 확인하는 테스트

 4) 성능(Performance) 테스트

     - 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트로, 소프트웨어의 응답 시간, 처리량 등을 테스트

 5) 구조(Structure) 테스트

     - 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트

 6) 회귀(Regression) 테스트

     - 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트

 7) 병행(Parallel) 테스트

     - 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트

 

화이트박스 테스트(White Box Test)

 - 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법

 - 모듈 안의 작동을 직접 관찰한다.

 - 원시 코드(모듈)의 모든 문장을 한 번 이상 실행함으로써 수행된다.

 

화이트박스 테스트의 종류

  1) 기초 경로 검사 (Base Path Testing)

     - 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법

     - 대표적인 화이트박스 테스트 기법

 2) 제어 구조 검사(Control Structure Testing)

     - 조건 검사(Condition Testing) : 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법

     - 루프 검사(Loop Testing) : 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

     - 데이터 흐름 검사(Data Flow Testing) : 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

 

화이트 박스 테스트의 검증 기준

 1) 문장 검증 기준(Statement Coverage)

     - 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계함

 2) 분기 검증 기준(Branch Coverage)

     - 소스 코드의 모든 조건문에 대해 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계함

 3) 조건 검증 기준(Condition Coverage)

     - 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계함

 4) 분기/조건 기준(Branch/Condition Coverage)

     - 분기 검증 기준과 조건 검증 기준을 모두 만족하는 설계로, 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스를 설계함

 

블랙박스 테스트(Black Box Test)

 - 각 기능이 완전히 작동되는 것을 입증하는 테스트

 - 사용자의 요구사항 명세를 보면서 테스트한다..

 

블랙박스 테스트의 종류

 1) 동치 분할 검사(Equivalence Partitioning Test, 동치 클래스 분해)

     - 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 기법

     - 동등 분할 기법이라고도 함

 2) 경계값 분석(Boundary Value Analysis)

     - 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법

 3) 원인-효과 그래프 검사(Cause-Effect Graphing Testing)

     - 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법

 4) 오류 예측 검사(Error Guessing)

     - 과거의 경험이나 확인자의 감각으로 테스트하는 기법

 5) 비교 검사(Comparison Testing)

     - 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법

 

단위 테스트(Unit Test)

     - 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것이다.

 

통합 테스트(Integration Test)

 - 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트

 1) 하향식 통합 테스트(Top Down Integration Test)

     - 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트

     - 깊이 우선 통합법이나 넓이 우선 통합법을 사용

 2) 상향식 통합 테스트(Bottom Up Integration Test)

     - 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트

 3) 혼합식 통합 테스트

     - 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원하는 방식

 4) 회귀 테스팅(Regression Testing)

     - 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트

 

시스템 테스트(System Test)

 - 개발된 소프트웨어가 완벽하게 수행되는가를 점검하는 테스트

 

인수 테스트(Acceptance Test)

 - 사용자의 요구사항을 충족하는지에 중점을 두고 테스트

 

테스트 케이스(Test Case)

 - 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 테스트 항목에 대한 명세서

 

테스트 시나리오(Test Scenario)

 - 테스트 케이스를 적용하는 순서에 따라 여러 갱의 테스트 케이스를 묶은 집합

 

테스트 오라클(Test Oracle)

 - 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법

 - 종류

     1) 참(True) 오라클 : 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클

     2) 샘플링(Sampling) 오라클 : 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클로 전수 테스트가 불가능한 경우 사용

     3) 추정(Heuristic) 오라클 : 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클

     4) 일관성 검사(Consistent) 오라클 : 애플리케이션에 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클

 

애플리케이션 성능 : 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도

 1) 처리량 : 일정 시간 내에 애플리케이션이 처리하는 일의 양

 2) 응답 시간 : 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간

 3) 경과 시간 : 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간

 4) 자원 사용률 : 애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률