본문 바로가기
Software Engineering/Testing & Debugging

소프트웨어 테스트 기본 구성

by 부뚜기 2024. 4. 27.
반응형

SW Test 구성

 

테스트 준비

1. Test Basis

테스트 케이스를 설계하고 개발하는 데 사용되는 정보의 집합을 말한다. 이는 테스트 대상이 되는 시스템이나 컴포넌트의 요구 사항, 설계, 구현 등을 기초로 구성된다. 즉, 테스트 기준은 테스트 활동을 수행하기 위한 기준점이나 기반 자료로 볼 수 있다.

Test Basis에는 다음과 같은 문서나 자료들이 기준으로 구성된다.

  • 요구 사항 문서(Requirements Documents): 시스템이나 소프트웨어가 충족해야 하는 기능 및 비기능 요구 사항을 정의한 문서.
  • 설계 문서(Design Documents): 소프트웨어의 아키텍처, 인터페이스, 모듈 설계 등을 포함한 문서.
  • 기술 명세서(Technical Specifications): 소프트웨어의 기술적 세부 사항을 기술한 문서.
  • 사용자 매뉴얼(User Manuals): 최종 사용자를 위한 소프트웨어 사용 방법을 설명한 문서.
  • 기존 시스템과 관련된 문서 및 데이터: 이전 버전의 소프트웨어, 유사 시스템에 대한 문서 및 데이터 등을 포함.
  • 법적 문서 및 규제 요구 사항: 소프트웨어가 준수해야 하는 법적 요구 사항이나 규제 기준 등이 포함.
  • 기타 관련 문서: 프로젝트 계획, 위험 평가, 품질 보증 계획 등 프로젝트와 관련된 다양한 문서들을 포함.

Test Basis는 테스트 케이스의 개발뿐만 아니라 테스트 커버리지를 결정하고, 테스트 결과의 유효성을 평가하는 데에도 중요한 역할을 한다. 효과적인 테스트 기준의 선정과 활용은 소프트웨어의 품질을 보장하고, 개발 과정에서 발생할 수 있는 오류를 최소화하는 데 기여한다.

 

2. Test Suite

소프트웨어 테스트에서 'Test Suite'는 관련된 테스트 케이스들의 집합을 의미한다. 이는 특정 목적을 달성하기 위해 함께 실행되는 테스트 케이스들로 구성된다.  테스트 케이스는 보통 특정 기능을 검증하거나, 소프트웨어의 특정 부분에 대한 테스트 커버리지를 확보하기 위해 작성한다.

 

Test Suite의 주요 구성 요소는 다음과 같다.

  • 테스트 케이스(Test Cases): 특정 조건 하에서 소프트웨어를 실행하고 예상되는 결과를 확인하기 위한 단계들의 시퀀스다. 이러한 테스트 케이스는 Test Suite의 핵심 요소이다.
  • 테스트 스크립트(Test Scripts): 자동화된 테스트 케이스를 실행하기 위한 스크립트. 테스트 케이스가 수동이 아닌 자동으로 실행되는 경우 포함된다.
  • 테스트 데이터(Test Data): 테스트 케이스 실행 시 필요한 입력 데이터. 이 데이터는 테스트의 정확성을 보장하는 데 중요한 역할을 한다.
  • 설정/정리 스크립트(Setup/Cleanup Scripts): 테스트를 실행하기 전에 테스트 환경을 설정하거나, 테스트 후 환경을 원래 상태로 복구하기 위한 스크립트.

3. Test Scripts

테스트 스크립트는 소프트웨어 테스팅에서 특정 테스트를 수행하기 위해 작성된 지시 사항의 집합이다. 이 스크립트는 주로 자동화된 테스트 환경에서 사용되며, 테스트 케이스의 실행 과정, 입력 값, 예상 결과 등을 구체적으로 명시한다. 테스트 스크립트는 테스트의 재현성과 일관성을 보장하는 데 중요한 역할을 한다.

