Chatpter 08 테스트 01 테스트의 이해 02 테스트의 분류 03 정적 테스트 05 소프트웨어 개발 단계에 다른 테스트

Presentation on theme: "Chatpter 08 테스트 01 테스트의 이해 02 테스트의 분류 03 정적 테스트 05 소프트웨어 개발 단계에 다른 테스트"— Presentation transcript:

1 Chatpter 08 테스트 01 테스트의 이해 02 테스트의 분류 03 정적 테스트 05 소프트웨어 개발 단계에 다른 테스트
04 동적 테스트 05 소프트웨어 개발 단계에 다른 테스트 요약 연습문제

2 소프트웨어 테스트 프로세스에 대해 알아본다. 시각에 따른 테스트 기법에 대해 살펴본다. 목적에 따른 테스트 기법에 대해 살펴본다. 프로그램 실행 여부에 따른 테스트 기법에 대해 살펴본다. 개발 단계에 따른 테스트 기법에 대해 살펴본다.

3 Section 01 테스트의 이해

4 1. 테스트와 소프트웨어 테스트 死.後.藥.方.文 사람이 죽은 뒤에 약을 짓는다

5 1-1 소프트웨어 오류로 인한 사고 사례 걸프전 당시 페트리어트 미사일 실패 방사선 치료기 테락-25의 사고
미사일이 1 km를 날아갈 때마다 0.5~1초 정도의 아주 미세한 오차 발생 때문 방사선 치료기 테락-25의 사고 테락-20을 테락-25로 버전 업할 때, 사고가 없던 테락-20만 믿고 테락-25의 전체 코드에 대한 테스트를 생략했기 때문 상업용 우주선 아리안 5호의 공중 폭발 64비트 값을 16비트 정수로 변환하는 과정에서 overflow 자동 폭발 장치 작동 아리안 4호 프로젝트에서 내버려둔 불필요한 dead code를 간과한 결과 SW의 사소한 결함 대형 사고

6 2. 전문가들의 소프트웨어 정의 IEEE Zoha Manna Dahl, Dijkstra, Hoare
테스트는 시스템이 명시된 요구를 잘 만족하는지, 즉 예상된 결과와 실제 결과가 어떤 차이를 보이는지 수동이나 자동으로 검사하고 평가하는 작업 Zoha Manna 테스트는 시스템의 명세까지 완벽하게 옳다고 확신할 수 없고, 테스트 시스템 그 자체가 맞다고 증명할 수 없기 때문에 프로그램을 완전히 테스트할 수 없다. Dahl, Dijkstra, Hoare 테스트는 결함이 있음을 보여줄 뿐, 결함이 없음을 증명할 수는 없다.

7 2-1 소프트웨어 테스트 정의 소프트웨어에 내에 존재하지만 드러나지 않고 숨어 있는 오류를 발견할 목적으로, 개발 과정에서 생성되는 문서나 프로그램에 있는 오류를 여러 기술을 이용해 검출하는 작업 오류를 찾아내 정상적으로 실행될 수 있도록 하는 정도이지, 소프트웨어에 오류가 없음을 확인시켜주지는 못한다. 테스트는 오류를 찾고 올바르게 수정하여 프로그램을 작동시킬 수는 있지만, 그 프로그램이 완전하고 정확하다고 증명할 수는 없다. But!

8 2-2 소프트웨어 테스트의 목표 작은 의미 큰 의미 원시 코드 속에 남아 있는 오류를 발견하는 것
결함이 생기지 않도록 예방하는 것 큰 의미 개발된 소프트웨어가 고객의 요구를 만족시키는지 확인시켜주는 것 개발자와 고객에게 사용하기에 충분한 소프트웨어임을 보여주는 것 개발된 소프트웨어에 신뢰성을 높여주기 위한 작업

9 2-3 소프트웨어 테스트의 어려움과 특징 테스트 케이스가 적어 효과에 한계가 있다 완벽한 테스트 케이스를 도출하기 어렵다
테스트를 위한 실제 사용 환경을 구축하기 어렵다 작은 실수를 발견하기 어렵다 테스트 중요성에 대한 인식이 부족하다 고객의 요구 사항을 충족시켜야 한다 테스트 단계에서만 수행되는 단순한 활동이 아니라 개발 단계와 함께한다 파레토 원리를 적용할 수 있다 모듈 단위를 점점 확대해나가며 진행한다 완벽한 테스트는 불가능하다 개발자와 다른 별도의 팀에서 수행한다 살충제 패러독스(테스트 내성) 문제 해결을 위해 테스트 케이스 업데이트가 필요하다

10 2-4 테스트에서 결함관련 용어 오류error 결함defect, bug, fault
소프트웨어 개발자에 의해 만들어지는 실수로 결함의 원인이 된다. 결함defect, bug, fault 오류에 의해 프로그램이 완전치 못한 것으로, 고장의 원인이 된다. 고장, 실패failure, 문제problem, 장애 시스템이 요구 사항대로 작동하지 않는 것을 말한다.

