소프트웨어 테스팅

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

소프트웨어 테스팅의 기초


소프트웨어 테스팅의 정의 Time goes now

 소프트웨어 테스팅이란 …
소프트웨어의 테스트는 수동이나 자동으로 시스템을 시험 작동시키고 평가하는 작업으로 명시된 요구를 잘 만족하는지,
즉 예상된 결과와 실제 결과와의 차이를 인식하기 위한 목적을 가진다 - IEEE

 컴퓨터 소프트웨어를 실행하여 그 결과가 올바른지 판단하는 과정
 Executing software in a simulated or real environment, using inputs selected somehow
 사용자의 기대 수준과 요구사항에 맞게 구현되었는지 확인

 소프트웨어 테스팅의 목적 관점에 따라
각기 다른 여러 가지

 요구사항 충족 확인
목적을 가진다.

 결함 발견 또는 결함 방지
 소프트웨어 품질 수준에 대한 확신을 얻고, 정보를 제공
 소프트웨어의 여러 측면 평가
 메모리 사용량 (Memory Usage)
 신뢰성(Reliability), 성능(Performance), 보안(Security), 사용성(Usability)


소프트웨어 테스팅의 목적 Time goes now

주 목적 상세 목적
 남아 있는 결함 발견  품질에 대한 확신, 정보 제공
 명세 충족 확인  비즈니스 리스크를 감소
 사용자 및 비즈니스 요구 충족 확인  개발 프로세스 점검, 이슈제기
 결함 예방  논리적 설계의 구현 검증

 개발 주기에 따른 테스팅의 목적

단계 목적
개발과정  소프트웨어 결함을 찾아내고, 수정하기 위해 가능한 많은 장애 발생

인수과정  예상대로 시스템이 동작하는지 확인, 요구사항에 맞는지 확인

품질 평가  특정시간 안에 출시하는 제품의 리스크를 개발 프로젝트에게 전달

유지 보수  변경 작업이 일어나는 경우, 새로 유입되는 결함이 있는지 확인

운영 과정  신뢰성 또는 가용성과 같은 시스템의 특성을 평가


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 operation

Test Terms Time goes now

 Test Basis
 요구사항을 내포하고 있는 모든 문서
 테스트 케이스는 테스트 베이시스를 토대로 만들어 진다
 Test Harness
 시스템 및 시스템 컴포넌트를 시험하는 환경의 일부분으로 시험 지원을 목적으로
생성된 코드와 데이터
 Test Oracle
 테스트 실행 결과의 참/거짓 판별 기준
 Test Suite
 여러 테스트 케이스의 집합
 False-fail result (False Alarm)
 결함이 아닌데도 결함으로 보고된 테스트 결과


테스팅 원리 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)
 사용자 요구사항에 맞지 않는다면 결함을 찾고 수정하는 것은 무의미
 결함을 모두 발견했다고 해도 품질이 높다고 할 수 없음


테스팅 프로세스 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]


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 Plan


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.


3. Test Design Time goes now



 어떻게 테스트 할 것인가?
 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)

4. Test Implementation Time goes now



 테스트 케이스 구현
 테스트 스크립트 작성
 테스트 데이터 준비
 예상 결과 정의
 문서화
 Test Oracle
 테스트 실행 결과가 올바른 결과인지를 판별할 수 있는 메커니즘
 True Oracle, Sampling Oracle, Heuristic Oracle, Consistent Oracle


5. Test Execution Time goes now

 가장 중요한 것부터 실행
 모든 TC를 다 실행해야 하는가?
 테스팅은 결함의 Fix를 목적으로 한다.
 초기의 테스트에 의하여 결함이 너무 많이 발견되는 경우
 일정의 압박
 새로운 TC의 생성
 자동화 여부
 False Positive, False Negative
 Logging Issue


