[정보처리기사 이론 정리]테스트

<테스트 케이스 작성순서>

 

1. 테스트 계획 검토, 자료 확보

 

2. 위험 평가, 우선순위 결정

 

3. 테스트 요구사항 정의

 

4. 테스트 구조 설계, 테스트 방법 결정

 

5. 테스트 케이스 정의

 

6. 테스트 케이스 타당성 확인, 유지보수

---

<통합 테스트>

 

1. 테스트 드라이버(Driver)

 

상위 모듈에서 데이터 입력 & 출력 확인 위한 더미모듈

상향식 통합 테스트 수행 시 사용

상향식 통합 테스트에서 데이터의 입력과 출력을 확인하기 위해서 하위 모듈을 호출하는 상위의 더미 모듈이다.

 

2. 테스트 스텁

 

모듈, 모든 하위 컴포넌트를 대신하는 더미모듈

하향식 통합 테스트 수행 시 사용

 

3. 빅뱅 테스트

 

모든 모듈을 동시에 통합 후 테스트 수행

단시간에 통합 테스트 가능

---

<상항식 통합 테스트(Bottom Up Integration Test) 절차>

 

1. 모듈 또는 컴포넌트들이 하위 모듈의 기능을 수행하는 클러스터(Cluster)로 결합

 

2. 드라이버라는 제어 프로그램의 작성

 

3. 각 통합된 클러스터 단위 테스트

 

4. 각 클러스터들은 프로그램의 위쪽으로 결합되며, 드라이버는 실제 모듈 또는 컴포넌트로 대체

---

<테스트 레벨>

 

한 번에 총체적으로 조직화하고 관리하는 테스트 활동의 묶음

 

1. 단위 테스트(Unit Test)

 

사용자 요구사항에 대한 단위 모듈, 서브루틴 등을 테스트하는 단계

인터페이스 테스트, 자료구조 테스트, 실행 경로 테스트, 오류 처리 테스트가 존재

코딩 직후 SW 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트 진행

사용자 요구사항을 기반으로 한 기능성 테스트 최우선

주로 구조기반(화이트박스 테스트) 시행

 

2. 통합 테스트

 

시스템이나 시스템 구성 요소 또는 소프트웨어 프로그램의 데이터 및 기능의 인터페이스(흐름)가 정상적으로 작동하는지에 중점을 둠

단위 테스트를 통과한 개발 소프트웨어/하드웨어 컴포넌트 간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트

 

(1) 빅뱅 통합 테스트

 

모든 모듈을 한꺼번에 통합하고 결합 격리가 어려움

 

(2) 상향식 통합

 

가장 하부의 모듈부터 통합해가면서 상부로 올라감, 드라이브가 필요

 

(3) 하향식 통합

 

가장 상부의 모듈부터 통합해가면서 하부로 내려감, 스텁 필요

 

(4) 백본 통합

 

소프트웨어 리스크가 높은 것을 우선적으로 통합하고 접근, 드라이버, 스텁은 필요에 따라 만들어서 사용

 

3. 시스템 테스트

 

실제 환경과 가능한 유사한 환경에서 진행

기능적 요구사항(명세기반 기법), 비기능적 요구사항(구조기반 기법)

개발 조직과는 독립된 테스트 조직에서 수행되어야 하며 사전 요구사항이 명확해야 한다

단위, 통합 테스트가 가능한 완벽히 완료되어 가능상에 문제가 없는 상태여야 한다

---

<테스트 유형>

 

1. 인수테스트

 

사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자의 입장에서 확인하는 테스트로 알파, 베타 테스트가 있다.

 

2. 강도(Stress) 테스트

 

시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정상적으로 작동되는지를 검증하는 테스트 기법이다.

시스템이 과부하상태에서 어떻게 작동하는지를 검사하는 테스트

테스트 목적에 따른 분류 중 하나로 ‘시스템에 과다 정보량을 부과하여 과부화 시에도 시스템이 정상적으로 작동되는지를 검증하는 테스트 기법

 

3. 회귀(Regression) 테스트

 

오류를 제거하거나 수정한 시스템에서 오류 제거와 수정에 의해 새로이 유입된 오류가 없는지 확인하는 일종의 반복 테스트 기법이다.

 

4. 성능(Performance) 테스트

 

시스템의 요소가 특정 상황에서 어느 정도의 성능을 보이는지를 측정하는 테스트

 

5. 부하(Load) 테스트

 

임계치의 한계에 도달할 때까지 시스템에 부하를 꾸준히 증가시키면서 진행하는 테스트