11 3. 테스트 절차

12 3-1 테스트 계획 테스트 목표 정의 테스트 대상 및 범위 결정 테스트 계획서 작성 및 검토
테스트 항목 중에서 어떤 항목을 중점적으로 테스트할 것인지 명확히 나타낸다. 테스트 대상 및 범위 결정 테스트 계획서 작성 및 검토 테스트의 목적, 담당 인원, 테스트 전략과 접근 방법 수립, 필요한 자원 및 자원 확보 일정, 실시할 테스트의 종류, 적용할 테스트 기법, 일정 등에 관한 정보를 기록

13 3-2 테스트 케이스 설계 테스트 케이스 설계 기법 정의 테스트 케이스 도출 원시 데이터 작성
테스트할 프로젝트 문제의 성격을 파악하고 이 문제에 적합한 테스트 기법을 선정 테스트 케이스 도출 원시 데이터 작성

14 3-3 테스트 실행 및 측정 테스트 환경 구축 테스트 실행 및 측정
테스트 계획서에 정의된 환경 및 자원을 설정하여 테스트를 실행할 준비를 한다. 테스트 실행 및 측정

15 3-4 테스트 결과 분석 테스트 결과 분석 보고서 작성
테스트 활동을 통해 얻어진 결과 값과 테스트 계획 단계에서 목표한 값을 비교하여 예정된 테스트 품질 목표가 달성되었는지를 비교·분석 보고서 작성 테스트를 수행한 결과와 테스트를 수행하는 데 사용된 방법 등을 기술 결과에 따른 평가와 권고 사항도 기술

16 3-5 오류 추적 및 수정 오류 수정 계획 오류 수정 수정된 내용 보고
테스트 결과 보고서를 기반으로 오류가 발생된 위치를 찾아내고, 오류 수정 우선순위를 결정하여 오류 제거 계획을 세운다. 오류 수정 수정된 내용 보고

17 Section 02 테스트의 분류

18 [사용자가 원하는 실제 문제] 1부터 10까지 곱셈 프로그램이었다면
1. 시각에 따른 테스트(1) 확인 테스트(verification rest) 1부터 10까지 덧셈의 결과가 정확한지만 테스트, 결과가 55나오면 확인 테스트 합격! but! 확인 테스트로 체크 안됨 각 단계에서 개발자의 시각으로 테스트 설계도 대로 만들었는지 테스트 이전 단계에서 생성된 산출물이 현 단계의 산출물에 정확히 반영되었는지 테스트 [문제] 1부터 10까지 덧셈 프로그램 [사용자가 원하는 실제 문제] 1부터 10까지 곱셈 프로그램이었다면

19 소프트웨어가 사용자의 목적에 맞게 구현되었지 확인 가능
1. 시각에 따른 테스트(2) 확인 테스트의 문제점 사용자의 요구가 맞는지 틀리는지는 체크를 안 해보고, 오직 계산 과정이 맞는지 만 검증 검증 테스트(validation test) 1부터 10까지 곱셈을 했는지 테스트, 결과는 덧셈을 했으므로 검증 테스트 불합격! 사용자의 요구 사항대로 만들었는지를 테스트 사용자가 원하는 것을 만들었는지 사용자의 시각에서 테스트 완성된 제품이 사용자의 요구 사항을 모두 충족하는지 소프트웨어가 사용자의 목적에 맞게 구현되었지 확인 가능

20 2. 사용 목적에 따른 테스트 - 운영 목적 적합성 테스트
소프트웨어가 시스템의 운영 목적에 적합한지를 테스트 테스트 설명 성능 사용자의 요구 사항 중 성능과 관련된 요구 사항을 얼마나 준수하는지 테스트 예상된 부하에 대한 실행시간, 응답 시간, 처리 능력, 자원 사용량 등을 테스트 신뢰성 4장에서 설명 강건 비정상 상태(예상치 못한 입력, 예외적인 입력, 평상시보다 몇 배 많은 입력 데이터)에서도 소프트웨어가 올바르게 동작하는지 테스트 스트레스 평소보다 많은 비정상적인 값, 양, 빈도, 부피 등으로 부하를 발생시켜 부하가 최고치인 상황에서 시스템의 반응을 살피고 이때 발생하는 오류를 찾는 것 부하 소프트웨어가 과부하인 상태를 체크 보안 부당하고 불법적인 침입을 시도하여, 시스템을 보호하기 위해 구축된 보안 시스템이 불법적인 침투를 잘 막아내는지 테스트 사용성 안정성 며칠 동안 부하를 주면서 시스템이 안정적으로 돌아가는지를 테스트

21 2. 사용 목적에 따른 테스트 – 수정 용이성 테스트 상호운용성 테스트 소프트웨어 수정이 얼마나 쉬운지 테스트 테스트 설명
사용자의 요구 사항을 만족할 만큼 잘 수행하고 있는지를 얼마나 쉽고, 효율적이고, 철저하게 테스트할 수 있는가를 테스트 유지보수성 수정으로 인해 오류를 발생시키지 않고 변경시킬 수 있는지를 테스트 상호운용성 테스트 양립성compatibility, 일치성conformance, 이식성portability, 재사용성reusability 등을 체크

