Dev Diary.

2. 소프트웨어 개발

 2.5 인터페이스 구현

 2.5.4 인터페이스 구현 검증

- 인터페이스 구현 검증

1. 설계 산출물

1.1 인터페이스 구현 검증 및 감시 도구

1. 인터페이스 구현 검증 도구

인터페이스 구현을 검증하기 위해서는 인터페이스 단위 기능 및 시나리오에 기바한 통합 테스트가 필요하다. 테스트 자동화 도구를 이용하여 단위 및 통합 테스트의 효율성을 높일 수 있다.

2. 인터페이스 감시 도구

인터페이스 구현이 제대로 동작하는지 확인하기 위해서는 애플리케이션 모니터링 도구를 사용하여 동작 상태를 감시한다.

1.2 인터페이스 구현 검증에 필요한 설계 산출물

1. 인터페이스 명세서

인터페이스 명세서에 정의된 데이터 전송주기, 전송량, 전송 포맷대로 수신 시스템에 데이터가 전송되었는지 확인한다.

2. 인터페이스 단위 및 통합 테스트 설계서

인터페이스 단위 및 통합 테스트 설계서를 활용하여 구현 검증을 진행 한다.

2. 인터페이스 명세서

2.1 인터페이스 명세서 기반 구현 검증

1. 인터페이스 명세서 기반 구현 검증 기법

인터페이스 명세서의 세부 기능을 참조하여 구현 검증 및 감시에 필요한 기능을 분석한다.

2.2 인터페이스 테스트 설계서 기반 구현 검증

1. 인터페이스 테스트 설계서 기반 구현 검증 기법

인터페이스 명세서의 세부 기능을 참조하여 구현 검증 및 감시에 필요한 기능을 분석한다.

2. 인터페이스 테스트 결과 검증 방법

운영 DB 테이블의 건수를 카운트 하는 방법

실제 테이블이나 파일을 열어서 데이터를 확인하는 방법

파일 생성 위치의 파일 생성 여부와 파일 크기를 확인하는 방법

연계서버에서 제공하는 모니터링 화면의 내용을 확인하는 방법

시스템에 기록하는 로그를 확인하는 방법

3. 인터페이스 시스템 로그를 통한 오류 확인

인터페이스 오류는 시스템운영 로그에 기록된다. 인터페이스 오류의 자세한 내역을 알기위해 시스템 관리자나 운영자가 오류 로그를 확인한다.

인터페이스 오류는 관련 테이블에 기록되기도 한다.

2. 소프트웨어 개발

 2.5 인터페이스 구현

 2.5.1 인터페이스 구현 능력 단위 정의

 2.5.2 인터페이스 설계 확인

 2.5.3 인터페이스 기능 구현

- 인터페이스 구현 능력 단위 정의

인터페이스 구현이란 모듈간의 분산이 이루어진 경우를 포함하여 단위 모듈간의 데이터 관계를 분석하고 이를 기반으로 한 매커니즘을 통해 모듈간의 효율적인 연계를 구현하고 검증하는 능력이다.

-인터페이스 설계 확인

1. 인터페이스 기능 확인

1.1 인터페이스 기능 확인 방법

1. 인터페이스 기능 확인이란?

내/외부 모듈간에 연계 기능을 인터페이스 기능이라고 한다.

2. 인터페이스 기능 확인 방법

상세 인터페이스 기능은 인터페이스 설계서를 보고 확인한다.

시스템 정적/동적 기능분석을 통하여 내/외부 인터페이스 기능을 확인한다.

인터페이스 되는 데이터 유형, 값의 범위, 예외처리 규칙을 확인한다.

1.2 인터페이스 설계서를 통한 기능 확인

1. 인터페이스 설계서란?

인터페이스 설계서는 이기종 시스템 또는 컴포넌트 간 데이터 교환 및 처리를 위한 목적으로 각 시스템의 교환 데이터 및 업무, 송/수신 주체 등이 정의 되어 있다.

인터페이스 설계서에는 인터페이스 목록과 인터페이스 명세서가 있다.

2. 인터페이스 목록

인터페이스 목록은 내/외부 인터페이스 대상들을 리스트화 하였다.

3. 인터페이스 명세서

인터페이스 목록에 정의도니 리스트에 대해서 만든 상세 설계서를 말한다.

4. 인터페이스 흐름도

인터페이스 데이터의 흐름을시간 순서로 표현한 것이다.

1.3 정적/동적 기능 분석을 통한 인터페이스 기능 확인

1. 시스템 정적/동적 모형 분석을 통한 인터페이스 기능 확인

시느템 구성요소 간에 트랜잭션을 분석하여 상호 교호나하는 기능에서 인터페이스 기능을 확인한다.

2. 데이터 표준 확인

2.1 인터페이스 데이터 표준 개요

1. 인터페이스 데이터 표준이란?

연계가 되어야 할 범위의 데이터들의 형식과 표준을 정의하는 것이다.

송신과 수신 시스템 간에 데이터 형식이 동일한 경우 공통 영역을 추출하여 표준화를 할 수 있지만 송신과수신 시스템 간에 데이터 형식이 다를 경우 표준화를 위하여 일부 시스템의 데이터 형식 변환이 필요하다.

2. 인터페이스 데이터 표준 확인

인터페이스 구현 전에 개발자는 인터페이스 데이터 표준을 확인한다.

인터페이스 구현 시 데이터 표쥰을 준수하여 구현한다.

Json, DB, XMl 등 다양한 형태로 인터페이스 모듈의 표현이 가능하다.

2.2 송/수신 시스템간 데이터 매핑 방법 확인

1. 송신 시스템 코드를 수신 시스템 코드로 매핑

송/수신 시스템간 데이터가 표준화가 되어 있지 않다면 직접 코드 변환을 위한 코드매핑 테이블을 작성해야 한다.

2. 송/수신 시스템의 코드를 통합하여 표준화 후 매핑

송/수신 시스템 간 데이터 표준화가되어 있다면 이를 기준으로 송신, 수신 시스템 간 코드 매핑 테이블을 작성한다.

2.3 내/외부 인터페이스 기술 표준 확인

1. EAI 방식

기업에서 운영되는 서로 다른 플랫폼 및 애플리케이션들 간의 정보 전달, 연계, 통합을 가능하게 해주는 솔루션이다.

2. ESB 방식

ESB는 애플리케이션 간의 통합 측면에서 EAI와 유사하다고 볼 수 있으나 애플리케이션 보다는 서비스 중심의 통합을 지향하는 아키텍쳐이다.

웹서비스 중심으로 표준화된 데이터, 버스르 통해 이기종 애플리케이션을 유연하게 통합하는 핵심플랫폼 기술이다.

-인터페이스 기능 구현

1. 인터페이스 보안

1.1 인터페이스 보안 취약점

1. 데이터 통신 시 데이터 탈취 위협

인터페이스를 위하여 송/수신 시스템간에 데이터 통신 시 중간에서 통신 내역을 감청하여 데이터를 유출 시킨다.

2. 데이터 통신 시 데이터 위변조 위협

인터페이스를 위하여 송/수신 시스템 간에 데이터 통신 시 데이터의 위/변조 위협

1.2 인터페이스 시큐어 코딩 가이드

1. 인터페이스 보안 기능

민감정보가상화, 필드 암복호화 등 인터페이스 보안 기능 제공

암호화 알고리즘은 DES 보다 AES 알고리즘을 적용한다.

2. 중요 인터페이스 데이터 암호화 저장

개인정보, 금융정보, 패스워드 등 중요 인터페이스 정보는 암호화하여 저장한다.

3. 중요 인터페이스 데이터 암호화 전송

민감한 정보를 통신 채널을 통하여 내보낼 때에는 반드시 암호화 과정을 거쳐야하며, 필요한 경우 SSL 또는 HTTPS 등과 같은 보안 채널을 사용한다.

2. 인터페이스 모듈 구현

구성된 연계 매커니즘에 따라 내외부 연계 모듈 구현을 한다.

내외부 연계 모듈은 EAI방식과 웹 서비스 방식이 가장 많이 사용된다.

2.1 EAI/ESB 방식

1. EAI/ESB 방식이란?

EAI/ESB 방식은 트리거를 자바와 같은 프로그램 언어를 사용한 응용 애플리케이션으로 구현하거나, 연계 테이블 혹은 연계 파일을 이용하여 송신에서 수신시스템으로 전송하는 방식이다.

송신시스템의 운영 데이터베이스에서 트리거를 이용하여 전송할 데이터를 연계 데이터베이스로 전달하면 EAI/ESB Adapter에서 이를 네트워크를 통하여 수신 시스템의 수신 Adapter까지 전송한다. 수신 시스템의 연계 데이터베이스에서는 수신 Adapter로 전송된 데이터를 운영 데이터베이스로 전달한다.

2. 연계 데이터베이스 또는 계정 생성

송신 시스템과 수신 시스템에 연계 데이터베이스와 계정을 생성한다.

운영 데이터베이스의 사용자와 연계를 위한 사용자는 생성되는 스키마의 목적이 다르므로 물리적, 논리적으로 분리하여 관리한다.

3. 연계 테이블 생성

생성한 연계 데이터베이스 사용자 계정으로 연계를 위한 인터페이스 테이블, 송/수신 이력 및 오류 확인을 위한 로그 테이블을 생성한다.

코드 매핑 및 변환을 위한 매핑 테이블, 오류 처리를 위한 오류 코드 테이블 등을 생성한다.

