Transcript 확인 (Validation)

Slide 6.1
Object-Oriented and
Classical Software
Engineering
Yoo haeyoung
[email protected]
Dankook.University, Yoo haeyoung, 2005
CHAPTER 6
TESTING
Dankook.University, Yoo haeyoung, 2005
Slide 6.2
학습목표







Quality issues
Non-execution-based testing
Execution-based testing
What should be tested?
Testing versus corrctness proofs
Who should perform execution-based testing?
When testing stops
Dankook.University, Yoo haeyoung, 2005
Slide 6.3
Testing

Slide 6.4
테스팅의 두개의 기본 타입
실행 기반 테스팅(execution-based testing)
비-실행 기반 테스팅(non-execution-based testing)

“V & V”
검증 (Verification)

Determine if the workflow was completed correctly
확인 (Validation)


Determine if the product as awhole satisfies its requirement
Warning
The term “verify” is also used for all non-executionbased testing
Dankook.University, Yoo haeyoung, 2005
6.1 Software Quality
Slide 6.5

품질이란 “우수함(excellence)”을 뜻하는 것이 아님

The extent to which software satisfies its
specifications

모든 소프트웨어 전문가들은 자신들이 작업한 것이
항상 고품질의 소프트웨어인지를 보장해야 하는
책임이 있음
품질은 소프트웨어 품질 보증(SQA: Software Quality
Assurance) 그룹이 후에 어떤 것을 추가하는 것이 아니라
개발자들이 처음부터 구축해야 하는 사항임
Dankook.University, Yoo haeyoung, 2005
6.1.1 소프트웨어 품질 보증 (Software Quality Assurance)
Slide 6.6

SQA 그룹의 멤버들은 개발자들이 해당 작업을
high-quality work로 했는지를 확인해야 함,즉
At the end of each workflow
When the product is complete

SQA 그룹의 역할은 소프트웨어 프로세스의 품질을
확인하고 또 프로덕트의 품질도 확인하는 것
SQA는 소프트웨어 프로세스 자체에도 적용

Example: Standards
Dankook.University, Yoo haeyoung, 2005
6.1.2 관리의 독립성 (Managerial Independence)

Slide 6.7
다음의 두 가지는 독립적으로 관리 되어야 함
개발 팀
SQA 그룹

어느 쪽의 그룹도 다른 쪽을 지배해서는 안됨

소프트웨어 조직은 이때 만족스럽지 못한 두 가지
선택 사항 중 하나를 선택해야 함
클라이언트가 소프트웨어에 있는 결함 때문에 고생을
할지라도 정시에 인도를 할 것인지 , 아니면
인도가 늦어지더라도 개발자가 소프트웨어에 있는
결함들을 수정하든지

개발 조직과 클라이언트 모두에게 이익이 되도록
결정해야함
Dankook.University, Yoo haeyoung, 2005
6.2 Non-Execution-Based Testing

Slide 6.8
기초 원리
문서를 작성하는 사람이 그 문서를 검토하는 책임을 갖는
것은 좋은 아이디어가 아님
그룹 시너지 효과
Dankook.University, Yoo haeyoung, 2005
6.2.1 워크스루 (Walkthroughs)
Slide 6.9

워크스루 팀(walkthrough team)은 4명에서 6명으로 구성

워크스루 팀의 구성
 현재 웍플로우를 담당하는 팀의 대표자
 다음 웍플로우를 담당할 팀의 대표자
 클라이언트의 대표자
 SQA 그룹의 대표자

워크스루에서 사용할 자료들은 참가자들이 구체적으로
준비할 수 있게 사전에 배포되어야 함,즉
 작성해야할 두가지 아이템
검토자가 이해할 수 없는 항목(item)
 부정확하다고 생각되는 항목의 리스트

Dankook.University, Yoo haeyoung, 2005
6.2.2 워크쓰루 관리 (Managing Walkthroughs)
Slide 6.10

워크스루 팀은 SQA 대표자가 의장이 되어야 함