22 2. 사용 목적에 따른 테스트 – 운영지원 용이성 테스트
문서화documentation, 복원 가능성recovery, restart 등을 체크 테스트 설명 복원 가능성 소프트웨어를 고장 나게 해놓고(문제를 발생시켜놓고) 소프트웨어 복구가 잘 되는지(소프트웨어의 복구 능력) 확인해보는 테스트 회복이 소프트웨어에서 자동으로 이루어진다면: 재초기화가 제대로 수행되는지, 데이터는 완전하게 복구되었는지, 재시작이 정상적으로 이루어졌는지 등과 같은 소프트웨어 회복의 완벽성을 평가 만약 기술자에 의해 소프트웨어가 복구된다면: 고장 수리에 소요되는 평균 시간이 허용 범위 한계치 내인지 등을 테스트

23 3. 프로그램 실행 여부에 따른 테스트(1) 정적 테스트 프로그램을 실행하지 않고 코드를 검토하며 오류를 찾는 방법

24 3. 프로그램 실행 여부에 따른 테스트(2) 동적 테스트 프로그램을 실행하면서 오류를 찾는 방법

25 Section 03 정적 테스트

26 1. 정적 테스트 정적 테스트(static test)
프로그램 코드를 실행하지 않고 여러 참여자가 모여 소프트웨어 개발 중에 생성되는 모든 명세나 코드를 검토해서 실패(failures)보다는 결함(defects)을 찾아내는 방법

27 2. 비공식/공식 검토 비공식 검토informal technical review
산출물(문서, 프로그램)을 동료와 함께 책상에서 검사. 제품을 검토할 목적으로 하는 간단한 만남 개별 검토, 동료 검토 공식 검토formal technical review 동료와 전문가들이 수행. 결함을 찾기 위해 정의된 절차에 따라 적절히 계획되고 통제된다. 검토회의walk-through와 소프트웨어 검사software inspection

28 2-1 공식 검토 공식 검토 내용 공식 검토 수행 절차 • 원시 코드상에 존재하는 오류 검토
• 소프트웨어가 사용자의 요구를 충분히 반영했는지 검토 • 소프트웨어가 미리 정의된 표준을 지키는지 검토 • 소프트웨어 개발 방식이 일관적인지 검토 • 소프트웨어 공식 검토 수행 절차

29 3. 정적 테스트(1) 개별 검토self review 동료 검토peer review
체크리스트를 가지고 본인이 개발한 코드와 산출물 등을 검토 본인 스스로 검토 가장 간단한 방법, 상대적으로 객관성이 떨어짐 동료 검토peer review 동료에게 원시 코드나 여러 가지 산출물에 대한 검토를 의뢰하여 오류를 찾는 방법 정해진 형식도 없고 별도의 격식을 차린 회의를 수행할 필요가 없어 비공식 검토

30 3. 정적 테스트(2) 검토 회의work-through 검토회의 준비 및 주의 사항
개발자가 소집한 전문가들에 의해 개발자의 작업을 검토 3~5명 정도의 전문가(프로젝트 팀장, 다른 개발자, 품질 보증단장)들이 절차에 따라 평가 설계 문서들이 고객의 요구 사항을 정확히 명시하고 있는지 여부, 작업 진척 상황 등 확인 검토회의 준비 및 주의 사항 • 검토회의를 통해 검토 받고자 하는 개발자는 회의 자료(검토 받을 문서 또는 원시 코드) 를 준비하고 회의 일정을 계획한다. • 검토회의의 결과를 인사 평가 자료로 사용해서는 안 된다. • 회의 자료는 회의가 있기 4~6일 전에 전달되어 미리 살펴보고 올 수 있도록 한다. • 검토회의는 문제점을 찾는 데 주안점을 두고, 그 문제의 해결은 검토회의 이후로 미룬다. • 검토회의 때 발견되고 작성된 오류 리스트는 회의가 끝난 후 개발자에게 전달한다. • 검토회의 시간은 너무 길지 않아야 한다. 일반적으로 1~2시간 이내가 좋다.

31 3. 정적 테스트(3) 소프트웨어 검사software inspection 소프트웨어 검사 절차
검토회의: 문제점을 찾는 데 초점을 두고, 검토회의 후 개발자가 해당 문제를 수정 소프트웨어 검사: 문제점 수정 지침까지도 제시 및 수정을 잘하고 있는지 추후에 조사 원시 코드뿐 아니라 각 단계 산출물의 문서 등을 포함하여 분석하고 품질을 평가 소프트웨어 품질 보증 기법으로 유용 공식 검토에 속함 소프트웨어 검사 절차

