The Art of Software Testing - 소프트웨어 개발은 주로 최종 프로그램

 

The Art of Software Testing 3판 국내도서 저자 : 글렌포드 마이어스(Glenford J. Myers),톰 뱃지트(Tom Badgett),코리 샌들러(Corey Sandler) / 이상기,신준식역 출판 : 인피니티북스 2013.05.31 상세보기

 

1. 소프트웨어 개발은 주로 최종 프로그램에 대한 정보를 교환하고 다른 형태로 이 정보를 변형하는 프로세스이다. 본질적으로 그것은 개념에서 실체가 있는 방향으로 이동한다. 그런 이유로 소프트웨어 오류의 대부분은 정보를 호환하고 변형하는 과정에서 발생하는 장애, 실수 그리고 간섭에 의한 것이다. 이러한 소프트웨어 개발 사이클의 이런 특성을 7단계로 요약할 수 있는데, 각 단계별 내용을 자세히 설명하고, 이런 형태의 문서화를 다른 시각으로 봤을 경우 보이게 되는 4가지를 작성하시오. 그리고 7단계의 개발주기가 정보교환, 이해, 정보변환 과정을 포함하고 대부분의 소프트웨어 오류가 정보 처리 과정을 통해 발생한다는 전제 하에, 이러한 오류를 예방하고 발견할 수 있는 상호 보완적 접근법 3가지를 작성하시오

1. 소프트웨어 개발 사이클의 특성 7단계를 각 단계별로 자세히 설명

1) 요구사항 : 프로그램 사용자의 요구를 일련의 요구사항으로 변경한다. 이것이 제품의 목표이다.

2) 개발목적 : 가능성과 비용을 평가하고 대립되는 요구사항을 해결하며 우선순위와 균형을 맞추면서 요구사항을 개발 목적으로 변형한다.

3) 외부명세 : 제품을 블랙박스로 보면서 제품의 최종 사용자와 제품의 인터페이스 간 상호작용만 고려해 목적을 정확한 제품 명세로 바꾼다. 이 명세를 외부 명세라 한다.

4) 시스템설계 : 제품이 애플리케이션이 아니라 오퍼레이팅 시스템, 비행관제 시스템, 데이터 베이스 시스템 또는 직원 인사 관리 시스템과 같은 시스템이라면, 다음 과정은 시스템 설계이다. 이 단계는 시스템을 개별 프로그램, 컴포넌트 또는 서브시스템으로 나누고 상호 인터페이스를 정의한다.

5) 프로그램 구조 설계 : 각 모듈의 기능, 계층별 구조, 모듈 간 인터페이스를 명세화하여 프로그램 구조를 설계한다.

6) 모듈 인터페이스 명세 : 각 모듈의 기능과 인터페이스를 정의한 상세 명세를 개발한다.

7) 코드 : 여러번의 세부 단계를 통해 각 모듈의 인터페이스 명세를 소스코드 알고리즘으로 변환한다.

2. 소프트웨어 개발 프로세스 7단계를 다른 시각으로 밨을 경우 보이게 되는 4가지를 작성

1) 요구사항이 프로그램에 필요한 이유를 명시한다.

2) 개발 목적에 프로그램이 무엇을 해야하는지와 그것을 얼마나 잘 해야 하는지 지정한다.

3) 외부 명세에 프로그램이 사용자에게 정확하게 무엇을 하는지 정의 한다.

4) 후속 프로세스와 관련된 문서화에는 프로그램이 어떻게 구성되었는지 점차 상세하게 기술한다.

3. 7단계의 개발 주기가 정보 교환, 이해, 정보변환 과정을 포함하고 대부부분의 소프트웨어 오류가 정보 처리 과정을 통해 발생한다는 전제 하에, 이러한 오류를 예방하고 발견할 수 있는 상호 보완적 접근법 3가지를 작성

1) 많은 오류를 예방하기 위해 개발 과정을 보다 명확하게 한다.

2) 각 개발 프로세스 마지막에 별도의 검증 단계를 만들어 다름 프로세스로 넘어가기 이전에 가능한 많은 오류를 발견한다. 

