Part 01. 정보시스템 기반 기술 | Chapter 07. 테스트

Section 01. 통합 구현 도구

1. 소프트웨어 형상 관리(SCM)의 의미
- 소프트웨어 개발 과정에서 발생하는 산출물의 변경 사항을 버전 관리하기 위한 일련의 활동

 

2. Git(형상 관리 도구)
- 중앙 집중 방식이 아닌 분산형 방식
- PUSH, Fetch, PULL 등을 사용하여 원격 저장소에 변경 사항을 송수신할 수 있음
- 공개 소프트웨어 커뮤니티 중심으로 사용하는 개발자가 많이 확대되고 있는 도구

# Third party : 중간자란 의미로 플랫폼, 콘텐츠 개발자를 의미
# SVN : 현재 업계의 표준으로 사용되고 있으며 CVS의 단점을 보완한 방식이며 CVS 대체 도구이기 때문에 CVS 사용자도 쉽게 도입하여 사용할 수 있음
# CVS : 가장 오랫동안 사용한 형상 관리 도구로 중앙 집중형 서버 저장소에 클라이언트가 접속해서 버전 관리를 실행

 

3. 제품 소프트웨어 패키징의 형상 관리란?
- 배포본 관리가 용이
- 변경 내용을 관리하는 것이 형상 관리 목적
- 특정 시점의 버전을 다시 사용할 수 있도록 관리하는 체계
- 변경 관리도 용이하고, 오류가 발생했을 때 빠른 시간 내에 복구도 가능

 

4. 형상 관리 도구의 주요 기능
- 체크인, 체크아웃, 커밋, IMPORT, EXPORT, UPDATE

 

Section 02. 애플리케이션 테스트

1. 워크 스루
- 검토회의 전에 요구사항 명서세를 미리 배포하여 사전 검토한 후 짧은 검토회으를 통해 오류를 조기에 검출하는 데 목적을 두는 요구사항 검토 방법

# 빌드 검증 : 빌드는 소스 코드 파일을 컴퓨터에서 실행할 수 있는 제품 소프트웨어의 단위로 변환하는 과정이나 결과물을 말함, 빌드 검증은 이를 검증하는 작업
# Peer Review(동료 검토) : 2~3명 정도의 검토 담당자가 수행하는 검토로 이해 관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행됨
# 개발자 검토 : 개발자가 검증하는 작업

 

2. 소프트웨어 품질 보증을 위한 정형 기술 검토의 지침 사항
- 논쟁과 반박을 제한하라.
- 의제의 제한성 : 의견을 제한하되 충분히 받아들인다.
- 제품의 검토에 집중하라.
- 참가자의 수를 제한하라.

 

3. 소프트웨어 테스트 원칙
- 완벽한 테스트는 불가능하다.
- 개발자가 테스트하지 않는다.
- 테스트는 결함을 밝히는 활동이다.
- 테스트는 계획 단계부터 해야 한다.

 

4. Pareto의 법칙 : 소프트웨어 테스트에서 오류의 80%는 전체 모듈의 20% 내에서 발견된다는 법칙

# Brooks의 법칙 : 프로토타입 소프트웨어는 폐기 처분하는 첫 번째 시스템으로 개발 일정이 지연된다고 해서 말기에 새로운 인원을 투입하면 일정이 더욱 지연됨
# Boehm : COCOMO 소프트웨어 개발 비용 산정 방법을 제안한 사람
# Jackson : 자료 구조 중심 설계 방법론을 제안한 사람

 

5. Pesticide Paradox : 동일한 테스트 케이스로 반복 실행하면 더 이상 새로운 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 점검하고 개선해야 한다는 것

# Defect Clustering(결함 집중) : 소프트웨어 결함은 대부분 소수의 특정한 모듈에 집중되어 있음
# Absence of Errors Fallacy(오류-부재의 궤변) : 사용자의 요구사항을 만족하지 못한다면 오류를 발견하고 제거해도 품질이 높다고 말할 수 없음
# Walk-Through : 소프트웨어 생명주기의 각 단계마다 산출된 명세서를 가지고 오류를 찾아내는 비정형 검토회의

 

