11. 테스트

• 용어
• 블랙박스 테스트
• 화이트박스 테스트
• 객체지향 테스트
• 통합 & 시스템 테스트
• 테스트 관리 및 자동화 도구

 

---

용어

 

• 테스트

→ 시스템이 정해진 요구를 만족하는지, 예상과 실제가 어떤 차이를 보이는 지 수동or자동으로 검사 및 평가하는 것

→ 100% 테스트는 불가능 ( 판단의 어려움 / 시간, 자원 제약 )

→ 소프트웨어는 많은 테스트를 해봐야 한다

→ 테스트 단계 : 대규모 시스템의 테스트는 단계적으로 이루어져야 함

 

• 신뢰도

→ 시스템의 동작과 명세에 기술된 동작이 일치하는 정도

 

• 오류

→ 시스템 실행동안 결함

→ 시스템이 정상적으로 작동하지 못하게 하는 것

 

• 결함

→ 이상 동작을 하게 하는 설계 / 코딩 / 버그

 

• 고장

→ 컴포넌트의 명세와 실행 동작의 차이

→ 하나 이상의 오류로 인해 발생

 

• 테스트 대상 컴포넌트

→ 분리해서 시험할 수 있는 시스템의 모듈

 

• 테스트 케이스

→ 고장 및 결함을 찾기 위해 컴포넌트의 입력 및 예상 결과 집합

→ 속성 : 이름 , 테스트 대상, 조건, 입력 , 오라클, 로그

→ 테스트 스위트 : 테스트 케이스 집합

→ 테스트 절차 : 테스트 케이스를 어떤 순서로 실행할 것인지 기술한 것

→ 테스트 스텝 : 테스트 케이스 실행의 최소 단위

 

• 테스트 드라이버 ( bottom up )

→테스트될 컴포넌트를 호출하는 부분적인 구현

→ 테스트 대상을 구동시키는 프로그램

 

• 테스트 스터브 ( top down )

→ 테스트될 컴포넌트가 호출하는 컴포넌트가 부분적으로 구현된 것

→ 호출되는 컴포넌트를 시뮬레이션 한 프로그램

 

• 오류 개념

→ 테스트는 오류가 있음을 보여주는 작업이지 오류가 없음을 보여주는 작업이 아님

→ 모든 오류가 결함이 되지는 않음

→ 결함이 고장 현상으로 나타나지 않을 수 있음

→ S/W 고장은 오류로 인해 발생함

 

• 오류 수정

→ 결함을 고치기 위해 컴포넌트를 변경하는 것

→ 버그 트래킹 : 고장, 오류, 결함, 오류 수정작업을 기록한 것 / 형상관리 작업의 일부

→ 리그레션 테스트 : 수정된 모듈 및 관련 모듈의 테스트 / 수정할 때 마다 리그레션 테스트를 해야하기 때문에 자동화해야함

→ 문서화 : 변경 이유 및 관계를 기록

 

 

---

블랙박스 테스트

 

 

• 블랙박스 테스트

→ 대상을 블랙박스로 보고 기능이 올바른 지 확인하는 작업

→ 종류 : 동등 분할 테스트 / 경곗값 분석 / 원인 결과 분석

 

1. 동등 분할 테스트

→ 입력의 결과가 동등한 클래스를 분할 , 대표 입력값

→ 가능한 입력을 동치 클래스로 나눈 후, 테스트 사례를 각 클래스에서 선택한다.

→ 대표 입력값 선택의 기준 : 포함 정도 / 비결합성 / 표현성

→ 포함 정도 : 가능한 모든 입력은 동치 클래스 중 하나에 반드시 속할 것

→ 비결합성 : 동치 클래스에는 같은 입력이 존재하면 안됨

→ 표현성 : 동치 클래스A의 멤버가 입력으로 사용되서 오류가 발생했다면, 동치 클래스A의 다른 멤버도 오류가 발생해야 함

 

2. 경곗값 분석

→ 오류가 많이 발생하는 경계선 상의 테스트

→ 클래스 경계에서 값을 선택함

→ 예를 들어 입력값의 범위가 1~100 이라면 경곗값은 1 주변값 ( 0,1,2 ) 이거나 100 주변값 ( 99, 100, 101 ) 이어야 함

 

