테 스 트 (Testing) - Software Engineering -

강의 개요 소 개 테스트의 원리 화이트 박스 테스트 블랙 박스 테스트 자료 중심 테스트 통합 테스트 테스트 계획서 COE 306 소프트웨어공학 강의 개요 소 개 테스트의 원리 화이트 박스 테스트 블랙 박스 테스트 자료 중심 테스트 통합 테스트 테스트 계획서 (c) Eun Man Choi, 2001

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

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

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

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

테스트의 유형 Validation Verification 인증(Certification) Are we building the right product? Verification Are we building the product right? 인증(Certification) A written guarantee 정적 분석(Static Analysis) 동적 분석(Dynamic Analysis) 단계별 단위 테스트(unit test) 통합 테스트(integration test) 인수 테스트(acceptance test)

테스트의 유형 시험 방법 기능 시험 성능 시험 스트레스 시험 Benchmark 시험 Field 시험 리그레션 테스트 품질 보증 화이트 박스 테스트 블랙 박스 테스트 기능 시험 성능 시험 스트레스 시험 Benchmark 시험 Field 시험 리그레션 테스트 품질 보증

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

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

오류 패턴 테스트는 시스템의 오류 패턴과 매우 밀접한 관련 모듈에 오류가 너무 많다면 오류 없는 모듈이 될 수 있도록 테스트하여 고치는 것은 한계

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

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

점수의 평균을 구하는 모듈 if Score > 0.0 then begin 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; 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 read(ScoreFile, Score); if Score > 0.0 then begin SumOfScores := SumOfScores + Score; NumberOfScore := NumberOfScore + 1.0 end; {Compute the mean and print the results.} if NumberOfScores > 0.0 then Mean := SumOfScores/NumberOfScores; writeln('The mean score is ', Mean) end else writeln('No scores were entered.')

N-S 도표 SumOfScore <- 0.0 NumberOfScores <- 0.0 ① Mean <- 0.0 read a Score while there are still Scores to be read in do ② T Score > 0.0 ? ③ F SumOfScores<-SumOfScores+Score ④ ⑤ NumberOfScore<-NumberOfScores+1 read a Score ⑥ T ⑦ NumberOfScores > 0.0 F Mean<-SumOfScores/ NumberOfScores write "No scores ⑧ were entered." write "The mean is", ⑨ 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 while not of skip ∨ once ∨ >1 ∨ if Score > 0 T ∨ F ∨ if NumberOf T ∨ ∨ Score>0.0 F ∨ 케이스 # 값 예상되는 결과 실행 결과 1. 89.0<eof> Mean=89.0 2. <eof> 'No scores were entered' 3. 53.41-77.0<eof> Mean=53.41 4.

테스트 기준(Test Coverage) Random Test Statement 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; 2 endif; 3 if (X=4 OR Z>3) then 3 4 Z=Z+1; 4 5 endif; 5 Test path: 1, 2, 3, 4, 5

테스트 기준 Branch Test Path Test Condition Test 1, 2, 3, 5 1, 3, 4, 5 1, 2, 3, 4, 5 1, 3, 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)

사례: 문장 검증 기준 문장검증기준 1-2-3-4-5-6-7 선택검증기준 1-2-3-5-6-1 경로검증 기준 1-2-3-4-5-6-1 1-2-4-5-6-7 1-2-4-5-6-1 조건검증기준 if (x > 1 or y < 10)

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

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

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, 23 2 3 5 6, 10, 12 7(BB) 8, 7(AB) 14 15 17 19 21

자료구조 중심 테스트 자료구조와 관련된 오류를 검출하기 위한 테스트 <예> 연결된 리스트나 배열 1. 배열이나 리스트의 요소가 하나도 없음. 2. 하나의 요소만 가짐. 3. 배열이나 리스트가 가질 수 있는 최대크기 보다 하나 작은 요소를 가짐. 4. 배열이나 리스트가 가질 수 있는 최대 크기의 요소를 가짐. * 같은 방법으로 structure 타입도 테스트

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

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

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

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

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

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

기타 통합 테스트 구조 테스트 기능 테스트 각 모듈의 입력, 출력 매개변수 유틸리티 호출을 포함한 모든 모듈의 호출 시스템 전체를 하나의 블랙박스로 보고 시험 정상적인 입력에 대하여 시험 입력과 출력 예상 결과를 비교

기능 테스트(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#： 415-74-8837 S# <- 415-74-8837 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 (없음) 없음

통합 작업 일정

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

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

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

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