Ⅰ. 테스트의 원칙

테스트는 관점에 따라 여러 가지로 정의되고 있다. 일반적으로, “테스트의 목적은 프로그램이 의도된 기능대로 바르게 동작되는지 확인하는 것” 이라 이해되고 있으나, Myers는 “테스트는 오류를 찾아내려고 프로그램을 실행하는 과정” 이라 정의하고 있다.

만일 의도된 기능 확인이 주목적이라면, 테스트케이스는 무의식중에 그 방향이 중심이 되기 쉽다는 것이다. 그래서 프로그램에 오류가 있다는 가정 하에 테스트를 시작해야하고, 가능한 한 많은 오류를 찾아내기 위해 테스트해야 한다는 주장이다.

여기서 어떤 정의가 타당한가 하는 논의보다는, 어떤 의식으로 테스트에 임해야 하는가에 대한 지침으로 이 “테스트의 원칙”이 의미가 있다고 본다.

1. 테스트케이스의 필수조건은 예상되는 출력 또는 결과를 미리 정의해두는 것이다.
만일 테스트결과를 미리 예상해 두지 않으면, 틀린 결과를 바른 결과로 판단할 수도 있다. 왜냐하면 무의식적으로 자기의도대로 바르게 나온 것으로 보기 쉬운 현상이 있기 때문이다. 따라서 테스트케이스는 프로그램에의 입력데이터를 기술하는 것과 그 입력데이터세트로서 작성될 출력데이터를 정확히 기술하는 두 가지 요소가 필요하다.

2. 프로그래머는 자기 자신의 프로그램을 테스트해서는 안 된다.
대부분의 프로그래머가 자신의 프로그램을 효과적으로 테스트할 수 없는 것은 자기 자신이 그에 필요한 마음가짐, 즉 오류를 발견하려는 태도를 갖기 어렵기 때문이다. 또 요건(사양)에 대한 프로그래머의 오해 때문에 생긴 오류도 프로그램에 포함되어 있을지도 모르기 때문이다. 자기 자신의 작업상 결점을 자신이 찾아낸다는 것은 사람의 기분에 반하는 것이므로 타인이 테스트하는 것이 더 효과적이다.

3. 각각의 테스트결과를 완전히 검사해야 한다.
오류의 징후가 출력데이터의 리스트에 확실히 나타나 있는데도, 그 오류가 발견되지 않는 경우가 많다. 즉 우연히 찾은 오류의 대부분이 보다 앞서의 테스트케이스에서 실제로 나타난 것인데도 그 테스트결과를 주의 깊게 검사하지 않아서 놓친 경우가 있는 것으로서 그렇다는 것을 알 수 있다.

4. 테스트케이스는 바르고 예상 가능한 입력조건뿐만 아니라, 틀리고 예상되지 않는 경우도 고려하여 설정하지 않으면 안 된다.
틀리고 예상되지 않는 입력조건을 고려하지 않고, 바르고 예상 가능한 입력조건을 주로 착안하는 것은 자연스러운 경향이다. 그런데 갑자기 발견되는 오류는 그 프로그램이 무엇인가 새로운 예상되지 않은 상태에서 사용되었을 때 많이 나타난다. 그래서 예상되지 않고 틀린 입력조건을 위한 테스트케이스는 바른 입력조건을 위한 테스트케이스보다 오류발견비율이 높게 되는 것이다.

5. 프로그램 테스트에서 그것이 의도된 대로 동작되는가를 보는 것만으로는 할 일의 절반만 한 것에 지나지 않다. 나머지 절반은 의도되지 않은 동작을 하는 가 어떤가를 검사하는 것이다.
프로그램은 바람직하지 않은 부차적 효과에 대해서 검사해야 한다는 것으로, 앞에서 말한 원칙의 필연적인 결과에 지나지 않다. 예를 들면, 급여명세서를 작성하는 프로그램이 존재하지 않는 종업원의 것을 작성하는 경우에 해당된다.

6. 프로그램을 한번 쓰고 버리는 것이 아닌 이상, 그 테스트케이스도 한번 쓰고 버려서는 안 된다.
테스트케이스의 준비에는 적지 않은 작업량이 필요하다. 그렇다고 프로그램의 오류수정이나 유지 개선한 후에 수정부분의 테스트케이스만으로 테스트해서는 안 된다. 그 수정으로 인하여 정상적이었던 부분에서 새로 오류가 발생하는 경우가 많기 때문이다.

