S/W Testing introduction 작성자 : 강정훈 작성일 : 2010-03-19.

Presentation on theme: "S/W Testing introduction 작성자 : 강정훈 작성일 : 2010-03-19."— Presentation transcript:

1 S/W Testing introduction 작성자 : 강정훈 taru00@naver.comtaru00@naver.com 작성일 : 2010-03-19

2 2 1. 시간, 인력이 부족해서 테스팅을 제대로 못한다. 2. 테스트는 완벽하게 수행 될 수 있다. 3. 테스트는 그리 어려운 작업이 아니다. 4. 아무나 테스트를 수행 할 수 있다. 5. 프로그램이나 시스템이 잘 수행될 수 있음을 보여주는 것이다. 6. 테스트는 개발 이후의 작업이다. 7. 개발일정에 따라 테스트는 생략 될 수 있다. S/W 테스팅에 대한 오해

3 3 1. 테스팅은 결함이 존재함을 밝히는 활동 2. 완벽한 테스팅 (Exhaustive testing) 은 불가능하다 3. 개발 초기에 테스팅을 시작하라 4. 결함 집중 5. 살충제 패러독스 6. 테스팅은 정황 (Context) 에 의존적이다 예 ) 대상 S/W 가 safety critical 인 경우와 mission critical 인 경우 서로 테스팅 전략이 다르다 7. 오류 - 부재의 궤변 (Absence-of-errors fallacy) S/W 테스팅의 일반 원리

4 4 Criteria  테스팅의 정의 초창기 “ 코딩 작업의 일부 ” 테스팅은 프로그램이 당연히 수행되어야 할 기능을 수행하고 있음을 확신하는 과정 현재 “ 결함을 발견하는 것 ” Testing is the process of analyzing a software item to defect the difference between existing and required conditions (that is defects/error/bugs) and to evaluate the features of the software items. [IEEE/ANSI, Std 829-1998] Testing is a concurrent lifecycle process of engineering, using and maintaining testware in order to measure and improve the quality of the software being tested. Rick D. Craig, 2002, “Systematic Software Testing”

5 5 Criteria  오류 (Error)  잘못된 결과를 낳는 인간의 행위 (Action), 실수 (Mistake)  결함 (Defects, Bug, Fault)  요구된 기능의 부정확한 처리  장애 (Failure) 를 발생시키는 원인  장애 (Failure)  결함의 실행 또는 환경적 조건에 의해 의도된 대로 동작하지 않거나 동작하지 말아야 함에도 동작하는 경우

6 6 Criteria Test Basis 요구사항을 내포하고 있는 모든 문서 테스트 케이스는 테스트 베이시스를 토대로 만들어 진다 Test Case 특별한 목표 또는 테스트 상황을 테스팅 하기 위해 개발된 입력 값, 실행 사전조건, 예상결과, 사후 조건 들의 집합 Test Suite 여러 테스트 케이스의 집합 False-fail result (False Alarm) 결함이 아닌데도 결함으로 보고된 테스트 결과

7 7 테스트 수명주기

8 8 테스트 수명주기 – Multiple V 모델 Bart Broekman, Testing Embedded Software, 2002 Design Test Build Design Test Design Test Iteration (4 주 ~5 주 ) Milestone (1~3 Iteration)

9 9 테스팅 종류 1. 정적 테스팅  리뷰  정적 분석 2. 동적 테스팅  L) Acceptance 테스트  L) System 테스트  L) Integration 테스트  L) Unit 테스트  D) Specification based 테스트  D) Structure based 테스트  D) Experience based 테스트  Confirmation 테스트, Regression 테스트  Smoke 테스트 or Sanity 테스트  Functional 테스트, Non-Functional 테스트  BlackBox, WhiteBox 테스트

