1 / 37

소프트웨어 공학 Lecture #9: 테스팅

소프트웨어 공학 Lecture #9: 테스팅. 안 병 익 biahn99@gmail.com 강의 블로그 Mobilecom.tistory.com. 학습 목표. 테스팅 기초 블랙 박스 테스팅 화이트 박스 테스팅 통합 및 시스템 테스팅 인수 테스팅 테스트 자공화 도구. 테스팅. 테스팅 테스팅에 필요한 시간과 노력 ---> 매우 크다 그러나 테스트는 대부분 초보자나 개인의 역량에 맡기는 경우가 많음 정 의

brook
Télécharger la présentation

소프트웨어 공학 Lecture #9: 테스팅

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 소프트웨어 공학Lecture #9: 테스팅 안 병 익 biahn99@gmail.com 강의 블로그Mobilecom.tistory.com

  2. 학습 목표 테스팅 기초 블랙 박스 테스팅 화이트 박스 테스팅 통합 및 시스템 테스팅 인수 테스팅 테스트 자공화 도구

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

  4. 9.1 테스팅 기초 • 오류 • 프로그램의 실행 결과가 예상한 결과와 다를 때 그 차이 • 소프트웨어가 결함을 갖게 하거나 고장을 일으키게 한 인간의 실수 • 결함(버그) • 요구된 기능을 수행하지 못하게 하는 조건 • 고장 • 작성된 요구와 기능을 제대로 수행할 수 없는 현상 • 결함의 존재가 모두 고장을 발생하는 것은 아님

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

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

  7. 테스트와 개발 단계 (V모형) 테스트 단계와 소프트웨어 개발 단계의 관계

  8. 테스트 케이스 • 테스트 케이스 선택이 무엇보다 중요 • 좋은 테스트 케이스란? • 효과적으로 결함을 드러낼 수 있는 테스트 케이스 • 전수 테스팅(exhaust testing) • 가능한 입력을 모두 테스팅 • 테스트 케이스 • 테스트 데이터와 예상 결과

  9. 9.2 블랙 박스 테스트 • 블랙 박스 테스팅 vs. 화이트 박스 테스팅 • 프로그램의 구조를 고려하느냐 안하느냐에 따라 구별 • 모듈이 요구에 맞게 잘 작동하는가에 초점 • 기능 테스팅(functional testing) • 모듈의 외형(입력, 출력) • 모듈의 기능 위주의 검사 • 전수 테스팅 • 모든 기능에 대하여 전부 테스팅

  10. 동치 클래스 분해 • 전수 테스팅이 불가능하여 입력값의 영역을 동치 클래스로 나누고 대표값을 실행 • 내부 구조를 보지 않고 이상적인 최적의 동치클래스를 결정하기가 어려움 • 예) 절대값을 구하는 모듈 • 양의 정수와 음의 정수가 동치 클래스 • 입력이 일정한 범위 안의 값을 가져야 한다면 최소한 세 개의 동치 클래스가 존재한다. 범위보다 작은 값, 범위 내의 값, 범위를 넘어서는 큰 값 • <예> 현금자동 지급기의 총 지급액 범위:1000원-30만원 ① 1000원에서 30만원 사이의 값(정상) ② 1000원 미만의 값(비정상) ③ 30만원보다 큰 값(비정상)

  11. 동치 분해 • 또 다른 방법 • 동치 클래스와는 다른 동작을 보일만한 특수한 값을 찾아내기 • 예: 0, 비정상적인 입력 • 출력에 대한 통치 클래스 • 예: 흑자, 적자, 본전 • 예: 길이가 N인 스트링 s, 정수 n

  12. 경계값 분석 • 동치 클래스의 경계에 있는 값을 선택 • 경계에 있는 값을 가진 테스트 케이스는 높은 효율을 보임 • 범위 경계선 상의 값과 하나 작은 값, 하나 큰 값 • 변수가 여러 개일 때 • 하나는 고정, 하나는 변동(범위밖, 안, 경계)

  13. 원인 결과 그래프 • 동치 클래스, 경계값 분석의 단점 • 각각의 입력을 별도로 생각 • 원인 결과 그래프 • 입력 조건의 조합을 체계적으로 선택하여 개수를 조절 • 예) 은행 데이터 베이스 • 입금 계정 번호 트랜젝션_금액 • 출금 계정 번호 트랜젝션_금액

  14. 상태 기반 테스팅 • 상태 기반 시스템 • 시스템의 동작과 출력은 제공되는 입력만이 아니라 시스템의 상태에 의하여 좌우됨 • 상태 모델 • 상태를 저장하는 시스템을 모델링 • 상태 공간은 변수의 제곱에 비례

  15. 상태 기반 테스팅 테스트 케이스

  16. 9.3 화이트 박스 테스트 • 모듈 안의 작동을 자세히 관찰하는 시험 • 구조적 시험 • 화이트 박스 테스트 순서 1) 논리 흐름도에 의한 표현 2) 테스트 케이스 생성 • 논리 흐름도 • 모듈 내의 제어흐름을 간선으로 표시한 그래프 • 세그멘트 ---> 정점 • 제어흐름 ---> 간선 • 세그멘트의 발견

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

  18. 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

  19. 논리흐름도

  20. 테스트 케이스 • 검증기준에 따라 논리 흐름도의 경로를 적어도 한번씩 방문하도록 테스트 케이스를 추출 <예> 테스트 케이스 경로 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

  21. 화이트 박스의 실행 모 듈 이 름:_________________모 듈 번 호 :______________ 저 작 자 :_________________ 테스트담당자 : ______________ 선택/루프 가능결과 1 2 3 4 5 6 7 8 • skip ∨ • while not of 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.

  22. 테스트 기준(Test Coverage) • 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; 4 5 Test path: 1, 2, 3, 4, 5

  23. 테스트 기준 • 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)

  24. 사례: 문장 검증 기준 • 문장검증기준 • 1-2-3-4-5-6-7 • 선택검증기준 • 1-2-3-4-5-6-7 • 1-2-3-5-6-1 • 경로검증 기준 • 1-2-3-4-5-6-7 • 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)

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

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

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

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

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

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

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

  32. 기능 테스트(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 (없음) (없음)

  33. 통합 테스트 계획

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

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

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

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

More Related