정보처리기사 정리1

뿌엑·2022년 5월 5일

정보처리기사

목록 보기

19/20

비용산정 모델

LoC(Line of Code) 모형

LoC 모형은 소프트웨어 각 기능 원시코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식이다.
예측치
- 낙관치 + 4 * 중간치 + 비관치 / 6
비관치: 가장 많이 측정된 코드 라인 수
중간치: 측정된 모든 코드 라인 수의 평균
낙관치: 가장 적게 측정된 코드 라인 수

Man Month 모형

Man Month 모형은 한 사람이 1개월 간 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식이다.
Man Month = LoC/프로그래머의 월간 생산성
프로젝트 기간 = Man Month/프로젝트 인력

COCOMO(COnstructive COst MOdel) 모형

COCOMO 모형은 보헴이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 모델이다.
규모에 따라 조직형, 반 분리형, 임베디드형으로 나뉜다.

소프트웨어 생명주기 프로세스

요구사항 분석
- 다양한 이해관계자의 상충할 수 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계
- 개발할 소프트웨어의 기능과 제약조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계
- 기능 요구사항, 비기능 요구사항
설계
- 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계
- 시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계
구현
- 설계 단계에서 논리적으로 결정한 문제 해결방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계
- 프로그래밍 언어, 기법, 스타일 등을 결정하는 단계
- 인터페이스 개발, 자료 구조 개발, 오류 처리
테스트
- 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계
- 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
유지보수
- 시스템이 인수되고 설치된 후 일어나는 모든 활동

소프트웨어 개발방법론

구조적 방법론
- 전체 시스템을 기능에 따라 나눠 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
정보공학 방법론
- 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
- 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론
객체지향 방법론
- 객체란 기본 단위로 시스템을 분석하고 설계하는 방법론
컴포넌트 기반 방법론(CBD)
- 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
애자일 방법론
- 절차보다 사람 중심으로 변화에 유연하고 신속하게 적응하며 효율적으로 시스템을 개발할 수 있는 개발방법론
제품 계열 방법론
- 특정 제품에 적용하고 싶은 공통 기능을 정의하여 개발하는 방법론
- 임베디드 소프트웨어를 작성하는데 유용한 방법론

※ 반복적 모델은 소프트웨어 개발방법론이 아닌 소프트웨어 생명주기 모델에 해당한다.

TDD(Test Driven Development)

테스트 주도 개발
반복 테스트를 이용한 소프트웨어 개발 방법론으로 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

애자일 방법론 - XP(eXtreme Programming)

의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
1~3주의 반복 개발주기
5가지 가치와 12개의 실천항목 존재

XP의 5가지 가치
- 용기(Courage): 용기를 가지고 자신감있게 개발(코드 작성 전 테스트, 빠르게 피드백, 테스트에 부합하지 않는 코드를 리팩토링할 용기)
- 단순성(Simplicity): 필요한 것만 하고 그 이상의 것들은 하지 않음
- 의사소통(Communication): 개발자, 관리자, 고객 간 원활한 소통
- 피드백(Feedback): 의사소통에 대한 빠른 피드백
- 존중(Respect): 팀원 간 상호 존중
XP의 12가지 기본원리
- 짝 프로그래밍(Pair Programming): 개발자 두 명이 짝을 맺어 함께 개발함
- 공동 코드 소유(Collective Ownership): 시스템에 있는 코드는 누구라도 언제든 수정할 수 있다는 원리
- 지속적인 통합(CI: Continuous Integration): 매일 여러 번 소프트웨어를 통합하고 빌드해야 한다는 원리
- 계획 세우기(Planning Process): 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지 알려줘야 한다는 원리
- 작은 릴리즈(Small Release): 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리
- 메타포어(Metaphor): 공통적 이름 체계와 시스템 서술서를 통해 고객과 개발자 간 의사소통을 원활하게 한다는 원리
- 간단한 디자인(Simple Design): 현재 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
- 테스트 기반 개발(TDD; Test Driven Develop): 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고, 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
- 리팩토링(Refactoring): 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템을 재구성한다는 원리
- 40시간 작업(40-Hour Work): 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리
- 고객 상주(On Site Customer): 개발자의 질문에 즉각 대답해줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
- 코드 표준: 효과적인 공동 작업을 위해 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리

애자일 방법론 - 스크럼(SCRUM)

매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

델파이 기법

전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법으로 전문가 합의법이라고도 한다.

일정관리 모델 - 주 공정법(CPM)