결함들을 수정하는 것은 팀의 임무가 아니고 단지
후의 수정을 위해 문서로 기록
워크스루의 한정된 시간 내에 위원회(즉, 워크스루 팀)가
작성한 수정은 품질면에서 필요한 기법들을 훈련 받은
사람이 작성한 수정보다 떨어질 수 있음
위원회 수정 비용은 너무 높음
결함들로 간주했던 모든 아이템들이 정확하지 않다는 것
워크스루는 2시간 이상 계속하면 안됨

워크스루에서는 결함들을 발견하고 수정할 충분한 시간이 없음
Dankook.University, Yoo haeyoung, 2005
6.2.2 워크스루 관리 (Managing Walkthroughs)(contd)
Slide 6.11

워크스루를 진행하는 방법
참가자-중심(participant- driven)
문서-중심(document-driven)

Verbalization은 결함을 발견할 수 있게 함

워크스루는 고가(성능)평가에 사용되어선 안됨
Dankook.University, Yoo haeyoung, 2005
6.2.3 인스펙션 (Inspections)

인스펙션은 5개의 정형화된 단계로 구성
개요 (Overview)
준비 (Preparation)

발견된 결함들의 유형에 대한 리스트는 빈도에 따라 순위가
부여되기 때문에 큰 도움이 됨
인스펙션 (Inspection)
재작업 (Rework)
사후검토 (Follow-up)
Dankook.University, Yoo haeyoung, 2005
Slide 6.12
6.2.3 인스펙션 (Inspections) (contd)

인스펙션은 4명으로 구성된 팀이 수행
중재자 (Moderator)
현재 워크스루를 수행하고 있는 팀의 멤버
다음 웍플로우를 수행할 팀의 멤버
SQA 그룹의 멤버

중요한 담당 역할은 다음과 같음
중재자 (Moderator)
판독자 (Reader)
기록자 (Recorder)
Dankook.University, Yoo haeyoung, 2005
Slide 6.13
결함 통계 (Fault Statistics)

Slide 6.14
결함들은 엄격히 기록됨
Example:


Major or minor
결함들은 결함 타입으로 기록됨
설계 결함들의 예:


명세 아이템 모두가 어드레스를 가지고 있는 것은 아님
각 인터페이스에 대해 실 인수(actual argument)들과 가인수들이
대응되어 있지 않음
Dankook.University, Yoo haeyoung, 2005
결함 통계 (Fault Statistics) (contd)
Slide 6.15

주어진 웍플로우에 대해 우리는 이전의
프로덕트들의 결함 비율과 현재 결함 비율을 비교

특정 코드 산출물의 인스펙션이 해당 프로덕트의
다른 코드 산출물에서 발견 된 것 보다 많은
결함들이 나타나면
처음부터 재설계 하는 것은 좋은 대안

인스펙션 프로시저의 중요한 컴포넌트는 결함이
발생한 통계 기록
현재의 인스펙션에서 모든 타입의 결함을 발견할 순 없음
Dankook.University, Yoo haeyoung, 2005
인스펙션 통계 (Statistics on Inspections)

Slide 6.16
IBM 인스펙션의 결과
 모든 결함의 82% (1976)
 모든 결함의 70% (1978)
 모든 결함의 93% (1986)

스위칭 시스템
 결함 발견 비용이 90% 감소 (1986)

JPL
 각 2시간 인스펙션에서 평균적으로 4개의 중요 결함과 14개의 사소한
결함들이 노출 (1990)
 인스펙션 당 약 $25,000의 절약을 의미
 발견된 결함들의 개수는 고전적 단계로 보면 지수적으로 감소된 것을
보여 줌 (1992)
Dankook.University, Yoo haeyoung, 2005
인스펙션 통계 (Statistics on Inspections) (contd)

Warning

인스펙션 프로세스의 위험은 성능감정 용으로
사용되면 안됨
“황금 달걀을 낳는 거위를 죽인다”는 속담과 같음
Dankook.University, Yoo haeyoung, 2005
Slide 6.17
6.2.4 인스펙션과 워크스루의 비교

Walkthrough
2단계 비정형 프로세스



준비 (Preparation)
분석 (Analysis)
Inspection
5단계 정형 프로세스





개요 (Overview)
준비 (Preparation)
인스펙션 (Inspection)
재작업 (Rework)
사후검토 (Follow-up)
Dankook.University, Yoo haeyoung, 2005
Slide 6.18
6.2.5 검토의 강점과 약점

