2과목 -3 (필기 개념 정리)

 

 

 

1. 형상 관리 기능

(1) 형상 식별 : 형상 관리 대상에 이름과 관리 번호를 부여 하고, 계층(Tree) 구조로 구분하여 수정 및 추적이 용이 하도록 하는 작업

(2) 버전 제어 : 소프트웨어 업그레이드나 유지 보수 과정에 서 생성된 다른 버전의 형상 항목을 관리하고, 이를 위 해 특정 절차와 도구(Tool)를 결합시키는 작업

(3) 형상 통제(변경 관리) : 식별된 형상 항목에 대한 변경 요 구를 검토하여 현재의 기준선(Base Line)이 잘 반영될 수 있도 조정하는 작업

(4) 형상 감사 : 기준선의 무결성을 평가하기 위해 확인, 검 증, 검열 과정을 통해 공식적으로 승인하는 작업

(5) 형상 기록(상태 보고) : 형상의 식별, 통제, 감사 작업의 결과를 기록·관리하고 보고서를 작성하는 작업

 

 

 

 

 

2. 소프트웨어의 버전 등록 관련 주요 기능

(1) 체크아웃 (Check-Out) : 프로그램을 수정하기 위해 저장소(Repository)에 서 파일을 받아옴

 

(2) 체크인 (Check-In) : 체크아웃 한 파일의 수정을 완료한 후 저장소 (Repository)의 파일을 새로운 버전으로 갱신함

 

(3) 커밋 (Commit) : 체크인을 수행할 때 이전에 갱신된 내용이 있는 경 우에는 충돌(Conflict)을 알리고 diff 도구를 이용해 수정한 후 갱신을 완료함

 

(4) 동기화 (Update) : 저장소에 있는 최신 버전으로 자신의 작업 공간을 동기화함

 

 

 

 

3. 공유 폴더 방식

(1) 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식

(2) 종류에는 SCCS, RCS, PVCS, QVCS 등이 있다.

 

 

 

 

4. 클라이언트/서버 방식

(1) 버전 관리 자료가 중앙 시스템 (서버)에 저장되어 관리되는 방식

(2) 서버의 자료를 개발자별로 자신의 PC(클라이언트)로 복사하여 작업한 후 변경된 내용을 서버에 반영한다.

(3) 종류에는 CVS, SVN(Subversion), CVSNT, Clear Case, CMVC, Perforce 등이 있다.

 

 

 

 

5. 분산 저장소 방식

(1) 버전 관리 자료가 하나의 원격 저장소 와 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관 리되는 방식

 

(2) 개발자별로 원격 저장소의 자료를 자신의 로컬 저장소 로 복사하여 작업한 후 변경된 내용을 로컬 저장소에서 우선 반영(버전 관리)한 다음 이를 원격 저장소에 반영 한다.

(3) 로컬 저장소에서 버전 관리가 가능하므로 원격 저장소 에 문제가 생겨도 로컬 저장소의 자료를 이용하여 작업 할 수 있다.

(4) 종류에는 Git, GNU arch, DCVS, Bazaar, Mercurial, TeamWare, Bitkeeper, Plastic SCM 등이 있다.

 

 

---

 

 

1. Subversion(서브버전, SVN)

(1) 클라이언트/서버 구조로, 서버(저장소, Repository)에 는 최신 버전의 파일들과 변경 내역이 관리된다.

(2) 서버의 자료를 클라이언트로 복사해와 작업한 후 변경 내용을 서버에 반영(Commit)한다.
(3) 모든 개발 작업은 trunk 디렉터리에서 수행되며, 추가 작업은 branches 디렉터리 안에 별도의 디렉터리를 만 들어 작업을 완료한 후 trunk 디렉터리와 병합(merge) 한다.
(4) 커밋(Commit)할 때마다 리비전(Revision)이 1씩 증가 한다.

 

 

 

2. Git(깃)

(1) 리누스 토발즈(Linus Torvalds)가 2005년 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후 주니오 하마 노(Junio Hamano)에 의해 유지 보수되고 있다.

 

 

 

