Testing

Testing(1)  정의  테스트는 오류를 발견하기 위한 작업  시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동의 방법을 사용하여 검사하고 평가하는 일련의 과정 [IEEE]  오류의 종류  원시코드가 예상한대로 동작하지 않는 경우  원시코드가 예상하지 못한 결과를 나타내는 경우  오류의 원인  시스템 자체  테스트 과정  테스트 오라클

Testing(2)  특성  테스트에 소요되는 자원  총 개발비용의 50% 이상  총 개발기간의 50% 정도  심리적으로 받아들이기 어려운 작업  독립된 팀을 구성하여 수행  A test of any program must be necessarily incomplete ==> 완벽한 테스트는 불가능  No way of knowing if the error detected is the last remaining error ==> 테스트 종료의 결정은 어려운 일

3 단계 테스트  단위 테스트 (unit test)  프로그래머가 실시하는 모듈에 대한 시험  White Box testing & Black Box testing  목적 : 모듈을 정확하게 구현하였는가 ?  통합 테스트 (integration test)  시스템을 구성하는 모듈을 모아 통합적으로 시 험  목적 : 모듈 사이의 인터페이스를 시험  인수 테스트 (acceptance test)  완성된 제품에 대한 시험  시스템을 사용할 환경에 설치하여 시험

생명주기 테스트 External specification Code Module interface specifications End user Program structure design System design Requirements Objectives Acceptance test Installation test System test Function test Integration test Module test

테스트 절차  테스트의 목표를 결정 (what)  테스트 방법을 결정 (how)  검사, 증명, 자동화 도구, …  Test Cases 를 개발  테스트 방법에 따라 상이한 테스트 케이스 적용  테스트 케이스 = 테스트 자료 + 실행 조건  예상되는 테스트 결과를 작성  Test Oracle: 테스트 케이스에 대한 예상 결과  테스트 케이스로 실행  테스트를 실시하는 단계  필요시 Test Harness 사용

테스트 방법 (1)  정적 분석  프로그램을 수행하지 않고 원시코드를 직접 시험  프로그램 분석, Walk through, 정적분석기, …  정적분석기가 제공하는 원시코드의 구조에 관한 정보 : 심볼 테이블, Call Graph, 논리흐름도, parameter list, …  동적 분석  모듈 또는 전체 시스템이 수행되는 동안의 동작을 시험  모듈 단위 : black box test, white box test, 구조중 심 테스트

테스트 방법 (2)  블랙 박스 테스팅  소프트웨어 인터페이스에서 시행  소프트웨어 기능의 작동 여부  적절한 입력이 받아들여 지는지 여부  정확한 출력 생성 여부  내부적인 논리 구조와는 관계없이 시스템의 외부 적 측면만을 시험  화이트 박스 테스팅  세부적인 절차의 시험  논리적인 경로를 시험 : 조건 및 루프들을 시험

시스템의 오류 패턴  오류 발견 패턴  초기에는 적당히 분산되어 발견  테스트가 진행될수록 오류가 발견된 모듈에서 더 많은 오류가 검출  오류가 많은 모듈을 고치는 것은 한계가 있음 # of errors / day probability oferror detection

Module Test  격리된 환경에서 하나의 모듈을 검증하는 테스트  설계 및 구현과 관련된 프로그램의 계산 특성을 집중적으 로 테스트  테스트 데이터는 프로그램의 기능과 형태에 매우 밀접하 게 관련  test stubs & test driver 가 필요  easy pinpointing and correcting errors  고려 사항  인터페이스 : 정보 입출력의 적절성 시험  지역 자료 구조 : 모듈이 실행되는 동안 자료의 무결성 유 지 여부를 시험  경계 조건 : 처리를 제한하거나 금지시키기 위해 설정된 경 계에서 모듈의 적절한 작동 여부를 시험  독립 경로 : 모듈의 모든 문장은 적어도 한번 실행됨을 확 인하기 위한 시험  오류 처리 경로 (error-handling paths)

White Box Test(1)  기본 용어  Segment: 같이 수행되는 코드 블록  원시코드 = segment + 선택 + 루프  Path: 원시코드에서 가능한 하나의 실행 경로  Path Domain: 특정 경로를 수행시키는 입력 값의 집합  Path Computation: 특정 경로를 따라 수행되는 기 능  Test Data: 입력 값 영역으로부터 어떤 기준에 따 라 선택된 입력 값  검증기준 (coverage): 테스트에 의하여 확인되는 원시코드의 범위

White Box Test(2)  논리흐름도 (logic-flow diagram)  모듈 내의 segment 를 vertex 로, 제어흐름을 edge 로 나타낸 그래프  논리흐름과 관계없는 부분은 생략  기본 구성 요소 Sequence If While Until