4. 연계 응용 프로그램 구현

송신 시스템에서는 운영 데이터베이스에서 트리거를 구현하여 연계 데이터베이스 전송에 필요한 데이터를 복사한다.

트리거를 사용하지 않고 Java 혹은 C#과 같은 응용 애플리케이션 코드를 이용하여 운영 데이터베이스에서 연계 데이터베이스로 전송 데이터를 복사하기도 한다.

특히 연계 데이터 보안 적용을 위해서는 Java 혹은 C#과 같은 응요 애플리케이션 코드를 이용하여 암호화 알고리즘을 적용한다.

2.2 웹서비스 방식

1. 웹서비스 방식이란?

웹서비스는 데이터의 소비자와 공급자 간에 SOAP, WSDL, UDDI 기술을 이용하여 데이터를 주고 받는 기술이다.

2. 웹서비스 방식의 연계 모듈 구현 환경 구축 절차

송신은 웹서비스 소비자, 수신은 웹서비스 공급자가 된다.

웹서비스 방식은 EAI/ESB방식과는 달리 실제 전송이나 전송 이력에 대한 기록 및 모니터링 기능을 별도로 구현해야한다.

송신 시스템에서는 송신 연계 파일, 로그파일, 오류 로그 파일이 생성될 위치와 파일명을 정의한 후 디렉토리를 생성한다.

수신 시스템에서는 수신 연계파일, 로그파일, 오류 로그 파일이 생성될 위치와 파일명을 정의한 후 디렉토리를 생성한다.

송신 시스템에서 운영DB로 부터 연계 데이터를 추출하여 송신파일을 XML 형식을 생성하는 Java 프로그램을 구현한다.

구현된 서비스는 주기적으로 실행하기 위해서는 운영체제의 크론 또는 데이터베이스 관리 시스템의 잡스케줄러에 등록한다.

3. 연계 파일 전송 및 수신 시스템의 DB반영 서비스 호출 처리

SOAP 프로토콜을 이용하여 송신에서 수신 시스템으로 연계 파일을 전송한다.

SOAP 프로토콜의 SOAP Header 와 Body에 전송하려는 데이터를 넣어서 전송한다. 또는 SOAP Attachment에 파일을 첨부하여 전송하는 방법도 있다.

전송 시스템과 수신 시스템 간에 동일한 WSDL을 작성하여 공유한다. WSDL에는 수신 시스템에 연계 파일을 전송 후 연계 파일의 내용을 수신 시스템 운영 DB에 반여하는 서비스의 위치, 서비스명 등이 기술되어 있다.

4. 수신 시스템의 연계 응용 프로그램 구현

수신 시스템에서는 웹서비스로 전달 받은 파일을 운영 DB에 반영해야 한다. 이를 위하여 Java 혹은 C# 같은 언어를 활용하여 프로그램을 구현하여 반영한다.

3. 소프트웨어 연계 테스트

내외부 연계 모듈 구현에서 소프트웨어 연계 테스트는 송신 시스템간 수신 시스템 간에 연계테스트를 의미한다.

송신 시스템에서 중계 시스템을 거쳐서 수신 시스템까지 연계 하였을 경우 데이터의 정합성 및 데이터 전송 여부를 테스트 한다.

3.1 소프트웨어 연계 테스트

1. 소프트웨어 연계 테스트 구간

소프트웨어 연계 테스트 구간은 송신 시스템에서 연계 서버 또는 중계 서버를 거치고 수신시스템까지 데이터가 전달되는가를 테스트한다.

2. 소프트웨어 연계 단위 테스트

소프트웨어 연계 단위 테스트는 연계 자체만을 테스트한다. 송신 시스템에서 연계 데이터를 추출 및 생성하고 이를 연계 테이블 간 송수신을 한다.

연계 서버 또는 중계 서버에서는 수신 된 연계 테이블을 생성한다.

수신 시스템에서는 연계 테이블에서 연계 데이터를 수신 시스템으로 로드 한다.

최종적으로 수신 시스템의 운영 DB에 반영이 제대로 되는지 테스트 한다.

3. 소프트웨어 연계 통합 테스트

비즈니스 프로세스 흐름에 맞춰 데이터 생성, 전송, 저장까지 한다.

보다 큰 통합 기능 테스트의 일부로서 연계 통합 테스트를 수행한다.

인위적인 조작없이 비즈니스프로세스 흐름에 맞춰 연계 기능을 점검한다.

최종적으로 수신 시스템의 운영 DB에 반영된 데이터를 검색 및 활용한다.

3.2 소프트웨어 연계 테스트 케이스

1. 소프트웨어 연계 테스트 케이스 작성 방법

연계 테스트 케이스는 송신 시스템과 수신 시스템에서 확인해야 할 사항을 각각 도출하며, 송/수신 시스템 각각에서 단순 개별 데이터의 유효값을 체크하는 경우의 수와 데이터 간의 연관 관계를 체크하는 경우의 수로 식별하여 작성한다.

단순 개별 데이터의 유효값은 코드일 경우, 코드 테이블에 등록된 값의 여부 또는 유효 데이터 타입, 길이 ,필수 입력 드으이 체크를 의미한다.

데이터 간의 연관 관계 체크는 연계 서버 또는 중계 서버를 통하여 연관 관계가 주어진 규칙대로 데이터 변환을 시켜 주는지를 점검한다.

2. 송신용 연계 응용 프로그램의 단위 테스트 케이스 작성

송신시스템에서 연계 데이터 추출이 제대로 되었는지, 연계 데이터가 수신시스템에 맞게 코드 변환이 제대로 되었는지 등을 테스트 한다.

3. 연계 통합 테스트 케이스 작성

송신용 연계 응용 프로그램과 수신용 연계 응용 프로그램의 기능 위주 결함을 확인하는 통합 테스트 케이스로 작성한다.

2. 소프트웨어 개발

 2.4 애플리케이션테스트 관리

 2.4.4 애플리케이션 성능 개선

1. 알고리즘

1.1 알고리즘 개요

1. 알고리즘이란?

알고리즘은 수학과 컴퓨터과학, 언어학 또는 관련 분야에서 어떠한 문제를 해결하기 위해 정해진 일련의 절차나 방법을 공식화한 형태로 표현한 것을 말한다.

대부분의 알고리즘은 유한한 수의 규칙에 따라 구별 가능한 기호들을 조작하여 입력 정수에서 출력 정수를 생성하기 위한 일반화된 작업을 정의한다.

2. 알고리즘 기술 방법

자연어, 의사코드, 순서도, 프로그래밍 언어, 인터프리터가 작업하는 제어 테이블, 유한상태 기계의 상태도 등으로 표현할 수 있다.

알고리즘 개발은 문제 정의 -> 모델 고안 -> 명세 작성 -> 설계 -> 검증 -> 분석-> 구현 -> 테스트 -> 문서화의 순서로 개발한다.

3. 알고리즘 구현 사례

가장 단순한 알고리즘 가운데 하나는 임의로 나열된 숫자를 가운데 가장 큰 수를 찾는것이다.

1.2 알고리즘 분류

1. 소프트웨어 구현 시 적용되는 알고리즘

재귀적 알고리즘, 연역적 알고리즘, 결정록적 알고리즘, 근사 알고리즘, 양자 알고리즘 등이 사용된다.

2. 소프트웨어 설계 시 적용되는 알고리즘

무차별 대입 공격, 분할 정복 알고리즘, 그래프 순회, 분기 한정법, 확률적 알고리즘, 리덕션, 백 트래킹 등이 사용된다.

3. 최적화 문제에 적용되는 알고리즘

선형 계획법, 동적 계획법, 탐욕 알고리즘, 휴리스틱 함수 등이 사용된다.

4. 이론적 분야에 적용되는 알고리즘

검색 알고리즘, 정렬 알고리즘, 수치 알고리즘, 그래프 알고리즘, 문자열 알고리즘, 암호학적 알고리즘, 기계학습, 데이터압축 등이 사용된다.

1.3 알고리즘 복잡도 측정

1. O(1)

n에 관계없이 일정시간 이하에서 수행되는 알고리즘이다

예) 파일의 첫 번쨰 바이트가 널인지 검사하는 것

2. O(log n)

log2n에 비례하는 시간 이하에 수행되는 알고리즘이다.

예) 이진 탐색

3. O(nlogn)

n에 대략 비례할 수 있는 시간 이하에 수행되는 알고리즘이다.

예) 정렬 알고리즘

4. O(n2)

n2에 비례하는 시간 이하에 수행되는 알고리즘이다.

예) 최장 공통 부분 수열 문제

5. O(n3)

n3에 비례하는 시간 이하에 수행되는 알고리즘이다.

1.4 정렬 알고리즘

1. 정렬 알고리즘이란?

여러원소로 구성된 리스트에서 이 원소들을 크기 순서대로 재배치하는 것

2. 선택 정렬

최소원소를 찾아 제자리에 위치시키는 기법 

3. 버블 정렬

왼쪽부터 모든 인접한 두 키를 비교한 후 왼쪽의 키가 더 크면 오른쪽의 키와 자리바꿈을 통하여 정렬해 나가는 방법

4. 삽입 정렬

왼쪽부터 모든 인접한 두 키를 비교한 후 왼쪽의 키가 더 크면 오른쪽의 키와 자리바꿈을 통하여 정렬해 나가는 방법

5. 기수 정렬

