[소프트웨어공학] 소프트웨어 검사

한국어

<h1 id="검사-관련-용어정의">검사 관련 용어정의</h1> <ul> <li><strong>검사</strong>(Testing)<br /> 오류를 찾는 작업</li> <li><strong>검증</strong>(Verification)<br /> 개발된 소프트웨어와 사용자의 요구분석 명세서와의 차이를 확인하는 작업</li> <li><strong>디버깅</strong>(Debugging)<br /> 검사로 찾아낸 오류를 수정하는 작업</li> <li><strong>검토 회의</strong>(Walk-through)<br /> 소프트웨어 생명주기의 단계마다 산출된 명세서를 가지고 다음 단계로 넘어가기 전에 오류를 찾아내는 작업</li> <li><strong>정형 기술 검토</strong>(FTR)<br /> 소프트웨어에 관련된 여러 사람이 모여 회의하는 정형화된 오류 검토 회의</li> </ul> <h1 id="검사방법">검사방법</h1> <h2 id="화이트-박스-검사">화이트 박스 검사</h2> <p>상자 안을 들여다 볼 수 있다는 뜻으로 <strong>원시 프로그램을 직접 보면서</strong> 프로그램 상 허용되는 논리적인 모든 경로를 직접 검사하는 방법</p> <ul> <li>프로그램 모듈의 논리적 구조를 체계적으로 점검하는 구조 검사</li> <li>원시 코드의 모든 문장을 <strong>한 번 이상 수행함</strong>으로써 진행되는 구조 검사</li> <li>검사 대상의 가능한 경로를 어느 정도 통과하는 지의 적용 범위성을 측정 기준으로 한다</li> <li> <p>프로그램의 제어 구조에 따라 <strong>선택, 반복 등의 부분들을 수행</strong>함으로써 논리적인 경로를 검사</p> </li> <li>종류 <ul> <li><strong>기초 경로 검사</strong>(Basic Path Testing)<br /> 모든 논리적인 경로를 복잡도로 계산하여 구한 후 경로를 수행할 수 있는 검사 경우를 직접 입력하여 오류를 검출하는 방법 <blockquote> <p><code class="language-plaintext highlighter-rouge">오일러의 공식</code> : V - E + R = 2<br /> _{V: 노드의 수, E: 간선의 수, R:영역의 수}</p> </blockquote> </li> <li><strong>루프 검사</strong>(Loop Testing)<br /> 반복문 관련 오류 검출</li> <li><strong>데이터 흐름 검사</strong>(Data Flow Testing)<br /> 제어 흐름 그래프에 데이터 사용 현황(정의, 소멸, 사용)을 테스트</li> <li><strong>조건 검사</strong>(Condition Testing)<br /> 조건문 관련 오류 검출</li> </ul> </li> <li>찾을 수 있는 오류 <ul> <li>자세하고 세부적 오류 검출 가능</li> <li>반복문, 참거짓을 판단할 수 있는 논리 구조 상의 오류 검출 가능</li> </ul> </li> </ul> <h2 id="블랙-박스-검사">블랙 박스 검사</h2> <p>상자 안을 볼 수 없다는 뜻으로 원시 프로그램은 보지 않고 프로그램만 실행시켜 데이터 입력에 대한 결과만을 보고 오류를 판단하는 방법</p> <ul> <li>종류 <ul> <li><strong>균등 분할</strong>(Equivalence Partitioning)<br /> 입력 자료에 초점을 맞춰 검사 사례를 만드는 방법.<br /> 타당한 자료와 타당하지 않은 자료의 개수를 균등하게 하여 정함</li> <li><strong>한계값 분석</strong>(Boundary Value Analysis)<br /> 입력조건의 중간값에서 보다 <strong>경계값에서 에러가 발생될 확률이 높다</strong>는 점을 이용하여 이를 실행하는 테스크 케이스를 만드는 방법</li> <li><strong>원인-결과 그래프</strong>(Cause-Effect Graphing)<br /> 입력 데이터 간의 관계가 출력에 미치는 영향을 그래프로 표현하여 오류 검출</li> <li><strong>오류 예측</strong>(Error Guessing)<br /> 각 시험기법들이 놓치기 쉬운 오류들을 감각 및 경험으로 찾아보는 것</li> <li><strong>비교 검사</strong>(Comparison Testing)<br /> 여러 버전의 프로그램에 동일한 검사 자료를 제공하여 동일한 결과가 출력되는 지 비교 및 확인하는 검사</li> <li><strong>페어 와이즈 조합 테스트</strong><br /> 모든 가능한 입력 값들의 조합들을 테스트하는 대신에 모든 Pair의 조합을 테스트하는 방법</li> <li><strong>상태 전이 검사</strong><br /> 시스템의 상태가 변화함에 따른 검사</li> </ul> </li> <li>비정상적인 자료를 입력해도 오류 처리를 수행하지 않은 경우의 오류 검출 가능</li> <li>정상적인 자료를 입력해도 요구된 기능이 제대로 수행되지 않는 경우의 오류를 검출 가능</li> <li>성능 오류, 자료 구조 상의 오류, 인터페이스, 시작과 종결 상의 오류를 찾을 수 있다</li> </ul> <h1 id="검사-순서">검사 순서</h1> <ul> <li>단위(코드) 검사</li> <li>통합(설계) 검사</li> <li>검증(요구사항) 검사</li> <li>시스템 검사</li> </ul> <h2 id="단위-검사">단위 검사</h2> <p>원시 프로그램의 모듈을 대상으로 <strong><code class="language-plaintext highlighter-rouge">화이트 검사</code>를 실시</strong>하는 방법</p> <ul> <li>인터페이스 검사</li> <li>자료 구조 검사</li> <li>경로 검사</li> <li>오류 처리 검사</li> <li>한계값 검사</li> </ul> <h2 id="통합-검사">통합 검사</h2> <p>단위 검사를 성공적으로 실시한 후에 단위별로 <strong>결합하면서 오류를 검출</strong>하는 방법</p> <h3 id="하향식top-down-통합-검사">하향식(Top-Down) 통합 검사</h3> <p>상위 모듈에서 하위 모듈로 결합하면서 오류를 찾는 방법으로 가짜 모듈(<code class="language-plaintext highlighter-rouge">Stub</code>)이 필요하다</p> <ol> <li>전체 프로그램을 매번 실행하고 종속적인 모듈은 <strong>가짜 모듈(Stub)로 대치</strong>한다</li> <li>통합 방법에 따라 가짜 모듈을 <strong>실제 모듈로 대치</strong>한다</li> <li>각 모듈이 <strong>통합되면 검사</strong>를 실시</li> <li>통합될 때마다 <strong>회귀 검사</strong>를 실시</li> </ol> <ul> <li>프로그램 전체를 실행하면서 검사 가능</li> <li>중요 모듈을 우선 검사할 때에는 부적합</li> <li>독립적인 구조로 검사할 수 있다</li> </ul> <h3 id="상향식bottom-up-통합-검사">상향식(Bottom-Up) 통합 검사</h3> <p>최하위의 모듈부터 상위로 진행하면서 통합하는 방식으로 가짜 모듈은 필요없지만 통합 시에 통합된 클러스터(<code class="language-plaintext highlighter-rouge">Cluster</code>)를 실행할 수 있는 시험 가동기(<code class="language-plaintext highlighter-rouge">Driver</code>)가 필요하다</p> <p>_{클러스터 : 여러 개의 모듈을 하나로 묶어 놓은 단위<br /> 드라이버 : 임시로 실행시켜 검사해 보기 위한 임시 프로그램 모듈}<br /><br /></p> <ol> <li>낮은 수준의 모듈들을 클러스터로 <strong>결합</strong></li> <li>검사 사례 입/출력을 조정하기 위해 <strong>드라이버</strong> 작성</li> <li>클러스터 <strong>검사</strong></li> <li>드라이버 제거하고 클러스터를 <strong>상위</strong>로 결합</li> </ol> <ul> <li>중요 모듈을 우선 검사할 때 유리</li> </ul> <h3 id="혼합식mixed-통합-검사">혼합식(Mixed) 통합 검사</h3> <p>하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 검사하는 방법. <strong>샌드위치식 통합 방식</strong>이라고도 한다.</p> <h2 id="검증-검사">검증 검사</h2> <p>소프트웨어가 사용자의 <strong>요구사항을 충족시키는가</strong>에 중점을 두고 검사하는 방법. 요구사항 명세서를 토대로 <strong><code class="language-plaintext highlighter-rouge">블랙 박스 테스트</code>를 사용</strong></p> <ul> <li><strong>형상 검사</strong> : 소프트웨어 구성요소, 목록, 유지보수를 지원하기 위해 필요한 사항 표현 검사</li> <li><strong>알파 검사</strong> : 개발자의 장소에서 사용자가 개발자 앞에서 실행하는 검사</li> <li><strong>베타 검사</strong> : 다수의 사용자를 제한되지 않은 환경에서 프로그램을 사용하게 하고 오류가 발견되면 개발자에게 통보하는 방식</li> </ul> <h2 id="시스템-검사">시스템 검사</h2> <p>개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 검사</p> <ul> <li>확인 검사 : 이해관계가 있는 모든 사람이 참석하여 오류 검출하는 방법</li> <li>보안 검사</li> <li>무결성 검사</li> <li>스트레스 검사</li> <li>부피 검사</li> <li>메모리 검사</li> <li>성능 검사</li> <li>호환성 검사</li> <li>신뢰성 검사</li> <li>회복 검사</li> <li>사용 용이성 검사</li> <li>유지보수 용이성 검사</li> </ul> <h2 id="정형-기술-검토ftr--formal-technical-review">정형 기술 검토(FTR : Formal Technical Review)</h2> <ul> <li>목적 <ul> <li>소프트웨어가 요구사항에 일치되는 정도를 확인</li> <li>소프트웨어가 <strong>표준화되었는지 검토</strong></li> <li>정형화된 소프트웨어가 개발되도록 지원</li> <li>프로젝트 관리</li> </ul> </li> <li>검토 지침 <ul> <li><strong>제품 검토의 집중성</strong> : 수정이 아닌 제품의 검토에 집중</li> <li><strong>사전 준비성</strong> : 검토를 위한 자료를 사전에 배포하여 검토</li> <li><strong>의제의 제한성</strong> : 의견을 제한하되 충분히 받아들인다</li> <li><strong>안건 고수성</strong></li> <li><strong>논쟁 반박의 제한성</strong></li> <li><strong>문제 공개성</strong></li> <li><strong>참가 인원의 제한성</strong></li> <li><strong>문서성</strong> : 발견된 오류는 문서화한다</li> </ul> </li> </ul> <h2 id="오류-증폭-모형">오류 증폭 모형</h2> <p>소프트웨어 개발 생명주기 중 검사 단계에서 오류를 찾는 것보다 <strong>생명주기의 단계마다 확인하고 검사</strong>하면 많은 양의 오류 검출 및 수정이 가능하다.</p> <p>이러한 방법을 <code class="language-plaintext highlighter-rouge">검토 회의</code>(Walk-through)라고 하며 검토 회의를 할 경우에 예측할 수 있는 <strong>오류 감소 비율을 이론적으로 정립한 것</strong>을 <strong>오류 증폭 모델</strong>이라 한다.</p> <blockquote> <p>(전달된 오류수 + 오류 증폭수 + 생성된 오류수) X (100% - 오류 제거 비율)<br /> 오류 증폭수 = (이전 단계에서 전달된 오류수 - 전달된 오류 수) X 오류 증폭 비율</p> </blockquote>