3. 빌드 자동화 도구의 개념

(1) 소스 코드 파일들을 컴파일한 후 여러 개의 모듈을 묶어 실행 파일로 만드는 과정이며, 이러한 빌드를 포함 하여 테스트 및 배포를 자동화하는 도구를 빌드 자동화 도 구라고 한다.

(2) 애자일 환경에서는 하나의 작업이 마무리될 때마다 모 듈 단위로 나눠서 개발된 코드들이 지속적으로 통합되 는데, 이러한 지속적인 통합(Continuous Integration) 개발 환경에서 빌드 자동화 도구는 유용하게 활용된다.
(3) 빌드 자동화 도구에는 Ant, Make, Maven, Gradle, Jenkins 등이 있으며, 이중 Jenkins와 Gradle이 가장 대표적이다.

 

 

 

4. Jenkins

(1) JAVA 기반의 오픈 소스 형태로, 가장 많이 사 용되는 빌드 자동화 도구이다.

 

 

 

 

5. Gradle

(1) Groovy를 기반으로 한 오픈 소스 형태의 자동 화 도구로, 안드로이드 앱 개발 환경에서 사용된다.

 

 

---

 

1. 애플리케이션 테스트의 개념

(1) 확인(Validation) : 사용자의 입장에서 개발한 소프트웨어가 고객 의 요구사항에 맞게 구현되었는지를 확인하는 것

 

(2) 검증(Verification) : 개발자의 입장에서 개발한 소프트웨어가 명세 서에 맞게 만들어졌는지를 점검하는 것

 

 

 

 

2. 애플리케이션 테스트  관련 용어

(1) 결함 집중(Defect Clustering)  : 대부분의 결함이 소수의 특정 모듈에 집중해서 발생하는 것이다.

 

(2) 파레토 법칙(Pareto Principle) : 상위 20% 사람들이 전체 부의 80%를 가지고 있다거나, 상위 20% 고객이 매출의 80%를 창출한다는 의미로, 이 법칙이 애플리케이션 테스트에도 적용된다는 것이다. 즉 테스트로 발견된 80%의 오류는 20%의 모듈에서 발견되 므로 20%의 모듈을 집중적으로 테스트하여 효율적으로 오류를 찾자는 것이다.

 

(3) 살충제 패러독스 (Pesticide Paradox) : 살충제를 지속적으로 뿌리면 벌레가 내성이 생겨서 죽지 않는 현상을 의미한다.

 

(4) 오류-부재의 궤변(Absence of Errors Fallacy) : 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말 할 수 없다는 것을 의미한다.

 

 

 

 

3. 프로그램 실행 여부에 따른 테스트

(1) 정적 테스트 

- 프로그램을 실행하지 않고 명세서나 소스 코드를 대상 으로 분석하는 테스트

- 소프트웨어 개발 초기에 결함을 발견할 수 있어 소프 트웨어의 개발 비용을 낮추는데 도움이 됨

- 종류 : 워크스루, 인스펙션, 코드 검사 등

 

(2) 동적 테스트

(1) 프로그램을 실행하여 오류를 찾는 테스트로, 소프트웨 어 개발의 모든 단계에서 테스트를 수행할 수 있음

(2) 종류 : 블랙박스 테스트, 화이트박스 테스트

 

 

 

 

 

4. 테스트 기반(Test Bases)에 따른 테스트

(1) 명세 기반 테스트 

(2) 구조 기반 테스트 

(3) 경험 기반 테스트

 

 

---

 

1. 목적에 따른 테스트

(1) 회복 (Recovery) 테스트

(2) 안전(Security) 테스트

(3) 강도(Stress) 테스트

(4) 성능(Performance) 테스트

(5) 구조(Structure) 테스트 

(6) 회귀(Regression) 테스트 

(7) 병행(Parallel) 테스트 

 

 

 

2. 화이트박스 테스트(White Box Test)

(1) 모듈의 원시 코드를 오픈시킨 상태 에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스 트 케이스를 설계하는 방법이다. 