7. 오류가 발견되지 않을 것이란 가정 하에 테스트계획을 세워서는 안 된다.
테스트는 프로그램이 바르게 기능을 다하는지를 확인하는 과정이라고, 테스트의 정의를 오해하여 잘못된 판단에서 비롯되는 경우를 지적하는 것이다.

8. 프로그램의 어떤 부분에 오류가 아직 남아있을 확률은 이미 그 부분에서 찾아낸 오류의 수에 비례한다.
전형적인 프로그램에서는 (경험적으로) 오류는 한데 모여 있고, 위치에 따라 편재하는 경향이 있다는 것인데, 이렇다 할 이유가 설명되고 있지 않다. 단지 어느 OS에서 사용자가 찾아낸 오류의 47%가 시스템가운데 4%의 모듈중에서 나왔다는 예시가 있을 정도이다.
이 현상이 시사하는 것은, 만일 프로그램의 어떤 부분에 다른 부분보다 많은 오류가 있었다면 그 오류가 많은 부분에 테스트를 집중시키는 것이 보다 효과적이라는 것이다.

9. 테스트는 매우 창조적이며 지적으로 도전할 만한 작업이다.
규모가 큰 프로그램을 테스트하는데 필요한 창조력은 그 프로그램을 설계하는데 필요한 창조력을 능가한다고 보는 것이다. 즉 테스트케이스를 개발하는데도 방대한 창조력이 필요하다는 것이다.

10. 중요성이 강조되는 3원칙
- 테스트란 오류를 발견하려고 하면서 프로그램을 실행하는 과정이다.
- 양질의 테스트케이스란 아직 발견되지 않은 오류를 검출할 확률이 높은 것이다.
- 성공한 테스트케이스란 아직 발견되지 않은 오류를 검출한 것이다.

Ⅱ. 디버그(Debug)의 원칙

디버그는 오류의 존재를 확인하는 것부터 시작하여 프로그램 내에서 의심스러운 오류의 정확한 성질과 있는 위치를 찾아내는 것, 오류를 수정하는 작업으로 나누어진다.

 

Ⅱ-1 오류위치발견의 원칙

1. 숙고(熟考)하라
디버그는 문제해결의 과정이라 할 수 있다. 디버그의 보다 효과적인 방법은 오류의 징후(徵候)와 관계되는 정보를 충분히 분석하는 것이다. 효율적인 디버그요원은 컴퓨터에 의존하지 않고도 많은 오류의 장소를 찾아내지 않으면 안 된다.

2. 풀리지 않을 때는 내일까지 늘인다.
인간의 잠재의식은 문제해결의 강한 힘이 된다. 만일 적절한 시간 내에 오류를 찾아내지 못할 경우에는, 일단 디버그를 멈추고 다른 일을 한다. 예를 들면 먹는다던가, 걷는 다던가 등을 한다. 그것은 사고(思考)의 효율이 약해졌다고 보기 때문이다. 잠시 그 문제에 대해 잊고 있은 후에 잠재의식이 그 문제를 해결하던가, 또는 현재의식이 오류의 징후를 새로운 기분으로 찾아낼 수 있게 될 것이기 때문이다.

3. 풀리지 않을 때는 그 문제를 타인에게 설명한다.
그렇게 하면 거의 새로운 무엇인가를 발견하게 될 것이다. 사실, 단지 그 문제를 들어줄 사람에게 설명하는 것만으로도, 그 사람의 조언 없이도 갑자기 해답을 스스로 터득하게 되는 경우가 종종 있다.

4. 디버그도구는 두 번째 수단으로 사용한다.
디버그도구(Dump, Trace 등)는 사고(思考)의 대신이 아니라 보조수단으로 쓴다. 이런 도구를 사용하지 않는 쪽이 도구를 사용한 쪽보다 익숙하지 않은 프로그램의 디버그에서도 성공하고 있다(실험 결과).

5. 실험은 피한다. 실험은 최후 수단이다.
미경험 디버그담당자가 범하기 쉬운 공통적인 잘못은, 프로그램을 실험적으로 변경하여 문제를 해결하려고 하는 것이다. 이것은 성공의 기회를 줄일 뿐만 아니라 그 프로그램에 새로운 오류를 추가해 문제를 복잡하게 하는 경우가 많다.

