소프트웨어 품질과 테스트 E DRE = E + D DRE: Defect Removal Efficiency

Presentation on theme: "소프트웨어 품질과 테스트 E DRE = E + D DRE: Defect Removal Efficiency"— Presentation transcript:

1 소프트웨어 품질과 테스트 E DRE = E + D DRE: Defect Removal Efficiency
E: total error before delivery D: total error after delivery 99.9 s/w eng_y.e.han

2 소프트웨어 테스트 목적 개발한 소프트웨어를 사용자에게 넘겨주기 전에 오류를 찾아 내기 위해서 프로그램을 실행시키는 프로세스이다
- 소프웨어에 내포된 오류를 찾아낸다 - 소프트웨어가 요구사항에 순응하는가를 확인한다 - 소프트웨어 성능이 요구 수준을 만족시키고 있는가를 확인한다 99.9 s/w eng_y.e.han

3 소프트웨어 테스트 담당자 개발자 테스트 전담자 시스템을 잘 알고 있다 대충 테스트 하려고 한다 납기를 맞추려고 노력한다
시스템을 파악해야 한다 철저하게 테스트하려고 한다 품질의 수준을 높이려고 노력한다 99.9 s/w eng_y.e.han

4 테스트 전담자의 조직 옵션 기업/기관 소프트웨어 엔지니어링 그룹 소프트웨어 품질보증 그룹 외부 계약자 테스트 전담자 테스트
99.9 s/w eng_y.e.han

5 전체 테스트 - exhaustive test
Loop < 20x 99.9 s/w eng_y.e.han

6 선택적 테스트 - selective test
Loop < 20x 99.9 s/w eng_y.e.han

7 테스트 원칙 - 1 코드 궁극적으로 테스트는 개발된 소프트웨어가 설계서 고객의 요구사항에 순응하는 가를 확인하는 것이다 요구
명세서 99.9 s/w eng_y.e.han

8 테스트 원칙 - 2 요구 명세서 테스트 계획은 일찍 수립되지만 테스트 케이스 설계와 실제 테스트는 나중에 실시된다 설계서 코드
99.9 s/w eng_y.e.han

9 테스트 원칙 - 3 테스트에서 발견되는 오류의 80%는 전체 모듈의 20%에서 발견된다 80% 모듈 20% 오류 99.9
s/w eng_y.e.han

10 테스트 원칙 - 4 점진적인 테스트가 항상 효과적이다 99.9 s/w eng_y.e.han

11 테스트 원칙 - 5 항상 비 전형적인 운영조건에서 테스트하라 99.9 s/w eng_y.e.han

12 테스트 원칙 - 6 Test와 debugging은 동일한 작업이 아니다 Result symptoms test Debugging
New test data Suspected cause 99.9 s/w eng_y.e.han

13 소프트웨어 테스팅 White-box method Black-box method 방법론 method 전략 strategies
99.9 s/w eng_y.e.han

14 테스트 케이스 설계 - 목적: 오류를 발견하기 위함 - 기준: 완전하게 - 제약: 최소의 노력과 시간으로
Bug는 구석에 숨어 있고, 경계선으로 모인다 - Boris Beizer - - 목적: 오류를 발견하기 위함 - 기준: 완전하게 - 제약: 최소의 노력과 시간으로 99.9 s/w eng_y.e.han

15 White-box test 모든 명령문과 조건이 적어도 한번씩은 수행되는 것을 확인하는 것이 목표이다 99.9
s/w eng_y.e.han

16 경로 테스트 path test 경로: 명령의 실행 순서 99.9 s/w eng_y.e.han

17 기초 경로 테스트: basis path test- 1
2 4 3 5 6 7 우선: cyclomatic complexity를 계산한다 ; V(G) - V(G) = simple decision no. + 1 - V(G) = enclosed area no. + 1 - V(G) = = 4 99.9 s/w eng_y.e.han

18 기초 경로 테스트: basis path test- 2
1 2 4 3 5 6 7 다음: 독립적인 경로를 도출한다 V(G) = 4 이므로 4개의 독립적인 경로가 있음 - 경로1: 1,2,3,6,7,8 - 경로2: 1,2,3,5,7,8 - 경로3: 1,2,4,7,8 - 경로4: 1,2,4,7,2,4,,,7,8 마지막으로 이 경로들을 수행할 테스트 케이스를 도출한다 99.9 s/w eng_y.e.han

19 기초 경로 테스트: basis path test- 3
1 2 4 3 5 6 7 - 프로우 차트는 프로그램 경로를 추적하는데 도움을 준다 - 논리적 테스트는 하나씩 계수하고 복합 테스트는 둘 이상으로 계수한다 - 기초 경로 테스트는 주요 모듈에만 적용되어야 한다 99.9 s/w eng_y.e.han

20 Loop test Simple loop Nested loop Concatenated loop Unstructed loop
99.9 s/w eng_y.e.han

21 Loop test: simple loop Loop를 완전히 생략한다 한 번 loop 통과 두 번 loop 통과
m 번 loop 통과( m < n ) (n - 1), n, (n + 1)번 loop 통과 n: 최대 허용 통과의 수 99.9 s/w eng_y.e.han