검사 관련 용어정의

• 검사(Testing)
  오류를 찾는 작업
• 검증(Verification)
  개발된 소프트웨어와 사용자의 요구분석 명세서와의 차이를 확인하는 작업
• 디버깅(Debugging)
  검사로 찾아낸 오류를 수정하는 작업
• 검토 회의(Walk-through)
  소프트웨어 생명주기의 단계마다 산출된 명세서를 가지고 다음 단계로 넘어가기 전에 오류를 찾아내는 작업
• 정형 기술 검토(FTR)
  소프트웨어에 관련된 여러 사람이 모여 회의하는 정형화된 오류 검토 회의

검사방법

화이트 박스 검사

상자 안을 들여다 볼 수 있다는 뜻으로 원시 프로그램을 직접 보면서 프로그램 상 허용되는 논리적인 모든 경로를 직접 검사하는 방법

• 프로그램 모듈의 논리적 구조를 체계적으로 점검하는 구조 검사
• 원시 코드의 모든 문장을 한 번 이상 수행함으로써 진행되는 구조 검사
• 검사 대상의 가능한 경로를 어느 정도 통과하는 지의 적용 범위성을 측정 기준으로 한다

• 프로그램의 제어 구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적인 경로를 검사

• 종류
  • 기초 경로 검사(Basic Path Testing)
    모든 논리적인 경로를 복잡도로 계산하여 구한 후 경로를 수행할 수 있는 검사 경우를 직접 입력하여 오류를 검출하는 방법

    오일러의 공식 : V - E + R = 2
    _{V: 노드의 수, E: 간선의 수, R:영역의 수}

  • 루프 검사(Loop Testing)
    반복문 관련 오류 검출
  • 데이터 흐름 검사(Data Flow Testing)
    제어 흐름 그래프에 데이터 사용 현황(정의, 소멸, 사용)을 테스트
  • 조건 검사(Condition Testing)
    조건문 관련 오류 검출