6. Evaluating exit criteria & Reporting test results Time goes now

 Dash board – KPI (Key Performance Indicate)

 IEEE 829 – Reporting Template
 테스트 요약 보고 정의
 요약 (예를 들어, 무엇이 테스트 되었는지, 결과가 어떠한지 등..)
 변경 사항 (계획, TC, 절차)
 종합적인 평가
 결과의 요약 (예를 들어, 최종 매트릭, 개수)
 평가 (Pass/Faile 항목과 비교한 각 테스트 아이템에 대한)
 액티비티 요약 (자원 사용, 효율, 등)
 승인 사항


7. Closure Time goes now

 테스트 종료를 결정
 테스트 종료 조건이 모든 레벨의 테스트에서 만족됨을 확인
 Branch 커버리지
 사용자 요구사항
 비용과 시간
 발견된 결함 수 (예상 대비)


8. Test Control Time goes now

 모든 것은 계획대로 되지 않는다..
 계획대로 진행되는지 관리하고, 잘못되었으면 수정이 필요하다.


Good Software Tester Time goes now

비즈니스 전략을 분석과 테스트에 우선 순위화
이해하는 능력 대한 열정 및 체계화 능력

인내심~

적응 및
순수한 지적 능력 학습 능력

Software Tester

직접적인 감독 없이
전문 기술 일할 수 있는 능력
의사소통 능력


Software Team Time goes now


Time goes now

소프트웨어 개발과 테스팅


소프트웨어 개발(1/2) Time goes now

Problem Space Solution

[Question]

 Problem이 무엇인가?

 Solution은 무엇인가?

 Solution 구현을 위한 mechanism은
무엇인가?

Requirements  어떻게 구현할 것인가?

 해결되어야 할 문제가 무엇인가?

 고객이 구현된 산출물을 사용할 수 있는가?

 보완할 필요가 있는가?

 개발 기간 동안 발행되는 변화/변경을
어떻게 control 할 것인가?


소프트웨어 개발 (2/2) Time goes now

 Big bang 접근
 제품이 한번에 전달 된다
 Waterfall Model
 Cyclical 접근 / Iterative 접근
 제품이 단계마다 개발되고 전달 된다
 Spiral Model
 Iteration Model

정의 개발 유지보수
(Definition) (Development) (Maintenance)

무엇 어떻게 변경

보호활동 (Umbrella Activities)


소프트웨어 수명주기 Time goes now

 고품질의 소프트웨어를 구축하는 데에 요구되는 태스크(Task)에 대한 프레임워크(Framework)
 소프트웨어 개발활동에 필요한 다양한 태스크와 이에 대한 산출물

 모든 소프트웨어 개발 프로젝트의 필수적인 4가지 주요 단계
 Requirement (Elicitation, Analysis, Specification)
 System Design
 Program Implementation
 Test
 소프트웨어 수명주기
 프로젝트 별로 4가지 주요 단계를 다르게 해석한다.
 프로젝트 특성(기간, 사용기술, 도메인)에 따라 결정하여 적용
 각각의 특별한 스타일들은 “소프트웨어 수명주기라고 부른다.
 왜 수명주기 모델을 사용하는가?
 중요한 활동 식별, Milestone 정의, 진척도 측정의 용이
 개발 과정을 나눔으로써 관리하기가 쉽다

수명주기 모델 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 Request


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

Maintenance


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.


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

Implementation


Incremental vs. Iterative Time goes now

Delivery 1 Delivery 2 Delivery 3

Incremental Plan

Iterative Plan


Prototyping Model Time goes now

Start

Stop
Requirements
gathering
and refinement
시제품
Engineer Quick 개발 및 수정
product design

Refining Building
prototype prototype
고객의 Customer
의견 수렴 evaluation of
prototype

고객의 시제품 테스트


Spiral Model Time goes now

Cost

• 계획 • 위험 분석
목표, 대안, 제약 각 대안의 위험 분석 및
사항 결정 접근방법 선택
초기 요구사항 초기 위험 분석
분석과 계획 수립

고객의 반응에 따른
고객의 feedback을 위험 분석
반영한 계획

 추진여부 결정

Toward a completed
system
고객 평가
Time
첫 번째 prototype
다음 단계의 prototype
시스템 개발
• 고객 평가 • 개발

평가결과와 다음 반복을 개발과 다음 단계 작업산
위한 계획 출물의 검증