낮은 자리수부터 비교하여 정렬해 간다는 것을 기본 개념으로 하는 정렬 알고리즘이다. 기술정렬은 비교 연산을 하지 않으며 정렬 속도가 빠르지만 데이터 전체 크기에 기수 테이블의 크기만한 메모리가 더 필요하다.

2. 소스코드 품직 분석 도구

2.1 소스코드 품질분석 도구 개요

1. 소스코드 품질분석 도구란?

소스코드에 대한 코딩 스타일, 설정된 코딩 표준, 코드의 복잡도, 코드 내에 존재하는 메모리 누수 현황, 스레드의 결함 등을 발견하기 위하여 사용하는 분석 도구이다.

소스 코드 품질 분석도구는 정적 분석 도구와 동적 분석 도구가 있다.

2. 정적 분석 도구

작성된 소스 코드를 실행시키지 않고, 코드 자체만으로 코딩 표준 준수 여부, 코딩 스타일 적정 여부, 잔존 결함 발견 여부를 확인하는 코드 분석 도구이다.

사전에 결함을 발견하고 예방하는 도구, 코딩 표준 준수 여부를 분석하는 도구, 소스 코드의 복잡도를 계산하는 도구 등이 있다.

3. 동적 분석 도구 

애플리케이션을 실행하여 코드에 존재하는 메모리 누수 현황을 발견하고, 발생한 스레드의결함 등을 분석하기 위한 도구이다.

3. 코드 최적화

3.1 소스코드 최적화 개요

1. 소스코드 최적화를 해야 하는 이유

소스코드 최적화는 읽기 쉽고 변경 및 추가가 쉬운 클린코드를  작성하는 것으로, 소스코드 품질을 위해 기본적으로 지킬 원칙과 기준을 정의하고 있다.

소스 코드는 지속적으로 변경이 되는데, 소프트웨어 구조와 실행 시간 및 자원 사용량 측면에서 비효울적인 형태로 변경이 될 수 있다. 이 때문에 소스코드는 지속적으로 최적화를 해야 한다.

2. 나쁜 코드

나쁜 코드는 다른 갭라자가 로직을 이해하기 어렵게 작성된 코드이다. 대표적인 사례로 처리 로직의 제어가 정제되지 않고 서로 얽혀 있는 스파게티 코드, 변수나 메소드에 대한 이름 정의를 알 수 없는 코드, 동일한 처리 로직이 중복되게 작성된 코드 등이 있다.

이러한 나쁜 코드가 많아질 경우 잦은 오류가 발생할 가능성이 높다.

소스코드 이해가 안되어 유지보수 비용이 높아진다.

3. 외계어 코드

아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드를 의미한다.

4. 클린 코드

잘 작성되어 가독성이 높고, 단순하며, 의존성을 줄이고, 중복을 최소화하여 깔끔하게 잘 정리된 코드를 말한다.

클린 코드가 많을 수록 애플리케이션 설계가 개선된다.

가독성이 높으므로 유지보수비가 낮아지고, 변경 속도가 빠르다.

3.2 소스코드 최적화 기법

1. 클래스 분할 배치 기법

클래스는 하나의 역할, 책임만 수행할 수 있도록 응집도를 높이고, 크기를 작게 작성한다.

2. 클래스 간 느슨한 결합 기법

클래스의 자료 구조, 메소드를 추상화할 수 있는 인터페이스 클래스를 이용하여, 클래스간의 의존성을 최소화 한다.

3. 코딩 형식 기법

코딩 시 줄바꿈을 확실히 지켜야 한다.

호출하는 함수를 먼저 배치하고, 호출되는 함수는 나중에 배치한다.

변수 선언 위치를 지역 변수는 각 함수 맨 처음에 선언한다.

함수간에 주고하는 파라메터는 이름만 보고도 어떠한 파라메터인지 파악할 수 있도록 이름을 부여한다.

변수 이름은 기억하기 좋은 이름, 발음이 쉬운 용어, 접두어 사용 등 기본적인 명명 규칙을 정의한다.

4. 주석문 사용을 습관화

코딩 시 항상 주석문을 사용하여 다른 개발자가 이해하기 쉽도록 설명한다.

3.3 아키텍처 조정을 통한 코드 최적화 

1. SpringMVC 구조 활용

SpringMVC는 사용자 화면 계층에 적용하면 코드 최적화에 도움이 된다.

디스패처 서블릿은 Spring MVC 프레임워크의 Front Controller, 웹 요청과 응답의 수명주기를 주관하는 컴포넌트이다.

핸들러매핑은 웹 요청시 해당 URL에 매핑되는 컨트롤러를 검색, 결정하는 컴포넌트이다.

컨트롤러는 비즈니스 로직을 수행하고 결과를 Model And View에 반영하는 컴포넌트이다.

모델앤뷰 는 수행 결과와 반영하는 모델 데이터 객체, 이동할 페이즈 정보 및 뷰로 이루어져 있다.

뷰리졸버는 결과를 표시할 어떤 뷰를 선택할지 결정한다.

뷰는 결과 데이터인 모델 객체를 표현한다.

2. 팩토리 메소드 패턴 활용

객체의 생성과 사용을 분리함으로써 소프트웨어의 의존성을 최소화 하기 위하여 팩토리 메소드 패턴을 이용하여 성능 개선을 한다.

3.4 프로그램 호출 손서 조정을 통한 성능 개선

1. 호출하는 프로그램을 먼저, 호출 당하는 프로그램을 나중에 작성

호출하는 함수를 먼저 코딩하고, 호출되는 함수는 나중에 배치한다.

2. 루프 내 불필요한 메소드 호출이 반복되지 않도록 코딩

루프 내에서 메소드의 호출이 반복되는 코드를 루프 진입 전에 호출하도록 소스코드를 수정한다.

3.5 리팩토링 기법

1. 리팩토링 이란?

코드의 외부 행위는 바꾸지 않고 내부 구조를 개선시켜 소프트웨어 시스템을 변경하는 프로세스이다.

이는 버그 발생의 기회를 최소화 시켜주는 코드 정화 방법이다.

3.6 성능 검사

1. 성능 검사란?

시스템 검사의 종류 중 통합 시스템의 맥락에서 소프트웨어의 실시간 성능을 비교 검사하며, 모든 단계에서 수행된다.

2. 소프트웨어 개발

 2.4 애플리케이션테스트 관리

 2.4.3 애플리케이션 통합 테스트

1. 결함관리 도구

1.1 테스트 결함 관리란?

각 단계별 테스트 수행 후 발생한 결함의 재발 방지를 위해, 유사 결함 발견시 처리 시간 단축을 위해 결함을 추적하고 관리하는 활동이다.

테스트 결함 관리 도구는 이러한 결함관리를 자동화하는 도구이다.

1.2 결함 관리 도구 도입시 고려사항

웹 클라이언트 지원을 하는지 확인이 필요하다.

윈도우, 유닉스 환경 등 이기종 플랫폼의 웹 서버를 지원하는지 확인

프로세스 및 워크플로우 변경이 가능해야 한다.

결함 간에 연관관계 정보를 제공해야 한다.

예를들면 중복, 관계,부모관계 등

결함 등록 및 상태 변경 시 담당자에게 이벤트 통보기능이 되어야한다.

각종 레포트, 차트, 쿼리 구성 및 저장이 가능해야 한다.

결함 상태 변경에 대한 추적 기능이 되어야 한다.

다국어 지원이 가능해야 한다.

다중 프로젝트 지원이 가능해야 한다.

2. 테스트 자동화 도구

2.1 소프트웨어 테스트 자동화 란?

소프트웨어 개발 시 포함되는 다양한 테스트 과정을 하드웨어 혹은 소프트웨어적으로 자동화 도구를 사용하여 반복성, 일관성 및 생산성을 향상시키는 테스트 기법이다

테스트 자동화 도구는 테스트에 포함되는 다양한 과정을 자동적으로 지원하는 도구이다.

2.2 소프트웨엉 테스팅 도구 분류

소프트웨어 개발 사이클(SDLC) 전반에 걸쳐 테스트 자동화 도구가 존재한다.

소프트웨어 설꼐 단계에는 테스트 케이스 설계 자동화 도구가 사용되고, 구현 및 테스트 실행 단계에서는 정적/동적 분석도구, 커버리지 측정 도구 및 성능/부하/기능 테스트 도구가 사용된다.

2.3 소프트웨어 테스팅 자동화 도구 기능 및 역할

테스트 관리, 설계, 실행 단계별 테스트 자동화 도구의 기능 및 역할이 각각 다르다.

2.4 소프트웨어 테스트 관리 지원 도구

실행된 테스트와 테스트 활동 관리를 지원한다. 테스트 실행 도구나 결함 추적 도구, 요구사항 관리 도구와의 인터페이스 역할을 한다.

결함이 발견, 분배, 수정, 확인, 종료되는 결함의 수명주기를 관리한다.

테스트 진행 상황에 대한 리포트 생성, 발견도니 결함의 정량적인 분석을 지원한다.

2.5 소프트웨어 정적 분석 지원 도구

리뷰 프로세스에 관한 정보를 저장, 리뷰 코멘트를 저장한다.

정적 분석 도구는 동적 테스트를 하기 전에 결함을 발견할 수 있도록 지원한다.

특히, 코딩 표준을 지킬 것을 강제하고, 구조와 의존관계를 분석한다.

소스 코드의 복잡도를 측정한다.

