[NCS 모듈] 애플리케이션 테스트 수행 - 애플리케이션 테스트 수행하기(1)

 

테스트 수행

 

테스트 개요

테스트 과정에 필요한 역할은 소프트웨어 아키텍트와 테스트 매니저이다. 소프트웨어 생명 주기는 요구사항, 분석, 디자인, 구현 또는 개발 순으로 진행되며, 프로젝 트의 특성과 방법론에 따라 반복적(iteration)으로 수행하는 경우도 있다. 테스트는 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트의 순으로 진행된다.

 

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

    (1) 단위 테스트

          작은 소프트웨어 단위(컴포넌트 또는 모듈)를 테스트하는 것으로서, 일반적으로 개발자 자신에 의해 행해진다. 단위 테스트는

          아주 중요한 부분이므로 개발도구에서 지원하지 않아도 반드시 수행해야 한다.

    (2) 통합 테스트

          모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호 작용을 테스트하는 것.

    (3) 시스템 테스트 

         통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지를 테스트하는 것.

    (4) 인수 테스트

         일반적으로 최종 사용자와 업무에 따른 이해관계자 등이 테스트를 수행함으로써 개발된 제품에 대해 운영 여부를 결정하는

         테스트이다.

 

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

 

1. 단위 테스트

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

    (1) 특징

          구조적 테스트, 기능성 테스트, 리소스 관련 테스트, 강건성 테스트 등 특정 비기능성 테스트 등이 포함되어 수행되며,

          컴포넌트 명세, 소프트웨어 상세설계, 데이터 모델 명 세 등을 이용하여 테스트한다.

    (2) 방법과 목적

          단위 테스트는 구조 기반과 명세 기반 테스트로 나누어지며, 기본적으로 개발된 코드 및 모듈의 범위 내에서 정상적인

          작동과 사용자의 요구사항 등을 태스트하는 데 목적이 있다.

테스트 방법	테스트 내용	테스트 목적
구조 기반	- 프로그램 내부 구조 및 복잡도를 검증 하는 화이트박스(White Box) 테스트	제어 흐름, 조건 결정
명세 기반	- 목적 및 실행 코드 기반의 실행을 통한 블랙박스(Black Box) 테스트	동등 분할, 경계 값 분석

 

2. 통합 테스트

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

    (1) 특징

         일반적으로 빅뱅 방식보다는 순차적(Incremental) 형태와 아키텍처에 대한 이해를 바탕으로 진행.

    (2) 종류

         빅뱅, 상향, 하향, 샌드위치, Central, Collaboration, 레이어 통합 등의 테스트가 있다.

 

3. 시스템 테스트

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

    (1) 특징

          환경 제한적 장애 관련 리스크를 최소화하기 위하여 실제의 최종 사용자 환경과 유사하게 시스템 성능, 관련된 고객의 기능,              비기능적인 요구사항 등이 완벽하게 수행 되는지를 테스트한다.

    (2) 테스트 방법

테스트 방법	테스트 내용
기능적 요구사항	요구사항 명세서, 비즈니스 절차, 유스케이스 등 명세서 기반의 블랙박스(Black Box) 테스트
비기능적 요구사항	성능 테스트, 회복 테스트, 보안 테스트, 내부 시스템의 메뉴 구조, 웹 페이지의 네비게이션 등의 구조적 요소에 대한 화이트박스(White Box) 테스트

 

4. 인수 테스트

시스템의 일부 또는 특정한 비기능적인 특성에 대해 인수테스트를 통해 확인한다.

테스트 종류	테스트내용
사용자 인수 테스트	비즈니스 사용자가 시스템 사용의 적절성 여부를 확인
운영상의 인수 테스트	시스템 관리자가 시스템 인수 시 수행하는 테스트 활동으로 백업/복원 시스템, 재난 복구, 사용자 관리, 정기 점검 등을 확인
계약 인수 테스트	계약상의 인수/검수 조건을 준수하는지 여부를 확인
규정 인수 테스트	정부 지침, 법규, 규정 등 규정에 맞게 개발하였는지 확인
알파 테스트	개발하는 조직 내 잠재 고객에 의해 테스트 수행
베타 테스트	실제 환경에서 고객에 의해 테스트 수행

 