6. 소프트웨어 검사 단계
- 단위(코드) -> 통합(설계) -> 요구사항 검사 -> 시스템 검사

 

7. 테스트 기법의 분류
- 분석 기법, 설계 기법, 실행 기법, 자동화 기법

 

8. 동적 분석 테스트
- 테스트 분석 기법에 해당됨
- 프로그램의 실행을 요구하는 테스트
- 화이트박스 테스트와 블랙박스 테스트
- 프로그램의 내부를 보면서 테스트를 수행

# 정적 테스트 방법 : 인스펙션, 코드 테스트, Walk-Through

 

Section 03. 단위 테스트

1. White Box Testing
- 기초 경로 테스트(Base Path Testing)는 화이트박스 테스트 기법
- Source Code의 모든 문장을 한 번 이상 수행함으로써 진행됨
- 모듈 안의 작동을 직접 관찰할 수 있음
- 산출물의 각 기능별로 적절한 프로그램의 제어 구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 점검

# Boundary Value Analysis(경계값 테스트)는 블랙박스 테스트 기법

 

2. 블랙박스 검사를 통해 발견할 수 있는 오류?
- 성능 오류
- 부정확한 기능
- 인터페이스 오류

# 논리 구조상의 오류(참과 거짓을 판단)는 화이트박스 검사에서 발견할 수 있음

 

3. 블랙박스 테스트의 유형
- 동등(균등) 분할, 경계값 테스트, 오류 예측, 원인 결과 그래프, 비교 테스트

# 화이트박스 테스트 : 기초 경로 테스트, 루프 테스트, 데이터 프름 테스트, 조건 테스트

 

4. McCabe에 의해 제한한 소프트웨어의 복잡성 측정에 대한 설명
- 영역은 그래프의 평면에서 둘러 쌓여진 부분으로 묘사될 수 있다(= 원과 간선으로 그려진 부분에서 간선으로 둘러싸여진 부분으로 복잡성을 측정)
- 영역의 수는 경계된 영역들과 그래프 외부의 비경계 지역의 수를 계산(= 간선으로 둘러싸여진 부분과 그렇지 않은 부분 1개를 추가하여 구한다)
- 서브 프로그램을 만들어진 하나의 모듈 크기, 즉 서브 프로그램의 명령어 라인 수는 100라인 정도로 제한하고 있음
- V(G)는 영역의 수를 결정함으로써 계산되어진다(간선으로 둘러싸여진 부분을 세어 복잡도를 구한다)

 

Section 04. 통합 테스트

1. 하향식 통합 테스트
- 깊이 우선 방식 또는 너비 우선 방식이 있음
- 상위 컴포넌트를 테스트하고 점증적으로 하위 컴포넌트를 테스트
- 하위 컴포넌트 개발이 완료되지 않은 경우 스텁(stub)을 사용하기도 함

# 상향식 통합 테스트 : 중요 모듈 우선, 클러스터(하위 모듈 그룹), 드라이브 사용

 

2. Stub(가짜 모듈) : 하향식 통합에 있어서 모듈 간의 통합 시험을 위해 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈(모듈명만 있고 모듈 안에 프로그램은 존재하지 않는 모듈)

# Driver(시험 가동기) : 독립적인 실행을 위해서 임시적으로 사용하는 시험 가동기
# Procedure와 Function : 부품화된 프로그램으로 부분 기능, 모듈, 서브루틴에 해당. Procedure와 Function 프로그램 언어마다 혹은 사용하는 문법에 따라 다르게 사용되지만 같은 개념

 

3. 상향식 통합 검사(Botton-up Integration Test)의 과정
① 낮은 수준의 모듈들을 클러스터로 결합
② 드라이버라는 제어 프로그램의 작성
③ 클러스터의 검사
④ 드라이버를 제거하고 클러스터를 상위로 결합

 

Section 05. 시스템 테스트

1. 알파 검사(알파 테스트)
- 검증(Validation) 검사 기법 중 개발자의 장소에서 사용자가 개발자 앞에서 해당하는 기법, 일반적으로 통제된 환경에서 사용자와 개발자가 함께 확인하면서 수행되는 검사(개발자 장소에서 사용자가 테스트)

