Microsoft PowerPoint - 14_Testing(2010).ppt [호환 모드]

Size: px

Start display at page:

Download "Microsoft PowerPoint - 14_Testing(2010).ppt [호환 모드]"

예인 점
5 years ago
Views:

1 LECTURE 14 테스트 모든코드가실행될때까지코딩작업이완료된것은아니다. - Pragmatic Programmer 테스트는조기에, 자주, 자동화하는것이좋다. - Pragmatic Programmer 최은만, CSE 4039 소프트웨어공학

2 Outline 테스트작업의원리와목표 테스트의단계와테스트의종류 블랙박스테스트 화이트박스테스트 통합테스트, 인수테스트 테스트자동화도구 최은만, CSE 4039 소프트웨어공학

3 소 개 테스트 테스트에필요한시간과노력 ---> 매우크다 그러나테스트는대부분초보자나개인의역량에맡기는경우가많음 정의 시스템이정해진요구를만족하는지, 예상과실제결과가어떤차이를보이는지수동또는자동방법을동원하여검사하고평가하는일련의과정 [IEEE, 1993] 숨어있는결함을찾기위해소프트웨어를작동시키는일련의행위와절차 ---> 결함이없음을증명하는것이아니고결함이존재함을보여주는작업 테스트 --> 분석, 설계도중에일어나는검증, 검토등품질보증을위한모든행위 최은만, CSE 4039 소프트웨어공학 3

4 테스트와개발단계 (V 모형 ) 테스트단계와소프트웨어개발단계의관계 개발단계 테스트단계 범위와목표 인수테스트 요구분석 구조설계 시스템테스트 통합테스트 리그레션테스트 프로그램설계 단위테스트 코딩 최은만, CSE 4039 소프트웨어공학 4

5 소프트웨어심리 프로그래머의심리 자신의프로그램이맞다고생각, 그러나프로그램은테스트에의하여확임됨 프로그램안의오류를인신공격, 또는개인평가로해석하여테스트를기피 egoless programming, democratic programming 심리적불안 테스트는파괴적인과정 (destructive process) 으로생각 이를극복하기위하여테스트하기전에예상결과를준비 independent d test, t test t automation ti 최은만, CSE 4039 소프트웨어공학 5

6 테스트이슈 소프트웨어신뢰도요구의증가 오류의방지 개발단계에서의오류유입방지 테스트케이스설계기술 모듈화설계가테스트에드는노력을줄임 개발전단계에서의 Verification and Validation 노력 대부분의오류는설계단계에서의정보관리부재에기인 설계오류가제일많음 오류수정에드는비용 테스트는전개발단계에서이루어져야함 리그레션테스트의비용이매우큼 테스트환경을다시구축하는데드는비용 소프트웨어테스트에대한이론적기초 소프트웨어오류의성질을이해 최은만, CSE 4039 소프트웨어공학 6

7 테스트의유형 Validation Are we building the right product? Verification Are we building the product right? 인증 (Certification) A written guarantee 정적분석 (Static ti Analysis) 동적분석 (Dynamic Analysis) 단계별 단위테스트 (unit test) 통합테스트 (integration test) 인수테스트 (acceptance test) 최은만, CSE 4039 소프트웨어공학 7

8 테스트의유형 시험방법 화이트박스테스트 블랙박스테스트 기능시험 성능시험 스트레스시험 Benchmark 시험 Field 시험 리그레션테스트 품질보증 최은만, CSE 4039 소프트웨어공학 8

9 테스트의원리 테스트의단계 1) 테스트에의하여무엇을점검할것인지정한다. < 예 > 테스트의목표 - 기능의완벽성, 신뢰도 2) 테스트방법을결정한다. < 예 > 검사, 증명, 블랙박스테스트, 화이트박스테스트, 자동화도구 3) 테스트케이스를개발한다. - 테스트자료, 시행조건 4) 테스트의예상되는올바른결과를작성한다. - 테스트오라클 (test oracle) 5) 테스트케이스로실행시킨다. - 테스트하니스 (test harness) 가필요 최은만, CSE 4039 소프트웨어공학 9

10 테스트에대한올바른이해 테스트는오류를발견하려고프로그램을수행시키는것 따라서테스트에의하여오류가발견되지않았다고하여프로그램에오류가없는것은아님 완벽한테스트는불가능하다. 테스트는창조적인일이며힘든일이다. 테스트는오류의유입을방지할수있다. 테스트는구현에관계없는독립된팀에의하여수행되어야함 최은만, CSE 4039 소프트웨어공학 10