2.6 소프트웨어 테스트 실행 및 로깅 지원 도구

스크립트언어의 도움으로 저장된 입력값과 예상 결과를 이용하여 테스트를 실행하고 실제 결과와 비교한다.

Capture and playback 도구라고도 한다.

테스트 대상이 실행되는 환경을 시뮬레이션 한다. 테스트 하네스 도구라고도 한다.

측정하고자 하는 특정 유형의 코드구조가 몇퍼센트 수행되었는가를 측정한다. 커버리지 측정 도구라고도 한다.

2.7 소프트웨어 성능 및 모니터링 도구

소프트웨어가 실행도중에만 발생하는 시간 의존성과 메모리 누수와 같은 결함 발견에 활용한다.

소프트웨어의 성능/부하/스트레스를 테스트한다.

특정 시스템 리소스의 사용량을 지속적으로 분석하고 확인한다.

3. 통합테스트

3.1 애플리케이션 통합 테스트 개요

1. 애플리케이션 통합 테스트란?

소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법이다.

단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인한다.

2. 애플리케이션 통합 테스트 수행 방법

점증적인 방법과 빅뱅 방식으로 나누어 진다.

점증적인 방식은 개발된 컴포넌트 중 일부를 테스트하고 점차적으로 컴포넌트를 늘려가면서 테스트하는 방식이다. 점증적인 방법은 다시 상향식 통합과 하향식 통합으로 나누어 진다.

빅뱅 방식은 모든 컴포넌트를 사전에 통합하여 한꺼번에 테스트하는 방식이다.

3.2 애플리케이션 통합 테스트 접근 전략

1. 하향식 통합

메인 제어 컴포넌트부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향식으로 통합하면서 테스트를 진행한다.

메인 제어 컴포넌트는 작성된 프로그램을 사용하고, 아직 작성되지 않은 하위 제어 컴포넌트 및 모든 하위 컴포넌트를 대신하여 더미 컴포넌트인 스텁을 개발한다.

깊이-우선 방식 또는 너비-우선 방식에 따라, 하위 컴포넌트인 스텁이 한 번에 하나씩 실제 컴포넌트로 대체된다.

2. 상향식 통합

애플리케이션 구조에서 최하위 레벨의 컴포넌트로부터 위쪽방향으로 제어 경로를 따라 이동하면서 테스트를 시작한다.

최하위 레벨의 컴포넌트들이 하위 컴포넌트의 기능을 수행하는 클러스터로 결합된다.

상위 컴포넌트 개발이 안되었을 경우 더미 컴포넌트인 드라이버를 작성한다.

각 통합된 클러스터 단위를 테스트한다.

테스트가 완료되면 각 클러스터들은 프로그램의 위쪽으로 결합되며, 드라이버는 실제 컴포넌트로 대체된다.

3.3 애플리케이션 통합 테스트 유형

1. 회귀 테스트

통합 테스트 과정에서 오류를 제거하거나 수정한 프로그램이 새로운 형태의 오동작이나 오류를 일으킬 수 있다.

회귀 테스트는 이미 통합 테스트를 완료한 컴포넌트가 어떠한 변화로 인해 의도하지 않은 오류가 생기지 않았음을 보증하기 위해 반복 테스트하는 것을 말한다.

2. 애플리케이션 회귀 테스트 선정 기준

실제 수정이 발생한 컴포넌트와 관련된 테스트 케이스를 도출한다. 이를 위하여 변경 관리 도구를 사요하여 애플리케이션 변경 영향도 분석을 한다.

변경 영향도가 가장 높은 컴포넌트 기능에 집중한 회구 테스트 케이스를 도출한다.

3. 사용 기반 vs 스레드 기반 테스트

사용 기반 테스트는 사용자 중심의 시나리오 기반 테스트이다.

스레드 기반 테스트는 주요 기능의 모듈부터 점차 범위를 넓혀 나가는 통합 테스트 기법이다.

4. 빅뱅 vs 점증적 테스트

빅뱅 테스트는 모든 모듈을 한꺼번에 테스트하는 기법이다.

점증적 테스트는 주요 기능을 먼저 테스트 후 점차 범위를 넓혀가는 테스트이다.

3.4 애플리케이션 통합 테스트 수행 절차

1. 통합 테스트 케이스 설계

단위 테스트 케이스를 비즈니스 시나리오에 따라 여러 개를 묶고 이어서 통합 테스트 케이스를 만든다.

통합 테스트 케이스는 사용자 요구사항을 기준으로 작성한다.

2. 통합 테스트 데이터 준비

통합 테스트 데이터는 운영 데이터베이스에서 일부를 추출하여 테스트 데이터를 만든다.

예를들면, 운영.DB에서 1개우러 전까지의 데이터를 추출하여 테스트 DB에 전달한다.

보안을 위하여 테스트 데이터에서 개인정보는 스크램블링 한다.

3. 통합테스트 수행 및 결과 확인

테스트 수행 시 1개월 전부터 현재까지의 데이터를 애플리케이션에 그대로 입력하여 레거시와 비교검사를 한다.

테스트 케이스에 따라 데이터를 입력하고 예상 결과와 비교하낟.

4. 결함등록

테스트 결과가 예상 결과와 다를 경우 결함 등록을 한다.

이때, 결함 화면을 캡처하여 붙인다.

5. 테스트 결과 보고 및 종료

모든 통합 테스트 수행이 완료되면 결과 집계하여 보고하고, 종료한다.

3.5 애플리케이션 통합 테스트 시작 및 종료 기준

1. 통합 테스트 시작 기준

통합 테스트를 시작할 수 있는 기준을 정한다.

2. 통합 테스트 종료 기준 

통합 테스트를 종료할 수 있는 기준 수립이 필요하다. 

2. 소프트웨어 개발

 2.4 애플리케이션테스트 관리

 2.4.1 애플리케이션테스트 관리 능력 단위 정의

 2.4.2 애플리케이션 테스트케이스 설계

- 애플리케이션테스트 관리 능력 단위 정의

애플리케이션 테스트 관리란 요구사항대로 응용소프트웨어가 구현되었는지를 검증하기 위해서 테스트케이스를 작성하고 개발자 통합 테스트를 수행하여 애플리케이션의 성능을 개선하는 능력이다.

- 애플리케이션 테스트케이스 설계

1. 소프트웨어 테스트 개요

1.1 소프트웨어 테스트의 개념

1. 소프트웨어 테스팅이란?

소프트웨어 테스트랑 구현된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능의 동작과 성능, 사용성, 안정성 등을 만족하는지 확인하기 위하여 소프트웨어의 결함을 찾아내는 활동이다.

소프트웨어 테스트는 검사 혹은 확인 활동이라고도 한다.

검사 활동은 개발 결과가 원래의 요구사항을 만족하는지를 점검하는 활동을 의미한다.

2. 소프트웨어 테스트 프로세스

테스트 프로세스 유형은 다양하다. 테스트 계획 수립 단계와 수행 단계, 그리고 결과 보고 단계에 따라 테스트 프로세스 유형은 달라진다.

계획 수립 단계에서는 테스트 계획 수립 프로세스와 테스트 시나리오 및 케이스 관리 프로세스가 있다.

테스트 수행 단계의 대표적인 프로세스는 테스트 환경 관리, 테스트 수행관리, 코드 커버리지 관리, 형상 및 배포 관리 프로세스가 있다.

테스트 결과 단계에서는 테스트 결과 검토  프로세스가 있다.

1.2 소프트웨어 테스트의 기본 원칙

1. 테스팅은 결함이 존재함을 밝히는 활동이다.

테스팅은 소프트웨어의 잠재적인 결함을 줄일 수 있지만, 결함이 발견되지 않아도 결함이 없다고 증명할 수 없음을 나타낸다.

2. 완벽한 테스팅은 불가능하다.

무한경로, 무한입력 값, 무한 시간이 소요되어 완벽하게 테스트할 수 없으므로 리스크 분석과 우선순위를 토대로 테스트에 집중할 것을 의미한다.

3. 테스팅은 개발 초기에 시작해야 한다.

애플리케이션 개발 단계에 테스트를 계획하고 SDLC의 각 단계에 맞춰 전략적으로 접근하는 것을 고려하라는 뜻이다.

4. 결합 집중

애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다는 의미이다.

5. 살충제 패러독스

동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 한다.

6. 테스팅은 정황에 의존한다.

정황과 비즈니스 도메인에 따라 테스트를 다르게 수행하여야 한다.

7. 오류-부재의 궤변

이 세상에 어떠한 소프트웨어도 오류가 완벽하게 해소된 제품을 만들어 낼 수 없음을 의미한다. 테스트는 오류를 100

% 없애는 것이 목적이 아니라 일정수준이하로 줄이는 것이 목표이다.

2. 테스트 케이스

2.1 테스트 케이스의 개념

특정한 프로그램의 일부분 또는 경로에 따라 수행하거나, 특정한 요구사항을 준수하는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서를 말한다.

2.2 테스트 케이스의 작성 절차

테스트 케이스의 정확성, 재사용성, 간결성 보장을 위해 아래의 절차에 따라 작성한다.

1. 테스트 계획 검토 및 자료 확보

테스트 대상 프로젝트 범위와 접근 방법 이해를 위하여 테스트 계획을 재검토한다.

테스트 대상 시스템 자료와 정보를 확보하여, 시스템 요구사항과 기능 명세서를 검토한다.

2. 위험 평가 및 우선순위 결정