Incremental Model Time goes now

 General Case

 In Agile


[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

Implementation


[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
Walkthrough


[Variation Model] Multiple V-Model Time goes now


[Variation Model] Nested Multiple V-Model Time goes now

Nested V-Model Nested multiple V-Model


수명주기와 테스팅 Time goes now

 모든 개발 활동은 테스팅 활동과 대응된다.
 모든 개발 액티비티와 관련 있는 테스팅 액티비티가 있다.
 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있다.
 하위 레벨 테스팅
• 단위 테스팅(Unit Testing)
• 통합 테스팅(Integration Testing)
 상위 레벨 테스팅
• 사용성 테스팅(Usability Testing)
• 기능 테스팅(Function Testing)
• 시스템 테스팅(System Testing)
• 인수 테스팅(Acceptance Testing)

 주어진 레벨에 대한 테스트의 분석과 설계는 관련된 개발 액티비티 동안에 시작
되어야 한다.
 개발 수명 주기 모델에서 문서들의 배포판이 이용 가능하게 되면, 문서 리뷰 시
반드시 테스터들이 포함 되여야 한다.


테스트 구분 Time goes now

 소프트웨어 테스트는 관점에 따라 분류될 수 있다.
 단계, 목적, 방법, 시작

방법
블랙박스 테스트 화이트박스 테스트

목적
시각 단계 기능 테스트 성능 테스트 볼륨 테스트 구조 테스트

단위 테스트

통합 테스트
검증
(개발자)
확인 테스트

시스템 테스트

인수 테스트
확인
(사용자)
설치 테스트


테스트 레벨 Time goes now

 테스트 레벨
 한번에 총체적으로 조직화되고 관리하는 테스트 활동
 Unit, Integration, System, Acceptance Test Level
 SW/HW 모두 포함한다.
 독립적 테스트 계획
 독립적으로 테스트 된다.
 독립적 테스트 환경

레벨 설명
 단위 시험은 소프트웨어 설계의 기본 단위인 모듈 내부적인 오류를 발견하기 위한 시험이다.
단위 시험  단위 시험은 화이트 박스 방식과 블랙 박스 방식으로 수행할 수 있으며 일반적으로 화이트 박스 중심의
시험을 사용한다

 통합 시험은 이와 같은 인터페이싱과 관련된 오류를 발견하는 시험을 수행하고 동시에 프로그램 구조를
통합 시험
구성하는 체계적인 기법이다

 다른 시스템 요소인 하드웨어, 정보들과 통합되어 일련의 시스템 통합과 검증 시험이 수행
시스템 시험
 기능 요구사항과 비기능 용구사항을 모두 충족시켜야 함

 고객의 모든 요구사항을 만족하는지 확인
인수 시험  알파 테스트와 베타 테스트 (알파 테스트는 고객이 개발자의 위치에서 실행, 베타 테스트는 개발자가
참여 하지 않은 상황에서 실질적으로 프로그램을 실행하여 사용하는 환경에서 수행된다)

테스트 유형 Time goes now

유형 설명
 소프트웨어 기능 중심의 테스팅
기능 테스트  테스트 케이스 (대부분을 차지함)
(Functional Testing)  메뉴, 사용자 매뉴얼 챕터 제목이나 목차에서 기능 추출
 각각의 기능에 대해 기준, 출력, 내부 조건, 내부 상태를 파악하여 테스트 케이스 작성

 소프트웨어 제품 특성을 테스팅
 성능 테스팅, 부하 테스팅, 스트레스 테스팅
비기능 테스트
 사용성 테스팅
(Non-functional Testing)
 호환성 테스팅, 유지보수 테스팅, 신뢰성 테스팅, 이식성 테스팅
 보안성 테스팅

 구조 테스팅(화이트 박스)은 모든 테스트 레벨에서 수행될 수 있음
구조적 테스팅
 문장, 분기 등의 요소들에 대한 커버리지 측정
(Structural Testing)
 호출 계층 구조(calling hierarchy)와 같은 시스템의 아키텍처에 기반을 둘 수 있음

 변경 사항에 관련된 테스트
확인/회귀 테스팅  확인 테스트는 결함이 제거 후, 원래의 결점이 성공적으로 제거되었는지 확인하기 위한 테스트
(Confirmation/
 회귀 테스팅은 소프트웨어나 환경(environment)이 변경되었을 때 수행
Regression Testing)
 확인 테스팅을 사용하고, 회귀 테스팅을 지원하기 위해서는 테스트를 반복적으로 수행되어야 함

GREY BOX TESTING APPROACH


Time goes now

정적 테스팅 기법


테스트 기법 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
Combination


정적 테스팅 Time goes now

 정적 테스팅 (from wikipedia)

 Static testing is a form of software testing where the software isn't actually used
 It checks mainly for the sanity of the code, algorithm, or document

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


정적 테스팅 기법 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 분석 분석 결과 보고

리뷰 (1/4) Time goes now

 리뷰(Review)란 …
 SW 중간 산출물을 테스팅 하는 방법
 프로그램 코드, 요구사항 명세서, 설계 명세서, 테스트 계획서, 테스트 설계서, etc. …

 소프트웨어 개발 생명 주기의 앞부분에서 수행하여 결함 제거 비용이 저렴
 개발 생산성 향상, 개발 시간 단축, 테스트 비용과 시간 단축
• 보다 적은 내재 결함 수와 향상된 의사 소통으로 위 사항을 가능하게 함

 테스팅 기법 별로 다른 종류의 결함 발견 (상호보완적)
 리뷰
• 코드 또는 문서상의 결함 (failure는 발견하지 못함)
• 표준과의 불일치성, 설계 결함, 유지보수의 불충분성, 인터페이스 명세 결함
 정적 분석
• 코드의 복잡도, 구문 에러, Missing 파라미터, Dead 코드 등



 리뷰(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 Test



 리뷰 타입

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)



 리뷰의 성공요소
 각각의 리뷰가 명확하게 미리 정의된 목적이 있어야 함
 적합한 인력이 선택되어야 함
 결함 발견은 언제나 환영하는 분위기이고 결함은 객관적으로 표현되어야 함
 People issues와 심리적인 측면이 고려되어야 함
 리뷰 기법이 적절히 적용되어야 함
 효과적/효율적인 결함 발견을 위하여 필요 시 체크리스트 활용
 (역할 분담도 적절히 활용)
 리뷰 기법에 대한 교육 훈련 제공 (특히, 인스펙션의 경우)
 경영층이 리뷰 프로세스를 지원 (프로젝트에서 리뷰 기법 적용에 일정 할당)
 학습과 프로세스 개선에 대한 강조


리뷰 단계 Time goes now

 인력을 선발
 개인별 역할(role)을 할당 및 문서들의 어떤 부분들을 살펴 볼 것인가를 결정
 시작과 종료 조건(entry and exit criteria)을 정의

 문서를 분배하고, 참가자들에게 리뷰 목적, 프로세스, 문서들에 대해 설명
 시작 조건을 확인

 참가자 개개인들 스스로가 리뷰 미팅 전에 잠재적인 결함, 질문과 코멘트들을 기록
 반드시 체크리스트를 사용

개별 준비 리뷰 미팅
계획 킥오프 재 작업 추가작업
Individual Review
(Planning) (Kick-Off) (Rework) (Follow-up)
Preparation Meeting

 문서화 된 기록 또는 상세한 기록과 더불어 논의와 로깅
 결함에 대한 기록
 미팅 참석자들은 결함(defects)을 처리하기 위한 충고사항을 제시

 발견된 결함을 처리
 일반적으로 작성자(Author)에 의하여 행해진다

 처리된 결점을 확인하고 측정 기준들을 수집
 좀더 형식적인 리뷰들을 위해서 종료 조건에 대한 확인


역할과 책임 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))


