[2020 정보처리기사 필기] 애플리케이션 테스트 관리 (1)

49. 애플리케이션 테스트 ★★

1. 애플리케이션 테스트의 개념

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

- 고객의 요구사항을 만족시키는지 확인(Validation)하고 소프트웨어가 기능을 정확히 수행하는지 검증(Verification)한다.

- 애플리케이션 테스트를 진행하기 전에 개발한 소프트웨어의 유형을 분류하고 특성을 정리해서 중점적으로 테스트할 사항을 정리해야 한다.

- Validation : 사용자의 입장에서 개발한 소프트웨어가 고객의 요구사항에 맞게 구현되었는지를 확인하는 것

- Verification : 개발자의 입장에서 개발한 소프트웨어가 명세서에 맞게 만들어졌는지를 점검하는 것

 

2. 애플리케이션 테스트의 필요성

- 프로그램 실행 전에 오류를 발견하여 예방할 수 있다.

 

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

- 소프트웨어의 잠재적인 결함은 줄일 수 있지만 결함이 아예 없다고 증명할 수는 없다. 즉 완벽한 소프트웨어 테스팅을 불가능하다.

- 결함은 대부분 특정 모듈에 집중되어 있다. 애플리케이션의 20%에 해당하는 코드에서 전체 80%의 결함이 발견된다고 하여 파레토 법칙을 적용하기도 한다.

- 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 '살충제 패러독스' 현상이 발생한다. 살충제 패러독스를 방지하기 위해 테스트 케이스를 지속적으로 보완 및 개선해야 한다.

- 정황(Context)에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수정해야 한다.

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

- 테스트와 위험은 반비례한다. 테스트를 많이 할수록 미래에 발생할 위험을 줄일 수 있다.

- 테스트는 작은 부분에서 큰 부분으로 진행해야 한다.

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

 

핵심

- Validation : 사용자 입장에서 고객의 요구사항에 맞게 구현되었는지 확인하는 것

- Verification : 개발자 입장에서 개발한 소프트웨어가 명세서에 맞게 만들어졌는지 점검하는 것

- 애플리케이션 테스트는 프로그램 실행 전에 코드 리뷰, 인스펙션 등을 통해 사전에 오류를 발견하여 예방할 수 있다.

- 테스팅은 프로그램 개발 초기부터 계획하고 시작해야 오류 발견뿐만 아니라 새로운 오류의 유입도 예방할 수 있다.

- 테스트는 작은 부분에서 큰 부분으로 점점 확대하면서 진행한다.

---

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

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

- 애플리케이션을 테스트 할 때 프로그램의 실행 여부에 따라 정적 테스트와 동적 테스트로 나뉜다.

- 정적 테스트

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

       - 소프트웨어 개발 초기에 결함을 발견할 수 있어 소프트웨어의 개발 비용을 낮추는데 도움이 된다.

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

- 동적 테스트

       - 프로그램을 실행하여 오류를 찾는 테스트로, 소프트웨어 개발의 모든 단계에서 테스트를 수행할 수 있다.

       - 블랙박스 테스트, 화이트박스 테스트

 

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

- 애플리케이션을 테스트할 때 무엇을 기반으로 수행하느냐에 따라 명세 기반, 구조 기반, 경험 기반 테스트로 나뉜다.

- 명세 기반 테스트

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

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

- 구조 기반 테스트 

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

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

- 경험 기반 테스트

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

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

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

 

3. 시각에 따른 테스트

- 애플리케이션을 테스트 할 때 누구를 기준으로 하느냐에 따라 검증(Verification) 테스트와 확인(Validation) 테스트로 나뉜다.

- 검증(Verification) 테스트 : 개발자의 시각에서 제품의 생산 과정을 테스트하는 것으로, 제품이 명세서대로 완성됐는지를 테스트한다.

- 확인(Validation) 테스트 : 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것으로, 사용자가 요구한대로 제품이 완성됐는지, 제품이 정상적으로 동작하는지를 테스트한다.

 

4. 목적에 따른 테스트

- 애플리케이션을 테스트 할 때 무엇을 목적으로 테스트를 진행하느냐에 따라 회복, 안전, 강도, 성능, 구조, 회귀, 병행 테스트로 나뉜다.

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

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

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

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

- 구조(Structure) 테스트 : 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트이다.

- 회귀(Regression) 테스트 : 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트이다.

- 병행(Parallel) 테스트 : 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트이다.

 

핵심

- 정적 테스트 : 워크스루, 인스펙션, 코드 검사

- Verification : 개발자의 시각, Validation : 사용자의 시각

- 회귀 테스트 : 수정된 코드에 새로운 결함이 없음을 확인하는 테스트

---

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

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

- 화이트박스 테스트는 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법이다.

- 화이트박스 테스트는 설계된 절차에 초점을 둔 구조적 테스트로 프로시저 설계의 제어 구조를 사용하여 테스트 케이스를 설계하며, 테스트 과정의 초기에 적용된다.

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

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

- 프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행함으로써 논리적 경로를 제어한다.

 

2. 화이트박스 테스트의 종류

