본문 바로가기
개발/정보처리기사

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

by hamcheeseburger 2021. 10. 4.

애플리케이션 테스트

1. 애플리케이션 테스트

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

 

2. 애플리케이션 테스트 기본 원리

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

- 파레토 법칙 : 애플리케이션의 80%의 결함은 20%에 해당하는 코드에서 발생

- 살충제 패러독스 : 동일한 테스트 케이스로 동일한 테스트를 반복하는 것은 결함을 발견할 수 없음

- 테스팅은 정황에 의존 : 정황에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 진행해야 함

- 오류-부재의 궤변 : 아무리 결함이 적다고 해도 사용자의 요구사항을 만족하지 못한다면 해당 소프트웨어는 품질이 높다고 말할 수 없음

- 테스트와 위험은 반비례

- 테스트의 점진적 확대

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

 


애플리케이션 테스트의 분류

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

- 정적 테스트

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

- 동적 테스트

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

 

2. 테스트 기반에 따른 테스트

- 명세 기반 테스트

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

- 구조 기반 테스트

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

- 경험 기반 테스트

  : 테스터의 경험을 기반으로 하는 테스트

 

3. 시각에 따른 테스트

- 검증 테스트

  : 개발자의 시각에서 제품의 생산 과정을 테스트 하는 것 (제품이 명세대로 완성됐는지)

- 확인 테스트

  : 사용자의 시각에서 생산된 제품의 결과를 테스트 하는 것 (사용자가 요구한 대로 완성됐는지)

 

4. 목적에 따른 테스트

- 회복 테스트

  : 시스템에 여러 가지 결함을 준 후 올바르게 복구를 하는지 확인하는 테스트

- 안전 테스트

  : 시스템이 불법적인 침입으로 부터 안전하게 보호할 수 있는지 확인하는 테스트

- 강도 테스트

  : 과도한 정보량, 과부하를 부여함에도 시스템이 정상적으로 실행되는지 확인하는 테스트

- 성능 테스트

  : 실시간 성능이나 효율성을 확인하는 테스트

- 구조 테스트

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

- 회귀 테스트

  : 애플리케이션 변경 시에 새로운 결함이 없음을 확인하는 테스트

- 병행 테스트

  : 변경된 소프트웨어와 변경 전 소프트웨어에 동일한 입력값을 넣었을 때 동일한 결과가 나오는지 확인하는 테스트

 


테스트 기법에 따른 애플리케이션 테스트

1. 화이트박스 테스트

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

투명한 박스라는 의미로 모듈 내의 내용을 볼 수 있어서 내부의 논리적인 경로를 테스트한다고 생각하면 됨.

 

(1) 종류

- 기초 경로 검사

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

 

- 제어 구조 검사

  • 조건 검사 : 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법
  • 루프 검사 : 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
  • 데이터 흐름 검사 : 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

 

(2) 검증 기준

- 문장 검증 기준 : 모든 구문이 한 번씩 실행되도록

- 분기 검증 기준 : 모든 조건문이 한 번 이상 수행되도록

- 조건 검증 기준 : 모든 조건문에 대해 조건이 True인 경우, False인 경우가 한 번 이상 수행되도록

- 분기/조건 기준 : 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우, False인 경우가 한 번 이상 수행되도록

 

2. 블랙박스 테스트

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

어떤 일이 일어나는지는 알 수 없으나 입력된 데이터의 결과물이 올바르게 반환되는지 확인하는 것.

 

(1) 종류

- 동치 분할 검사(동치 클래스 분해)

: 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 그에 맞는 결과가 출력되는지 확인하는 방법

 

- 경계값 분석

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

 

- 원인-효과 그래프 검사

: 입력 데이터 간의 관계와 출력에 영향을 미치는 상황 분석하여 효용성이 높은 테스트 케이스를 선정

 

- 오류 예측 검사

: 과거의 경험이나 감각으로 테스트 하는 방법

 

- 비교 검사

: 여러 버전의 프로그램에 동일한 테스트 자료를 입력하여 동일한 결과가 나오는지 테스트 하는 방법

 


개발 단계에 따른 애플리케이션 테스트

소프트웨어 개발 단계와 애플리케이션 테스트 단계를 연결하여 표현한 것을 V-모델 이라고 함

 