테스트 스크립트의 주요 구성 요소는 다음과 같다.

  • 테스트 케이스 식별자(ID): 특정 테스트 케이스를 식별하기 위한 고유번호.
  • 목적: 테스트 스크립트가 검증하고자 하는 목표나 기능을 설명.
  • 테스트 데이터: 테스트 실행 시 입력될 데이터. 이는 고정값일 수도 있고, 동적으로 생성되어야 할 수도 있다.
  • 실행 단계: 테스트 수행 위한 구체적인 단계와 지시 사항을 포함. 사용자의 입력, 시스템의 반응, 필요한 환경 설정 등.
  • 예상 결과: 테스트가 성공적으로 완료 시 기대되는 결과. 이를 통해 실제 테스트 결과와 비교해 테스트 성공 여부 판단.
  • 실행 환경: 테스트가 실행될 특정 소프트웨어, 하드웨어, 네트워크 설정 등 실행 환경에 대한 정보.

테스트 스크립트는 자동화된 테스트 도구를 사용하여 실행되거나 수동으로 실행될 수 있다. 이러한 스크립트를 통해 테스트 과정을 표준화하고 반복 가능하게 만들어 소프트웨어의 품질을 유지하고 개선하는 데 도움이 된다.

테스트 수행

1.Test Bed

테스트 베드(Test Bed)는 소프트웨어나 하드웨어 제품을 테스트하기 위해 필요한 환경을 뜻한다. 이 환경은 테스트 대상이 실제 운영될 때와 유사한 조건들로 구성한다. 테스트 베드에는 테스트 대상 소프트웨어뿐만 아니라, 운영 체제, 하드웨어, 네트워크 구성, 데이터베이스, 다른 응용 프로그램, 그리고 필요한 모든 소프트웨어와 하드웨어를 포함해서 구성하는 게 좋다.

테스트 베드의 주요 목적은 다음과 같다.

  • 실제 운영 환경을 모방: 테스트 대상 제품이 실제로 사용될 때 발생할 수 있는 다양한 조건들을 시뮬레이션하여, 제품이 실제 환경에서도 예상대로 작동하는지 검증.
  • 결함 발견: 버그나 결함을 찾아내어 수정할 수 있도록 한다. SW의 품질을 향상시키는 데 필수적인 과정이다.
  • 성능 평가: SW의 성능을 측정하고, 성능 기준에 부합하는지 평가한다. 사용자 경험을 개선하고, 시스템의 신뢰성을 보장하는 데 중요하다.

테스트 베드를 구성할 때는 테스트의 목적과 요구사항에 따라 다양한 요소들을 고려해야 한다. 테스트 베드는 정적일 수도 있고, 테스트의 단계에 따라 동적으로 변경될 수도 있다. 또한, 자동화된 테스트 스크립트를 실행하는 데 사용되는 경우가 많으며, 이를 통해 테스트 과정의 효율성과 정확성을 높일 수 있다.

2. Test Target

Test Target은 소프트웨어 테스팅에서 테스트의 대상을 의미한다. 테스트를 수행할 때 검증하거나 평가해야 하는 소프트웨어의 특정 부분이나 기능들이다.

 

테스트 대상은 다음과 같이 다양한 형태일 수 있다.

  • 기능 (Functionality): 소프트웨어가 사용자의 요구사항을 충족하는지 평가하기 위한 특정 기능이나 기능 집합.
  • 성능 (Performance): 소프트웨어의 응답 시간, 처리량, 리소스 사용량 등 성능 관련 특성.
  • 사용성 (Usability): 사용자 인터페이스(UI)의 편리성, 직관성, 사용자 경험(UX) 등 사용성 측면.
  • 보안 (Security): 소프트웨어의 보안 취약점, 데이터 보호, 인증 및 권한 관리 등 보안 관련 특성.
  • 호환성 (Compatibility): 다른 시스템, 플랫폼, 브라우저, 디바이스 등과의 호환성.
  • 회복성 (Recovery): 오류 상황이나 실패 후 시스템이 얼마나 잘 회복하는지 평가하는 테스트.