3. 원인 결과 분석

→ 원인과 결과 관계를 파악하여 테스트

→ 어떤 결과와 그 결과에 영향을 주는 요인 사이의 관계를 분석

→ 의사 결정표 : 입력이 원인이 되고,  출력은 결과가 된다.

→ 과정 : 원인과 결과를 찾는다 à 원인과 결과의 관계를 그래프로 나타낸다 à 원인과 결과 사이에 제약조건을 추가해 그래프를 완성한다 à 그래프를 의사 결정표로 전환한다 à 테스트 케이스를 생성한다

 

 

---

화이트박스 테스트

 

• 화이트박스 테스트

→ 모듈 안의 내부 구조와 실행 경로를 자세히 참조하는 테스트

→ 종류 : 경로 테스트 / 경로 찾기

 

1. 경로 테스트

→ 가능한 경로를 적어도 한번씩 실행

 

2. 경로 찾기

→ 원시 코드의 흐름도 작성

 

• 테스트 커버리지

→ S/W 총량에 대해 테스트된 아이템의 비율 : 테스트한 경로 / 기본 경로의 수

→ 문장 커버리지 : 실행 코드라인이 한 번 이상 실행되면 충족

→ 분기 커버리지 : 내부 조건이 참 또는 거짓이면 충족

→ 경로 커버리지 : 독립된 모든 경로를 테스트하는 기준

→ 조건 커버리지 : 각 분기의 내부 복합 조건에 대한 단위 조건의 참과 거짓을 모두 테스트해야 충족

 

※ 구조기반 기법

 

---

객체지향 테스트

 

 

• 객체지향 테스트

→ 사용사례 기반 테스트 : 사용사례 명세에서 테스트 케이스 추출

→ 상태기반 테스트 : 시계 실행 상태의 예상된 결과와 오러클의 비교

→ 테스트 케이스 : 모든 상태 변환이 적어도 한 번씩 방문 되도록 할 것

 

 

---

통합 & 시스템 테스트

 

• 통합 테스트

→ 2개 이상의 컴포넌트에 초점을 두어 단위 테스트에서 발견하지 못한 결함을 찾는 것

→ 스터브와 드라이버 작성이 필요

→ 종류 : 동시식 / 하향식 / 상향식 / 샌드위치식

 

1. 동시식 통합

→ 모든 컴포넌트를 동시에 통합

→ 스터브나 테스트 드라이버가 필요하지 않음

→ 비용이 많이 들고 고장과 관련된 컴포넌트를 찾기 어려움

 

2. 하향식 통합

→ 최상위층을 단위테스트 / 아래층을 점증적으로 통합

→ 하위층을 시뮬레이션 하는 스터브 사용

→ 시스템의 골격 테스트에 좋음

→ 스터브 개발에 시간이 많이들고, 하위층에 기능이 많이 구현되어 있으면 효율이 떨어짐

하향식 통합

 

3. 상향식 통합

→ 하위층의 컴포넌트를 테스트 à 위층에 있는 컴포넌트를 차례로 통합

→ 테스트 드라이버 필요

→ 인터페이스 결함 발견에 좋음

→ 시스템의 골격이 나중에 테스트되고, 상위층에서 발견된 결함이 서브 시스템에 영향을 줄 수 있음

상향식 통합

 

4. 샌드위치 통합

→ 상향식 + 하향식

→ 서브 시스템 분할 : 타깃층 + 타깃 아래층 + 타깃 위층

→ 타깃층을 중심으로 위쪽은 하향식 , 아래쪽은 상향식으로 병행 테스트

→ 최상위층과 최하위층은 스터브와 드라이브가 필요없음

샌드위치 통합

 

• 시스템 테스트

→ 전체 시스템을 빌드한 후 요구 중심의 테스트

→ 종류 : 기능 테스트 / 성능 테스트 / 파일럿 테스트 / 인수 테스트 / 설치 테스트가 있음

 

1. 기능 테스트 : 기능적 요구와 시스템의 차이를 발견하기 위한 테스트

2. 성능 테스트 : 스트레스 / 볼륨 / 보안 / 타이밍 / 복구 테스트를 하는 것

