728x90
이 글은 이기적 정보처리기능사 실기 기본서를 기반으로 제작되었습니다.
소개
이번 시간엔 애플리케이션 결함 조치에 대해 배워보도록 합시다!
이름만 들어도 벌써부터 졸린것같지만.. 화이팅!
1. 결함 관리
1. 결함의 정의
- 결함은 프로그램과 명세서 간의 차이, 업무 내용의 불일치이다.
- 결함은 기대 결과와 실제 결과 간의 차이이다.
- 사용자가 기대하는 타당한 기대치를 시스템이 만족시키지 못할 때 변경이 필요한 모든 것을 결함이라고 한다.
2. 결함 관리 프로세스
- 1) 결함 관리 계획
- 전체 프로세스에서 결함 관리에 대한 일정, 인력, 업무 프로세스를 확보, 계획을 수립한다.
- 2) 결함 기록
- 테스터는 발견된 결함에 대한 정보를 결함 관리 DB에 기록한다.
- 3) 결함 검토
- 등록된 결함에 있어서 주요 내용을 검토하고, 결함을 수정할 개발자에게 전달한다.
- 4) 결함 수정
- 개발자는 할당된 결함의 프로그램을 수정한다.
- 5) 결함 재확인
- 테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행한다.
- 6) 결함 상태 추적 및 모니터링 활동
- 결함 관리 팀장은 결함 관리 DB를 이용해 대시보드 or 게시판 형태의 서비스를 제공한다.
- 7) 최종 결함 분석 및 보고서 작성
- 발견된 결함에 대한 내용, 이해관계자들의 의견이 반영된 보고서를 작성, 결함 관리를 종료한다.
3. 결함의 상태 및 추적
- 1) 결함 등록 ( Open )
- 테스터와 품질 관리 담당자에 의해 처음 발견되어 등록된 상태
- 아직 분석이 되지 않은 상태이다.
- 2) 결함 검토 ( Reviewed )
- 등록된 결함을 담당 모듈 개발자, 테스터, 프로그램 리더, 품질 관리 담당자와 검토하는 상태
- 3) 결함 할당 ( Assigned )
- 결함의 영향 분석, 수정을 위해 개발자와 문제 해결 담당자에게 할당된 상태
- 4) 결함 수정 ( Resolved )
- 개발자에 의해 결함이 수정 완료된 상태이다.
- 5) 결함 조치 보류 ( Deferred )
- 수정이 필요한 결함이지만 현재 수정이 불가능해서 연기된 상태
- 우선순위, 일정 등을 고려하여 재오픈을 준비하는 상태이다.
- 6) 결함 종료 ( Closed )
- 발견된 결함이 해결되고 테스터와 품질 관리 담당자에 의해 종료 승인을 한 상태이다.
- 7) 결함 해제 ( Clarified )
- 테스터, 프로그램 리더, 품질 관리 담당자가 결함을 검토한 결과, 결함이 아니라고 판명된 경우이다.
4. 결함 분류
- 결함은 여러 가지 유형으로 나뉘며, 결함을 분석하는 단계에서 이러한 유형을 나눠야 한다.
- 결함 유형은 시스템 결함, 기능 결함, GUI 결함, 문서 결함 등 크게 4가지 유형으로 분류된다.
1) 시스템 결함
- 비정상적인 종료/중단, 응답 시간 지연, DB에러 등 주로 애플리케이션 활경, 데이터베이스 처리에서 발생하는 결함을 말한다.
- 비정상적인 종료 / 중단
- 특정 기능 실행 시 응용 프로그램의 작동 정지, 종료, 시스템 다운이 되는 경우이다
- Ex ) 발로란트를 켰는데 갑자기 종료된다..., 계산기 프로그램을 열었는데 응답없음이 떴다..
- 응답 시간 지연
- 응용 프로그램 작동 후 조회 또는 보고서 출력 시 지연되는 경우이다.
- 메모리 부족, 하드웨어와 소프트웨어 비일관성으로 발생하는 경우이다.
- DB 에러
- 응용 프로그램 작동 후 사용자 데이터의 등록, 수정, 삭제, 조회가 정상적으로 작동하지 않는 경우이다.
- 비정상적인 종료 / 중단
2) 기능 결함
- 사용자의 요구사항 미반영/불일치, 부정확한 비즈니스 프로세스, 스크립트 에러,
타 시스템 연동 시 오류 등 기획, 설계, 업무 시나리오 단계에서 발생한 결함을 말한다.- 요구사항 미반영 / 불일치
- 요구사항에 명시된 기능이 응용 프로그램에 구현되지 않은 경우
- 다르게 구현되어 작동하는 경우이다.
- Ex) 왜 계산기에 + 버튼을 눌렀는데 빼기가 되냐 ㅋㅋ;
- 부정확한 비즈니스 프로세스
- 기능 자체는 수행되나, 내부 프로세스 로직의 문제로 부정확한 결과를 내는 경우
- 스크립트 에러
- 특정 기능 실행 시 웹 브라우저에서 스크립트 오류가 발생하는 경우이다.
- 특정 기능 실행 시 웹 브라우저에서 스크립트 오류가 발생하는 경우이다.
- 타 시스템 연동 시 오류
- 기존 시스템과의 연동을 통해 데이터를 주고받는 과정에서 오류가 발생하는 경우
- 요구사항 미반영 / 불일치
3) GUI ( Graphical User Interface ) 결함
- GUI 결함은 응용 프로그램의 UI 비일관성, 부정확한 커서/메시지, 데이터 타입의 표시 오류 등
사용자 화면 설꼐에서 발생한 결함을 말한다.- 응용 프로그램의 UI 비일관성
- 프로젝트에서 정의한 UI 표준과 상이하게 구현된 경우이다
- 프로젝트에서 정의한 UI 표준과 상이하게 구현된 경우이다
- 부정확한 커서 / 메시지
- 커서의 위치가 입력 대상의 첫 번째 필드에 위치에 있지 않은 경우
- 탭 시퀀스가 순차적으로 동작하지 않는 경우
- 각 기능에서 제공하는 메시지 내용이 부정확한 내용을 보여주는 경우
- 데이터 타입의 표시 오류
- 입력 필드에 지정된 형식과 다르게 입력해도 저장이 되는 경우
- 입력 필드에 유효하지 않은 데이터를 입력했을 때 오류가 나는 경우
- 응용 프로그램의 UI 비일관성
4) 문서 결함
- 기획자, 사용자, 개발자 간의 의사소통과 기록이 원활하지 않은 경우에 발생하는 결함이다.
- 사용자의 온라인/오프라인 메뉴얼의 불일치, 요구사항 분석서와 기능 요구사항의 불일치로 인한 불완전한 상태의 문서로 발생한 결함을 말한다.
5. 결함 심각도
- 결함 심각도는 여러 개의 결함 중 전체 시스템에 결함이 미치는 영향을 레벨별로 나타낸다.
- 우선순위는 High, Medium, Low로 정한다.
- Low
- 시스템의 흐름에는 영향을 미치진 않는다.
- 상황에 맞지 않는 용도와 화면 구성 등의 결함이다.
- 부정확한 GUI 및 메시지, 에러 시 메시지 미출력, 화면상의 문법/철자 오류 등
- Medium
- 시스템의 흐름에 영향을 미치는 결함이다.
- 부정확한 기능, 부정확한 업무 프로세스, 데이터 필드 형식의 오류, DB 에러, 보안 오류 등
- High
- 시스템이 중단(또는 다운)되어 더 이상 프로세스를 진행할 수 없게 만드는 결함이다.
- 시스템의 핵심 요구사항 미구현, 시스템 다운, 장시간 시스템 응답 지연, 시스템 복구 후 데이터 왜곡 등
- Low
2. 결함 조치
1. 소프트웨어 테스트 기법
1) 단위 테스트 기법
- 테스트 가능한 단위인 컴포넌트나 모듈 내의 결함을 찾고 기능을 검증하기 위한 테스트이다.
- 대표적으로 Junit과 Mock 테스트 기법이 있다.xunit : 다양한 코드 중심의 테스트 프레임워크이다.
Junit(Java), Cppunit(C++), .Nunit(.NET)
Mock 테스트 : 특정 기능 또는 모듈에 대한 응답 결과를 미리 정의해놓고 테스트하는 기법이다.
2) 통합 테스트 기법
- 전체 시스템이 통합 완료될 때까지 단위 시스템 간의 연계성 및 기능 요구사항들을 확인하고,
하드웨어와 소프트웨어 구성요소간의 상호작용을 테스트하는 것이 주요 목적이다. - 업무 간의 연계성과 상호 운영성 중심의 테스트를 수행한다.
1. 설계 기법
- 테스트 설계는 개발된 소프트웨어나 시스템의 요구사항, 요구사항 명세서, 업무 구조, 시스템 구조 등을 기반으로 소프트웨어의 어떤 부분을 어떻게 접근하여 테스트할지에 대한 테스트 상황과 방법을 파악하는 것이다.
- 이를 체계적으로 구체화시켜 테스트 케이스를 도출하고 작성하는 것을 '테스트 구현'이라고 한다.
- 테스트 상황과 방법을 구체화 시키기 위한 수단 및 도구를 "테스트 설계 방법'이라고 한다.
2. 설계 방법
- 보다 작은 케이스
- 동등 클래스(Equivalence Class)
- 예를 들어, 한 자리 정수를 더하는 프로그램인 경우, 1+1, 1+2 ... 1+9까지 81가지 케이스는 모두 동등한 경우이다.
- 따라서 이런 경우를 모두 모아서 몇 가지 케이스만 테스트하면 되는 경우
- 동등 클래스(Equivalence Class)
- 보다 많은 버그 찾기
- 경계 테스트(Boundary Test)
- 위의 동등 클래스 중 대표 클래스를 뽑을 때 가장자리, 즉 경계값을 뽑는 경우.
- 경계 테스트(Boundary Test)
3) 시스템 테스트 기법
- 시스템 테스트 업무의 진행 전체를 총괄할 수 있도록 절타 및 각 프로세스별 세부 임무를 알아야 한다.
- 결과에 대한 분석 및 해결 방안을 제시할 수 있어야 한다.
- 시스템 테스트 기법으로는 부하 및 성능 테스트, 장애 복구 테스트, 보안 테스트가 있다.
4. 인수 테스트 기법
- 최종 사용자가 요구한 기능이 제대로 반영되었는지, 인수 조건에 만족하는지를 테스트하는 기법이다.
- 요구 기능 만족 여부, 사용 편리성에 대하여 실제 운영 환경에서 실행된다.
- 고객이 주도하는 테스트이다.
2. 결함 관리의 이해
1) 결함 관련 용어
- 에러(Error)
- 소프트웨어 개발 또는 유지 보수 수행 중에 발생한 부정확한 결과
- 개발자의 실수로 발생한 오타, 개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등이 있다.
- 오류(Fault)
- 정상적인 프로그램과 비정상적인 프로그램 버전 간에 차이로 인하여 발생
- 프로그램 코드 상에 존재함.
- 잘못된 연산자가 사용된 경우, 프로그램이 서브루틴으로부터 에러리턴을 점검하는 코드가 누락된것을 말한다.
- 실패(Failure)
- 정상적인 프로그램과 비정상적인 프로그램의 실행 결과 차이를 의미함
- 프로그램 실행 중에 프로그램의 실제 실행 결과를 개발 명세서에 정의된 예상 결과와 비교함으로써 발견한다.
- 결함(Defect)
- 위에서 소개한 에러, 오류, 실패 이외에도 버그, 프로그램 실행에 대한 문제점, 프로그램 개선 사항 등 전체를 포괄하는 용어이다
2) 결함의 판단 기준
결함의 판단은 기능 명세서를 기준으로 한다.
- 기능 명세서에 가능하다고 명시된 동작을 수행하지 않은 경우
- 기능 명세서에 불가능하다고 명시된 동작을 수행하는 경우
- 기능 명세서에 명시되어 있지 않은 동작을 수행하는 경우
- 기능 명세서에 명시되어 있지 않지만 수행해야 할 동작을 수행하지 않은 경우
- 테스터의 시각에서 볼 때 문제가 있다고 판단되는 경우
테스터의 시각에서 이해하기 어려운 기능, 사용이 까다로운 기능, 비정삭적으로 느린 기능 등도
결함에 포함됩니다.
3. 테스트 격언 ( Testing Axioms )
소프트웨어를 완벽하게 테스트하는 것은 불가능하다.
- 가능한 입력의 수가 너무 많다.
- 가능한 출력의 수가 너무 많다.
- 소프트웨어 명세서가 주관적이다.
- 소프트웨어 결함도 주관적이다.
소프트웨어 테스트는 위험을 수반하는 훈련이다.
- 가능한 모든 테스트 시나리오와 테스트 케이스를 테스트하지 않을 경우 위험을 감수하기로 했다는 뜻과 같다.
- 테스터는 무엇이 중요하고 무엇이 중요하지 않은지 현명한 판단을 하여야 한다.
테스트 작업으로 결함이 존재하지 않는다는 사실을 입증할 수 없다.
- 테스트를 통해 소프트웨어에 결함이 없다는 것을 보장할 수는 없다.
- 단지 테스트 결과로 결함이 있다는 사실만을 보여줄 수 있다.
- 테스트 결과 결함이 발견되지 않았다 하더라도 이는 결함이 없음을 의미하는 것은 아니다.
아래와 같은 사유로 인하여 발견한 모든 결함을 수정할 수는 없다.
- 쫓기는 작업 일정
- 외부적인 요인(테스트 환경 미비, 사용자 환경 자체 장애, 법률/규정 변경 등)으로 결함이 아님에도 결함으로 판단되는 경우
- 각각의 프로그램 간에 서로 결합도가 높아 고치기 위험한 결함
- 현실에서 발생할 가능성(자연재해)이 낮아 고칠 가치가 없는 결함
발견한 결함이 많을수록 남아 있는 결함의 수도 많다
놀러와요 결함의 숲
4. 소프트웨어 테스터
1) 소프트웨어 테스터의 역할
- 결함을 발견한다.
- 결함을 가능한 한 빨리 발견한다.
- 가능한 한 결함을 빨리 발견하여 결함이 수정ㆍ보완되었는지 확인한다.
2) 소프트웨어 테스터의 능력
- 탐구심, 문제 해결력을 갖추어야 한다
- 때로는 창의력을 발휘하여 결함을 찾기 위해 새로운 접근법도 사용해야 한다.
- 완벽함을 추구하지만, 가능한 한도 내에서 적당한 수준의 완벽성을 추구한다.
- 테스터는 항상 나쁜 소식을 전하는 사람이므로 개발자에게 그들의 작품에 결함이 있다고 말하려면
재치, 능숙함 그리고 설득력이 필요하다.
3. 결함 조치 관리
1. 프로그램 코드 검토 기법
1) 소프트웨어 인스펙션(Software Inspection)의 개요
- 코드 인스펙션(Code Inspection)외에도 설계 및 설계 산출물까지 포함하여 소프트웨어 인스펙션으로 부르기도 한다.
- 코드 인스펙션은 매우 효과적인 테스트 방법이며, 어떠한 다른 테스트 방법으로 대체할 수 없다,
- 상당한 시간이 필요한 작업이며, 통계에 따르면 인스펙션을 적절히 잘 수행하기만 하면 포함된 에러에 90%까지 찾아낼 수 있다.
- 코드 인스펙션, 워크스루와 같이 몇 시간 동안 수행되는 단위 미팅과는 구별되어야 한다.
- 적절한 코드 인스펙션은 여러 날이 필요하고 도구의 도움이 있어야 한다.워크스루? 코드의 품질 평가, 개선하기 위한 목적으로 수행되는 검토 기법으로, 검토회의라고도 한다.
- 적절한 인스펙션 = 소프트웨어 개발의 전체 수명 주기에 걸친 리소스 절감 + 비용 감소 + 산출물의 품질 향상
- 인스펙션을 해야 하는 비즈니스적인 이유는 다음과 같다.
- 결함을 빨리 찾을수록 수정 비용이 적게 든다.
- 인스펙션의 데이터를 통해 업무에 집중할 수 있다.
- 인스펙션을 함으로써 교차 교육(Cross-training)을 돕는다.
- 제품의 're-engineering'이 가능한 영역을 식별하도록 돕는다.
- 소프트웨어를 개발하고 유지하는 데 적은 비용이 든다.
- 스케줄에 긍정적인 효과를 준다.
- 품질을 향상시킨다.
2) 소프트웨어 인스펙션 중점 항목
- 프로젝트에서 소프트웨어 인스펙션 업무는 QA(품질보증)이 주관하여 당당 또는 부서에서 실시한다.
- 아키텍트가 각 단계에서 원할한 업무 수행을 위해 지원을 하여야 한다.
- 소프트웨어 인스펙션 중 특히 코드 인스펙션과 관련하여, 아키텍트는 코드 인스펙션의 프로세스 전반과 각 단계별 수행 업무 등을 전체적으로 이해할 필요가 있음.
- 아래와 같이 검토 절차에서 아키텍트는 Overview와 Rework가 잘 수행될 수 있도록 지원하는것이 중요하다.
- 자동 코드 인스펙션을 위한 환경 지원, 계획 수립 지원 활동
- 체크리스트 정합성 검토 지원 활동
- 인스펙션 결과 리뷰 참석
- 발견된 결함을 수정하기 위한 개발자 리딩 지원 활동
3) 코드 인스펙션 테스크별 수행 내용
1) 코드 인스펙션 프로세스
2) 코드 인스펙션 테스크별 수행 내용
3) 코드 인스펙션의 프로세스와 수행 내용
- 자동 코드 인스펙션
- 전체 개발된 프로그램을 대상으로 자동 인스펙션 수행
- 수동 코드 인스펙션
- 자동 코드 인스펙션 코드 중 에러가 많은 경우
- 업무 중에 복잡한 처리 로직이 있는 경우
- 처음 투입되는 개발자의 산출물
4) 코드 인스펙션 수행 시 고려사항
- 일반적으로 인스펙션의 목적은 개발 가이드에 따른 표준 준수성을 파락하기 위함에 있다.
- 기능적으로 이상이 없는 소스코드를 대상으로 검증한다.
- 인스펙션의 효과는 개발 가이드에 따른 체크 항목 파악, 결함 유형 파악에 따른 차후 코딩 시 유념
다른 개발자의 기술 습득 등으로 다양하다. - 실제적으로는 테스트 전 결함 발견에 따른 이익을 수행 팀원들이 인식하는 것이 가장 크다고 함.
4) 인스펙션과 워크스루의 차이점
구분인스펙션워크스루| 목적 | 결함 파악 및 제거 | 산출물 평가 및 개선 |
| 수행 조건 | 완성도가 기준 이상일 때 | 팀이나 관리자가 필요할 때 |
| 결함 수정 여부 | 모든 결함은 제거되어야 함 | 저자 결정 |
| 변경 사항 검증 | 진행자가 재작업 결과 확인 | 저자 결정 |
| 검토자 인원 | 3 ~ 6명 | 2 ~ 7명 |
| 참여자 | 동료 | 기술 전문가 및 동료 |
| 검토 인도자 | 교육받은 진행자(Moderator) | 저자 |
| 검토 준비 여부 | 체크리스트를 이용한 검토 | 일반적으로 검토 준비하지 않음 |
| 검토 분량 | 상대적으로 적음 | 상대적으로 적음 |
| 검토 속도 | 상대적으로 느림 | 빠름 |
| 발표자 | 산출물에 의존도가 높은 사람(Reader) | 저자 |
| 지표 수집 여부 | 모든 검토자들이 기록함 | 하지 않음 |
| 보고서 | 결함 리스트 및 측정 지표 | 워크스루 보고서 |
| 데이터 측정 여부 | 필수 | 권장 사항 |
| 체크리스트 사용 여부 | 사용함 | 사용하지 않음 |
인스펙션은 워크스루와 달리, 체크리스트를 기반으로 검토한다.
완성도가 기준 이상일 때 수행함으로써 모든 결함을 제거한다는 특징과 목적이 있다.
2. 형상 관리 및 구성요소
1) 소프트웨어 형상 관리의 정의
- 소프트웨어 프로세스의 모든 출력물 정보, 컴퓨터 프로그램, 프로그램 설명 문서, 데이터 등 프로세스 전반에 걸쳐 소프트웨어 형상의 변경 요안에 대해 소프트웨어 형상을 보호하는 활동이다.
2) 기준선과 소프트웨어 형상 관리 항목
1) 기준선
- 젼경을 통제하게 도와주는 선
- 정식으로 검토 및 합의된 명세서나 제품 개발의 바탕
- 정식의 변경 통제 절차를 통해서만 변경 가능하다.
2) 소프트웨어 형상 관리 항목(SCI)
- SCI는 Software Configuration Item에 약자이다.
- 소프트웨어 형상과 개발 도구의 합성으로 개발 단계별로 기준선을 기준으로 형상 항목을 관리한다.
3) 형상 관리의 주요 활동
- 형상 관리의 주요 기능은 형상을 식별하고 관리하는 데에 있다.
4) 형상 관리 도구
- 소프트웨어 변경 과정, 처리 상태를 기록 및 보고한다.
- 부합하는 해당 사항에 대하여 추적, 통제하고 관리한다.
- 품질 향상 및 안전성을 높이는 데에 지원하는 도구이다.
- 종류는 다음과 같다.
- CVS(Concurrent Version System)
- 가장 오래된 형상 관리 도구 중 하나이다.
- 서버는 단순한 명령 구조를 가진다는 장점이 있다.
- 텍스트 기반의 코드만 지원한다는 단점이 있다.
- SVN(Subversion)
- 아파치에서 나온 시스템이다.
- CVS의 단점을 보완해 현대 가장 대중화 된 도구 중 하나이다.
- 다양한 GUI 도구가 존재하고 압축을 통해 서버의 공간을 절약할 수 있다.
- Git
- 현대 개발자들에겐 없어선 안되는 귀중한 도구 중 하나이다.
- 리눅스 커널 개발을 위해 만든 형상 관리 시스템이다.
- CVS와 SVN의 단점을 모두 보완하는 장점이 있다.
- 중앙 집중형이 아닌 분산형 방식으로 스스로 저장공간이 필요하다.
- 개념이 다르므로 개발자에게 학습할 시간이 필요하다.
- Github와 연동하여 클라우드에 자신에 소스를 올릴 수 있다.
- CVS(Concurrent Version System)
마치며
드디어 Part2가 끝났네요!
어때요? 이 파트에선 문제가 많이 나오진 않지만 중요한 부분이 많으니 꼭 읽고 가시는 걸 추천드려요!
그럼 저희는 다음 part인 응용 SW 기초 기술 활용에서 만나도록 할게요!
그럼 다음 시간에 다시 뵙도록 하죠!
728x90