소프트웨어 테스팅
Upcoming SlideShare
Loading in...5
×
 

소프트웨어 테스팅

on

  • 7,080 views

 

Statistics

Views

Total Views
7,080
Views on SlideShare
6,684
Embed Views
396

Actions

Likes
14
Downloads
428
Comments
0

4 Embeds 396

http://dsmoon.tistory.com 226
http://hidka.tistory.com 167
http://feedly.com 2
http://translate.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

소프트웨어 테스팅 소프트웨어 테스팅 Presentation Transcript

  • 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 …
  • 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
  • Time goes now 소프트웨어 테스팅의 기초What’s your point ? 3 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement View slide
  • 소프트웨어 테스팅의 정의 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 View slide
  • 소프트웨어 테스팅의 목적 Time goes now 주 목적 상세 목적  남아 있는 결함 발견  품질에 대한 확신, 정보 제공  명세 충족 확인  비즈니스 리스크를 감소  사용자 및 비즈니스 요구 충족 확인  개발 프로세스 점검, 이슈제기  결함 예방  논리적 설계의 구현 검증 개발 주기에 따른 테스팅의 목적 단계 목적 개발과정  소프트웨어 결함을 찾아내고, 수정하기 위해 가능한 많은 장애 발생 인수과정  예상대로 시스템이 동작하는지 확인, 요구사항에 맞는지 확인 품질 평가  특정시간 안에 출시하는 제품의 리스크를 개발 프로젝트에게 전달 유지 보수  변경 작업이 일어나는 경우, 새로 유입되는 결함이 있는지 확인 운영 과정  신뢰성 또는 가용성과 같은 시스템의 특성을 평가What’s your point ? 5 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 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
  • 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
  • 테스팅 원리 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
  • 테스팅 프로세스 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 7. Closure Time goes now 테스트 종료를 결정  테스트 종료 조건이 모든 레벨의 테스트에서 만족됨을 확인  Branch 커버리지  사용자 요구사항  비용과 시간  발견된 결함 수 (예상 대비)What’s your point ? 16 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 8. Test Control Time goes now 모든 것은 계획대로 되지 않는다..  계획대로 진행되는지 관리하고, 잘못되었으면 수정이 필요하다.What’s your point ? 17 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 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
  • Software Team Time goes nowWhat’s your point ? 19 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • Time goes now 소프트웨어 개발과 테스팅What’s your point ? 20 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 소프트웨어 개발(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
  • 소프트웨어 개발 (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
  • 소프트웨어 수명주기 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
  • 수명주기 모델 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • [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
  • [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
  • [Variation Model] Multiple V-Model Time goes nowWhat’s your point ? 34 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • [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
  • 수명주기와 테스팅 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
  • 테스트 구분 Time goes now 소프트웨어 테스트는 관점에 따라 분류될 수 있다.  단계, 목적, 방법, 시작 방법 블랙박스 테스트 화이트박스 테스트 목적 시각 단계 기능 테스트 성능 테스트 볼륨 테스트 구조 테스트 단위 테스트 통합 테스트 검증 (개발자) 확인 테스트 시스템 테스트 인수 테스트 확인 (사용자) 설치 테스트What’s your point ? 37 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 테스트 레벨 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
  • 테스트 유형 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
  • Time goes now 정적 테스팅 기법What’s your point ? 40 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 테스트 기법 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
  • 정적 테스팅 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
  • 정적 테스팅 기법 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
  • 리뷰 (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
  • 리뷰 (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
  • 리뷰 (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
  • 리뷰 (4/4) Time goes now 리뷰의 성공요소  각각의 리뷰가 명확하게 미리 정의된 목적이 있어야 함  적합한 인력이 선택되어야 함  결함 발견은 언제나 환영하는 분위기이고 결함은 객관적으로 표현되어야 함  People issues와 심리적인 측면이 고려되어야 함  리뷰 기법이 적절히 적용되어야 함  효과적/효율적인 결함 발견을 위하여 필요 시 체크리스트 활용  (역할 분담도 적절히 활용)  리뷰 기법에 대한 교육 훈련 제공 (특히, 인스펙션의 경우)  경영층이 리뷰 프로세스를 지원 (프로젝트에서 리뷰 기법 적용에 일정 할당)  학습과 프로세스 개선에 대한 강조What’s your point ? 47 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 리뷰 단계 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
  • 역할과 책임 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
  • 비형식 리뷰와 기술 리뷰 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
  • 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
  • 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
  • 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
  • 체크리스트 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
  • 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
  • Software Metric (1/2) Time goes now 매트릭이란 무엇인가?  나쁜 디자인과 좋은 디자인을 구별할 수 있는 측정 가능한 항목에 대한 정의  시스템에 특성에 대한 수량적 측정치 왜 매트릭을 사용하는가?  소스의 좋고 나쁨의 정도를 알려준다.  제품/프로세스의 품질을 예측하게 해준다.  품질 향상에 활용이 가능 • 제품 및 프로세스  새로운 도구나 기법이 생산성에 주는 영향을 파악  유지보수에 들어갈 자원과 노력을 예상/감소 소프트웨어 매트릭의 특징  계산이 가능하다 (자동 계산 또는 임의로 결정)  개발주기 초기에 확보가 가능하다.  일부 단일 시스템에서는 의미가 없을 수 있다.  언어에 독립적이다.What’s your point ? 56 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 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
  • [Additional Martials]Software Metrics- Halstead’s Metrics, Maintainability Index, CK Metrics
  • 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.
  • 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)
  • 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)}
  • 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)
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Time goes now 동적 테스팅 기법What’s your point ? 72 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 동적 테스팅 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
  • 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
  • 블랙박스 테스트 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
  • 동등 분할 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
  • 경계값 분석 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
  • 결정 테이블 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
  • 원인-결과 그래프 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
  • 화이트박스 테스트 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
  • 테스트 커버리지 Time goes now 테스트 커버리지(Test Coverage)  테스트의 시스템 또는 컴포넌트의 Spec/코드 커버 정도  얼마나 많은 범위를 테스트 했는가?  특정한 Coverage 항목이 Test suite에 의해 이행되는 백분율 정도  커버리지를 측정하지 않고, 테스트를 수행  일반적으로 코드의 50% ~ 60%만 실행하게 됨 (Weigers, 2002)  커버리지 종류  Decision/Condition/Statement Coverage  Condition/Decision, MC/DC, Multiple Condition Coverage Test Coverage 사용 용도 Test 수행 중 미리 정해 놓은 기준을 참고하여 추가 Test 가 필요한지, 만약 그렇다면 어떤 Test Case 가 필요한지를 결정하기 위해 명세된 Coverage 항목 대비 달성된 Coverage 를 측정하는 분석  테스트 중지 지침  Test case 추가 지침What’s your point ? 81 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 구조적 커버리지 Time goes now Enough tests? Tests Spec Software Results OK? Whats Coverage OK? More tests covered? Stronger structural techniques (different structural elements) Increasing coverageWhat’s your point ? 82 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 구문 테스팅/분기 테스팅 Time goes now 구문 테스트  테스트 케이스 Suite에 의하여 실행된 구문이 몇 %인지 측정  테스트 소프트웨어로 측정 ?  가능한 많은 부분을 검증하지 못함  대부분 60~75% 𝑵𝒖𝒎𝒃𝒆𝒓 𝒐𝒇 𝒔𝒕𝒂𝒕𝒆𝒎𝒆𝒏𝒕𝒔 𝒆𝒙𝒆𝒓𝒄𝒊𝒔𝒆𝒅 = 𝒕𝒐𝒕𝒂𝒍 𝒏𝒖𝒎𝒃𝒆𝒓 𝒐𝒇 𝒔𝒕𝒂𝒕𝒆𝒎𝒆𝒏𝒕𝒔 분기 테스트  테스트 케이스 Suite에 의해 실행된 조건문 분기가 몇 %인지 측정 False  결정 포인트 내 각각의 조건식이 참, 거짓의 모든 값을 갖게 되면 달성 True  제어 흐름을 다루기 때문에 구문 테스팅 보다 효과적 𝑵𝒖𝒎𝒃𝒆𝒓 𝒐𝒇 𝒐𝒖𝒕𝒄𝒐𝒎𝒆𝒔 𝒆𝒙𝒆𝒓𝒄𝒊𝒔𝒆𝒅 = 𝒕𝒐𝒕𝒂𝒍 𝒏𝒖𝒎𝒃𝒆𝒓 𝒐𝒇 𝒅𝒆𝒄𝒊𝒔𝒊𝒐𝒏 𝒐𝒖𝒕𝒄𝒐𝒎𝒆𝒔What’s your point ? 83 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 커버리지 타입 Time goes now 커버리지 타입  Decision Coverage  Condition Coverage  Condition/Decision Coverage  MC/DC (Modified Condition/Decision Coverage)  Multiple Condition Coverage 예제 : DP = A and B DPoint A B DPoint A B DPoint A B 0 1 0 0 1 0 0 0 0 1 1 1 0 0 1 1 1 1 DPoint A B DPoint A B 0 1 0 0 0 0 0 0 1 0 0 1 1 1 1 0 1 0 1 1 1What’s your point ? 84 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • Coverage Scope Time goes now 다중 조건 커버리지 얼마만큼의 (Multiple Condition Coverage) Coverage를 확보해야 하는가? 변경 조건/결정 커버리지 (MC/DC) 조건/결정 커버리지 (Condition/Decision Coverage) 100% coverage does not mean 100% tested! 구문 커버리지 (Statement Converge) Coverage is not Thoroughness 결정 커버리지 조건 커버리지 (Decision Coverage) (Condition Coverage)What’s your point ? 85 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 경험 기반 테스팅 Time goes now 경험기반 테스트  비시스템적 테스트(Non-systematic test techniques)  경험 기반 접근  체계적인 테스트 기법을 경험 기법으로 보강하는 것이 유용  테스트 스크립트가 없음  주요 기법  Error guessing • 테스터의 경험에 기반하여 결함 예측 : 테스터의 능력에 결과가 영향을 받음 • 결함 공격 : 가능한 오류를 모두 나열하고 해당 오류를 찾을 수 있는 테스트를 수행 • 고려 사항 : 과거의 실패 케이스, 브레인 스토밍, 직관, …  Exploratory testing • TC를 먼저 작성하지 않고, 테스트 대상을 실행하면서 익숙해지는 것과 동시에 테스트 설계 • TC 작성 시간을 최소화하고 테스터의 지적 능력을 활용하여 테스트What’s your point ? 86 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 그레이 박스 테스트 Time goes now 그레이 박스 테스트(Gray Box Test, = Glass Box Test)  프로그램 기반으로 테스트, 그러나 소스 코드의 정확성 및 오류 사항을 함께 테스트  내부 시스템에 대한 제한된 지식을 가지고 테스트  요구사항 문서보다는 상세 설계 문서를 참고  사전에 오류를 미리 확인하여, 오류로 인한 추가 코딩 시간을 줄임  Dark Gray Box Test 화이트박스 테스트처럼  외부 인터페이스만을 사용해서 내부 구현 코드를 분석 소스코드를 이해하고,  명세에 없는 특정 범위 산출물을 결정하여 테스트 테스트 하는 것이 목적이 아니라 소스코드들을 통해서  Light Gray Box Test 기능을 이해하고 테스트를 진행하는 것  테스트 수행은 외부 인터페이스만 사용  결과 검사는 내부 쿼리를 사용 GREY BOX TESTING APPROACHWhat’s your point ? 87 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 상태 전이 테스트 Time goes now 상태 전이 테스트(State Transition Testing)  상태 전이 다이어그램에 기반  대부분의 시스템의 경우 많은 수의 상태를 갖는다.  테스트 기준  모든 상태 (All states) – 모든 상태가 테스트되어야 함  모든 이벤트 (All events) – 모든 이벤트가 적어도 한번은 발생해야 함  모든 행동 (All actions) – 모든 행위가 한번은 수행되어야 함 a a A a[p1] / w A B C B A a[p1] / w b[p2] / u b[p2] / u C W A W B A WWhat’s your point ? 88 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • Time goes now 요구사항과 테스트 설계What’s your point ? 89 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 요구사항 ? Requirements ?
  • 요구사항이란 ... 정의  문제의 해결 또는 목적 달성을 위하여 고객에 의해 요구되거나, 표준이나 명세 등을 만 족하기 위하여 시스템이 가져야 하는 서비스 또는 제약사항  고객이 요구한 사항과 요구하지 않았더라도 당연히 제공되어야 한다고 가정되는 사항들 왜 요구사항을 관리하는가?  참여자들로 하여금 개발되는 소프트웨어 제품을 전체적으로 파악하도록 하여 의사 소통 시간을 절약하게 해 주는 것  상세한 요구사항이 있어야만 산정이 가능하고, 이를 기반으로 계획을 세울 수 있기 때문 요구사항 설계 구현 테스트 유지보수 가이드라인 가이드라인 테스트의 기준 가이드 라인 및 지침
  • 요구사항의 분류 기능적 요구사항(Functional Requirements)  수행될 기능과 관련되어 입력과 출력 및 그들 사이의 처리과정  목표로 하는 제품의 구현을 위해 소프트웨어가 가져야 하는 기능적 속성  예) 워드 프로세서에서 파일 저장 기능, 편집 기능, 보기 기능 비기능적 요구사항(Non-Functional Requirements)  제품의 품질 기준 등을 만족시키기 위해 소프트웨어가 가져야 하는 성능, 사용의 용이성, 안전성과 같은 행위적 특성  시스템의 기능에 관련되지 않는 사항을 나타냄  예) 성능(응답 시간, 처리량), 사용의 용이성, 신뢰도, 보안성, 운용상의 제약, 안전성 등
  • 요구사항 개발 요구사항 개발  발주자나 고객으로부터 구현될 소프트웨어 제품의 사양을 정확히 도출하고,  요구사항을 명세하고,  이를 분석한 결과를 개발자들이 이해할 수 있는 형식으로 기술하는 작업 요구사항 개발 요구사항 수집/추출 요구사항 분석 요구사항 명세 요구사항 검증 요구사항 관리 Inception Elicitation 이론적인 요구사항 Elaboration 개발 프로세스 Negotiation Specification Validation Requirements Management
  • 요구사항 추출 요구사항 추출  고객이 원하는 요구사항을 수집  수집된 요구사항을 통해 개발되어야 하는 시스템에 대한 사용자 요구 와 시스템 기능 및 제약사항을 식별 하고 이해하는 단계 기능  고객의 최초 요구사항은 추상적이기 때문에 수주자는 정확한 요구사항을 파악  요구사항은 계약 및 최초 산정의 기본이 됨 요구사항 추출 기법  인터뷰 User Requirement  시나리오 (Usecase) Requirement H/W Requirement System Requirement S/W Requirement Software 개발의 출발점
  • 요구사항 분석 요구사항 분석  추출된 고객의 요구사항을 분석 기법을 이용하여, 식별 가능한 문제들을 도출하고 요구사항을 이해하는 과정  참여자들로부터 추상적 요구사항을 명세서 작성 전에 완전하고 일관성 있는 요구사항으 로 정리하는 활동 요구사항 분석의 기준  시스템을 계층적이고 구조적으로 표현하여야 한다.  외부 사용자와의 인터페이스 및 내부 시스템 구성요소 간의 인터페이스를 정확히 분석 하여야 한다.  분석단계 이후의 설계와 구현단계에 필요한 정보를 제공하여야 한다 분석 기법  구조적 분석(Structured Analysis)  시스템의 기능을 정의하기 위해서 프로세스들을 도출하고, 도출된 프로세스 간의 데이터 흐름 을 정의  객체지향 분석  Usecase 의 실체화(Realization)과정을 통해 추출된 요구사항을 분석
  • 요구사항 명세 요구사항 명세  분석된 요구사항을 명확하고 완전하게 기록하는 것  소프트웨어 시스템이 수행하여야 할 모든 기능과 시스템에 관련된 구현상의 제약 조건 및 개발자와 사용자가 합의한 성능에 관한 사항 등을 명세 최종 결과물  요구사항 명세서(SRS: Software Requirement Specification)  프로젝트 산출물 중 가장 중요한 문서  사용자, 분석가, 개발자 및 테스터 모두에게 공동의 목표를 제시  시스템이 어떻게 수행될 것인가가 아닌 무엇을 수행할 것인가에 대한 기술
  • 요구사항 검증 요구사항 검증  사용자 요구가 요구사항 명세서에 올바르게 기술되었는가에 대해 검토하는 활동 검증 목적  시스템 요구사항이 설계기준에 따라 하드웨어 형상 항목, 소프트웨어 형상 항목 등에 적 절하게 할당되었는지 검증  안전, 보안, 및 위험성과 관련된 소프트웨어 요구사항이 정확한지 검증 검증 내용  요구사항이 사용자나 고객의 목적을 완전하게 기술하는가?  요구사항 명세가 문서 표준을 따르고, 설계 단계의 기초로 적합한가?  요구사항 명세의 내부적 일치성과 완정성이 있는가?  기술된 요구사항이 참여자의 기대에 일치하는가?
  • 요구사항 관리 요구사항 관리  프로젝트와 관련된 이해 관계자들로부터 요구사항을 추출, 구성 및 문서화하고 변경에 대한 동의를 설정해 관리하는 시스템적 활동.  참여자들 사이에서 효과적인 의사소통 전략을 사용하여 충분한 합의와 협의를 통해 공 통의 이해를 구축하고, 개발 생명주기의 전체 기간 동안 지속적인 관리를 제공함 변경 관리 활동 Activity Task 요구사항 변경통제  요구사항 변경에 대해 비용,일정 등에 따라 변경식별 및 평가, 제어 및 재설정 등을 수행  요구사항 변경에 의해 다른 형상에 영향을 미치는 요구사항을 식별하고 영향을 받은 요구사항 요구사항 추적 통제 들을 추적하는 연계성관리  변경으로 영향 받은 요소를 식별하고 요구사항 변경에 대한 노력을 평가하는 영향평가를 수행  이는 형상관리 기반으로 요구사항 명세 베이스라인과 요구사항 관리공정 전체 과정에 걸쳐 요구사항 버전통제 축적된 모은 요구사항 정보를 관리
  • Good Requirement Example of Good Requirement Defines a user type “to be” verb “The internet user shall be able to access their current account balance in less than 5 seconds” Defines a positive end result Performance Criteria This requirement sentence identifies a specific user and end result that is wanted Within a specified time. It also defines the success criteria in measurable terms – “access ….. Account Balance” “in less than 5 seconds” The challenge is to seek out the user type, end result, and success measure in every requirement you define  Complete  Consistent  Clear  Testable  Traceable
  • 개발 문서 체계  System 관점의 H/W, S/W 구조 기술 System 구조 설계 서  Architecture 구조 내용 일부 기술 S/W 요구사양 서  S/W 전체 구조에 대한 View 포함 - Static View, Dynamic View S/W 구조 설계 - Subsystem 간 Interface 서  서브 시스템 단위 기술 - Call, OAM… S/W 기본 설계 서 - Block 간 Interface  Block 단위 기술 S/W 상세 설계 서
  • 요구사항 명세 표준 IEEE-Std-830 1. 소개(Introduction) 3. 상세한 요구사항 (Specific requirements) 1.1 SRS의 목적(Purpose of SRS) 3.1 기능적 요구사항(Functional requirements) 3.1.1 기능적 요구사항1 (Functional requirements 1) 1.2 산출물의 범위(Scope of product) 3.1.1.1 개요 1.3 정의,두문자어,약어(Definitions, acronyms and 3.1.1.2 입력물 Abbreviations) 3.1.1.3 프로세싱(Processing) 1.4 참조문서(References) 3.1.1.4 산출물(Outputs) 1.5 SRS 개요(Overview of rest of SRS) 3.1.1.5 수행 요구사항(Performance requirements) 2. 일반적인 기술사항(General Description) 3.1.1.6 디자인 제약사항(Design constraints) 2.1 제품의 관점(Product Perspective) 3.1.1.7 속성(Attributes) 3.1.1.8 기타 요구사항(Other requirements) 2.2 제품의 기능(Product Functions) . . . 2.3 사용자 특성(User Characteristics) 3.2 외부적인 인터페이스 요구사항(External interface 2.4 제약사항(Constraints) requirements) 2.5 가정 및 의존성(Assumptions and Dependencies) 3.2.1 사용자 인터페이스(User Interface) 3.2.2 하드웨어 인터페이스(Hardware interface) 3.2.3 소프트웨어 인터페이스(Software interface) 3.2.4 커뮤니케이션 인터페이스(Communications interface) 부록(Appendices) 인덱스(Index)
  • Good SRS ? 좋은 요구 사항 명세서가 되기 위하여 지녀야 할 기본적인 조건  설계 과정에 도움을 줄 것  고객과 user가 모두 이해하기 쉽고, 개발 계약의 기초가 될 수 있을 것  Software의 정확성을 평가하는 수단으로 사용할 수 있을 것  Software 제품이나 개발과정을 공학화 할 때 핵심이 될 수 있을 것 Good SRS 의 특성 - 완전성(Completeness) - 자동 처리성(Automobility) - 일관성(Consistency) - 필요성(Necessity) - 정당성(Correctness) - 실현 가능성(Feasibility) - 테스트 용이성(Testability) - 형식성(Formality) - 명확성(Unambiguity) - 작성의 용이성(Constructability) - 독립적 설계(Design freedom) - 이해성(Comprehensibility) - 추적 가능성(Traceability) - 최소성(Minimality) - 전달성(Communicability) - 적용성(Applicability)/ - 모듈성 및 변경에 대한 강건성 - 확장성(Extensibility) (Modularity/Change Robustness)
  • 테스트 케이스 Time goes now  Test Case : 테스트 케이스 특별한 목표 또는 테스트 상황(test conditions)을 테스팅 하기 위해 개발된 입력 값, 실행 사전조건, 예상 결과, 실행 사후조건 들의 집합. 특별한 목표와 테스트 상황은 특정 프로그램 경로를 실행하거나 지정된 요구사항을 준수하는지 검증하는 것을 의미한다. [IEEE610 준수]  Test Procedure : 테스트 절차 테스트를 수행할 때 따라야 할 순서. 테스트 절차 명세 (test procedure specification) 참고.  Test Scenario : 테스트 시나리오 테스트 절차 명세 (test procedure specification) 참고.  Test Procedure Specification : 테스트 절차 명세 테스트 실행을 위한 동작 순서를 기술한(명세한) 문서. 테스트 스크립트 또는 수동 테스트 스크립트로 알려져 있다 Most important Good Test Case (4E) test conditions Least important  Effective test conditions Importance  결함을 찾을 수 있어야 한다. Test cases  Exemplary  다른 것들을 대표해야 한다.  Evolvable  유지보수가 쉬워야 한다.  Economic  사용 비용이 적어야 한다. TimeWhat’s your point ? 103 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • UML – Testing에서의 활용 Time goes now Testing에서의 Use Case Diagram과 Use Case 활용  요구사항 분석서(SRS), 설계 기준서 등 명세서를 작성/표현 시 UML 사용  UML의 요소 중 Process Flow을 표시하는 Use Case를 Testing 영역에 적용함  Use Case를 활용하여 작성된 Test Cases  시스템 실사용 동안의 Process Flow내에 존재할 수 있는 Defects를 발견 시 유용  S/W가 없이 명세만으로 TC 도출  Early Test Design(조기 테스트 설계)이 가능  Test Case를 생성하는 과정에서 Architect/Analyst/Developer가 발견하기 어려운 결함을 효과적으로 발견할 수 있음  ISTQB에서는 Use Case Testing을 명세기반 기법 중 하나로 분류  Use Case를 이용 Test Case 도출 시, 다양한 명세기반 기법을 추가적으로 적용/도입 가능 좋은 문서를 작성하기 위해서는 UML에 대해서는 한번은 개인적으로 정리가 필요 !!!What’s your point ? 104 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • Use Case 소개 Time goes now Use case 란 ?  사용자의 관점에서 시스템을 모델링 하는 역할 수행  시스템의 사용 방법을 결정하는데 도움을 주는 장치  시스템 사용에 대한 시나리오의 집합  요구사항을 알아내는 과정  누가, 무엇을 할 수 있는지에 대해 상세히 기술해 놓은 집합  사용자 시각에 맞춘 분석  시스템의 행위를 결정 왜 사용하는가 ?  공학에서 널리 쓰이는 방법  사용자의 요구사항을 반영  프로젝트 참여자들의 의사소통 도구  시스템이 주체가 되어 돌아가는 상황 반영  각 기능, 서비스 별 목적을 명확히 파악What’s your point ? 105 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • Use Case 다이어그램과 기술 Time goes now Use case Diagram  Use case Description  Actor, Use Case, Relationship으로 구성  Use Case를 상세화 Use case Description Use Case Name : Use Case Name 작성 개요 Use Case에 대한 간단한 설명 작성 Pre-Condition Use Case의 전제 조건 작성 Post-Condition Use Case 완료 후 조건 작성 Flows of Events 1. Main Flows 2 Alternative FlowsWhat’s your point ? 106 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • Use case에서 테스트 케이스 생성하기 Time goes now Why ?  시스템이 실제 사용되는 Process Flow에서 Defect을 발견하는데 유용  고객이나 유저 그룹을 참여시키는 Acceptance Test(인수 테스트)를 설계 시 유용  통합 테스트 시 컴포넌트 간 상호작용과 간섭으로 발생되는 통합 결함을 발견 How to Generate ?  Use Case 식별  Use Case Diagram 작성  Use Case Description 작성  Basic Flow(기본흐름)  Alternate Flow(대체 흐름)  Test Case 작성  시나리오 작성  Test Case 확인  Test Data Value 확인What’s your point ? 107 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 사례 연구 (1/6) Time goes now Use Case 식별What’s your point ? 108 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 사례 연구 (2/6) Time goes now Use Case Diagram 작성 본 예제에서는 “제품 등록” Use Case에 대한 Test Case를 작성함What’s your point ? 109 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 사례 연구 (3/6) Time goes now Use Case Description 작성  시스템이 실제 사용되는 Process Flow에 따라 Main Flows와 Alternate Flows를 작성What’s your point ? 110 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 사례 연구 (4/6) Time goes now Test Case 작성  Scenario 작성  Use Case Description 내용을 파악  Main Flows와 Alternate Flows의 결합을 통핚 Scenarios 작성  Scenario Matrix 작성What’s your point ? 111 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 사례 연구 (5/6) Time goes now Test Case 작성  Scenario 분석 및 Use Case Description 리뷰  각 Scenario에서 최소한 1개 이상의 Test Case를 추출  추출된 Test Case를 이용하여 Test Case Matrix 작성What’s your point ? 112 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 사례 연구 (6/6) Time goes now Test Case 명세서 작성  Test Data Value 확인  Data Value을 입력하여 Test Case 명세서 완성  각 조직에서 사용하고 있는 Test Case 명세서 Template를 이용하여 작성  작성된 Test Case를 이용하여 테스트 수행 Data Value 작성What’s your point ? 113 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • Time goes now 테스트 관리 도구 - Open Source BasedWhat’s your point ? 114 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 테스트 도구 Time goes now 테스트 도구  반복성이 강한 테스트의 수행에 소요되는 시간을 줄이기 위해서 사용되는 도구  수작업에 의한 테스트보다 더 효과적인 방법을 제공하여 문제를 해결  구조분석, 커버리지 도출, 테스트 케이스 도출, 결함 관리, 테스트 프로세스 관리 등 테스트 도구의 특징 특징 설명 속도  수작업 보다 더욱 빠르게 작업을 수행 (Speed) 효율성  테스트 수행 시간을 감소 (Efficiency)  감소된 시간을 다른 활동에 활용 정확성(Accuracy) &  테스트 도구는 항상 동일한 테스트를 수행하고 매번 완전하게 결과를 검사 정밀성(Precision) 리소스 절감  시뮬레이션을 이용하여 실제 환경과 비슷한 환경에서 작업을 수행 (Resource Reduction) 지속성  테스터와 달리 쉬지 않고 지속적인 작업 수행 (durability)What’s your point ? 115 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 테스트 도구 타입 Time goes now 타입 설명 도구  Test Link 테스트 관리 도구  테스트 관리와 수행된 활동에 대한 지원 및 관리  Test Director  Test Manager  Mantis 결함추적  결함 관리, 결함 추적, 변경 요구 사항 및 작업 할당을 수행  BugZilla 관리 도구  Trac  FindBugs 정적 분석 도구  SW를 실행시키지 않고 소스 코드에서 실행 시 발생할 수 있는 결함을 발견  CheckStyle  PMD  Jmeter 성능/부하  시스템이 시뮬레이션 된 다양한 조건에서 어떻게 동작하는지 모니터링과 테스트  soalUI 테스트 도구  OpenSTA  CVS 형상 관리 도구  SW, 테스트 관련 산출물의 버전 관리 및 빌드 추적  Sub Version(SVN)  Git  ANT 빌드 &  빌드, 릴리즈 등의 반복 작업을 자동화  NANT 릴리즈 도구  MavenWhat’s your point ? 116 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 테스트 툴과 사용자 Time goes now 프로젝트 관리자 테스트 프로젝트 관리도구 관리도구 개발자 결함 관리 테스트 정적 분석 성능/부하 도구 엔지니어 도구 테스트 도구 빌드& 릴리즈 도구 형상 관리 도구 주로 사용 빌드& 참조 릴리즈 담당자What’s your point ? 117 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 테스트 관리 도구 Time goes now 테스트 관리 도구란 …  테스트 관리와 수행된 활동에 대한 지원  테스트 실행 관리, 결함 추적 그리고 요구사항 관리도구와 인터페이스  독립적인 버전 컨트롤 또는 외부 구성 관리 도구와의 인터페이스  테스트, 테스트 결과, 요구사항 명세와 같은 소스 문서의 부가사항에 대한 추적성  테스트 결과 Logging과 진행 상황 보고  테스트 대상에 대한 정보 제공 또는 테스트 프로세스 제어 및 개선을 위해 정략적인 분석 지원  테스트 관련 측정(테스트 진행률, Pass/Fail Rate, 발견한 결함/인시던트) TestLink WATT http://www.teamst.org http://wisewires.comWhat’s your point ? 118 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 결함 추적 관리 도구 Time goes now 결함 추적 관리 도구란 …  결함추적 관리도구는 결함, 장애 또는 인지된 문제와 불일치 등에 대한 내용을 저장 하고 관리  보고된 변경 요청사항간에 우선순위 설정  관련 담당자에게 변경 요청사항 작업 할당  결함 상태 변경 및 추적 Bugzilla – http://bugzilla.org Mantis – http://www.mantisbt.org Trac – http://trac.edgewall.orgWhat’s your point ? 119 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 정적 분석 도구 Time goes now 정적 분석 도구란 …  개발자, 테스터, 품질 보증 담당자가 동적 테스팅을 하기 전에 결함을 발견할 수 있 도록 지원하는 도구  코딩 표준을 지킬 것을 강제  구조와 의존관계를 분석  테스트 계획을 세우거나 리스크 분석을 할 때 필요한 복잡도를 계산 FindBugs Check Style PDM http://findbugs.sourceforge.net http://checkstyle.sourceforge.net http://pmd.sourceforge.netWhat’s your point ? 120 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 성능/부하 테스트 도구 Time goes now 성능/부하 테스트 도구란 …  주로 시스템의 부하와 트랜잭션 측정  부하 발생을 통해 다수의 사용자 또는 많은 양의 입력 데이터를 모의 테스트  테스트 수행 중에 선정된 트랜잭션으로부터 응답시간을 측정 및 기록  일반적으로 응답시간에 대한 부하 테스트 로그와 그래프 기반의 리포트 제공 JMeter soapUI OpenSTA http://jakarta.apache.org/jmeter http://www.soapui.org http://www.opensta.orgWhat’s your point ? 121 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 형상 관리 도구 Time goes now 형상 관리 도구란 …  소프트웨어나 Testware의 버전이나 빌드에 대한 정보를 저장  Testware와 소프트웨어 중간 산출물 및 다른 버전들에 대한 추적성 확보  제품의 현재 상태와 변경 요구사항의 달성 상태를 파악  표준, 절차, 재사용 라이브러리 등 조직 전체 작업 산출물을 저장 및 관리 CVS – http://www.evscm.org SVN – http://subversion.apache.org Git – http://git-scm.comWhat’s your point ? 122 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 빌드 & 릴리즈 도구 Time goes now 빌드 & 릴리즈 도구란 …  소프트웨어의 빌드/릴리즈의 자동화를 도와주는 도구  개발 완료된 소프트웨어를 모두 결합하여 고객 또는 테스트 팀에게 전달/인도 하기 위해 필요한 실행 절차를 자동화하는 도구  빌드&릴리즈는 형상 관리 영역의 일부분 Ant – http://ant.apache.org NAnt – http://nant.sourceforge.net Maven – http://maven.apache.orgWhat’s your point ? 123 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • 테스트 도구의 도입의 장점과 단점 Time goes now 테스트 지원 도구는 테스트 엔지니어를 대신하지 않고, 단지 테스트 작업을 더 수월하게 도와주는 역할을 수행 장점  반복적임 업무 감소  테스트 노력 절감 및 실수 감소  객관적인 평가 기준 제공(정적 측정치, 커버리지)  효율적인 비용으로 유지보수 가능  제품의 품질 향상과 고객 만족도 향상 단점  테스트 관리 도구의 비용이 고가이며, 유지 비용이 높음  초기 환경 및 테스트 설정에 많은 시간, 비용, 노력이 소요됨  도구에 의해 생성된 테스트 자산(Assets)를 유지하는데 많은 비용이 소요됨  테스트 스크립트 유지보수가 어려움What’s your point ? 124 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement
  • Time goes nowWhat’s your point ? 125 This presentation created by Youngki, Kim Do not modify arbitrarily without agreement