• 찾을 수 있는 오류
  • 자세하고 세부적 오류 검출 가능
  • 반복문, 참거짓을 판단할 수 있는 논리 구조 상의 오류 검출 가능

블랙 박스 검사

상자 안을 볼 수 없다는 뜻으로 원시 프로그램은 보지 않고 프로그램만 실행시켜 데이터 입력에 대한 결과만을 보고 오류를 판단하는 방법

• 종류
  • 균등 분할(Equivalence Partitioning)
    입력 자료에 초점을 맞춰 검사 사례를 만드는 방법.
    타당한 자료와 타당하지 않은 자료의 개수를 균등하게 하여 정함
  • 한계값 분석(Boundary Value Analysis)
    입력조건의 중간값에서 보다 경계값에서 에러가 발생될 확률이 높다는 점을 이용하여 이를 실행하는 테스크 케이스를 만드는 방법
  • 원인-결과 그래프(Cause-Effect Graphing)
    입력 데이터 간의 관계가 출력에 미치는 영향을 그래프로 표현하여 오류 검출
  • 오류 예측(Error Guessing)
    각 시험기법들이 놓치기 쉬운 오류들을 감각 및 경험으로 찾아보는 것
  • 비교 검사(Comparison Testing)
    여러 버전의 프로그램에 동일한 검사 자료를 제공하여 동일한 결과가 출력되는 지 비교 및 확인하는 검사
  • 페어 와이즈 조합 테스트
    모든 가능한 입력 값들의 조합들을 테스트하는 대신에 모든 Pair의 조합을 테스트하는 방법
  • 상태 전이 검사
    시스템의 상태가 변화함에 따른 검사
