2020 정보처리기사 실기 : Chapter 07

Chapter 07 : 애플리케이션 테스트 관리

---

1-1. 응용 소프트웨어 구분

구분	설명
1) 상용 소프트웨어 - 일반인 대상 - 상업적 목적, 판매 목적 - 홍보를 위한 무료	1-1) 산업 범용 소프트웨어 - 임베디드/리얼타임 OS, WAS, 영상 관련 SW 등
	1-2) 산업 특화 소프트웨어 - 자동차, 항공, 조선 분야 등
2) 서비스 제공 소프트웨어 - 특정 사용자 대상 - 판매가 아닌, 요구사항 구현	2-1) 신규 개발 소프트웨어 - 새로운 서비스의 제공을 목적
	2-2) 기능 개선 소프트웨어 - 기존 서비스의 성능 개선을 목적
	2-3) 추가 개발 소프트웨어 - 기존 서비스의 새로운 기능 추가를 목적
	2-4) 시스템 통합 소프트웨어 - 서비스의 통합을 목적

 

 

1-2. 산업 범용 소프트웨어 구분

구분	설명
시스템 소프트웨어	응용 소프트웨어를 실행하기 위한 플랫폼 제공 컴퓨터 하드웨어를 동작, 접근할 수 있도록 설계 예 : OS, DBMS 등
미들웨어	응용 소프트웨어가 OS로부터 제공받는 서비스 이외의 추가적으로 이용할 수 있는 서비스 제공 예 : WAS, 실시간 데이터 처리 등
응용 소프트웨어	OS에서 실행되는 모든 소프트웨어 예 : 영상 처리 소프트웨어 등

---

2-1. 소프트웨어 테스트

• 구현된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능이 만족하는지 확인하기 위하여 소프트웨어의 결함을 찾아내는 활동
• 관점 종류
  1. 오류 발견 관점 : 잠재된 오류 발견 및 수정
  2. 오류 예방 관점 : 프로그램의 실행 전 리뷰, 인스펙션 등의 활동을 통해 사전에 발견
  3. 품질 향상 관점 : 반복 테스트를 통해 신뢰도를 향상시킴

 

 

2-2. 소프트웨어 테스트의 원리

• 테스팅의 결함이 존재함을 밝히는 활동이다. 
• 완벽한 테스팅은 불가능하다. 
• 조기 테스팅으로 시간과 비용을 절약할 수 있다. 
• 결함 집중 (Defect Clustering)
• 살충제 패러독스 (Presticide Paradox)
• 테스팅은 정황(Context)에 의존한다. 
• 오류-부재의 궤변 (Absence of Errors Fallacy)

 

 

2-3. 소프트웨어 테스트 과정

1. 테스트 계획
2. 테스트 분석 및 디자인
3. 테스트 케이스 및 시나리오 작성
4. 테스트 수행
5. 테스트 결과 평가 및 리포팅

 

 

2-4. 소프트웨어 테스트 유형

프로그램 실행 여부	정적 테스트	- 소프트웨어의 실행 없이 수행 - 구현, 개발 단계에서 수행 - 예 : 인스펙션, 코드 검사, 워크스루
	동적 테스트	- 소프트웨어를 실행하여 수행 - 예 : 화이트박스 테스트, 블랙박스 테스트
테스트 기법	화이트박스 테스트	- 내부 구조나 구현을 기반으로 함 - 예 : 코드, 아키텍쳐, 워크플로우, 데이터플로우 등
	블랙박스 테스트	- 적절한 테스트 명세서에 대한 분석을 통해 진행
테스트에 대한 시각	검증 (Verification)	- 올바른 제품을 생산하고 있는지 검증
	확인 (Validation)	- 요구사항이 만족하는지 검증
테스트 목적	회복 테스트	- 고의로 실패를 유도한 뒤 정상적으로 복귀하는지 확인
	안전 테스트	- 보안적 결함을 미리 점검
	강도 테스트	- 과부하 시 정상작동 여부 확인
	성능 테스트	- 처리 시간, 처리량 등 성능 확인
	구조 테스트	- 내부의 논리 경로, 소스코드의 복잡도 평가
	회귀 테스트	- 수정된 코드에 대해 새로운 결함 여부 테스트
	병행 테스트	- 기존 시스템과 변경된 시스템 비교

 

 

2-5. 테스트 오라클

• 테스트 대상 소프트웨어의 실제 결과와 비교할 목적으로 에상 결과를 결정하는 근거
• 테스트의 결과가 참인지 거짓인지 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교한다.

구분	설명
참 오라클	모든 입력 값에 대한 결과 값을 검출할 수 있는 오라클
샘플링 오라클	특정 몇 개의 입력 값만을 대상으로 하는 오라클 전 범위 테스트가 불가한 경우 사용
휴리스틱 오라클	샘플링 오라클의 개선 특정 몇 개의 입력 값을 대상을로 하고, 나머지는 휴리스틱(추정)으로 처리
일관성 검사 오라클	애플리케이션의 변경이 있을 때, 전 후 값이 동일한지 확인하는 오라클 회귀 테스트 시 사용

---

3-1. 통합 테스트

• 컴포넌트 간의 인터페이스를 테스트하는 것은 물론, 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트하는 것
• 하나 이상의 테스트 레벨이 가능
• 목적 : 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인하기 위함

 

 

3-2. 통합 테스트 수행 방법의 종류

