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

Presentation on theme: "Testing. Testing(1)  정의  테스트는 오류를 발견하기 위한 작업  시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동의 방법을 사용하여 검사하고 평가하는 일련의 과정 [IEEE]  오류의 종류  원시코드가."— Presentation transcript:

1 Testing

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

3 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 ==> 테스트 종료의 결정은 어려운 일

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

5 생명주기 테스트 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

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

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

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

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

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

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

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

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

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

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

16 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 모두를 테스트

17 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 + 5 4 < y <= 8y + 7 1 < 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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