11 오류패턴 테스트는시스템의오류패턴과매우밀접한관련 모듈에오류가너무많다면오류없는모듈이될수있도록테스트하여고치는것은한계 최은만, CSE 4039 소프트웨어공학 11

12 화이트박스테스트 모듈안의작동을자세히관찰하는시험 구조적시험 검증기준 (test coverage) 1) statement coverage 원시코드의모든문장을한번이상수행 2) decision coverage 선택구조조건의모든경우가적어도한번씩테스트 3) loop coverage 루프구조를완벽히테스트 1 반복조건을만족하지못하여루프를수행시키지못한경우 2 루프안의내용을한번만수행 3 한번이상수행 최은만, CSE 4039 소프트웨어공학 12

13 화이트박스테스트 화이트박스테스트순서 1) 논리흐름도에의한표현 2) 테스트케이스생성 논리흐름도 모듈내의제어흐름을간선으로표시한그래프 세그멘트 ---> 정점 제어흐름 ---> 간선 세그멘트의발견 최은만, CSE 4039 소프트웨어공학 13

14 점수의평균을구하는모듈 procedure FindMean(var Mean: real; var ScoreFile: file of real); {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.} var Score, SumOfScores, NumberOfScores: real; if Score > 0.0 then begin SumOfScores := SumOfScores + Score; NumberOfScore := NumberOfScore end; end; begin {Initialize SumOfScores and NumberOfScores to zero} SumOfScores := 0.0; NumberOfScores := 0.0; {Read in and sum the scores and count the number of scores} while not eof(scorefile) do begin read(scorefile, Score); {Compute the mean and print the results.} if NumberOfScores >0.0then begin Mean := SumOfScores/NumberOfScores; writeln('the mean score is ', Mean) end else writeln('no scores were entered.') end; 최은만, CSE 4039 소프트웨어공학 14

15 N-S 도표 SumOfScore <- 0.0 NumberOfScores < Mean <- 0.0 read a Score while there are still Scores to be read in do 2 T Score > 0.0? 3 F SumOfScores<-SumOfScores+Score Score 4 5 NumberOfScore<-NumberOfScores+1 read a Score 6 T 7 NumberOfScores > 0.0 F Mean<-SumOfScores/ NumberOfScores write "No scores 8 were entered." write"themeanis", 9 Mean 최은만, CSE 4039 소프트웨어공학 15

16 논리흐름도 최은만, CSE 4039 소프트웨어공학 16

17 테스트케이스 검증기준에따라논리흐름도의경로를적어도한번씩방문하도록테스트케이스를추출 < 예 > 테스트케이스 score=89.0 <eof> score=53.41, 경로 a, b, d, h, c, i a, c a, b, d, h, b, e, h, c, j 최은만, CSE 4039 소프트웨어공학 17

18 화이트박스의실행 모듈이름 : 모듈번호 : 저작자 : 테스트담당자 : 선택 / 루프가능결과 skip while not of once >1 if Score > 0 T F if NumberOf T Score>0.0 F 케이스 # 값 예상되는결과 실행결과 <eof> Mean= <eof> 'No scores were entered' <eof> Mean= 최은만, CSE 4039 소프트웨어공학 18

19 테스트기준 (Test Coverage) Random Test < 예 > Ax^2 + Bx + C = 0 A B C 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; 4 5 Test path: 1, 2, 3, 4, 5 최은만, CSE 4039 소프트웨어공학 19

20 테스트기준 Branch Test 1, 2, 3, 4, 5 1, 3, 5 Path Test 1, 2, 3, 4, 5 1, 3, 5 1, 2, 3, 5 1, 3, 4, 5 Condition 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) 최은만, CSE 4039 소프트웨어공학 20

21 사례 : 문장검증기준 문장검증기준 선택검증기준 경로검증기준 조건검증기준 if (x > 1 or y < 10) 최은만, CSE 4039 소프트웨어공학 21

22 블랙박스테스트 모듈이요구에맞게잘작동하는가에초점 기능테스트 모듈의외형 ( 입력, 출력 ) 모듈의기능위주의검사 동치분해 (equivalence partitioning) 입력조건을여러개의동치클래스로나눔 입력이일정한범위안의값을가져야한다면최소한세개의동치클래스가존재한다. 범위보다작은값, 범위내의값, 범위를넘어서는큰값. < 예 > 현금자동지급기의총지급액범위 :1000원-30만원 원에서 30만원사이의값 ( 정상 ) 원미만의값 ( 비정상 ) 3 30만원보다큰값 ( 비정상 ) 최은만, CSE 4039 소프트웨어공학 22

