SW 테스트의 개요

개념
- 노출되지 않은 숨어있는 결함(Fault)을 찾기 위해 소프트웨어를 작동시키는 일련의 행위와 절차 - 오류 발견을 목적으로 프로그램을 실행하여 품질을 평가하는 과정 - 개발된 소프트웨어의 결함과 문제를 식별하고 품질을 평가하며 품질을 개선하기 위한 일련의 활동 - 일반적으로 테스트 케이스에 따라 SW를 동적으로 실행시켜 예상결과치와 비교 분석 - SW의 동작과 성능, 안정성이 요구되는 수준을 만족하는지 확인하기 위한 결함을 발견하는 메커니즘 - “테스트는 프로그램이나 시스템이 예상대로 작동할 것이라는 확신을 증진시키는 과정이다.” - Hetzel 1973 -

  • SWEBOK에 정의된 소프트웨어 테스팅의 영역

 

  •  테스트 작업에 대한 간단한 퀴즈 (몸 풀기 )

1. 소프트웨어 개발이나 유지보수 작업에서 테스트, 디버깅, 수정에  필요한 노력은 평균 몇 %나 차지하는가?  정답:50%(개발), 65%(유지보수)      

 

2. 처음 개발에 드는 비용과 유지보수 또는 기능개선에 드는 비용의 비율은?

   정답: 처음개발: 25~30%  유지보수: 70~75%

 

3. 분석이나 설계에서 발생하는 소프트웨어 오류와 프로그래밍 작업에서 발생하는 오류의 비율은?

   정답:프로그래밍: 30%            분석 및 설계: 70%

 

4. 프로젝트가 완성되는 시점에 오류를 발견하고 수정하는 비용과 프로젝트 시작할 때 오류를 발견하고 수정하는 비용의 비율은 얼마인가?  정답:100 대 1

 

5. 고급 언어로 100 라인의 프로그램을 작성할 때 평균적으로 어느 정도의 오류를 발생시키겠는가? 새로 작성하는 코드와 수정하는 코드 각각의 오류빈도를 답하시오.

  정답: 새로 작성하는 프로그램: 100 라인 당 6~8개의 오류

         수정하는 프로그램: 100 라인 당 2~3 개의 오류(구조화되어 있고 잘 문서화 된 경우)

         종합적으로 100 라인 당 12~20 개의 오류(구조화 되지 않고 문서화 되지 않은 경우)

 

6. 모듈 테스트 또는 서브 시스템을 테스트한 후에 100라인 당 몇 개 정도의 오류가 남아 있겠는가? 소프트웨어에 대한 시스템 또는 인수 테스트 후 제품을 출하할 때 오류가 남아있는 평균 개수는?

  정답: 단위 테스트 후: 100 라인 당 1.0~1.5 개의 버그

              시스템 출하 후: 1000 라인 당 4~6 개의 버그

 

7. 새로 개발한 시스템 기능의 몇 퍼센트가 올바로 테스트된 후 출하되는가?

   정답:     15~20%

 

8. 인스펙션, 리뷰, 워크스루에 필요한 비용은 개발 비용에 비하여 어느 정도인가?

   정답:      20%

 

9. 리뷰나 워크스루를 한 시간 효과적으로 한다면 몇 시간 정도의 테스트 작업을 줄이는 효과가 있겠는가?

        정답:      8~12 시간

 

10. 단순한 오류를 고치는데 필요한 평균 인원-시간(man-hour)은? 복잡한 오류는 얼마나 걸리는가?

정답:      1~4 시간(단순한 오류), 40~80 시간(복잡한 오류)

 

11.  전문가들은 시스템 테스트나 품질 보증 활동에 대하여 얼마나 부정적인 태도를 가지고 있을 것으로 생각되나?

    정답:      85%

 

12.  IBM MVS 운영체제나 Microsoft 윈도우 등 소프트웨어 제품이 처음 출시될 때 어느 정도의 오류가 남아 있겠는가?

  정답: 1995년 MVS 출시할 때 1000 개의 버그

        2000년 2월 윈도우 2000 처음 출시할 때 63000 개의 버그

        출시 전에 발견되었으나 출시에 앞서 또는 출시 후 1년 동안 한 버그 수정하지 못한 개수임.

 

13.  테스트 작업이 끝나기 전과 제품이 설치되어 사용되기 시작한 후 얼마나 많은 테스트 엔지니어들이 제정신이 아닌 상태가 되는가?

   정답: 없음(이미 프로젝트 수행하면서 테스트 이전에 스트레스가 많이 쌓임)

 

 

