14 testing(2010).ppt [호환 모드] - dongguk · 2011-12-19 · lecture 14 테스트...

LECTURE

1414테스트테스트테스트테스트

모든 코드가 실행될 때까지 코딩 작업이 완료된 것은 아니다.

- Pragmatic Programmer

테스트는 조기에, 자주, 자동화 하는 것이 좋다.

- Pragmatic Programmer

최은만, CSE 4039 소프트웨어 공학

Outline

테스트 작업의 원리와 목표테스트 작업의 원리와 목표

테스트의 단계와 테스트의 종류

블랙박스 테스트

화이트 박스 테스트

통합 테스트, 인수 테스트

테스트 자동화 도구테스트 자동화 도구


소소 개개

테스트테스트에 필요한 시간과 노력 ---> 매우 크다

그러나 테스트는 대부분 초보자나 개인의 역량에 맡기는 경우가 많음

정 의시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동 방법을 동원하여 검사하고 평가하는 일를 보이는지 수동 또는 자동 방법을 동원하여 검사하고 평가하는 일련의 과정[IEEE, 1993]

숨어있는 결함을 찾기 위해 소프트웨어를 작동 시키는 일련의 행위와절차

---> 결함이 없음을 증명하는 것이 아니고 결함이 존재함을 보여주는 작업

테스트 --> 분석, 설계 도중에 일어나는 검증, 검토 등 품질보증을 위한 모든 행위

최은만, CSE 4039 소프트웨어 공학 3

테스트와테스트와 개발개발 단계단계 (V(V모형모형))

테스트 단계와 소프트웨어 개발 단계의 관계

개발 단계 테스트 단계

범위와 목표 인수테스트

요구 분석 시스템 테스트

리그레션 테스트

구조 설계

프로그램 설계

통합 테스트

단위 테스트프로그램 설계

코 딩

단위 테스트


코 딩

소프트웨어소프트웨어 심리심리

프로그래머의 심리

자신의 프로그램이 맞다고 생각, 그러나 프로그램은 테스트에 의하여

확임됨

프로 램 안의 오류를 인신 공격 는 개인 평가로 해석하여 테스트프로그램 안의 오류를 인신 공격, 또는 개인 평가로 해석하여 테스트

를 기피

egoless programming, democratic programmingegoless programming, democratic programming

심리적 불안

테스트는 파괴적인 과정(destructive process)으로 생각

이를 극복하기 위하여 테스트하기 전에 예상 결과를 준비

i d d t t t t t t tiindependent test, test automation


테스트테스트 이슈이슈

소프트웨어 신뢰도 요구의 증가

오류의 방지

개발 단계에서의 오류 유입 방지

테스트 케이스 설계 기술테스트 케이스 설계 기술

모듈화 설계가 테스트에 드는 노력을 줄임

개발 전 단계에서의 Verification and Validation 노력

대부분의 오류는 설계 단계에서의 정보 관리 부재에 기인

설계 오류가 제일 많음

오류 수정에 드는 비용오류 수정에 드는 비용

테스트는 전 개발 단계에서 이루어져야 함

리그레션 테스트의 비용이 매우 큼

테스트 환경을 다시 구축하는데 드는 비용

소프트웨어 테스트에 대한 이론적 기초

소프트웨어 오류의 성질을 이해


소프트웨어 오류의 성질을 이해

6

테스트의테스트의 유형유형

ValidationAre we building the right product?

Verification Are we building the product right?Are we building the product right?

인증(Certification)A written guarantee

정적 분석(St ti A l i )정적 분석(Static Analysis)

동적 분석(Dynamic Analysis)

단계별단위 테스트(unit test)

통합 테스트(integration test)

인수 테스트(acceptance test)인수 테 ( p )


테스트의테스트의 유형유형

시험 방법

화이트 박스 테스트

블랙 박스 테스트

기능 시험기능 시험

성능 시험

스트레스 시험레 시험

Benchmark 시험

Field 시험

리그레션 테스트

품질 보증


테스트의테스트의 원리원리

테스트의 단계

1) 테스트에 의하여 무엇을 점검할 것인지 정한다.

<예> 테스트의 목표 - 기능의 완벽성, 신뢰도

2) 테스트 방법을 결정한다2) 테스트 방법을 결정한다.

<예> 검사, 증명, 블랙박스 테스트, 화이트 박스 테스트, 자동화 도구

3) 테스트 케이스를 개발한다.3) 테 케이 를 개발한다.

- 테스트 자료, 시행 조건

4) 테스트의 예상되는 올바른 결과를 작성한다.