10 10 정적 분석의 특징 1. 리뷰와 마찬가지로 장애 (Failures) 보다는 오류 (Error) 나 결함 (Defects) 을 발견함 2. 대상 소프트웨어를 실행하지 않는 상태에서 툴의 지원으로 수행하는 것 3. 정적 분석의 가치  테스트 실행 전 조기 결함 발견  복잡도 분석  소프트웨어 모델상의 의존도와 불일치성 (Dependencies and inconsistencies) 발견  코드와 설계의 유지보수성 (Maintainability) 향상

11 11 정적 분석 툴을 통해 발견되는 결함 1. 해제되지 않은 자원 (Resource Leak) 2. 비효율적인 메모리 할당 3.Type Check 없이 강제 Casting 4. 정의 되지 않은 값으로 변수 참조 5. 사용되지 않는 변수 6. 사용되지 않는 코드 (Dead code) 7. 코딩 표준 위반 8. 구문 규칙 (Syntax) 위반 … 이외에도 툴마다 수백여 종의 Rule 들이 있다

12 12 정적분석 툴 RSAR 적용 사례 Resource Leak Stream Object 를 생성 / 사용 하고 Close 를 하지 않은 경우 메모리 누수 발생 Public class ClassA { public void makeStream (InputStream iStream) { try { BufferedInputStream stream = new BufferedInputStream(iStream); stream.read(); //do something… stream.close(); } catch (IOException e) { //stream leaked… }

13 13 테스트 레벨 별 특징 단위 테스트통합 테스트시스템 테스트 인수 테스트 Focus, 목적 개발 초기에 가능한 많은 결함 제거 통합 과정에서 발생되는 side effect 검증 전체 시스템의 기능상의 결함, 비기능적 요소 확인 요구사항과의 일치성 검증 수행 주체 개발자, 개발조직내 테스터 개발자, 개발조직내 테스터, 독립적 테스터 독립적 테스터, 사용자 환경 개발 환경 (Driver, Stub) 개발 환경 (Driver, Stub) 실제 시스템과 같거나 유사한 환경 ( 시뮬레이터 ) 사용자 환경

14 14 Integration 테스팅 접근법 Device Computing Environment Game Engine Game Core Presentation 1. Big bang 통합

15 15 Integration 테스팅 접근법 Game Core 3. Backbone 통합 Stub Test Driver

16 16 Integration 테스팅 접근법 Device Computing Environment Game Engine Game Core Presentation 2. Bottom up 통합 Test Driver

17 17 Integration 테스팅 접근법 Device Computing Environment Game Engine Game Core Presentation 3. Top down 통합 Stub

18 18 테스트 베이시스 ( Test Basis ) 테스트 케이스 ( Test Case ) 개발 체크리스트 리스크 분석 결과 결함 분석 결과 정적 분석 결과 커버리지 분석 결과 요구사항 명세서 테스트 케이스

19 19 경험 기반 기법 1. 탐색적 테스팅 (Exploratory testing)  You test while you explore  테스트 차터 (Charter)  시간 제한 (Time Box)  체크리스트 (Checklist) 2. 오류 추정 (Error Guessing), 결점 공격 (Fault attack)  테스터의 경험을 사용하여 결함을 예측하고,  해당 결함만을 중점적으로 검출하는 테스트를 설계 3. 분류 트리 (Classification tree)  계층적으로 정렬된 등가 분할 (equivalence) 을 보여주는 트리 사용  입력 및 출력 도메인의 대표값을 조합하여 수행하도록 설계

20 20 경험 기반 기법 -- 탐색적 테스팅 시간 제한 (Time Box) tester1tester2tester3 Heuristics Charter 1 Charter 2Charter 3

21 21 TC2 TC3 TC1 경험 기반 기법 – 분류 트리 Example 해상도 32bit 언어 그림자 유무 Color Depth 게임 옵션 800x600 1024x768 16bit O O X X 한국어 영어 디바이스 지원시 디바이스 미지원시

22 22 명세 기반 테스트 설계 기법 1. 등가분할 ( Equivalence Partitioning) 2. 경계값 ( Boundary Value ) 3. 결정테이블 ( Dicision Table) 4. 상태전이 ( State Transition ) 5. 유즈케이스 ( UseCase )  유즈 케이스에서 테스트케이스를 도출 6. 조합 테스팅 ( pairwise )  Allpairs 라는 도구로 조합 자동 생성 가능  http://www.satisfice.com/tools.shtml http://www.satisfice.com/tools.shtml

23 23 등가분할 Example 100 80 60 40 20 0 구분입력값 TC Invalid100 < x <= INT_MAX1 Valid 80 < x <= 1002 60 < x <= 803 40 < x <= 604 20 < x <= 405 0 < x <= 206 Invalid-INT_MAX <= 07

24 24 등가분할 Example 100 80 60 40 20 0 구분입력값 TC Invalid INT_MAX1 1012 Valid 1003 814 805 616 607 418 409 2110 2011 112 Invalid 013 -INT_MAX14

25 25 구조 기반 테스트 설계 기법 1.Control Flow 2. 구문커버리지 SC 3. 결정커버리지 DC 4.CC 5.C/DC 6.MC / DC 7.MCC

26 26 Clover Screen Capture

27 27 리스크 기반 테스팅 전략 사례 ITA (Intensive Test Area) STA (Severe Test Area) FTA (Fundamental Test Area) STTA (Strong Test Area) Impact Likelihood 상위 레벨 테스트 (Low level test) 1.Basic & Alternative Usecase testing 2.Non-Functional testing 3.Decision coverage 60% 1.Basic Usecase testing 2.Decision coverage 50% 1.Statement coverage 40% 1.Exploratory testing 2.Statement coverage 50%

28 28 리스크 기반 테스팅 전략 사례 ITA (Intensive Test Area) STA (Severe Test Area) FTA (Fundamental Test Area) STTA (Strong Test Area) Impact Likelihood 하위 레벨 테스트 (Low level test) 1.Formal testing design 2.Boundary value analysis 3.Decision coverage 60% 4.Code inspection 1.Decision coverage 50% 2.Peer review 1.Statement coverage 40%1.Exploratory testing 2.Statement coverage 50%

29 29 테스트 프로세스 1. 테스트 계획 과 제어  조직 구성, R&R, MBO 수립  테스트 목적 / 목표 설정 및 대상 연구  테스트 전략 수립  테스트 진입조건, 완료 조건 설정 2. 테스트 분석과 설계  테스트 베이시스 검토  테스트 상황 / 요구사항 / 데이터 식별  테스트 기법 할당  테스트 환경 구축 3. 테스트 구현  테스트 케이스 구현 4. 테스트 실행  테스트 진입 조건 확인  Sanity 테스트 수행  ( 재 ) 테스트 수행  테스트 결과 기록 5. 테스트 완료조건 평가, 리포팅  완료 조건의 달성 여부 확인  미달성시 Round-Up or Cut-In 요청 6. 테스트 마감 활동  산출물 확인  프로세스 개선 활동

30 30 Entrance / Exit Criteria Example 1.Entrance Criteria  Release Note 문서 제공  Change History 문서 제공  Feature 구현 목록 제공  TR 시스템으로 의뢰 및 개발 PL 승인  디바이스 및 테스트 환경 제공 2.Exit Criteria  No Compile Error in Unit Test  Unit Test Pass Rate 95%  All System Test Case 수행  System Test Pass Rate 90%  System Test Execution Rate 80%  Compatibility Check List Pass Rate 80%  No Critical/Major Defects  MTTF 2 시간 이상

31 31 테스트 케이스 Example

32 32 테스트 보고서 Example Unit Test Report Sample

33 33 테스트 보고서 Example Defect Trend Report 누적결함 S 커브

34 34 테스트 보고서 Example Build Pass Rate

35 35 참고자료

36 36 http://datasyncxml.tistory.com/118