• 비정상적인 자료를 입력해도 오류 처리를 수행하지 않은 경우의 오류 검출 가능
• 정상적인 자료를 입력해도 요구된 기능이 제대로 수행되지 않는 경우의 오류를 검출 가능
• 성능 오류, 자료 구조 상의 오류, 인터페이스, 시작과 종결 상의 오류를 찾을 수 있다

검사 순서

• 단위(코드) 검사
• 통합(설계) 검사
• 검증(요구사항) 검사
• 시스템 검사

단위 검사

원시 프로그램의 모듈을 대상으로 화이트 검사를 실시하는 방법

• 인터페이스 검사
• 자료 구조 검사
• 경로 검사
• 오류 처리 검사
• 한계값 검사

통합 검사

단위 검사를 성공적으로 실시한 후에 단위별로 결합하면서 오류를 검출하는 방법

하향식(Top-Down) 통합 검사

상위 모듈에서 하위 모듈로 결합하면서 오류를 찾는 방법으로 가짜 모듈(Stub)이 필요하다

1. 전체 프로그램을 매번 실행하고 종속적인 모듈은 가짜 모듈(Stub)로 대치한다
2. 통합 방법에 따라 가짜 모듈을 실제 모듈로 대치한다
3. 각 모듈이 통합되면 검사를 실시
4. 통합될 때마다 회귀 검사를 실시