- 테스트 오라클(test oracle)

5) 테스트 케이스로 실행시킨다.

- 테스트 하니스(test harness)가 필요테스트 하니스(test harness)가 필요


테스트에테스트에 대한대한 올바른올바른 이해이해

테스트는 오류를 발견하려고 프로그램을 수행 시키는 것

따라서 테스트에 의하여 오류가 발견되지 않았다고 하여 프로그램에 오류가 없는 것은 아님

완벽한 테스트는 불가능하다완벽한 테스트는 불가능하다.

테스트는 창조적인 일이며 힘든 일이다.

테스트는 오류의 유입을 방지할 수 있다.

테스트는 구현에 관계없는 독립된 팀에 의하여 수행되어야 함


오류오류 패턴패턴

테스트는시스템의오류 패턴과 매우 밀접한 관련

모듈에 오류가 너무 많다면 오류 없는 모듈이 될 수 있도록 테스트하여 고치는 것은 한계


화이트화이트 박스박스 테스트테스트

모듈 안의 작동을 자세히 관찰하는 시험

구조적 시험

검증 기준(test coverage)

1) statement coverage

• 원시코드의 모든 문장을 한번 이상 수행

2) decision coverage

• 선택구조 조건의 모든 경우가 적어도 한번씩 테스트

3) loop coverage3) loop coverage

• 루프 구조를 완벽히 테스트

① 반복조건을 만족하지 못하여 루프를 수행시키지 못한 경우

② 루프 안의 내용을 한번만 수행

③ 한번 이상 수행


화이트화이트 박스박스 테스트테스트

화이트 박스 테스트 순서

1) 논리 흐름도에 의한 표현

2) 테스트 케이스 생성

논리 흐름도논리 흐름도

모듈 내의 제어흐름을 간선으로 표시한 그래프

• 세그멘트 ---> 정점

• 제어흐름 ---> 간선

세그멘트의 발견


점수의점수의 평균을평균을 구하는구하는 모듈모듈

procedure FindMean(var Mean: real; var ScoreFile: file of real);

if Score > 0.0 then

begin{Procedure which reads in a series of real values form a file, sums the values and computes their mean. The mean is computed by dividing the sum of the scores by the number of scores by the number of scores read in }

begin

SumOfScores := SumOfScores + Score;

NumberOfScore := number of scores read in.}

var Score, SumOfScores, NumberOfScores: real;

NumberOfScore + 1.0

end;

end;

begin

{Initialize SumOfScores and N OfS }

{Compute the mean and print the results.}

if NumberOfScores > 0.0 thenNumberOfScores to zero}

SumOfScores := 0.0;

NumberOfScores := 0.0;