비형식 리뷰와 기술 리뷰 Time goes now

 Informal Review vs. Technical Review

Informal Review Technical Review
 저비용 문서/코드 검토  기술적 문제 해결
- 혜택을 얻는 비용이 많이 들지 않는 방법  토론, 의사결정, 대안 평가
주요 목적
 결함 발견
 명세서 또는 표준과의 적합성 체크

 (선택적) Pair 프로그래밍  동료 또는 기술 전문가가 문서화하고, 정의된 결
참여자
 기술 선임자가 설계와 코드 리뷰 함 발견 프로세스에 참여

문서화  (선택적) 문서화  실무에는 Informal 또는 Formal

 리뷰어에 따라 효과가 다양  실무에는 Informal 또는 Formal
효과
 정보 공유 및 교육

사전 준비  미팅 사전 준비 단계를 거침

 Pair programming  이상적으로는 Moderator가 미팅 주도
 기술 리더가 디자인과 코드를 리뷰  선택적 체크리스트
기타
 리뷰 리포트, 인시던트 리스트
 경영층 참여 활동


Walkthrough Time goes now

 Walkthrough …
 개발자(Author) 진행
 학습, 시스템에 대한 이해가 목적
 시간, 인원수 제한 없음,
 준비 과정은 선택적
 비형식적인 것에서부터 매우 형식적인 까지 다양

