소프트웨어 테스트(Software Test), 테스팅기법

○ 소프트웨어 테스트
 

정의	° 노출되지 않은 숨어있는 결함을 찾기위해 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	° 분석과 설계에 대한 반복적인 검증으로 요구사항에 대한  정확한 이해를 높인다

[관련 포스트] 2008/09/25 - [IT 노트/소프트웨어공학] - 소프트웨어비용산정(Doty, Putnam, COCOMO, COCOMO II, Function Point) 2008/08/21 - [IT 노트/소프트웨어공학] - 소프트웨어 분석 및 설계