(Strengths and Weaknesses of Reviews)

검토(review)는 효과적
Slide 6.19
결함들이 소프트웨어 프로세스 초기에 발견

만약 소프트웨어 프로세스가 부적절 하다면 검토의
효과는 감소
대규모 소프트웨어는 작은 독립된 컴포넌트로 구성되지
않으면 검토하기가 매우 어려움
이전 웍플로우의 문서화가 완전하지 않으면 프로젝트의
현재의 버전을 반영하기 위해 갱신시켜야 하고 또
온라인을 이용할 수 있게 하면 검토 팀들의 효과는 현저히
하락
Dankook.University, Yoo haeyoung, 2005
6.2.6 인스펙션용 척도 (Metrics for Inspections)
Slide 6.20

인스펙션 율(Inspection rate) (e.g., 시간당 검사된
설계페이지들의 수)

결함 밀도 (Fault density) (e.g., 검사된 KLOC(Kilo Line Of
Code: 1000라인)당 결함들의 수 )

결함 발견율 (Fault detection rate) (e.g., 시간당 발견된
결함들의 수)

결함 발견 효과 (Fault detection efficiency) (e.g., 사람 당
발견한 주요-단순 결함들의 수 )

결함 발견율이 50% 증가된 것이 의미하는 것은
 품질이 저하되었는가? 혹은
 인스펙션 프로세스들이 보다 효율적인가?
Dankook.University, Yoo haeyoung, 2005
6.3 실행 기반 테스팅 (Execution-Based Testing)

조직은 테스팅에 소프트웨어 예산의 50%까지 사용
그럼에도 불구하고 인도된 소프트웨어를 신뢰할 수
없다고 말함

Slide 6.21
Dijkstra (1972)
“프로그램 테스팅은 버그의 존재를 보여주는 가장
효과적인 방법일 수 있지만, 그들이 없는 것을
보여주기에는 안타깝게도 부적절하다.”
Dankook.University, Yoo haeyoung, 2005
6.4 테스트 대상은 무엇인가?

Slide 6.22
실행-기반 테스팅(execution- based testing) 정의
“알고 있는 환경에서 선택된 데이터를 대입시켜
프로덕트에 실행해서 나온 결과를 기준으로 프로덕트의
어떤 행위의 성질을 추론하는 과정”

이 정의에는 다음의 세가지 고민스러운 의미가
내포되어 있음
Dankook.University, Yoo haeyoung, 2005
6.4 테스트 대상은 무엇인가? (contd)

Slide 6.23
“추론(Inference)”
사용자 결함 보고서, 소스코드, KLOC 등. 이들로 부터
테스터는 결함이 있다면 어떤 것이 있는지를 추론해야

“알고 있는 환경 (Known environment)”
우리는 결코 우리가 처한 환경을 알지 못할 수도 있음

“선택된 입력들 (Selected inputs)”
때로는 우리가 원하는 입력들을 제공할수가 없다,즉
실시간 시스템인 경우에 입력들이 시스템을 자주 제어할
수 없음
시뮬레이션이 필요
Dankook.University, Yoo haeyoung, 2005
6.4 테스트 대상은 무엇인가? (contd)

Slide 6.24
우리는 정확성(correctness),그리고 다음의
항목들을 테스트할 필요가 있음.필요충분 조건은
아니지만.
유용성 (Utility)
신뢰성 (Reliability)
강건성 (Robustness)
성능 (Performance)
Dankook.University, Yoo haeyoung, 2005
6.4.1 유용성 (Utility)

