정의 |
° 노출되지 않은 숨어있는 결함을 찾기위해 SW를 작동시키는 일련의 행위와 절차로 오류발견을 목적으로 프로그램을 실행하여 품질을 평가하는 과정 |
목표 |
° 잠재된 오류의 발견
° 기술적인 기능 및 성능의 향상
° 사용자 만족도, 신뢰도 향상 |
특징 |
° 결함이 있다는 가정하에 테스트 계획을 수립 및 테스트 케이스 작성하여 실행
° 개발자가 자신의 프로그램을 직접 테스트 하지 않음(테스트의 결과로 디버깅수행)
° 성공적인 테스트는 무결점이 아닌 결함을 찾는데 있음
° 소프트웨어 개발의 노력분포는 40-20-40 법칙을 따른다(설계-개발-시험) |
절차 |
° 테스트 목표 설정(What) → 테스트 방법 결정(How) → 테스트케이스 개발 → 예상결과 작성 → 테스트케이스 실행 |
단계별 분류 |
단위
테스트 |
° 컴파일된 독립모듈의 완전성을 따져보는 모듈시험(Module Test)
° 자료구조, 수행경로, 오류처리, 경계, 인터페이스 테스트 등이 있음(White Box기법을 주로 사용) |
통합
테스트 |
|
Top-Down(하향식) |
Bottom-Up(상향식) |
내용 |
° 최상위 모듈에서 하위 모듈로 테스트 수행 |
° 최하위 모듈에서 상위 모듈로 테스트 수행 |
장점 |
° 실사용 환경과 유사한 테스트 |
° 테스트 용이, 초기에 병행 작업 가능
° 대형 시스템에 적합 |
단점 |
° Stub 모듈 작성에 많은 시간 소요 |
° Cluster분류 곤란
° I/F 점검이 가정상태로 진행됨 |
특징 |
° Stub모듈이 필요
° Menu방식 SW개발에 적용
° 회귀테스트(Regression Test) |
° 모듈의 신뢰성 향상 가능
° 최종결과 산출 곤란
° 마지막 단계까지 주요 결함 발견이 어려움 | ° 모듈간의 인터페이스와 관련된 결함을 발견하고 제거하면서 모듈들을 체계적으로 통합시키는 작업
※ 회귀테스트
- 이미 수행했던 시험의 부분집합을 다시 실행(테스트 재사용 관점)
- S/W의 변경으로 영향받게 될 S/W의 기능에 초점을 맞춘 추가 시험
- 변경이 다른 부분에 영향을 주는지, 통합이 제대로 이루어 졌는지 확인
※ 연쇄식 테스트(Threads Test)
- 입출력과 최소 기본 기능을 갖는 중요 모듈들의 집합을 먼저 통합 테스트 진행
- 부가적 기능의 모듈들은 점차적으로 구현 테스트하여 통합해 나감
- 초기에 시스템의 골격을 알 수 있고 사용자의 의견을 빠르게 수정할 수 있음 |
시스템
테스트 |
° 사용자의 신뢰성을 확보하기 위해 컴퓨터, 네트워크 제반 모든 사항에 관계된 테스트
° 시험목적에 따른 분류 - 회복, 안전, 강도, 성능, 구조 테스트 |
인수
테스트 |
° 요구를 불만족하는 Negative한 케이스 추출, 사용자측 관점에서 SW요구사항을 충족시키는지를 평가
° 확인(Validation)
° 알파테스트 - 특정 사용자에 의해 개발자 관점에서 수행, 개발자는 사용상의 문제점을 기록, 반영
° 베타테스트 - 선정된 다수의 사용자들이 자신의 사용환경에서 일정기간 사용하면서 문제점, 개선사항을 기록하고 개발조직에 통보하여 반영되도록 함(잘못된 요구분석의 발견) |
설치
테스트 |
° SW를 사용자 환경에 설치하는 과정중에 나타날 수 있는 결함을 발견할 목적으로 수행하는 테스트 | |
시험 시각 |
검증(Verification) |
° 개발자, 시험자의 시각으로 SW가 명세화된 기능을 올바로 수행하는지 알아보는 과정
° 어느 단계의 산출물이 이전 단계에서 설정된 개발규격과 요구들을 충족하는지의 여부를 판단 |
확인(Validation) |
° 사용자 시각으로 올바른 SW가 개발되었는지를 입증하는 과정
° 어느 단계의 개발제품이 최초의 사용자 요구 또는 SW 요구에 적합한지 입증하기 위한 활동 |
공인(Certification) |
° 사용자 혹은 사용자를 보호하는 입장의 전문가가 SW 품질을 공식적으로 확인하는 것 | |
시험 방법 |
Black Box
(Dynamic Test) |
° 명세기반시험(Spec-based testing), 입출력시험(Input/Output testing), 기능시험(Functional testing) 으로 지칭됨
° 데이터, 입출력 위주 시험
° 동등분할 기법, 경계값 분석, Cause-Effect Graph, 결함예측기법, 비교검사 |
White Box
(Static Test) |
° 프로그램상의 모든 논리적 경로, 복잡도를 계산하여 시험사례를 만들어 테스트를 수행하는 기법
° 데이터 흐름 검사(Data flow testing), 구조시험, 루프시험
※ 구조시험 - Macabe에 의해 제안된 대표적 화이트 박스 기법
- condition coverage > branch coverage(Decision Coverage) > statement coverage
※ 복잡도 척도
Macabe |
Halstead |
° 사이클로매트릭의 수(보통 10을 넘지 않음)
° 경계된 영역들과 그래프 외부의 비경계지역의 수 |
° 원시코드에 표현된 사실로부터 계산되는 여러 가지 척도를 제안
° 프로그램의 유사성 검출 용도로도 사용 |
° V(G) = Edge - Node + 2(= DecisionCount + 1)
° 복잡도 평가
~ 10 : 매우 간단한 Program
~ 20 : 구조적이고 안정된 Program
21 ~ 50 : 복잡한 구조의 Program
50 ~ : 비구조적, 불안정 Program |
° 연산자의 종류(n1), 피연산자의 종류(n2)
° 총연산자의 수(N1), 총피연산자의 수(N2)
° 프로그램의 길이
° 프로그램의 부피
° 언어추상화 레벨(최소부피)
° 프로그래밍 노력 E = V/L | | |
TMM (Test Maturity Model) |
|
정의 |
활동 |
초기 |
° 시험 프로세스가 정립되지 않음 |
|
정의 |
° 시험과 디버깅의 구분
° 시험이 SW 생명주기에서 하나의 독립된 단계로 정의됨 |
° 목표설정, 계획수립, 변경제어, 추적 및 감시 |
통합 |
° 시험이 SW 생명주기 전체에 걸쳐 이루어짐 |
° 조직 구성, 교육훈련, 회귀시험
° 시험 프로세스의 제어 및 감시 |
관리/측정 |
° 시험 활동이 측정되고 정량화 됨 |
° 검토, 측정, 품질평가 |
최적화 |
° 결점예방 및 품질제어 활동 |
° 결점예방, 품질제어, 프로세스 최적화 | |
V & V Model |
° 분석과 설계에 대한 반복적인 검증으로 요구사항에 대한 정확한 이해를 높인다 |