3) 접근법에서는 서로 다른 테스팅 프로세스를 각 개발 프로세스에 맞춰 배치한다. 다시 말해 각 테스팅 과정을 특정한 변환 단계에 집중 배치하여 특정한 종류의 오류를 발견하는데 집중한다.

1. 소프트웨어 개발 사이클의 특성 7단계를 각 단계별로 자세히 설명합니다. 

1) 요구사항 : 프로그램 사용자의 요구를 일련의 요구 사항으로 변형한다. 이것이 제품의 목표이다.

2) 개발목적 : 가능성과 비용을 평가하고 대립되는 요구사항을 해결하며 우선 순위와 균형을 맞추면서 요구사항을 개발 목적으로 변형한다. 

3) 외부명세 : 제품을 블랙박스로 보면서 제품의 최종 사용자와 제품의 인터페이스 간 상호작용만 고려해 목적을 정확한 제품 명세로 바꾼다. 이 명세를 외부 명세라 한다.

4) 시스템설계 : 제품이 애플리케이션(예, 컴파일러, 급여 프로그램, 워드 프로세서)이 아니라 오퍼레이팅 시스템, 비행 관제 시스템, 데이터 베이스 시스템 또는 직원 인사 관리 시스템과 같은 시스템이라면, 다음 과정은 시스템 설계이다. 이 단계는 시스템을 개별 프로그램, 컴포넌트 또는 서브시스템으로 나누고 상호 인터페이스를 정의한다. 

5) 프로그램 구조 설계 : 각 모듈의 기능, 계층별 구조, 모듈 간 인터페이스를 명세화하여 프로그램 구조를 설계한다. 

6) 모듈 인터페이스 명세 : 각 모듈의 기능과 인터페이스를 정의한 상세 명세를 개발한다. (3점) 7) 코드 : 여러 번의 세부 단계를 통해 각 모듈의 인터페이스 명세를 소스코드 알고리즘으로 변환한다. 

2. 소프트웨어 개발 프로세스 7단계를 다른 시각으로 봤을 경우 보이게 되는 4가지를 작성합니다. 

1) 요구사항이 프로그램에 필요한 이유를 명시한다. 

2) 개발목적에 프로그램이 무엇을 해야 하는 지와 그것을 얼마나 잘 해야 하는지 지정한다.

3) 외부 명세에 프로그램이 사용자에게 정확하게 무엇을 하는지 정의한다. 

4) 후속 프로세스와 관련된 문서화에는 프로그램이 어떻게 구성되었는지 점차 상세하게 기술한다.

3. 7단계의 개발주기가 정보교환, 이해, 정보변환 과정을 포함하고 대부분의 소프트웨어 오류가 정보 처리 과정을 통해 발생한다는 전제 하에, 이러한 오류를 예방하고 발견할 수 있는 상호 보완적 접근법 3가지를 작성합니다.

1) 첫째, 많은 오류를 예방하기 위해 개발과정을 보다 명확하게 한다. 

2) 둘째, 각 개발 프로세스 마지막에 별도의 검증 단계를 만들어 다음 프로세스로 넘어가기 이전에 가능한 많은 오류를 발견한다. 

3) 세 번째, 접근법에서는 서로 다른 테스팅 프로세스를 각 개발 프로세스에 맞춰 배치한다. 다시 말해 각 테스팅 과정을 특정한 변환 단계에 집중 배치하여 특정한 종류의 오류를 발견하는 데 집중한다. 

 

 

---

 

 

 

 2. 디버깅은 프로그램 테스팅에서 필수적인 작업이지만, 프로그래머는 소프트웨어 개발 프로세스 중에서 가장 흥미 없는 부분으로 여긴다. 그 이유 4가지를 작성하시오. 그리고 프로그램 디버깅의 가장 일반적인 방법 중에서 저장된 덤프를 이용한 디버깅이 가장 비효율적인 무차별 접근 방법인 이유 5가지를 작성하고, 귀납적 디버깅의 절차 5단계를 작성하시오. 마지막으로 학습자가 생각하는 디버깅이 가장 흥미 없는 부분임에도 반드시 해야하는 이유 1가지를 작성하시오