결함 해결에 있어 상대적 중요성을 지니며 테스트의 초점을 결정한다.

3. 테스트 요구사항 정의

시스템의 요구사항, 테스트 대상 재검토, 테스트할 특성,조건, 기능을 식별 및 분석한다.

4. 테스트 구조 설계 및 테스트 방법 결정

테스트 케이스의 일반적 형식을 결정하고, 테스트 케이스 분류 방법을 결정한다.

테스트 절차, 장비, 도구, 테스트 문서화 방법을 결정한다.

5. 테스트 케이스 정의

각 요구사항에 대해 테스트 케이스를 작성하고, 입력값, 실행조건, 예상 결과를 기술한다.

6. 테스트 케이스 타당성 확인 및 유지보수

기능 또는 환경 변화에 따라 테스트케이스를 갱신하고, 테스트 케이스의 유용성을 검토한다.

3. 테스트 오라클

3.1 테스트 오라클의 개념

테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법 및 활동을 말한다.

3.2 테스트 오라클의 유형

1. 참 오라클

모든 입력값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클이다.

2. 샘플링 오라클

특정한 몇 개의 입력 값에 대해서만 기대하는 결과를 제공해주는 오라클이다.

3. 휴리스틱 오라클

샘플링 오라클을 개선한 오라클로, 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱으로 처리하는 오라클이다.

4. 일관성 검사 오라클

애플리케이션 변경이 있을 때 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클이다.

3.3 테스트 오라클 적용 방안

참 오라클은 주로 항공기, 임베디드 발전소 소프트웨어 등 미션 크리티컬한 업무에 적용하고, 샘플링/추정 오라클은 일반, 업무용, 게임, 오락 등의 일반적인 업무에 적용한다.

4. 테스트 레벨

4.1 단위 테스트

구현된 단위 모듈의 기능 수행 여부를 판정하고 내부에 존재하는 논리적 오류를 검출한다.

4.2 통합 테스트

모듈 간의 인터페이스 연계를 검증하고 오류를 확인, 모듈 간의 상호 작용 및 연계동작이 제대로 기능하는지 점검한다.

4.3 시스템 테스트

단위, 통합 테스트 후 전체 시스템이 정상적으로 작동하는지 판정하는 기능을 점검한다.

4.4 인수 테스트

사용자 요구분석 명세서에 명시된 사항을 모두 충족하는지 판정하고 시스템이예성대로 동작하고 있는지 점검한다.

1. 알파 테스트

개발자의 장소에서 사용자가 개발자 앞에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 검사하는 기법 즉 개발자 환경에서 테스트하는 기법

2. 베타 테스트

다수의 사용자를 제한하지 않은 환경에서 프로그램을 사용하게 하고 오류가 발견되면 개발자에게 통보하는 방식

즉 사용자 환경에서 테스트하는 기법

5. 테스트 시나리오

5.1 테스트 시나리오 개요

1. 테스트 시나리오란?

테스트 수행을 위한 여러 테스트 케이스의 집합으로서, 테스트 케이스의 동작 순서를 기술한 문서이며 테스트를 위한 절차를 명세한 문서이다.

2. 테스트 시나리오 작성 시 유의점

테스트 항목을 하나의 시나리오에 모두 작성하지 않고, 시스템별, 모듈별, 항목별 테스트 시나리오를 분석하여 작성한다.

고객의 요구사항과 설계 문서 등을 토대로 테스트 시나리오를 작성한다.

각 테스트 항목은 식별자 번호, 순서 번호, 테스트 데이터, 테스트 케이스, 예상 결과, 확인등의 항목을 포함하여 작성한다.

5.2 테스트 시나리오 프로세스

1. 테스트 시나리오 관리 프로세스

테스트 실행을 하기 위해서는 테스트 시나리오를 만들어야 한다.

2. 테스트 시나리오 도출

테스트 시나리오는 업무 기반으로 도출하기 때문에 설계자는 업무 전문가가 많다.

테스트 시나리오는 업무 기반으로 도출한다.

업무 흐름에 따라서 시나리오를 스토리리텔링 하듯이 도출한다.

3. 테스트 케이스 도출

테스트 시나리오가 만들어 지면 이를 가지고 테스트 케이스를 도출한다.

테스트 케이스는 테스트 시나리오를 짧은 문장으로 나누어서 쉽게 테스트 할 수 있도록 만들 수행절차이다.

4. 테스트 케이스 검토 및 보완

테스트 케이스가 만들어 지면 품질관리자와 테스트 리더가 검토를 한다.

5. 테스트 케이스 피어리뷰

테스트 케이스 피어 리뷰는 테스트 케이스가 시나리오에 맞게 작성이 되었는지 검토한다.

사용자 요구사항을 테스트할 수 있게 작성이 되었는지 점검한다.

6. 테스트 케이스 업로드

테스트 케이스가 문제없이 만들어 졌으면 테스트 관리 시스템에 업로드한다.

6. 테스트 지식 체계

6.1 개념과 정의

전체 시리즈에 대한 가이드를 제공해주는 부분이다.

소프트웨어 테스팅 개념

조직과 프로젝트 관점에서의 소프트웨어 테스팅

소프트웨어 생명주기 모델에서의 일반적인 테스팅 프로세스

위험 기반 테스팅

테스트 서브 프로세스

6.2 테스트 프로세스

조직, 테스트 관리, 동적 테스트의 3가지 수준의 다계층 프로세스 모델을 설명한다.

다계층 프로세스 모델

조직의 테스트 프로세스

테스트 관리 프로세스

동적 테스트 프로세스

6.3 테스트 문서화

테스트 프로세스 단계별 산출물의 견본제스 및 작성방법을 설명한다.

조직의 테스트 프로세스 문서

테스트 관리 프로세스 문서

동적 테스트 프로세스 문서

6.4 테스트 기법

1. 화이트박스 실행 기법

소스코드를 보면서 소스코드의 실행을 변겨하면서 검사하는 기법

기본경로, 반복경로 검사, 제어구문 검사, 데이터 흐름 검사 등이 있음

2. 블랙박스 실행 기법

소스코드 참조없이 외부에 드러난 인터페이스만을 이용하여 검사하는 기법

동등분할, 경계값분석 기법, 원인효과 그래프 기법 및 결정트리 기법 등이 있음.

3. 동등분할 기법 

입력값의 범위를 유사한 특징을 갖는 동등 그룹으로 나누고, 각 그굷마다 대표 값을 선정하여 테스트케이스를 선정하는 기법

예를들어 100점 만점에 0~100점을 받을 수 있는 시험에 대해서 시험 점수를 입력하면 점수에 따라 A~F 까지 성적을 출력하는 테스트케이스를 선정한다고 가정한다.

즉 90점 이상 100점 이하면 A를 출력한다.

80~90 B

70~80 C

0~70 F 출력일때 동등분할 기법에 의해서 테스트 케이스를 선정한다면

4. 경계값분석 기법

경계값 분석은 등가 분할된 경계의 유효한 값과 경계에서 가장 가까운 유효하지않는 값을 테스트 데이터로 선택하여 컴포넌트나 시스템을 테스트하는 기법이다.

경계값 분석은 등가 분할 기법을 확장하여 등가 분할 내에 있는 임의의 값이 아닌 분할된 영역에 있는 값을 테스트 데이터로 이용하여 보다 많은 결함을 발견하는 테스트케이스를 작성하는 기법이다.

5. 원인 효과 그래프 기법

입력값을 원인으로, 효과를 출력값으로 정하고 이에 따른 원인 결과 그래프를 만들어서 테스트 케이스를 작성하는 기법

6. 결정트리 기법

입력값과 출력값을 트리형태로 만들어서 특정 입력값에 따라서 결정되는 출력 값이 정해지도록 만든 테스트 케이스 작성 기법 

7. 명세기반 기법

테스트 케이스를 프로그램 명세서를 기반으로 테스트 케이스를 선정하여 테스트하는 기법

동등 분할 기법, 경계값 분석, 결정 테이블 기법, 상태전이 테스트, 유즈케이스 테스트, 페어와이즈 테스트, 직교 배열 테스트 기법이 여기 속한다.

8. 경험기반 기법

프로그램 명세서와 같은 산출물 없이 테스터의 경험을 기반으로 테스트수행하는 기법

탐색적 테스트, 즉흥적 테스트, 분류 트리기법 등이 있다.

6.5 키워드 주도 테스팅

사전 정의된 키워드의 모음으로 테스트 케이스를 만드는 것이다.

테스트 단계에서 자연어 대신 키워드를 사용함으로써 테스트 케이스는 이해하기 쉽고 유지보수가 용이하다.

2. 소프트웨어 개발

 2.3 제품소프트웨어 패키징

 2.3.4 제품소프트웨어 버전관리

1. 소프트웨어 버전관리 도구

1. 소프트웨어 버전관리 도구 개요

1. 소프트웨어 버전관리 도구란?

형상관리 지침을 활용하여 제품 소프트웨어의 신규 개발, 변경, 개선과 관련된 수정 내역을 관리하는 도구이다.

버전관리 도구를 활용하여 시장에 출시되는 제품 소프트웨어의 버전과 변경, 개선 내역을 히스토리로 관리한다.

2. 소프트웨어 버전관리 도구 유형

초기의 소프트웨어 버전관리 도구는 공유 폴더 방식이었다.

최근에는 클라이언트/서버 방식과 분산 저장소 방식이 많이 사용된다.