테스트 타깃을 명확히 정의하는 것은 테스트 계획을 수립하고 테스트 케이스를 개발하는 과정에서 매우 중요하다. 테스트의 범위와 목적을 결정하며, 테스트의 효율성과 효과성을 높이는 데 기여한다. 테스트 대상을 정확히 이해하고 정의하는 것은 성공적인 소프트웨어 테스트와 품질 보증 과정의 핵심이다.  

 

3. Test Harness

테스트 하네스(Test Harness)는 소프트웨어를 테스트하는 데 사용되는 자동화된 테스트 도구나 프레임워크이다. 테스트를 자동화하고 실행하기 위해 필요한 구조와 도구를 제공한다. 

  • 테스트 실행 및 관리: 테스트 케이스를 실행하고 결과를 수집하며 테스트를 관리하는 기능을 제공.
  • 테스트 데이터 생성: 필요한 테스트 데이터를 생성하거나 불러오는 기능등 테스트를 수행 시 필요한 데이터를 제공.
  • 결과 분석: 테스트 실행 결과를 분석하고 기록하여 테스트 케이스의 성공 또는 실패를 확인.
  • 환경 제어: 테스트를 실행하기 전에 테스트 환경을 설정하고 초기화하는 기능을 제공.

테스트 하네스는 소프트웨어 테스트를 효율적으로 수행하고 관리하기 위한 필수 도구로 사용된다. 이를 통해 테스트 프로세스를 자동화하고 반복 가능하게 만들어 소프트웨어의 품질을 향상시키는 데 도움이 된다.

 

Test Driver (Simulator)

- 컴포넌트나 시스템 호출하는 테스트 도구
- 상향식 (Bottom-Up) 테스트에서 아직 통합되지 않은 상위 컴포넌트 동작을 시뮬레이션 하는 모의 모듈

The use of drivers when bottom-up testing C

Test Stub (SetDebug)

- 테스트 대상과 연계된 컴포넌트가 개발되지 않은 시점에 필요한 테스트 진행 위해 생성하는 더미 컴포넌트
- 하향식(Top-down) 테스트에서 해당 모듈이 호출했을 때 리턴하는 가상하위 모듈
- 테스트 대상과 상호 작용하는 에뮬레이터
- 단지 기능 또는 프로시저 헤더 등의 코드 루틴만 갖고 내부 프로세싱은 제한적으로 존재하거나 존재하지 않는 것이 일반적

The use of a stub when top-down testing C

테스트 결과

1. Test Log

테스트 로그(Test Log)는 소프트웨어 테스트 과정에서 발생하는 모든 활동, 이벤트, 발견된 오류, 테스트 결과를 기록하는 문서나 파일을 말한다. 테스트 로그는 테스트의 진행 상황을 추적하고, 테스트 결과를 분석하며, 품질 보증 및 테스트 과정의 투명성을 확보하기 위해 필수적으로 작성한다.

테스트 로그에는 다음과 같은 정보를 포함한다.

  • 테스트 케이스 ID: 어떤 테스트 사례가 실행되었는지 식별하기 위한 고유 번호나 이름.
  • 테스트 실행 날짜와 시간: 테스트가 수행된 정확한 시간.
  • 테스트 수행자: 테스트를 실행한 사람이나 팀.
  • 테스트 환경: 테스트가 수행된 환경에 대한 상세 정보(예: 하드웨어, 운영 체제, 소프트웨어 버전 등).
  • 테스트 결과: 테스트가 성공적으로 수행되었는지, 실패했는지에 대한 결과.
  • 오류 로그: 테스트 중에 발견된 오류나 버그에 대한 상세 정보.
  • 비고: 테스트 수행 과정에서의 특이 사항이나 추가적인 관찰 사항.

테스트 로그는 테스트 과정의 효율성과 효과를 평가하는 데 중요한 자료로 활용되며, 품질 개선 및 향후 유사한 프로젝트의 테스트 계획 수립에 귀중한 참고 자료가 된다. 또한, 테스트 로그는 테스트가 정확히 어떻게 수행되었는지에 대한 객관적인 증거를 제공하므로, 프로젝트 관리 및 감사(감리) 과정에서 중요한 역할을 한다. 

