2020 정보처리기사 필기 : 2과목 : 4장

4장 : 애플리케이션 테스트 관리

---

1.     어플리케이션 테스트

• 결함을 찾아내는 일련의 행위 또는 절차를 말한다. 
• 유형
  • 확인 (Validation) : 고객에 초점을 맞춤.
  • 검증 (Verification) : 기능에 초점을 맞춤.

• 완벽한 테스팅은 불가능하다. 
• 파레토 법칙 : 대부분의 결함은 특정 모듈에 집중되어 있다. 
• ‘살충제 패러독스 현상’을 막기 위해 지속적인 보완 및 개선을 해야 한다. 
• 오류-부재의 궤변 : 소프트웨어의 결함을 모두 제거해도, 사용자의 요구사항을 만족시키지 못하면, 해당 소프트웨어는 품질이 높다고 말할 수 없다. 

---

2.     애플리케이션 테스트의 기준

• 프로그램 실행 여부에 따라
• 기반에 따라
• 시각에 따라
• 목적에 따라 

---

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

• 정적 테스트
  • 실행하지 않는다.
  • 명세서나 소스 코드를 분석한다.
  • 초기에 결함을 발견할 수 있다.
  • 비용을 낮추는데에 도움된다.  
  • 종류 : 워크스루, 인스펙션, 코드 검사

• 동적 테스트
  • 실행을 한다.
  • 소프트웨어 개발의 모든 단계에서 테스트 수행이 가능하다.
  • 종류 : 블랙박스 테스트, 화이트박스 테스트 

 

3-1. 워크스루

• 소프트웨어 개발자의 작업 내역을, 개발자가 모집한 전문가들이 검토하는 것
• 개발자가 주최이다. 
• 오류의 조기 검출을 목적으로한다. (오류의 문제 해결이 아니다.)

 

3-2. 인스펙션

• 워크스루의 발전된 형태이다. 
• 소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가한다. 

---

4.     기반에 따른 테스트

• 명세 기반 테스트
  • 명세를 기준으로 진행 한다.
  • 종류 : 동등 분할, 경계 값 분석

• 구조 기반 테스트
  • 논리 흐름에 따라 진행 한다.
  • 종류 : 구문 기반, 결정 기반, 조건 기반, 결정 기반

• 경험 기반 테스트
  • 테스터의 경험을 통해 진행 한다.
  • 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅 

---

5.     시각에 따른 테스트 ★★★

• 확인 (Validation) 테스트 : 사용자의 시각에서 진행 한다.
• 검증 (Varification) 테스트 : 개발자의 시각에서 진행 한다.

---

6.     목적에 따른 테스트

• 회복 테스트 : 실패하게 한 후, 올바르게 복구되는지 확인한다.
• 안전 테스트 : 위협으로 부터 보호할 수 있는지 확인한다.
• 강도 테스트 : 과부하 시 실행 가능한지 확인한다.
• 성능 테스트 : 실시간 성능, 전체적인 효율성 등을 확인한다.
• 구조 테스트 : 논리적인 경로를 확인한다.
• 회귀 테스트 : 수정 후 결함이 없는지 확인한다.
• 병행 테스트 : 변경 전, 후의 소프트웨어에 동일 값을 입력하여 결과 값을 비교한다. 

---

7.     화이트박스 테스트 ★★★

• 절차에 초점을 둔다.
• 원시 코드를 오픈시킨다. 
• 모든 경로를 테스트한다. 
• 테스트 과정의 초기에 적용된다. 
• 모듈 내부의 논리적인 구조를 관찰한다. 
• 직접 관찰한다. 
• 모든 문장을 1회 이상 실행한다. 
• 종류 
  • 기초 경로 검사
  • 조건 검사
  • 루프 검사
  • 데이터 흐름 검사

• 검증 기준
  • 문장 검증 기준
  • 분기 검증 기준
  • 조건 검증 기준
  • 분기 / 조건 검증 기준 

---

8.     블랙박스 테스트 ★★★

• 기능 테스트라고도 한다.
• 특정 기능에 초점을 맞춘다.  
• 테스트 과정의 후반부에 적용된다. 
• 종류
  • 동치 분할 검사
  • 경계값 분석
  • 원인 효과 그래프 검사
  • 오류 예측 검사
  • 비교 검사

---

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

V-Model of Software Life Cycle

 

9-1. 단위 테스트 (Unit Test)