I. 소프트웨어 테스트의 개요

가. SW 테스트의 중요성

- 시스템 개발에 드는 총비용의 50%이상, 총기간의 50% 정도를 테스트에 할애한다. [Myers,1979]

나. 소프트웨어 테스트와 유지보수 비용과의 관계

- 유지보수 단계의 생산성은 개발 단계의 생산성의 1/40

- 테스트를 얼마나 철저히 했느냐에 따라 사용자의 만족도가 달라지고 유지보수 비용에 큰 차이가 있을 수 있음

 

 

다. SW 테스트의 정의

- 노출되지 않은 숨어있는 결함(Fault)을 찾기 위해 소프트웨어를 작동시키는 일련의 행위와 절차

- 오류 발견을 목적으로 프로그램을 실행하여 품질을 평가하는 과정

- 개발된 소프트웨어의 결함과 문제를 식별하고 품질을 평가하며 품질을 개선하기 위한 일련의 활동

- 일반적으로 테스트 케이스에 따라 SW를 동적으로 실행시켜 예상결과치와 비교 분석

- SW의 동작과 성능, 안정성이 요구되는 수준을 만족하는지 확인하기 위한 결함을 발견하는 메커니즘

    - “테스트는 프로그램이나 시스템이 예상대로 작동할 것이라는 확신을 증진시키는 과정이다.”                                   -            Hetzel 1973 -

 

 

라. SW 테스트의 목적

- 프로그램의 잠재된 오류의 발견

- 기술적인 기능 및 성능의 확인

- 사용자 요구 만족도 향상

- 제품 신뢰도 향상

- 프로그램이 사용할만한 것인지 확인하기 위하여 결함을 발견할 목적으로 프로그램을 실행하는 작업

- 그러나 완벽한 테스트는 불가능

한 프로그램 내의 내부조건 무수히 많을 수 있음.

입력이 가질 수 있는 모든 값의 Combination 무수히 많음.

GUI 이벤트가 발생하는 순서에 대한 Combination도 무한정.

- 테스트는 오류가 없음을 보이려는 것이 아님.

테스트: 효율적인 오류의 발견

증명: 프로그램 논리의 Proof

- 현실적인 목적

주어진 시간과 인력으로 오류를 발견할 확율이 많은, 즉 가장 효율적인 테스트 케이스를 찾아내고 실행하는 일.

 

마. 성공적인 테스트는 무결점이 아닌 결함을 찾는데 있음

- 테스트 케이스 선정, 테스트 계획 수립에 따라 영향을 많이 받음

- 테스트 케이스는 기대되는 표준 결과를 포함하여 예측오류, 기대되지 않은 결함이 있다는 가정 하에 테스트 계획 수립

- 개발자가 자기 프로그램을 직접 테스트 하지 않음 ( 마이어 법칙 )

- 능력 있는 테스트 수행자는 성공적이고 효율적으로 시험을 수행

 

바. 테스트에 대한 이해

- 테스트는 오류를 발견하려고 프로그램을 수행 시키는 것

- 따라서 테스트에 의하여 오류가 발견되지 않았다고 하여 프로그램에 오류가 없는 것은 아님

- 완벽한 테스트는 불가능하다.

- 테스트는 창조적인 일이며 힘든 일이다.

- 테스트는 오류의 유입을 방지할 수 있다.

- 테스트는 구현에 관계없는 독립된 팀에 의하여 수행되어야 함

- 테스트: 프로그램이 잘 수행된다는 것을 검증하는 과정(X).

- 프로그램이 올바로 작동한다고 증명할 수 있을 정도로 충분히 테스트하는 것은 불가능.

- 100 라인 당 1개 내지 3개의 오류가 테스트 단계에 발견

 

II. 소프트웨어 테스트의 원칙

 

가. 소프트웨어 테스트의 원칙과 경제성의 원리

구분

내용

테스트 원칙

마이어의 원칙

개발자가 자신의 프로그램을 테스트하지 않는 원칙

Test Case

기대되는 표준 결과 포함(테스트 오라클), 예측오류,기대되지 않은 결함이 있다는 가정아래 Test Plan 수립

결과Review

Test 내용을 점검하여 누락된 사례도출

경제성의 원리

