why programs fail ch5 - andstudy/forge GitHub Wiki

문제점을 재현했다면 다음으로는 그것을 단순화해야 한다.

어떻게?
- 유관/무관한 조건들을 밝혀낸다.
결과물은?
- 문제점에 관련 있는 상황들만을 담은 하나의 테스트 케이스.
델타 디버깅?
- 테스트 케이스를 자동적으로 단순화시키는 디버깅 방법

단순화 개략적 설명 (비행기 사고)
푹발 원인을 알아내기 위해 상황을 변화시켜 가면서 시험 비행
엔진은 유관, 커피머신은 무관 -> 반복...
최종적으로 남은 단순화된 뼈대는 모두 추락의 재현에 유관
단순화의 가치는 필수적인 부분들을 남겼다는 점보다는 무관한 사항들을 제거했다는 점에서 더 크게 나타난다.

문제점 보고를 단순화하는 일반적인 공정은 하나의 간단한 규칙을 따른다.
- 문제점의 모든 상황에 대해, 그것이 문제점 발생에 관련이 있는지 점검한다.
- 만일 문제점 발생과 무과하다면 해당 문제점 보고 또는 테스트 케이스에서 그것을 제거한다.]

이 장의 핵심 질문 :
- 테스트 케이스들을 체계적이고 자동적으로 단순화하려면 어떻게 해야 할까?

사례 (Mozilla Bug #24735, 책 160p)
- 이 복잡한 HTML코드 중에 무엇이 문제를 일으키는 것일까
- 우리가 원하는 건 여전히 실패하면서도 최대한 단순한 HTML 입력.
- 자원 봉사자들로 해결.
단순화된 테스트 케이스의 유용함.
- 의사소통을 쉽게 한다 : 받아 적거나 설명 읽기 쉽고, 쓸데없는걸 말 안해도 됨
- 디버깅을 쉽게 한다 : 스도쿠에서 주변 숫자를 다 알아낸 경우, 경우의 수가 줄어듦
- 중복을 식별한다 : select 때문에 발생한 다른 bug를 솎아냄.

수동 단순화 (목록 5.1, 그림 5.1)
896줄에서 1줄로 줄어들었다. 문제는 의사소통 : 이제는 "를 인쇄하면 폭주함"이라는 간단한 요약문만으로도 문제점을 잘 설명할 수 있다.
디버깅 : Mozilla 프로그래머는 태그의 신쇄를 처리하는 코드에 즉시 집중할 수 있다.
중복 : 인쇄에 관한 다른 문제점들을 검색해서 입력 HTML에 가 포함된 것은 이 문제점의 중복일 가능성이 있다.

자동 단순화
수동 단순화는 반복적이고 지루한 활동 -> 자동화
기본 아이디어
- 어떤 특정한 입력에 대해 Mozilla가 인쇄에 실패하는지를 결정하는 자동 테스트를 설정한다.
- 이전에 언급한 이진 검색 접근방식을 실현하는, HTML 페이지의 일부분에 대해 테스트를 수행하는 하나의 전략을 구현한다.
전략(자동적인 단순화 전략)의 설계
1. 입력의 반을 제거하고 테스트가 실패하는지 본다. 만일 그렇다면 나머지 반을 가지고 같은 과정을 반복
2. 그렇지 않다면 이전 상태로 돌아가서 입력의 다른 반을 제거한다.
3. 두 절반 모두 테스트를 통과한다면 입력을 절반씩 자르는 더 작은 부분씩 잘라내는 방향으로 나아간다.(그림 5.2, 5.3)
최종적으로 입력에서 어떤 문자를 제거해도 문제점이 사라지는(구체적으로 말하면 딱 만 남은) 상태에 이를 것이다.

5.5 단순화 알고리즘
- ppt 참고

사용자 입력에 델타 디버깅 적용
그림 5.2 : 100개 정도의 사용자 상호작용에 대해 델타 디버깅,
82회 테스트 후에 3개로 줄었음
- Alt-p
- 왼쪽 마우스 버튼 다운
- 왼족 마우스 버튼 업
개발 도중에 발생하는 상황뿐만 아니라
입력, 코드 변경, 일정에서 실제 원인을 자동으로 찾도록 이용 가능

자동 단순화 속도를 높이기 위해 사용할 수 있는 방법
- 캐싱을 활용 : 테스트 결과를 캐시에 담아두어 중복 실행 막는다.
- 일찍 중단한다(그림 5.3) : 결과 품질과 소요 시간을 맞바꾼다.
- 구문적 수준 또는 의미론적 수준에서 단순화한다(그림 5.4, 5.5) :
- 어휘적 수준이 아닌 구문적 수준에서 입력을 단순화
- {0, 1, 1.1, 2, 3, 3.1} => {0, 1, 1.1} => {0}
- 상황들을 격리하는 대신 실패를 야기하는 차이들을 격리한다.

⚠️ GitHub.com Fallback ⚠️