테스트 기반(Test Bases)에 따른 테스트의 종류

 

테스트의 종류는 명세 기반, 구조 기반, 경험 기반 테스트의 3가지 종류로 나누어지며 진행되는 프로젝트와 테스트 단계에 따라 세부 기법으로 수행한다.

테스트 종류	테스트 내용	세부 기법
구조 기반	소프트웨어 내부의 논리 흐름에 따른 테스트 케이스 작성 및 결함 발견 활동	구문 기반, 결정 기반, 조건 기반, 조건결정 기반, 변경 조건 기반, 멀티 조건 기반 커버리지
명세 기반	사용자의 요구사항 분석서에 주어진 명세를 빠뜨리지 않고 테스트 케이스화	동등 분할, 경계 값 분석, 결정 테이블 테스팅, 상태 전이 테스팅, 유스케이스 테스팅
경험 기반	유사 소프트웨어나 기술에서의 테스터의 경험, 직관, 기술 능력을 바탕으로 하는 테스트 기법	탐색적 테스팅, 리스크 기반 테스팅

 

테스트 자동화 도구

 

1. 배경

소프트웨어 테스트는 소프트웨어 개발에 소요되는 총 시간과 비용의 절반 이상을 차지하 기도 할 정도로 많은 자원이 투입되는 프로세스라 태스트의 정확성을 유지하면서 시간과 비용을 줄일 수 있는 자동화 도구가 매우 중요하다.

 

2. 테스트 자동화

    (1) 테스트 자동화의 개념

         사람이 하던 반복적 테스트 절차를 자동화 도구를 활용하여 준비, 구 현, 수행, 분석 등을 스크립트 형태로 구현함으로써,

         시간과 인력 투입의 부담을 최소 화하면서 운영 중인 시스템의 모니터링 또는 UI가 없는 서비스의 경우에도 정밀한 테스트가           가능하도록 하는 것이다.

     (2) 테스트 도구의 장점

          (가) 테스트 데이터의 재입력과 재구성 같은 반복 작업의 자동화를 통하여 테스트 인력과 시간을 최소화.

          (나) 향상된 요구사항 정의, 성능 및 스트레스 테스트, 품질 측정을 최적화.

          (다) 빌드확인, 회귀, 다중 플랫폼 호환성, 소프트웨어 구성, 기본 테스트 등의 향상된 테스트 품질을 보장.

     (3) 테스트도구의 단점

           (가) 도입 후 테스트도구 정문가를 양성 또는 고용이 필요하며, 초기에 프로세스 적용에 대한 시간, 비용, 노력에 대한

                  추가 투자가 필요.

           (나) 비공개 상용 소프트웨어의 경우 고가이며, 인력과 교육에 대한 유지관리 비용 높음.

      (4)  테스트 자동화 수행 시의 고려사항

            (가) 테스트 절차를 고려하여 재사용 및 측정이 불가능한 테스트 프로그램은 제외해 야 한다.

            (나) 설계기준 고려하여 반복적인 빌드에서 스크립트 재사용성이 가능해야 한다.

            (다) 도구의 한계성으로 모든 수동 테스트 과정을 자동화 할 수 있는 도구는 없다.

                   따라서 용도에 맞는 적절한 도구 사용이 필요하다.

            (라) 도구 환경 설정과 도구 습득 기간을 고려하여 프로젝트의 지연을 방지해야 한다.

            (마) 테스트 엔지니어 늦은 투입은 프로젝트의 이해 부족으로 불완전한 테스트를 초 래할 수 있으므로,

                   적절한 투입 시기와 계획을 프로젝트 초기에 수립해야 한다.

 

3. 테스트 도구 평가방법 및 요소

    (1) 테스트 도구 평가방법

         테스트 도구가 지원하는 모든 사항에 대해 종류별로 나열하고 기록하여야 하며 테스트에 해당하는 요소에 대한 목표 또는

         평균값을 설정하고 설정된 기준으로 평가하고 비용을 최소화하기 위해 필수적인 몇 가지 요소만을 고려해야 할 경우

         최소한의 요구사항을 만족하는 도구를 선정한다.

    (2) 테스트 도구 평가요소

          테스트 도구의 사용 편의성, 다중 사용자 접속, 결함 추적, 도구 기능성, 보고 능력, 성 능 및 스트레스 테스트, 버전 제어,

          테스트 계획과 관리, 가격, 테스트 도구 제조사의 지원 능력 등의 객관적이고 수치화되는 항목을 이용하여 평가한다.

 

