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) |
- 설계변경이 프로그램으로 잘 전달되어야 하며 문서화가 정확/완전해야 함 |