# 베타 테스트 : 사용자 장소에서 사용자가 테스트

 

2. 인수 테스트 : 알파, 베타 테스트와 가장 밀접한 연관이 있음

 

3. 테스트 오라클(Oracle)의 종류
- 참 오라클, 샘플링 오라클, 휴리스틱(Heuristic) 오라클, 일관성 테스트(Consistent) 오라클

# False 오라클은 X

 

Section 06. 성능 분석 및 품질 평가

1. 성능 측정 지표
- 처리량(Throughput), 응답 시간(Response Time), 경과 시간(Turnaround Time = 반환 시간), 자원 사용률(Resource Usage)

# Performance는 X

 

2. 모니터링의 도구의 기능
- 성능/부하/스트레스 점검 도구의 기능(장애진단/ 성능 저하 원인 분석/용량 산정)

# 경과 시간은 X

 

3. 소스 코드 품질 분석 도구 중 정적 분석 도구의 종류
- pmd, cppcheck, checkstyle

 

4. 성능 저하 원인
- 데이터 베이스 잠금
- 부적절한 연결 풀 크기
- 트랜잭션 처리 중 확정(Commit)이 되지 않고 연결 풀(Pool)에 반환될 때
- 커서를 옮기는 작업이 빈번한 경우

 

5. Persfective Maintenance(완전화 보수/기능 개선)
- 소프트에어 유지보수 유형 중 현재 수행 중인 기능의 수정, 새로운 기능의 추가, 전반적인 기능 개선 등의 요구를 사용자로부터 받았을 때 수행되는 유형으로서, 유지보수 유형 비용 비율 중 50%를 차지함

 

6. 외계인 코드(Alien Code)
- 아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램을 의미
- 대부분 개발 시에 문서화를 하지 않았거나 개발자가 없거나 비구조적으로 작성한 경우들을 말함

 

7. 소프트웨어 품질 측정을 위해 개발자 관점에서 고려해야 할 항목
- 품질 목표 항목 : 정확성/신뢰성(=소프트웨어 품질 목표 중 주어진 시간 동안 주어진 기능을 오류 없이 수행하는 정도)/효율성/무결성/유지보수 용이성/사용 용이성(=소프트웨어를 쉽게 사용할 수 있는 정도)/검사 용이성/이식성(=다양한 하드웨어 환경에서도 운용할 수 있도록 쉽게 수정될 수 있는 정도)/상호 운용성/유연성/재사용성

 

8.
MTBF = (가동중을 모두 더한 값) / 가동중 횟수
MTTR = (고장중을 모두 더한 값) / 고장중 횟수
신뢰도 = MTBF/(MTBF+MTTR)

 

예상문제

1. IDE 도구
- JDBC, ODBC와 데이터베이스 연동 기능을 지원
- 형상 관리, 배포 관리 기능 제공
- 라자루스는 어디서든 실행이 가능한 크로스 플랫폼
- Java, C++ 등의 언어를 이용하여 프로그램을 개발할 수 있는 환경을 제공해 줌

 

2. 형상 관리 도구
- GIT은 공개 소프트웨어 커뮤니티 중심으로 사용하는 개발자가 많이 확대되고 있는 도구
- SVN : 현재 가장 많이 사용하고 있는 형상 관리 도구로, 업계의 표준으로 사용되고 있음
- 형상 관리 도구의 Checkout 기능은 형상 관리 저장소로부터 소프트웨어의 회근 변경 사항을 개발자의 컴퓨터로 다운받는 기능
- CVS는 가장 오랫동안 사용한 형상 관리 도구로 중앙 집중형 서버 저장소에 클라이언트가 접속해서 버전 관리를 실행
- 형상 관리 도구는 프로그램 소스코드나 문서의 버전 관리, 이력 관리, 추적, 변경 사항을 체계적으로 관리할 수 있는 기능을 제공하는 프로그램

 

3. 형상 관리 저장소를 사용하는 명령어
- Commit, Checkin, Checkout, Update

# Save는 X

 

