[정보처리기능사] chapter 02. 애플리케이션 결함 조치

Part 02. 애플리케이션 테스트 수행 

 

chapter01. 애플리케이션 테스트 수행

 

chapter02. 애플리케이션 결함 조치

 

---

 

1. 결함 (Defect) 

• 프로그램과 명세서 간의 차이, 업무 내용 불일치
• 기대 결과와 실제 관찰 결과 간의 차이

<결함 심각도>

High	프로세스를 진행할 수 없을 정도의 결함 / 시스템 다운
Medium	시스템 흐름에 영향을 미치는 결함 / 보안 관련 오류
Low	상황에 맞지 않는 용도 및 화면구성 결함 / 에러 메세지 미출력

 

 

2. 결함 관리 프로세스

· 결함 관리 프로세스는 애플리케이션 테스트에서 발견된 결함을 처리하는 과정.

· 결함 관리 프로세스 7과정 : 관리계획 - 기록 - 검토 - 수정 - 재확인 - 상태추적 - 최종분석

 

1) 결함 관리 계획 : 전체 프로세스에 대한 결함 관리 일정, 인력, 업무 프로세스 등을 확보하여 계획을 수립하는 단계.

2) 결함 기록 : 테스터는 발견된 결함을 결함 관리 DB에 등록.

3) 결함 검토 : 테스터, 프로그램 리더, 품질 관리 담당자 등은 등록된 결함을 검토하고 결함을 수정할 개발자에게 전달.

4) 결함 수정 : 개발자는 전달받은 결함을 수정.

5) 결함 재확인 : 테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행.

6) 결함 상태 추적 및 모니터링 활동 : 결함 관리 DB를 이용하여 프로젝트별 결함 유형, 발생률 등을 한눈에 볼 수 있는 대시보드 또는 게시판 형태의 서비스를 제공.

7) 최종 결함 분석 및 보고서 작성 : 발견된 결함에 대한 정보와 이해관계자들의 의견이 반영된 보고서를 작성하고 결함 관리를 종료.

 

3. 결함의 상태 추적

 

1) 결함 등록(Open) : 결함 처음 발견되어 등록 , 분석 전

2) 결함 검토(Reviewed) : 결함 검토

3) 결함 할당(Assigned): 결함 할당

4) 결함 수정(Resolved) : 결함 수정(Fixed)

5) 결함 조치 보류(Deferred) : 수정 연기

6) 결함 종료(Closed) : 수정 후 결함 미발견

7) 결함 해제(Clarified) : 비 결함으로 판명

 

 

4. 결함 분류

· 결함 분류(4유형) : 시스템 결함 - 기능 결함 - GUI 결함 - 문서 결함

 

1) 시스템 결함 : 애플리케이션 환경과 데이터베이스 처리에서 발생하는 결함.

   ex) 비정상적인 종료/중단, 응답 시간 지연, 데이터베이스 에러

 

2) 기능 결함 : 기획, 설계, 업무 시나리오 단계에서 발생된 결함.

   ex) 요구사항 미반영/불일치, 부정확한 비즈니스 프로세스, 스크립트 에러, 타 시스템 연동 시 오류

 

3) GUI 결함(Graphical User Interface) : 사용자 화면 설계에서 발생된 결함.

   ex) 응용 프로그램의 UI 비일관성,  부정확한 커서/메시지, 데이터 타입의 표시 오류

 

4) 문서 결함 : 기획자, 사용자, 개발자 간의 의사소통과 기록이 원활하지 않은 경우에 불완전한 상태의 문서로 발생한 결함 

    ex) 사용자의 온라인/오프라인 매뉴얼의 불일치, 요구사항 분석서와 기능 요구사항의 불일치

 

 

 

5. 결함 조치

· 소프트웨어 테스트 기법

 

1) 단위 테스트 기법 : 컴포넌트나 모듈 내의 결함을 찾고 기능을 검증하기 위한 테스트.

 

   ex) Junit, Mock 테스트 기법

xunit	Mock 테스트
다양한 코드 중심의 테스트 프레임워크, 함수나 클래스 등 서로 다른 구성 단위를 검사.	특정 기능 또는 모듈에 대한 응답 결과를 미리 정의해 놓고 테스트하는 기법.
JAVA(Junit), C++(Cppunit), NET(Nunit)	Dummy : 객체의 전달에만 사용되고 실제로는 사용되지 않으며, 주로 매개 변수 목록을 채우는 데 쓰임 Fake : 실제로 동작하도록 구현되지만, 보통 바른 구현을 위해 실제 환경과는 다르게 구현할 수 있음. Stubs : 테스트를 위해 미리 준비한 응답만을 제공하는 것으로, 그 외의 상황에 대해서는 정상적인 작동을 하지 못하는 것 Mocks : 스펙을 통해 정의된 응답을 받고 다른 응답을 받을 경우 예외를 발생하도록 구현되어 있으며, 응답에 대한 확인을 수행하는 역할

 

 

2) 통합 테스트 기법

