1. 테스트의 개요

• 테스트 과정에 필요한 역할은 소프트웨어 아키텍트와 테스트 매니저이다
• [그림 1-1]과 같이 두 역할은 소프트웨어 생명 주기(Life Cycle)의 V모델에서 각각 좌측과 우측의 핵심 역할을 담당하고 서로 보완 관계에 있다
• 소프트웨어 생명 주기는 요구사항, 분석, 디자인, 구현 또는 개발 순으로 진행, 테스트는 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 순서로 진행 된다
  

01. 프로젝트 수행 단계에 따른 테스트의 분류

-1. 단위 테스트

• 작은 소프트웨어 단위(컴포넌트 또는 모듈)를 테스트 한다

-2. 통합 테스트

• 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호 작용을 테스트한다

-3. 인수 테스트

• 일반적으로 최종 사용자와 업무에 따른 이해관계자 등이 테스트를 수행한다

2. 프로젝트 수행 단계에 따른 테스트의 접근 방법

01. 단위 테스트

• 테스트 가능한 단위로 작게 분리된 소프트웨어 내에서 결함을 찾고 기능을 검증하는 테스트 활동이다

-1. 특징

• 구조적 테스트, 기능성 테스트, 리소스 관련 테스트, 강건성 테스트 등 트겆ㅇ 비기능성 테스트 등이 포함되어 수행되며, 컴포넌트 명세, 소프트웨어 상세설계, 데이터 모델 명세 등을 이용하여 테스트 한다

-2. 방법과 목적

• 단위 테스트는 구조 기반과 명세 기반 테스트로 나누어지며 <표 1-1>과 같이 기본적으로 개발된 코드 및 모듈의 범위 내에서 정상적인 작동과 사용자의 요구사항 등을 테스트하는데 목적이 있다
• (가) 구조 기반의 업무 단위별 제어 흐름과 조건 결정에 따른 결과를 테스트하는 데 목적이 있다
• (나) 명세 기반은 동등 분할과 경계 값 분석을 위하여 사용자의 입력, 출력, 내부, 이벤트 등을 확인하는 데 목적이 있다
  

02. 통합 테스트

• 통합 테스트는 컴포넌트 간 인터페이스 테스트 하고 운영체제(OS), 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 각각 다른 부분과 상호 연동이 정상적으로 작동하는지 여부를 테스트한다

03. 시스템 테스트

• 컴퓨터 시스템을 완벽하게 검사하기 위한 목적 또는 성능 목표를 가지고 테스트한다

-1. 특징

• 환경 제한적 장애 관련 리스크를 최소화하기 위하여 실제의 최종 사용자 환경과 유사하게 시스템 성능, 관련된 고객의 기능, 비기능적인 요구사항 등이 완벽하게 수행 되는지를 테스트하며, 이때 요구사항 명세서, 비즈니스 절차, 유스케이스, 리스크 분석 결과 등을 이용한다

-2. 테스트 방법

• 테스트 방법은 <표 1-2>과 같이 업무 기반의 기능적 요구사항과 시스템적인 비기능적 요구사항으로 나누어진다
  

04. 인수 테스트

• 시스템의 일부 또는 특정한 비기능적인 특성에 대해 인수테스트를 통해 확인하며, <표 1-3>과 같이 6가지의 종류로 구분해서 테스트한다.
  

3. 테스트 기반(Test Base)에 따른 테스트의 종류

• 테스트 종류는 <표 1-4>와 같이 명세 기반, 구조 기반, 경험 기반 테스트의 3가지 종류로 나누어 진다
  

4. 소프트웨어 테스트 기법

01. 단위 테스트 기법

-1. JUnit을 활용한 테스트

• Java 환경이라면 대부분 JUnit이라는 단위 테스트 프레임워크를 통해 <표 2-1>과 같이 단위 테스트를 할 수 있어야 한다
  

-2. Mock 테스트

• (가) 단위 테스트 시 Mock 객체를 사용하여 테스트하는 기법을 말하며, 특정 기능 또는 모듈에 대한 응답 결과를 미리 정의해 놓고 테스트한다, 이는 특정 모듈이나 기능이 완벽히 개발 완료되지 않은 상태에서도 진행할 수 있다
• (나) 테스트 전용 객체를 테스트 더블(Test Double)이라 부르며, 이는 테스트를 위해 실체 객체를 대신해서 사용되는 용어이고 객체의 유형은 <표 2-2>와 같다
  

02. 통합 테스트 기법

• 전체 시스템이 통합 완료될 때까지 단위 시스템 간의 연계성 및 기능 요구사항들을 확인하고, 하드웨어와 소프트웨어 구성 요소 간의 상호 작용을 테스트하는 것이 주요 목적이다
• 업무 간의 연계성과 상호 운영성 중심의 테스트를 수행한다