(2) 모듈 안의 작동을 직접 관찰한다. 
(3) 원시 코드(모듈)의 모든 문장을 한 번 이상 실행함으로 써 수행된다. 
(4) 프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행함으로써 논리적 경로를 제어한다.

 

 

 

 

3. 화이트박스 테스트의 종류

(1) 기초 경로 검사 (Base Path Testing) : 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법 으로, 테스트 측정 결과는 실행 경로의 기초를 정의하는 데 지침으로 사용됨

 

(2) 제어 구조 검사 (Control Structure Testing) 

- 조건 검사(Condition Testing)
- 루프 검사(Loop Testing) 
- 데이터 흐름 검사(Data Flow Testing)

 

 

 

 

4. 블랙박스 테스트(Black Box Test)

(1) 소프트웨어가 수행할 특정 기능을 알 기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스 트로, 기능 테스트라고도 한다. 

(2) 프로그램의 구조를 고려하지 않기 때문에 테스트 케이 스는 프로그램 또는 모듈의 요구나 명세를 기초로 결정 한다.
(3) 소프트웨어 인터페이스에서 실시되는 테스트이다.
(4) 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구 조나 외부 데이터베이스 접근에 따른 오류, 행위나 성 능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용 되며, 테스트 과정의 후반부에 적용된다.

 

---

 

1. 블랙박스 테스트의 종류

(1) 동치 분할 검사 (Equivalence Partitioning Testing, 동치 클래스 분해)

- 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고, 해당 입력 자료 에 맞는 결과가 출력되는지 확인하는 기법

 

(2) 경계값 분석 (Boundary Value Analysis)

- 입력 자료에만 치중한 동치 분할 기법을 보완 하기 위한 기법
- 입력 조건의 중간값보다 경계값에서 오류가 발생 될 확률이 높다는 점을 이용하여 입력 조건의 경 계값을 테스트 케이스로 선정하여 검사하는 기법

 

(3) 원인-효과 그래프 검사 (Cause-Effect Graphing Testing)

- 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법

 

(4) 오류 예측 검사 (Error Guessing)

- 다른 블랙 박스 테스트 기법으로는 찾아낼 수 없는 오류를 찾아내는 일련의 보충적 검사 기 법이며, 데이터 확인 검사라고도 함

 

(5) 비교 검사 (Comparison Testing)

- 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법

 

 

 

 

 

 

 

2. 단위 테스트(Unit Test)

(1) 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것이다.

(2) 단위 테스트에서는 인터페이스, 외부적 I/O, 자료 구 조, 독립적 기초 경로, 오류처리 경로, 경계 조건 등을 검사한다.
(3) 단위 테스트는 사용자의 요구사항을 기반으로 한 기능 성 테스트를 최우선으로 수행한다.
(4) 단위 테스트는 구조 기반 테스트와 명세 기반 테스트로 나뉘지만 주로 구조 기반 테스트를 시행한다.
(5) 단위 테스트로 발견 가능한 오류 : 알고리즘 오류에 따 른 원치 않는 결과, 탈출구가 없는 반복문의 사용, 틀린 계산 수식에 의한 잘못된 결과

 

 

 

 

 

3. 통합 테스트(Integration Test)

(1) 비점진적 통합 방식

- 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법으 로, 빅뱅 통합 테스트 방식

 

(2) 점진적 통합 방식

- 모듈 단위로 단계적으로 통합하면서 테스트하는 방 법으로, 하향식, 상향식, 혼합식 통합 방식이 있음
- 오류 수정이 용이하고, 인터페이스와 연관된 오류를 완전히 테스트할 가능성이 높음

 

 

 

 

 

4. 시스템 테스트(System Test)

(1) 개발된 소프트웨어가 해당 컴퓨터 시스 템에서 완벽하게 수행되는가를 점검하는 테스트이다

(2) 환경적인 장애 리스크를 최소화하기 위해서는 실제 사 용 환경과 유사하게 만든 테스트 환경에서 테스트를 수 행해야 한다.

(3) 기능적 요구사항과 비기능적 요구사 항으로 구분하여 각각을 만족하는지 테스트한다.