32 3. 정적 테스트(4) 소프트웨어 검사 시 지켜야 할 원칙 • 검사 회의는 2시간 이내로 하는 것이 적당하다.
• 검사 회의에 참가하는 총 인원은 5명 내외가 적당하다. • 검토자가 사전에 읽어보고 올 수 있도록 최소한 2일 전에는 자료를 전달한다. • 주제를 벗어나는 개별적인 질문은 삼가도록 한다. • 발견된 오류에 대해서는 반드시 문서화하여 기록으로 남긴다. • 검사 회의 목적은 오류를 발견하는 것이다. 따라서 오류 수정은 하지 않는다. • 검사 회의가 끝나면 문서를 정리하여 관련된 사람들에게 전달한다.

33 3. 정적 테스트(5) 설계와 구현 시 소프트웨어 검사

34 Section 04 동적 테스트

35 1. 명세 기반 테스트 명세 기반 테스트(블랙박스 테스트)
입력 값에 대한 예상출력 값을 정해놓고 그대로 결과가 나오는지를 체크 프로그램 내부의 구조나 알고리즘을 보지 않고, 요구 분석 명세서나 설계 사양서에서 테스트 케이스를 추출하여 테스트 기능을 어떻게 수행하는가 보다는 사용자가 원하는 기능을 수행하는가 테스트

36 1-1 동적 테스트 동적 테스트dynamic test 정보를 얻는 문서 종류에 따른 분류
테스트 데이터를 이용해 실제 프로그램을 실행함으로써 오류를 찾는다. 정보를 얻는 문서 종류에 따른 분류 명세 기반 테스트 구현 기반 테스트

37 1-2 신택스 기법 신택스syntax 기법 문법에 기반을 둔 테스트
문법을 정해놓고 적합/부적합 입력 값에 따른 예상 결과가 제대로 나오는지 테스트

38 1-3 동등 분할 기법 동등 분할equivalence partitioning기법
각 영역에 해당하는 입력 값을 넣고 예상되는 출력 값이 나오는지 실제 값과 비교 (즉) 입력 값에 대한 예상 결과 값을 미리 정해 놓고, 각 영역에서 임의 값을 하나 정해 입 력 값으로 사용하여 실제 결과가 예상 값과 같은지 확인 장점: 단순하고 이해하기 쉬우며 사용자가 작성 가능

39 1-4 경계 값 분석 기법 경계 값 분석(boundary value analysis)기법
경계에 있는 값을 테스트 데이터로 생성하여 테스트하는 방법 (즉) 경계 값과 경계 이전 값, 경계 이후 값을 가지고 테스트

40 1-5 원인-결과 그래프기법(1) 원인-결과 그래프(cause-effect graph)기법
동등 분할/경계 값 분석 기법의 단점: 입력 환경의 복합성을 완전하게 고려하지 못함 단점 극복 원인-결과 그래프(cause-effect graph)기법 원인, 결과 찾기 원인-결과 그래프 작성 그래프에 제한 조건 표시 의사 결정 테이블로 변환

41 1-5 원인-결과 그래프기법(2) ① 프로그램을 적합한 크기로 분할한다 ② 원인과 결과를 찾는다
규모가 큰 프로그램은 원인-결과 그래프를 작성할 만한 크기로 분할한다. ② 원인과 결과를 찾는다 명세서에서 원인과 결과를 찾아 일련번호와 같은 식별자를 각각 부여한다. 여기서 원인은 하나의 입력 조건이고, 결과는 출력 조건이다. ③ 원인-결과 그래프를 작성한다 프로그램 명세가 의미하는 내용을 분석하여, 이에 알맞은 원인과 결과를 연결하는 논리 그래프를 작성한다.

42 1-5 원인-결과 그래프기법(3) ④ 그래프에 제한 조건을 표시한다

43 1-5 원인-결과 그래프기법(4) ⑤ 의사결정 테이블로 변환한다 1 : 90점 이상(T), 리포트 제출(T) → A1
2 : 90점 이상(T), 리포트 미제출(F) → A0 3 : 80점 이상(T), 리포트 제출(T) → B1 4 : 80점 이상(T), 리포트 미제출(F) → B0 5 : 70점 이상(T), 리포트 제출(T) → C1 6 : 70점 이상(T), 리포트 미제출(F) → C0 7 : 70점 미만(T), 리포트 제출(T) → D 8 : 70점 미만(F), 리포트 미제출(F) → F

44 1-5 원인-결과 그래프기법(5) 성적 처리에 대한 의사결정 테이블

45 1-5 원인-결과 그래프기법(6) ⑥ 테스트 케이스를 작성한다 작성된 의사결정 테이블을 기반으로 테스트 케이스를 도출한다.
(예) 테스트 케이스3번째의 테스트 데이터(총점 86점, 리포트 제출)를 생성했다면 결과 값 이 B1가 되어야 한다