여러 작업의 수행 순서가 얽힌 프로젝트의 일정을 계산하는 기법
프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로를 계산한다.(임계 경로, Critical Path)

소프트웨어 아키텍처 4+1 뷰

유스케이스 뷰(Usecase View)
- 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰
- 사용자, 설계자, 개발자, 테스트 관점
논리 뷰(Logical View)
- 시스템의 기능적 요구사항이 제공되는 방식을 설명하는 뷰
- 설계자, 개발자 관점
프로세스 뷰(Process View)
- 시스템의 비기능적 속성으로서 자원의 효율적 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
- 개발자, 시스템 통합자 관점
구현 뷰(Implementation View)
- 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
- 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적 정보 정의
배포 뷰(Deployment View)
- 컴포넌트가 물리적인 아키텍처에 어떤 방식으로 배치되는지 매핑하여 보이는 뷰

소프트웨어 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물

요구사항 명세서

형상관리 위원회

형상관리에 대한 주요 방침을 정하고 산출물을 검토하며 단계별 의사결정을 수행하는 조직

분석 모델 검증

분석 모델 검증은 요구사항 도출 기법을 사용하여 업무 분석가가 제시한 분석 모델에 대해 확인하는 활동이다.
분석 모델 검증 방법
- 유스케이스 모델 검증
  - 시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해 액터, 유스케이스, 유스케이스 명세서 점검
- 개념 수준의 분석 클래스 검증
  - 시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하기에 개념 수준의 주요 분석 클래스를 적절히 도출했는지, 관련 정보가 명확한지 점검함
- 분석 클래스 검증
  - 유스케이스 실현에 필요한 분석 클래스 도출 확인
  - 유스케이스별로 도출된 분석 클래스들이 스테레오 타입으로 표시됐는지 확인
  - 경계와 제어 클래스의 도출 여부 및 상세화 정도 확인
  - 클래스 간 관계, 클래스 정보의 상세화 정도 확인

분석 모델 기술적 타당성 검토

성능 및 용량 산정의 적정성
- 요구사항을 만족시키기 위한 분석 모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원 식별
- 분석 클래스에서 불필요하게 많은 속성을 포함시키면 객체 생성시 시스템의 메모리 자원이 크게 요구되어 전체 시스템의 기능 저하가 발생한다.
시스템 간 상호 운용성
- 분석 모델을 이용하여 보다 구체적으로 시스템 간 상호 정보 및 서비스가 교환 가능한지 검토
- 분석 모델에서 정의한 구체적인 정보의 존재 여부, 생성 가능성, 교환방식 지원 등 확인
IT 시장 성숙도 및 트렌드 부합성
- 분석 모델이 과거의 문제를 해결하고 최근 많이 사용되는 트렌드에 부합되는지 확인
- 분석 자동화 도구 활용 고려
기술적 위험 분석
- 분석 모델이 시스템의 기술 구조, 프레임워크, 사용되는 하드웨어 및 소프트웨어와 부합하는지 확인
- 분석 모델이 검증되지 않은 기술의 사용을 가정으로 하고 있어 추가적인 비용 발생 가능성이 있는지 확인
- 분석 모델을 구현하기 위해 특정 업체 기술, 특허, 라이센스에 의존해야 하는지 확인

소프트웨어 생명주기 모델

시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

요구사항 도출 단계 주요 기법

인터뷰
- 이해관계자와 직접 대화하여 정보를 구하는 공식적, 비공식적 정보 수집 방법
브레인스토밍
- 말을 꺼내기 쉬운 분위기로 만들어 회의 참석자들이 내놓은 아이디어들을 비판없이 수용할 수 있도록 하는 회의
델파이 기법
- 전문가의 경험적 지식을 통한 문제해결 및 미래예측을 위한 방법
롤플레잉
- 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기하는 것으로 요구사항을 분석하고 수집하는 방법
워크숍
- 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법
- 프로젝트에 참여하는 모든 핵심 인물의 참여가 필요
- 참석자들은 해당 전문 영역별로 팀 협력이 필요하며 사전 준비가 요구됨
설문조사
- 설문지 혹은 여론조사 등을 이용해 간접적으로 정보를 수집하는 방법
- 개발될 시스템의 사용자가 다수일 때 의견 수렴에 용이

소프트웨어 아키텍처 비용 평가 모델

소프트웨어 아키텍처 비용 평가 모델은 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델이다.
종류
- SAAM(Software Architecture Analysis Method)
  - 변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능한 비용 평가 모델