• 코딩 직후 수행한다.
• 최소 단위인 모듈이나 컴포넌트에 초점을 맞춘다. 
• 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 한다. 
• 구조 기반 테스트(화이트 박스 테스트)를 주로 사용한다. 
• 종류

테스트 방법	테스트 내용	테스트 목적
구조 기반 테스트	화이트 박스 테스트	제어 흐름, 조건 결정
명세 기반 테스트	블랙 박스 테스트	동등 분할, 경계 값 분석

 

9-2. 통합 테스트 (Integration Test)

• 단위 테스트 후, 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서 수행한다. 
• 모듈 간 상호 작용 오류를 검사한다.
• 종류

테스트 방법	설명
비점진적 통합 방식	단계적으로 통합하는 절차 없이, 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법이다.  규모가 작은 소프트웨어에 유리하다.  전체 프로그램을 대상으로 하기 때문에, 오류의 발견 및 수정이 어렵다.
점진적 통합 방식	단계적을로 통합하며 진행한다.  하향식, 상향식, 혼합식 통합 방식이 있다.  오류 수정이 용이하다.

 

9-3. 시스템 테스트 (System Test)

• 해당 컴퓨터 시스템에서 완벽하게 수행되는가 점검한다.
• 실제 사용 환경과 유사하게 만든 환경에서 진행한다.
• 종류

테스트 방법	테스트 내용
기능적 요구사항	블랙 박스 테스트
비기능적 요구사항	화이트 박스 테스트

 

9-4. 인수 테스트 (Acceptance Test)

• 사용자가 직접 테스트한다.
• 종류
  • 사용자 인수 테스트
  • 운영상의 인수 테스트
  • 계약 인수 테스트
  • 규정 인수 테스트
  • 알파 테스트 : 선택된 사용자가, 개발자 앞에서, 통제된 환경에서 검사
  • 베타 테스트 : 최종 선정된 사용자가, 여러 명의 사용자 앞에서, 제어되지 않은 상태에서 검사

---

10. 하향식 통합 테스트 ★★★

• 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트를 진행한다. 
• DFS, BFS를 사용한다. 
• 테스트 초기에 사용하므로, 사용자에게 시스템의 구조를 보여줄 수 있다. 
• 상위 모듈에서는 부적절하다. 
• 회귀 테스트를 실시한다. 

---

11. 상향식 통합 테스트 ★★★

• 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
• 스텁은 필요 없지만, 클러스터는 필요하다. 
• 드라이버(Driver)를 작성한다. 

 

 

11-1. 상향식 통합 테스트의 과정 ★★★

순서	과정
1	낮은 수준의 모듈들을 클러스터로 결합한다.
2	드라이버라는 제어 프로그램을 작성한다.
3	클러스터를 검사한다.
4	클러스터를 상위로 결합한다.

---

12. 드라이버(driver)와 스텁(stub) ★★★

구분	드라이버	스텁
필요 시기	상위 모듈 없이, 하위 모듈이 있는 경우	상위 모듈은 있지만, 하위 모듈이 없는 경우
테스트 방식	상향식 테스트	하향식 테스트
공통점	소프트웨어 개발과 테스트를 병행할 경우 이용된다.
차이점	개발이 완료되면, 드라이버는 본래의 모듈로 교체된다.	일시적, 임시적인 가짜 모듈 역할을 한다.  드라이버보다 작성이 쉽다.

 

---

13. 테스트 케이스

• 입력 값, 실행 조건, 예상 결과 등으로 구성된 테스트 항목에 대한 명세서
• 오류 방지
• 자원 낭비 방지
• 시스템 '설계' 시 작성해야 한다.

---

14. 테스트 시나리오

• 여러 개의 테스트 케이스를 묶은 집합이다. 
• 테스트 절차를 명세한 문서이다. 

---

15. 테스트 오라클 (Test Oracle) ★★★

• 테스트 결과가 올바른지 판단하기 위해, 사전에 정의된 참 값을 대입한다.
• 테스트 결과가 올바른지를 판단하는 근거가 된다.
• 모든 테스트 케이스에 적용할 수 없다.
• 종류
  • 참 오라클
  • 샘플링 오라클
  • 추정 오라클
  • 일관성 검사 오라클

---

16. 어플리케이션 성능 측정 지표

• 처리량 (Throughput) : 일정 시간 내의 처리하는 일의 양
• 응답 시간 (Response Time) : 요청 시간 ~ 응답 시간
• 경과 시간 (Turn Around Time) : 작업 의뢰 시간 ~ 처리 완료 시간
• 자원 사용률 (Resource Usage) : CPU 사용량 등