소프트웨어 테스팅

20,897 views

Published on

Published in: Technology
1 Comment
68 Likes
Statistics
Notes
No Downloads
Views
Total views
20,897
On SlideShare
0
From Embeds
0
Number of Embeds
556
Actions
Shares
0
Downloads
1,187
Comments
1
Likes
68
Embeds 0
No embeds

No notes for slide

소프트웨어 테스팅

  1. 1. Time goes now Software Testing Fundamentals Made in 2013.02 SE Lab 김영기 책임If I sleep now I will have a dream, but if I study now I will make my dream com true …
  2. 2. Contents Time goes now 1 소프트웨어 테스팅의 기초 2 소프트웨어 개발과 테스팅 3 정적 테스팅 기법 4 동적 테스팅 기법 5 요구사항과 테스트 설계 6 테스트 관리 도구What’s your point ? 2 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  3. 3. Time goes now 소프트웨어 테스팅의 기초What’s your point ? 3 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  4. 4. 소프트웨어 테스팅의 정의 Time goes now 소프트웨어 테스팅이란 … 소프트웨어의 테스트는 수동이나 자동으로 시스템을 시험 작동시키고 평가하는 작업으로 명시된 요구를 잘 만족하는지, 즉 예상된 결과와 실제 결과와의 차이를 인식하기 위한 목적을 가진다 - IEEE  컴퓨터 소프트웨어를 실행하여 그 결과가 올바른지 판단하는 과정  Executing software in a simulated or real environment, using inputs selected somehow  사용자의 기대 수준과 요구사항에 맞게 구현되었는지 확인 소프트웨어 테스팅의 목적 관점에 따라 각기 다른 여러 가지  요구사항 충족 확인 목적을 가진다.  결함 발견 또는 결함 방지  소프트웨어 품질 수준에 대한 확신을 얻고, 정보를 제공  소프트웨어의 여러 측면 평가  메모리 사용량 (Memory Usage)  신뢰성(Reliability), 성능(Performance), 보안(Security), 사용성(Usability)What’s your point ? 4 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  5. 5. 소프트웨어 테스팅의 목적 Time goes now 주 목적 상세 목적  남아 있는 결함 발견  품질에 대한 확신, 정보 제공  명세 충족 확인  비즈니스 리스크를 감소  사용자 및 비즈니스 요구 충족 확인  개발 프로세스 점검, 이슈제기  결함 예방  논리적 설계의 구현 검증 개발 주기에 따른 테스팅의 목적 단계 목적 개발과정  소프트웨어 결함을 찾아내고, 수정하기 위해 가능한 많은 장애 발생 인수과정  예상대로 시스템이 동작하는지 확인, 요구사항에 맞는지 확인 품질 평가  특정시간 안에 출시하는 제품의 리스크를 개발 프로젝트에게 전달 유지 보수  변경 작업이 일어나는 경우, 새로 유입되는 결함이 있는지 확인 운영 과정  신뢰성 또는 가용성과 같은 시스템의 특성을 평가What’s your point ? 5 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  6. 6. Bug, Error, Fault, Failure Time goes now 오류(Error)  잘못된 결과를 만드는 사람의 행위 결함(Defect, Bug, Fault) :  소프트웨어 상의 Error를 일으킬 수 있는 징후  요구 기능의 부정확한 처리  Failure의 원인이 될 수 있다. 장애(Failure)  예상과 다르게 동작하는 소프트웨어의 의도하지 않은 결과 A person makes … that creates a … that can cause an error ... fault in the a failure software ... in operationWhat’s your point ? 6 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  7. 7. Test Terms Time goes now Test Basis  요구사항을 내포하고 있는 모든 문서  테스트 케이스는 테스트 베이시스를 토대로 만들어 진다 Test Harness  시스템 및 시스템 컴포넌트를 시험하는 환경의 일부분으로 시험 지원을 목적으로 생성된 코드와 데이터 Test Oracle  테스트 실행 결과의 참/거짓 판별 기준 Test Suite  여러 테스트 케이스의 집합 False-fail result (False Alarm)  결함이 아닌데도 결함으로 보고된 테스트 결과What’s your point ? 7 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  8. 8. 테스팅 원리 Time goes now 원리 1. 테스팅은 결함이 존재함을 밝히는 활동이다.  결함이 없다는 것은 증명할 수 없다. 원리 2. 완벽한 테스팅(Exhaustive)은 불가능하다.  무한 경로, 무한 입력 값, 무한 타이밍  리스크 분석과 결정된 우선 순위에 테스팅을 집중 원리 3. 테스팅을 개발 초기에 시작한다.  개발 시작과 동시에 테스트를 계획, 전략적으로 접근  Test case 를 도출하면서 문서상의 결함 발견 Be effective 원리 4. 결함 집중 (Defect Clustering)  적은 수의 모듈에서 대다수의 결함 발견 (결함과 장애가 집중) 원리 5. 살충제 패러독스 (Pesticide Paradox)  동일한 테스트를 반복적으로 수행하면 버그를 찾기 힘듦  경험 기반 기법을 통해 테스트 방법을 다양화 Be efficient 원리 6. 테스팅은 정황(Context)에 의존적이다.  효율적, 효과적 테스트 팀 조직, 독립적 테스트 환경 원리 7. 오류-부재의 궤변 (Absence-of-errors fallacy)  사용자 요구사항에 맞지 않는다면 결함을 찾고 수정하는 것은 무의미  결함을 모두 발견했다고 해도 품질이 높다고 할 수 없음What’s your point ? 8 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  9. 9. 테스팅 프로세스 Time goes now 테스트 프로세스의 주요 활동  계획과 통제(Planning and Control) 논리적으로는 순차적이지만,  분석과 설계(Analysis and Design) 중첩되거나 동시에 진행이 가능  구현과 실행(Implementation and Execution)  종료 기준의 평가와 보고(Evaluating exit criteria and Reporting)  테스트 마감 활동(Test Closure activities) Execution Analysis Planning Design Implement Closure Evaluating exit criteria Reporting test results Control Project Timeline [ISTQB fundamental test process]What’s your point ? 9 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  10. 10. 1. Test Planning Time goes now Test Planning – Different Levels  테스트 전략과 프로젝트 테스트 계획을 어떻게 적용할 것인가?  테스트 환경  Testware Test Policy  Stubs, Drivers Company level  테스트 종료 조건 … Test Strategy  문서화 Project level (IEEE 829) High Level High Level : one for each project Test Plan Test Plan Test stage level (IEEE 829) Detailed : one for each stage within a project, Detailed Test Detailed Plan e.g. Component, System, Etc. Test Detailed Plan Test Plan Test PlanWhat’s your point ? 10 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  11. 11. 2. Test Analysis Time goes now 테스트 명세 (3 Steps) 정의 설계 구축 (Identify) (Design) (Build) Importance  무엇을 테스트 할 것인가? Best  테스트 조건 set 8  어떤 것을 먼저 테스트 할 것인가?  우선 순위화 First set Time Prioritise tests It is difficult to determine so that, How much testing is enough whenever you stop testing, But it not impossible you have done the best testing in the time available.What’s your point ? 11 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  12. 12. 3. Test Design Time goes now 테스트 명세 (3 Steps) 정의 설계 구축 (Identify) (Design) (Build)  어떻게 테스트 할 것인가?  Test case 작성 • 선행 조건, 테스트 환경 요구사항, 입력 및 필요 데이터, 예상 결과, 사후 조건  IEEE 829 • Test case specification identifier • Test items (what is to be delivered and tested) • Input specifications (user inputs, files, etc.) • Output specifications (expected results, including screens, files, timing, etc.) • Environmental needs (hardware, software, people, props, and so forth) • Special procedural requirements (operator intervention, permissions, etc.) • Inter-case dependencies (if needed to set up preconditions)What’s your point ? 12 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  13. 13. 4. Test Implementation Time goes now 테스트 명세 (3 Steps) 정의 설계 구축 (Identify) (Design) (Build)  테스트 케이스 구현  테스트 스크립트 작성  테스트 데이터 준비  예상 결과 정의  문서화  Test Oracle  테스트 실행 결과가 올바른 결과인지를 판별할 수 있는 메커니즘  True Oracle, Sampling Oracle, Heuristic Oracle, Consistent OracleWhat’s your point ? 13 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  14. 14. 5. Test Execution Time goes now 가장 중요한 것부터 실행 모든 TC를 다 실행해야 하는가?  테스팅은 결함의 Fix를 목적으로 한다.  초기의 테스트에 의하여 결함이 너무 많이 발견되는 경우  일정의 압박  새로운 TC의 생성 자동화 여부 False Positive, False Negative Logging IssueWhat’s your point ? 14 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  15. 15. 6. Evaluating exit criteria & Reporting test results Time goes now Dash board – KPI (Key Performance Indicate) IEEE 829 – Reporting Template  테스트 요약 보고 정의  요약 (예를 들어, 무엇이 테스트 되었는지, 결과가 어떠한지 등..)  변경 사항 (계획, TC, 절차)  종합적인 평가  결과의 요약 (예를 들어, 최종 매트릭, 개수)  평가 (Pass/Faile 항목과 비교한 각 테스트 아이템에 대한)  액티비티 요약 (자원 사용, 효율, 등)  승인 사항What’s your point ? 15 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  16. 16. 7. Closure Time goes now 테스트 종료를 결정  테스트 종료 조건이 모든 레벨의 테스트에서 만족됨을 확인  Branch 커버리지  사용자 요구사항  비용과 시간  발견된 결함 수 (예상 대비)What’s your point ? 16 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  17. 17. 8. Test Control Time goes now 모든 것은 계획대로 되지 않는다..  계획대로 진행되는지 관리하고, 잘못되었으면 수정이 필요하다.What’s your point ? 17 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  18. 18. Good Software Tester Time goes now 비즈니스 전략을 분석과 테스트에 우선 순위화 이해하는 능력 대한 열정 및 체계화 능력 인내심~ 적응 및 순수한 지적 능력 학습 능력 Software Tester 직접적인 감독 없이 전문 기술 일할 수 있는 능력 의사소통 능력What’s your point ? 18 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  19. 19. Software Team Time goes nowWhat’s your point ? 19 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  20. 20. Time goes now 소프트웨어 개발과 테스팅What’s your point ? 20 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  21. 21. 소프트웨어 개발(1/2) Time goes now Problem Space Solution [Question]  Problem이 무엇인가?  Solution은 무엇인가?  Solution 구현을 위한 mechanism은 무엇인가? Requirements  어떻게 구현할 것인가?  해결되어야 할 문제가 무엇인가?  고객이 구현된 산출물을 사용할 수 있는가?  보완할 필요가 있는가?  개발 기간 동안 발행되는 변화/변경을 어떻게 control 할 것인가?What’s your point ? 21 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  22. 22. 소프트웨어 개발 (2/2) Time goes now Big bang 접근  제품이 한번에 전달 된다  Waterfall Model Cyclical 접근 / Iterative 접근  제품이 단계마다 개발되고 전달 된다  Spiral Model  Iteration Model 정의 개발 유지보수 (Definition) (Development) (Maintenance) 무엇 어떻게 변경 보호활동 (Umbrella Activities)What’s your point ? 22 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  23. 23. 소프트웨어 수명주기 Time goes now 고품질의 소프트웨어를 구축하는 데에 요구되는 태스크(Task)에 대한 프레임워크(Framework) 소프트웨어 개발활동에 필요한 다양한 태스크와 이에 대한 산출물 모든 소프트웨어 개발 프로젝트의 필수적인 4가지 주요 단계  Requirement (Elicitation, Analysis, Specification)  System Design  Program Implementation  Test 소프트웨어 수명주기  프로젝트 별로 4가지 주요 단계를 다르게 해석한다.  프로젝트 특성(기간, 사용기술, 도메인)에 따라 결정하여 적용  각각의 특별한 스타일들은 “소프트웨어 수명주기라고 부른다. 왜 수명주기 모델을 사용하는가?  중요한 활동 식별, Milestone 정의, 진척도 측정의 용이  개발 과정을 나눔으로써 관리하기가 쉽다What’s your point ? 23 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  24. 24. 수명주기 모델 Time goes now 단일 버전 모델 (Single-Version Models)  빅뱅 모델 (Big-Bang Model)  폭포수 모델 (Waterfall Model)  Waterfall Model with “Back Flow  V 모델 : Integration Testing 점증적 모델 (Incremental Models)  Single-Version with Prototyping 모든 단계에는 산출물이 정의 되어 있다. 반복적 모델 (Iterative Models) Phase Output  Software Requirement  Spiral Model & Variants Requirements Specification (SRS)  Use Cases  Scrum Model Design  Design Document  Design Classes Implementation  Code  Incremental: add to the product at each phase  Test Report  Iterative: re-do the product at each phase Test  Change RequestWhat’s your point ? 24 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  25. 25. Big-Bang Model Time goes now Build and Fix 1. Developer receives problem statement. 2. Developer works in isolation for some extended time period. 3. Developer delivers result. 4. Developer hopes client is satisfied. Development 모든 것은 운으로 결정된다 !!! Build First Maintenance Version Modify until client is satisfied MaintenanceWhat’s your point ? 25 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  26. 26. Waterfall Model Time goes now Requirements Each phase “pours over” into the next phase. Design Implementation Adjustments made to immediately previous phase based on issues Test with successive phase.What’s your point ? 26 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  27. 27. V-Model Time goes now Each phase has corresponding test or validation counterpart Requirements Acceptance Test Analysis System Design Integration Test Program Design Unit Test ImplementationWhat’s your point ? 27 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  28. 28. Incremental vs. Iterative Time goes now Delivery 1 Delivery 2 Delivery 3 Incremental Plan Iterative PlanWhat’s your point ? 28 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  29. 29. Prototyping Model Time goes now Start Stop Requirements gathering and refinement 시제품 Engineer Quick 개발 및 수정 product design Refining Building prototype prototype 고객의 Customer 의견 수렴 evaluation of prototype 고객의 시제품 테스트What’s your point ? 29 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  30. 30. Spiral Model Time goes now Cost • 계획 • 위험 분석 목표, 대안, 제약 각 대안의 위험 분석 및 사항 결정 접근방법 선택 초기 요구사항 초기 위험 분석 분석과 계획 수립 고객의 반응에 따른 고객의 feedback을 위험 분석 반영한 계획  추진여부 결정 Toward a completed system 고객 평가 Time 첫 번째 prototype 다음 단계의 prototype 시스템 개발 • 고객 평가 • 개발 평가결과와 다음 반복을 개발과 다음 단계 작업산 위한 계획 출물의 검증What’s your point ? 30 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  31. 31. Incremental Model Time goes now General Case In AgileWhat’s your point ? 31 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  32. 32. [Variation Model] Sawtooth Model Time goes now Requirements Demo Prototype 1 Demo Prototype 2 Acceptance Test Analysis System Design Integration Test Program Design Unit Test ImplementationWhat’s your point ? 32 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  33. 33. [Variation Model] W-Model Time goes now 1 Requirement Review/Test Acceptance Install System Requirements Requirement 2 Testing Regression Specification Test Cycles Review/Test Spec 3 Build System System Document Testing Specification 4 Architecture 6 Review/Test Spec Build Software Architect Doc 5 Integration Architecture Testing 6 Design Review Build Software / Test Design Unit 6 Detailed Design Testing Code Code WalkthroughWhat’s your point ? 33 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  34. 34. [Variation Model] Multiple V-Model Time goes nowWhat’s your point ? 34 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  35. 35. [Variation Model] Nested Multiple V-Model Time goes now Nested V-Model Nested multiple V-ModelWhat’s your point ? 35 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  36. 36. 수명주기와 테스팅 Time goes now 모든 개발 활동은 테스팅 활동과 대응된다.  모든 개발 액티비티와 관련 있는 테스팅 액티비티가 있다.  각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있다.  하위 레벨 테스팅 • 단위 테스팅(Unit Testing) • 통합 테스팅(Integration Testing)  상위 레벨 테스팅 • 사용성 테스팅(Usability Testing) • 기능 테스팅(Function Testing) • 시스템 테스팅(System Testing) • 인수 테스팅(Acceptance Testing)  주어진 레벨에 대한 테스트의 분석과 설계는 관련된 개발 액티비티 동안에 시작 되어야 한다.  개발 수명 주기 모델에서 문서들의 배포판이 이용 가능하게 되면, 문서 리뷰 시 반드시 테스터들이 포함 되여야 한다.What’s your point ? 36 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  37. 37. 테스트 구분 Time goes now 소프트웨어 테스트는 관점에 따라 분류될 수 있다.  단계, 목적, 방법, 시작 방법 블랙박스 테스트 화이트박스 테스트 목적 시각 단계 기능 테스트 성능 테스트 볼륨 테스트 구조 테스트 단위 테스트 통합 테스트 검증 (개발자) 확인 테스트 시스템 테스트 인수 테스트 확인 (사용자) 설치 테스트What’s your point ? 37 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  38. 38. 테스트 레벨 Time goes now 테스트 레벨  한번에 총체적으로 조직화되고 관리하는 테스트 활동  Unit, Integration, System, Acceptance Test Level  SW/HW 모두 포함한다.  독립적 테스트 계획  독립적으로 테스트 된다.  독립적 테스트 환경 레벨 설명  단위 시험은 소프트웨어 설계의 기본 단위인 모듈 내부적인 오류를 발견하기 위한 시험이다. 단위 시험  단위 시험은 화이트 박스 방식과 블랙 박스 방식으로 수행할 수 있으며 일반적으로 화이트 박스 중심의 시험을 사용한다  통합 시험은 이와 같은 인터페이싱과 관련된 오류를 발견하는 시험을 수행하고 동시에 프로그램 구조를 통합 시험 구성하는 체계적인 기법이다  다른 시스템 요소인 하드웨어, 정보들과 통합되어 일련의 시스템 통합과 검증 시험이 수행 시스템 시험  기능 요구사항과 비기능 용구사항을 모두 충족시켜야 함  고객의 모든 요구사항을 만족하는지 확인 인수 시험  알파 테스트와 베타 테스트 (알파 테스트는 고객이 개발자의 위치에서 실행, 베타 테스트는 개발자가 참여 하지 않은 상황에서 실질적으로 프로그램을 실행하여 사용하는 환경에서 수행된다)What’s your point ? 38 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  39. 39. 테스트 유형 Time goes now 유형 설명  소프트웨어 기능 중심의 테스팅 기능 테스트  테스트 케이스 (대부분을 차지함) (Functional Testing)  메뉴, 사용자 매뉴얼 챕터 제목이나 목차에서 기능 추출  각각의 기능에 대해 기준, 출력, 내부 조건, 내부 상태를 파악하여 테스트 케이스 작성  소프트웨어 제품 특성을 테스팅  성능 테스팅, 부하 테스팅, 스트레스 테스팅 비기능 테스트  사용성 테스팅 (Non-functional Testing)  호환성 테스팅, 유지보수 테스팅, 신뢰성 테스팅, 이식성 테스팅  보안성 테스팅  구조 테스팅(화이트 박스)은 모든 테스트 레벨에서 수행될 수 있음 구조적 테스팅  문장, 분기 등의 요소들에 대한 커버리지 측정 (Structural Testing)  호출 계층 구조(calling hierarchy)와 같은 시스템의 아키텍처에 기반을 둘 수 있음  변경 사항에 관련된 테스트 확인/회귀 테스팅  확인 테스트는 결함이 제거 후, 원래의 결점이 성공적으로 제거되었는지 확인하기 위한 테스트 (Confirmation/  회귀 테스팅은 소프트웨어나 환경(environment)이 변경되었을 때 수행 Regression Testing)  확인 테스팅을 사용하고, 회귀 테스팅을 지원하기 위해서는 테스트를 반복적으로 수행되어야 함 GREY BOX TESTING APPROACHWhat’s your point ? 39 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  40. 40. Time goes now 정적 테스팅 기법What’s your point ? 40 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  41. 41. 테스트 기법 Time goes now Static Dynamic Reviews etc. Behavioural Static Analysis Inspection Walkthroughs Structural Non-functional Functional etc. Desk-checking etc. Equivalence Control Usability Partitioning Data Flow Flow Performance etc. Boundary Value Analysis etc. Statement Symbolic Cause-Effect Graphing Execution Arcs Branch/Decision Random Definition-Use Branch Condition LCSAJ Branch Condition State Transition CombinationWhat’s your point ? 41 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  42. 42. 정적 테스팅 Time goes now 정적 테스팅 (from wikipedia)  Static testing is a form of software testing where the software isnt actually used  It checks mainly for the sanity of the code, algorithm, or document 정적 테스팅의 특징  리뷰와 마찬가지로 장애(Failures)보다는 결함(Defects)을 발견함  대상 소프트웨어를 실행하지 않는 상태에서 툴의 지원으로 수행하는 것  정적 분석의 가치  테스트 실행 전 조기 결함 발견  복잡도 분석  소프트웨어 모델상의 의존도와 불일치성(Dependencies and inconsistencies) 발견  코드와 설계의 유지보수성(Maintainability) 향상What’s your point ? 42 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  43. 43. 정적 테스팅 기법 Time goes now 정적 기법 분류  리뷰  Review, Walkthrough, Inspection, Audit  정적 분석  코딩 표준 (Coding Standards)  코드 매트릭 (Code Metric)  코드 구조 분석  Control Flow Analysis 실제로 코드의 실행이 없다  Data Flow Analysis  Data Structure Analysis Static Analysis Tool Source Code Source Code 분석 분석 결과 보고What’s your point ? 43 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  44. 44. 리뷰 (1/4) Time goes now 리뷰(Review)란 …  SW 중간 산출물을 테스팅 하는 방법  프로그램 코드, 요구사항 명세서, 설계 명세서, 테스트 계획서, 테스트 설계서, etc. …  소프트웨어 개발 생명 주기의 앞부분에서 수행하여 결함 제거 비용이 저렴  개발 생산성 향상, 개발 시간 단축, 테스트 비용과 시간 단축 • 보다 적은 내재 결함 수와 향상된 의사 소통으로 위 사항을 가능하게 함  테스팅 기법 별로 다른 종류의 결함 발견 (상호보완적)  리뷰 • 코드 또는 문서상의 결함 (failure는 발견하지 못함) • 표준과의 불일치성, 설계 결함, 유지보수의 불충분성, 인터페이스 명세 결함  정적 분석 • 코드의 복잡도, 구문 에러, Missing 파라미터, Dead 코드 등What’s your point ? 44 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  45. 45. 리뷰 (2/4) Time goes now 리뷰(Review)의 필요성  테스팅 보다는 Review에서 결함을 발견하는 것이 더 효율적  단위 테스트에서 시간당 2~4개 정도의 결함을 발견한다면  Code Review에서는 6~10개 정도의 결함을 발견  단위 테스트 후의 결함제거에는 많은 비용이 필요  통합 및 시스템 테스트에서 결함을 발견하고 수정하는 데 걸리는 시간은 10~40 M/H 정도  Inspection은 결함당 1시간 이내 소요  빠른 결함 제거 시 시간과 비용 절감 효과가 있다.  개발 후반기 결함을 발견하고 수정하는 경우 더 많은 결함 비용 소모  개발 완료 후 결함을 발견하고 수정하는 경우에는 보다 많은 결함 비용 소요 Revs Req. R Design R Code R Test No Revs. Req. Design Code TestWhat’s your point ? 45 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  46. 46. 리뷰 (3/4) Time goes now 리뷰 타입 Target / Review Item (What) Requirements review Design review Code review User documentation review [Proj. Man. | Config. Man. | QA | V&V | Test |...] [plan | report] review not the focus here Formality detect errors and problems (How and Who) check conformity with specification and fitness for purpose check quality attributes and detect quality faults V&V and QA check adherence to standards check progress not the focus here Purpose / Goals (Why)What’s your point ? 46 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  47. 47. 리뷰 (4/4) Time goes now 리뷰의 성공요소  각각의 리뷰가 명확하게 미리 정의된 목적이 있어야 함  적합한 인력이 선택되어야 함  결함 발견은 언제나 환영하는 분위기이고 결함은 객관적으로 표현되어야 함  People issues와 심리적인 측면이 고려되어야 함  리뷰 기법이 적절히 적용되어야 함  효과적/효율적인 결함 발견을 위하여 필요 시 체크리스트 활용  (역할 분담도 적절히 활용)  리뷰 기법에 대한 교육 훈련 제공 (특히, 인스펙션의 경우)  경영층이 리뷰 프로세스를 지원 (프로젝트에서 리뷰 기법 적용에 일정 할당)  학습과 프로세스 개선에 대한 강조What’s your point ? 47 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  48. 48. 리뷰 단계 Time goes now  인력을 선발  개인별 역할(role)을 할당 및 문서들의 어떤 부분들을 살펴 볼 것인가를 결정  시작과 종료 조건(entry and exit criteria)을 정의  문서를 분배하고, 참가자들에게 리뷰 목적, 프로세스, 문서들에 대해 설명  시작 조건을 확인  참가자 개개인들 스스로가 리뷰 미팅 전에 잠재적인 결함, 질문과 코멘트들을 기록  반드시 체크리스트를 사용 개별 준비 리뷰 미팅 계획 킥오프 재 작업 추가작업 Individual Review (Planning) (Kick-Off) (Rework) (Follow-up) Preparation Meeting  문서화 된 기록 또는 상세한 기록과 더불어 논의와 로깅  결함에 대한 기록  미팅 참석자들은 결함(defects)을 처리하기 위한 충고사항을 제시  발견된 결함을 처리  일반적으로 작성자(Author)에 의하여 행해진다  처리된 결점을 확인하고 측정 기준들을 수집  좀더 형식적인 리뷰들을 위해서 종료 조건에 대한 확인What’s your point ? 48 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  49. 49. 역할과 책임 Time goes now Leader (Moderator) Author Inspectors Scribe (Creator of documents) (Reviewers of documents) (Recorder) Role Responsibility  리뷰 실행에 대한 결정 관리자  프로젝트 일정 내에 리뷰 시간 할당 (Manager)  리뷰의 목표가 달성되었는가를 결정  리뷰 계획, 미팅의 운영, 그리고 미팅 후 추가 사항을 포함하는 문서 혹은 문서 셋 중재자 (document set)의 리뷰의 진행 (Moderator)  중재자는 다양한 관점들 사이를 중재할 수 있다  작가 혹은 리뷰 된 문서에 대한 주된 책임을 가지고 있는 사람 작성자 (Author)  특정 기술 혹은 비즈니스 배경을 가지고 있는 개인 리뷰어  필요한 준비 후에 리뷰 동안에 제품에서 발견된 사항(결함)을 정의하고 설명 (Reviewer)  리뷰어는 리뷰 프로세스에서 표현되는 다양한 관점과 역할을 선택할 수 있어야 한다  모든 리뷰 미팅에 참가  모든 이슈사항, 문제 그리고 미팅 동안에 정의되어야 하는 문제점(-미정사항open points)을 필기자(또는 서기) 문서화 (Scribe (or recorder))What’s your point ? 49 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  50. 50. 비형식 리뷰와 기술 리뷰 Time goes now Informal Review vs. Technical Review Informal Review Technical Review  저비용 문서/코드 검토  기술적 문제 해결 - 혜택을 얻는 비용이 많이 들지 않는 방법  토론, 의사결정, 대안 평가 주요 목적  결함 발견  명세서 또는 표준과의 적합성 체크  (선택적) Pair 프로그래밍  동료 또는 기술 전문가가 문서화하고, 정의된 결 참여자  기술 선임자가 설계와 코드 리뷰 함 발견 프로세스에 참여 문서화  (선택적) 문서화  실무에는 Informal 또는 Formal  리뷰어에 따라 효과가 다양  실무에는 Informal 또는 Formal 효과  정보 공유 및 교육 사전 준비  미팅 사전 준비 단계를 거침  Pair programming  이상적으로는 Moderator가 미팅 주도  기술 리더가 디자인과 코드를 리뷰  선택적 체크리스트 기타  리뷰 리포트, 인시던트 리스트  경영층 참여 활동What’s your point ? 50 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  51. 51. Walkthrough Time goes now Walkthrough …  개발자(Author) 진행  학습, 시스템에 대한 이해가 목적  시간, 인원수 제한 없음,  준비 과정은 선택적  비형식적인 것에서부터 매우 형식적인 까지 다양 기술적 리스크 Inspection 기술적 리뷰 기술적 리뷰 Walkthroughs 비공식적 리뷰 Walkthroughs 사업적 리스크What’s your point ? 51 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  52. 52. Inspection Time goes now Inspection …  체크리스트와 규칙을 기반으로 하는 정식 프로세스  저자가 아닌 훈련된 Moderator에 의한 진행 및 제어  미팅 전 준비 과정 거침  프로세스 개선(선택적)  인스펙션 리포트와 발견사항 리스트 산출  주요 목적 : 결함 발견  정식적인 결함 수정 확인  매트릭을 수집하고 활용함 "하나의 좋은 인스펙션은 30,000개의 테스트케이스와 동등한 효과를 가져올 수 있다."  인스펙션 대상 -Vern Crandell  요구사항, 설계 등의 문서 산출물  개발 단계의 소스 코드  도입 효과  에러 예방, 비용 절감, 팀간 커뮤니케이션 향상, 이용 감소,What’s your point ? 52 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  53. 53. Audit Time goes now Audit is …  소프트웨어 제품이나 프로세스의 표준, 명세, 절차에 대한 준수를 확인하기 위하여 객관적인 기준에 기반한 독립적인 평가를 제공  규정 (Regulations), 표준 (Standard), 지침 (Guidelines), 계획 (Plans), 절차 (Procedures)  Audit 프로세스 Developers Auditor Project Manager Plan Prepare Start (Requirements, Scope, Audit & Checklist) Conduct Write-up Review Audit Report & with NO Findings Manager Findings? Corrective YES Actions OK Closeout Audit & File END Follow-up Audit Re-WorkWhat’s your point ? 53 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  54. 54. 체크리스트 Time goes now 체크리스트  반드시 확인이 필요한 항목의 리스트  일반적으로 질문지 형식을 취한다.  작성자와 리뷰어 모두 사용 가능  특성  목적을 가지고 작성한다  습득한 교훈에 기반하여 작성  가능한 일반적인 내용으로 .. Attribute What to consider Complete Is anything missing or forgotten? Is it thorough? Does it include everything necessary to make it stand alone? Accurate Is the proposed solution correct? Does it properly define the goal? Are there any errors? Consistent Is the description of the feature written so that it doesnt conflict with itself or other items in the specification? Is the statement necessary to specify the feature? Is there extra information that should be left out? Is the Relevant feature traceable to an original customer need? Can the feature be implemented with the available personnel, tools, and resources within the specified budget Feasible and schedule? Can the feature be tested? Is enough information provided that a tester could create tests to verify its Testable operation?What’s your point ? 54 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  55. 55. Coding Standards Time goes now Coding Standard (Small View)  목적  누가 그 코드를 보더라도 쉽게 이해할 수 있도록 한다.  누가 만든 코드인지 코드만으로 판별을 못하게 한다  원칙  경험에 기반한 상식들 • 코드는 명확하고 단순해야 한다. (Clear and Simple – Readability) • 복잡하지 않은 Logic. Good style is crucial • 의미 있는 명명 규칙 (Naming Rule) to good programming • 도움이 되는 주석 • 중립적인 표현 • 기술적인 트릭이나 일반적이지 않은 방법을 피한다.  일관성이 가장 중요하다.  Coding 영역 외에서도 사용이 된다. (Documents, E-mail)What’s your point ? 55 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  56. 56. Software Metric (1/2) Time goes now 매트릭이란 무엇인가?  나쁜 디자인과 좋은 디자인을 구별할 수 있는 측정 가능한 항목에 대한 정의  시스템에 특성에 대한 수량적 측정치 왜 매트릭을 사용하는가?  소스의 좋고 나쁨의 정도를 알려준다.  제품/프로세스의 품질을 예측하게 해준다.  품질 향상에 활용이 가능 • 제품 및 프로세스  새로운 도구나 기법이 생산성에 주는 영향을 파악  유지보수에 들어갈 자원과 노력을 예상/감소 소프트웨어 매트릭의 특징  계산이 가능하다 (자동 계산 또는 임의로 결정)  개발주기 초기에 확보가 가능하다.  일부 단일 시스템에서는 의미가 없을 수 있다.  언어에 독립적이다.What’s your point ? 56 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  57. 57. Software Metric (2/2) Time goes now Life Cycle Perspective Direct Measures  Internal attributes  Functionality, Complexity,  Cost, Effort, LOC, Speed, Memory Indirect Measures  External attributes End-Product  Quality Attributes  Efficiency, Reliability, Maintainability Quality Metrics Maintenance In-Process Quality Metrics Quality MetricsWhat’s your point ? 57 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  58. 58. [Additional Martials]Software Metrics- Halstead’s Metrics, Maintainability Index, CK Metrics
  59. 59. Halstead’s Metrics (1/2) Halstead’s Software Science  Halstead proposed the first analytic law for computer science by using a set of primitive measures  These can be derived once the design phase is completed and the code is generated  Halstead´s metrics is based on interpreting the source code as a sequence of tokens and classifying each token to be an operator or an operand Number of Operators and Operands  n1 = number of distinct operators in a program  n2 = number of distinct operands in a program  N1 = total numbers of operators  N2 = total number of operands  By using these measures, Halstead developed an expression for overall program length, program volume, program difficulty, development effort and so on.
  60. 60. Halstead’s Metrics (2/2) Metric Equation Description  The sum of the total number of operators and Program Length N = n1log2 n1 + n2log2 n2 operands in the program (N)  A suitable measure for the size of any Program Volume implementation of any algorithm V = N log2(n1+n2) (V)  The information contents of the program, measured in mathematical bits  L must be less than 1 Volume ratio L = 2/n1 * n2/N2 (L)  Difficulty is the inverse of LevelProgram Difficulty  a longer implementation of an algorithm will have a D = (n1/2)*(N2/n2) (D) higher difficulty than a shorter implementation of the same algorithm  Measurement of the mental activity required to reduce a Program Effort preconceived algorithm to a program (E) E=D*V  Halsteads formulation for the effort required to author (or understand) a program characterizes effort as proportional to both difficulty and volume  Programming time is considered to be directlyProgramming Time proportional to programming effort T = E / 18 (T)  Halstead intended this metric to be a language-Intelligent Content I=V/D independent measure of algorithmic complexity (I)
  61. 61. Example of Halstead Measures  Halstead Metric Values#include <stdio.h>int twice (int a){ return 2*a; }int f_switch(int a){ switch (a){ Function N1 N2 n1 n2 N V L D E T I case 0 : printf("zero"); twice() 5 4 4 3 9 25.3 0.3 2.7 67.4 3.7s 9.5 case 10 : printf("an even number"); max() 9 7 5 3 16 48 0.2 5.8 280 15.6s 8.2 break; default: f_nestedif() 19 15 9 6 34 132.8 3.6 11.25 1494.4 83.0s 11.8 printf("I dont know that one"); return -1; f_while() 17 14 10 9 31 131.7 6.4 7.8 1024.2 56.9s 16.9 break; } f_switch() 21 10 8 9 31 126.7 7.2 4.4 563.1 31.2s 28.5 return 0;}int max (int a, int b){ if (a > b) return a;  Halstead Metric Values return b;} Function Operators Operandsint f_nestedif(int a, int b){ if (a*a < b*b) twice() int (×2), return, *, semicolon twice, a (×2), 2 if (a > 60) return max(a,b); else if (b > 60) return 60; int (×3), if, >, return (×2), semicolon (× return b; max() max, a (×3), b (×3) 2)} int (×3), if (×3), * (×2), > (×2), <, returnint f_while(int a){ f_nestedif() f_nestedif, a (×5), b (×6), 60,60,60 (×3), max(), else, semicolon (×3) int i = 2; if (a < 0) return 0; int (×3), =, if, <, >, while, return (×2), - f_while() f_while, a (×4), i (×3), 2,2, 0,0,0, 100 while (a > 0){ =, *=, semicolon (×5) a -= 100; i *= 2; int (×2), switch, switch-case (×3), -, prin f_switch, a (×2), 0,0, 10, 1, "zero", "an ev } f_switch() tf (×3), break (×2), return (×2), semicolo en...", "I dont..." return i; n (×7)}
  62. 62. Maintainability Index (MI) Maintainability Index (MI)  A single-number value for estimating the relative maintainability of the code  Meanings of the Maintainability Index (MI, with comments) values:  85 and more : Good maintainability  65-85 : Moderate maintainability  < 65 : Difficult to maintain with really bad pieces of code  Calculation  Need to measure the following metrics from the source code  V = Halstead Volume  G = Cyclomatic Complexity  LOC = count of source Lines Of Code (SLOC)  CM = percent of lines of Comment (optional)  From these measurements the MI can be calculated  The original formula: MI = 171 - 5.2 * ln(V) - 0.23 * (G) - 16.2 * ln(LOC)  The derivative used by SEI is calculated as follows: MI = 171 - 5.2 * log2(V) - 0.23 * G - 16.2 * log2 (LOC) + 50 * sin (sqrt(2.4 * CM))  The derivative used by Microsoft Visual Studio (since v2008) MI = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)
  63. 63. The CK Metrics Suite (1/6) CK Metrics Suite  Chidamber and Kemerer have proposed six class-based design metrics for OO Systems  Weighted methods per class (WMC)  Coupling between object classes (CBO)  Depth of the inheritance tree (DIT)  Response for a class (RFC)  Number of children (NOC)  Lack of cohesion in methods (LCOM)  A study by NASA reports the following average values for Chidamber & Kemerer metrics System analyzed Java Java C++ Classes 46 1000 1617 Lines 50,000 300,000 500,000 Quality "Low" "High" "Medium" CBO 2.48 1.25 2.09 LCOM1 447.65 78.34 113.94 RFC 80.39 43.84 28.60 NOC 0.07 0.35 0.39 DIT 0.37 0.97 1.02 WMC 45.7 11.10 23.97
  64. 64. The CK Metrics Suite (2/6) Depth of the Inheritance tree (DIT)  The maximum length from the node to the root of the tree  As DIT grows, it become difficult to predict behavior of a class  Positively, large DIT values imply that many methods may be used C0  DIT (C0) = 0 C1 C0’  DIT (C0’) = 0  DIT (C1) = 1 C2  DIT (C2) = 2  DIT (C3) = 3  DIT (C4) = 4 C3 C4
  65. 65. The CK Metrics Suite (3/6) Number of children (NOC)  Count of the subclasses immediately subordinate to a class  As NOC grows, reuse increases  As NOC grows, abstraction can become diluted  Increase in NOC means the amount of testing will increase  The upper and lower limits of 1 and 3 correspond to a desirable average
  66. 66. The CK Metrics Suite (4/6) Coupling between object classes (CBO)  The number of collaborations listed for a class  As CBO increases, reusability of the class decreases  High CBO values complicate modifications  In general, CBO values for each class should be kept as low as possible  Equation  CBO = # of Links / # of Classes Variable Represents  number of classes used (associations, use links) for all the packages classes. A class used s NumberOfLinks everal times by another class is only counted once.  number of classes of the package, by recursively processing sub-packages and classes. For NumberOfClasses the UML modeling project, this variable represents, therefore, the total number of classes o f the UML modeling project. Bad Case Good Case
  67. 67. The CK Metrics Suite (5/6) Response for a class (RFC)  The number of methods that can potentially be executed in response to a message received by an object  As RFC increases, testing effort increases because the test sequence grows  As RFC increases, the overall complexity of the class increases  Smaller number are better  C++: median 6, max 120  Equation n RFC =  Mc i 1 i  Mci # of methods called in response to a message that invokes method Mi  Fully nested set of calls
  68. 68. The CK Metrics Suite (6/6) Lack of cohesion in methods (LCOM)  Measure of the number of methods within a class that access the same instance variables  If no methods access the same attributes, LCOM = 0  As LCOM increases, coupling between methods (via attributes) increases, and thus class complexity increases  C++: median 0, max 200
  69. 69. Control Flow Analysis Time goes now 제어 흐름(Control Flow)  프로그램에서 실행되는 각 구문, 명령어나 함수가 호출되는 순서를 의미한다  표현 방법 시각화를 통화 프로그램의 구조  Control Flow Graph 및 문제점 파악  Control Dependence - Dead Code, Infinite Loops - Jumps to undefined labels • 분기 조건의 검증 - Provide the code metrics  Call Graph if (x==y) if (x==y) then { … } else { …} …. 제어 흐름 분석(Control Flow Analysis)  프로그램의 제어 구조를 파악하기 위하여 프로그램을 분석What’s your point ? 69 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  70. 70. Data Structure Analysis Time goes now 데이터 구조 분석  프로그램과 독립적으로 데이터 구조 자체를 분석  데이터 모델 작성 및 활용  프로그램의 이해도를 높여준다 • 프로그램 작성 시  주석 활용  프로그램 작성 시 처리하는 데이터 작성에 대한 정보를 제공  테스트 케이스 설계 시 이용 가능  프로그램 성능에 영향을 미침  데이터 구조 최적화 • 중복 데이터 제거 • 데이터의 분할과 합병  데이터 특성에 따른 분류 • Read Only • Read/Write • Persistent / TemporaryWhat’s your point ? 70 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  71. 71. Data Flow Analysis Time goes now 데이터 흐름 분석  데이터 사용 흐름에 대한 파악  데이터에 대한 접근과 수정을 추적  일반적으로 다음과 같은 결함을 발견  정의되지 않은 변수의 참조  미사용 변수  데이터 흐름 구조 (Data Flow Structure)  정의된 변수에 어떤 값이 저장되는가?  저장된 변수의 값이 언제 사용되는가?  변수가 어느 때 유효한지, 언제 정의되지 않은 변수를 참조하는지? n := 0; read (x); n is re-defined without being used y = x+z; n := 1; ==> Data flow anomaly //y is defined; x,z are used while x > y do begin if a>b then read(c); read (y); write( n*y); y is used before it has been //a,bare used; c is defined x := x –n; defined==> Data flow fault end;What’s your point ? 71 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  72. 72. Time goes now 동적 테스팅 기법What’s your point ? 72 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  73. 73. 동적 테스팅 Time goes now 동적 테스팅  소소 코드를 실행하면서 테스트  Code Coverage – Statement/Decision/Condition Systematic approach와  Test Bed 필요 Non systematic approach의 두 가지 접근 방법이 있다.  블랙 박스  소스 코드 없이 실행만으로 테스트  TC를 만들고 기대 값을 산출 후 해당 TC가 기대하는 값과 일치하는지 확인  화이트 박스  소스 코드를 가지고 테스트하는 방법,  디버깅, 단위 테스트, 스크립트의 자동 실행  검출 가능 결함  기능의 구현 여부  메모리 누수, Pointer 관련  성능. 자원의 사용What’s your point ? 73 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  74. 74. Test Bed Time goes now 테스트 베드  기술 개발 과정에 있어 기술이 소비되는 실제와 동일한 환경 또는 결과 예측이 가능 한 가상환경을 구축하여 개발 기술의 적합성을 테스트 해보는 환경 Test Driver Test cases 즉, 장비들을 구비해 Stubs PoC 실제 프로세스에 Test Output 적용 가능한 테스트를 실시 할 수 있도록 구성한 환경 PoO Comparison Test Object * PoC – Point of Control Runtime environment, Test Stubs * PoO – Point of Observation Analysis tools, monitorsWhat’s your point ? 74 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  75. 75. 블랙박스 테스트 Time goes now 블랙박스 테스트  소프트웨어 내면을 알 수 없는 블랙박스로 규정, 외부에서 기능, 성능 등을 테스트  기능 위주의 테스트  모듈의 입력과 출력, 모듈이 수행하는 기능을 테스트  요구에 맞게 잘 작동하는가에 초점을 맞춘 테스트 방법 블랙박스 테스트 기법  Equivalence partitioning  Boundary value analysis  Decision table  State transition testing  Cause-effect graphing  Syntax testing  Random testing  …What’s your point ? 75 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  76. 76. 동등 분할 Time goes now 동등 분할(Eequivalence partitioning)  가정 :  하나의 값이 정상적으로 동작한다면, 다른 모든 값도 정상적으로 동작할 것이다.  전체에서 테스트하는 것보다, 각각의 부분에서 하나씩 테스트하는 것이 낮다  입력 값/출력 값 영역을 유한개의 상호 독립적인 집합으로 나눈 후 등가 집합의 원소 중 대표 값 하나를 선택하여 테스트 케이스 선정  경험이나 필요에 따라 하나 이상의 값을 선정할 수 있음 invalid valid invalid 0 1 100 101What’s your point ? 76 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  77. 77. 경계값 분석 Time goes now 경계값 분석 (Boundary value analysis)  결함은 등등 분할의 경계 부분에서 발생할 확률이 높다는 경험적 사실에 기반  경계 값 = 해당 분할 영역의 최대값과 최소값  Ex) Customer Name Number of characters: 1 2 64 65 invalid valid invalid Valid characters: A-Z a-z Any -’ space other Boundary value Robustness worst-case Robust worst-case analysisWhat’s your point ? 77 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  78. 78. 결정 테이블 Time goes now 결정 테이블 (Decision Table)  여러 종류의 입력 값의 조합으로 인한 연관성을 확인하는 방법  Input, Output 의 값이 Boolean 일 경우 유리  조건  조건의 순서에 따라 행위가 달라지지 않는다.  결과는 조건의 조합에만 영향을 받는다.  결정 테이블은 조건부(Condition Section)과 액션부 (Action Section)으로 구성  조건 : 발생 가능한 모든 사항을 나열  액션 : 발생 가능한 조건에 따라 처리해야 할 작업을 나열 Input Condition의 단순화 (Test case 수 감소)What’s your point ? 78 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  79. 79. 원인-결과 그래프 Time goes now 원인-결과 그래프(Cause-Effect Graph)  입력 데이터간 관계가 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성 높은 시험 사례를 발견  입력 조건의 조합을 체계적으로 선택하여 개수를 조절  동치 클래스, 경계값 분석의 단점  각각의 입력을 별도로 생각 D Fails G1 A Fails B or C Fail A G2 B Fails C Fails Fishbone Diagram Fault TreeWhat’s your point ? 79 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  80. 80. 화이트박스 테스트 Time goes now 화이트박스 테스트  프로그램 상에 허용 되는 모든 논리적 경로를 파악하거나 경로상의 복잡도를 계산 하여 테스트  코드 분석과 프로그램 구조에 대한 지식을 바탕으로 문제가 발생할 가능성이 있는 모듈 내부를 테스트하는 방법입니다 화이트박스 테스트 기법  Statement testing  Branch / Decision testing  Data flow testing  Branch condition testing  Branch condition combination testing  Modified condition decision testing  LCSAJ testing  …What’s your point ? 80 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement

×