White Box Test(3)  White Box Test 란 ?  모듈 내부를 투명하게 들여다 보는 시험방법  모듈의 논리적 구조를 체계적으로 검증하는 구 조적 테스트  검증기준의 개념을 기반으로 함  White Box Test 절차  논리흐름도 작성  선형적으로 독립적인 경로의 기본 집합 결정  경로를 실행시킬 수 있는 테스트 케이스 준비  테스트 케이스 수행  테스트 결과를 토대로 오류의 발견 및 정정

White Box Test(4)  오류의 종류  Domain Error: 제어 흐름에서의 에러로 인해 잘못된 경로를 따르는 경우  Computation error: 정확한 경로를 따르지만 잘 못된 기능이 수행되는 경우  Missing Path Error : 요구되는 조건이 프로그 램에 나타나지 않는 경우  Infeasible Paths : 어떤 입력 값에도 수행되지 않는 경로  Coincidental Correctness : 부정확한 경로를 따를지라도 우연히 정확한 결과를 생성하는 경 우

White Box Test(5)  테스트 종결 기준의 종류  검증기준 척도  검증기준 (coverage) 를 기초로 테스트 케이스를 설계  검증기준에 의한 경로를 모두 cover 하면 테스트 종결  신뢰도 향상 모델  테스팅을 통해 신뢰도가 향상되는 정도를 측정하여 종결 여부를 결정  에러 통계  미리 정의된 에러의 수를 기초로 테스트 케이스를 설계  각 단계마다 error rate 및 detection rate 등을 평가  발견된 에러를 관찰하여 테스트 종결을 결정

White Box Test(6)  검증기준 (Coverage) 의 종류  Segment coverage  모듈의 모든 segment 가 적어도 한번은 수행  Decision (or Branch) coverage  segment coverage 를 포함  선택구조에 대하여 모든 경우를 한번 이상 테스트  Loop coverage  segment coverage 및 decision coverage 포함  모든 루프에 대하여 루프의 몸체를 한번도 수행하지 않는 경 우, 한번만 수행하는 경우, 한번 이상 수행하는 경우를 테스트  Path coverage  수행 가능한 모든 경로를 테스트  Condition coverage  조건식의 sub-condition 모두를 테스트

White Box Test(7)  테스팅 사례 if y > 1 then y = y + 1 if y > 9 then y = y + 1 else y = y + 3 end y = y + 2 else y = y + 4 end if y > 10 then y = y + 1 else y = y – 1 end Input Domain Program Output y > 8y < y <= 8y < y <= 4y + 5 y <= 1y + 3 Program Path Path Condition T T T y > 8 T T F infeasible T F T 4 < y <= 8 T F F 1 < y <= 4 F - T infeasible F - F y <= 1

Black Box Test(1)  Black Box Test 란 ?  모듈이 요구에 맞게 작동하는가를 시험  기능 테스트 (function test) 라고도 부름  동치분할 기법 또는 경계값 분석 기법을 사용하여 테스트 케이스 설계  블랙 박스 테스팅을 통해 발견 가능한 에러  부정확하거나 누락된 기능  인터페이스 에러  자료구조나 외부 데이터베이스 접근에 있는 에러  성능 에러  초기화 및 종료 에러

Black Box Test(2)  동치 분할 (equivalence partitioning)  프로그램의 입력 도메인을 equivalence class 로 분할  동치 클래스의 발견 1. 범위 (range) 입력 조건 : 범위보다 작은, 범위 내, 범위 보다 큰 클래스로 구분 2. 특수한 값 (value) : 값보다 작은, 특정 값, 값보다 큰 클 래스로 구분 3. 집합 (set) : 집합 내, 집합 외 클래스로 구분 4. 논리 조건 (boolean) : TRUE, FALSE 클래스로 구분  테스트 케이스 : 각 클래스로부터 추출된 대표 값

Black Box Test(3)  Boundary testing  많은 수의 오류가 입력 도메인의 경계에서 발생  동치 분할 방법을 보완하기 위하여 사용  경계값 분석 지침 입력 조건이 값 a 와 b 의 영역인 경우 => a 와 b 의 바로 위 값과 아래 값 입력 조건이 다수의 값인 경우 => 최대 수와 최소 수의 바로 위와 아래 값 내부 자료 구조의 경계 지정 => 경계 값의 바로 아래, 경계 값, 경계 값의 바로

Black Box Test(4)  테스팅 사례 - 식료품 점의 전산화  요구 : 식료품의 무게는 1 부터 48 사이의 값을 가질 수 있으며, 소수점을 갖지 않는 숫자이다  생성된 동치 클래스  1 보다 작은 값 ( 비정상 ) : 0  1 과 48 사이의 값 ( 정상 ) : 24  48 보다 큰 값 ( 비정상 ) : 100  정수 ( 정상 ) : 24  실수 ( 비정상 ) : 7.9  숫자 ( 정상 ) : 24  숫자 아님 ( 비정상 ) : 5%