{Read in and sum the scores and

if NumberOfScores > 0.0 then

begin

Mean := SumOfScores/NumberOfScores;

{Read in and sum the scores and count the number of scores}

while not eof(ScoreFile) do

begin

writeln('The mean score is ', Mean)

end

else writeln('No scores were entered.')

d;


b g

read(ScoreFile, Score);end;

NN--S S 도표도표

SumOfScore <- 0.0

NumberOfScores <- 0.0 ①

Mean <- 0.0

read a Scoreread a Score

while there are still Scores to be read in do

② T Score > 0.0 ? ③ F

SumOfScores<-SumOfScores+ScoreSumOfScores< SumOfScores Score

④ ⑤

NumberOfScore<-NumberOfScores+1

read a Score ⑥read a Score ⑥

T ⑦ NumberOfScores > 0.0 F

Mean<-SumOfScores/

NumberOfScores write "No scoresNumberOfScores write No scores

⑧ were entered."

write "The mean is", ⑨

Mean


Mean

논리흐름도논리흐름도


테스트테스트 케이스케이스

검증기준에 따라 논리 흐름도의 경로를 적어도 한번씩 방문하도록테스트 케이스를 추출

<예>

테스트 케이스 경로테스트 케이스 경로

score=89.0 a, b, d, h, c, i

<eof> a, c

score=53.41, -77.0 a, b, d, h, b, e, h, c, j


화이트화이트 박스의박스의 실행실행

모 듈 이 름 : 모 듈 번 호 :모 듈 이 름 :_________________ 모 듈 번 호 : ______________저 작 자 :_________________ 테스트담당자 : ______________

선택/루프 가능결과 1 2 3 4 5 6 7 8

skip ∨

while not of once ∨

>1 ∨>1 ∨

if Score > 0 T ∨

F ∨

if NumberOf T ∨ ∨

Score>0.0 F ∨

케이스 # 값 예상되는 결과 실행 결과1. 89.0<eof> Mean=89.02. <eof> 'No scores were entered'3 53 41-77 0<eof> Mean=53 41


3. 53.41 77.0<eof> Mean 53.414.

테스트테스트 기준기준(Test Coverage)(Test Coverage)gg

Random Test<예> Ax^2 + Bx + C = 0

A B C

4 5 1

5 -7 2

1 2 -3

Statement Test<예>

1 if (X>3 AND Y=2) then 1

2 Z=1;

endif; 2

3 if (X=4 OR Z>3) then 3

5 Z=Z+1;

endif; 4endif; 4

5

Test path: 1, 2, 3, 4, 5


테스트테스트 기준기준

Branch Test

1, 2, 3, 4, 5

1, 3, 5

Path TestPath Test

1, 2, 3, 4, 5

1, 3, 5

1, 2, 3, 5

1, 3, 4, 5

Condition TestCondition Test

test all branches and all possible outcomes of multiple conditions

(X=5 Y=2 Z=3) (X=4 Y=3 Z=3) (X=5 Y=3 Z=4)(X=5, Y=2, Z=3) (X=4, Y=3, Z=3) (X=5, Y=3, Z=4)


사례사례: : 문장문장 검증검증 기준기준

• 문장검증기준• 문장검증기준1-2-3-4-5-6-7 • 선택검증기준

1-2-3-4-5-6-71-2-3-5-6-1 경로검증 기준• 경로검증 기준1-2-3-4-5-6-71-2-3-4-5-6-11 2 3 4 5 6 11-2-4-5-6-7 1-2-4-5-6-1 • 조건검증기준

if (x > 1 or y < 10)


블랙블랙 박스박스 테스트테스트

모듈이 요구에 맞게 잘 작동하는가에 초점

기능 테스트

모듈의 외형(입력, 출력)

모듈의 기능 위주의 검사모듈의 기능 위주의 검사

동치분해(equivalence partitioning)

입력조건을 여러 개의 동치 클래스로 나눔

¬ 입력이 일정한 범위 안의 값을 가져야 한다면 최소한 세 개의 동치 클래스가 존재한다. 범위보다 작은 값, 범위 내의 값, 범위를 넘어서는큰 값.큰 값

<예> 현금자동 지급기의 총 지급액 범위:1000원-30만원

① 1000원에서 30만원 사이의 값(정상)

② 1000원 미만의 값(비정상)② 1000원 미만의 값(비정상)

③ 30만원보다 큰 값(비정상)


동치동치 분해분해- 이산적 집합에 속하는 값이어야 정상 입력이라면 두 가지 동치 클래스가

존재한다. 정상 입력에 속하는 값, 그 외의 값,

<예> 학적관리 시스템에서의 재학상태

① 재학상태의 정상적인 값, 즉 재학, 휴학, 졸업, 중퇴

② 그 외의 비정상적인 값

<예> 품명, 1, 2, 3, 4 13. 오름차순의 무게(정상): 1, 2, 3

② 외의 비정상적인 값

m 식료품점 전산화를 위한 모듈의 블랙 박스 테스트입력: 식료품 이름, 무게(온스; 1-48)

예 , , , ,

1. 영문자 이름(정상): AbcDef

2. 영문자가 아닌 이름(비정상): A2X?/

3. 길이가 2 미만의 문자(비정상): A

4 2 이상 15 이하의 문자(정상): AbcDef

, ,

14. 오름차순이 아닌 무게(비정상): 2, 1, 3

15. 무게가 입력되지 않음(비정상)

16. 한개 이상 다섯개 까지의 무게(정상): 1, 2, 3

17. 다섯개 이상의 무게값(비정상): 1, 2, 3, 4, 5, 64. 2 이상 15 이하의 문자(정상): AbcDef

5. 길이가 15 보다 큰 문자열(비정상):

abcdefghijklmnopqr

6. 1 보다 작은 값(비정상): -1

7 1과 48 사이의 값(정상): 24

17. 다섯개 이상의 무게값(비정상) 1, 2, 3, 4, 5, 6

18. 품명이 먼저 입력(정상): AbcDef, 1, 2, 3

19. 품명이 먼저가 아님(비정상): 1, AbcDef, 2, 3

20. 하나의 쉼표로 입력의 요소들을 분리(정상): AbcDef, 1, 2, 37. 1과 48 사이의 값(정상): 24

8. 48 보다 큰 값(비정상): 127

9. 정수(정상): 24

10. 실수(비정상): 5.3 또는 7 1/2

11 숫자(정상): 24

, , ,

21. 쉼표로 입력요소를 분리하지 않음(비정상): XYZ 1, 2, 3

22. 입력이 빈칸을 포함하지 않음(정상): AbcDef, 1, 2, 3


11. 숫자(정상): 24

12. 숫자 아님(비정상): 5%23. 입력이 빈칸을 포함(비정상): A bcDef, 1, 2, 3

Boundary TestBoundary Testyy

테스트케이스 예상되는결과 동치클래스테스트케이스 예상되는결과 동치클래스

a. Xy, 1

b. AbcDefghijklmno,

정상

정상

1, 4(LB), 7(LB), 9, 11,

13, 16(LB), 18, 20, 22

1, 4(UB), 7(LB), 7(UB), 9,1, 2, 3, 4, 48

c. A2x?, 1

d. A, 1

b d f hijkl

비정상

비정상

비정상

, , , , ,

11, 13, 16(UB), 18, 20, 23

2

3e. abcdefghijklmnop

f. Xy, -1, 5

g. Xy, 0

h Xy 49

비정상

비정상

비정상

비정상

5

6, 10, 12

7(BB)

8 7(AB)h. Xy, 49

i. Xy, 2, 1, 3, 4, 5

j. Xy

k. Xy, 1, 2, 3, 4, 5, 6

비정상

비정상

비정상

비정상

8, 7(AB)

14

15

17l. 1, Xy, 2, 3, 4, 5

m. Xy, 1, 2, 3, 4, 5

비정상

비정상19

21


통합통합 테스트테스트(Integration Test)(Integration Test)gg

통합 테스트의 목적1) 시스템을 구성하는 모듈의 인터페이스와 결합을 테스트