1. 위 테스트

: 최소 단위인 모듈이나 컴포넌트 단위로 테스트 하는 것

 

2. 합 테스트

: 단위 테스트가 완료된 모듈을 결합하여 하나의 시스템으로 테스트 하는 것

 

(1) 방식

- 비점진식 통합 방식

: 단계적으로 통합하는 절차 없이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법

- 점진식 통합 방식

: 모듈 단위로 단계적으로 통합하면서 테스트하는 방식

 

(2) 종류

- 하향식 통합 테스트

: 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트 하는 방법. 스텁 사용.

- 상향식 통합 테스트

: 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트 하는 방법.

하위 모듈을 클러스터로 결합하고 상위 모듈에서 데이터 입출력을 확인하기 위해 더미 모듈인 드라이버를 작성한다.

- 혼합식 통합 테스트

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

- 회귀 테스팅

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

3. 스템 테스트

: 개발된 소프트웨어완벽하게 수행되는지 테스트 하는 것

 

4. 수 테스트

: 개발된 소프트웨어가 사용자의 요구사항을 충족하는지 테스트 하는 것

(1) 종류

- 사용자 인수 테스트

: 사용자가 시스템 사용의 적절성 여부 판단

- 운영상의 인수 테스트

: 시스템 관리자가 시스템 인수 시 수행하는 테스트 기법

- 계약 인수 테스트

: 계약 상의 인수/검수 조건을 조건하는지 테스트

- 규정 인수 테스트

: 지침, 법규, 규정에 맞게 개발되었는지 확인

- 알파 테스트

: 개발자의 장소에서 사용자가 개발자 앞에서 수행하는 테스트

- 베타 테스트

: 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트

 


애플리케이션 테스트 프로세스

1. 애플리케이션 테스트 프로세스

: 개발된 소프트웨어가 사용자의 요구에 맞게 만들어졌는지, 결함은 없는지 테스트 하는 절차

 

테스트 계획 -> 테스트 분석 및 디자인 -> 테스트 케이스 및 시나리오 작성 -> 테스트 수행 -> 테스트 결과 평가 및 리포팅 -> 결함 추적 및 관리

 

2. 결함 관리 프로세스

에러 관리 -> 에러 등록 -> 에러 분석 -> 결함 확정 -> 결함 할당 -> 결함 조치 -> 결함 조치 검토 및 승인

 


테스트 케이스, 테스트 시나리오, 테스트 오라클

1. 테스트 케이스

: 사용자의 요구사항을 정확하게 준수했는지 확인하기 위해 설계된 입력 값, 조건 등으로 구성된 테스트 항목에 대한 명세서

 

2. 테스트 시나리오

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

 

3. 테스트 오라클

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

 

(1) 특징

- 제한된 검증

: 테스트 오라클을 모든 테스트 케이스에 적용할 수 없음

- 수학적 기법

: 테스트 오라클을 수학적 기법을 이용해 표현할 수 있음

- 자동화 가능

: 자동화할 수 있음

 

(2) 종류

- 참 오라클

: 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공

- 샘플링 오라클

: 몇몇 테스트 케이스에 대한 입력 값들에 대해서만 기대하는 결과를 제공

- 휴리스틱(추정) 오라클

: 몇몇 테스트 케이스에 대한 입력 값들에 대해서만 기대하는 결과를 주고 나머지 입력 값들에 대해서는 추정으로 처리

- 일관성 검사 오라클

: 애플리케이션에 변경이 있을 때 테스트 케이스의 수행 전과 수행 후의 결과 값이 동일한지를 확인

 


테스트 자동화 도구

1. 정적 분석 도구

: 프로그램을 실행하지 않고 분석하는 도구

 

2. 테스트 실행 도구

: 스크립트 언어를 사용하여 테스트를 실행하는 도구

- 데이터 주도 접근 방식

- 키워드 주도 접근 방식

 

3. 성능 테스트 도구

: 애플리케이션 처리량, 응답 시간, 경과 시간, 자원 사용률을 인위적으로 적용한 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인하는 도구

 

4. 테스트 통제 도구

: 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구

 

5. 테스트 하네스 도구

: 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구

 

(1) 구성요소

- 테스트 드라이버