• 전체 시스템이 통합 완료될 때까지 단위 시스템 간의 연계성 및 기능 요구사항들을 확인하고, 하드웨어와 소프트웨어 구성요소 간의 상호작용을 테스트하는 것이 주요 목적
• 업무 간의 연계성과 상호 운영성 중심의 테스트를 수행
• 테스트 설계 : 소프트웨어나 시스템 요구사항, 요구사항 명세서, 업무 구조, 시스템 구조 등을 기반으로 테스트 상황과 방법을 파악
• 테스트 구현 : 체계적으로 구체화시켜 테스트 케이스를 도출, 작성
• 테스트 설계 방법 : 테스트 상황과 방법을 구체화 시키기 위한 수단 및 도구

보다 작은 케이스	동등 클래스 한 자리 정수를 더하는 프로그램 경우, 1+1, 1+2 ... 9+9까지 81가지 케이스는 모두 동등한 경우.
보다 많은 버그 찾기	경계 테스트 위의 동등 클래스 중 대표 클래스를 뽑을 때 가장자리, 즉 경계값을 뽑는 경우

 

 

3) 시스템 테스트 기법 : 절차 및 각 프로세스별 세부 업무를 알아야 하고 결과에 대한 분석 및 해결 방안을 제시할 수 있어야한다.

   ex)부하 및 성능 테스트, 장애 복구 테스트, 보안 테스트

 

 

4) 인수 테스트 기법 : 사용자가 요구한 기능이 제대로 반영되었는지, 인수조건에 만족하는지를 테스트 하는 기법,
고객이 주도하는 테스트

 

 

6. 결함 관련 용어

1) 에러(Error) : 개발 중 발생한 부정확한 결과

2) 오류(Fault) : 프로그램 버전 간의 차이로 발생

3) 실패(Failure): 프로그램 버전 간의 실행 결과의 차이

4) 결함(Defect) : 버그, 에러, 오류, 실패, 프로그램 실행에 대한 문제점, 프로그램 개선 사항 등의 전체를 포괄

 

• 결함 판단 기준 : 기능 명세서를 기준으로 한다.
• 테스터의 시각에서 이해하기 어려운 기능, 사용이 까다로운 기능. 비정상적으로 느린 기능 등도 결함에 포함.

 

 

7. 테스트 격언(Testing Axioms)

1) 소프트웨어를 완벽하게 테스트하는 것은 불가능

2) 소프트웨어 테스트는 위험을 수반하는 훈련

3) 테스트 작업으로 결함이 존재하지 않는다는 사실을 입증할 수 없다. ( = 결함이 있다는 것만 알아 낼 수 있다.)

4) 아래와 같은 사유로 인하여 발견한 모든 결함을 수정할 수는 없다.

• 쫓기는 작업 일정
• 외부적인 요인(테스트 환경 미비, 사용자 환경 자체 장애, 법률 또는 규정 변경 등)으로 결함이 아님에도 결함으로 판단되는 경우
• 각각의 프로그램 간에 서로 결합도가 높아 고치기 위험한 결함
• 현실에서 발생할 가능성(자연재해)이 낮아 고칠 가치가 없는 결함

5) 발견한 결함이 많을수록 남아 있는 결함의 수도 많다.

 

 

8. 결함 조치 관리

 1) 프로그램 코드 검토 기법

• 코드 인스펙션(Code Inspection) = 소프트웨어 인스펙션(Software Inspection) : 자동화 도구 사용, 결함 발견/수정
• 워크스루 : 코드의 품질을 평가, 개선 목적으로 수행되는 검토 기법 , 검토 회의(단위 미팅)
  ※ 코드 인스펙션이랑 워크스루는 다름!!! (코드 인스펙션은 여러 날, 도구의 도움 필요)
• 코드 인스펙션 프로세스

구분	수행 단계	주요 내용
자동 수행	1. 범위 계획	인스펙션의 범위와 범위 선정 기준 결정
	2. 시작	자동 인스펙션 수행
준비 단계	3. 준비	계획서 작성, 체크리스트 작성, 계획 공지, 대상 산출물 준비
이행 단계	4. 인스펙션 회의	사전 검토 실시, 미팅 실시
시정 조치	5. 재작업	개발 원작자가 직접 작업
	6. 후속 처리	결과서 작성 및 보고

 

구분	인스펙션	워크스루
목적	결함 파악 및 제거	산출물 평가 및 개선
수행 조건	완성도가 기준 이상일 때	팀이나 관리자가 필요할 때
결함 수정 여부	모든 결함 제거	저자 결정
변경 사항 검증	진행자가 재작업 결과 확인	저자 결정
검토자 인원	3~6명	2~7명
참여자	동료	기술 전문가 및 동료
검토 인도자	교육받은 진행자(Moderator) 주도	저자 주도
검토 준비 여부	체크리스트	x
검토 분량	상대적 적음	상대적 적음
검토 속도	상대적 느림	빠름
발표자	산출물에 의존도가 높은 사람(Reader)	저자
지표 수집 여부	모든 검토자들이 기록	x
보고서	결함 리스트 및 측정 지표	워크스루 보고서
데이터 측정 여부	필수	권장사항
체크리스트 사용 여부	사용	x

 

 

 

 2) 형상 관리 및 구성요소