2) 시스템 전체의 기능과 성능을 테스트

통합 순서에 따라통합 순서에 따라1) 동시식(big-bang)

2) 하향식(top-down)

3) 상향식(bottom-up)3) 상향식(bottom up)

4) 연쇄식(threads)

통합시 필요한 소프트웨어테스트 하니스 부분적인 테스트를 위하여 코드에 삽입하는 프로그램테스트 하니스: 부분적인 테스트를 위하여 코드에 삽입하는 프로그램--> 추후 삭제됨

스텁(stub): 시험 대상 모듈이 호출하는 모듈 대신에 만들어진 모의서브루틴서브루틴

드라이버(driver): 시험 대상 모듈을 호출하는 모의 모듈


동시식동시식 통합통합(Big Bang)(Big Bang)g gg g

모든 모듈을 한꺼번에 통합하여 테스트든 듈을 한꺼번에 통합하여 테

단위 테스트에 많은 시간이 필요

시스템의 중요 부분과 부수적인 부분을 구별하지 않음시스템의 중요 부분과 부수적인 부분을 구별하지 않음

일정 계획에 융통성이 없음

오류가 있을 경우 어떤 모듈이 변경되어야 하는지 파악하기 어려움오류가 있을 경우 어떤 모듈이 변경되어야 하는지 파악하기 어려움


하향식하향식 통합통합(Top(Top--Down)Down)pp

시스템 구조도의 위에 있는 모듈부터 아래 층의 모듈로 내려 오면서 통합

점증적 통합이므로 하드웨어의 사용이 분산되고 오류의 원인을 찾아 내기 쉬움아 내기 쉬움

상위층의 중요한 모듈을 먼저 시험

---> 시스템의 골격을 조기에 테스트 함

스텁의 사용으로 시스템의 모양을 사용자에게 조기에 보여줄 수 있음

프로그래머가 시스템의 작동에 대한 확신을 유지시킬 수 있음프로그래머가 시스템의 작동에 대한 확신을 유지시킬 수 있음


상향식상향식 통합통합(Bottom(Bottom--Up)Up)pp

최하위 모듈을 먼저 시험

드라이버가 필요

오류 발견이 쉽고 하드웨어의 사용을 분산

하위층의 모듈을 상위층 보다 더 많이 시험

테스트의 초기에 뼈대가 갖추어지지 않음


연쇄식연쇄식 통합통합(Threads)(Threads)

최선의 통합 방법

어느 정도의 기본 기능을 수행하는 모듈(thread)로부터 통합

시스템의 중요한 기능을 담당하는 모듈부터 통합

초기에 시스템을 골격을 보여주고 사용자의 의견을 받아 수정 가능


사례사례: : 색인제작색인제작 시스템시스템 통합통합