4. 소프트웨어 검사(Test)
- 소프트웨어 검사는 개발 단계의 마지막 단계에서 시행
- 소프트웨어 검사는 작성된 소프트웨어를 대상으로 오류를 찾는 것만 하고, 수정은 X
- 오류는 있지만 발견되지 않으면서 존재하는 오류를 잠재적 오류라고 함
- 오류를 많이 찾아내는 검사가 성공적인 검사

 

5. 낚시의 법칙 : 낚시를 즐기는 사람들은 특정 자리에서 물고기가 잘 잡힌다는 사실을 경험적으로 알고있음. 소프트웨어 제품의 결함도 특정 기능, 모듈, 라이브러리에서 결함이 많이 발견된다는 것이 낚시의 법칙이다

 

6. 단위 테스트의 종류
- 코드 테스트, 모듈 테스트, 프로그램 설계 테스트

# 구조 설계 테스트 -> 통합 테스트

 

7. 테스트 기법 중 설계 기법
- 구조기반 설계, 명세기반 설계, 경험기반 설계

# 객체기반 설계는 X

 

8. 소프트웨어 테스트
- 베타 테스트는 고객 사이트에서 사용자에 의해서 수행
- 회귀(Regression) 테스트는 한 모듈의 수정이 다른 부분에 미치는 영향을 검사
- 화이트박스 테스트는 모듈의 내부 구현을 검사
- 블랙박스 테스트는 입력과 출력에 의해 기능을 검사
- 스트레스 테스트는 비정상적으로 과도한 분량 또는 빈도로 자원을 요청할 때의 영향을 검사

 

9. 노드의 수가 10, 간선의 수가 18일 경우 복잡도?
E(간선의 수) - V(노드의 수) + 2 = 18 - 10 + 2 = 10

 

10. 다음 인접 행렬의 복잡도는?
0 1 0 1 1 0
0 0 0 0 1 0
1 0 1 1 0 0
0 1 0 0 1 0

- 1행에 1을 모두 더하면 3-1=2, 2행의 1을 모두 더하면 1-1=0, 3행의 1을 모두 더하면 3-1=2, 4행의 1을 모두 더하면 2-1=1, 2 + 0 + 2 + 1 => 5 + 1 -> 6 

 

11. 알파 테스트
- 개발자의 장소, 사용자가 시험, 개발자가 지켜봄

# 베타 테스트 : 제한되지 않은 환경, 사용자가 시험, 개발자가 지켜볼 수 없음

 

12. 15년 이전에 사용했던 프로그램 언어를 외계인 코드라고 하는 이유?
- 15년 전에 개발자가 현재에는 없음
- 구조적인 설계가 아닌 주관적인 설계가 되었음
- 개발된 방법론이 적용되지 않았음

# 모듈화 개념을 사용한 것은 표준적인 방법으로 개발된 것이고, 극히 객관적으로 개발된 것이라 누구나 쉽게 알아볼 수 있는 코드

 

13. 외계인 코드를 방지하기 위한 방법으로 가장 적합한 것은?
- 프로그램 내에 문서화를 철저하게 해두어야 함

 

14. 소프트웨어 유지보수의 부작용 중 자료 코드에 대한 설계 문서나 사용자가 사용하는 매뉴얼에 적용되지 않을 때 발생하는 부작용은?
- 문서화 부작용

 

15. 품질 보증의 개념
- 어떤 항목이나 제품에 설정된 기술적인 요구사항과 일치하는가를 적절하게 확인하는데 필요한 체계적이고도 계획적인 유형의 활동

 

16. 소프트웨어의 신뢰성과 가용성
- 소프트웨어의 신뢰성인 당연히 과거의 개발상의 자료를 이용해야 함
- 소프트웨어의 간단한 신뢰성 측정은 MTBF로 가능
- 소프트웨어의 가용성은 프로그램이 요구사항에 따라 운영되는 확률
- 신뢰도는 MTBF/(MTBF+MTTR)로 정의된다

 

17. 유지보수 비용산정을 구하는 공식(유지보수 비용 측정 공식)
- M : 유지보수를 위한 노력(인원/월)
- P : 생산적인 활동에 드는 비용
- K : 통곗값에서 구한 상수
- c : 복잡도
- d : 소프트웨어에 대한 지식의 정도

=> M = P + Ke의 c-d승