통합 테스트 (1)  통합 테스트의 목적  시스템을 구성하는 모듈의 인터페이스를 검사  시스템 전체의 기능 및 성능을 검사  통합 테스트의 종류  비 점진적 테스팅 : "big bang" 테스팅  점진적 테스팅  하향식 (top-down)  상향식 ( bottom-up)  연쇄식 (threads): 특수하고 중요한 기능을 수행하는 최소 모듈 집합을 우선적으로 구현하는 방법

통합 테스트 (2)  테스팅 종결 기준  모듈 호출  모든 가능한 응답  Parameter 전달 A DCB FEG

통합 테스트 (3)  Test harness  시스템을 테스트하기 위하여 작성된 별도의 프 로그램  테스팅이 끝난 후 삭제  Test driver: 시험 대상 모듈을 호출, 파라메터 를 전달, 모듈 수행 후의 결과 제시. 상향식 테 스팅에 필요  Test stub: 시험 대상 모듈이 호출하는 다른 모 듈의 기능을 간략히 수행. 메시지 출력, 상수 값 반환,....

통합 테스트 (4)  동시식 통합  오류를 발견하기가 어려움  모든 모듈을 구현한 후 테스트를 시작하므로 일정계획에 융통성이 없음  하향식 통합  개발 초기부터 시행 가능  상위 층의 핵심적인 부분이나 인터페이스에 대 해 조기에 검사함으로써 위험 감소  test harness 를 자연스럽게 제공  테스트 조건을 생성하기가 매우 어렵다

통합 테스트 (5)  상향식 통합  최하위 모듈부터 시스템 전체로 점진적으로 통 합하므로 에러를 발견하기 쉽다  하위 층 모듈을 더 많이 테스트하기 때문에 중 요한 기능이 하위 층에 많은 경우 효과적  개발 초기에 시스템의 전체 구조 파악이 어려 움  연쇄식 통합  일반적으로 최선의 통합 방법  특정 기능을 수행하는 모듈부터 시작  초기에 시스템의 골격을 보여주고, 사용자로부 터 feedback 을 받을 수 있음

구조 테스트  정의  기본 개념은 white box test 와 유사  구조도에 있는 모든 경로와 sub-system 사이의 호출 관계를 점검  테스트 케이스 작성  Transaction flow diagram 을 사용  transaction = 특정한 입력 자료와 관련된 작업의 집합  처리흐름도 : 처리 과정에서 호출되는 모듈을 리 스트 또는 도표로 표현

기능 테스트  정의  시스템의 외부 명세에 기술된 시스템의 기능을 검사  black box test 와 유사  테스트 케이스 작성  동치 분할 (Equivalence Partitioning)  프로그램 도메인을 몇 개의 동치 클래스로 분할  각 클래스의 대표 값 + 경계 값 추출  specification based testing

시스템 테스트  정의  시스템이 초기 목표에 맞게 동작하는가를 검증  시스템의 초기 목표 (objectives) 로부터 외부 명세를 작성 하는 동안에 발생한 에러에 대해 집중 검사  테스트 항목  Usability  Security  Performance  Reliability  Maintainability  Compatibility/Conversion

인수 테스트  정의  시스템이 사용 가능한 상태에 있는지를 확인  특정 사용자를 위한 소프트웨어  사용자가 테스트 방법을 선택  사용자 환경에서 수행  대부분 통합 테스트와 동일한 방법 사용  성능 테스트 및 스트레스 테스트 포함  불특정 다수 사용자를 위한 소프트웨어  알파 테스트 : 선택된 사용자가 개발환경에서 시험  베타 테스트 : 고객의 사용 환경에서 개발자의 참여 없 이 수행

테스트 자동화 도구 (1)  코드 분석 도구  정적 분석 도구  프로그램을 실행하지 않고 원시코드를 분석하여 오 류 발견  코드분석 도구, 구조검사 도구, 데이터분석 도구, 순 서검사 도구  동적 분석 도구  프로그램이 수행되는 동안 이벤트의 상태를 파악하 기 위하여 변수나 조건의 snapshot 을 생성  프로그램 모니터라고도 부르며, 시스템의 성능을 평가하는데 도움을 줄 수 있음

테스트 자동화 도구 (2)  테스트 케이스 생성 도구  자료흐름도 이용 방법  기능 테스트 방법  입력 도메인 분석 방법  랜덤 테스트 방법  테스트 실행 도구  capture & replay  stub & test driver  자동 테스트 환경