1. 프로그래머들이 소프트웨어 개발 프로세스 중에서 디버깅을 가장 흥미 없는 부분으로 여기는 이유 4가지 작성

1) 자존심에 상처를 입는다. 좋든 싫든 디버깅은 프로그래머가 완벽하지 않다는 것을 확인시킨다. 그들의 설계나 코드에 오류를 남기기 때문이다.

2) 의욕을 상실할 수 있다. 소프트웨어 개발 중 디버깅은 정신적으로 가장 힘든 작업이다. 일반적으로 가능한 빨리 문제를 수정해야 하는 조직과 개인도 커다란 압박 속에서 업무를 수행한다.

3) 목적을 잃을 수 있다. 프로그래머가 발견한 오류는 사실상 프로그램 내부의 어떤 구문에서도 발생할 수 있기 때문에 디버깅은 정신적으로 어려운일이다.

4) 스스로 해결해야 한다. 기타 소프트웨어 개발 작업과 비교해 보면 디버깅 단계는 상대적으로 기존 연구나 문헌, 잘 갖추어진 지침서가 거의 없다.

2. 프로그램 디버깅의 가장 일반적인 방법 중에서 저장된 덤프를 이용한 디버깅이 가장 비효율적인 무차별 접근 방법인 이유 5가지 작성

1) 메모리 위치와 소스 프로그램 변수의 관련성을 찾기 어렵다.

2) 적절한 수순의 복잡도를 갖는 프로그램이더라도 메모리 덤프는 대부분 서로 관련 없는 많은 양의 데이터를 생성한다.

3) 오류를 찾기 위해서는 시간 경과에 따라 상태가 변하는 프로그램의 동적 상태를 검토해야 하는데, 메모리 덤프는 그 시점에서 인스턴스의 프로그램 상태를 보여주는 정적인 그림이다.

4) 메모리 덤프가 오류의 정확한 지점에서 생성되는 일은 거의 없기 때문에 해당 오류 지점의 프로그램 상태를 보여주지 않는다. 덤프 시점과 오류 발생 시점 사이에 일어난 프로그램 동작은 오류 발견에 필요한 실마리를 찾기 어렵게 한다.

5) 메모리 덤프를 분석하여 오류를 발견하는 적절한 방법론은 없다(많은 프로그래머들이 오류 스스로 프로그램 덤프에서 마술처럼 나타나길 기대하며 초점 없는 눈으로 바라보기만 한다.)

3. 귀납적 디버깅 절차 5단계를 작성

1) 적절한 데이터 수집

2) 데이터 구성

3) 가설 고안

4) 가설 입증

5) 문제 해결

4. 학습자가 생각하는 디버깅이 가장 흥미 없는 부분임에도 반드시 해야하는 이유 1가지를 작성

- 오류가 발생했을 경우에 소스코드 한줄한줄 디버깅함으로써 어느 부분에서 문제가 있었는지 쉽게 확인할수 있기 때문에 반드시 해야한다.

1. 프로그래머들이 소프트웨어 개발 프로세스 중에서 디버깅을 가장 흥미 없는 부분으로 여기는 이유 4가지를 작성합니다.

1) 자존심에 상처를 입는다. 좋든 싫든 디버깅은 프로그래머가 완벽하지 않다는 것을 확인시킨다. 그들의 설계나 코드에 오류를 남기기 때문이다. 

2) 의욕을 상실할 수 있다. 소프트웨어 개발 중 디버깅은 정신적으로 가장 힘든 작업이다. 일반적으로 가능한 빨리 문제를 수정해야 하는 조직과 개인도 커다란 압박 속에서 업무를 수행한다.

3) 목적을 잃을 수 있다. 프로그래머가 발견한 오류는 사실상 프로그램 내부의 어떤 구문에서도 발생할 수 있기 때문에 디버깅은 정신적으로 어려운 일이다. 다시 말해 프로그램을 검토 없이는 발견된 오류가 프로그램 내에서 발생한 것인지 확신하기 어렵다.

4) 스스로 해결해야 한다. 기타 소프트웨어 개발 작업과 비교해 보면 디버깅 단계는 상대적으로 기존 연구나 문헌, 잘 갖추어진 지침서가 거의 없다. 