공유 폴더 방식 (RCS, SCCS)

매일 개발 완료 파일은 약속된 위치의 공유 폴더에 복사

담당자 한명이 ㅐ일  공유 폴더의 파일을 자기 PC로 복사하고 컴파일하여 에러 확인과 정상동작여부 확인

클라이언트/서버 방식 (CVS, SVN)

중앙에 버전 관리 시스템이 항시 동작

개발자들의 현재 작업 내용과 이전 작업내용 축적이 용이

서로 다른 개발자가 같은 파일을 작업했을 때 경고출력

분산 저장소 방식(Git, Bitkeeper)

로컬 저장소와 원격저장소 구성됨

중앙의 저장소에 로컬에 복사한 순간 개발자 자신만의 로컬저장소에 생성

개발 완료한 파일 수정 이후 로컬 저장소에 커밋한 이후 다시 원격저장소에 반영하는 방식

3. 소프트웨어 버전관리 도구별 특징

현재 개별 프로젝트에서 가장 많이 사용하는 소프트웨어 버전관리 도구는  SVN이다.

세계적으로 오픈 소스 기반의 소프트웨어 버전 관리도구는 Git이 가장 많이 사용된다.

1.2 소프트웨어 버전관리 도구 사용시 유의점

1. 형상관리 지침에 의거 버전에 대한 정보를 언제든지 접근할 수 있어야 함

프로젝트 단위 접근 혹인 파일 단위 접근이던 간에 개발자가 원하는 때에 언제든 소프트웨어 소스에 접근이 가능해야 한다.

2. 개발자 배포자 이외에 불필요한 사용자가 소스 접근할 수 없도록 해야함

중요한 파일 혹은 폴더에 대한 접근은 개발자, 배포자만 접근해야 한다.

만일 신입 사원이 접근하여 허가 없이 수정한다면 그 동안 개발된 소스 버전이 수정될 위험이 존재한다.

3. 동일한 프로젝트 파일에 대해서 여러 개발자가 동시 개발 할 수 있어야함

여러 개발자가 동일한 파일, 폴더에 접근 시 동시에 파일 수정이 일어나더라도 개발자의 수정 내역이 통합 될 수 있어야 한다.

4. 에러 발생 시 최대한 빠른 시간 내에 복구 필요

소프트웨어 버전에 오류 발생 시 개발자가 신속하게 알고 최대한 빠르게 복구할 수 있어야한다.

과거 버전의 소스를 가지고 신속하게 원복 할 수 있어야한다.

1.3 제품소프트웨어에 소프트웨어 버전관리 도구 활용방안

1. 공동 개발 및 작업 관리

동일 버전의 소스 코드를 두 명 이상의 개발자가 수정할 수 있도록 한다.

분산환경에서 두명 이상의 개발자가 동일한 버전의 소스를 수정할 경우 향후 소스 누락없이 통합을 할 수 있어야 한다.

2. 버전 백업 및 복구

이전 버전으로의 복구 필요 시 혹인 이전 버전의 기능을 재활용 시 버전 관리 도구를 활용한다.

3, 여러 버전 솔루션 작업

하나의 솔루션을 기반으로 여러 버전의 제품을 동시 개발할 경우 활용

2. 빌드 자동화 도구

2.1 소프트웨어 빌드 자동화 도구 개요

1. 소프트웨어 빌드 자동화 도구란?

제품 소프트웨어 실행파일 생성을 자동화하기 위해서 저장소에 있는 소스를 자동으로 읽어서 빌드를 하여 실행 파일을 만드는 도구이다.

빌드 자동화 도구는 지속적인 통합과도 일맥상통한다.

수없이 반복해서 최종 결과물을 만들어내야 하는 소프트웨어 개발업무에서 빌드자동화 도구는 반드시 갖추어야 한다.

2. 온란인 빌드 자동화 도구, 젠킨스

젠킨스는 빌드 자동화 도구로서 가장 많이 활용되는 도구이다.

Java 기반의 오픈소스로 지속적 통합관리를 가능하게 한다.

Apache-tomcat과 같은 서블릿 컨테이너 서버 기반으로 구동되는 시스템이며, CVS, SVN,Git 등 다양한 버전관리 도구를 지원한다.

Ant, Maven 기반의 프로젝트 뿐 아니라 임의의 쉘 스크립트와 윈도우 배치 명령까지 실행시킬 수 있다.

3. 안드로이드 환경에 적합한 도구 그래들

C나 C++언어는 보통 Makefile, Java는 Ant,Maven, Scala는 sbt를 빌드 자동화 도구를 주로 사용하는데 오픈소스인 그래들은 여러가지 언어의 빌드 환경을 구성할 수 있다.

그래들은 주로 안드로이드 개발환경에서 빌드 자동화 도구로 사용되고, C++,Swift,Object C, Haskell, Scala 등의 언어도 플러그인 설정하면 빌드가 가능하다.

그래들 스크립트는 groovy를 사용해서 만든 DSL이다. 모든 그래들 스크립트는 두가지 개념을 구성되어 있는데 Project와 tasks 이다.

모든 그래들 빌드는 하나 이상의 project로 구성된다. 각 project는 하나 이상의 task들로 구성되어 있다. 이 task는 어떤 클래스를 컴파일하거나 JAR을 생성하거나 javadoc을 만드는 작업을 의미한다.

2. 소프트웨어 개발

 2.3 제품소프트웨어 패키징

 2.3.3 제품 소프트웨어 매뉴얼 작성

1. 제품 소프트웨어 매뉴얼 작성

1.1 제품 소프트웨어 매뉴얼 개요

제품소프트웨어 매뉴얼은 설치 매뉴얼과 사용자 매뉴얼이 있다.

1.2 제품소프트웨어 설치 매뉴얼

1. 제품소프트웨어 설치 매뉴얼이란?

사용자가 제품 구매 후 최초 설치 시 참조하는 매뉴얼이다.

제품 소프트웨어 소개, 설치 파일, 설치 절차 등이 포함된다.

2. 제품소프트웨어 설치 매뉴얼의 기본 작성 항목

목차 및 개요 : 매뉴얼 전체 내용에 대한 요약

문서 이력 정보 : 매뉴얼 변경 이력 정보

설치 도구 구성 : exe/dll/ini/chm 등 설치 관련 파일 설명

설치 위치 지정 : 설치 폴더와 설치 프로그램 실행 파일 설명

설치를 위한 환경 체크 항목

3. 제품소프트웨어 설치 매뉴얼 구성요소

제품 소프트웨어의 설치 방법을 순서대로 상세하게 설명한다. 주로 화면을 계속 캡쳐하여 사용자가 이해하기 쉽도록 구성한다.

설치화면은 exe 등 install 파일을 실행하도록 화면을 첨부한다.

설치 실행 시 표시되는 내용 및 안내창에 대한 메시지를 설명한다.

4. 제품소프트웨어 설치 매뉴얼 작성 순서

기능 식별 : 제품 소프트웨어의 개요 및 기능들을 식별한다.

UI분류 : 화면 단위로 작성될 UI를 분류한다.

설치/백업 파일 확인 : 설치 파일 및 백업 파일명 확인 및 폴더위치를 확인한다.

Uninstall 절차 확인 : 제품 제거 시 uninstall파일을 설명한다.

이상 Case 확인 : 설치 진행 시 이상 메시지 등에 대한 발생 시 조치 방안을 기술한다.

최종 매뉴얼 적용 : 최종 설치 정상 완료 시 결과를 캡쳐 후 최종 매뉴얼에 적용한다.

1.3 제품소프트웨어 사용자 매뉴얼 작성

1. 제품소프트웨어 사용자 매뉴얼이란?

개발이 완료된 소프트웨어를 고객에게 전달하기 위한 형태로 패키징하고, 설치와 사용에 필요한 제반 절차 및 환경 등 전체 내용을 포함한다.

제품소프트웨어에 대한 패치 개발과 업그레이드를 위해 버전 관리를 수행한다.

2. 제품소프트웨어 사용자 매뉴얼 작성 순서

• 작성 지침 정의
• 사용자 매뉴얼 구성요소 정의
• 구성 요소별 내용 작성
• 사용자 매뉴얼 검토

3. 제품소프트웨어 사용자 매뉴얼 작성 항목 

주로 화면을 계속 캡처하여 사용자가 이해하기 쉽도록 구성한다.

주요 기능을 설명할 화면을 첨부한다.

제품 소프트웨어 동작 시 함께 동작하는 App이나 설치되어 충돌될 수 있는 응용프로그램에 대해 보여준다.

제품 소프트웨어 동작 시 사전에 실행해야할 App이 있으면 기술한다.

제품 소프트웨어가 Embedded관련된 제품을 경우 해당 Device에는 어떤 것이 있는지, 연동되는 Device에는 무엇이 있는지 설명한다.

2. 국제 표준 제품 품질 특성

2.1 국제 표준 제품 관련 품질

1. 국제 표준 제품 품질 특성의 분류 

제품 품질 표준과 프로세스 품질 표준으로 나뉜다.

소프트웨어 제품 패키지 품질은 ISO/IEC 12119를 참조한다.

ISO/IEC 12119는 소프트웨어의 품질 평가를 위해 정보기술과 소프트웨어 패키지에 대한 품질 요구사항 및 시험사항을 규정한 국제 표준이다.

1. ISO/IEC 12119 평가 절차