: 테스트 대상의 하위 모듈 호출, 파라미터 전달, 테스트 수행 후의 결과를 도출하는 도구

- 테스트 스텁

: 제어 모듈이 타 모듈의 기능을 단순히 수행하는 도구

- 테스트 슈트

: 테스트 케이스의 집합

- 테스트 케이스

: 입력 값, 실행 조건 등으로 만들어진 테스트 항목의 명세서

- 테스트 스크립트

: 테스트 실행 절차에 대한 명세서

- 목 오브젝트

: 사용자 행위를 조건부로 입력해두면 그 상황에 맞는 예정된 행위를 수행하는 객체


결함 관리

1. 결함

소프트웨어 개발자가 설계한 의도와 다르게 동작하거나 다른 결과 값이 반환되는 경우

 

결함 관리 계획 -> 결함 기록 -> 결함 검토 -> 결함 수정 -> 결함 재확인 -> 결함 상태 추적 및 모니터링 활동 -> 최종 결함 분석 및 보고서 작성

 

2. 결함 상태 추적

- 결함 분포

: 특정 속성에 해당하는 결함 수 측정

- 결함 추세

: 테스트 진행 시간에 따른 결함 수 추이 분석

- 결함 에이징

: 결함 상태로 지속되는 시간 측정


애플리케이션 성능 분석

1. 애플리케이션 성능

: 최소한의 자원을 사용하여 최대한 많은 기능을 빠르게 처리하는 정도

 

(1) 성능 지표

- 처리량

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

- 응답 시간

: 애플리케이션에 요청을 했을 때 응답이 도착할 때까지 걸린 시간

- 경과 시간

: 특정 작업을 의뢰하고 처리가 완료될 때 까지 걸린 시간

- 자원 사용률

: 작업을 처리할 때의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등의 자원 사용률

 

(2) 테스트 도구

- 성능 테스트 도구

- 시스템 모니터링 도구


복잡도

소프트웨어의 복잡한 정도를 나타내는 말

1. 시간 복잡도

알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 나타내는 것

 

(1) 종류

- 빅오 표기법

: 실행시간이 최악인 경우를 나타냄

- 세타 표기법

: 실행시간의 평균을 나타냄

- 오메가 표기법

: 실행시간의 최상일 때를 나타냄

2. 순환 복잡도 (멕케이브 순환도)

논리적인 복잡도를 측정하기 위한 소프트웨어의 척도

순환 복잡도 = 화살표 수 - 노드 수 + 2


애플리케이션 성능 개선

1. 소스 코드 최적화

나쁜 코드는 배제하고 클린 코드로 작성하는 것

- 클린 코드 : 누구나 쉽게 이해할 수 있고 수정 및 추가할 수 있는 단순 명료한 코드

- 나쁜 코드 : 로직이 복잡하고 이해하기 어려운 코드

 

(1) 유형

- 클래스 분할 배치

: 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이기

- 느슨한 결합

: 추상화된 자료 구조와 메소드를 구현하여 클래스 간의 의존성 최소

2. 클린 코드 작성 원칙

- 가독성

: 이해하기 쉬운 용어, 들여쓰기 사용

- 단순성

: 한 번에 한 가지를 처리하도록

- 의존성 배제

: 코드가 다른 모듈에 미치는 영향을 최소화함

- 중복성 최소화

- 추상화

: 상위 클래스에서는 간략하게 특성을 나타내고 하위 클래스에서 구체적으로 구현함

 

3. 소스 코드 품질 분석 도구

코딩 스타일, 코드 복잡도, 메모리 누수, 결함 등을 발견하기 위한 분석 도구

- 정적 분석 도구

: 코드를 실행하지 않고 코딩 스타일, 결함 등을 분석하는 도구

pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura

- 동적 분석 도구

: 코드를 실행하여 메모리 누수, 스레드 결함 등을 분석하는 도구

Avalanche, Valgrind

'개발 > 정보처리기사' 카테고리의 다른 글

9장 소프트웨어 개발 보안 구축  (0) 2021.10.10
8장 SQL 응용  (0) 2021.10.09
10장 프로그래밍 언어 활용  (0) 2021.10.07
2장 데이터 입출력 구현  (0) 2021.10.04
6장 화면설계  (0) 2021.10.04

이전 댓글