4. 테스트 단계를 지원하는 도구 종류

테스트 활동	테스트 도구	내 용
테스트 계획	요구사항 관리	고객 요구사항 정의 및 변경 사항 관리
테스트 분석/설계	테스트케이스 생성	테스트 기법에 따른 테스트 데이터 및 케이스 작성
	커버리지 분석	대상 시스템에 대한 테스트 완료 범위의 척도
테스트 수행	테스트 자동화	기능 테스트 등 테스트 도구를 활용하여 자동화를 통한 테스트의 효율성 제고
	정적 분석	코딩 표준, 런타임 오류 등을 검출
	동적 분석	대상 시스템 시뮬레이션을 통한 오류 검출
	성능 테스트	가상 사용자를 인위적으로 생성하여 시스템 처리 능력 측정
	모니터링	시스템 자원(CPU, Memory 등)의 상태 확인 및 분석 지원 도구
테스트 통제	형상 관리	테스트 수행에 필요한 다양한 도구 및 데이터 관리
	테스트 관리	전반적인 테스트 게획 및 활동에 대한 관리
	결함 추적/관리	테스트에서 발생한 결함 관리 및 협업 지원

 

결함관리

 

결함의 정의

 

1.결함은 프로그램과 명세서 간의 차이, 업무 내용 불일치이다.

2. 결함은 기대 결과와 실제 관찰 결과 간의 차이이다.

3. 시스템이 사용자가 기대하는 타당한 기대치를 만족시키지 못할 때 변경이 필요한 모든 것은 결함이다.

 

결함관리 프로세스

 

결함관리 프로세스는 7개의 활동으로 구성된다.

 

1. 결함관리 계획

결함관리 계획은 전체 프로세스에서 결함관리에 대한 일정, 인력, 업무 프로세스를 확보하여 계획을 수립하는 것을 말한다.

2. 결함 기록

테스터는 발견된 결함에 대한 정보를 결함관리 DB에 기록한다.

3. 결함 검토

등록된 결함에 있어서 주요 내용을 검토하고, 결함을 수정하 개발자에게 전달한다.

4. 결함 수정

개발자는 할당된 결함의 프로그램을 수정한다.

5.결함 재확인

테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행한다.

6. 결함 상태 추적 및 모니터링 활동

결함관리 팀장은 결함관리 데이터베이스를 이용하여 대시보드 또는 게시판 형태의 서비스를 제공한다.

7. 최종 결함 분석 및 보고서 작성

발견된 결함에 대한 내용과 이해관계자들의 의견이 반영된 보고서를 작성하고 결함관리를 종료한다.

 

결함의 상태 및 추적

 

결함은 여러 상태를 가지고 있으며, 이 상태의 변화를 지속적으로 추적 관리하는 것이 결함관리의 주요 작업 중 하나.

 

1. 결함 등록(Open)

테스터와 품질 관리(QA) 담당자에 의해 결함이 처음 발견되어 등록되었지만, 아직 분석이 되지 않은 상태.

2. 결함 검토(Reviewed)

등록된 결함을 담당 모듈 개발자, 테스터, 프로그램 리더, 품질 관리(QA) 담당자와 검토하는 상태.

3. 결함 할당(Assigned)

결함의 영향 분석 및 수정을 위해 개발자와 문제 해결 담당자에게 할당된 상태.

4. 결함 수정(Resolved)

개발자에 의해 결함의 수정이 완료된 상태.

5. 결함 조치 보류(Deferred)

수정이 필요한 결함이지만 현재 수정이 불가능해서 연기된 상태로서 우선순위, 일정 등을 고려하여 재오픈을 준비하는 상태

6. 결함 종료(Closed)

발견된 결함이 해결되고 테스터와 품질 관리(QA) 담당자에 의해 종료 승인을 한 상태.

7. 결함 해제(Clarified)

테스터, 프로그램 리더, 품질 관리(QA) 담당자가 결함을 검토한 결과, 결함이 아니라고 판명된 경우임.

 

