소프트웨어테스팅 - booksr.co.kr†Œ프트웨어테스팅_미리보기.pdf ·...
TRANSCRIPT
소프트웨어테스팅
Life & Power Press
권용래 지음
소프트웨어 테스팅은 소프트웨어 개발에 있어서 품질 수준을 높이기 위한 가
장 중요한 수단의 하나이며 최후의 수단임에도 불구하고 소홀히 되어온 것이 사
실이다. 그 이유는 소프트웨어 개발의 1차적인 관심이 요구되는 시스템을 가능
한 한 빠른 시간에 개발해내는 데에 있었고 개발 완료된 소프트웨어의 품질 자
체에는 부차적인 관심을 두고 있었기 때문이라고 볼 수 있다. 그러나 요구되는
소프트웨어 시스템의 구현에 경험과 자신감이 축적됨에 따라 소프트웨어 품질
제고에 관심을 보이기 시작하 지만 그 방법으로서는 개발 프로세스 개선을 통
한 품질 개선에 치중해 왔다고 볼 수 있다.
소프트웨어 테스팅이 소홀히 될 수밖에 없었던 가장 큰 이유는 테스팅이 개
발 완료된 소프트웨어를 고객에게 인도하기 직전에 수행하는 작업이다 보니까
인도하기에 바빠서 충분한 시간을 가지고 철저하게 테스팅을 할 여유가 없었기
때문이다.
그러나 이러한 경향은 급격히 변화할 것으로 예상된다. 소프트웨어의 응용이
확산되고 소프트웨어가 응용 시스템에서 점점 더 중요한 역할을 맡게 됨으로써
소프트웨어 품질에 한 관심이 빠른 속도로 높아지고 있기 때문이다. 우선 낮
은 품질의 소프트웨어가 초래하는 피해가 이용자의 불편은 물론 국가 안보를 위
협하거나, 환경의 피해, 재산상의 손실 등 점점 규모와 파장이 커지고 있기 때문
이다. 따라서 소프트웨어를 고객에게 인도하기 전에 보다 철저하게 결함을 제거
함으로써 품질에 한 고객의 높아진 요구를 충족시키는 것이 결함투성이인 시
스템을 인도하는 것보다 고객을 만족시킬 가능성이 높음을 인식하기 시작했다.
또한 인도한 후에 발견되는 결함을 수정하는 비용이 아주 크기 때문에 인도하기
전에 가능한 한 결함을 제거하는 것이 상 적으로 비용 절감이라는 인식 또한
확산되고 있다.
소프트웨어 품질을 획기적으로 제고하기 위해서는 지금까지의 임시 방편적
인 기법의 적용으로는 불충분하고 개발 단계 전반에 걸쳐서 품질을 제고시킬 수
있는 노력이 체계적으로 가해져야 할 것이다. 따라서 그 사이에 연구되고 축적
되어 온 체계적 테스팅 기술을 적용하여 시간이 허용하는 한도 내에서 최 한
PR
EF
AC
E
3
머/리/말
결함을 검출해 내어야 할 것이다.
그러나 소프트웨어 프로세스의 경우와 달리 이 분야에 관심이 있더라도 소프
트웨어 테스팅에 관한 지식은 쉽게 얻을 수 있는 기회가 별로 없다. 개의 경우
에 학의 학부과정에서 소프트웨어 공학 개론 한 과목을 수강할 수 있을 뿐 소
프트웨어 테스팅을 독립된 과목으로 다루는 학은 거의 없다고 볼 수 있다. 그
렇다고 실무적인 교육의 기회가 제공되는 사례도 별로 보이지 않는다. 그 뿐 아
니라 산업체 현장에서도 소프트웨어 테스팅에 관한 교육은 다른 분야에 비해 체
계가 잡혀 있지 않다.
이 책에 관한 구상은 2004년 한국과학기술원에 소프트웨어 전문가 과정이
설치되고 그 과정을 위하여 소프트웨어 품질 보증이라는 과목의 강의를 새롭게
개설하는 계기로 시작되었다. 전문과 과정의 목표는 일반 정규 과정과 달리 산
업체의 유경험자를 상으로 산업체에서 얻은 경험적 지식을 체계화하고 과정
을 수료한 후에 다시 실무에 돌아가게 될 때 요구되는 기술을 제공하는 데 있다.
따라서 소프트웨어 테스팅이라는 과목이 이러한 목표에 잘 부합하겠다는 판단
이 섰던 것이다.
특히 2006년 한국과학기술원에서 연구연가를 얻어 2006년 3월부터 1년여
동안 삼성전자 소프트웨어연구소에서 소프트웨어 테스트 프로세스 개선에 관한
자문 활동을 하면서 소프트웨어 개발 현장에서 직면하는 품질 요구 수준, 테스
팅을 위한 주변 환경, 활용 가능한 테스팅 기법에 접하면서 소프트웨어 개발 현
장에서 사용할 수 있는 테스팅 전문 서적에 한 필요성을 인식하게 되었다.
따라서 이 책은 처음부터 소프트웨어 개발 현장에서 참고할 수 있는 소프트
웨어 테스팅에 관한 전문 서적으로 기획되었다. 그렇다고 해서 이 책을 실무적
인 지침서로 구상한 것은 아니다. 현장에서 활용 가능한 기법을 포함하는 것은
물론 현재까지 소개되어 있는 테스트 기법을 최 한 균형있게 망라하되 그 중에
서 실제로 활용 가능한 기법을 선별하여 비교적 상세하게 설명하는 방식으로 서
술하 다. 따라서 일반 학에서 소프트웨어 테스팅이 한 학기 정도의 독립 과
목으로 개설된다면 그러한 과목의 교재로서도 사용 가능할 것으로 사료된다. 단
PR
EF
AC
E
4
이 경우에는 테스팅 도구를 사용한 실습이 보완되어야 할 것이다.
현장에서는 품질 관리 기법도 테스트 기법 못지않게 긴요하지만 이 책에서는
품질 관리 기법에 관해서는 비교적 적은 분량을 할애하 다. 그 이유의 하나는
품질 관리 기법에 관해서는 다른 훌륭한 책들이 많이 소개되어 있기 때문이고
또 다른 이유는 소프트웨어 품질관리 기법이 체로 일반 공학의 품질 관리 기
법을 상당 부분 원용하고 있기 때문에 거기에 특별히 추가할 내용이 많지 않다
고 생각하 기 때문이다.
이 책은 앞부분에서 소프트웨어 품질 제고를 위한 테스팅의 역할, 테스팅이란
무엇인지, 어떠한 유형의 테스팅이 존재하는지, 테스팅이 왜 기술적으로 어려운
지 등에 관해 논의하고 이어서 소프트웨어 테스팅이 수행되는 절차를 설명한다.
서론적인 부분에 이어서 테스팅의 기술적인 내용, 즉 테스트 설계 기법들을
비교적 상세하게 소개한다. 테스트 설계 기법은 크게 명세서를 기반으로 하는
기법과 코드를 기반으로 하는 기법으로 나누어서 소개하며 각 기법을 적용하는
예를 곁들인다.
그 다음에는 소프트웨어 시스템의 개발이 진행되고 있는 과정에 각종 테스트
기법들이 어떠한 시점에 어떠한 조합을 가지고 적용되는지를 논의한다.
끝으로 새롭게 등장하는 새로운 소프트웨어 패러다임에 응한 소프트웨어
테스트 전략 및 앞에서 다루지 않은 테스팅의 고급과제를 간략하게 소개한다.
소프트웨어 테스팅은 엄 하게 진행되어야 하고 많은 작업이 반복되어 수행
된다. 따라서 테스팅에 수반하는 작업들은 최 한 자동화가 되어야 한다. 테스
트 작업의 자동화 방법과 자동화 도구는 따로 모아서 설명하지 않고 테스트 기
법과 작업이 소개될 때 그와 더불어 더불어 설명한다.
이 책은 5부로 구성되어 있다.
1부에서는 소프트웨어 테스팅의 기본 개념을 소개한다.
1장에서는 소프트웨어 품질을 개선하는 데에 테스팅이 어떠한 역할을 하는지
PR
EF
AC
E
5
에 관하여 다룬다. 소프트웨어에 요구되는 품질 요소들이 무엇이며, 구현된 소
프트웨어가 각 품질 요소를 충족시키는지를 확인하기 위하여 어떠한 종류의 테
스팅이 수행되는지, 그리고 테스팅이 왜 어려운지에 관하여 논의한다. 그리고
소프트웨어의 품질 개선을 위해서는 테스팅도 중요하지만 결함이 소프트웨어에
들어 오지 않도록 하기 위해서는 최신 소프트웨어 공학기술이 크게 기여할 수
있음을 강조하고 최신 소프트웨어 공학기술이 테스팅 작업에 어떻게 도움을 줄
수 있는지에 관하여 논의한다.
2장에서는 소프트웨어 테스팅이 무엇인지를 정의하고 각종 테스팅의 유형을
비교 소개하고 간단한 예제 프로그램을 테스팅하는 과정을 소개하면서 테스팅에
서 요구되는 기술적인 과제가 무엇이며 테스팅의 한계가 무엇인지를 논의한다.
3장에서는 테스팅에서 가장 중요한 기술적 개념과 테스트 프로세스에 관하여
설명한다. 테스트를 진행하는 순서, 테스트에 사용할 테스트 데이터, 테스트의
성패를 판정하는 데 사용하는 테스트 오라클 그리고 테스트에 사용되는 각종 기
준에 관하여 설명한다. 그리고 이러한 사항을 설명하는 과정에서 등장하는 여러
테스팅의 용어들을 소개한다. 마지막으로 테스트 프로세스 개선을 위해 사용되
는 테스트 성숙도 모형을 소개한다.
4장에서는 실행을 통하지 않고 결함을 검출하는 기법인 각종 정적 분석 기법
에 관하여 설명한다. 간단하게는 작성된 코드를 신중이 검토함으로써 결함을 찾
아내려는 검토 기법으로부터 각종 정형적 정적 분석 기법을 소개한다.
테스팅에서 가장 중요하다고 할 수 있는 작업은 결함을 효과적으로 검출할
수 있는 테스트입력을 찾아 내는 기술일 것이다. 테스트 설계는 크게 소프트웨
어 명세서에 기반을 두는 기법과 작성된 코드에 기반을 두는 기법으로 나눌 수
있다.
2부에서는 명세서에 기반을 두는 주요 테스트 설계 기법을 소개한다.
5장의 처음에는 명세서 기반 테스트 설계가 무엇인지를 소개하고 명세서 기
반 테스트 설계기법을 표하는 분할 테스팅 기법과 경계치 테스팅 기법을 다룬
PR
EF
AC
E
6
다. 그리고 이 기법들을 적용하여 입력 역을 표할 수 있는 사용 가능한 입력
데이터들이 정의되었을 때 이것들을 어떻게 효과적으로 결합하여 테스트에 사
용할 수 있는지에 관하여 설명한다. 그리고 간단한 예제를 가지고 분할 테스팅
과 경계치 테스팅에서 사용할 테스트를 설계하는 세부적인 방법을 설명한다.
6장에서는 5장에서 소개하지 않은 명세서 기반 테스트 설계 기법을 소개한다.
3부에서는 코드에 기반을 두는 주요 테스트 설계 기법을 소개한다. 작성된 코
드가 준비되어있으면 구체적인 코드의 구조를 테스트 설계에 활용할 수 있다.
이러한 기법은 공통적으로 코드의 구조를 참고하여 테스팅에서 코드의 각 부분
을 체계적으로 살펴 볼 수 있는 방법을 제공한다.
7장에서는 소프트웨어에 포함되어 있는 프로그램 문장들, 각종 분기들과 조
건들을 체계적으로 살펴 볼 수 있는 테스트를 설계할 수 있는 기법을 소개한다.
그리고 간단한 예제프로그램을 가지고 문장 테스트, 분기 테스트와 조건 테스트
를 위한 테스트 케이스를 설계하는 세부적인 방법을 설명한다.
8장에서는 프로그램에 포함되어 있는 모든 실행 경로들을 체계적으로 살펴
볼 수 있는 테스트를 설계할 수 있는 기법을 소개한다. 그리고 크게는 경로 테스
트에 포함될 수 있는 데이터 흐름 테스트 기법도 소개한다. 그리고 여기에서도
간단한 예제프로그램을 가지고 경로 테스트를 위한 테스트 케이스를 설계하는
세부적인 방법을 설명한다.
4부에서는 3부에서 소개한 테스트 설계 기법을 소프트웨어를 실제로 테스트
할 때 어떻게 적용하는지에 관하여 설명한다. 소프트웨어 개발이 진행되는 동안
에 테스팅은 소프트웨어의 여러 수준에서 수행된다. 시스템을 구성하는 기본 단
위가 완성되면 시스템의 다른 부분과 상관없이 이 단위를 따로 테스트하고 여러
단위를 묶어가는 과정에서 통합 테스트를 실시하고 완전한 시스템이 형성되면
다양한 시스템 수준의 테스팅을 수행한다.
9장에서는 개발이 완료된 시스템의 모든 단위가 하나의 시스템으로 완전히
PR
EF
AC
E
7
통합되기 전까지의 테스팅, 즉 단위 테스트와 통합 테스트를 진행하는 방법을
소개한다.
10장에서는 모든 구성 단위가 하나의 시스템으로 통합되고 나서 시스템 수준
에서 수행되는 여러 종류의 테스트 기법을 소개한다.
11장에서는 1차 테스트 중에 검출된 결함을 제거하기 위해 소프트웨어에 수
정이 가해졌을 때 수정이 제 로 이루어졌고 수정이 시스템의 다른 부분에 부작
용을 일으키지는 않았는지를 확인하기 위하여 수행되는 회귀 테스팅 기법을 소
개한다.
그리고 테스트 작업을 효과적으로 관리하는 방법을 소개한다. 테스팅에서는
결함을 효과적으로 검출할 수 있는 기술도 중요하지만 테스팅 작업에 소요되는
자원을 효과적으로 배분하는 방법, 검출된 결함을 반드시 수정되도록 노력하는
기술, 테스팅 작업의 능률을 고도화하기 위한 자동화, 소프트웨어 품질 보증 기
법 등과 같은 기술 외적인 노력도 중요하다.
12장에서는 테스트 계획 수립 방법, 결함 관리 기법과 같은 테스트 작업을 능
률적으로 관리하는 여러 기법들을 소개한다. 그리고 소프트웨어 테스팅에 적용
할 수 있는 품질 보증 기법도 아울러 소개한다.
이 책의 12장까지는 전통적 유형의 소프트웨어인 순차적 프로그램에 적용할
수 있는 테스팅 기법을 소개한 셈이다. 그러나 최근의 프로그래밍은 새로운 패
러타임을 빠른 속도로 채택하고 있다. 새로 등장하고 있는 객체 지향 프로그램,
실시간 병렬 프로그램, 임베디드 소프트웨어 등을 테스팅하는 기법도 아직 미진
한 수준이지만 빠른 속도로 발전하고 있다. 또한 검출된 결함 유형을 분석하여
그러한 결함들을 효과적으로 검출할 수 있는 테스트를 설계하는 기법은 일종의
경험을 기반으로 기법으로서 명세서나 코드를 바탕으로 한 체계적 설계 기법과
구별된다. 따라서 5부에서는 앞에서 취급하지 않은 고급 과제를 다룬다.
13장에서는 결함 기반 테스트 설계 기법을 소개한다. 이 범주에 속하는 표
적인 기법은 변종 분석 기법이다. 이 기법은 오래 전에 소개되었지만 이 기법을
적용하는 데 소요되는 막 한 비용 때문에 사실상 잊혀졌던 기법이다. 그러나
PR
EF
AC
E
8
그간 꾸준한 연구로 비용을 절감할 수 있는 기술이 축적됨으로써 이제는 실용할
만한 유망한 기술로 인식되고 있다.
14장에서는 객체 지향 소프트웨어를 테스팅하는 기법을 소개한다. 객체 지향
언어가 순차적 프로그래밍 언어에서 찾아 볼 수 없는 다양한 기능을 보유한 것
처럼 객체 지향 프로그램 테스팅도 이제까지 소개된 것과는 다른 테스트 기술을
요구하고 있다.
이 책의 마지막 장인 15장에서는 실시간 임베디드 소프트웨어 테스팅 기법을
논의한다. 소프트웨어가 다양한 장비와 시스템에 내장되어 그것들을 제어하는
데 사용됨에 따라 임베디드 소프트웨어 개발이 활발하게 진행되고 있다. 이러한
시스템은 다양한 하드웨어 시스템, 주변기기, 컴퓨터 기능과는 무관한 장비와
연동해야 하기 때문에 개발에 새로운 복잡도를 제공한다. 그리고 소프트웨어 개
발은 내장 시스템의 다른 부분과 동시에 개발이 이루어지므로 소프트웨어 테스
팅에는 새로운 차원의 어려움을 제공하게 된다.
이 책의 마지막 부분에는 연습 문제와 참고 문헌을 수록하 다. 연습문제는
블랙박스 테스트와 화이트박스 테스트의 테스트 설계 방법을 복습하기 위한 것
이다. 참고 문헌은 학술적인 연구자료라기보다는 개념의 이해에 도움이 되고 실
무에 참고할만하고 독자들이 쉽게 구할 수 있는 것을 중심으로 선별하 다.
한국과학기술원 전산학과 소프트웨어 공학 연구실의 학원생들과 소프트웨
어 전문가 과정 학생들이 검토를 해주었다. 그리고 슈어소프트 테크놀로지의 배
현섭 박사가 원고를 면 하게 살펴보며 개선점을 지적해 주었다. 이 책의 집필
은 저자의 불가피한 사정으로 여러 번 지연이 되었다. 너그럽게 지연을 허용해
주신 생능출판사 김승기 사장님께 감사를 드린다. 끝으로 편집에 수고해 주신
생능출판사 편집부 여러분께 심심한 감사를 드린다.
PR
EF
AC
E
9
소프트웨어 품질과 테스팅
1.1 개요 20
1.2 소프트웨어 품질 요소 25
1) 운 상 적합성 여부를 나타내는 품질 요소 26
2) 변경하기 쉬운지를 나타내는 품질 요소 27
3) 활용도를 높이기 쉬운지를 나타내는 품질 요소 28
1.3 소프트웨어 결함의 예방 31
1.4 테스팅이 어려운 이유 35
1) 소프트웨어의 복잡도 35
2) 불완전한 명세의 문제 36
3) 테스트를 위한 작동 환경 구축의 어려움 37
4) 소프트웨어 고유의 특성에 따른 문제 38
5) 테스트 마인드의 부재 39
소프트웨어 테스팅이란?
2.1 개요 42
2.2 소프트웨어 에러, 결함과 고장 43
2.3 테스팅의 유형 45
1) 테스팅의 목적에 따른 분류 45
2) 테스트 기반에 따른 분류 46
3) 테스트 설계 기법에 따른 분류 47
4) 테스트 수준에 따른 분류 47
2.4 체계적 테스트의 예 48
1) 기능적 테스트의 실행 과정 49
2) 구조적 테스트의 실행 과정 50
2.5 테스팅의 한계 53
소프트웨어 테스트 프로세스
3.1 개요 58
3.2 테스트의 절차 60
1) 테스트의 설계 60
CO
NT
EN
TS
10
차/례
PART ��
01
소프트웨어테스팅의기본개념
CHAPTER
02CHAPTER
03CHAPTER
2) 테스트의 실행 61
3) 테스트의 결과 평가 62
3.3 테스트 케이스의 설계 63
3.4 테스트 오라클 65
3.5 테스트 기준 68
3.6 테스트 프로세스의 자동화 72
1) 개발 초기 단계에 사용되는 테스트 도구 74
2) 개발 중간 단계에서 사용되는 테스트 도구 74
3) 개발 후기 단계에서 사용되는 테스트 도구 75
4) 모든 개발 단계에서 사용되는 테스트 관리 도구 76
5) 테스트 유틸리티 76
3.7 테스트 프로세스의 개선 77
소프트웨어 정적 분석 기법
4.1 정적 분석 82
4.2 소프트웨어 에러 유형 83
4.3 검토 기법 85
1) 개별 검토(Self Review) 85
2) 동료 검토(Peer Review) 86
3) 워크스루(Walkthrough) 86
4.4 공식 검토회 88
4.5 사열과 감리 90
4.6 기호 실행 기법 91
4.7 프로그램의 정확성 증명법 95
분할 테스트
5.1 개요 109
5.2 분할 테스트 113
5.3 분할 테스트 설계의 예 116
5.4 경계치 테스트 120
CO
NT
EN
TS
11
04CHAPTER
PART ��
05
명세기반테스트설계기법
CHAPTER
5.5 경계치 테스트 설계의 예 121
5.6 테스트 데이터의 조합 방법 124
기타 명세서 기반 테스팅 기법
6.1 개요 130
6.2 결정표 테스팅 130
6.3 결정표 테스트의 예 136
6.4 원인 결과 그래프 138
6.5 랜덤(Random) 테스트 140
6.6 상태에 기반을 둔 테스팅 142
6.7 문법에 기반을 둔 테스트 146
문장 테스트와 분기 테스트
7.1 개요 150
7.2 제어 흐름 그래프 152
7.3 문장 테스트 157
7.4 문장 테스트 설계의 예 159
7.5 분기 테스트 162
7.6 분기 테스트 설계의 예 164
7.7 조건 테스트 166
1) 조건 테스트 167
2) 조건-결정 테스트 167
3) 다중 조건 테스트 167
4) 개선된 조건-결정 테스트 168
7.8 조건 테스트 설계의 예 169
경로 테스트
8.1 개요 172
8.2 독립적 경로 173
8.3 루프 테스트 177
CO
NT
EN
TS
12
PART ��
07
코드기반테스트설계기법
CHAPTER
08CHAPTER
06CHAPTER
1) 조건부 반복 구조의 테스트 177
2) 일반적인 반복 구조의 테스팅 177
8.4 경로 테스트 설계의 예 179
8.5 데이터 흐름 테스트 181
8.6 테스트 커버리지 184
1) 테스트 수행 수준 평가 184
2) Assertion 기법 184
3) 테스트 케이스의 설계 188
4) 테스트 케이스의 보완 188
5) 테스트 케이스와 테스트 프로세스의 평가 188
6) 테스트 종결 기준 189
7) 테스트 케이스 관리 189
단위 테스트와 통합 테스트
9.1 개요 198
9.2 단위 테스트 200
9.3 단위 테스트의 진행 202
9.4 단위 테스트 드라이버 205
9.5 다른 형태의 단위 테스트 206
9.6 테스트 주도형 소프트웨어 개발 208
9.7 통합 테스트 214
1) 해석상의 에러 216
2) 인터페이스 에러 217
시스템 차원의 테스트
10.1 개요 220
10.2 기능 테스트 222
10.3 시스템 테스트의 유형 224
1) 시스템이 운 목적에 적합한지 여부 226
2) 시스템을 수정하기 쉬운지 여부 228
CO
NT
EN
TS
13
PART ��
09
소프트웨어테스트의수행
CHAPTER
10CHAPTER
3) 시스템의 상호운용 가능성 229
4) 시스템의 운 지원 용이성 230
5) 기타 시스템 테스트 항목 232
10.4 신뢰성 테스트 232
1) 구현상의 결함으로 인한 고장 233
2) 허용되지 않은 입력에 의한 고장 233
3) 비정상적인 작동 조건으로 인한 고장 235
4) 가용 메모리 부족 또는 메모리 훼손에 의한 고장 236
10.5 인도 직전의 테스트 237
10.6 인도 이후의 테스트 238
회귀 테스트
11.1 개요 240
11.2 회귀 테스트 전략 241
11.3 회귀 테스트 절차 242
11.4 회귀 테스트 케이스 선별 방법 243
1) 슬라이싱 기법 243
2) 데이터 흐름 기법 243
3) 클러스터 식별 기법 244
4) System Dependence Graph 기법 244
5) Firewall 기법 244
11.5 회귀 테스트 시스템 244
소프트웨어 테스트 관리와 품질 보증
12.1 개요 248
12.2 소프트웨어 결함 관리 249
12.3 테스트 인력 관리 255
12.4 소프트웨어 테스트 계획 수립 257
12.5 독립적 테스팅 261
12.6 소프트웨어 품질 보증 263
12.7 검증과 확인 265
CO
NT
EN
TS
14
11CHAPTER
12CHAPTER
결함 기반 테스팅
13.1 개요 270
13.2 변종 분석법 271
13.3 변종 분석의 비용 절감 기법 275
13.4 변종 분석 시스템 277
객체 지향 소프트웨어 테스팅
14.1 개요 280
14.2 객체 지향 시스템의 테스팅 차원 281
14.3 클래스 테스팅 282
14.4 상속 관계의 테스팅 285
14.5 컴포넌트 소프트웨어 테스팅 286
실시간 임베디드 소프트웨어 테스팅
15.1 개요 290
15.2 실시간 시스템 테스팅 292
15.3 임베디드 소프트웨어 테스팅 293
■ 연습문제 295
■ 참고문헌 307
■ 찾아보기 317C
ON
TE
NT
S
15
PART ��
13
소프트웨어테스팅의고급과제
CHAPTER
14CHAPTER
15CHAPTER
��CHAPTER 소프트웨어 품질과 테스팅
��CHAPTER 소프트웨어 테스팅이란?
��CHAPTER 소프트웨어 테스트 프로세스
��CHAPTER 소프트웨어 정적 분석 기법
�� PART
소프트웨어테스팅의기본개념
1.1 개요
1.2 소프트웨어 품질 요소
1.3 소프트웨어 결함의 예방
1.4 테스팅이 어려운 이유
C HA P
T ER
��소프트웨어 품질과 테스팅
우리 주변에 컴퓨터가 등장한 이래 다양한 소프트웨어가 끊임없이 개발되어
여러 용도로 사용되어 왔다. 처음에는 전혀 예상하지 못한 일을 척척 해내는 소
프트웨어의 능력이 경외의 상이었다. 이제까지는 생각조차 않았던 문제도 점
차 소프트웨어로 해결되고 따라서 일을 처리하는 능력은 놀라울 정도로 향상되
었다. 물론 구현된 소프트웨어가 오작동을 일으키는 수도 있었지만 사람들은 이
러한 문제를 수롭지 않게 여기고 어려운 일을 능률적으로 처리해내는 소프트
웨어의 능력에 감탄할 뿐이었다.
그러나 더 많은 소프트웨어가 개발되고 소프트웨어의 응용 역 또한 꾸준히
확장됨에 따라 소프트웨어의 구현은 점점 어려워지게 되었고 개발자의 실수는
늘어나게 되었다. 개발자의 실수로 유발된 오작동의 빈도도 늘어날 수밖에 없었
고 오작동에 한 사람들의 참을성도 한계에 도달하기 시작하 다. 사람들은 차
츰 소프트웨어가 일을 제 로 해내길 바라게 되었다.
그럼에도 불구하고 소프트웨어의 응용 역은 끝을 모르고 확장되었고 꾸준
히 전혀 새로운 역의 문제에 한 소프트웨어 해결책을 모색하게 되었다. 결국
최근에 개척된 새로운 응용 역에서는 소프트웨어의 결함으로 인하여 막 한
경제적 손해가 유발되거나 인명 손실로 이어지는 사례가 빈번히 발생하고 있다.
특히 소프트웨어가 실시간 임베디드 시스템 등의 중요한 요소로 자리잡음에
따라 시스템 전체의 평판이 소프트웨어의 정상적인 작동에 좌우되는 사례가 증
가하고 있다. 따라서 소프트웨어의 품질에 한 요구가 현저히 높아가고 있으며
머지 않아 소프트웨어 품질이 시스템 전체의 결정적인 성공 기준이 될 것으로
20
��CHAPTER
소프트웨어 품질과 테스팅
1.1 개요
예상되고 있다.
최근에 소개된 어느 자료에 따르면 미국 국방성이 개발하는 시스템에서 소프
트웨어 테스팅의 평균적인 투자 비 효과(ROI; Return On Investment)는
800%로 나타나고 있다. 이 수치는 개발 완료된 소프트웨어 시스템이 실제 운용
에 들어간 후에 결함이 발견되었을 때에 이 결함을 수정하는 비용과 결함이 유
발한 비용 손실을 합한 비용을 테스팅 과정에서 검출할 수 있었다고 가정할 때
의 테스팅 비용과 비교하여 얻어진 값이다. 물론 이와 같은 방식으로 소프트웨
어 테스팅의 투자 비 효과를 산정하는 것은 무리라는 이론이 있지만 적어도
이 수치는 소프트웨어 테스팅의 중요성을 확인해 주고 있다.
소프트웨어 품질을 원하는 수준으로 유지하려면 소프트웨어 제작 과정에서
결함이 소프트웨어에 유입되지 않도록 노력하는 것이 중요하다. 최근의 개발 현
장에서는 소프트웨어의 결함을 사전에 예방하기 위하여 최신 소프트웨어 개발
기법을 적용하고 있으며 일반적인 공학 분야에서 널리 사용되고 있는 품질관리
기법을 도입하여 나름 로의 성과를 거두고 있다.
그러나 일단 소프트웨어에 유입된 결함을 제거하는 데에는 소프트웨어 테스
팅이 거의 유일한 수단이다. 그뿐 아니라 소프트웨어 테스팅은 구현된 소프트웨
어를 제어 가능하고 실제 운용 환경에 가까운 상황하에서 실행시켜 정상적 작동
여부를 확인해 볼 수 있다는 점에서 다른 어떠한 품질확인 방법이 가질 수 없는
장점을 보유하고 있다.
소프트웨어 테스트 기술은 요구 분석, 설계, 프로그래밍 등의 다른 개발 기술
에 비하여 늦게 관심을 두게 되었고 따라서 기술 수준이 낮고 체계적인 연구가
미흡한 실정이다. 그러나 품질이 낮은 소프트웨어는 이용자에게 불편을 주는 것
은 물론, 막 한 재산상의 피해를 입히고, 나아가서는 인명 및 국가 안보에까지
도 지 한 향을 끼칠 수 있기 때문에 보다 완벽한 테스팅이 요구되고 있다.
조사에 따르면 테스팅은 소프트웨어 개발 비용의 50퍼센트 이상을 점유한다
고 하는데 이 비율은 임베디드 소프트웨어나 안전성이 중요시되는 소프트웨어
의 경우에는 더욱 높아질 것으로 예상된다. 그리고 소프트웨어가 사용자에게 인
도된 후에도 뒤늦게 결함이 발견된다든지 운 중인 소프트웨어에 새로운 기능
을 추가한다든지 기능의 일부를 개선하기 위한 수정을 한 후에 이를 확인하기
위해서도 테스팅을 해야 하므로 이러한 작업까지 포함하면 이 비율은 전체 비용
의 3분의 2에 달할 것으로 추정되고 있다.
21
��CHAPT
ER소프트웨어 품질과 테스팅
그런데 테스팅 비용이라는 것은 따지고 보면 개발 작업이 잘못된 것을 바로
잡는 비용으로 볼 수 있기 때문에 결국 낭비되는 비용으로 여겨지는 것이 현재
의 실정이기도 하다. 따라서 처음부터 개발 작업이 정 하게 진행되는 것이 소
프트웨어 개발 비용을 줄이는 지름길이 될 것이다. 개발 작업이 정 하게 진행
되려면 개발 프로세스가 정 하게 정의되어야 하지만 무엇보다도 중요한 것은
개발자의 자질이다. 적절한 개발 기술을 갖추고 개발 프로세스를 충분히 이해하
는 사람이 개발에 참여해야 하는 데 소프트웨어 분야에서는 이점이 소홀히 되고
있다. 이 부분이 개선되지 않고 소프트웨어 품질 향상을 테스팅의 노력에 의존
하는 것은 한계가 있을 수밖에 없다.
테스트 과정에 더 많은 시간과 노력이 투입되고 있고 이에 그치지 않고 모든
개발 단계에서 에러를 방지하기 위한 보다 엄 한 각종 예방책이 투입되고 있
다. 새로 소개되는 개발 기술은 생산성 제고에 기여하는 것도 중요하지만 품질
향상에 기여할 수 있는 기술이 우수한 기술로 평가되고 있다. 또한 테스트의 부
담을 줄여줄 수 있는 개발 기법도 꾸준히 도입되고 있다. 따라서 소프트웨어 테
스트 작업은 구현 다음 단계의 작업에 국한되지 않고 생명 주기 전반에 걸쳐 꾸
준히 관심을 두어야 하는 작업으로 인식되고 있다.
예컨 소프트웨어 개발 작업은 어떤 면에서는 소프트웨어에 한 단편적인
요구가 명세서의 형태로, 이것을 바탕으로 설계가 이루어지고 설계에 의거하여
코드가 작성되는 일련의 정보 변환 작업이다. 따라서 한 형태의 정보를 다른 형
태의 정보로 변환하는 작업을 그르치면, 몇 단계의 변환 작업을 거친 후에는 문
제가 발생되어도 문제의 원인을 추적하여 시정하는데 많은 시간과 노력이 필요
하게 된다. 실제로 통계에 의하면 소프트웨어 에러가 초기 단계의 정보 취급 과
정 즉 요구 정의 및 설계 과정의 소홀함에 기인한 바가 큰 것으로 나타나고 있
다.([그림 1-1] 참조)
22
��소프트웨어 테스팅의 기본 개념PA
RT
[그림 1-1] 소프트웨어 개발 단계별 에러 발생 비율
개발 작업 단계별 에러 수정 비용을 보이는 [그림 1-2]는 초기의 개발 단계에
서 에러가 끼어 들지 않도록 유의하고 또한 가능하면 앞 단계에서 에러를 추출
해 내어야 함을 알려주고 있다.
테스트를 끝으로 개발이 완료되어 소프트웨어가 운 되기 시작해도 에러를
제거하는 작업은 생명주기의 마지막 순간까지 계속된다. 그러나 이때에는 개발
팀도 해체된 상태이고 많은 경우에는 코드의 내용과 일치하지 않는 부실한 문서
에 의존할 수밖에 없기 때문에 테스트 데이터를 준비하고 테스트 환경을 재구성
하는 일은 매우 어려운 작업이 된다.
[그림 1-2] 소프트웨어 개발 단계별 에러 수정 비용
1000
500
200
100
100
50
20
10
Requirements
SAFEGUARD
80%Median(TRW survey)20%
GTE
IBM-SSD
Design Code DevelopmentTest
AcceptanceTest
Operation
Smaller Software Projects
Larger Software Projects
Re cost to flx e
rror
� (Boehm. 1980)2
1
23
��CHAPT
ER소프트웨어 품질과 테스팅
테스팅은 개발된 소프트웨어가 의도한 로 작성되었는가를 컴퓨터상의 실
행을 통하여 확인하는 작업이다. 따라서 일반적으로 소프트웨어를 실행시킬 때
와 마찬가지로 테스트하려는 소프트웨어에 적절한 입력을 주어 실행시킨 다음
에 얻어지는 출력을 살펴보는 식으로 진행된다. 그러므로 테스팅에 사용되는 입
력은 일반적인 실행의 경우와 달라서 원하는 출력을 얻기에 필요한 입력이 아니
라 결함을 검출하기에 편리한 입력이 되어야 한다. 테스팅에 최적인 입력값을
찾아내는 작업을 테스트 설계라고 부른다.
소프트웨어가 의도한 로 작성되었는가를 테스트하기 위해서는 실행을 통
해서 얻어진 결과가 의도했던 내용과 일치하는지를 조사해보아야 한다. 의도한
내용은 보통 소프트웨어 명세서 형태로 정리되고 개발자가 이를 보고 개발한다.
그러므로 테스팅이 제 로 이루어지려면
1. 명세서가 반드시 존재해야 하고
2. 의도한 내용이 명세서에 빠짐없이 정확하게 반 되어야 하고
3. 명세서 내용이 충분히 상세해서 개발자가 이 내용을 정확히 코드에 반 할
수 있어야 한다.
명세서가 존재하더라도 명세서가 사용자의 요구사항을 충실히 반 한다는
보장이 없다. 소프트웨어 명세서는 고객 또는 사용자의 요구사항을 작성자가 문
서로 반 한 것이다. 따라서 명세서에는 요구사항을 제 로 반 하지 않은 부
분, 내용이 다른 부분, 개발자가 달리 해석한 부분이 존재한다. 이럴 경우 실행
결과가 명세서와 일치한다고 해도 코드가 사용자의 의도를 제 로 반 한 것이
라고 할 수 없다. 사용자의 요구사항을 명세서에 정확히 수록하여 개발자가 그
내용을 코드에 충실하게 반 할 수 있도록 하는 것은 요구명세 단계의 책임이
다. 테스팅에서는 이 작업이 제 로 이루어졌다고 가정한다.
테스터는 명세서 내에서 코드에 응되는 부분을 해석하여 이 내용을 테스트
케이스 형태로 표현한 다음에 코드에 하여 테스트 케이스를 실행시켜 얻은 결
과가 올바른지를 확인한다. 자연어 형태로 작성되어 있는 명세서의 내용을 구체
적이고 정량적인 테스트 케이스로 표현하는 작업은 어려울 뿐 아니라 그 작업
자체에도 실수가 따른다. 그러나 반드시 유념해야 하는 것은 일반적인 테스팅에
서는 시간적 제약 때문에 유한 개의 테스트 케이스를 사용할 수밖에 없다는 사
24
��소프트웨어 테스팅의 기본 개념PA
RT
실이다. 그러므로 유한 개의 모든 테스트 케이스에 하여 올바른 실행 결과를
얻었다고 할지라도 소프트웨어가 명세서와 일치하게 작성되었다고 단언할 수
없다. 따라서 유한 개의 테스트 케이스가 명세서에 최적의 근사치가 되도록 하
는 것이 테스트의 기술이라고 할 수 있다.
실행 결과가 명세서의 내용과 일치하는 지를 판단하려면 실행결과를 비교할
수 있는 다른 수단이 존재해야 한다. 즉 명세서로부터 다른 방법을 통하여 얻어
진 값(옳다고 믿을 수 있는 값)과 실행을 통하여 얻어진 값이 일치해야 한다. 오
라클(Oracle)이라고 부르는 이 값은 쉽게 얻을 수 있는 경우도 있지만 많은 경
우에는 확보하기가 매우 어렵거나 뚜렷한 오라클이 존재하지 않는 경우도 있다.
오라클 확보가 어렵거나 오라클과의 비교가 기계적으로 이루어질 수 없는 경우
에는 테스트에 사용할 테스트 케이스를 제한해야 하는 경우도 발생한다. 테스팅
을 하려면 오라클이 존재해야 하므로 손쉽게 확보할 수 있고 결과의 자동 비교
가 가능한 오라클을 확보하는 것이 테스트의 주요 과제 중의 하나이다.
테스팅 작업은 확보한 테스트 케이스를 실행시키고 실행 결과를 통하여 소프
트웨어가 의도한 로 작동하는지를 확인하는 작업이다. 따라서 테스팅 작업은
비슷한 작업이 수없이 반복되고 정 하게 진행되어야 한다. 그러므로 작업의 자
동화가 어느 개발 작업보다도 중요하다. 그러나 유감스럽게도 테스트 케이스 설
계와 오라클 확보는 자동화가 어려운 작업이다. 따라서 최소한 테스트의 실행이
라도 최 한 자동화가 이루어지도록 노력해야 한다.
소프트웨어 품질의 좋고 나쁨을 판단하는 기준은 상당히 다양하다. 소프트웨
어가 고객을 만족시킬 수 있으면 일단 그 소프트웨어는 품질이 좋은 소프트웨어
라고 말할 수 있을 것이다. 사용자를 만족시키려면 우선 소프트웨어에 해 요
구되는 기능을 두루 갖추어야 할 것이다. 그리고 고객이 필요로 하는 때에 맞춰
소프트웨어가 완성되거나 구입 가능해야 할 것이다. 그러나 개발 또는 구입 비
용이 너무 높으면 아무리 기능이 훌륭해도 소비자는 만족하지 않을 것이다. 적
25
��CHAPT
ER소프트웨어 품질과 테스팅
1.2 소프트웨어품질요소
정한 가격이어야 고객은 기꺼이 소프트웨어에 수반되는 비용을 지불하려 할 것
이다.
기능이 아무리 훌륭해도 결함이 많은 소프트웨어는 품질이 좋다고 말할 수
없다. 따라서 명세서의 내용과 일치하도록 소프트웨어가 구현되어야 한다. 그러
나 구현된 소프트웨어가 명세서와 일치하는지를 판단하는 것은 기술적으로 매
우 어려울 뿐 아니라 명세서가 사용자의 요구 사항을 완전하게 반 했다는 보장
이 없다. 명세서가 사용자의 요구 사항을 정확하게 반 할 수 있도록 소프트웨
어 공학에서는 많은 노력을 기울이고 있으며 이것을 전문적으로 다루는 소프트
웨어 요구 공학이라는 분야가 따로 있기까지 한다.
또한 비록 명세서와 일치하는 소프트웨어라도 사용자가 고품질 소프트웨어
로 인식하지 않는 경우도 존재하며 이와 반 로 비록 명세서와 완전히 일치하지
않으나 사용자가 유용한 소프트웨어로 생각하는 경우도 존재한다.
이와 같이 소프트웨어의 품질을 명확하게 정의하기 어렵기 때문에 소프트웨
어 품질을 나타낼 수 있는 요소를 다각적으로 고려하여 정의한 다음에 개발된
소프트웨어가 요구되는 품질 요소를 갖추고 있는지를 개별적으로 조사해 보고
이를 토 로 소프트웨어의 품질을 결정하는 방법이 널리 사용되고 있다.
McCall은 소프트웨어의 품질 요소를 1)소프트웨어가 운 에 적합한지 여부
를 판단할 수 있는 품질 요소, 2)소프트웨어를 변경하기에 편한 정도를 나타내
는 품질 요소, 3)구현된 소프트웨어를 다른 목적에 사용하기 편한 정도를 나타
내는 품질 요소 등으로 분류하고 각 분류에 포함되는 세부 품질 요소를 정의하
다. 아래에서는 McCall이 정의한 세부 품질 요소를 간단히 소개한다.
1) 운 상 적합성 여부를 나타내는 품질 요소
개발된 소프트웨어가 운 에 사용해도 될 정도인지, 즉 고객에게 인도할만한
지를 판단할 수 있는 품질 요소이다.
정확성(correctness)
구현된 소프트웨어가 명세서와 일치하는 정도를 나타낸다.
26
��소프트웨어 테스팅의 기본 개념PA
RT
신뢰성(reliability)
구현된 소프트웨어가 고장을 일으키는 일 없이 작동하는지를 나타낸다. 정확
하게 구현된 소프트웨어라도 예기치 않은 상황에서는 고장이 발생할 수 있다.
따라서 명세서에 기술되어 있지 않은 예기치 않은 상황에서 기능 저하가 발생하
더라도 가능한 한 오랜 시간 동안 서비스를 지속할 수 있는 소프트웨어가 우수
한 것으로 평가 받고 있다. 소프트웨어가 유효하지 않은 입력이나 부하를 받고
도 제 로 작동하는지를 나타내는 강건성(robustness)도 이와 관련이 많다. 다
음 고장시까지의 평균 연속작동 시간(MTTF; mean time to failure)이 신뢰성
의 척도로 사용된다. 높은 신뢰도를 보유하려면 시스템에 결함이 존재하더라도
고장을 회피할 수 있는 능력(maturity), 결함이나 명시된 인터페이스가 저해될
지라도 정해진 수준의 성능을 유지할 수 있는 능력(fault tolerance), 고장이 발
생한 경우에 정해진 수준의 성능을 회복하고 고장에 직접 향을 받은 데이터를
복원할 수 있는 능력(recoverability)이 갖추어져야 한다.
성능(efficiency, performance)
주어진 기능을 얼마나 능률적으로 처리하는지를 나타낸다.
무결성(integrity, security)
인가받지 않은 사용자가 소프트웨어나 데이터에 접근하는 것을 적절히 제어
할 수 있는지를 나타낸다.
사용편의성(usability)
사용자가 어려움 없이 소프트웨어를 적절히 작동시킬 수 있는지를 나타낸다.
2) 변경하기 쉬운지를 나타내는 품질 요소
운 에 들어간 후에도 운 중에 새로이 발견된 결함을 제거하기 위해서, 새로
운 기능을 추가하기 위하여, 또는 달라진 운 환경에 적응시키기 위하여 소프트
웨어에는 꾸준히 수정이 가해진다. 따라서 소프트웨어가 변경을 가하기 쉽도록
구현이 되면 소프트웨어의 유용성은 높아지고 소프트웨어의 수명은 연장된다.
27
��CHAPT
ER소프트웨어 품질과 테스팅
유지보수성(maintainability)
발견된 결함을 수정하는 데 필요한 노력의 정도를 나타낸다.
융통성(flexibility)
운용 중의 소프트웨어를 변경하는 데 필요한 노력의 정도를 나타낸다.
시험가능성(testability)
소기의 기능을 제 로 수행하는지를 확인하는 데 소요되는 노력의 정도를 나
타낸다.
3) 활용도를 높이기 쉬운지를 나타내는 품질 요소
유용성이 입증되고 융통성을 갖춘 소프트웨어는 새로운 하드웨어 환경에 옮
겨 사용하기도 하고 다른 소프트웨어와 연계하여 사용하기도 하고 소프트웨어
의 전부 또는 일부를 다른 시스템의 일부로서 재사용하기도 한다. 이것이 가능
하면 소프트웨어의 가치는 더욱 높아진다.
이식성(portability)
다른 동작 환경에서 제 로 작동하도록 하는 데 소요되는 노력의 크기를 나
타낸다.
재사용가능성(reusability)
소프트웨어의 전부 또는 일부를 얼마나 쉽게 다른 용도로 사용할 수 있는지
를 나타낸다.
상호운용성(interoperability)
얼마나 쉽게 다른 소프트웨어와 결합하여 사용할 수 있는지를 나타낸다.
최초의 운용 목적에 부합되도록 구현된 소프트웨어가 체로 우수한 소프트
웨어이다. 이를 위해서 정확성, 신뢰성, 성능, 무결성, 사용편의성 등을 갖추어
28
��소프트웨어 테스팅의 기본 개념PA
RT
야 한다. 최초의 운용 목적에 사용하는 데에는 문제가 없더라도 소프트웨어에는
여러 가지 이유로 변경이 가해진다. 변경이 용이할수록 소프트웨어의 유용성은
그만큼 증가한다. 변경이 쉽도록 구현되려면 유지보수성, 융통성, 시험가능성
등이 좋아야 하는데 그러려면 소프트웨어의 설계에 처음부터 그러한 특성이 반
되어야 한다. 변경의 수요가 어느 정도 충족된 후에는 소프트웨어는 사용자의
요구에 부응하면서 상당 기간 안정적으로 사용된다. 그리고 소프트웨어에 만족
한 사용자는 그 소프트웨어를 다른 작동환경에 이식해서 사용하거나, 기능의 일
부를 다른 용도로 재사용하거나 다른 소프트웨어와 더불어 사용하고 싶은 욕심
을 갖기 시작한다. 소프트웨어가 이식성, 재사용가능성, 상호운용성 등을 갖추
면 사용자의 새로운 요구에 능히 부응할 수 있고 따라서 소프트웨어의 수명은
그만큼 연장된다.
한편 R. L. Glass는 소프트웨어의 품질이 아예, 이식성, 신뢰성, 능률
(efficiency), 사용편의성, 검사용이성(testability), 이해도(understandability),
수정용이성(modifiability) 일곱 가지 속성의 집합으로 규정된다고 말하고 있
다. 이 중에서 특히 눈에 띄는 것은 검사용이성, 이해도, 수정용이성 등 소프트
웨어의 유지 보수와 관련되는 품질 요소가 세 가지나 포함되어 있다는 사실이
다. Glass는 현 적 개발 기법을 적용하여 제 로 구현된 소프트웨어는 수정할
필요성이 적어질 것이라는 통념과 달리 훌륭한 소프트웨어일수록 꾸준한 변경
을 통하여 새로운 환경, 새로운 응용 역으로 유용성을 키워나가는 경향이 있
음에 주목하 다. 따라서 변경이 가해진다는 것은 소프트웨어에 그만한 가치가
있음을 입증하는 것이고 이 사실은 소프트웨어의 중요한 특성의 하나라고 지적
하 다.
한편 Freeman은 소프트웨어의 품질 요소를 기본적인 품질 요소와 부가적인
품질 요소로 구분하 다. 즉 소프트웨어는 기본적으로 요구되는 기능을 제 로
갖추고(functionality), 신뢰할만하고(reliability), 사용하기에 편하고
(usability), 안전성이 있고(safety), 가격이 적정해야 한다고 하 다. 부가적으
로 소프트웨어는 융통성이 있고 수리하기 쉬워야 하고 새로운 환경에 적용하기
쉬워야 하고 이해하기 쉬우며 새로운 기능을 추가하기 쉽고 문서화가 잘 되어
있어야 한다고 지적하 다. 특히 적정한 가격을 소프트웨어의 중요한 품질 요소
의 하나로 포함시킨 것은 소프트웨어의 실용성을 강조한 것이다.
최근에는 소프트웨어의 응용이 크게 확장되어 소프트웨어의 안전성이 중요
29
��CHAPT
ER소프트웨어 품질과 테스팅
시되기에 이르 다. Freeman도 이미 기본적인 품질 요소의 하나로 안정성을
꼽았지만 이 품질 요소의 중요성은 점차로 커질 것으로 예상된다.
안전성(safety)
의도한 기능의 수행 여부와 관계없이 인명의 손실, 직업병, 장비나 재산의 손
실, 환경 피해 등의 위험한 사태(mishap)를 초래하는 조건이 발생하지 않도록
하는 시스템의 능력을 가리킨다. 모든 소프트웨어 에러가 안정성 문제를 일으키
는 것도 아니며 명세서 로 작동하는 소프트웨어라고 안전한 소프트웨어라고
할 수도 없다. 신뢰도를 위해서는 고장이 발생하지 않도록 해야 하며 안전성을
위해서는 위험한 사태를 방지할 수 있어야 한다. 소프트웨어의 응용 역이 확
장되고 많은 응용 분야에서 소프트웨어의 역할이 점점 더 중요해짐에 따라 소프
트웨어의 안전성이 크게 요구되고 있다.
안전성과 관련하여 보안성이 높고, 안정성, 신뢰성을 두루 갖춘 시스템을 의
존할만하다(dependable)고 말하기도 한다
위에서 살펴본 바와 같이 소프트웨어의 품질을 규정짓는 요소들의 수효는 상
당히 많다. 이상적으로는 어느 소프트웨어 시스템이든지 위에 열거한 모든 소프
트웨어 품질 요소를 두루 갖추는 것이 바람직하겠지만 이것은 쉬운 일이 아니며
공학적 측면에서 바람직하지도 않다. 현실적으로는 개발하고자 하는 소프트웨
어에 우선적으로 요구되는 품질 요소가 무엇인지를 파악하는 것이 중요하다. 그
것을 알면, 소프트웨어를 설계할 때 또는 테스트를 계획할 때에 소프트웨어가
요구되는 품질 요소를 갖추었는지를 확인할 수 있을 것이다.
어느 시스템이든지 정확성과 신뢰성은 기본적으로 요구된다고 볼 수 있다.
동일한 품질 요소라도 어떠한 소프트웨어 유형을 논의하느냐에 따라 중요성이
현저하게 달라질 수 있다.
급여시스템의 경우를 예로 들면 금전을 다루므로 우선 급여 처리 결과가 정
확해야 하고 금전적 손해가 발생할 가능성이 적어야 하며 시스템의 보안이 확보
되어야 하고 급여 체계나 세제의 변화에 능률적으로 응할 수 있어야 한다. 그
러나 급여시스템은 시스템에 익숙한 사람이 운 하는 것이 보통이므로 사용편
의성 등은 덜 강조된다. 그리고 오프라인으로 작동시키는 것이 보통이므로 요구
되는 성능에도 융통성이 있다고 볼 수 있다.
널리 활용되고 있는 비디오 여시스템의 경우에는 시스템을 수정할 필요는
30
��소프트웨어 테스팅의 기본 개념PA
RT
그다지 없을 것으로 예상되고 성능, 신뢰도나 안정성에 한 요구도 높지 않다.
비전문적인 사용자가 사용하는 시스템이므로 사용편의성이 높아야 하겠지만 비
교적 간단한 기능을 반복해서 사용하는 시스템이므로 사용편의성이 약간 떨어지
더라도 사용법을 익히면 큰 불편은 없을 것이다. 그러나 소규모 점포의 업무에
사용할 것이므로 적정한 가격이 가장 우선적으로 고려되는 품질 요소일 것이다.
소프트웨어 품질을 높이려면 철저한 테스팅을 통하여 결함을 최 한 제거해
야 하지만 그보다 더 중요한 일은 결함이 소프트웨어에 잠입하지 않도록 노력하
는 일이다. 결함 예방의 최선책은 소프트웨어 개발에 최신 소프트웨어 공학 기
법을 적용하는 방법이다. 그러면 개발 과정에서 실수를 현저하게 줄 수 있을 뿐
아니라 여러 면에서 테스팅 작업에 도움을 준다.
최근에 널리 활용되고 있는 구조적 프로그래밍의 예를 들어 보자. 구조적 프
로그래밍 기법은 소프트웨어가 바람직한 구조를 갖도록 도와 주고 그 구조가 쉽
게 드러나게 도와 준다. 구조가 드러나면 프로그래머는 자신이 작성한 프로그램
을 잘 이해할 수 있고 따라서 실수를 저질 어도 결함을 바로 발견할 수가 있다.
또한 구조가 뚜렷이 드러나기 때문에 코드를 충분히 커버할 수 있는 테스트
케이스를 쉽게 도출할 수 있다. [그림 1-3]에 실린 간단한 포트란 프로그램의 예
를 가지고 이 점을 확인해 보자. 참고로 이 프로그램에 나오는 산술적 if문
IF(expression) s1, s2, s3은 expression의 값이 0보다 작으면 s1, 0이면 s2, 0
보다 크면 s3를 실행한다.
31
��CHAPT
ER소프트웨어 품질과 테스팅
1.3 소프트웨어결함의예방
IF ( TOTAL - 19 ) 20, 20, 10
10 RESULT = 'YES'
GOTO 50
20 IF ( TOTAL - 9 ) 40, 40, 30
30 RESULT = 'MAYBE'
GOTO 50
40 IF ( TOTAL - 0 ) RESULT = 'NO'
50 CONTINUE
[그림 1-3] 좋은 구조를 갖추지 못한 프로그램의 테스팅
우선 이 프로그램은 이해하기도 어렵고 제어 흐름을 쫓아 가기도 쉽지 않다.
따라서 테스트를 위한 경우의 수를 따져 보기가 쉽지 않아 테스트해야 할 경우
를 빠뜨릴 가능성이 있다.
그런데 이 프로그램을 구조적 프로그래밍 기법을 적용하여 작성하면 [그림
1-4]와 같은 모습이 된다. 이 프로그램은 제어 흐름의 구조가 뚜렷이 드러나 있
기 때문에 모든 경우를 어김없이 조사해 볼 수 있다.
실제로 H. D. Mills는“구조적 프로그래밍 출현으로 말미암아 프로그래밍이
명세서의 내용을 프로그램으로 구성하는 공적이고 엄 한 활동이 되었다. 이제
프로그래머 자신의 검증 작업이 신뢰할 만해서 통상적인 컴퓨터를 통한 디버깅
작업을 체할 수준이 되었다.”고 말하 다. 이것은 최신 개발 기법이 실수 예
방에 크게 공헌하고 있음을 지적한 말이다.
int total;
String result;
if ( total > 19 )
result = 'yes';
else if ( total > 9 )
result = 'maybe';
else
result = 'no';
[그림 1-4] 좋은 구조를 갖춘 프로그램의 테스팅
32
��소프트웨어 테스팅의 기본 개념PA
RT
또 하나의 예는 모듈화 설계 기법이 모듈에 한 테스팅의 노력을 크게 덜어
준다는 사실이다. 모듈의 크기가 크면 한 모듈에 포함되는 프로그램 문장수가
많아지고 따라서 모듈 내의 경로의 수가 큰 폭으로 증가한다. 반 로 모듈의 크
기를 작도록 유지하면 한 모듈 내의 실행 경로수가 현저하게 줄어 든다.
int v, x, y, z;
if ( v > 0 )
S1;
else
S2;
switch (x)
{
case n1:
S3;
break;
case n2:
S4;
break;
case n3:
S5;
break;
default:
S6;
break;}
while ( y > 0 )
S7;
if ( z > 0 )
S8;
else
S9;
[그림 1-5] 크기가 큰 프로그램의 테스팅
[그림 1-5]의 프로그램을 예로 들어 보자. 이 프로그램은 2개의 If-Then
Else 구문과 1개의 While문과 Case문이 포함되어 있다. 이 프로그램에 해서
33
��CHAPT
ER소프트웨어 품질과 테스팅
경로 커버리지를 하려면 While문에 하여 루프를 들어가는 테스트 1개와 들어
가지 않는 테스트 하나만을 포함한다고 해도 최소 32개의 테스팅을 수행해야
한다.
그러나 이 프로그램을 [그림 1-6]과 같이 2개의 작은 모듈로 분해한다면 테
스팅에 소요되는 노력이 절감될 수 있다. 즉, 이 모듈을 테스트하려면 첫 번째
모듈에 하여 8개의 테스트, 두 번째 모듈에 하여 4개의 테스트를 합해서 12
개의 테스트를 하면 된다. 따라서 통합하는 비용을 고려할지라도 테스트의 노력
이 크게 절감됨을 알 수 있다.
int v, x, y, z;
if ( v > 0 )
S1;
else
S2;
switch (x) while ( y > 0 )
{ S7;
case n1:
S3; if ( z > 0 )
break; S8;
case n2: else
S4; S9;
break;
case n3:
S5;
break;
default:
S6;
break;
}
(a) (b)
[그림 1-6] 모듈화 설계와 테스팅의 노력
이 예를 통하여 알 수 있듯이 모듈이 어느 정도 이상 크면 코드 커버리지를
34
��소프트웨어 테스팅의 기본 개념PA
RT
충족시키는 것은 불가능해짐을 알 수 있다. 즉 모듈의 크기가 어느 정도 이상이
되면 충분한 테스트는 사실상 불가능해진다.
소프트웨어 테스트는 순수한 기술적인 어려움도 있지만 테스트를 어렵게 하
는 여러 가지 기술 외적인 이유가 있다. 이 절에는 그러한 어려움을 살펴보기로
한다.
1) 소프트웨어의 복잡도
소프트웨어는 다른 공학 제품과 비교할 때 상 적인 복잡도가 훨씬 높다. 문
제의 복잡도가 높기 때문에 사람들은 소프트웨어를 개발하고 컴퓨터를 사용하
여 문제 해결에 도움을 얻으려는 것이다. 복잡도가 높으면 개발하는 데 노력이
많이 소요될 뿐 아니라 실수를 범하기 쉽다. 따라서 상 적으로 더 많은 테스트
를 위한 노력이 필요하다. 그러나 더욱 문제가 되는 것은 복잡한 소프트웨어는
많은 기능을 포함하고 또한 기능들을 다양하게 조합하여 사용할 수 있도록 구성
된다는 점이다. 그런데 이러한 조합의 수가 워낙 많기 때문에 모든 조합에 하
여 문제가 없는가를 확인하려면 현실적으로 허용되는 작업 시간으로는 개의
경우에 불가능하다.
예를 들면, [그림 1-7]은 어느 워드프로세스 선택 사항을 지정하는 메뉴이다.
사용자는 이 메뉴를 통하여 모두 12가지 선택 사항을 지정할 수 있다.
35
��CHAPT
ER소프트웨어 품질과 테스팅
1.4 테스팅이어려운이유
[그림 1-7] 테스트 항목수
그리고 각각에 하여 Field Shading에 3가지 중의 하나를 선택할 수 있다.
사용자의 모든 선택 가능성에 하여 시스템이 옳게 작동하는가를 확인하려면 실
제로 각 조합을 실행시키고 결과를 확인해야 할 것이다. 그런데 각 옵션이 상호
독립적이라고 가정하여 조합의 수를 계산해 보면 3×212 즉 12288 가지가 된다.
즉 12288번 실행을 시켜 보고 테스트 결과가 옳은지를 확인해야 한다. 이것이 필
요한 테스트의 전부라고 한다면 시간을 내어서 해 볼 수 있겠지만 이 시스템에서
옵션을 설정하는 일은 무수히 많은 사용 가능성의 하나에 지나지 않는다.
일반적인 소프트웨어 시스템에서 테스트해야 할 조합의 수는 너무 많아서 조
합의 전부를 시험할 수는 없다. 따라서 결함 검출 효과를 떨어뜨리지 않으면서
적은 조합을 시험하는 방안을 연구해야 한다.
2) 불완전한 명세의 문제
고객의 시스템에 관한 요구 사항은 명세서로 정리되어 구현할 때 참조하게
된다. 따라서 테스트의 1차적인 목표는 구현된 내용이 명세서와 일치하는지를
점검하는 일이다. 그러나 이것은 요구 사항이 완벽하게 명세서에 반 되었다는
가정 하에서 가능한 일이고 명세서가 불완전하면 결국은 명세서를 보완하거나
구현이 완료된 소프트웨어가 고객의 요구 사항을 반 하고 있는지를 면 하게
36
��소프트웨어 테스팅의 기본 개념PA
RT
Show
Startup Task Pane
Highlight
Bookmarks
Status Bar
Screen Tips
Smart tags Windows in Task Bar
Field Codes
Field Shading:
Field Shading:
Don't show
Show always
When selected ▼
When selected▼
Anim ated Text
Horizontal Screen Bar
Vertical Screen Bar
Picture Placeholders
점검해야 한다. 완전한 명세서를 얻는 것은 요구 공학의 일이고 테스트에서는
일차적으로 명세서를 기반으로 해서 도출한 테스트 케이스를 가지고 시스템을
시험하고 아울러 고객의 요구 사항이 충분히 반 되었는지도 확인해야 한다.
그러나 실질적으로는 완전한 수준에 가까운 명세서가 존재하는 경우는 드물
고 많은 경우에는 부실한 명세서를 가지고 테스트를 해야 한다. 이 경우에는 테
스트 케이스를 도출하는 일 자체가 어렵고 실행 결과를 비교할 예상 결과도 명
세서에서 구할 수 없는 경우도 흔하다. 또한 사용자 지침서 로 소프트웨어가
작동하는지 여부도 검사해야 하는데 사용자 지침서의 작성자가 시스템을 충분
히 이해하지 못한 상태에서 작성한 경우도 있고 아예 명세서와는 무관하게 구현
된 시스템의 작동 상황을 있는 그 로 반 하도록 작성하기도 한다. 따라서 사
용자 지침서의 내용이 명세서와 일치하지 않는 경우가 많을 것은 당연하다.
따라서 테스트에서는 구현된 시스템이 명세서와 일치하는 지를 시험해야 하
고, 시스템이 고객의 요구사항을 제 로 반 하고 있는지를 확인해야 하고, 코
드가 사용자 지침서 로 작동하는지도 점검해야 한다.
3) 테스트를 위한 작동 환경 구축의 어려움
개발에 사용되는 시스템 환경은 완성된 소프트웨어가 실제로 탑재되어 운
될 시스템 환경과 다른 경우가 많다. 이 경우에는 일단 개발에 사용된 시스템 환
경에서 시스템을 시험한 후에 시스템을 실제 환경에 설치한 후에도 문제가 없이
작동하는지를 확인하는 설치 테스트를 수행한다.
개발의 편의상 다른 시스템을 사용하기도 하지만 실제보다 낮은 성능의 컴퓨
터를 사용하거나 실제보다 주변 장치와 같이 운 될 다른 소프트웨어들을 단순
화시킨 상태에서 개발하고 또 시험하는 것이 보통이다. 따라서 시스템 테스트
단계에서는 적어도 한번은 완전한 시스템의 구성을 갖춘 상태에서 시스템을 테
스트 할 필요가 있다.
그러나 테스트 목적에서 완전한 구성을 갖추는 데에는 많은 비용이 소요가
된다. 예를 들어 실제 환경의 금융 시스템의 경우, 수천에서 수만의 금융 터미널
이 시스템에 연결되고 수백 명의 동시 사용자가 있을 수 있다. 이런 경우에도 시
스템이 제 로 작동하는지를 반드시 사전 점검을 할 필요가 있지만 이런 규모의
37
��CHAPT
ER소프트웨어 품질과 테스팅
비용을 테스트에 할애하기는 어렵다고 보아야 한다. 따라서 성공적인 테스트를
위해서는 실제 상황을 체할 수 있는 테스트 환경을 구성할 수 있는 경험과 기
술이 필수적이다.
특히 임베디드 소프트웨어와 같이 소프트웨어가 내장될 시스템이 소프트웨
어와 동시에 개발되는 경우도 많은데 이때에는 하드웨어 시스템 개발이 끝나기
를 기다려서 소프트웨어를 테스트하든지 하드웨어의 모형이나 프로토타입을 가
지고 테스트해야 한다. 그러나 하드웨어 개발이 끝난 후, 소프트웨어를 탑재하
고 테스트할 수 있는 시점은 제품을 출시해야 하거나 고객에게 인도할 시점에
임박하기 때문에 충분한 테스트 시간이 주어지지 않는 것이 보통이다.
예를 들어, 인공위성을 개발할 때에는 인공위성 자체를 개발함과 동시에 인
공위성의 운 을 제어하는 소프트웨어와 개발 목적의 응용 소프트웨어도 개발
하게 된다. 따라서 인공위성 본체의 개발이 끝나기 전에 소프트웨어를 테스트하
려면 훌륭한 시뮬레이터가 존재해야 한다. 결국 테스팅의 성패는 얼마나 훌륭한
시뮬레이터를 제작하느냐에 달려 있다고 할 수 있다.
4) 소프트웨어 고유의 특성에 따른 문제
개발이 완료된 시스템이 실제 운 에 적합한지 여부를 시험하는 하나의 방법
은 빈도가 높을 것으로 예상되는 사용 시나리오의 리스트를 준비하여 이것을 철
저하게 테스트해보는 것이다. 이것은 부분의 공학 제품에서 채택되고 있는 기
법이지만 이러한 방법이 소프트웨어 테스트에는 불충분하다는 사실이 알려져
있다.
즉 소프트웨어에는 특이한 성질이 있어서
첫째, 하찮고 사무적인 실수도 중 한 결과를 초래할 수 있다.
둘째, 아주 드문 경우에나 나타날 수 있는 에러도 소프트웨어에서는 무시할
수 없다는 사실이다.
프로그래머의 큰 실수는 테스트를 통하여 개는 곧바로 검출되지만 사소한
실수는 테스트로도 걸러지기가 어렵다. 그러나 소프트웨어에서 역설적인 사실
은 사소한 실수라고 해서 반드시 결과까지 미미하지는 않다는 것이다.
이러한 예로서 유럽연합이 개발한 발사체인 Ariane 로켓을 들 수 있다. 1996
38
��소프트웨어 테스팅의 기본 개념PA
RT
년에 Ariane 5 로켓이 발사 40초 후에 문제가 발생하여 자체적으로 폭파시켰
는데 문제의 원인을 추적하여 보니 64비트 부동 소수점 수를 16비트 부호가 있
는 정수로 변환하는 과정에서 프로그래머의 사소한 실수 음이 밝혀졌다. 이 실
수로 인하여 로켓의 수평속도가 위험치에 도달한 것으로 계산되고 소프트웨어
의 예외 처리 수단으로 강제 폭파시켰다는 것이다.
다른 하나의 예는 방사선 치료기기이다. 1985년부터 3년 사이에 캐나다의 한
회사가 제작한 의료기기로 치료를 받던 환자 4명이 사망하여 규모의 손해배
상청구 소송이 발생하 다고 한다. 역시 원인을 추적해 보니 치료기 기사가 방
사선의 강도를 조절할 수 있도록 설계되었음에도 불구하고 조절하는 것과 무관
하게 최 치의 방사선을 방출하여 노출과다가 발생한 것으로 밝혀졌다고 한다.
이러한 사실을 뒷받침할만한 사례는 이것말고도 문헌상에 무수히 보고되어
있다.
앞에서도 언급한 바와 같이 주어진 시간의 범위 안에서 우선 순위가 높고 사
용 빈도가 높을 것으로 예상되는 테스트 케이스의 순서로 테스트를 수행하는 것
이 보통이다. 따라서 시간 관계상 발생 확률이 적은 테스트 케이스는 수행시켜
보지도 못하고 테스트를 종료하는 경우가 많다. 부분의 공학 분야의 경우에는
이렇게 해도 큰 문제가 없지만 소프트웨어의 경우에는 반드시 그렇지는 않다는
것이다.
소프트웨어의 많은 사용자들이 비록 드물기는 하지만 시스템에서 가려져 있
는 기능을 시도해 보게 되고 따라서 미쳐 테스트되지 않았던 상태가 실행되어
앞의 경우와 같은 예상치 않은 결과를 초래할 수 있다. 특히 소프트웨어는 실행
속도가 빨라져서 시스템의 다양한 기능이 속속들이 시험될 가능성이 높다.
5) 테스트 마인드의 부재
다른 분야에서도 마찬가지이지만 개발은 시험보다 먼저 진행되기 때문에 관
심이 높고 상 적으로 시험에 해서는 관심이 떨어질 수밖에 없다. 또한 작업
시점이 인도에 임박한 시점이기 때문에 개는 시간에 쫓기며 작업하게 되고 형
편상 도중에 중단되어 계획된 작업을 다하지 못하기도 한다. 테스트에 충분한
시간이 주어지는 일이 없기 때문에 계획하에 체계적으로 작업을 하기 어렵다.
39
��CHAPT
ER소프트웨어 품질과 테스팅
테스트는 고도의 집중을 요하는 작업이고 풍부한 경험과 충실한 훈련을 요하
는 작업임에도 불구하고 능력이 떨어지거나 경험이 부족한 인력이 배치되는 경
우가 많다. 그리고 개발자는 테스터를 존중하지 않고 따라서 테스트 작업에 비
협조적이다. 따라서 일단 테스트 업무에 배치되어도 항상 다른 부서에서 일하기
를 희망하고 의욕은 떨어지게 마련이다.
40
��소프트웨어 테스팅의 기본 개념PA
RT
소프트웨어 테스팅
권용래 지음
초 판 인 쇄 : 2010. 7. 15
초 판 발 행 : 2010. 7. 20
발 행 인 : 김 승 기
발 행 처 : 생능출판사
신 고 번 호 : 제 406-2004-000002호
신 고 일 자 : 2005. 1. 21
I S B N : 978-89-7050-674-6
� � � ─���
경기도 파주시 교하읍 문발리 507-12 파주출판도시표전화 : (031)955-0761, FAX : (031)955-0768
홈페이지 : http://www.booksr.co.kr
� 파본 및 잘못된 책은 바꾸어 드립니다. 정가 27,000원
권용래
KAIST 전산학과 교수 (1983 ~ 현재)
1971 ~ 1974 육군사관학교 교관
1974 ~ 1977 미국 Pittsburgh 학원 졸업(이학박사)
1978 ~ 1983 미국 Computer Sciences Corporation 연구원
1989 ~ 1990 한국정보과학회 소프트웨어 공학 소사이어티 회장
1998 ~ 1999 미국 Maryland 학교 방문교수
2003 한국정보과학회 회장
2006 ~ 2007 삼성전자 자문교수
저 자 약 력
저자와 협약에 의해검인을 생략함