- ATAM(Architecture Trade-off Analysis Method)
  - 아키텍처 품질 속성을 만족시키는지 판단하고 품질 속성들의 이해 상충관계까지 평가하는 모델
- CBAM(Cost Benefit Analysis Method)
  - ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델
- ADR(Active Design Review)
  - 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델
- ARID(Active Reviews for Intermediate Designs)
  - 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델

UI 품질 요구사항(ISO/IEC 9126 기반)

기능성
- 기능성은 실제 수행 결과와 품질 요구사항과의 차이를 분석하고, 실제 사용시 정확하지 않은 결과가 발생할 확률과 관련하여 시스템의 동작을 관찰하기 위한 품질 기준이다.
  - 적절성: 소프트웨어 제품이 주어진 작업과 사용자의 목표에 필요 적절한 기능을 제공할 수 있는 소프트웨어의 능력
  - 정밀성: 소프트웨어 제품이 요구되는 정확도로 올바른 결과를 산출할 수 있는 능력
  - 상호 운용성: 소프트웨어 제품이 특정 시스템과 상호작용하여 운영될 수 있는 능력
  - 보안성: 비인가된 접근을 차단하고 우연 또는 고의적 접근을 인지하여 대처할 수 있는 능력
  - 호환성: 소프트웨어 제품이 비슷한 환경에서 연관된 표준, 관례 및 규정을 준수하는 능력
신뢰성
- 신뢰성은 시스템이 일정한 기간 또는 작동되는 시간 동안 의도하는 기능을 수행할 것을 보증하는 품질 기준이다.
  - 성숙성: 소프트웨어 결함으로 인한 고장을 회피할 수 있는 소프트웨어의 능력
  - 고장 허용성: 소프트웨어 결함이나 인터페이스 오류시에도 특정 수준 이상의 성능을 유지할 수 있는 능력
  - 회복성: 소프트웨어 고장 발생시 영향 받은 데이터를 복구하고 성능 수준을 다시 확보할 수 있는 능력
사용성
- 사용성은 사용자와 컴퓨터 사이 발생하는 행위를 정확하고 쉽게 인지할 수 있는 품질 기준이다.
  - 이해성: 소프트웨어의 논리적 개념과 적용 가능성(응용 가능성)을 구분하는데 필요한 사용자의 노력 정도에 따른 소프트웨어의 특성
  - 학습성: 소프트웨어 애플리케이션 학습에 필요한 사용자의 노력 정도에 따른 특성
  - 운용성: 소프트웨어 운용과 운용 통제에 필요한 사용자의 노력 정도에 따른 특성
효율성
- 효율성은 할당된 시간에 한정된 자원으로 얼마나 빨리 처리할 수 있는지에 대한 품질 기준이다.
  - 시간 효율성: 소프트웨어 기능을 수행하는 것에서 반응 시간, 처리 시간 및 처리율에 따른 소프트웨어 특성
  - 자원 효율성: 소프트웨어의 기능을 수행하는 것에서 사용되는 자원의 양과 지속 시간에 따른 특성
유지보수성
- 유지보수성은 요구사항을 개선하고 확장하는 것의 용이성에 대한 품질 기준이다.
  - 분석성: 소프트웨어 고장의 원인이나 결함 진단 또는 수정이 요구되는 부분의 확인에 필요한 노력 정도에 따른 소프트웨어 특성
  - 변경성: 결함 제거 또는 환경 변화에 따른 수정에 필요한 노력 정도에 따른 특성
  - 안정성: 소프트웨어의 변경으로 발생하는 예상치 못한 영향에 의한 위험 요소에 따른 특성
  - 시험성: 소프트웨어가 변경되어 발생하는 검증에 필요한 노력 정도에 따른 특성
이식성
- 이식성은 다른 플랫폼(운영체제)에서도 많은 추가작업 없이 얼만큼 쉽게 적용 가능한지에 대한 품질 기준이다.
  - 적용성: 소프트웨어의 목적을 위해 제공된 수단이나 다른 조치 없이 특정 환경으로 전환되는 능력에 따른 소프트웨어 특성
  - 설치성: 특정 환경에 소프트웨어을 설치하는데 필요한 노력 정도에 따른 특성
  - 대체성: 특정 운용 환경에서 동일한 목적 달성을 위해 다른 소프트웨어를 대신 사용할 수 있는 능력

사용성 테스트