기술적 리스크 Inspection
기술적 리뷰
기술적 리뷰
Walkthroughs

비공식적 리뷰 Walkthroughs

사업적 리스크


Inspection Time goes now

 Inspection …
 체크리스트와 규칙을 기반으로 하는 정식 프로세스
 저자가 아닌 훈련된 Moderator에 의한 진행 및 제어
 미팅 전 준비 과정 거침
 프로세스 개선(선택적)
 인스펙션 리포트와 발견사항 리스트 산출
 주요 목적 : 결함 발견
 정식적인 결함 수정 확인
 매트릭을 수집하고 활용함 "하나의 좋은 인스펙션은 30,000개의
테스트케이스와 동등한 효과를 가져올 수 있다."
 인스펙션 대상 -Vern Crandell

 요구사항, 설계 등의 문서 산출물
 개발 단계의 소스 코드
 도입 효과
 에러 예방, 비용 절감, 팀간 커뮤니케이션 향상, 이용 감소,


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-Work


체크리스트 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 doesn't 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?


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)


Software Metric (1/2) Time goes now

 매트릭이란 무엇인가?
 나쁜 디자인과 좋은 디자인을 구별할 수 있는 측정 가능한 항목에 대한 정의
 시스템에 특성에 대한 수량적 측정치
 왜 매트릭을 사용하는가?
 소스의 좋고 나쁨의 정도를 알려준다.
 제품/프로세스의 품질을 예측하게 해준다.
 품질 향상에 활용이 가능
• 제품 및 프로세스
 새로운 도구나 기법이 생산성에 주는 영향을 파악
 유지보수에 들어갈 자원과 노력을 예상/감소
 소프트웨어 매트릭의 특징
 계산이 가능하다 (자동 계산 또는 임의로 결정)
 개발주기 초기에 확보가 가능하다.
 일부 단일 시스템에서는 의미가 없을 수 있다.
 언어에 독립적이다.

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 Metrics


[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 Level
Program 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  Halstead's 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 directly
Programming 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 don't 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 Operands
int 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), <, return
int 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 don't..."
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


 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


 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


 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 package's 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


 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


 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)
 프로그램의 제어 구조를 파악하기 위하여 프로그램을 분석


Data Structure Analysis Time goes now

 데이터 구조 분석
 프로그램과 독립적으로 데이터 구조 자체를 분석
 데이터 모델 작성 및 활용
 프로그램의 이해도를 높여준다
• 프로그램 작성 시  주석 활용

 프로그램 작성 시 처리하는 데이터 작성에 대한 정보를 제공
 테스트 케이스 설계 시 이용 가능
 프로그램 성능에 영향을 미침
 데이터 구조 최적화
• 중복 데이터 제거
• 데이터의 분할과 합병
 데이터 특성에 따른 분류
• Read Only
• Read/Write
• Persistent / Temporary


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;


Time goes now

동적 테스팅 기법