23 동치분해 - 이산적집합에속하는값이어야정상입력이라면두가지동치클래스가존재한다. 정상입력에속하는값, 그외의값 < 예 > 학적관리시스템에서의재학상태 1 재학상태의정상적인값, 즉재학, 휴학, 졸업, 중퇴 2 그외의비정상적인값 m 식료품점전산화를위한모듈의블랙박스테스트입력 : 식료품이름, 무게 ( 온스 ; 1-48) < 예 > 품명, 1, 2, 3, 오름차순의무게 ( 정상 ): 1, 2, 3 1. 영문자이름 ( 정상 ): AbcDef 2. 영문자가아닌이름 ( 비정상 ): A2X?/ 3. 길이가 2 미만의문자 ( 비정상 ): A 4. 2 이상 15 이하의문자 ( 정상 ): AbcDef 5. 길이가 15 보다큰문자열 ( 비정상 ): abcdefghijklmnopqr 6. 1 보다작은값 ( 비정상 ): 과 48 사이의값 ( 정상 ): 보다큰값 ( 비정상 ): 정수 ( 정상 ): 실수 ( 비정상 ): 5.3 또는 7 1/2 11. 숫자 ( 정상 ): 숫자아님 ( 비정상 ): 5%,, 14. 오름차순이아닌무게 ( 비정상 ): 2, 1, 무게가입력되지않음 ( 비정상 ) 16. 한개이상다섯개까지의무게 ( 정상 ): 1, 2, 다섯개이상의무게값 ( 비정상 ): 1, 2, 3, 4, 5, 품명이먼저입력 ( 정상 ): AbcDef, 1, 2, 품명이먼저가아님 ( 비정상 ): 1, AbcDef, 2, 하나의쉼표로입력의요소들을분리 ( 정상 ): AbcDef, 1, 2, 쉼표로입력요소를분리하지않음 ( 비정상 ): XYZ 1, 2, 입력이빈칸을포함하지않음 ( 정상 ): AbcDef, 1, 2, 입력이빈칸을포함 ( 비정상 ): A bcdef, 1, 2, 3 최은만, CSE 4039 소프트웨어공학 23

24 Boundary Test 테스트케이스예상되는결과동치클래스 a. Xy, 1 b. AbcDefghijklmno, 1, 2, 3, 4, 48 c. A2x?, 1 d. A, 1 e. abcdefghijklmnop f. Xy, -1, 5 g. Xy, 0 h. Xy, 49 i.xy,2,1,3,4,5 j. Xy k.xy,1,2,3,4,5,6 l.1,xy,2,3,4,5 m.xy,1,2,3,4,5 정상정상비정상비정상비정상비정상비정상비정상비정상비정상비정상비정상비정상 1, 4(LB), 7(LB), 9, 11, 13, 16(LB), 18, 20, 22 1, 4(UB), 7(LB), 7(UB), 9, 11, 13, 16(UB), 18, 20, , 10, 12 7(BB) 8, 7(AB) 최은만, CSE 4039 소프트웨어공학 24

25 통합테스트 (Integration Test) 통합테스트의목적 1) 시스템을구성하는모듈의인터페이스와결합을테스트 2) 시스템전체의기능과성능을테스트 통합순서에따라 1) 동시식 (big-bang) 2) 하향식 (top-down) 3) 상향식 (bottom-up) 4) 연쇄식 (threads) 통합시필요한소프트웨어 테스트하니스 : 부분적인테스트를위하여코드에삽입하는프로그램 --> 추후삭제됨 스텁 (stub): 시험대상모듈이호출하는모듈대신에만들어진모의서브루틴 드라이버 (driver): 시험대상모듈을호출하는모의모듈 최은만, CSE 4039 소프트웨어공학 25

26 동시식통합 (Big Bang) 모든모듈을한꺼번에통합하여테스트 단위테스트에많은시간이필요 시스템의중요부분과부수적인부분을구별하지않음 일정계획에융통성이없음 오류가있을경우어떤모듈이변경되어야하는지파악하기어려움 최은만, CSE 4039 소프트웨어공학 26

27 하향식통합 (Top-Down) 시스템구조도의위에있는모듈부터아래층의모듈로내려오면서통합 점증적통합이므로하드웨어의사용이분산되고오류의원인을찾아내기쉬움 상위층의중요한모듈을먼저시험 ---> 시스템의골격을조기에테스트함 스텁의사용으로시스템의모양을사용자에게조기에보여줄수있음 프로그래머가시스템의작동에대한확신을유지시킬수있음 최은만, CSE 4039 소프트웨어공학 27