기능기능 테스트테스트(Functional Test)(Functional Test)

시스템 Rental-Out Modules 테스트 케이스 #：테스트 시행자 일시：테스트 시행자 일시：

호출 또는 리턴되는 입력, 사용자 반응 예상되는 자료 예상되는 출력 테스트 결과

모듈 이름 구조의 변화Handle Costume Rental 사용자 "Rental (없음) Rental 메뉴 화면

C t t"선택 출력Costume out"선택 출력Rental Out 사용자 "Non-fee (없음) Fee/NoFee 메뉴

Rental" 선택 화면 출력Get No Fee Rental 사용자 입력 New Renter 레코드 사용자 입력I f 항목 변경： 자료가 프린트Info 항목 변경： 자료가 프린트

Renter Name： Renter Name <-J. M. Kim J. M. Kim

Organization： Organization <-CS Department CS DeptCS Department CS Dept.

Campus Address： Campus Address <-WonHeung Hall WonHeung Hall

S#： 415-74-8837 S# <- 415-74-8837Date Out： 3/27/94 Date Out < 3/27/94Date Out： 3/27/94 Date Out <- 3/27/94Expected Date/n： Expected Date/n <-

4/2/94 4/2/94Puller： M.Lee Puller <- M. Lee

Rental Out (없음) (없음)


Rental Out (없음) (없음)

인수인수 테스트테스트

목적

시스템이 사용할 수 있도록 모든 준비가 되어 있는지를 보이는 것

사용할 모든 준비가 되었다는 것을 확인시켜 주는 작업

테스트 방법은 사용자가 선택테스트 방법은 사용자가 선택

인수 테스트 방법의 대부분은통합 테스트와 같음. 다른 점은 사용자 환경에서 한다는 것

베타 테스트

고객의 사용 환경에서 시험

개발자 없이 사용 환경에 소프트웨어를 설치하여 시험개발자 없이 사용 환경에 소프트웨어를 설치하여 시험


테스트테스트 자동화자동화 도구도구

코드 분석 도구

정적 분석 도구

• 코드 분석 도구: 원시 코드의 문법적 적합성을 자동으로 평가하여 잘못된문장을 표기장 기

• 구조 검사 도구: 원시코드의 그래프를 생성하여 논리 흐름을 보여주고 구조적인 결함이 있는지 체크

• 데이터 분석 도구: 원시 코드에 정의된 데이터 구조, 데이터 선언, 컴포넌트 인터페이스를 검사. 잘못된 링크나 데이터 정의의 충돌, 잘못된 데이터의 사용 등을 발견

• 순서 검사 도구: 이벤트의 순서 체크. 잘못된 순서로 코딩되어 있다면 이벤트를 지적벤트를 지적

동적 분석 도구

• 프로그램이 수행되는 동안 이벤트의 상태를 파악하기 위하여 특정한 변수나 조건의 스냅샷( h t)을 생성나 조건의 스냅샷(snapshot)을 생성


테스트테스트 케이스케이스 생성생성 도구도구

자료 흐름도

원시 프로그램을 입력받아 파싱한 후 자료 흐름도를 작성

define-use 관계

찾으려는 변수에 영향을 주는 요소들을 모아 테스트 경로를 구동시키찾으려는 변수에 영향을 주는 요소들을 모아 테스트 경로를 구동시키는 입력값들을 찾아낸다.

기능 테스트

주어진 기능을 구동시키는 모든 가능한 상태를 파악하여 이에 대한입력을 작성

입력 도메인 분석입력 메인 분석

원시코드의 내부를 참조하지 않고

입력 변수가 가질 수 있는 값의 도메인 분석

랜덤 테스트랜덤 테스트

입력 값을 무작위로 추출

시스템의 신뢰성 분석에 사용


테스트테스트 실행실행 도구도구

캡쳐 및 리플레이

테스트 계획에 표시된 테스트 데이터를 자동으로 입력하고 실행 과정에 발생하는 화면이나 인쇄되는 결과를 캡쳐

예상되는 결과와 비교예상되는 결과와 비교

예상되는 결과와 차이를 보일 경우 테스트 프로그래머에게 보고

오류를 발견하고 수정한 후 고치는 작업이 바르게 되었는지 확인하는데 유용데 유용

자동적으로스텁과 드라이버를생성하는 도구

자동 테스트 환경자동 테 환경

테스트 수행 도구들이 테스트 환경으로 통합되어 제공


14 testing(2010).ppt [호환 모드] - dongguk · 2011-12-19 · lecture 14 테스트...

Documents