Slide 6.25
유용성(utility)은 정확한 프로덕트가 해당 명세들이
허용한 조건들 아래서 사용될 때 사용자의
니즈(user`s needs)를 만족시키는 정도를 의미함
Examples:



Ease of use
Useful functions
Cost effectiveness
Dankook.University, Yoo haeyoung, 2005
6.4.2 신뢰성 (Reliability)

Slide 6.26
신뢰성(Reliability)은 프로덕트 실패의 빈도와
위험을 측정하는 것
프로덕트들이 얼마나 자주 실패하는지(mean time
between failures)
해당 실패의 결과들이 얼마나 나쁜 영향 미칠 수
있는지(mean time to repair)
프로덕트가 실패할 때 실패를 복구하는데 평균적으로
얼마나 걸리는지(time (and cost) to repair the results of
a failure)
Dankook.University, Yoo haeyoung, 2005
6.4.3 강건성 (Robustness)

Slide 6.27
A function of
The range of operating conditions
The possibility of unacceptable results with valid input
The effect of invalid input
Dankook.University, Yoo haeyoung, 2005
6.4.4 성능 (Performance)
Slide 6.28

성능(performance)은 테스트해야 할 프로덕트의 또
다른 측면

프로덕트는 응답 시간이나 공간 요구에 대한 제약을
만족시키는 정도를 의미함

실시간 소프트웨어는 시간 제약으로 특징지을 수
있음

만약 시스템이 너무 느려서 데이터를 잃어버린다면
그 데이터들을 되찾을 방법이 없음
Dankook.University, Yoo haeyoung, 2005
명세의 정확성 (Correctness of specifications)

Slide 6.29
정렬에 대한 부정확한 명세:
Figure 6.1

명세들을 충족시키는 메쏘드 trickSort 방법 :
Figure 6.2
Dankook.University, Yoo haeyoung, 2005
명세의 정확성 (Correctness of specifications) (contd)
Slide 6.30

정렬에 대한 부정확한 명세 :
Figure 6.1 (again)

정렬을 위해 고쳐진 명세:
Figure 6.3
Dankook.University, Yoo haeyoung, 2005
6.4.5 정확성 (Correctness)
Slide 6.31

프로덕트가 만약 설계명세를 만족시킨다면 이 프로덕트는
정확(correct)하다고 말함

기술적으로, 정확성은

필요하지 않음 (Not necessary)
 Example: C++ compiler

충분하지 않음 (Not sufficient)
 Example: trickSort

그래서 프로덕트의 정확성은 필요ㆍ충분 조건이 아님
Dankook.University, Yoo haeyoung, 2005
6.5 테스팅 대 정확성 증명
Slide 6.32

Testing versus Correctness Proofs

정확성 증명(correctness proof)은 프로덕트가 해당
명세들을 만족여부를 보여주는 수학적인 기법
Dankook.University, Yoo haeyoung, 2005
6.5.1 정확성 증명의 예

Slide 6.33
정확성을 증명 할 코드 세그먼트(code segment)
Figure 6.4
Dankook.University, Yoo haeyoung, 2005
6.5.1 정확성 증명의 예 (contd)

A flowchart equivalent
of the code segment
Dankook.University, Yoo haeyoung, 2005
Figure 6.5
Slide 6.34
6.5.1 정확성 증명의 예 (contd)

Add
입력명세 (Input specification)
출력명세 (Output specification)
루프 인베리언트 (Loop invariant)
어서션 (Assertions)

(See next slide)
Dankook.University, Yoo haeyoung, 2005
Slide 6.35
6.5.1 정확성 증명의 예 (contd)
Figure 6.6
Dankook.University, Yoo haeyoung, 2005
Slide 6.36
6.5.2 Correctness Proof Mini Case Study
Slide 6.37


비정형 증명(induction)은 6.5.1절에 있음
Dijkstra (1972):
“프로그래머는 프로그램 증명과 프로그램이 잘 어울리게
성장 시킨다 ”

Naur - “텍스트 프로세싱 문제 (text-processing
problem)” (1969)
Dankook.University, Yoo haeyoung, 2005
Naur의 텍스트 프로세싱 문제

Blank 문자들이나 Newline 문자들로 분리된
단어들로 구성된 텍스트가 주어지면 다음 구성
규칙들에 따라 line-by-line 형태로 변환 됨:
line break들은 주어진 텍스트가 blank나 newline을
포함하는 곳에서만 만들어져야 함
각 line은 가능한 한 길게 채워져야 함
maxpos 문자들보다 더 많이 포함되는 line은 없음
Dankook.University, Yoo haeyoung, 2005
Slide 6.38
Episode 1

Naur는 프로시저를 대략 25라인으로 구축

그는 정확성을 비정형적으로 증명했음
Dankook.University, Yoo haeyoung, 2005
Slide 6.39
Episode 2

Slide 6.40
1970 — Computing Reviews의 Leavenworth가
검토
그는 Naur의 프로시저 출력에서 첫 라인의 첫 단어는
첫 단어가 정확히 maxpos 문자들 길지 않으면 blank로
처리된다고 지적
Dankook.University, Yoo haeyoung, 2005
Episode 3
Slide 6.41

1971 — London은 Naur의 프로시저에 있는 세 가지
추가 결함을 찾아 냄

Including:
maxpos 문자보다 더 긴 문자를 만나지 않는다면 그
프로시저는 종료되지 않는다는 사실
Dankook.University, Yoo haeyoung, 2005
Episode 4
Slide 6.42

1975 — Goodenough와 Gerhart가 London이
그들의 공식적인 “증명”에도 불구하고 발견치 못한
3가지 결함을 발견

Including:
마지막 단어가 blank나 newline이 나오지 않는 한
출력되지 않는다는 사실을 포함
Dankook.University, Yoo haeyoung, 2005
6.5.2 Correctness Proof Mini Case Study (contd)
Slide 6.43

Lesson:

프로덕트가 정확하다고 증명되었어도 그것은
철저하게 테스트를 해야 함.
Dankook.University, Yoo haeyoung, 2005
6.5.3 정확성 증명과 소프트웨어 공학

Correctness Proofs and Software Engineering

정확성 증명의 세가지 신화
Slide 6.44
 소프트웨어 엔지니어들은 적절한 수학적 훈련을 받지 못했다는 주장

컴퓨터 과학 주요과목에는 선수과목으로 있거나 전문적으로 정확성
증명기법을 배울 수 있게 기초가 포함되어 있음
 증명은 비용이 너무 많이 들기 때문에 소프트웨어 개발에 사용할 수
없다는 주장

정확성 증명의 경제적인 실용성은 비용-이익 분석(5.2절)을 사용해
프로젝트 단위로 결정
 정확성을 증명하는 것이 너무 어렵다는 주장
많은 프로덕트들은 성공적으로 정확하다고 입증
 이론 증명기(theorem prover)와 같은 많은 툴들이 정확성 증명을 돕는데
사용

Dankook.University, Yoo haeyoung, 2005
정확성 증명의 어려움

Slide 6.45
우리는 어떻게 다음의 theorem prover가 정확하다고 확신할
수 있는가?
Figure 6.7

만약 이론 증명기가 This product is correct라고 출력하면
우리는 그것을 믿을 수 있는가 ?

이론 증명기의 출력물에 어떤 신뢰성이 있는가 ?

결코 우리는 설계 명세나 검증 시스템이 옳다고 확신할 수
없음.
Dankook.University, Yoo haeyoung, 2005
6.5.3 정확성 증명과 소프트웨어 공학(contd)
Slide 6.46

소프트웨어 엔지니어링 툴은 정확성 증명에 중요함

informal proofs 는 프로덕트의 품질을 향상 시킬 수
있음
Use the assert statement
Dankook.University, Yoo haeyoung, 2005
6.6 누가 실행-기반 테스팅을 수행하는가?

프로그래밍은 건설적임(constructive)

테스팅은 파괴적임(destructive)
Slide 6.47
성공적인 테스트는 결함을 발견함

그래서 프로그래머들은 그들 자신의 코드 결과물을
테스트하지 말아야 함
Dankook.University, Yoo haeyoung, 2005
6.6 누가 실행-기반 테스팅을 수행하는가?(contd)
Slide 6.48

Solution:
프로그래머는 informal testing을 함
그 후 SQA 그룹은 체계적인 테스팅을 함
프로그래머는 모듈의 결함을 없앰 (debugs)

모든 테스트 케이스는
미리 계획되어야 함
기대한 output을 포함 하여야 함
그 후 유지 되어야 함
Dankook.University, Yoo haeyoung, 2005
6.7 테스트 종료 시기
Slide 6.49

프로덕트가 많은 해 동안 성공적으로 유지보수 된
후 그 사용성이 결국에 손실되면 전체적으로 다른
프로덕트로 교체

소프트웨어를 폐기할 때 곧 테스팅을 종료시키는
시점
Dankook.University, Yoo haeyoung, 2005