사용자가 직접 제품을 사용하면서 미리 작성된 시나리오에 맞춰 과제를 수행한 후, 질문에 답하도록 하는 테스트이다.
현 제품에 대한 사용자의 요구사항과 행동을 관찰할 수 있는 유용한 진단방법이다.

UI 설계지침

사용자 중심: 사용자가 이해하기 쉽고, 편하게 사용할 수 있는 환경을 제공하며 실사용자에 대한 이해가 바탕 되어야 함
일관성: 버튼이나 조작 방법을 사용자가 기억하기 쉽고 빠르게 습득할 수 있도록 설계해야 함
단순성: 조작 방법은 가장 간단하게 작동되도록 하여 인지적 부담 최소화
결과 예측 가능: 작동시킬 기능만 보고도 결과 예측이 가능해야 함
가시성: 주요 기능을 메인 화면에 노출하여 쉬운 조작이 가능해야 함
표준화: 디자인을 표준화하여 기능구조의 선행 학습 이후 쉽게 사용 가능해야 함
접근성: 사용자의 직무, 연령, 성별 등이 고려된 다양한 계층을 수용해야 함
명확성: 사용자가 개념적으로 쉽게 인지해야 함
오류 발생 해결: 사용자가 오류에 대한 상황을 정확하게 인지할 수 있어야 함

데이터 마이닝

대규모로 저장된 데이터 안에서 체계적이고 자동적으로 통계적 규칙이나 패턴을 찾아내는 기술

암호 키 알고리즘

DES(Data Encryption Standard): 56bit의 키를 이용, 64bit의 평문 블록을 64bit의 암호문 블록으로 만드는 블록 암호 방식의 미국 표준(NIST) 암호화 알고리즘이다.
AES(Advanced Encryption Standard): 고급 암호화 표준이라 불리는 AES 암호 알고리즘은 DES를 대체한 암호 알고리즘이며 암호화와 복호화 과정에서 동일한 키를 사용하는 대칭 키 암호화 알고리즘이다.
SEED: KISA, ETRI에서 개발하고 TTA에서 인증한 안전성, 신뢰성 우수한(3DES보다) 고속 블록 단위의 128bit 대칭 키 암호화 알고리즘이다.
RSA: 현재 비대칭 키 암호방식 중 가장 널리 쓰이는 방식이며 소인수 분해의 어려움을 이용한 방식이다.
디피-헬만(Diffie-Hellman): 암호 키를 교환하는 방법으로 두 사람이 암호화되지 않은 통신망을 통해 공통의 비밀키를 공유할 수 있도록 하는 방식이다.

HRN

대기 중 프로세스 중 우선순위가 가장 높은 것을 선택하는 기법
HRN의 우선순위 = (대기시간 + 서비스 시간) / 서비스 시간

트랜잭션 특징

원자성: 트랜잭션이 DB에 모두 반영되거나, 그렇지 않거나
일관성: 트랜잭션 작업 처리 결과가 항상 일관돼야 하는 것이다. 데이터 타입이 트랜잭션 전후 달라지지 않아야 한다.
격리성: 하나의 트랜잭션은 다른 트랜잭션에 끼어들 수 없고 독립적이다.
지속성: 트랜잭션이 성공적으로 완료되면 영구적으로 결과에 반영돼야 한다.

소프트웨어 개발 보안테스트 유형

정적 분석
- SW를 실행하지 않고 보안 약점 분석
- SW 개발 단계에서 주로 활용
- 취약점 초기 발견으로 수정비용 절감
- 설계·구조 관점 취약점 식별 불가
동적 분석
- SW 실행환경에서 보안 약점 분석
- SW 시험 단계에서 주로 사용
- 소스 코드 필요하지 않음
- 구조 관점 보안약점 식별 불가

비즈니스 연속성 계획(BCP)

비즈니스 연속성 계획은 각종 재해, 장애, 재난으로부터 위기관리를 기반으로 재해복구, 업무복구 및 재개, 비상계획 등을 통해 비즈니스 연속성을 보장하는 체계이다.

주요 용어

