[정보처리기사] 실기 7장 애플리케이션 테스트 관리
애플리케이션 테스트
- 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차이다.
- 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인(Validation)하고 소프트웨어가 기능을 정확히 수행하는지 검증(Verification)한다.
- 애플리케이션 테스트의 기본 원리
- 완벽한 테스트 불가능: 소프트웨어의 잠재적인 결함을 줄일 수 있지만 소프트웨어에 결함이 없다고 증명할 수는 없음
- 파레토 법칙: 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙
- 살충제 패러독스: 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상
- 테스팅은 정황: 소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 함
- 오류-부재의 궤변: 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없는 것
- 테스트와 위험은 반비례: 테스트를 많이 하면 할수록 미래에 발생할 위험을 줄일 수 있음
- 테스트의 점진적 확대: 테스트는 작은 부분에서 시작하여 점점 확대하며 진행해야 함
- 테스트의 별도 팀 수행: 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함
애플리케이션 테스트의 분류
프로그램 실행 여부에 따른 테스트
- 정적 테스트: 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트
- 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트
화이트박스 테스트
- 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법이다.
- 원시 코드의 모든 문장을 한 번 이상 실행함으로써 수행된다.
- 화이트박스 테스트의 종류
- 기초 경로 검사: 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
- 제어 구조 검사
- 조건 검사: 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법
- 루프 검사: 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
- 데이터 흐름 검사: 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
- 화이트박스 테스트의 검증 기준
- 문장 검증 기준: 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계함
- 분기 검증 기준: 소스 코드의 모든 조건문에 대해 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계함
- 조건 검증 기준: 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계함
- 분기/조건 기준: 분기 검증 기준과 조건 검증 기준을 모두 만족하는 설계로, 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스를 설계함
블랙박스 테스트
- 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트로, 기능 테스트라고도 한다.
- 사용자의 요구사항 명세를 보면서 테스트하며, 주로 구현된 기능을 테스트한다.
- 블랙박스 테스트의 종류
- 동치 분할 검사: 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 기법
- 경계값 분석: 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법
- 원인-효과 그래프 검사: 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
- 오류 예측 검사: 과거의 경험이나 확인자의 감각으로 테스트하는 기법
- 비교 검사: 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법
테스트 기반에 따른 테스트
- 명세 기반 테스트: 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트
- 구조 기반 테스트: 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
- 경험 기반 테스트: 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트
시각에 따른 테스트
- 확인(Validation) 테스트: 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것으로, 사용자가 요구한대로 제품이 완성됐는지, 제품이 정상적으로 동작하는지를 테스트함
- 검증(Verification) 테스트: 개발자의 시각에서 제품의 생산 과정을 테스트하는 것으로, 제품이 명세서대로 완성됐는지를 테스트함
목적에 따른 테스트
- 회복 테스트: 시스템에 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트
- 안전 테스트: 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트
- 강도 테스트: 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지를 확인하는 테스트
- 성능 테스트: 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트로, 소프트웨어의 응답 시간, 처리량 등을 테스트
- 구조 테스트: 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트
- 회귀 테스트: 소프트웨어 변경 또는 수정된 코드에 새로운 결함이 없을음 확인하는 테스트
- 병행 테스트: 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트
개발 단계에 따른 애플리케이션 테스트
- 소프트웨어의 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 분류된다. 이렇게 분류된 것을 테스트 레벨이라고 한다.
- 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것을 V-모델이라고 한다.
단위 테스트(Unit Test)
- 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것이다.
- 인터페이스, 외부적 I/O, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등을 검사한다.
통합 테스트(Integration Test)
- 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트를 의미한다.
- 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류를 검사한다.
- 종류
- 비점진적 통합 방식: 단계적으로 톨합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법
- 점진적 통합 방식: 모듈 단위로 단계적으로 통합하면서 테스트하는 방법
- 종류: 하향식 통합 테스트, 상향식 통합 테스트, 혼합식 통합 테스트
하향식 통합 테스트
- 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법이다.
- 하향식 통합 테스트 절차
- 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁(Stub)으로 대체한다.
- 깊이 우선 또는 너비 우선 등의 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체된다.
- 모듈이 통합될 때마다 테스트를 실시한다.
- 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트를 실시한다.
상향식 통합 테스트
- 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법이다.
- 상향식 통합 테스트 절차
- 하위 모듈들을 클러스터(Cluster)로 결합한다.
- 상위 모듈에서 데이터의 입출력을 확인하기 위해 더미 모듈인 드라이버(Driver)를 작성한다.
- 통합된 클러스터 단위로 테스트한다.
- 테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합하고 드라이버는 실제 모듈로 대체된다.
시스템 테스트(System Test)
- 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트이다.
- 기능적 요구사항과 비기능적 요구사항으로 구분하여 각각을 만족하는지 테스트한다.
인수 테스트(Acceptance Test)
- 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트하는 방법이다.
- 개발한 소프트웨어를 사용자가 직접 테스트한다.
- 인수 테스트의 종류
- 사용자 인수 테스트: 사용자가 시스템 사용의 적절성 여부를 확인함
- 운영상의 인수 테스트: 시스템 관리자가 시스템 인수 시 수행하는 테스트 기법
- 계약 인수 테스트: 계약상의 인수/검수 조건을 준수하는지 여부를 확인함
- 규정 인수 테스트: 소프트웨어가 정부 지침, 법규, 규정 등 규정에 맞게 개발되었는지 확인함
- 알파 테스트: 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법
- 베타 테스트: 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법
복잡도
- 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말이다.
- 시스템 또는 소프트웨어를 어느 정도의 수준까지 테스트해야 하는지 또는 개발하는 데 어느 정도의 자원이 소요되는지 예측하는데 사용된다.
시간 복잡도
- 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화한 것을 의미한다.
- 시간 복잡도가 낮을수록 알고리즘의 실행시간이 짧고, 높을수록 실행시간이 길어진다.
- 점근 표기법의 종류
- 빅오 표기법(Big-O Notation): 알고리즘의 실행시간이 최악일 때를 표기하는 방법
- 세타 표기법(Big-θ Notation): 알고리즘의 실행시간이 평균일 때를 표기하는 방법
- 오메가 표기법(Big-Ω Notation): 알고리즘의 실행시간이 최상일 때를 표기하는 방법
순환 복잡도
- 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도이다.
- 맥케이브 순환도 또는 맥케이브 복잡도 메트릭라고도 한다.
- 제어 흐름도 이론에 기초를 둔다.
소스 코드 최적화
- 나쁜 코드(Bad Code)를 배제하고, 클린 코드(Clean Code)로 작성하는 것이다.
- 클린 코드(Clean Code): 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드, 즉 잘 작성된 코드
- 나쁜 코드(Bad Code): 프로그램의 로직이 복잡하고 이해하기 어려운 코드
클린 코드 작성 원칙
- 가독성: 누구든지 코드를 쉽게 읽을 수 있도록 작성함
- 단순성: 코드를 간단하게 작성함
- 의존성 배제: 코드가 다른 모듈에 미치는 영향을 최소화함
- 중복성 최소화: 코드의 중복을 최소화함
- 추상화: 상위 클래스/메소드/함수에서는 간략하게 애플리케이션의 특성을 나타내고, 상세 내용은 하위 클래스/메소드/함수에서 구현함
소스 코드 품질 분석 도구
- 소스 코드의 코딩 스타일, 코드에 설정된 코딩 표준, 코드의 복잡도, 코드에 존재하는 메모리 누수 현상, 스레드 결함 등을 발견하기 위해 사용하는 분석 도구이다.
- 정적 분석 도구와 동적 분석 도구로 나뉜다.
- 정적 분석 도구: 작성한 소스 코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인하는 코드 분석 도구
- 종류: pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura 등
- 동적 분석 도구: 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구
- 종류: Avalanche, Valgrind 등