-1. 테스트 설계 기법

• 테스트 설계는 개발된 소프트웨어나 시스템의 요구사항, 요구사항 명세서, 업무 구조, 시스템을 구조 등을 기반으로 소프트웨어의 어떤 부분을 어떻게 접근하여 테스트할지에 대한 테스트 상황과 방법을 파악하는 것이다
• 이를 체계적으로 구체화시켜 테스트 케이스를 도출하고 작성하는 것을 테스트 구현이라고 하고, 테스트 상황과 방법을 구체화시키기 위한 수단 및 도구를 테스트 설계 방법이라고 한다

-2. 테스트 설계 방법

03. 시스템 테스트 기법

• 시스템 테스트 업무 진행 전체를 총괄할 수 있도록 절차 및 각 프로세스 별 세부 업무를 알아야 하고 결과에 대한 분석 및 해결 방안을 제시할 수 있어야 한다

-1. 부하 및 성능 테스트

• 동시접속으로 시스템에 많은 요청(업데이트, 조회 등)이 발생될 때 어떻게 가동되는지 확인하는 테스트로서, 성능 요구사항에 정의된 임계점을 넘어 부하가 계속 증가하는 상황에서 시스템이 정상적인 수준의 반응을 보이는지를 확인해야 한다.
• 장애 복구 테스트 각종 장애(하드웨어 장애, 네트워크, 정전 운영 오류 등) 상황에서 복구 및 재가동을 테스트한다
• (가) 애플리케이션의 장애 복구 테스트는 다양한 관점에서 테스트할 수 있으나, 서비스의 지속적인 유지라는 측면에서 발생할 수 있는 장애를 목록으로 작성하고 장애 상황을 발생시킨다
• (나) 시스템(하드웨어, 네트워크, 시스템설비 등) 장애와 애플리케이션 장애로 나눌 때, 시스템 장애는 인프라 아키텍처 팀 등에서 별도로 담당하여 진행하도록 하고, 소프트웨어 아키텍트는 애플리케이션 장애 관점에서 장애 복구 테스트를 수행하도록 한다

04. 인수 테스트 기법

• 최종 사용자가 요구한 기능이 제대로 반영되었는지, 인수 조건에 만족하는지를 테스트하는 기법이다
• 요구 기능이 만족하는지를 테스트하는 기법이다
• 요구 기능 만족 여부, 사용 편리성에 대하여 실제 운영 환경에서 실행되며 고객이 주고하는 테스트이다

5. 소프트웨어 테스터의 역할과 능력

01. 소프트웨어 테스터의 역할

• (1) 탐구심과 문제 해결력을 갖추어야 한다
• (2) 때로는 창의력을 발휘하여 결함을 찾기 위해 새로운 접근법도 사용해야 한다
• (3) 완벽함을 추구하지만, 가능한 한도 내에서 적당한 수준의 완벽성을 추구한다
• (4) 테스터는 항상 나쁜 소식을 전하는 사람이다. 개발자에게 그들의 작품에 결함이 있다고 말하려면 재치와 능숙함, 그리고 설득력이 필요하다

6. 프로그램 코드 검토 기법

01. 소프트웨어 인스펙션(Software Inspection)의 개요

• (1) 코드 인스펙션(Code Inspection) 외에도 설계 및 설계 산출물까지 포괄하여 소프트웨어 인스펙션으로 부르기도 한다
• (2) 코드 인스펙션은 매우 효과적인 테스트 방법으로 어떠한 다른 테스트 방법으로 대체할 수 없다. 이는 상당한 시간이 필요한 작업이며, 통계에 따르면 인스펙션을 적절히 잘 수행하기만 하면 포함된 에러의 90%까지 찾아낼 수 있다
• (3) 코드 인스펙션, 워크스루와 같이 몇시간 동안 수행되는 단위 미팅과는 구별되어야 한다. 적절한 코드 인스펙션은 여러 날이 필요하고 도구의 도움이 있어야 한다
• (4) 적절한 인스펙션은 소프트웨어 개발의 전체 수명 주기에 걸친 리소스 절감과 그에 따른 비용 감소 그리고 산출물의 품질을 향상시키는 것으로 나타난다
• (5) 인스펙션을 해야하는 비즈니스적인 이유는 아래와 같다
  • (가) 결함을 빨리 찾을수록 수정(fix) 비용이 적게 든다
  • (나) 인스펙션의 데이터를 통해 업무에 집중할 수 있다
  • (다) 인스펙션을 함으로써 교차 교육(Creoss-training)을 돕는다
  • (라) 제품의 "re-enginerring"이 가능한 영역을 식별하도록 돕는다
  • (마) 소프트웨어를 개발하고 유지하는 데 적은 비용이 든다
  • (바) 스케줄에 긍정적인 효과를 준다
  • (사) 품질을 향상시킨다