• 프로그램 전체를 실행하면서 검사 가능
• 중요 모듈을 우선 검사할 때에는 부적합
• 독립적인 구조로 검사할 수 있다

상향식(Bottom-Up) 통합 검사

최하위의 모듈부터 상위로 진행하면서 통합하는 방식으로 가짜 모듈은 필요없지만 통합 시에 통합된 클러스터(Cluster)를 실행할 수 있는 시험 가동기(Driver)가 필요하다

_{클러스터 : 여러 개의 모듈을 하나로 묶어 놓은 단위
드라이버 : 임시로 실행시켜 검사해 보기 위한 임시 프로그램 모듈}

1. 낮은 수준의 모듈들을 클러스터로 결합
2. 검사 사례 입/출력을 조정하기 위해 드라이버 작성
3. 클러스터 검사
4. 드라이버 제거하고 클러스터를 상위로 결합

• 중요 모듈을 우선 검사할 때 유리

혼합식(Mixed) 통합 검사

하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 검사하는 방법. 샌드위치식 통합 방식이라고도 한다.

검증 검사

소프트웨어가 사용자의 요구사항을 충족시키는가에 중점을 두고 검사하는 방법. 요구사항 명세서를 토대로 블랙 박스 테스트를 사용

• 형상 검사 : 소프트웨어 구성요소, 목록, 유지보수를 지원하기 위해 필요한 사항 표현 검사
• 알파 검사 : 개발자의 장소에서 사용자가 개발자 앞에서 실행하는 검사
• 베타 검사 : 다수의 사용자를 제한되지 않은 환경에서 프로그램을 사용하게 하고 오류가 발견되면 개발자에게 통보하는 방식

시스템 검사

개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 검사

• 확인 검사 : 이해관계가 있는 모든 사람이 참석하여 오류 검출하는 방법
• 보안 검사
• 무결성 검사
• 스트레스 검사
• 부피 검사
• 메모리 검사
• 성능 검사
• 호환성 검사
• 신뢰성 검사
• 회복 검사
• 사용 용이성 검사
• 유지보수 용이성 검사

정형 기술 검토(FTR : Formal Technical Review)

• 목적
  • 소프트웨어가 요구사항에 일치되는 정도를 확인
  • 소프트웨어가 표준화되었는지 검토
  • 정형화된 소프트웨어가 개발되도록 지원
  • 프로젝트 관리
• 검토 지침
  • 제품 검토의 집중성 : 수정이 아닌 제품의 검토에 집중
  • 사전 준비성 : 검토를 위한 자료를 사전에 배포하여 검토
  • 의제의 제한성 : 의견을 제한하되 충분히 받아들인다
  • 안건 고수성
  • 논쟁 반박의 제한성
  • 문제 공개성
  • 참가 인원의 제한성
  • 문서성 : 발견된 오류는 문서화한다

오류 증폭 모형

소프트웨어 개발 생명주기 중 검사 단계에서 오류를 찾는 것보다 생명주기의 단계마다 확인하고 검사하면 많은 양의 오류 검출 및 수정이 가능하다.

이러한 방법을 검토 회의(Walk-through)라고 하며 검토 회의를 할 경우에 예측할 수 있는 오류 감소 비율을 이론적으로 정립한 것을 오류 증폭 모델이라 한다.

(전달된 오류수 + 오류 증폭수 + 생성된 오류수) X (100% - 오류 제거 비율)
오류 증폭수 = (이전 단계에서 전달된 오류수 - 전달된 오류 수) X 오류 증폭 비율