46 1-5 원인-결과 그래프기법(예제) [문제] [풀이] ① 원인과 결과를 찾는다
[문제] [풀이] ① 원인과 결과를 찾는다 • 첫 번째 열이 P 또는 S로 시작하고, 두 번째 열이 #이면 ‘출입 가능’을 출력한다. • 첫 번째 열이 P 또는 S로 시작하지 않으면 ‘출입 금지’를 출력한다. • 첫 번째 열이 P 또는 S로 시작하고, 두 번째 열이 #이 아니면 비‘밀번호 오류’를 출력한다. • P는 교수(Professor), S는 학생(Student)을 의미한다. 원인 결과 원인 1 : 첫 번째 열이 P 원인 2 : 첫 번째 열이 S 원인 3 : 두 번째 열이 # 결과 1 : ‘출입 가능’ 출력 결과 2 : ‘출입 금지’ 출력 결과 3 : ‘비밀번호 오류’ 출력

47 1-5 원인-결과 그래프기법(예제) [풀이] ② 원인-결과 그래프를 작성한다

48 1-5 원인-결과 그래프기법(예제) [풀이] ③ 원인-결과 그래프에 제한 조건을 표시한다

49 1-5 원인-결과 그래프기법(예제) [풀이] ④ 의사결정 테이블로 변환한다

50 2. 구현 기반 테스트(화이트박스 테스트, 코드 기반 테스트)
= 화이트 박스 테스트white box test = 코드 기반 테스트code based test 테스트 데이터 적합성 기준test data adequacy criterion = 테스트 데이터 생성 기준test data generation criterion 테스트에서 프로그램 코드의 가능한 경로를 모두 테스트할 수 없기 때문에 프로그램의 일부 경로만 정해 테스트해야 하는데 어떤 경로를 테스트 대상으로 선정할지 결정할 수 있는 기준

51 2-1 화이트박스 테스트 절차 ① 테스트 데이터 적합성 기준 선정

52 2-2 화이트박스 테스트 방법(1) ② 테스트 데이터 생성test data generation ③ 테스트 실행
명세나 원시 코드를 분석하여 선정된 기준을 만족하는 입력 데이터를 만든다. ③ 테스트 실행 프로그램 실행 실행 결과가 예상된 결과와 같은지 비교 화이트박스 테스트 방법 • 문장 검증 기준statement coverage • 분기 검증 기준branch coverage • 조건 검증 기준condition coverage • 분기/조건 검증 기준branch/condition coverage • 다중 조건 검증 기준multiple condition coverage • 기본 경로 테스트basic path test

53 2-2 화이트박스 테스트 방법(2) • 문장 검증 기준statement coverage
방법 별로 복잡도와 소요 시간이 다르므로 테스트의 목적과 조건에 맞는 방법을 선택 • 문장 검증 기준statement coverage • 분기 검증 기준branch coverage • 조건 검증 기준condition coverage • 분기/조건 검증 기준branch/condition coverage • 다중 조건 검증 기준multiple condition coverage • 기본 경로 테스트basic path test

54 1) 문장 검증 기준(1) 문장 검증 기준statement coverage ① 원시 코드 제어 흐름 그래프
프로그램 내의 모든 문장이 최소한 한 번은 실행될 수 있는 테스트 데이터를 갖는 테스트 케이스를 선정 ① 원시 코드 제어 흐름 그래프

55 1) 문장 검증 기준(2) ② 가능한 모든 경로 구함 프로그램 내의 모든 문장이 최소한 한 번은 실행될 수 있는 테스트 데이터를 갖는 테스트 케이스를 선정

56 1) 문장 검증 기준(3) ③ 모든 경로 중 문장 검증 기준을 만족하는 경로 선택
④ 선택한 경로에 해당하는 테스트 데이터를 가지고 실행

57 1) 문장 검증 기준 문제점(4) ① 첫 번째 조건문에서의 문제 ② 두 번째 조건문에서의 문제
원래는 or인데 실수로 and로 코딩한 경우: 검증 기준 방법으로는 오류를 발견하지 못함 and인 경우, or인 경우 모두 (나) 문장을 지나가기 때문 ② 두 번째 조건문에서의 문제 Z>1 식을 Z>0로 잘못 코딩해도 오류를 발견하지 못함 or의 특성이 둘 중 하나만 만족하면 다른 조건식은 결과에 영향을 주지 않기 때문 and인 경우: 입력 값(X=2, Y=0, Z=3), 출력 값(Z=2.5) or인 경우: 입력 값(X=2, Y=0, Z=3), 출력 값(Z=2.5) 분기 검증 기준 해결 방법? 조건문에 대해 T와 F가 적어도 한 번씩 수행할 수 있는 testcse 선정

58 2) 분기 검증 기준(1) 분기 검증 기준(branch coverage), 결정 검증 기준(decision coverage)
조건문에 대해 T, F가 최소한 한 번은 실행되는 입력 데이터를 테스트 케이스로 사용 분기 시점 또는 합류 위치에서 조건과 관련된 오류를 발견할 가능성이 높다. ① 원시 코드 제어 흐름 그래프 ② 가능한 모든 경로 구함