2. 프로그램 디버깅의 가장 일반적인 방법 중에서 저장된 덤프를 이용한 디버깅이 가장 비효율적인 무차별 접근 방법인 이유 5가지를 작성합니다. 

1) 메모리 위치와 소스 프로그램 변수의 관련성을 찾기 어렵다. 

2) 적절한 수준의 복잡도를 갖는 프로그램이더라도 메모리 덤프는 대부분 서로 관련 없는 많은 양의 데이터를 생성한다.

3) 오류를 찾기 위해서는 시간 경과에 따라 상태가 변하는 프로그램의 동적 상태를 검토해야 하는데, 메모리 덤프는 그 시점에서 인스턴스의 프로그램 상태를 보여주는 정적인 그림이다. 

4) 메모리 덤프가 오류의 정확한 지점에서 생성되는 일은 거의 없기 때문에 해당 오류 지점의 프로그램 상태를 보여주지 않는다. 덤프 시점과 오류 발생 시점 사이에 일어난 프로그램 동작은 오류 발견에 필요한 실마리를 찾기 어렵게 한다. 

5) 메모리 덤프를 분석하여 오류를 발견하는 적절한 방법론은 없다(많은 프로그래머들이 오류 스스로 프로그램 덤프에서 마술처럼 나타나길 기대하며 초점 없는 눈으로 바라보기만 한다).

3. 귀납적 디버깅의 절차 5단계를 작성합니다.

1) 적절한 데이터 수집. 디버거의 가장 큰 실수는 해결해야 할 문제에 대하여 가능한 모든 데이터와 증상을 고려하지 못하는 것이다. 디버깅의 첫 번째 단계에서는 오류가 있다고 믿도록 유도한 증상은 물론, 프로그램이 정확하게 실행한 경우와 잘못 실행한 경우에 대하여 알고 있는 모든 것을 나열한다. 문제가 발생하지 않더라도 유사한 테스트 케이스는 가치 있는 추가 단서이다. 

2) 데이터 구성. 귀납적 방법은 특정 사항에서 일반적인 사항으로 진행된다. 따라서 두 번째 단계는 수집된 데이터의 패턴을 관찰할 수 있도록 적절하게 데이터를 구조화한다. 이를 바탕으로 고객 이체 계좌에 미지불된 금액이 없을 때만 오류가 발생하는 모순점을 발견하는 것은 매우 중요하다. 

3) 가설 고안. 다음은 단서들의 관계를 조사하고 단서의 구조를 보여주는 패턴을 이용해 오류의 원인에 대하여 한가지 이상의 가설을 고안한다. 가설을 고안하지 못했다면 새로운 테스트 케이스로부터 더 많은 데이터를 찾아야 한다. 여러 가지 가설이 가능하다면 가장 유력한 가설을 선택한다. 

4) 가설 입증. 디버깅 수행 중 부담이 있는 상황에서는 가설 입증 단계를 생략하고, 문제를 수정하기 위해 결론으로 건너뛰는 중대한 실수를 범하기도 한다. 그러나 가설 입증 단계는 앞으로 나아가기 전에 가설의 적정성을 증명하기 위해 필수적인 것이다. 이 단계를 생략하면 문제의 증상만은 성공적으로 수정할 수도 있으나, 문제 자체를 수정할 수 없다. 가설이 단서의 존재를 완전히 설명할 수 있도록 하고, 가설을 원래의 단서나 데이터와 비교해서 입증한다. 가설이 잘 입증되지 않는다면, 가설이 유요하지 않고 불완전하거나 가설에 오류가 있는 것이다.

5) 문제 해결. 이전 단계가 완료되면 문제 해결을 진행할 수 있다. 각 단계에 완전히 시간을 할애함으로써, 오류를 정확하게 수정할 수 있다는 확신을 얻게 된다. 하지만 버스 수정은 다른 프로그램 영역의 문제를 생성하지 않도록 하기 위해 회귀 테스트의 일부 유형을 수행할 필요가 있다는 것을 기억해야 한다. 애플리케이션이 더 커질수록 수정 작업은 다른 문제를 발생시킬 가능성이 있다.