ISO/IEC 12119는 주로 패키지 소프트웨어에 대한 품질 평가에 적용한다.

2. ISO/IEC 14598

ISO/IEC 14598는 ISO 9126 규정에 따른다.

ISO/IEC 14598은 개발자에 대한 소프트웨어 제품 품질 향상과 구매자의 제품 품질 선정 기준을 제공한다.

2. 소프트웨어 개발

 2.3 제품소프트웨어 패키징

 2.3.1 제품소프트웨어 패키징 능력 단위 정의

 2.3.2 제품소프트웨어 패키징

- 제품소프트웨어 패키징 능력 단위 정의

제품소프트웨어 패키징이란 개발이 완료된 제품소프트웨어를 고객에게 전달하기 위한 형태로 패키징 하고, 설치와 사용에 필요한 제반 절차 및 환경 등 전체 내용을 포함하는 매뉴얼을 작성하며, 제품 소프트웨어에 대한 패치 개발과 업그레이드를 위해 버전 관리를 수행하는 능력이다.

- 제품 소프트웨어 패키징

1. 애플리케이션 패키징

1.1 애플리케이션 패키징 개요

1. 애플리케이션 패키징이란?

애플리케이션 패키징은 개발이 완료된 소프트웨어를 고객에게 전달하기 위하여 패키징, 설치 및 사용 매뉴얼을 작성하는 활동이다.

2. 애플리케이션 패키징 특징

애플리케이션 패키징은 개발자가 아닌 사용자 중심으로 진행된다.

신규 및 변경 개발 소스를 식별하고, 이를 모듈화하여 상용 제품으로 패키징한다.

고객 편의를 위해, 신규/변경 이력을 확인하고, 이를 버전 관리 및 릴리즈 노트를 통해 지속적으로 관리해간다.

사용자의 실행 환경을 이해하고, 범용 환경에서 사용이 가능하도록 일반적인 배포 형태로 분류하여 패키징이 진행된다.

1.2 사용자 중심의 애플리케이션 패키징

1. 사용자 실행 환경 이해

고객 편의성을 위해 사용자 실행 환경을 우선 고려한다 운영체제 , 실행 환경, 시스템 사용, 개발 언어, 고객의 사용방법 까지 상세 분석하여 실행 환경을 사전 정의한다.

다양한 실행 환경이 나오면 별도의 애플리케이션 패키징 작업이 필요하다.

2. 사용자 관점의 애플리케이션 패키징 고려 사항

사용자 운영체제, 시스템 사양 등 최소환경

직관적인 화면을 고려하고 매뉴얼과 일치시켜 패키징 작업을 하낟.

애플리케이션은 하드웨어와 함꼐 통합 적용될 수 있도록, 패키징은 Managed Service 형태로 제공한다.

다양한 사용자 요구사항을 반영하기 위해 패키징 변경 및 개선 관리를 고려한다.

1.3 애플리케이션 패키징 순서

1. 기능 식별

신규 개발 소스의 목적 및 기능을 식별한다.

입출력 데이터 , 전체적인 기능 정의 및 데이터 흐름을 식별한다.

2. 모듈화

모듈 단위 분류 및 모듈화를 순서에 맞게 진행한다.

수행을 위한 기능 단위 및 서비스 분류와 패키징 개념에서의 기능의 공유와 재활용 단위를 수행한다.

3. 빌드 진행

애플리케이션 빌드 도구를 활용한 빌드를 단위별로 진행한다.

신규 개발 소스 및 컴파일 결과물을 준비한다.

빌드 도구 확인 및 정상 수행여부를 확인한다.

4. 사용자 환경 분석

고객 편의성을 위한 사용자의 요구사항 및 사용 환경을 사전에 분석한다.

사용자 pc 운영 체제, 서버 사양, 네트워크 환경 등을 분석한다.

5. 패키징 적용 시험

최종 패키징에 대해서 사용자 입장에서 불편한 점을 체크한다.

사용자 환경과 똑같은 환경에서 패키징 적용을 해본다.

화면 사용 및 시스템 사의 편의성을 체크한다.

6. 패키징 변경 개선

사용자 입장을 반영하여 패키징에서 변경 및 개선을 진행한다.

사용자 최소 pc사양에서 서비스 가능한 수준의 개선 포인트를 도출한다.ㅇ자에게전

1.4 애플리케이션 릴리즈 노트

1. 애플리케이션 패키징 릴리즈 노트란?

애플리케이션 최종 사용자에게 전달되는 제품에 대한 공유 정보이다.

애플리케이션 패키징 버전별 릴리즈 노트는 제품의 주요 변경 사항을 담고있다.

2. 애플리케이션 패키징 릴리즈 노트 작성 항목

릴리즈 노트는 애플리케이션 최종 사용자에게 전달되는 제품에 대한 공유 정보이다.

2. 애플리케이션 배포 도구

애플리케이션 배포 도구란 배포를 위한 패키징 시에 디지털 컨텐츠의 지적 재산권을 보호하고 관리하는 기능을 제공하며, 안전한 유통과 배포를 보장하는 도구이자 솔루션이다.

2.1 애플리케이션 배포 도구 활용시 고려사항

1. 반드시 암호화/보안을 고려한다.

2. 추가로 다양한 이기종 연동을 고려한다.

3. 사용자 편의성을 위한 복잡성 및 비효율성 문제를 고려한다.

4. 애플리케이션의 종류에 적합한 암호화 알고리즘을 적용한다.

5. 지속적 배포 고려

3. 애플리케이션 모니터링 도구

제품소프트웨어 패키징에서 애플리케이션 모니터링 도구가 필요한 이유는 사용자 환경에 제품소프트웨어가 설치되었을 때에 애플리케이션 성능을 모니터링하여 제품의 장애를 미리 예방하기 위함이다.

3.1 애플리케이션 모니터링 도구

1. 애플리케이션 모니터링 도구(APM)

제품소프트웨어를 사용자 환경에 설치 후 기능 및 성능 운영 현황을 파악하는 도구이다.

2. 애플리케이션 모니터링 도구 기능

변경관리, 성능관리 및 정적분석 등 기능수행

4. DRM

4.1 DRM 개요

1. DRM이란?

각종 미디어의 접근 및 사용권한을 서버 인증을 통해 중앙집중식으로 통제하는 것을 말한다.

2. DRM 특징

저작권자와 콘텐츠 유통업자 사이의 거래구조 투명성을 제공한다.

사용가능 횟수, 유효기간, 사용환경 등의 사용 규칙을 제공한다.

이메일, 디지털미디어, 네트워크 등을 통한 자유로운 상거래를 제공한다.

3. DRM 구성

DRM은 컨텐츠 제공자와 컨텐츠 소비자, 클리어링 하우스로 구성된다.

컨텐츠 분배자는 제공자로부터 컨텐츠를 받아서 소비자에게 유통 시킨다.

4. 모바일 DRM 

무선 디지털 컨텐츠 유통시장에서 컨텐츠 및 지적 재산원을 보호하는 기술

스마트폰 os에 의존적이다.

2. 소프트웨어 개발

 2.2 통합 구현

  2.2.3 통합 구현 관리

- IDE 도구

통합개발환경은 코딩, 디버그, 컴파일, 배포 등 프로그램 개발에 과련된 모든 작업을 하나의 프로그램 안에서 처리하는 환경을 제공하는 소프트웨어이다.

1.1 IDE 도구 기능

1. 개발 환경 지원

C++ Java 등의 언어를 이용하여 애플리케이션을 개발할 수 있는 환경을 제공한다.

2. 컴파일 및 디버깅 기능 제공

소스코드 코딩이 완료되면 이를 컴파일하여 문법에 어긋나지 않는지 확인하고, 오류가 발생하면 이를 추적하여 수정할 수 있는 디버깅 기능을 제공한다.

3. 외부 연계모듈과 통합 기능 제공

EAI, ESB 등 외부 인터페이스 모듈과 통합을 통하여 통합 개발 기능 제공 

JDBC, ODBC 등을 통하여 데이터베이스 연동을 통한 통합 개발 기능 제공

외부형상, 배포 관리 기능과 연계되어 소스 코드의 형상관리 및 자동 배포가능

-협업도구

하나의 소프트웨어 개발 프로젝트에 수십 명에서 수천 명의 개발자가 참여하기 때문에 그들간의 협업을 위한 도구가 필요하다. 특히, 통합 구현 관리를 위하여 개발자 간 협업 도구가 필요하다.

개발자 간에는 전문 분야, 경험, 개인적 목표가 다르기 때문에 다른 의견이 나오는 것은 당연하다.

다른개발자와 유대감을 형성하거나 유지하기 위해 지속적으로 커뮤니케이션을 해야한다. 

1.1 협업도구 분류

1. 통합 구현에 협업도구 필요성

구현 기간 동안 다양한 개발자들과 실시간 커뮤니케이션 필요

개발 및 작업 일정, 소스, 아키텍처가 수시로 변경되기 때문에 이에 대해서 개발자 간에 공유가 되어야한다.

여러 개발자들의 아이디어를 공유해야 품질이 높아진다.

1.2 협업도구 기능

1. 개발자간 커뮤니케이션

개발자간 작업 공유, 오류 현상 공유, 의견 공유 등 다양한 의사 소통 제공

2. 일정 및 이슈 공유

소스 코드 구현 도중 발생하는 오류 및 이슈에 대한 공유 혹은 프로젝트 일정에 대한 공유 기능

3. 개발자간 집단 지성 활용