59 2) 분기 검증 기준(2) 모든 경로 중 분기 검증 기준을 만족하는 경로 선택
네 개의 경로 중 하나만으로는 분기 검증 기준을 만족시키지 못함 방법: 두 개의 경로를 묶어서 분기 검증 기준을 만족시킬 수 있는 경우를 찾는다. ( 1 , 2 ), ( 1 , 3 ), ( 1 , 4 ), ( 2 , 3 ), ( 2 , 4 ), ( 3 , 4 ) ( 1 , 4 ) 또는 ( 2 , 3 )

60 2) 분기 검증 기준(3) 경로 1, 4: Z>1를 Z<1로 코딩 실수 해도 그 오류를 발견 못함
이유: 개별 조건식이 or로 연결되어 있어 둘 중 하나만 만족하면 두 번째 식이 무엇이든 관 계없이 조건문의 결과 값에 영향을 주지 않기 때문 조건 검증 기준 해결방법? 조건문 내의 개별 조건식에 대하여 각각 T와 F인 경우를 최소한 한 번씩 수행

61 IF(score>=90 and report>=90) THEN printf(“A”)
3) 조건 검증 기준(1) 조건문만 고려한 ‘분기 검증 기준’의 문제(1) 두 개별 조건식이 T일 때만 조건문이 T이고, 나머지는 두 조건식과 관계없이 모두 F 이유: 두 개별 조건식이 and로 연결되어 있음 개별 조건식이 (T, T)를 제외하고는 나머지 (T, F), (F, T), (F, F)는 모두 거짓이 되기 때문 IF(score>=90 and report>=90) THEN printf(“A”)

62 IF(score>=90 and report>=90) THEN printf(“A”)
3) 조건 검증 기준(2) 조건문만 고려한 ‘분기 검증 기준’의 문제(2) 개별 조건식 A(score>=90)가 T이고, B(report >=90)가 F인 경우 개별 조건식 A: T에서 F로 바뀜 (F, T)에서 개별 조건식 B: T에서 F로 바뀜 모두 오류 발견 못함 (F, F)에서 개별 조건식 둘 중 하나가 T 로 바뀜 이유: and의 특성이 하나라도 F이면 전체 조건식이 항상 F이기 때문 IF(score>=90 and report>=90) THEN printf(“A”) 해결 방법? 조건 검증 기준

63 3) 조건 검증 기준(3) 조건 검증 기준 조건 검증 기준의 테스트 케이스(4가지)
두 개의 개별 조건식이 존재할 때 개별 조건식의 T와 F를 최소한 한 번은 테스트할 수 있도록 테스트 케이스 선정 분기 검증 기준에서 발견하지 못한 오류(개별 조건식에 존재하는 오류)를 발견할 수 있는 더 강력한 테스트 조건 검증 기준의 테스트 케이스(4가지) (가)의 개별 조건식을 만족하는 테스트 케이스 (가) : (X>1) = T and (Y=0) = T (가) : (X>1) = T and (Y=0) = F (가) : (X>1) = F and (Y=0) = T (가) : (X>1) = F and (Y=0) = F (T, T), (F, F) (T, F), (F, T)

64 3) 조건 검증 기준(4) 조건 검증 기준의 테스트 케이스(4가지) (다)의 개별 조건식을 만족하는 테스트 케이스
(다) : (X=2) = T or (Z>1) = T (다) : (X=2) = T or (Z>1) = F (다) : (X=2) = F or (Z>1) = T (다) : (X=2) = F or (Z>1) = F (T, T), (F, F) (T, F), (F, T)

65 3) 조건 검증 기준(5)

66 4) 분기/조건 검증 기준(1) 분기/조건 검증 기준branch/condition coverage
개별 조건식을 모두 만족하면서 전체 조건식도 만족하는 테스트 케이스

67 4) 분기/조건 검증 기준(2) 첫 번째 조건문에서 문제점 ∴ (가)의 개별 조건식 (Y=0)에서 오류 발생 시 발견 못함
(X>1)가 F이면 (Y=0)의 결과와 관계없이 조건문이 F (Z=Z/X)문장을 수행 안 함 ∴ (가)의 개별 조건식 (Y=0)에서 오류 발생 시 발견 못함 ∵ 두 개의 개별식이 and로 연결 ∴ 개별 조건식 하나만 F이면 조건문은 무조건 F 두 번째 조건문에서 문제점 (X=2)가 T이면 (Z>1)와 관계없이 문장(Z=Z+1)을 반드시 수행 ∵ 두 개의 개별식이 or로 연결되었기 때문 ∴ (다)의 개별 조건식(Z>1)에서 오류가 발생해도 이를 발견 못함 마스크(mask) 어떤 개별 조건식이 다른 개별 조건식의 결과와 상관없이 이미 결정되어지는 것