3.

 파일럿 테스트 : 필드 테스트 / 알파 테스트 / 베타 테스트를 하는 것

4. 인수 테스트 : 벤치마크 / 경쟁 테스트를 하는 것

5. 설치 테스트 : 목표 환경에서 기능 테스트와 성능 테스트를 반복, 설치 테스트가 시스템 테스트의 최종임

 

 

---

테스트 관리 및 자동화 도구

 

 

 

• 테스트 작업

→ 한정된 자원과 일정으로 진행되므로 '계획' 을 잘 세워야 한다.

→ 테스트 작업 계획 / 문서 / 할당 순서로 구성

 

1. 테스트 작업 계획

→ 효과적인 테스트 케이스를 선정하고, 테스트 작업을 병렬로 계획

 

2. 테스트 작업 문서

→ 테스트 계획서 : 관리 문서, 작업 범위, 접근 방법, 자원, 일정 , 요구 사항에 대한 문서

→ 테스트 케이스 : 입력 , 예상 출력, 드라이버, 스터브, 수행할 작업의 단계

→ 테스트 실행 보고서 : 실행 결과

→ 테스트 요약 보고서 : 발견된 오류

→ 완벽한 테스트는 불가능 하므로 종료 기준이 있어야 함

 

※ 테스트 종료 기준(시점) 

→ 테스트 케이스를 중요도에 따라 레벨 1~3으로 나눈다.

→ 레벨 1은 전부 테스트를 실행한다.

→ 레벨 2,3 은 정한 비율로 테스트를 진행해 통과시킨다.

→ 2번 이상의 빌드 과정을 거친다.

 

3. 테스트 작업 할당

→ 컴포넌트 개발에 참여하지 x 엔지니어

→ 컴포넌트 분석에 능통하고 모순점을 잘 찾는 사람

→ 품질 관리를 담당하는 팀

 

• 테스트 자동화 도구

1. 정적 분석 도구

 

1-1. 코드 분석 도구

→ 원시 코드의 문법적 적합성을 자동으로 평가하고 잘못된 문장을 표기해준다.

 

1-2. 구조 검사 도구

→ 원시 코드의 그래프를 생성해 논리흐름을 보여준다

→ 구조적 결함이 있는지 체크해준다.

 

1-3. 데이터 분석 도구

→ 원시 코드에 정의된 데이터 구조/선언, 컴포넌트 인터페이스를 검사한다.

→ 잘못된 링크 / 데이터 정의 충돌 / 잘못된 테이터 사용 등을 발견해준다.

 

1-4. 순서 검사 도구 

→ 이벤트의 순서를 체크해준다.

→ 잘못된 순서가 발견되면 지적해준다.

 

2. 동적 분석 도구

→ 프로그램이 수행되는 동안 이벤트의 상태를 파악하기 위해, 특정 변수나 조건의 스냅샷(snapshot) 을 생성

 

• 테스트 케이스 생성 도구

1. 자료 흐름도

→ 원시 프로그램을 입력받아 파싱하고 자료 흐름도를 작성해준다

→ define - use 관계

→ 찾으려는 변수에 영향을 주는 요소들을 모아 테스트 경로를 구동시키는 입력값을 찾아낸다.

 

2. 기능 테스트

→ 주어진 기능을 구동 시키는 모든 가능한 상태를 파악하고 입력을 작성한다.

 

3. 입력 도메인 분석

→ 원시 코드의 내부를 참조하지 않고 입력 변수가 가질수 있는 값의 도메인 분석

 

4. 랜덤 테스트

→ 입력 값을 무작위로 추출

→ 시스템의 신뢰성 분석에 사용

 

• 테스트 실행 도구

→ 자동적으로 스터브와 드라이버를 생성하는 도구

→ 자동 테스트 환경 : 테스트 수행 도구들이 테스트 환경으로 통합되어 제공

 

※ 캡쳐 및 리플레이

→ 테스트 계획에 표시된 테스트 데이터를 자동으로 입력

→ 실행 과정에 발생하는 화면 / 인쇄 결과를 캡쳐

→ 예상 결과와 비교

→ 예상 결과와 차이가 발생할 경우 프로그래머에게 보고

→ 오류를 발견하고 수정한 후 고치는 작업을 체크