- 기초 경로 검사

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

       - 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법으로, 테스트 측정 결과는 실행 경로의 기초를 정의하는 데 지침으로 사용된다.

- 제어 구조 검사

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

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

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

 

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

- 문장 검증 기준 : 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계

- 분기 검증 기준 : 소스 코드의 모든 조건문이 한 번 이상 수행되도록 테스트 케이스 설계

- 조건 검증 기준 : 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계

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

 

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

- 블랙박스 테스트는 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트로, 기능 테스트라고도 한다.

- 사용자의 요구사항 명세를 보면서 테스트하는 것으로, 주로 구현된 기능을 테스트한다.

- 소프트웨어 인터페이스에서 실시되는 테스트이다.

- 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류 등을 발견하기 위해 사용되며, 테스트 과정의 후반부에 적용된다.

 

5. 블랙박스 테스트의 종류

- 동치 분할 검사

       - 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사하는 방법

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

- 경계값 분석

       - 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법

- 원인-효과 그래프 검사

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

- 오류 예측 검사

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

       - 다른 블랙 박스 테스트 기법으로는 찾아낼 수 없는 오류를 찾아내는 일련의 보충적 검사 기법이며, 데이터 확인 검사라고도 한다.

- 비교 검사

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

 

핵심

- 논리적인 경로나 데이터 흐름과 관련된 기법은 화이트박스 테스트 기법이고, 기능과 관련된 기법은 블랙박스 테스트 기법이다.

- 화이트박스 테스트 : 기초 경로 검사, 제어 구조 검사

- 블랙박스 테스트 : 동치 분할 검사, 경계값 분석, 원인-효과 그래프 검사, 오류 예측 검사, 비교 검사

---

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

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

- 소프트웨어의 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 분류된다. 이렇게 분류된 것을 테스트 레벨이라고 한다.

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

 

2. 단위 테스트(Unit Test)

- 코딩 직후 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것이다.

- 인터페이스, 외부적 I/O, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등을 검사한다.

- 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 수행한다.

- 구조 기반 테스트와 명세 기반 테스트로 나뉘지만 주로 구조 기반 테스트를 시행한다.

- 구조 기반 테스트 : 프로그램 내부 구조 및 복잡도를 검증하는 화이트박스 테스트 시행, 제어 흐름과 조건 결정 등이 목적이다.

- 명세 기반 테스트 : 목적 및 실행 코드 기반의 블랙박스 테스트 시행, 동등 분할, 경계 값 분석 등이 목적이다.

 

3. 통합 테스트(Integration Test)

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

- 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류를 검사한다.

 

4. 시스템 테스트(System Test)

- 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트이다.

- 환경적인 장애 리스크를 최소화하기 위해서는 실제 사용 환경과 유사하게 만든 테스트 환경에서 테스트를 수행해야 한다.

- 시스템 테스트는 기능적 요구사항과 비기능적 요구사항으로 구분하여 각각을 만족하는지 테스트한다.

- 기능적 요구사항 :명세서 기반의 블랙박스테스트 시행

- 비기능적 요구사항 : 구조적 요소에 대한 화이트박스테스트 시행

 

5. 인수 테스트(Acceptance Test)

- 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트하는 방법

- 인수 테스트는 개발한 소프트웨어를 사용자가 직접 테스트한다.

- 문제가 없으면 사용자는 소프트웨어를 인수하게 되고, 프로젝트는 종료된다.

- 인수 테스트는 다음과 같이 6가지의 종류로 구분해서 테스트한다.

- 사용자 인수 테스트 : 사용자가 시스템 사용의 적절성 여부를 확인한다.

- 운영상의 인수 테스트 : 시스템 관리자가 시스템 인수 시 수행하는 테스트 기법으로, 백업, 정기 점검 등을 확인한다.

- 계약 인수 테스트 : 계약상의 인수/검수 조건을 준수하는지 여부를 확인한다.

- 규정 인수 테스트 : 소프트웨어가 정부 지침, 법규 등 규정에 맞게 개발되었는지 확인한다.

- 알파 테스트 : 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법이다, 통제된 환경에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 기록한다.

- 베타 테스트 : 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법이다, 개발자에 의해 제어되지 않은 상태에서 테스트가 행해지며, 발견된 오류와 사용상의 문제점을 기록하고 개발자에게 주기적으로 보고한다.

 

핵심

- 단위 테스트 -> 통합 테스트 -> 시스템 테스트 -> 인수 테스트

- 알파 테스트는 선택된 사용자가 개발자 앞에서 검사, 베타 테스트는 선정된 최종 사용자가 여러 명의 사용자 앞에서 검사

- 알파 테스트는 통제된 환경에서, 베타 테스트는 개발자에 의해 제어되지 않은 상태에서 검사한다.

---

53. 통합 테스트 ★★★

1. 통합 테스트

- 통합 테스트는 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법이다.

- 통합 테스트 방법에는 비점진적 통합 방식과 점진적 통합 방식