추가 결함이 발견될 확률은 기 발견된 결함 수에 정비례 개발 시 노력 분포도 40:20:40 = 설계:프로그래밍:테스트 SW의 내재된 결함을 찾아 내는 시기가 중요

 

나. 소프트웨어 테스트의 일반적인 원리

원리 1 : 테스팅은 결함이 존재함을 밝히는 활동이다.

- 결함이 존재함을 밝히는 활동,

- 결함이 없다는 것을 증명할 수는 없음

- 결함을 줄이는 활동

원리 2 : 완벽한 테스팅(Exhaustive Testing)은 불가능

- 무한 경로: 한 프로그램내의 내부 조건은 무수히 많울 수 있음

-  무한 입력값:입력이 가질 수있는 모든 값의 조합이 무수히 많음

- 무한 타이밍 : GUI이벤트 발생순서에 대한 조합도 무수히 많음

- - 완벽하게 테스팅하려는 시도는 불필요한 시간과 자원낭비

원리 3 : 테스팅은 개발 초기에 시작한다.

- 조기 테스트 설계 시 장점

-  테스팅 결과를 단시간에 알 수 있고

-  테스팅 기간 단축

-  재 작업을 줄여 개발 기간 단축 및 결함 예방

원리 4 : 결함집중(Defect Clustering)

- 적은 수의 모듈에서 대다수의 결함이 발견됨

- 복잡한 구조의 모듈 , 최신기술적용 모듈

- 재사용이 아닌 신규개발 모듈,  크기가 큰 모듈

원리  5: 살충제 패러독스(Pesticide paradox)

- 동일한 테스트 케이스에 의한 반복적 테스트는 새로운  버그를 찾지 못함

-  테스트케이스의 정기적 리뷰와 개선 및, 다른 시각에서의 접근이 필요

- 탐색적 테스팅, JIT테스팅 등의 경험기반 접근을 통한

- 테스트 케이스의 개선이 필요

원리  6: 테스팅은 정황(Context)에 의존적이다.

- 소프트웨어의 성격에 맞게 테스트 실시

- 모든 소프트웨어에 공통적인 사항

    1. 테스트 수명주기에 따른 테스트 프로젝트 계획

    2. 표준적인 기법 적용

    3. 독립적 테스트 환경

    4. 효율적/효과적 테스트 팀 조직

    5. 공식 리포팅

원리  7 : 오류-부재의 궤변

- 요구사항을 충족시켜주지 못한다면, 결함이 없다고 해도  

- 품질이 높다고 볼 수 없다.

 

원리

내용

원인

결함발견

-결함제거가 아닌 겸함의 발견을 목적으로 함

-Test 본연의 역할

불완전

-완벽한 테스팅은 불가능

-무한경로, 무한입력값, 무한타이밍

- 자원의 한계

초기집중

-개발 설계 시 부터 테스트를 고려

-결함의 조기발견 및 재유입 방지

-품질비용 감소

결함집중

- 결함의 80%는 20%코드에 집중

- 결함이 높은 곳에 자원집중

-파레토 법칙

살충제페러독스

- 동일한 테스트 전략, 기법을 적용할 시 내성이 생김

-개발자의 TEST회피

테스트정황

- 테스트는 테스트 주변환경에 의한 영향을 받음

- 외부요소, 심리요소

 

 

III. 소프트웨어 테스트의 품질척도

- 컴퓨터 프로그램이 얼마나 쉽게 테스트할 수 있는가에 대한 성질

- 컴퓨터 엔지니어가 설계 단계에서부터 테스트용이성을 염두해 두고 설계해야 함

구 분

내 용

작동성(Operability)

- 시스템이 bug를 적게 가지도록 하여 시험이 효율적으로 되도록 함

관찰성(Observability)

- 입력에 대해 출력이 명확히 가시적으로 생성되도록 함

조종성(Controllability)

- 출력은 입력의 조합으로 생성될 수 있도록 함

분해성(Decomposability)

- 모듈들은 독립적으로 시험되어져야 함

단순성(Simplicity)

- 시험할 것이 적을수록 시험이 빨리 종료됨

- 기능적 단순성, 구조적 단순성(오류 전달이 제한적이 되도록 아키텍쳐가 모듈화 되어야 함), 코드단순성 (코딩규정 준수)

안정성(Stability)

- 실패를 잘 극복할 수 있도록 함

이해성(Understandability)

- 설계변경이 프로그램으로 잘 전달되어야 하며 문서화가 정확/완전해야 함

 

댓글