28 상향식통합 (Bottom-Up) 최하위모듈을먼저시험 드라이버가필요 오류발견이쉽고하드웨어의사용을분산 하위층의모듈을상위층보다더많이시험 테스트의초기에뼈대가갖추어지지않음 최은만, CSE 4039 소프트웨어공학 28

29 연쇄식통합 (Threads) 최선의통합방법 어느정도의기본기능을수행하는모듈 (thread) 로부터통합 시스템의중요한기능을담당하는모듈부터통합 초기에시스템을골격을보여주고사용자의의견을받아수정가능 최은만, CSE 4039 소프트웨어공학 29

30 사례 : 색인제작시스템통합 최은만, CSE 4039 소프트웨어공학 30

31 기능테스트 (Functional Test) 시스템 Rental-Out Modules 테스트케이스 #: 테스트시행자 일시 : 호출또는리턴되는 입력, 사용자반응 예상되는자료 예상되는출력 테스트결과 모듈이름 구조의변화 Handle Costume Rental 사용자 "Rental ( 없음 ) Rental 메뉴화면 Costume out" 선택 출력 Rental Out 사용자 "Non-fee ( 없음 ) Fee/NoFee 메뉴 Rental" 선택 화면출력 Get No Fee Rental 사용자입력 New Renter 레코드 사용자입력 Info 항목변경 : 자료가프린트 Renter Name: Renter Name <- J. M. Kim J. M. Kim Organization: Organization <- CS Department CS Dept. Campus Address: Campus Address <- WonHeung Hall WonHeung Hall S#: S# < Date Out: 3/27/94 Date Out <- 3/27/94 Expected Date/n: Expected Date/n <- 4/2/94 4/2/94 Puller: M.Lee Puller <- M. Lee Rental Out ( 없음 ) ( 없음 ) 최은만, CSE 4039 소프트웨어공학 31

32 인수테스트 목적 시스템이사용할수있도록모든준비가되어있는지를보이는것 사용할모든준비가되었다는것을확인시켜주는작업 테스트방법은사용자가선택 인수테스트방법의대부분은통합테스트와같음. 다른점은사용자환경에서한다는것 베타테스트 고객의사용환경에서시험 개발자없이사용환경에소프트웨어를설치하여시험 최은만, CSE 4039 소프트웨어공학 32

33 테스트자동화도구 코드분석도구 정적분석도구 코드분석도구 : 원시코드의문법적적합성을자동으로평가하여잘못된문장을표기 구조검사도구 : 원시코드의그래프를생성하여논리흐름을보여주고구조적인결함이있는지체크 데이터분석도구 : 원시코드에정의된데이터구조, 데이터선언, 컴포넌트인터페이스를검사. 잘못된링크나데이터정의의충돌, 잘못된데이터의사용등을발견 순서검사도구 : 이벤트의순서체크. 잘못된순서로코딩되어있다면이벤트를지적 동적분석도구 프로그램이수행되는동안이벤트의상태를파악하기위하여특정한변수나조건의스냅샷 (snapshot) 을생성 최은만, CSE 4039 소프트웨어공학 33

34 테스트케이스생성도구 자료흐름도 원시프로그램을입력받아파싱한후자료흐름도를작성 define-use 관계 찾으려는변수에영향을주는요소들을모아테스트경로를구동시키는입력값들을찾아낸다. 기능테스트 주어진기능을구동시키는모든가능한상태를파악하여이에대한입력을작성 입력도메인분석 원시코드의내부를참조하지않고 입력변수가가질수있는값의도메인분석 랜덤테스트 입력값을무작위로추출 시스템의신뢰성분석에사용 최은만, CSE 4039 소프트웨어공학 34

35 테스트실행도구 캡쳐및리플레이 테스트계획에표시된테스트데이터를자동으로입력하고실행과정에발생하는화면이나인쇄되는결과를캡쳐 예상되는결과와비교 예상되는결과와차이를보일경우테스트프로그래머에게보고 오류를발견하고수정한후고치는작업이바르게되었는지확인하는데유용 자동적으로스텁과드라이버를생성하는도구 자동테스트환경 테스트수행도구들이테스트환경으로통합되어제공 최은만, CSE 4039 소프트웨어공학 35

Microsoft PowerPoint 테스트.ppt

Microsoft PowerPoint 테스트.ppt 소프트웨어공학 () 2005 년가을학기 문양세컴퓨터과학과강원대학교자연과학대학 In this chapter 실제로현장 (real world) 에서테스트에드는노력은총비용의 50% 이상, 총개발기간의 50% 정도에해당한다. 테스트의목적은소프트웨어의기능을시험하는것이아니라, 소프트웨어의오류를찾아내어그품질 (quality) 을향상시키는데있다. We will cover