02. 인스펙션 중점 항목 프로젝트

• 인스펙션 중점 항목 프로젝트에서 소프트웨어 인스펙션 업무는 품질보증(QA)이 주관하여 담당 또는 부서에서 실시하나, 아키텍트가 각 단계에서 원활한 업무 수행을 위해 지원을 하여야 한다
• 소프트웨어 인스펙션 중 특히 코드 인스펙션과 관련하여 아키텍트는 코드 인스펙션의 프로세스 전반과 각 단계별 수행 업무 등을 전체적으로 이해할 필요가 있다

03 코드 인스펙션의 프로세스와 수행

• 내용 (1) 코드 인스펙션 프로세스
  
  
• 코드 인스펙션 태스크 별 수행 내용
  
  
• (2) 코드 인스펙션 태스크별 수행 내용
  • (가) 자동 코드 인스펙션 전체 개발된 프로그램을 대상으로 자동 인스펙션을 수행한다
  • (나) 수동 코드 인스펙션
    • 1) 자동 코드 인스펙션 코드 중 에러가 많은 경우
    • 2) 업무 중에 복잡한 처리 로직이 있는 경우
    • 3) 처음 투입되는 개발자의 산출물
• (3) 코드 인스펙션 수행 시 고려사항
  • 일반적으로 인스펙션의 목적은 개발 가이트에 다른 표준 준수성을 파악하기 위함에 있으므로 기능적으로 이상이 없는 소스 코드를 대상으로 검증한다
  • 인스펙션의 효과는 개발 가이드에 따른 체크 항목 파악, 결함 유형 파악에 따른 차후 코딩 시 유념, 다른 개발자의 기술 습득 등으로 다양하지만, 실제적으로 테스트 전 결함발견에 따른 이익을 수행 팀원들이 인식하는 것이 가장 크다고 할 수 있다

4. 설계 인스펙션

• 설계 인스펙션에 대해서는 이 문서에서 주로 다루지 않는다
• 다만 참고로 설계 인스펙션에서 흔히 다루는 체크리스트를 정리해보면 다음과 같다
  

5. 인스펙션과 워크스루의 차이점

• 인스펙션은 워크스루와 달리 체크리스트를 기반으로 검토하며 발견된 모든 결함을 제거해야 한다는 특징이 있다
• 완성도가 기준 이상일 때 수행함으로써 모든 결함은 없애는 데 주요 목적이 있다
  

7. 형상 관리 및 구성 요소

01. 소프트웨어 형상 관리의 정의

• (1) 소프트웨어 프로세스의 모든 출력물 정보
• (2) 컴퓨터 프로그램, 컴퓨터 프로그램 설명 문서, 데이터 등
• (3) 소프트웨어 프로세스 전반에 걸쳐 소프트웨어 형상의 변경 요인에 대해 소프트웨어 형상을 보호하는 활동
  

02. 기준선과 소프트웨어 형상 항목

-1. 기준선(Baseline)

• 변경을 통제하게 도와주는 기준선은 정식으로 검토 및 합의된 명세서나 제품 개발의 바탕으로서, 정식의 변경 통제 절차를 통해서만 변경 가능하다

-2. 소프트웨어 형상 항목(SCI, Spftware Configureation Item)

• 소프트웨어 형상과 개발 도구의 합성으로, SCI는 <표 2-18>과 같이 개발 단계별로 기준선을 기준으로 형상 항목을 관리한다
  
  

03. 형상 관리의 주요 활동

• (1) 형상 관리 기능 형상 관리의 주요 기능은 형상을 식별하고 관리하는 데 있다. <표 2-19>와 같이 형상 식별, 버전 관리, 변경 통제, 형상 감사, 상태 보고 등의 활동을 말한다
  
• (2) 형상 식별 소프트웨어 형상 항목에 대해 식별하고 고유한 이름을 부여하는 활동으로, <표 2-20>과 같이 식별자 항목을 정의하고 세부 내용을 파악하여 식별한다
  
• (3) 버전 관리 형상 관리 활동 중 버전 관리는 여러 버전의 형상 객체를 관리하기 위한 절차와 도구, 그리고 형상 항목의 여러 버전을 표현하는 기능을 [그림 2-7]과 같이 구성할 수 있다
  

04. 변경 통제에 대한 업무별 활동

• 변경 통제에 대한 업무별 활동은 변경 요청에 대하여 프로세스에 어떠한 영향이 있는 지 확인하는 과정으로, [그림 2-8]과 같이 검토와 승인이 완료된 후 결함 변경을 수행한다