68 5) 다중 조건 검증 기준(1) and로 연결된 개별 조건식에서의 마스크 문제 해결 방법
[문제] 두 식 중 하나가 F인 경우 나머지 식이 F이든 T이든 상관없이 결과가 F라는 것 [해결 방법] 나머지 식에서 T와 F인 경우를 각각 하나씩 추가하여 테스트 케이스 선정 or로 연결된 개별 조건식에서의 마스크 문제 해결 방법 [문제] 두 식 중 하나가 T인 경우 나머지 식은 F이든 T이든 상관없이 결과가 T라는 것 [해결 방법] 나머지 식에서 T인 경우와 F인 경우를 하나씩 추가하여 테스트 케이스 선정 다중 조건 검증 기준multiple condition coverage 마스크 문제까지 해결한 테스트 케이스에 해당하는 테스트 데이터를 생성하는 기준

69 5) 다중 조건 검증 기준(2) 다중 조건 검증 기준의 테스트 케이스

70 6) 기본경로 테스트(1) 기본 경로 테스트basic path test 기본 경로 테스트의 수행 절차
원시 코드의 독립적인 경로가 최소한 한 번은 실행되는 테스트 케이스를 찾아 테스트 목적: 원시코드의 독립적인 경로를 모두 수행하는 것 기본 경로 테스트의 수행 절차

71 6) 기본경로 테스트(2) ① 순서도 작성 문장statement, 조건문if then else, 반복문for과 같은 3가지의 기본 구조로 표현

72 6) 기본경로 테스트(3) ② 흐름 그래프 작성 순서 구조, 선택 구조와 같은 표기법을 사용하여 원시 코드 흐름 그래프를 표현

73 6) 기본경로 테스트(4) ③ 순환 복잡도 계산 순환 복잡도CC: Cyclomatic Complexity
매케이브가 정의한 메트릭으로 원시 코드의 복잡도를 정량적으로 평가하는 방법 원시 코드가 얼마나 복잡한지를 알아보기 위한 것 얼마나 많은 논리적인 경로를 가지고 있는지 계산한 값 순환 복잡도 계산 공식 • CC5R의 수53 • CC5E2N • CC5P [순환 복잡도 공식] • CC5R의 수 • CC5E2N12 • CC5P11 R(Region) : 화살표와 노드로 둘러싸인 구역 외부 구역도 하나의 영역으로 간주함. - E(Edge) : 화살표 수 - N(Node) : 노드 수 - P(Predicate) : 분기 노드 수

74 6) 기본경로 테스트(5) ④ 독립적 경로 정의 ⑤ 테스트 케이스 작성 순환 복잡도가 3이므로 독립적인 경로는 3개
• 경로 1: • 경로 2: • 경로 3: ⑤ 테스트 케이스 작성 테스트 케이스는 3개의 경로에 해당하는 테스트 데이터를 생성하면 된다.

75 Section 05 소프트웨어 개발 단계에 따른 테스트

76 0. 소프트웨어 개발 단계에 따른 테스트 V 모델 소프트웨어 개발 단계의 순서와 짝을 이루어 테스트를 진행해나가는 방법
프로젝트 초기 단계부터 테스트 계획을 세우고, 테스트 설계 과정이 함께 진행

77 1. 단위 테스트(1) 단위 테스트, 모듈 테스트(module test) 단위 테스트 수행 후 발견되는 오류
프로그램의 기본 단위인 모듈을 테스트 모듈 개발 완료한 후 명세서의 내용대로 정확히 구현되었는지를 테스트 (즉) 개별 모듈이 제대로 구현되어 정해진 기능을 정확히 수행하는지를 테스트 단위 테스트 수행 후 발견되는 오류 • 잘못 사용한 자료형 • 잘못된 논리 연산자 • 알고리즘 오류에 따른 원치 않는 결과 • 틀린 계산 수식에 의한 잘못된 결과 • 탈출구가 없는 반복문의 사용

78 1. 단위 테스트(2) 모듈 테스트 시 상위/하위 모듈이 개발 안된 경우 가상의 상위나 하위 모듈을 만들어 사용
테스트 드라이버test driver 상위 모듈의 역할을 하는 가상의 모듈, 테스트할 모듈 호출 필요한 데이터를 인자를 통하여 넘겨주고, 테스트가 완료된 후 그 결과 값을 받는 역할 테스트 스텁stub 하위 모듈의 역할 테스트할 모듈이 호출할 때 인자를 통해 받은 값을 가지고 수행 후 결과를 테스트할 모듈에 넘겨주는 역할

79 2. 통합 테스트(1) 통합 테스트integration test 모듈 통합 방법에 따른 분류 Big-bang 테스트
단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스트 ‘모듈 간의 상호작용이 정상적으로 수행되는가’ 테스트 모듈 사이의 인터페이스 오류는 없는지, 모듈이 올바르게 연계되어 동작하고 있는지 체크 모듈 통합 방법에 따른 분류 한꺼번에 하는 방법: big-bang 테스트 점진적으로 하는 방법: 하향식 기법, 상향식 기법 Big-bang 테스트 단위테스트가 끝난 모듈을 한꺼번에 결합하여 수행하는 방식 소규모 프로그램이나 프로그램의 일부를 대상으로 하는 경우에 적합 오류 발생 시 어떤 모듈에서 오류가 존재하는지, 그 원인이 무엇인지 찾기가 어려움