Ⅱ-2 오류수정의 원칙

1. 하나의 버그가 있는 곳에는 다른 오류도 있을 가능성이 높다.
프로그램의 어떤 부분에서 오류를 찾아낸 경우, 그 부분에는 다른 오류가 있을 확률이 높다(테스트의 원칙에서). 바꿔 말하면, 오류는 편재하는 경향이 있으므로 오류를 수정할 때, 다른데도 의심스러운 곳이 있지 않은지 그 부근을 살펴볼 필요가 있다.

2. 오류의 징후가 아니라, 오류 그 자체를 바로 잡아야 한다.
또 하나의 범하기 쉬운 잘못은 오류 그 자체가 아니라 오류의 징후, 즉 오류의 표면적인 현상만을 수정하는 경우이다. 의도하는 수정이 오류의 모든 단서가 아닌 한, 오류의 일부만을 수정하는 결과에 지나지 않게 된다.

3. 바르게 수정될 확률은 100%가 아니다.
오류를 수정하기 위하여 프로그램에 추가하는 코드는 바르다고만 볼 수 없다. 즉 수정은 본래의 프로그램 코드보다 오류가 개입하기 쉽다. 그래서 오류를 수정한 후에는 본래의 프로그램의 경우보다 엄밀하게 테스트할 필요가 있다.

4. 바르게 수정될 확률은 프로그램의 크기가 클수록 떨어진다.
경험적으로, 틀린 수정으로 인한 오류와 본래의 오류와의 비율은 큰 프로그램에서는 증가한다. 널리 사용되고 있는 어떤 큰 프로그램에서 새로 발견된 오류 6개중 하나는 전에 프로그램을 수정한때의 오류였다.

5. 오류수정에서는 새로운 오류를 만들 가능성이 있음에 주의한다.
수정이 틀리지 않게 할 뿐만 아니라, 바르다고 생각되는 수정이라도 바람직하지 못한 부차적인 효과, 즉 새로운 오류를 개입하게 할 가능성이 있음에 주의하지 않으면 안 된다. 틀리게 수정될 가능성이 있을 뿐만 아니라 수정이 새로운 오류를 지닐 가능성도 없지 않다. 따라서 수정한 후에 오류상황을 테스트해야 하지만, 이와 함께 새로운 오류가 생기지 않았는지 판정하기 위한 복귀테스트(Regression Test)도 하지 않으면 안 된다.

6. 오류를 수정한때에는 잠시 설계단계에 돌아가 수정에 따른 영향을 살핀다.
수정에서 다시 오류가 끼어들기 쉬움으로 프로그램 설계과정에서 사용되었던 절차를 오류수정과정에서도 응용하여 적용할 필요가 있다. 예를 들면 설계에서 코드검사를 했다면 오류수정후에도 답습할 필요가 있을 것이다.

 

 

Ⅲ. 오류의 분석

디버그는 프로그램에서 오류를 제거하는 하는 외에 소프트웨어 오류의 성질에 대한 정보를 우리에게 알려주고 있다. 앞으로의 설계나 테스트과정을 발전시킬 정보로서 이것을 활용할 필요가 있을 것이다.

프로그래머나 그 조직은 발견된 오류 또는 관련된 부분을 분석함으로서 크게 성장할 수 있게 될 것이다. 이것은 어렵고 시간이 걸리는 작업에 해당된다. 이 분석은 오류의 몇%는 논리설계의 오류라던가, 또는 몇%의 오류는 판정명령에서 나왔다는 등의 피상적인 분류보다 더 많은 의미를 갖고 있기 때문이다.

주의 깊은 분석으로서는 다음과 같은 것을 들 수 있다. 물론 이런 분석을 위해서는 오류의 현상과 원인분류가 선행되어야 하고, 오류기록 등의 문서화가 필요할 것이다.

1. 언제 오류가 생겨났는가.
이 질문에의 해답은 간단하지 않다. 시스템관련 문서와 이력을 거슬러 찾아 볼 필요도 있기 때문이다. 본래의 원인의 위치와 오류의 시간을 찾아볼 필요가 있을 것이다. 예를 들면 오류의 본래 원인은 요건의 기술이 불명확했다던가, 그 이전의 오류수정이 잘못 되었다던가, 최종이용자의 요건을 오해했기 때문이 라던가 하는 등을 찾을 수 있을 것이다.

