10. 테스팅

●테스팅

시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동/자동 방법을 동원하여 검사/평가하는 일련의 과정

숨어있는 결함을 찾기 위해 소프트웨어를 작동시키는 일련의 행위와 절차

결함이 없음을 증명하는 것이 아니고, 결함이 존재함을 보여주는 작업

분석, 설계 도중에 일어나는 검증, 검토 등 품질 보증을 위한 모든 행위

소프트웨어의 정확성을 확증하는 과정 : 결함이나 원치 않는 동작을 찾는 것, 요구와 제약에 맞는지 검증

오류 : 프로그램 실행 결과가 예상한 결과와 다른 경우 그 차이를 의미,

+ 결함 및 고장을 일으키게 한 인간의 실수

결함 : 시스템이 요구된 기능을 수행하지 못하게 하는 조건

+ 소프트웨어 오작동의 원인

고장 : 명세로 작성된 요구와 기능을 제대로 수행할 수 없는 경우

+ 결함은 고장을 유발하는 잠재성을 가지지만, 모든 결함이 고장을 발생하는 것은 아님

 

●테스팅 원리

테스팅은 오류를 발견하려고 프로그램을 실행시키는 것

완벽한 테스팅은 불가능

테스팅은 창조적이면서 어려운 작업

테스팅은 오류의 유입을 방지

테스팅은 구현과 관계없는 독립된 팀에 의해 수행 되야함

테스트는 오류를 발견하려고 프로그램을 수행 시키는 작업으로 테스트에 의해 오류가 발견되지 않았다고 하여 프로그램에 오류가 없는 것은 아님

 

●테스팅의 단계

단위 시험(Unit Testing)

통합 시험(Integration Testing)

시스템 시험(System Testing)

인수 시험(Acceptance Testing)

설치 시험(Installation Testing)

 

●개발 단계별 테스트

 

●Testing Strategies

Testing Strategies는 테스트 케이스 디자인을 위한 주제를 다룬다.

유효성 : 가능한 많은 실패한 테스트 케이스를 일으킨다

효율성 : 테스트 케이스의 작은 숫자의 결함을 드러낸다.

 

●테스팅 과정

테스트에 의해 무엇을 점검할 것인지 정한다.(테스트의 목표 : 기능의 완벽성, 신뢰도)

테스트 방법 결정(검사, 증명, 블랙박스 테스트, 화이트 박스 테스트, 자동화도구)

테스트 케이스를 개발(테스트 자료, 시행 조건, 시험 계획서)

테스트의 예상되는 올바른 결과 작성(테스트오라클:모든 테스트에 대한 예상 결과)

테스트 케이스로 실행(테스트 하니스:테스트를 위해 일부 기능을 변경하는 작업)

 

●테스트 케이스

소프트웨어 시스템에 포함된 결함을 발견하기 위해 설계한 명령 또는 입력 값의 집합

테스트 케이스 선택이 무엇보다 중요

좋은 테스트 케이스는 효과적으로 결함을 드러낼 수 있어야함

테스트 케이스는 테이스 데이터와 예상 결과를 포함

 

●블랙박스 테스팅

프로그램 구조를 고려하지 않음

테스트 케이스는 프로그램이나 모듈의 요구나 명세를 기초로 결정

입력과 출력에 대해 알아야함

기능 테스트

가능한 모든 기능을 전부 테스트 하는 것이 좋음

종류 : Equivalence classes, Boundary value analysis, Decision tables, State transitions, Use cases

 

●동치 클래스(Equivalence Class)

입력 값의 영역을 동치 클래스로 나누고 각 동치 클래스에 속한 대푯값으로 테스팅한 후 올바로 실행된다면 해당 클래스의 다른 모든 값에 대하여 올바로 실행될 것이라고 간주하는 블랙박스 테스팅

프로그램에서 같은 부분을 구동시키고 결과를 확인하는 값들은 대표 값으로 한 번만 테스트

모든 클래스 값을 찾아내어 각 클래스에서 하나의 값으로 프로그램을 실행시킨다면 전수 테스트와 같음

 

●경계값 분석(Boundary Value Analysis)

동치 클래스의 경계에서 문제를 발생하는 특수한 값이 존재

동치 클래스 경게에 있는 값을 가진 테스트 케이스는 높은 효율을 가짐

동치 클래스의 경계에 있는 값을 테스트 입력으로 선택

 

●원인과 결과 그래프(Cause-Effect Graph)

입력 조건이나 클래스의 조합을 체계적으로 선택하는 테스트 기법