구분	수행 방법	장점	단점
상향식 (Bottom-Up)	- 가장 하부의 모듈부터 통합 - 하위 레벨 모듈이 '클러스터'로 결합 - 상위 모듈에서 '드라이버'를 작성	- 결함의 격리가 쉬움 - 하위 모듈을 충분히 테스트 가능	- 중요한 결함이 상부에 있을 수 있음
하향식 (Top-Down)	- 가장 상부의 모듈부터 통합 - BFS, DFS 방식 사용 - 하위 레벨 모듈에서 '스텁'으로 결합	- 결함의 격리가 쉬움 - 결함을 빨리 발견 가능	- 중요한 결함이 하부에 잇을 수 있음
백본 (Backbone)	- 리스크가 높은 모듈로 초기 통합 형성	- 결함의 격리가 쉬움 - 리스크가 높은 결함을 초기에 발견 가능	- 테스트 시간이 오래 걸릴 수 있음
빅뱅 (Big Bang)	- 모든 테스트 모듈을 동시 통합	- 단시간 테스트 가능	- 결함의 격리가 어려움

---

4. 회귀 테스팅 (Regression Testing)

• 통합 테스트가 완료된 후, 변경된 모듈이나 컴포넌트가 있다면 다른 부분에 영향을 미치는지 테스트하여, 새로운 오류 여부를 확인하는 과정

---

5-1. 테스트 자동화 도구 유형

도구 유형	설명	비고
정적 분석 도구 (Static Analysis Tools)	- 애플리케이션의 실행 없이 분석하는 방법 - 소스 코드에 대한 결함을 발견
테스트 실행 도구 (Test Execution Tools)	- 자동화 테스트 스크립트를 사용	1) 데이터 주도 접근 방식 2) 키워드 주도 접근 방식
성능 테스트 도구 (Performance Test Tools)	- 애플리케이션의 처리량, 응답 시간 등을 테스트하는 방법
테스트 통제 도구 (Test Control Tools)	- 소프트웨어 수명주기 전체에 사용 가능
테스트 장치 (Test Harness)	- 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분 - 테스트를 지원하기 위한 코드와 데이터	1) 테스트 드라이버 2) 테스트 스텁 3) 테스트 슈트 4) 테스트 케이스 5) 테스트 스크립트 6) 목 오브젝트
테스트 자동화 도구	- 휴먼 에러를 줄이고, 테스트 소요 시간과 비용을 줄일 수 있음

 

 

5-2. 테스트 장치 (Test Harness)

장치	설명
테스트 드라이버 (Test Driver)	- 테스트 대상 하위 모듈 호출, 파라미터 전달, 모듈 테스트 수행 후 결과 도출 등 - 상향식 테스트에 필요함
테스트 스텁 (Test Stub)	- 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구 - 하향식 테스트에 필요함
테스트 슈트 (Test Suites)	- 테스트 대상 컴포넌트나 시스템에 사용되는 여러 테스트 케이스의 집합 - 테스트 사후 조건이 주로 다음 테스트를 위한 사전 조건이 되는 테스트 케이스로 구성
테스트 케이스 (Test Case)	- 특별한 목표 또는 테스트 상황을 테스트하기 위해 특정 조건들의 집합
테스트 스크립트 (Test Script)	- 테스트 절차 명세를 의미 - 자동화 됨
목 오브젝트 (Mock Object)	- 사용자의 행위를 조건부로 사전에 입력하고, 그 상황에 예정된 행위를 수행하는 객체

---

6. 소프트웨어 결함

• 에러(Error) / 오류
  • 결함의 원인
  • 사람이 발생시키는 결함

• 결함 / 결점 / 버그(Bug)
  • 에러 또는 오류의 원인
  • 소프트웨어 제품에 포함되어 있는 결함
  • 이를 해결하지 않으면, 소프트웨어의 실패 또는 문제가 됨

• 실패 / 문제
  • 소프트웨어 제품에 포함된 결함이 실행될 때 발생되는 현상

---

7. V-모델

• 폭포수 개발 모델에 근간을 둠
• 테스팅은 한 번에 이루어지는 것이 아니라, 각각의 개발 단계에 대응하는 테스트 레벨이 별도로 존재한다. 

---

8. 테스트 커버리지 (Test Coverage)

• 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준
• 테스트의 정확성과 신뢰성을 향상시키는 역할을 함

구분	설명
라인 커버리지 (Line Coverage)	애플리케이션의 전체 소스 코드의 Line 수를 모수로 테스트 시나리오가 수행한 소스 코드의 Line 수를 측정하는 방법
코드 커버리지 (Code Coverage)	프로그램의 소스코드가 얼마나 테스트되었는지를 나타내는 지표	구문(Statement) 커버리지	모든 구문에 대해 1회 이상 테스트
		조건(Condition) 커버리지	모든 조건식에 대해 테스트
		결정(Decision) 커버리지	모든 분기문에 대해 테스트
		변형 조건/결정 커버리지	전체 결과에 독립적으로 수행

---

9. 애플리케이션 성능 지표

• 처리량 (Throughput) : 시간 내에 처리할 수 있는 트랜잭션 수
• 응답 시간 (Response Time) : 사용자의 입력 후, 응답 출력이 개시될 때까지의 시간
• 경과 시간 (Turnaround Time) : 사용자가 요구를 입력한 시점부터 트랜잭션 처리 후 그 결과가 출력될 때까지 걸리는 시간
• 자원 사용률 (Resource Usage) : 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량 등