동적 테스팅 Time goes now

 동적 테스팅
 소소 코드를 실행하면서 테스트
 Code Coverage – Statement/Decision/Condition Systematic approach와

 Test Bed 필요 Non systematic approach의
두 가지 접근 방법이 있다.

 블랙 박스
 소스 코드 없이 실행만으로 테스트
 TC를 만들고 기대 값을 산출 후 해당 TC가 기대하는 값과 일치하는지 확인
 화이트 박스
 소스 코드를 가지고 테스트하는 방법,
 디버깅, 단위 테스트, 스크립트의 자동 실행
 검출 가능 결함
 기능의 구현 여부
 메모리 누수, Pointer 관련
 성능. 자원의 사용


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, monitors


블랙박스 테스트 Time goes now

 블랙박스 테스트
 소프트웨어 내면을 알 수 없는 블랙박스로 규정, 외부에서 기능, 성능 등을 테스트
 기능 위주의 테스트
 모듈의 입력과 출력, 모듈이 수행하는 기능을 테스트
 요구에 맞게 잘 작동하는가에 초점을 맞춘 테스트 방법

 블랙박스 테스트 기법
 Equivalence partitioning
 Boundary value analysis
 Decision table
 State transition testing
 Cause-effect graphing
 Syntax testing
 Random testing
 …

동등 분할 Time goes now

 동등 분할(Eequivalence partitioning)
 가정 :
 하나의 값이 정상적으로 동작한다면, 다른 모든 값도 정상적으로 동작할 것이다.
 전체에서 테스트하는 것보다, 각각의 부분에서 하나씩 테스트하는 것이 낮다

 입력 값/출력 값 영역을 유한개의 상호 독립적인 집합으로 나눈 후 등가 집합의
원소 중 대표 값 하나를 선택하여 테스트 케이스 선정
 경험이나 필요에 따라 하나 이상의 값을 선정할 수 있음

invalid valid invalid

0 1 100 101


경계값 분석 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
analysis


결정 테이블 Time goes now

 결정 테이블 (Decision Table)
 여러 종류의 입력 값의 조합으로 인한 연관성을 확인하는 방법
 Input, Output 의 값이 Boolean 일 경우 유리
 조건
 조건의 순서에 따라 행위가 달라지지 않는다.
 결과는 조건의 조합에만 영향을 받는다.
 결정 테이블은 조건부(Condition Section)과 액션부 (Action Section)으로 구성
 조건 : 발생 가능한 모든 사항을 나열
 액션 : 발생 가능한 조건에 따라 처리해야 할 작업을 나열

Input Condition의 단순화 (Test case 수 감소)


원인-결과 그래프 Time goes now

 원인-결과 그래프(Cause-Effect Graph)
 입력 데이터간 관계가 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성
높은 시험 사례를 발견
 입력 조건의 조합을 체계적으로 선택하여 개수를 조절
 동치 클래스, 경계값 분석의 단점
 각각의 입력을 별도로 생각

D Fails

G1

A Fails B or C Fail

A G2

B Fails C Fails

Fishbone Diagram Fault Tree


화이트박스 테스트 Time goes now

 화이트박스 테스트
 프로그램 상에 허용 되는 모든 논리적 경로를 파악하거나 경로상의 복잡도를 계산
하여 테스트
 코드 분석과 프로그램 구조에 대한 지식을 바탕으로 문제가 발생할 가능성이 있는
모듈 내부를 테스트하는 방법입니다
 화이트박스 테스트 기법
 Statement testing
 Branch / Decision testing
 Data flow testing
 Branch condition testing
 Branch condition combination testing
 Modified condition decision testing
 LCSAJ testing
 …

테스트 커버리지 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 추가 지침

구조적 커버리지 Time goes now

Enough
tests?
Tests
Spec
Software Results OK?

What's Coverage OK?
More tests covered?

Stronger structural techniques
(different structural elements)

Increasing coverage


소프트웨어 테스팅

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

Similaire à 소프트웨어 테스팅

Similaire à 소프트웨어 테스팅 (20)

Plus de 영기 김

Plus de 영기 김 (13)

Dernier

Dernier (7)

소프트웨어 테스팅