발생시키는 부하는 실제 시스템에 적용될 예상 트래픽

---

<애플리케이션 테스트>

 

1. 김PM은 온라인 예약시스템 개발 PM을 맡고 있다. 사용자 요구사항에 따라 시스템에 고의로 실패를 유도하고, 온라인 예약시스템의 정상적 복귀 여부를 확인하는 테스트를 수행해야 한다. 김PM이 수행해야 하는 테스트는 회복 테스트이다.

 

2. 이대리는 내부 인트라넷 급여시스템 개발자이다. 일정에 맞춰 커버리지 테스트를 수행해야 한다. 이대리는 전체 조건식뿐만 아니라 개별 조건식도 참 한 번, 거짓 한 번 결과가 되도록 수행하는 커버리지 테스트를 수행해야 한다. 이 코드 커버리지 유형은 조건/결정 커버리지이다.

 

3. 소프트웨어 테스트 유형

 

(1) 회귀 테스트 - 오류를 제거하거나 수정 후 새롭게 유입된 오류가 있는지 테스트

 

(2) 회복 테스트 - 고의로 실패 유도 후 정상 복귀 여부 확인하는 테스트

 

(3) 안전 테스트 - 소스 내의 보안적인 결함을 확인

 

(4) 강도 테스트 - 과부하시 정상적인 동작을 하는지 확인하는 테스트

 

(5) 성능 테스트 - 응답시간, 특정시간, 처리량 등 시스템 반응 속도 테스트

 

(6) 구조 테스트 - 시스템 내부의 경로나 소스코드 복잡도 테스트

 

(7) 병행 테스트 - 변경된 시스템과 기존의 시스템에 동일한 데이터 입력 후 결과 비교

 

4. 테스트 커버리지

 

유형 - 구문, 결정, 조건, 조건-결정, 변경조건-결정, 다중 조건

 

(0) 구문 커버리지

 

‘프로그램 내의 모든 명령문을 적어도 한 번 수행하는 커버리지리로 조건문 결과 관계 없이 구문 실행 개수로 계산’하는 코드 커버리지

 

(1) 결정 커버리지

 

프로그램 내의 전체조건식이 적어도 한 번은 참과 거짓의 결과를 수행하는 테스트 케이스

프로그램 내의 전체 결정문이 적어도 한 번은 참과 거짓의 결과를 수행하는 코드 커버리지 유형

 

(2) 조건 커버리지

 

전체 조건식과 결과와 관계없이 각 개별 조건식이 참/거짓 한 번만 모두 갖도록 개별 조건식을 조합하는 테스트 커버리지

결정 명령문 내의 각 조건이 적어도 한 번은 참과 거짓의 결과가 되도록 수행하는 코드 커버리지 유형

 

(3) 조건-결정 커버리지

 

결정 명령문 내의 각 조건(개별조건)과 전체조건식이 적어도 한 번은 참과 거짓의 결과를 수행하는 테스트 케이스

 

(4) 변경조건-결정 커버리지

 

조건/결정 커버리지를 향상시켜 ‘각 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 한’ 코드 커버리지

 

---

<애플리케이션 테스트>

 

1. 화이트박스 테스트가 끝난 후 더 나은 품질을 기대하기 위해서는 블랙박스 테스트를 실시해서 결함을 많이 검출할 필요가 없다. 화이트박스 테스트와 블랙박스 테스트의 수행 순서와 결함 검출률은 아무런 상관이 없다. 독립적으로 수행하면 된다.

 

2. 리그레션 테스트는 자동화에 적합한 테스트 타입이다. 리그레션 테스트(회귀 테스트)는 반복적 성향이 강해서 자동화 테스트에 적합하다.

 

3. 디버깅은 테스트의 일종이 아니다. 디버깅(Debugging)은 개발 활동이다.

 

4. 타 시스템과 연동되는 테스트는 테스트 수행 단계에서 통합 테스트(단위 테스트 X) 단계에 속한다.

 

5. 애플리케이션 테스트

 

시스템 테스트, 인수테스트, 통합테스트, 단위테스트

 

(1) 시스템 테스트

 

개발된 애플리케이션을 서버에 설치한 이후에 서버에서 잘 동작하고 DB연결도 잘되도록 하는 것

 

(2) 통합 테스트

 

모듈 결합 후 인터페이스 테스트, 전체 기능 동작 테스트

---

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

 

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

 

(1) 정적 테스트

 

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