2. Test Report

테스트 보고서는 소프트웨어 테스트 과정을 마친 후 작성되는 문서로, 테스트 결과의 요약, 분석, 평가를 포함한다. 이 보고서는 테스트 활동의 성과와 발견된 결함, 테스트 커버리지, 추천 사항 등을 포함하여 프로젝트 관리자, 개발 팀, 그리고 이해관계자들에게 제공되는 중요한 커뮤니케이션 도구이다. 

테스트 보고서에 포함되는 주요 내용은 다음과 같다.

  • 개요: 테스트의 목적과 범위를 설명.
  • 테스트 환경: 테스트가 진행된 환경(하드웨어, 소프트웨어, 네트워크 설정 등)에 대한 정보를 제공.
  • 테스트 결과: 성공, 실패, 중단된 테스트 케이스의 수와 같은 통계적 요약 및 각 테스트 케이스의 결과를 상세히 기술.
  • 결함 요약: 발견된 결함의 수, 심각도, 상태(해결됨, 미해결 등)에 대한 요약.
  • 테스트 커버리지: 테스트가 소프트웨어의 어떤 부분을 얼마나 커버했는지에 대한 분석.
  • 위험 평가 및 권장 사항: 테스트 결과를 바탕으로 한 위험 평가와 프로젝트의 품질 향상을 위한 권장 사항.
  • 결론: 테스트 활동의 전반적인 평가와 소프트웨어의 출시 가능성에 대한 의견을 제시.

테스트 보고서는 테스트 프로세스의 투명성을 보장하고, 프로젝트의 진행 상황을 모니터링하며, 품질 관리 결정을 내리는 데 중요한 근거를 제공한다.

 

3. Incident Report

Incident Report는 소프트웨어 테스트 과정에서 발견된 문제나 결함을 상세하게 기록하는 문서로 발생한 사고의 성격, 발생 시간, 영향을 받은 기능, 문제를 발견한 경로, 재현 방법, 잠재적인 영향, 해결을 위한 제안된 조치 등을 포함한다. Incident Report의 주요 목적은 프로젝트 팀, 개발자, 테스터 간의 효과적인 커뮤니케이션을 지원하고, 문제의 해결 과정을 추적하며, 향후 유사한 문제를 예방하기 위한 교훈을 제공하는 것이다.

Incident Report는 일반적으로 다음과 같은 항목을 포함한다.

  • 사고 ID: 사고를 구별하기 위한 고유 번호나 식별자.
  • 보고 날짜: 사고가 보고된 날짜.
  • 보고자: 사고를 보고하는 사람의 이름.
  • 영향을 받은 시스템 또는 컴포넌트: 문제가 발생한 시스템이나 컴포넌트의 명칭.
  • 사고 설명: 사고의 세부 사항, 발생 경위, 관련된 기능 등에 대한 설명.
  • 재현 단계: 문제를 재현하기 위한 구체적인 단계.
  • 영향 평가: 사고가 시스템이나 사용자에게 미치는 영향의 평가.
  • 해결 상태: 사고가 해결되었는지, 진행 중인지, 또는 미해결인지의 상태.
  • 조치 항목: 문제를 해결하기 위해 취해진 조치나 취할 계획인 조치.

사고 보고서는 문제 해결을 위한 중요한 도구이며, 소프트웨어의 품질을 향상시키고 유사한 문제의 재발을 방지하는 데 도움을 준다.

 

반응형

'Software Engineering > Testing & Debugging' 카테고리의 다른 글

경계값 분석(Boundary value analysis)  (3) 2024.04.26
Debugging  (0) 2023.04.23
화이트 박스 테스트  (0) 2023.04.22
블랙박스 테스트  (0) 2023.04.20
테스트 가이드라인  (2) 2023.04.16

댓글