BIA(Business Implact Analysis)
- 장애나 재해로 인해 운영상 주요 손실을 볼 것을 가정하여 시간 흐름에 따른 영향도 및 손실평가를 조사하는 BCP를 구축하기 위한 비즈니스 영향 분석
RTO(Recovery Time Objective)
- 업무중단 시점부터 업무가 복구되어 다시 가동될 때까지의 시간
- 재해시 복구 목표시간 선정
RPO(Recovery Point Objective)
- 업무중단 시점부터 데이터가 복구되어 다시 정상가동될 때 데이터의 손실 허용 시점
- 재해시 복구 목표지점 선정
DRP(Disaster Recovery Plan)
- 재난으로 장기간에 걸쳐 시설 운영이 불가한 경우를 대비한 재난 복구 계획
DRS(Disaster Recovery System)
- 재해복구계획의 원활한 수행을 지원하기 위해 평상시 확보해 두는 인적, 물적 자원 및 이들에 대한 지속적 관리체계가 통합된 재해복구센터

OSPF

다익스트라 알고리즘을 이용했으며 대규모 네트워크에 적합하다.
링크 상태 라우팅 프로토콜로도 불린다.

형상관리

개발 과정에서 변경사항을 관리하기 위한 일련의 활동
형상관리 절차
- 형상 식별
  - 형상관리 대상에 이름과 관리 번호를 부여하고, 계층(Tree) 구조로 구분하여 수정 및 추적이 용이하도록 함
- 버전 제어
  - 소프트웨어 업그레이드나 유지보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구(tool)를 결합시키는 작업
- 형상 통제(변경 관리)
  - 식별된 형상항목에 대한 변경 요구를 검토하여 현재의 기준선(Base Line)이 잘 반영될 수 있도록 조정하는 작업
  - 형상 항목의 버전 관리를 위해 변경여부와 변경 활동을 통제하는 작업
- 형상 감사
  - 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업
- 형상 기록(상태 보고)
  - 형상의 식별, 통제, 감사 작업의 결과를 기록 관리하고 보고서를 작성하는 작업

테스트

화이트박스 테스트
- 원시코드를 오픈시킨 상태에서 논리적 모든 경로를 테스트한다(구조 기반 테스트).
테스트 방식
- 문장 커버리지
  - 모든 구문 한 번 이상 수행하도록 항목 설계
- 결정 커버리지(분기 커버리지)
  - 모든 조건문이 참과 거짓에 대한 값을 한 번 이상 출력하도록 항목 설계
- 조건 커버리지
  - 모든 조건문의 True/False 경우에 대해 한 번 이상 수행하도록 항목 설계
- 분기/조건 커버리지
  - 모든 조건문 및 각 조건문에 포함된 개별 조건식의 결과가 True/False인 모든 경우에 대해 한 번 이상 수행하도록 항목 설계
블랙박스 테스트
- 각 기능이 완벽히 작동된다는 것을 입증한다(명세 기반 테스트).
- 구현된 기능을 테스트한다.
- 사용자 요구사항 명세를 보면서 테스트한다.
테스트 방식
- 동치 분할 검사
  - 정상/비정상 입력자료의 개수를 동등하게 하여 테스트 케이스를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인
- 경곗값 분석
  - 경곗값에서 오류가 자주 발생한다는 점을 이용한다.
- 원인-효과 그래프 검사
  - 입력 데이터 간 관계, 출력에 영향 미치는 상황 분석 후 효율성 높은 테스트 케이스 산정
- 오류 예측 검사
  - 테스터의 경험이나 감각으로 테스트
- 비교 검사
  - 동일한 테스트 케이스를 여러 버전의 프로그램에 적용하여 동일한 결과가 출력되는지 비교하는 테스팅 기법
코드 커버리지
- 테스트 수행 결과를 정량적 수치로 나타내는 방법
- 소프트웨어를 이루는 테스트 대상 소스 코드 중 테스트를 통해 실행된 코드의 비율

소스 코드는 구분(Statement), 조건(Condition), 결정(Decision)으로 나뉜다.
구문은 Line과 비슷하고, 조건은 x < 0 같은 조건식, 결정은 조건으로 인해 출력될 수 있는 값이다.

if(x < 10 && y > 5){
    print...
}else{
    print...
}

x < 10 && y > 5란 조건이 있을 때 조건은 x, y에 대한 True/False 4개이고, 결정은 조건식 전체에 대한 참/거짓 결과값으로 2개이다.

구문 커버리지는 else 조건이 있을 때 해당 부분까지 모두 실행되는지 보는 것이다.
조건 커버리지는 조건에 대한 True/False가 수행되었을 때 충족된다.
결정 커버리지는 각 분기 참/거짓 결과가 도출된 것을 두고 판단한다.

뿌엑

이전 포스트

디자인 패턴

다음 포스트