22 Black-box test 입력 출력 Black-box - 소프트웨어의 기능요구에 초점을 맞춘다
사항 입력 출력 Black-box 사건 - 소프트웨어의 기능요구에 초점을 맞춘다 - white-box test의 대안이 아니다 99.9 s/w eng_y.e.han

23 Black-box test 적용범위 부정확하고, 누락된 기능 인터페이스 오류 자료구조 내의 오류 성능 오류
초기화 및 종료시의 오류 99.9 s/w eng_y.e.han

24 Black-box test 기법 오류 추적(guess) 기법 의사결정표 기법 원인과 결과 기법 99.9
s/w eng_y.e.han

25 테스트 전략 Unit test 단위 테스트 시스템 테스트 통합 테스트 System test Integration test 확인
Validation test 99.9 s/w eng_y.e.han

26 테스트 전략: 테스트 vs 엔지니어링 산출물 . 시스템 기술서 . 시스템 테스트 . 요구 명세서 . 확인 테스트 . 설계서
. 코드 . 시스템 테스트 . 확인 테스트 . 통합 테스트 . 단위 테스트 99.9 s/w eng_y.e.han

27 단위 테스트: unit test - 인터페이스: interface - 자료구조: local data structure
테스트될 모듈 테스트 결과 테스트 케이스 - 인터페이스: interface - 자료구조: local data structure - 경계조건: boundary condition - 독립경로: independent paths - 오류 취급 경로: error handling paths 99.9 s/w eng_y.e.han

28 단위 테스트 환경 module stub stub 테스트 driver 테스트 케이스 테스트 결과 99.9
s/w eng_y.e.han

29 단위 테스트의 특성 모듈을 개발한 엔지니어가 테스트 한다 black-box test 기법이 항상 사용되고
white-box test 기법도 가끔 사용한다 대부분의 경우에 driver 와 stub가 필요하다 99.9 s/w eng_y.e.han

30 통합 테스트의 유형 하향식 통합 테스트 상향식 통합 테스트 Sandwich 테스트 99.9 s/w eng_y.e.han

31 하향식 통합 테스트 a 최상위 모듈은 stub로 테스트된다 b f g Stub는 한번에 하나씩 교체된다 c d e
새로운 모듈이 통합됨에 따라서 일부 모듈은 재 테스트 된다 99.9 s/w eng_y.e.han

32 상향식 통합 테스트 a b f g driver는 한번에 하나씩 교체된다 c d e 작업 모듈들은 통합된 모듈로 그룹화 된다
cluster 99.9 s/w eng_y.e.han

33 Sandwich 테스트 a 최상위 모듈은 stub로 테스트 된다 b f g c d e 작업 모듈들은 통합된 모듈로 그룹화 된다
cluster 99.9 s/w eng_y.e.han

34 통합 테스트의 특성 보통 개발자가 테스트를 수행한다 특별한 경우에는 테스트 전담자에 의해서 수행된다
보통 black-box 테스트 기법이 사용된다 전체적인 자료구조(global data structure)가 테스트된다 테스트 계획이 항상 수립된다 대부분의 경우에 driver와 stub가 필요하다 외부 및 내부 인터페이스가 테스트된다 99.9 s/w eng_y.e.han

35 확인 테스트: validation test
소프트웨어 요구 명세서가 지침서로 사용된다 소프트웨어 개발자 혹은 테스트 전담자에 의해서 수행된다 가능하면, 최종 운영환경에서 실시되어야 한다 99.9 s/w eng_y.e.han

36 External input or “live” data base
시스템 테스트: system test External input or “live” data base 외부 입력 Target operating system 목표 OS 응용 SW Application software 목표 HW Target hardware 99.9 s/w eng_y.e.han

37 Alpha & Beta 테스트 - Alpha 테스트 - Beta 테스트 고객이 테스트 SW 개발자 현장 고객 현장 SW
개발자가 검토 고객 현장 개발자 현장 99.9 s/w eng_y.e.han

38 debugging “ diagnostic process “ “ 진단과정 “ 99.9 s/w eng_y.e.han

39 Debugging process: 진단과정
테스트 케이스 테스트 결과 테스트 새로운 테스트 케이스 debugging 미확인 원인 correction 확인된 원인 99.9 s/w eng_y.e.han

40 Debugging effort 증상을 진단하고 원인을 파악하는데 필요한 시간 오류를 고치고 회귀 테스트를 하는데 필요한 시간
99.9 s/w eng_y.e.han

41 증상과 원인: sympton & causes
- 증상과 원인은 서로 다른 곳에서 발견될 수 있다 - 증상은 다른 문제가 해결되면 사라질 수 있다 - 원인은 오류가 아닌 것들의 조합으로 발생할 수 있다 - 원인은 시스템이나 컴파일러 오류 때문에 발생할 수 있다 - 원인은 모든 사람이 그럴 것이라고 믿는데 서도 발생할 수 있다 증상 원인 99.9 s/w eng_y.e.han