결함 분류

 

결함은 여러 가지 유형으로 나뉘며, 결함을 분석하는 단계에서 이러한 유형을 나누워한다.

 

1. 시스템 결함

비정상적인 종료/중단, 응답 시간 지연, 데이터베이스 에러 등 주로 애플리케이션 환경과 데이터베이스 처리에서 발생하는 결함을 

말한다.

    (1) 비정상적인 종료/중단

         특정 기능 실행 시 응용 프로그램의 작동 정지, 종료, 시스템 다운이 되는 경우

    (2) 응답 시간 지연

         응용 프로그램 작동 후 조회 또는 보고서 출력 시 지연되는 경우와 메모리 부족, 하드웨어와 소프트웨어의 비일관성으로 

         발생되는 경우

    (3) 데이터베이스 에러

         응용 프로그램 작동 후 사용자 데이터의 동록, 수정, 삭제, 조회가 정상적으로 작동하지 않는 경우이다.

2. 기능 결함

사용자의 요구사항 미반영/불일치, 부정확한 비즈니스 프로세스, 스크립트 에러, 타 시스템 연동 시 오류 등 기획, 설계, 업무 시나리오 단계에서 발생된 결함을 말한다.

    (1) 요구사항 미반영/불일치

         요구사항에 명시된 기능이 응용 프로그램에 구현되지 않은 경우와, 다르게 구현되어 작동하는 경우

    (2) 부정확한 비즈니스 프로세스

          기능 자체는 수행되나 내부 프로세스 로직의 문제로 부정확한 결과를 내는 경우

    (3) 스크립트 에러

         특정 기능 실행 시 웹 브라우저에서 스크립트 오류가 발생하는 경우

    (4) 타 시스템 연동 시 오류

         기존 시스템과의 연동을 통해 데이터를 주고받는 과정에서 오류가 발생하는 경우

 

3. GUI 결함

    GUI 결함은 응용 프로그램의 UI 비일관성, 부정확한 커서/메시지, 데이터 타입의 표시 오류 등으로 사용자 화면 설계에서 발생된

    결함을 말한다.

     (1) 응용 프로그램 UI 비일관성

          프로젝트에서 정의한 UI 표준과 상이하게 구현된 경우

     (2) 부정확한 커서/메시지

           커서의 위치가 입력 대상의 첫 번째 필드에 위치해 있지 않거나, 탭 시퀀스가 순차적 으로 동작하지 않는 경우,

           각 기능에서 제공하는 메시지 내용이 부정확한 내용을 보여 주는 경우

     (3) 데이터 타입의 표시 오류

           입력 필드에 지정된 형식과 다르게 입력해도 저장이 되는 경우와 입력 필드에 유효하지 않은 데이터(Invalid Data)를

           입력했을 때 오류가 나는 경우 

 

4. 문서 결함

    기획자, 사용자, 개발자 간의 의사소통과 기록이 원활하지 않은 경우에 발생하는 결함으로 사용자의 온라인/오프라인 매뉴얼의

    불일치, 요구사항 분석서와 기능 요구사항의 불일치 로 인한 불완전한 상태의 문서의 경우를 말한다.

 

결함 심각도

 

결함 심각도는 여러 개의 결함 중 전체 시스템에 결함이 미치는 영향을 레벨별로 나타낸다.

 

1. High

시스템이 중단(또는 다운)되어 더 이상 프로세스를 진행할 수 없게 만드는 결함으로 시스 템의 핵심 요구사항 미 구현, 시스템 다운, 장시간 시스템 응답 지연, 시스템 복구 후 데 이터 왜곡 등의 경우를 말한다.

2. Medium

시스템의 흐름에 영향을 미치는 결함으로 부정확한 기능, 부정확한 업무 프로세스, 데이터 필드 형식의 오류, 데이터베이스 에러, 보안 관련 오류 등의 경우를 말한다.

3. Low

시스템의 흐름에는 영향을 미치지 않는 결함이나 상황에 맞지 않는 용도와 화면 구성 (Configuration) 결함으로, 부정확한 GUI 및 메시지, 에러 시 메시지 미출력, 화면상의 문법 /철자 오류 등을 말한다.

 

 

*NCS 모듈 참조