구현 아이디어의 공유 혹은 새로운 아이디어를 개발자들간에 공유 함으로써 집단 지성을 활용한다.

- 형상관리 도구

소프트웨어 구현이 진행되는 동안 소스코드 및 문서에 대한 형사은 지속적으로 변한다. 이에 대한 관리를 위하여 형상관리 도구가 필요하다.

특히 내외부 연계 모듈 통합 구현을 위해서는 형상관리 도구가 필요하다.

형상관리는 소프트웨어 변경 사항을 관리하기 위해서 형상식별, 형상 통제, 형상 감사, 형상 기록을 수행한다.

1.1 소프트웨어 형상관리 개요

1. 소프트웨어 형상 관리란

소프트웨어 형상 관리는 소프트웨어 개발 과정에서 발생하는 변경을 관리하는 활동이다.

소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보장하는 것을 목적으로 한다.

2. 소프트웨어 형상 관리 대상

소스 코드와 실행파일, 그리고 각종 설계 문서가 형상 관리 대상이다.

또한 각종 프로그램 개발과 관련된 회의록 등 문서화된 자료도 형상 관리 대상이다.

3. CCB

형상 관리를 위하여 구성된 팀을 CCB 라고 한다.

1.2 소프트웨어 형상관리 도구 기능

1. 체크아웃 : 형상관리 저장소로부터 최신 소프트웨어 형상을 개발자pc로 다운로드 받는 기능이다.

2. 체크인 : 개발자가 수정한 소스를 형상관리 도구로 업로드하는 기능이다.

3. 커밋 : 개발자가 소스를 형상관리 도구에 업로드 후 최종적으로 업데이터가 되었음을 알릴 때에 형상관리 서버에서 반영하도록 하는 기능이다.

1.3 소프트웨어 형상관리 도구

1. 소프트웨어 형상관리 도구란?

형상 관리 도구는 소스코드나 문서의 버전관리, 이력관리, 추적 등 변경사항을 체계적으로 관리할 수 있는 기능을 제공하는 도구이다.

가장 널리 사용되는 도구는 CVS, Git 이 대표적이다.

2. CVS 

가장 오래된 형상 관리 도구 중의 하나로서 중앙 집중형 서버 저장소를 두고 클라이언트가 접속해서 버전 관리를 실행한다.

주요 기능은 체크아웃, 체크인/업데이트, 커밋 등 서버 저장소와 클라이언트의 변경 사항 전송, diff를 통한 파일 내용 비교, 파일 단위의 변경 사항 관리이다.

3. SVN

CVS와 같은 중앙 집중형 클라이언트-서버 방식이지만 CVS의 단점ㅇ을 보완하여 현재 가장 널리 사용되고 있는 형상관리 도구이다.

SVN은 CVS를 대체하기 위해 만든 도구로서 그 개념과 사용법이 CVS와 유사하여 CVS 사용자가 어렵지않게 SVN을 도입하여 사용 가능하다.

4. Git

Git은 앞서 나왔던 CVS나 SVN과는 개념이 많이 다른 형상 관리 도구로서, 공개 SW 커뮤니티를 중심으로 사용 저변이 많이 확대되고 있다.

Git는 중압 집중형 방식이 아닌 분산형 방식으로 각 로컬pc에 스스로 완전한 저장소가 구성되며, 필요에 따라 중앙 집중형 방식으로도 운영할 수 있다.

2. 소프트웨어 개발

 2.2 통합 구현

  2.2.1 통합 구현 능력 단위 정의

  2.2.2 모듈 구현

- 통합 구현 능력 단위 정의

통합구현이란 모듈간의 분산이 이루어진 경우를 포함하여 단위 모듈간의 데이터 관계를 분석하여 이를 기반으로 한 매커니즘을 통해 모듈간의 효율적인 연계를 구현하고 검증하는 능력이다.

- 모듈 구현

1. 단위모듈 구현

통합 구현에서 단위 모듈 구현은 모듈간의 분산이 이루어진 경우를 포함하여 비즈니스 컴포넌트, 내외부 인터페이스 모듈, 데이터베이스 접근 모듈 등 통합 구현에 필요한 단위 컴포넌트 구현을 말한다.

1.1 단위모듈 구현

1. 단위모듈 종류

통합 구현에서 단위모듈 구현은 상세 설계 된 단위모듈, 환경 변수를 실제 프로그래밍 언어로 구현하는 것이다.

단위 모듈은 화면 모듈, 화면에서 입력받은 데이터 처리를 위한 서비스 컴포넌트, 비즈니스 트랜잭션 컴포넌트가 있다.

데이터베이스 접근 컴포넌트, 내외부 인터페이스 컴포넌트, 데이터 암복호화 컴포넌트가 있다.

2. 공통모듈 구현

공통모듈은 모든 서비스 컴포넌트 혹은 트랜잭션 컴포넌트가 공통적으로 사용하는 컴포넌트이다.

내외부 인터페이스 컴포넌트, DB접근 컴포넌트, 암복호화 컴포넌트가 공통모듈의 예이다.

화면에서의 공통모듈은 스크립트로 구현하는데, 날짜 계산, 주소정보, 주민번호, 정합성 체크 컴포넌트 등이 그 사례이다.

공통모듈을 먼저 구현하고 이를 단위모듈 구현 시 재사용한다.

3. 단위모듈 구현 시 고려사항

응집도는 높이고 결합도는 낮춘다.

공통모듈 구현을 먼저 개발하고, 개별 단위 모듈 구현 시 이를 재사용한다.

항상 예외처리 로직을 고려하여 구현한다.

1.2 화면 구현

1. HTML 5

웹 어플리케이션에서 화면 단위 모듈화 프로그래밍은 일반적으로 HTML 5를 기반으로 구현된다.

HTML 5는 온라인, 모바일, 패드 등에서 수정없이 자유롭게 재사용할 수 있다.

2. 반응형 웹

반응형 웹은 모바일 환경이 시작되면서 장치도 다양해져 해상도의 크기 및 비율이 제각각 다른 경우에 이를 자유롭게 지원하는 웹 기술이다.

리액트, 뷰, 앵귤러 같은 웹 컴포넌트를 많이 활용하여 반응형 웹을 구현한다.

1.3 클린코드

1. 클린코드란?

클린코드란 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽게 만든 코드이다.

클린코드는 단순하고 직접적이며, 잘 쓴 문장처럼 읽힌다. 클린코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.

2. 클린코드의 특징

• 가독성이 뛰어남
• 간단하고 작다
• 의존성을 최대한 줄였다
• 코드의 의도와 목적이 명확하다.
• 코드가 타인에 의해 변경이 용이하다.
• 코드에 중복이 없거나 적다
• 개체가 한가지 작업만 수행한다.

2. 단위모듈 테스트

단위모듈 구현이 완료되었으면 단위모듈 테스트를 한다. 단위모듈 테스트를 위해서는 IDE 도구를 활용하여 단위모듈 하나하나에 대한 디버깅을 수행한다.

단위모듈 테스트는 화이트박스 테스트 기법을 사용한다. 화이트박스 테스트 기법은 프로그램의 로직을 이해하고 내부 구조화 동작을 검사하는 소프트웨어 테스트 방식이다.

2.1 단위모듈 테스트 방법

1. 화이트박스 테스트 

단위 모듈 테스트의 가장 기본적인 방법은 모듈 내부의 소스를 보면서 수행하는 화이트박스 테스트이다.

소스 코드를 보면서 테스트 케이스를 다향하게 만들어서 테스트 한다.

2. 메소드 기반 테스트

단위 모듈의 외부의 공개된 메소드 기반 테스트이다.

메소드에 파라미터 값을 다르게 호출하면서 다양한 테스트를 수행한다.

3. 화면 기반 테스트

사용자용 화면이 있는 경우 각각의 화면단위로 단위모듈 개발 후 화면에 직접 데이터를 입력하여 테스트를 수행한다.

화면 기반 테스트는 화면과 연계된 서비스 컴포넌트, 비즈니스 컴포넌트 및 공통 컴포넌트를 한꺼번에 단위 테스트에 참여 시킬 수 있다.

사용자 시나리오에 기반한 단위 모듈 테스트를 할 수 있어서 장점이다.

4. 타 모듈 개발이 안된 경우 스텁과 드라이버 활용

사용자용 화면이 없는 경우 스텁 혹은 드라이버를 활용하여 단위모듈을 테스트 한다.

서비스 컴포넌트, 비즈니스 컴포넌트 등 하위 모듈 개발이 안된 경우에도 스텁과 드라이버를 활용하여 단위 테스트를 한다.

2.2 소스코드 커버리지

1. 소스코드 커버리지 개념

프로그램의 테스트 수행 정도를 나타내는 값으로 테스트 수행의 완벽성을 측정하는 도구이다.

2.3 단위모듈 디버깅

1. IDE 도구를 활용한 디버깅

Eclipse 혹은 Window visual studio같은 IDE도구를 활용하여 단위 모듈에 대한 디버깅을 실시한다.

디버깅 시 에러가 나온 코드에 대해서 로직을 따라가면서 변수 값의 변화를 관찰한다.

2. 단위테스트 자동화 도구를 활용한 디버깅

JUnit : Java 기반의 단위 모듈 테스트 자동화 도구이다.

CppUnit : C++언어 기반의 단위 트스트 자동화 도구

unitest : python에서 단위 테스트를 수행하기 위한 자동화 도구