노드와 기호로 표시(노드 : 원인(입력 조건), 결과(출력 조건)

 

●화이트박스 테스팅

모듈의 논리적인 구조를 체계적으로 점검하는 구조적 테스팅

모듈 안의 작동을 자세히 관찰하는 시험, 각각의 라인이 제대로 수행되는지를 철저하게 시험

제어 흐름도를 이용

 

●테스트 커버리지(Test Coverage)

테스트를 어느 정도 완벽히 수행할 것인가의 기준

노드 커버리지 : 논리 흐름 그래프의 각 노드가 테스트 케이스에 의해 적어도 한 번씩 방문되어야 하는 검증 기준

간선 커버리지 : 노드 흐름 그래프의 각 간선이 테스트 케이스에 의하여 적어도 한 번씩 방문되어야 하는 검증 기준

기본 경로 커버리지 :모든 기본 경로가 적어도 한 번씩 방문되어야 하는 검증 기준

모든 경로 커버리지 : 모든 가능한 경로를 적어도 한 번씩 테스트하는 검증 기준

 

●문장 커버리지(Statement Coverage)

원시 코드의 모든 문장을 적어도 한번 이상 실행하는 것을 기준으로 하는 테스트 방법

 

●분기 커버리지(Branch Coverage)

원시 코드의 각 분기가 참과 거짓을 적어도 한번 이상 실행 시키는 것을 기준으로 하는 테스트 방법

 

●조건 커버리지(Condition Coverage)

모든 기본 조건식의 결과 값이 참과 거짓을 적어도 한 번 이상 실행

분기 커버리지는 전체 조건식의 참과 거짓을 대상으로 하나 조건 커버리지는 기본 조건식을 대상으로함

 

●기본 경로 테스팅(Basis Path Testing)

기본 경로 : 독립적인 논리 흐름을 검사하는 테스트 케이스를 생성, Cyclomatic Complexity를 이용하여 기본 경로의 수를 계산

시작 노드에서 종료 노드까지의 서로 독립된 경로로 싸이클을 최대 한번만 지남

 

●Cyclomatic Complexity(CC)

프로그램 복잡도 측정 방법

프로그램의 control flow graph를 이용해 측정

기본 경로의 수 = 테스트 케이스의 수 = CC의 수

 

●객체지향 테스팅

객체지향 방식의 프로그램에 적용

사용사례 기반 테스팅

상태 기반 테스팅

 

●사용 사례 기반 테스팅

사용 사례 명세로부터 테스트 케이스 추출

액터의 입력과 액션을 파악

입력 값을 결정

테스트 케이스 생성

 

●상태 기반 테스팅

시스템의 동작은 시스템의 상태에 의해 좌우됨

상태 : 시스템의 과거 입력에 대한 영향을 표시

트랜지션 : 이벤트에 대한 반응으로 어떻게 변해가는지를 나타냄

이벤트 : 시스템에 대한 입력

액션 : 이벤트에 대한 출력

검증기준 : 모든 트랜지션(유입과 방출 트랜지션 쌍을 의미)

 

●통합 테스팅(Integration Testing)

모듈의 인터페이스와 결합을 테스트

모듈의 결합 순서에 따라 방법이 다름

+ 빅뱅 : 한번에

+ 하향식 : 위에서부터 아래로

+ 상향식 : 아래서부터 위로

+ 연쇄식 : 중요한 것을 중심으로 동시에

드라이버 : 시험 대상 모듈을 호출하는 모의 소프트웨어

스텁 : 시험 대상 모듈이 호출하는 또 다른 모듈

테스트 하니스 : 부분적인 테스트를 위해 코드에 삽입하는 프로그램, 추후 삭제

 

●빅뱅 통합

한번에 모든 모듈을 모아 통합 시험, 매우 작은 규모의 시스템 개발에 적절

장점 : 고도의 신뢰도가 요구되는 시스템의 경우 의뢰자에게 신뢰감을 줄 수 있음, 중요 부분을 먼저 구현함으로써 견고한 개발이 가능

단점 : 오류의 위치와 원인을 찾기 어려움, 단위 테스트에 많은 시간과 노려이 듦, 개발 진도를 예측하기 어려움

 

●하향식 통합

시스템 구조상 위층에 있는 모듈부터 통합

장점 : 중요한 모듈의 인터페이스를 조기에 테스트, 스텁을 이용해 시스템 모습을 일찍 구현 가능, 개발자 입장에서 용이

단점 : 입출력 모듈이 상대적으로 하위에 있어 테스트 케이스 작성 및 실행 어려움

 

●상향식 통합

시스템 구조상 최하위에 있는 모듈부터 통합

장점 : 점증적 통합 방식, 하위층 모듈을 상위층보다 더 많이 테스트

단점 : 초기에 시스템의 뼈대가 갖추어지지 않음. 상위층의 중요한 인터페이스가 마지막에 가서야 확인 가능, 의뢰자에게 시스템을 시험해 볼 기회를 충분히 제공 X

 

●연쇄식 통합

특정 기능을 수행하는 모듈의 최소 단위(thread)로부터 시작

상대적으로 중요한 모듈부터 개발

장점 : 초기에 시스템의 골격 형성, 시스템을 나누어 개발하기 쉬움

 

●Regression Testing(회귀 테스트)

오류를 발견하여 고치고 다시 원래 문제를 일으켰던 것을 테스트 확인, 수정이 예상대로 되었는지 확인하고, 수정된 것을 반복 테스트

수정된 부분이 다른 부분에 영향을 주어 예상하지 않은 오류를 발생시키지 않는지 확인, 수정 후 프로그램의 통합이 제대로 이루어졌는지 확인

 

●시스템 및 인수 테스팅

컴포넌트 통합 후 수행하는 테스트 기법

종류 : 기능, 성능, 보안, 사용성, 인수, 설치

 

●기능 테스트

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

사용자와 관련되어 있으며 오류를 유발할 가능성이 많은 테스트를 선정

사용사례 모델을 검토하고 오류를 일으킬만한 사용사례 인스턴스를 찾아낸다.

테스트 케이스(일반적인 사례, 예외적인 사례_

 

●성능 테스트

시스템의 여러 측면 테스트(작업 부하, 처리량, 반응 시간, 효율성, 자원 효율성)

스트레스 테스팅 : 시스템 처리 능력의 몇 배의 작업 부하를 처리하고 견딜 수 있는지 측정

성능 테스팅 : 정상적인 사용 환경에서 시스템의 성능을 측정하는데 사용

 

●인수 테스트

시스템을 당장 사용할 수 있도록 모든 준비가 되어 있는지 확인

개발자를 제외한 개발을 의뢰한 사람 또는 대리인이 테스트 수행

시스템 요구 분석서를 기반으로 한 테스트 수행

실제 업무 절차를 따라 테스트 수행

테스트 유형 : 알파 테스트, 베타 테스트