2. 누가 오류를 만들었는가.
이것은 벌주기 위한 것이 아니라, 교육의 목적에서 필요한 것이다. 오류의 종류와 빈도, 그 원인 등의 통계가 작성되면 취약부분이 발견되어 바로 대처할 수 있게 될 것이다.

3. 무엇이 잘못되어 생겨났는가.
하나하나의 오류가 언제 누구에 의하여 발생되었는가가 판명되면 그다음에는 왜 그 오류가 발생되었는가를 규명하는 것이 필요하게 된다. 예를 들면 프로그램언어교육이 충분하지 못했다던가, 요건의 기술능력이 부족했다던가, 판단이나 추측을 잘 못했다던가하는 등이 있을 것이다.

4. 어떻게 했으면 그 오류를 예방할 수 있었겠는가.
다음 프로젝트에서 이와 같은 오류를 예방하기 위해서 무엇을 개선해야 할 것인가, 하는 것을 찾는다면 상당히 유용한 학습대상이 될 것이다.

5. 왜 그 오류가 조기에 발견되지 않았는가.
오류가 테스트단계에서 발견된 경우, 그 오류를 설계검토 등 그 이전단계에서는 발견할 수 없었겠는가, 하는 것을 연구해 볼 필요가 있다.

6. 어떻게 하면 그 오류가 보다 빨리 발견되었겠는가.
이와 같은 타입의 오류를 앞으로의 프로젝트에서 보다 빨리 발견할 수 있도록 하려면 검토나 테스트과정을 어떻게 개선해야 할 것인가, 하는 것은 보다 가치 있는 해답이 될 것이다.

7. 어떻게 하여 그 오류가 발견되었는가.
지금 분석하고 있는 오류가 이용자에 의하여 발견된 것이 아니고, 설정된 테스트케이스에 의하여 찾아낸 것이라면 왜 그 테스트케이스는 성공한 것인가를 되 삭여본다면 거기서 앞으로의 프로그램에 유용한 테스트케이스를 추가할 수 있는 무엇인가를 얻게 될 것이다.

* 부표
위와 같은 오류분석과정이 쉬운 일이 아니지만, 여기서 찾아낸 해답은 다음 프로그램처리를 개선하는데 더 없이 많은 가치를 안겨주게 될 것이다. 이런 분석결과를 활용하기 위해서는 작업과정에서 수집된 오류관련 데이터의 정리가 필요하게 된다.
여기서는 “버그통계 예”를 드는 것에 그친다.

버그 통계 예
대분류-----------------분 류 명------------------건수--구성비

1 기능불량, 요구사양 불량-----------------------1,317----8.1
(논리, 문서화, 변경 등)
2 개발된 기능 불량----------------------------- 2,623---16.2
(정확성, 누락중복, 경우의 분리, 영역 등)
3 구조 불량------------------------------------4,082---25.2
(제어, 루프, 알고리즘, 초기화 등)
4 데이터 불량----------------------------------3,638---22.4
(정의, 초기치, 형식, 값, 억세스 등)
5 코딩 불량------------------------------------1,601----9.9
(엔트리, 규약위반, 문서화 등)
6 통합 불량------------------------------------1,455----9.0
(인터페이스, 파라미터, 인터럽션, I/O타이밍 등)
7 시스템, 소프트웨어 구성 불량--------------------282----1.7
(기동, 회복, 자원관리, 응답시간, 예외처리 등)
8 테스트의 정의, 실행관련 불량--------------------447----2.8
(테스트설계, 실행, 테스트케이스, 테스트문서 등)
9 기타-------------------------------------------763----4.7

합 계------------------------------------------16,209 건 100 %

[주]
표본크기(코멘트 포함) 6,877,000 스텝
전체 버그건수 16,209 건
1,000 스텝당 버그건수 2.36 건

- 대분류만 발췌한 것임.
- 실행명령 이외의 것도 포함된 것임.
- 단위테스트 이후의 통합테스트와 시스템테스트에서 검출된 것임.
- 버그종류별 상대적 발생빈도를 표현한 것에 의미가 있음.

[출전] Boris Beizer, “Software Testing Techniques(Second edition)”,
Van Nostrand Reinhold, 1990