- 비점진적 통합 방식

       - 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법으로 빅뱅 통합 테스트 방식이 있다.

       - 규모가 작은 소프트웨어에 유리, 단시간 내에 테스트 가능

       - 전체 프로그램을 대상으로 하기 떄문에 오류 발견이 어렵다.

- 점진적 통합 방식

       - 모듈 단위로 단계적으로 통합하면서 테스트하는 방법으로, 하향식, 상향식, 혼합식 통합 방식이 있다.

       - 오류 수정이 용이하고, 인터페이스와 연관된 오류를 완전히 테스트할 가능성이 높다.

 

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

- 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법

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

- 테스트 초기부터 사용자에게 시스템 구조를 보여줄 수 있다.

- 상위 모듈에서는 테스트 케이스를 사용하기 어렵다.

- 하향식 통합 방법은 다음과 같은 절차로 수행된다.

       - 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁(Stub)으로 대체한다.

       - 깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈과 교체된다.

       - 모듈이 통합될 때마다 테스트 실시

       - 새로운 오류가 발생하지 않음을 보장하기 위해 회귀 테스트를 실시

 

3. 상향식 통합 테스트(Bottop Up Integration Test)

- 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법

- 가장 하위 단계의 모듈부터 통합 및 테스트가 수행되므로 스텁은 필요하지 않지만, 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(Cluster)가 필요하다.

- 상향식 통합 방법은 다음과 같은 절차로 수행된다.

       - 하위 모듈들을 클러스터(Cluster)로 결합한다.

       - 상위 모듈에서 데이터의 입출력을 확인하기 위해 더미 모듈인 드라이버(Driver)를 작성한다.

       - 통합된 클러스터 단위로 테스트

       - 테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합하고 드라이버는 실제 모듈로 대체된다.

 

4. 혼합식 통합 테스트

- 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원하는 방식으로, 샌드위치식 통합 테스트 방법이라고도 한다.

 

5. 회귀 테스팅(Regression Testing)

- 회귀 테스트는 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 오류가 있는지 확인하는 테스트이다.

- 회귀 테스트는 모든 테스트 케이스를 이용해 테스팅하는 것이 가장 좋지만 시간과 비용이 많이 필요하므로 기존 테스트 케이스 중 변경된 부분을 테스트할 수 있는 테스트 케이스만을 선정하여 수행한다.

- 회귀 테스트의 테스트 케이스 선정 방법

       - 대표적이니 테스트 케이스 선정

       - 파급 효과가 높은 부분이 포함된 테스트 케이스 선정

       - 실제 수정이 발생한 모듈 또는 컴포넌트에서 시행하는 테스트 케이스를 선정

 

핵심

- 비점진적 : 빅뱅 통합 테스트 방식

- 점진적 : 하향식, 상향식, 혼합식 통합방식

- 하향식 : 스텁, 회귀테스트

- 상향식 : 클러스터, 드라이버

- 혼합식 : 하위에서는 상향식, 상위에서는 하향식

- 회귀 테스팅 : 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 오류가 있는지 확인하는 테스트

---

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

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

- 개발된 소프트웨어가 사용자의 요구대로 만들어졌는지, 결함은 없는지 등을 테스트하는 절차로, 다음과 같은 순서로 진행된다.

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

- 테스트 계획서 : 테스트 목적, 범위, 일정 등 테스트 수행을 계획한 문서

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

- 테스트 시나리오 : 여러 개의 테스트 케이스의 동작 순서를 기술한 문서

- 테스트 결과서 : 결과를 비교, 분석한 내용을 정리한 문서

 

2. 테스트 계획

- 테스트 계획 단게에서는 프로젝트 계획서, 요구 명세서 등을 기반으로 테스트 목표를 정의하고 테스트 대상 및 범위를 결정한다.

- 테스트 시작 및 종료 조건을 정의한다.

 

3. 테스트 분석 및 디자인

- 테스트의 목적과 원칙을 검토하고 사용자의 요구사항을 분석한다.

- 리스크 분석 및 우선순위 결정

- 테스트 데이터, 테스트 환경, 테스트 도구 등을 준비

 

4. 테스트 케이스 및 시나리오 작성

- 테스트용 스크립트를 작성

 

5. 테스트 수행

- 테스트의 실행 결과를 측정하여 기록한다.

 

6. 테스트 결과 평가 및 리포팅

- 결함 내용 및 결함 재연 순서 등 결함을 중심으로 기록

 

7. 결함 추적 및 관리

- 결함 추적 및 관리를 통해 동일한 결함 발견 시 처리 시간 단축 및 결함의 재발 등을 방지할 수 있다.

- 결함 관리 프로세스 : 에러 발견 -> 에러 등록 -> 에러 분석 -> 결함 확정 -> 결함 할당 -> 결함 조치 -> 결함 조치 검토 및 승인

 

핵심

- 오류는 될 수 있으면 빨리 발견하는 게 좋다.

- 테스트 계획 -> 분석 -> 테스트 케이스 설계 -> 실행 -> 결과 분석

- 테스트를 마치면 산출되는 문서는 테스트 계획서, 테스트 케이스, 테스트 시나리오, 테스트 결과서