소프트웨어 개발 초기에 결함 발견 가능, 개발 비용 낮음

 

워크스루(Walk Trough) - 검토 회의 전 요구사항 명세서를 미리 배포해 짧은 검토회의를 통해 결함 발견

인스펙션(Inspection) - 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 결함 발견

동료검토(Peer Review) - 요구사항 명세서 작성자가 내용을 직접 설명, 동료들이 들으면서 결함 발견

 

(2) 동적 테스트

 

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

소프트웨어 개발의 모든 단계에서 테스트를 수행할 수 있음

 

블랙박스 테스트

화이트박스 테스트

 

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

 

(1) 명세 기반 테스트 ( 동등 분할, 경계 값 분석 등 )

 

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

 

(2) 구조 기반 테스트 ( 구문 기반, 결정 기반, 조건 기반 등 )

 

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

 

(3) 경험 기반 테스트 ( 에러 추정, 체크 리스트, 탐색적 테스팅 )

 

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

사용자의 요구사항에 대한 명세가 부족하거나 테스트 시간에 제약이 있는 경우 수행하면 효과

 

3. 시각에 따른 테스트

 

(1) 검증(Verification) 테스트

 

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

 

(2) 확인(Validation) 테스트

 

사용자의 시각에서 생산된 제품의 결과를 테스트하는 것. 사용자가 요구한대로 완성되었는

 

4. 목적에 따른 테스트

 

(1) 회복(Recovery) 테스트

 

시스템에 여러 결함을 주어 실패하도록 한 후 올바르게 복구되는지 확인

 

(2) 안전(Security) 테스트

 

시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지 확인

 

(3) 강도(Stress) 테스트

 

시스템에 과도한 정보량이나 빈도 등을 부과해 과부하 시 소프트웨어가 정상적으로 실행되는지 확인

 

(4) 성능(Performance) 테스트

 

소프트웨어의 실시간 성능이나 전체적인 효율성을 진단, 응답시간, 처리량 등 테스트

 

(5) 구조(Structured) 테스트

 

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

 

(6) 회귀(Regression) 테스트

 

소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인

 

(7) 병행(Parallel) 테스트

 

변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력해 결과를 비교

---

<테스트 레벨(Test Level)>

 

프로젝트에서 책임과 연관되어 있으며 서로 독립적 성격을 갖지만 함께 편성되고 관리되는 테스트 활동의 그룹을 이르는 용어

---

<테스트 산출물의 종류>

 

1. 테스트 계획서

 

2. 테스트 케이스

 

3. 테스트 시나리오(Test Scenario)

 

테스트 수행을 위한 여러 테스트 케이스의 집합으로서, 테스트 케이스의 동작 순서를 기술한 문서이며 테스트를 위한 절차를 명세한 문서

 

4. 테스트 결과서

---

<테스트 오라클(Test Oracle)>

 

테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법

테스트 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참값을 입력하여 비교하는 기법으로, true, sampling, heuristic, consistency check로 분류되는 테스트 기법

---

<테스트 자동화 도구>

 

테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현함으로써, 테스트 시간 단축과 인력 투입 비용을 최소화하고, 쉽고 효율적인 테스트를 수행할 수 있는 방법

 

1. 성능 테스트 도구(Performance Test Tools)

 

테스트 자동화 도구의 유형으로는 애플리케이션을 실행하지 않고 분석하는 ‘정적 분석 도구’, 테스트를 위해 작성된 스크립트를 실행하는 ‘ 테스트 실행 도구’, 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트를 수행

 

2. 테스트 통제 도구

 

테스트 관리 도구, 형상 관리 도구, 결함 추적/관리 도구 등

---

<테스트 조건>

 

1. 시작 조건

 

테스트 조건에서 테스트 계획의 수립, 사용자 요구사항에 대한 테스트 명세의 작성, 투입조직 및 참여 인력의 역할과 책임의 정의, 테스트 일정의 확정, 테스트 환경의 구축 등이 완료된 후, 정의하는 조건

 

2. 종료 조건

 

업무 기능의 중요도에 따라 조건 설정의 변경이 가능

---

<테스트 커버리지(Test Coverage)>

 

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

---

<테스트 하네스(Test Harness)>

 

애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위한 코드와 데이터를 말하며, 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성하는 요소

애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위한 코드와 데이터를 말하며, 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성하는 요소

---

<통합 테스트(Integration Test)>

 

단위테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인하고, 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법으로 하향식 통합 테스트, 상향식 통합 테스트, 그리고 빅뱅 테스트로 분류