• 소프트웨어 형상 관리 : 소프트웨어 형상의 변경 요인에 대해 소프트웨어 형상을 보호하는 활동,
                                       프로젝트 개시에서 소프트웨어 소멸 시점까지 활동
• 소프트웨어 지원 : 소프트웨어가 고객에게 인도되고 운영되는 시점에 발생하는 소프트웨어 엔지니어링 활동
•  기준선
  • 변경을 통제하게 도와주는 선
  • 정식으로 검토 및 합의된 명세서나 제품 개발의 바탕
  • 정식의 변경 통제 절차를 통해서만 변경 가능하다.
• 소프트웨어 형상 관리 항목(SCI, Software Configuration Item )
  • 소프트웨어 형상 + 개발 도구,  개발 단계별로 기준선을 기준으로 형상 항목을 관리한다.

소프트웨어 형상 관리 항목

• 형상 관리의 주요 기능

  

  형상 관리 기능

• 형상 관리 도구

CVS(Concurrent Version System)	가장 오래된 형상 관리 도구 서버는 단순한 명령구조를 가진다는 장점, 텍스트 기반의 코드만 지원한다는 단점
SVN(Subversion)	CVS의 단점을 보완해 현재 가장 대중화 된 도구 중 하나 다양한 GUI도구가 존재하고 압축을 통해 서버공간을 절약
Git	리눅스 커널 개발을 위해 만든 형상관리 시스템 CVS와 SVN의 단점을 모두 보완, 분산형 방식으로 스스로 저장공간이 필요함, 개발자에게 학습할 시간이 필요.

---

 

문제 풀어보기

 

01. 이것은 프로그램 명세서 간의 차이 즉, 업무 내용 불일치이다. 사용자가 기대하는 기대치를 만족하지 못할 때 변경이 필요한 모든 것을 이것이라 하는데 이것은 무엇인지 쓰시오.

 

답 : 결함

 

 

02. 결함의 상태 및 추적 단계 중 하나로 개발자에 의해 결함의 수정이 완료된 상태를 무엇이라 하는지 쓰시오.

 

답 : 결함 수정

 

03. 다음 중 결함 분류 유형으로 올바르지 않은 것을 골라 쓰시오.

ㄱ. 실행 결과 결함  ㄴ. 시스템 결함  ㄷ. GUI 결함  ㄹ. 기능 결함

 

답 : ㄱ

 

04. 다음 빈칸에 알맞은 용어를 작성하시오.

1번	소프트웨어 개발 또는 유지 보수 수행 중에 발생한 부정확한 결과로, 개발자의 실수로 발생한 오타. 개발 명세서의 잘못된 이해. 서브루틴의 기능 오해 등이 있다.
2번	프로그램 코드 상에 존재하는 것으로 비정상적인 프로그램과 정상적인 프로그램 버전 간의 차이로 인하여 발생한다.
3번	정상적인 프로그램과 비정상적인 프로그램의 실행 결과 차이를 의미, 프로그램 실행 중에 프로그램의 실제 실행결과를 개발 명세서에 정의된 예상 결과와 비교함으로써 발견한다.
4번	버그, 에러, 오류, 실패, 프로그램 실행에  대한 문제점, 프로그램 개선 사항 등의 전체를 포괄하는 용어이다.

 

답 : 1번 에러(error) / 2번 오류(fault) / 3번 실패(failed) / 4번 결함(defect)

 

 

05. 다음 Mock 테스트 중 빈칸에 들어가는 유형을 작성하시오.

 

Dummy	객체 전달에만 사용되고 실제로는 사용되지 않으며, 주로 매개 변수 목록을 채우는 데 쓰임
(         )	실제로 동작하도록 구현되지만, 보통 바른 구현을 위해 실제 환경과는 다르게 구현할 수 있음
Stubs	테스트를 위해 미리 준비한 응답만을 제공하는 것으로, 그 외의 상황에 대해서는 정상적인 작동을 하지 못하는 것
Mocks	스펙을 통해 정의된 응답을 받고 다른 응답을  받을 경우 예외를 발생하도록 구현되어 있으며, 응답에 대한 확인을 수행하는 역할

 

답 : Fake

 

 

06. 다음 설명하는 용어?

전문가가 하는 가장 공식적인 검토 방법 체크리스트를 기반으로 검토

 

답 : 인스펙션 (전문가가 체크리스트를 기반으로 검토)

 

 

07. 산출물을 검토하고 결함을 찾아내기 위하여 요구사항 명세서를 미리 배포하여 사전 검토한 후 오류를 조기에 검출하는 데 목적을 두는 검토 방법?

 

답 : 워크스루 (저자가 직접 주도)

 

08. 소프트웨어 변경 과정 및 처리 상태를 기록/보고하고 소프트웨어의 안전성을 높이는 데에 지원하는 도구를 무엇?

 

답 : 형상 관리 도구(CVS, SVN, Git)