80 2. 통합 테스트(2) 점진적 모듈 통합 방법 : 하향식top-down 기법
모듈의 계층 구조에서 맨 상위의 모듈부터 시작하여 점차 하위 모듈 방향으로 통합 모듈의 구성 상위 모듈: 시스템 전체의 흐름 관장 하위 모듈: 각 기능을 구현 장점 프로그램 전체에 영향을 줄 수 있는 오류를 일찍 발견하기가 쉽다. 단점 하위 모듈이 임시로 만든 스텁들로 대체되어 결과가 완전하지 않을 수도 있다. 스텁 수가 많으면 스텁을 만드는 데 시간과 노력이 많이 들 수 있다. ∴ 모듈 간의 인터페이스와 시스템의 동작이 정상적으로 잘되고 있는지를 빨리 파악하고자 할 때 유용

81 2. 통합 테스트(3) ①넓이 우선breadth first 방식 ② 깊이 우선 방식depth first 방식
같은 행에서는 옆으로 가며 통합 (A, B)→(A, C)→(A, D)→(A, B, E)→(A, B, F)→(A, C, G) ② 깊이 우선 방식depth first 방식 같은 행에서는 아래로 가며 통합 (A, B)→(A, B, E)→(A, B, F)→(A, C)→(A, C, G)→(A, D)

82 2. 통합 테스트(4) 점진적 모듈 통합 방법 : 상향식bottom-down 기법 가장 말단에 있는 최하위 모듈부터 테스트
상위 모듈의 역할을 하는 테스트 드라이버가 필요 드라이버: 하위 모듈을 순서에 맞게 호출하고, 호출할 때 필요한 매개 변수를 제공하며, 반환 값을 전달하는 역할 순서 우선 가장 말단(레벨 3)에 있는 모듈 E와 F를 모듈 B에 통합하여 테스트 그 다음 모듈 G를 모듈 C에 통합하여 테스트 마지막으로 모듈 B, C, D를 모듈 A에 통합하여 테스트 장점 최하위 모듈들을 개별적으로 병행하여 테스트 하위에 있는 모듈들을 충분히 테스트 가능 정밀한 계산이나 데이터 처리가 요구되는 시스템 같은 경우에 유용 단점 상위 모듈에 오류가 발견되면 그 모듈과 관련된 하위의 모듈을 다시 테스트해야 함

83 3. 시스템 테스트 시스템system 테스트 시스템 전체가 정상적으로 작동하는지를 체크
모듈이 모두 통합된 후 사용자의 요구 사항들을 만족하는지 테스트 사용자에게 개발된 시스템을 전달하기 전에 개발자가 진행하는 마지막 테스트 V & V에서 확인verification에 해당 실제 사용 환경과 유사하게 테스트 환경을 만들어놓고 요구 분석 명세서에 명시한 기능적 요구 사항과 비기능적 요구 사항을 충족하는지 테스트 주로 부하를 주는 상황에서 수행하고, 비기능적 테스트를 중심으로 수행

84 4. 인수 테스트(1) 인수 테스트acceptance test
시스템이 예상대로 동작하는지 확인하고, 요구 사항에 맞는지 확신하기 위해 하는 테스트 시스템을 인수하기 전 요구 분석 명세서에 명시된 대로 모두 충족시키는지를 사용자가 테스트 목적: 사용자 주도로 이루어지며, 오류 발견보다는 제품의 출시 여부를 판단하는 것 인수 테스트 결과: 시스템을 출시할지, 출시 시기를 늦추더라도 보완할지 결정 V & V의 검증(validation)에 해당

85 4. 인수 테스트(2) ① 알파 테스트alpha test ② 베타 테스트beta test 내부 필드 테스트
베타 테스트 개발자 환경에서 사용 오류와 사용상의 문제점 파악 ② 베타 테스트beta test 알파 테스트 후 시장 출시 전 시장의 피드백을 얻기 위한 목적으로 테스트 특정 사용자가 미리 사용 문제점, 오류 발견 개발자에게 알려줌 개발자: 베타 테스트를 통해 보고된 문제점 수정 제품 출시

86 5. 회귀 테스트 확정 테스트confirmation test 회귀 테스트regression test
원시 코드의 결함을 수정한 후 제대로 수정되었는지 확인하는 테스트 회귀 테스트regression test 한 모듈의 수정이 다른 부분에 영향을 끼칠 수도 있다고 생각하여 수정된 모듈뿐 아니라 관련된 모듈까지 문제가 없는지 테스트 ① 수정을 위한 회귀 테스트corrective regression test 모든 테스트를 완료하여 사용자에게 전달하기 전에 테스트 과정에서 미처 발견하지 못한 오류를 찾아 수정한 후 다시 테스트 ② 점진적 회귀 테스트progressive regression test 사용 중에 일부 기능을 추가하여 새로운 버전을 만들고, 이 새 버전을 다시 테스트

87