[SE-16] 전통적 개발 방법론 - 검사

1. 검사(Test)의 개념

• 소프트웨어 품질을 평가하는 작업이며 분석이나 설계, 코딩 결과를 최종적으로 점검하는 과정
• 소프트웨어에 대한 요구사항의 만족도 및 예상 결과와 실제 결과의 차이점을 여러 방법을 사용하여 검사하고 평가하는 일련의 과정
• 검사의 목적은 오류를 찾아내는 데 있음
• 검사의 목적은 소프트웨어를 구성하는 요소들이 잘 이루며 정상적으로 동작하고 성능이 요구에 맞는 것을 보장하기 위해서임
• 검사 기법 종류에는 화이트 박스 테스트, 블랙박스 테스트가 있다.

2. 화이트 박스 테스트

• 모듈 안의 작동을 자세히 관찰할 수 있음(모듈 안의 논리적인 구조 검사)
• 프로그램 원시 코드의 논리적인 구조를 커버(Cover)하도록 테스트 케이스를 설계하는 프로그램 테스트 방법
• 원시 코드의 모든 문장을 한 번 이상 수행함으로써 수행됨
• 프로그램의 제어 구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 제어함
• 검사 대상의 가능한 경로를 어느 정도 통과하는지의 적용 범위성을 측정기준으로 함
• Nassi-Shneiderman 도표를 사용하여 검정기준을 작성할 수 있음
• 논리 흐름도, 루프 구조, 순환 복잡도 등과 같은 오류를 찾을 수 있음

3. 화이트 박스 테스트 기법 - 기초 경로 검사 (Basic Path Test)

• McCabe가 제안한 것으로 대표적인 화이트 박스 데스트 기법

- 기초 경로 검사 절차

• 설계나 원시 코드를 기초로 흐름도 작성
• 흐름도의 논리적 복잡도 측정
• 독립 경로들의 기초 집합을 결정
• 기초 집합의 각 경로를 실행시키는 검사 사례 선정

- 제어 흐름도

• 제어 흐름을 표현하기 위해 사용되는 그래프

- 순환 복잡도

• 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도로, 제어 흐름도 이론에 기초를 듬

- McCabe에 의해 제안된 소프트웨어의 복잡성 측정

• 영역은 그래프의 평면에서 둘러 싸인 부분으로 묘사될 수 있음
• 영역의 수는 경계된 영역들과 그래프 외부의 비 경계지역의 수를 계산함
• V(G)는 영역의 수를 결정함으로써 계산되어 짐

- 제어 흐름도 G에서 순환 복잡도(Cyclomatic) V(G) 계산 방법

• 순환 복잡도 - 제어 흐름도의 영역 수와 일치하므로 영역 수를 계산
• V(G) = E - N + 2 (E: 화살표, N: 노드 수)

4. 블랙박스 테스트

• 제품이 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 검사
• 모듈의 구조보다 기능을 검사함
• 기능 검사라고도 함
• 소프트웨어의 기능이 의도대로 작동하고 있는지, 입력은 적절하게 받아들였는지, 출력은 정확하게 생성되는지를 보여주는 데 사용
• 동치 분할(Equivalence Partitioning)이라는 기법 사용
• 원인/결과 그래프(Cause and Effect Graph)로 테스트 케이스 작성 가능
• 블랙박스 테스팅을 통해 발견 가능한 오류 성능 오류, 부정확한 기능, 인터페이스 오류

5. 블랙박스 테스트 기법 종류

- 동치 분할 검사 (Equivalence Partitioning Test)

• 입력 자료에 초점을 맞춰 검사 사례를 만들고 검사하는 기법

- 경곗값 분석 (Boundary Value Analysis)

• 입력 자료에만 치중한 동치 분할 기법을 보완하기 위한 기법

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

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

- 오류 예측 검사 (Fault Based Testing, Mutation Testing)

• 오류 예측 검사는 과거의 경험이나 확인자의 감각으로 검사하는 기법

- 비교 검사 (Comparison Testing)

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

6. 소프트웨어 개발 단계와 테스트 전략

• 요구사항 분석 단계 <-> 시스템 테스트
• 설계 단계 <-> 통합 테스트
• 구현 단계 <-> 단위 테스트
• 유지보수 단계 <-> 시스템 테스트

7. 소프트웨어 감사 단계 순서

• 단위(코드) 검사 > 통합(설계) 검사 > 검증(요구사항) 검사 > 시스템 검사

- 단위(코드) 검사 (Unit Test)

• 단위 검사는 코딩이 이루어진 후 소프트웨어 설계의 최소 단위인 모듈에 초점을 맞추어 검사하는 것
• 단위 검사는 화이트 박스 테스트 기법을 사용

---

- 통합(설계) 검사 (Integration Test)

• 통합 검사는 단위 검사가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 검사를 의미
• 종류 : 하향식 통합 검사, 상향식 통합 검사

 1) 하향식 통합 검사 (Top Down Integration Test)

• 프로그램의 상위 모듈에서 하위 모듈 방향을 통합하면서 검사하는 기법

 2) 하향식 통합 검사 절차

• 주요 제어 모듈을 드라이버로 사용하고, 주요 제어 모듈의 종속 모듈들은 스터브(Stub)로 대체
• 깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 종속 스터브들이 실제 모듈로 교체
• 모듈이 통합될 때마다 검사를 실시
• 새로운 오류나 발생하지 않음을 보증하기 위해 희귀 검사(전에 수행된 검사의 일부나 전체를 다시 검사하는 것)를 실시

 * 스터브 (Stub)

• 하향식 통합에 있어서 모듈 간의 통합 시험을 하기 위해 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈

 3) 상향식 통합 검사 (Bottom-up Integration Test)

• 상향식 통합 검사는 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 검사하는 기법

 4) 상향식 통합 검사의 과정

• 클러스터 작성 (낮은 수준의 모듈들을 클러스터로 결합)
• 드라이버라는 제어 프로그램의 작성
• 클리스터 검사
• 드라이버를 제거하고 클러스터를 상위로 결합

---

- 검증(요구사항) 검사 (Validation Test)

• 소프트웨어가 요구사항에 맞는지를 추적해 보는 데 중점을 두고 있는 시험 방법

 1) 검증 검사 기법의 종류

• 형상 검사 : 소프트웨어 구성 요소, 목록, 유지보수를 지원하기 위해 필요한 모든 사람들이 제대로 표현되었는지를 검사
• 알파 검사 : 개발자의 장소에서 사용자가 시험하고 개발자는 뒤에서 결과를 지켜봄
• 베타 검사 : 실업무를 가지고 사용자가 직접 시험함

---

- 시스템 검사

• 개발된 소프트웨어가 컴퓨터 시스템에서 완벽하게 수행되는지를 검사하는 것

- 디버깅 (Debugging)

• 검사 단계에서 검사 사례에 의해 오류를 찾은 후 그 오류를 수정하는 과정
• 디버깅은 성공적인 태스킹의 결과로 발생
• 디버깅은 징후로부터 원인을 찾아 수정하는 과정
• 디버깅이 힘든 이유는 심리적인 요소가 많이 관여하기 때문