[소프트웨어 테스팅] 6. 고수준 테스팅

 

회사일과 개인프로젝트 해보고 싶은 것이 있어서 준비하느라

바빠서 포스팅을 꾸준하게 하지 못했다.. ㅠㅠ

핑계 그만대고 각설하고 다시 해보자!!

 

2022.05.16 - [컴퓨터 공학/0 +소프트웨어 테스팅] - [소프트웨어 테스팅] 5. 모듈 테스팅(단위 테스팅)

[소프트웨어 테스팅] 5. 모듈 테스팅(단위 테스팅)

 

지난 시간에는 모듈 테스팅에 대해서 포스팅 했다.

이번에는 고수준 테스팅에 대해서 포스팅 해보도록 하겠다.

 

---

 

 

고수준 테스팅

프로그램 모듈 테스팅이 끝냈다면, 이제 겨우 테스팅 프로세스를 시작한것이다.

최종 사용자가 논리적으로 기대하는 동작을 프로그램이 실행하지 않을때 소프트웨어 오류가 발생하는데

정말로 완벽한 모듈 테스트를 수행하더라도 소프트웨어의 모든 오류를 발견 했다고 확신 할 수 없다..!

그래서 테스팅을 완료하려면 어떤 추가의 테스팅이 필요한데,,,

그게 바로 고수준 테스팅이다.

 

 

소프트웨어 개발 프로세스

아래 그림과 같이 7단계로 요약 할 수 있다.

 

1. 요구사항

프로그램 사용자의 요구를 일련의 요구사항으로 변형, 요구사항은 제품의 목표

요구사항이 프로그램에 필요한 이유를 명시한다.

 

2. 개발목적

기능성, 비용을 평가하고 대립되는 요구사항을 해결한다.

또한, 우선순위와 균형을 맞추면서 요구사항을 개발 목적으로 변형

프로그램이 무엇을 해야하는지와 그것을 얼마나 잘해야 하는지 지정한다.

 

3. 외부 명세

제품을 블랙박스로 보면서 제품의 최종 사용자와 제품의 인터페이스 간 상호작용만 고려해 명세를 목적이 정확한 명세로 바꾼다.(목적이 정확한 명세 = 외부 명세)

프로그램이 사용자에게 정확하게 무엇을 하는지 정의

 

 

후속 프로세스와 관련된 문서화에는 프로그래밍 어떻게 구성되었는지 점차 상세하게 기술한다.

4. 시스템 설계

시스템을 개별 프로그램, 컴포넌트 또는 서브시스템으로 나누고 상호 인터페이스를 정의

(제품이 오퍼레이팅 시스템, 비행 관제 시스템, 데이터 베이스 시스템, 직원 인사 관리 시스템과 같은 경우)

 

5. 프로그램 구조 설계

각 모듈의 기능, 계층별 구조, 모듈 간 인터페이스를 명세화 하여 프로그램 구조 설계

 

6. 모듈 인터페이스 명세

각 모듈의 기능과 인터페이스를 정의한 상세 명세를 개발

 

7. 코드

여러 번의 세부 단계를 통해 각 모듈의 인터페이스 명세를 소스코드로 구현

 

 

 

7단계 개발 주기에서 오류를 예방하고 발견 할 수 있는 3가지 상호 보완적 접근법

1. 개발 과정을 명확하게 한다.

2. 각 개발 프로세스 마지막에 별도의 검증 단계를 만들어 다음 프로세스로 넘어가기 이전에 가능한 많은 오류를 발견한다.

3. 서로 다른 테스팅 프로세스를 각 개발 프로세스에 맞춰 배치

• 모듈테스트의 목적
  • 프로그램 모듈과 모듈 인터페이스 명세 간의 차이를 발견하는 것
• 기능테스트의 목적
  • 프로그램이 외부 명세와 다르다는 것을 보이는 것
• 시스템 테스트의 목적
  • 제품이 원래 개발 목적에 부합하지 않음을 보이는 것

 

고수준 테스팅

 

위 그림의 테스팅 프로세스의 순서는 시간 순서를 의미하는 것은 아니다.

병렬로 작업 가능하다.

 

고수준 테스팅에 사용하는 기법들은 테스트 대상 프로그램마다 각기 다르다.

 

---

728x90

 

기능 테스팅(Functional Testing)

• 기능 테스팅은 프로그램과 외부명세(시스템 명세)의 차이를 찾는 프로세스
• 외부 명세(시스템 명세)는 최종 사용자 관점에서 프로그램 동작을 상세히 기술한 것
• 기능 테스팅은 일반적으로 블랙박스 활동
  • 화이트 박스 로직 커버리지 기준은 모듈 테스팅에서 달성되어야 한다.
• 동등분할, 경계 값 분석, 원인-결과 그래프, 에러 추측과 같은 방법은 기능 테스팅에 있어 최적의 방법

기능테스팅의 목적은 프로그램이나 외부 명세의 불일치를 찾는것!

 

---

 

시스템 테스팅(System Testing)

 

• 시스템 테스팅은 가장 잘못 알고 있고 실행하기가 가장 어려운 테스팅 프로세스
• 시스템이나 프로그램 기능을 테스트하는 프로세스가 아님
  • 기능 테스트 프로세스와 중복 되기 때문
• 시스템이나 프로그램 목적을 원래 목적과 비교하는 것
  • 시스템에 한정되지 않는다.
  • 프로그램이 전체적으로 개발 목적을 충족하지 않는 다는 것을 찾아내는 프로세스
  • 문서화 되고 측정 가능한 제품의 개발 목적이 없다면, 본질적으로 시스템 테스팅은 이루어 질 수 없음
• 프로그램과 개발 목적간의 불일치를 찾을 때, 개발 목적을 근거로 외부 명세를 설계하는 프로세스 도중 생성되는 변환 오류에 주의
• 이 단계에서 오류가 발생할 가능성이 높기 때문에 반드시 필요한 과정
• 테스트 케이스 도출의 근거로 외부명세를 사용하지 않음(기능테스는 외부 명세를 사용)
• 개발 목적 문서도 직접 사용하지 않음(외부 인터페이스에 대한 정확한 기술이 없기 때문)
• 사용자 문서를 분석해서 테스트 케이스를 생성(개발 목적 분석)
  • 사용자 문서를 개발 목적(+문서)과 비교
• 구체적인 테스트 케이스 설계 방법론은 없음
  • 구체적인 프로그램 기능은 기술되어 있지 않기 때문 
  • 테스트 설계 방법론을 기술하기 보다는 시스템 테스트 케이스 종류를 설명

 

15가지 테스트 종류에 대해서 알아보자...!😀

 

 

편의 테스팅(Facility Testing)

• 목표에 언급된 각 Facility가 실제로 구현 되었는지 확인하는 것
• 컴퓨터가 없이 진행 가능
• 사용자 문서와 개발 문서를 비교한다.(머리 속으로 가능)
  • 개발 목적을 문장 단위로 읽고 특정 문장에 What이 명세 되어 있으면, What을 충족하는지 확인 
  • 체크리스트를 작성하는 것을 권장(다음 테스트 진행시 편리함)

 

 

볼륨 테스팅(Volume Testing)

• 프로그램이 대량의 데이터를 처리 할 수 있는지 확인
• 프로그램이 개발 목적에 명시된 대량의 데이터를 처리할 수 없음을 보이는 과정

 

 

스트레스 테스팅(Stress Testing)

• 과도한 부하(짧은 시간 동안 발생)나 스테레스 상황에서의 작동 여부 확인
• 웹 기반 애플리케이션에서는 스트레스 테스트가 필수적이다.
• 운영되는 동안에만 발생하는 상황을 반영
• 일부는 절대 발생하지 않을 상황에서 실행
  • 비현실적인 상황에서 오류가 발생한다면, 동일한 오류는 스테레스가 적은 실제 상황에서도 발생할 가능성이 높다는 것을 의미한다.

 

 

사용성 테스팅(Usability Testing)

• 사용자가 프로그램을 사용할 때 얼마나 사용하기 어려운지 밝히는 프로세스
• 기본적으로 블랙박스 테스팅 기법
• 아래 포스팅 참고

[소프트웨어 테스팅] 7. 사용성(사용자) 테스팅(Usability(User) Testing)

 

 

보안성 테스팅(Security Testing)

• 프로그램의 보안 기능을 파괴하는 테스트 케이스를 고안하고 실행하는 프로세스
• 다음 포스팅에서 상세히 다룰 예정

 

 

성능 테스팅(Performance Testing)

• 프로그램이 개발 목적 중 성능 목적을 충족하지 못함을 보여주기 위해 실행하는 프로세스
  • 프로그램의 정해진 성능, 효율성, 부하, 응답시간, 처리율 같은 특성을 만족 못하는지

 

 

스토리지 테스팅(Storage Testing)

• 스토리지 목표가 충족되지 않은 것을 보여주기 위해 테스트 케이스를 고안하고 실행하는 프로세스
  • 성능 테스팅과 마찬가지로 프로그램들은 사용하는 주 메모리, 보조 메모리의 크기나 임시 파일이나 조각난 파일의 크기와 같은 목표값이 있다.
  • 프로그램은 시스템 메모리 사용을 제어할 수 있으며, 호스트 내에서 운용중인 다른 프로세스에 부정적인 영향을 미치지 않아야 한다.
  • 파일 시스템 상에서 동일한 물리적 파일을 잡고 있는 상황에서 디스크 드라이브를 작성하면 크리티컬한 장애 시간이 발생 할 수 있다.

 

 

구성 테스팅(Configuration Testing)

• 하드웨어 장치의 각 종류와 최고 구성과 최대 구성의 조합이 만족하지 않는 것을 보여주기 위해 실행하는 프로세스
• 프로그램이 다른 컴퓨터에서 실행될 수 있다면, 가능한 각각의 구성 조합도 모두 테스트해야함
  • 많은 프로그램은 운영체제를 고려해서 설계
  • 지원하는 모든 운영체제에서 테스트해야함

 

 

호환성/전환 테스팅(Compatibility Testing)

• 호환성 목표를 만족하지 못하고 전환 절차가 동작하지 않는 것을 입증하는 것을 목적으로 함
  • 대부분 프로그램은 리팩토링을 통해 레거시를 제거하는 경우가 많다.
  • 현재 있는 기능에서 추가 기능을 구현하거나 새로운 기능을 개발하는 경우가 많다.
• 기존 시스템에서 특정한 호환성과 관련한 구체적인 목표를 가지고 기존 시스템에서 전환 절차를 따른다.

 

 

설치성 테스팅(Installation Testing)

• 설치 절차대로 진행되지 않음을 입증하는 것을 목적으로 함
  • 일부 프로그램은 설치 절차가 복잡
  • 자동화 설치 기능이 프로그램 패키지인 경우 중요
  • 설치가 사용자가 애플리케이션을 사용하는 첫 경험
  • 이 단계가 제대로 안된다면 사용자가 프로그램을 신뢰 할 수 없음

 

 

신뢰성 테스팅(Reliability Testing)

• 모든 테스팅의 목적이 프로그램의 신뢰성 향상이지만, 프로그램이 개발 목표에 신뢰성 목표가 구체적으로 명시되어 있다면 구체적인 신뢰성 테스트를 준비해야 한다.
  • 테스팅의 신뢰성 목표는 달성하기 어렵다...😥
  • 그 이유는 99.7%의 서버 가동시간을 목표로 한다면, 이 목표를 확인하기 위해서 몇 달 몇년 동안 테스트해야 하는지 알 수 있는 방법은 없다....
  • 20시간의 MTBF(Mean Time Between Failures)나 생산 배치 후 사용 과정에서 발견되는 결함이 12개 이하라는 목표를 가진 시스템은 통계적 프로그램 입증 테스팅이나 모델 기반 테스팅 등의 특별한 방법을 사용해 테스트 할 수 있음.

https://link.springer.com/content/pdf/10.1007/BFb0014980.pdf

• 귀납적 공리 방법
  • 테스트 대상 프로그램에 오류가 없음을 증명할 수 있는 몇 가지 명제 개발이 목표
    • 입력 조건, 출력 조건에 대한 가설
    • 프로그램 루프에 대해 임의의 시작점에서 변하지 않는(항상 참인)조건을 알리는 가설 추가
    • 모든 경로에서 가설과 가설 사이에 있는 프로그램 구문의 의문을 파악하면서 경로 끝에 도달

 

 

회복 테스팅(Recovery Testing)

• 대부분 프로그램은 오류가 발생 했을 때 복구하는 방법을 기술한 회복성 목표가 있음
• 이러한 회복 관련 기능(or MTTR: Mean Time To Recovery)들이 정상적으로 동작하지 않음을 보여주는 것
• 보통 평균 회복 시간(MTTR)을 최소하는것을 목표로함

 

 

서비스 가능성/유지 보수 테스팅(Serviceability / Maintenance Testing)

• 서비스 가능성 or 유지 보수의 특성에 대한 목표를 테스트
• 스토리지 덤프 프로그램, 진단기 등의 시스템, 명백한 문제를 디버깅하는 평균 시간, 유지보수 절차 및 내부 로직 문서의 품질과 같은 부가적인 서비스 지원 여부가 목표가 된다.

 

 

문서 테스팅(Documentation Testing)

• 사용자 문서의 정확성도 함께 테스트 해야한다..!🧐
• 사용자 문서를 주요 시스템 테스트 케이스를 도출하는 수단으로 사용(가장 효과적)
• 사용자 설명서도 역시 인스펙션을 사용해 정확성과 명확성을 검증
• 사용자 문서에 설명된 모든 예제를 테스트 케이스를 만들어 프로그램을 테스트

 

 

절차 테스팅(Prodcedure Testing)

• 대부분의 프로그램은 사람이 수행하는 대규모 시스템의 일부이다.(자동화 되지 않은)
• 시스템 운영자, 데이터 베이스 관리자, 최종 사용자를 위한 매뉴얼은 시스템 테스팅 단계에서 테스트해야 한다.
  • 데이터 베이스의 백업 및 복구 절차를 문서화 해야함
  • 가능하다면 해당 직무와 관련없는 사람이 절차를 테스트 해야함

 

 

시스템 테스팅 수행(Performing the System Test)

 

• 누가 테스트를 진행 할 것인가!?
  • 프로그래머는 시스템 테스트를 수행하면 안됨
  • 프로그램 개발 조직이 수행해서는 절대로 안되는 것이 시스템 테스팅!!!!!!!!!!!!!!!!!!!!!!!!!
• 시스템 테스트를 수행하는 사람은 반드시 최종 사용자처럼 생각
• 어떤 제한 없이 무엇이든지 할 수 있는 작업

 

 

---

 

인수테스팅(Acceptance Testing)

• 테스트 대상 프로그램과 초기 요구 사항 및 현재 사용자의 요구를 비교하는 프로세스
• 일반적으로 최종 사용자에 의해 수행
• 개발 조직의 책임으로 간주되지 않는 특이한 형태의 테스팅

 

---

 

설치 테스팅(Installation Testing)

• 설계 단계와 관련이 없는 테스트
• 설치하는 과정에서 발생하는 오류 발견하는 테스트
• 시스템 개발 조직이 개발하고 시스템의 일부로 공급되며, 시스템이 설치된 후 수행된다.

 

---

 

테스트 계획 및 관리(Test Planning and Control)

• 테스트 프로세스는 개발주기 마지막에 있기 때문에 리소스 변경이 어려운 복합적인 문제가 있다.
  • 잘못된 테스팅의 정의를 사용하는 것
• 좋은 테스트 계획 요소
  • 목표
    • 각 단계의 목표가 정의 되어야함
  • 완료 기준
    • 각 테스트 단계가 언제 완료될지 판정할 수 있는 기준 설계
  • 일정
    • 테스트 단계 마다 구체적인 일정이 계획되어야 한다.
  • 책임
    • 각 테스트 단계다마 테스트 케이스 설계, 작성, 실행에 대한 담당자 지정
    • 누가 테스트 케이스를 검증하고 발견된 오류를 수정할지를 지정
    • 분쟁 중재자도 있으면 좋다.
  • 테스트 케이스 라이브러리와 표준
    • 대규모 프로젝트에서는 테스트 케이스의 구분, 작성, 저장에 대한 체계적인 방법 필요
  • 도구
    • 누가 테스트 도구를 개발하지, 누가 구매할지, 어떻게 사용할지, 언제 필요할지 같은 계획을 포함해서 사전에 테스트 도구를 정의해야함
  • 연산시간
    • 테스트 단계별로 필요한 연산시간을 계획
      • 컴파일에 필요한 서버, 설치 테스트를 위한 컴퓨터, 웹 기반 애플리케이션을 위한 웹 서버...
  • 하드웨어 구성
    • 특별한 하드웨어 구성과 장치가 필요할 경우, 요구 사항과 해당 사항을 충족시킬 수 있는 방법, 계획 등이 필요함
  • 통합
    • 점진적 하향식 테스팅 같은 프로그램을 합치는 방법이 정의되어야 함
    • 통합 순서, 시스템의 버전 별 기능 목록, 개발되지 않는 구성 요소의 기능의 임시코드 제작...
  • 추적 절차
    • 오류 발생 가능성이 높은 모듈의 정보와 테스트 일정, 자원, 완료 조건을 포함한 테스팅 진척을 추적
  • 디버깅 절차
    • 발견한 오류 보고, 오류 수정 상황 추적, 수정 사항 반영 절차를 만들어야 함
  • 리그레션 테스팅(Regression Testing)
    • 기능 개선 또는 결함 수정 후에 수행함
    • 프로그램 변동으로 인하여 문제가 발생되었는지 확인하는것이 목적임
    • 변경하거나 오류를 수정한 코드에서 오류 발생 가능성이 훨씬 높기 때문에 매우 중요한 테스팅 기법이다

 

---

 

테스트 완료 기준(Test CompletionCrieria)

프로그램 테스트에서 가장 답변하기 어려운 질문은 바로바로바로바로

테스팅을 언제 끝내야 하는지에 대한 결정이다...!! ㅠ0ㅠ

그이유는 지금 결함이 마지막 잔여 결함이라는 것을 알 수가 없기 때문이다...

 

실무에서 가장 많이 사용하는 테스트 완료 기준에 대해서 알아보자(사실상 해당 기준은 무의미하고 비생산적이라고 한다)

1. 정해진 테스트 일정이 지나면 테스트 종료
2. 모든 테스트 케이스를 실행해도 더 이상 결함이 발견되지 않으면 테스트 종료

즉, 테스트 케이스가 의미 없게 되면 테스트를 종료

 

첫번째 기준은 아무것도 하지 않아도 그 기준에 충족하기 때문에 무의미하다.

두번째는 테스트 케이스의 품질을 고려하지 않아서 무의미 하다.

 

 

그러면 유용한 테스트 완료 기준은 무엇일까?

 

1. 특정 테스트 케이스 설계 방법론을 기본 완료 조건으로 사용

 

e.g)

(1)다중조건 커버리지와 (2)모듈 인터페이스 명세의 경계 값 분석을 만족해야한다.

문제점

• 시스템 테스트와 같이 명확한 테스트 설계 방법론이 없는 테스트 단계에서는 적용될 수 없는 경우가 발생
• 다중조건 커버리지와 같은 기법이 적절하게 사용된것인지 보장 할 수 없음
• 테스터가 목표를 정하지 않은 상태에서 테스트 설계 기법을 정할 수 있음

 

 

2. 구체적으로 명시된 목표를 완료 기준으로 정의

 

테스트의 목적이 결함을 발견하는 것이므로, 결함 발견 목표 수를 미리 정의하고 이를 완료기준으로 사용 할 수 있다.

이를 위해서는 다음과 같은 3가지 정보가 필요하다.

• 테스트 대상 프로그램의 총 오류 개수 추정치
  • 이전 프로그램 경험을 바탕으로 추정
  • 일반적으로 대략 100 code당 4 ~ 8개의 오류가 존재한다고 한다.
• 전체 결함 중 테스트를 통해 발견할 수 있는 오류 발견율 추정치
  • 임의적인 추측이 필요
  • 잠재 결함으로 인한 영향 등을 고려해야함
• 개발 프로세스 별 오류 원인 분포 추정치와 이 오류가 어떤 테스트 단계에서 발견될 수 있는가에 대한 추정
  • 오류가 어떻게 만들어지는가에 대한 정보가 부족하기 때문에 추정하기 어려움
  • 오류의 40%가 코딩과 논리설계 단계에서 실수로 발생
  • 그외 초기 설계 단계에서 발생

 

정리하자면

모듈 테스트 단계에서는

1. 특정 테스트 케이스 설계 방법론을 기본 완료 조건으로 사용  하는 것이 적합하다.

결함 추적을 공식적으로 하지 않기 때문

 

기능 테스트와 시스템 테스트 단계에서는

오류가 예측한 수만큼 발견되었고 동시에 계획한 테스트 일정이 모두 지났다면 테스트 완료 기준에 도달 한 것으로 보고 테스트를 종료

 

 

---

 

독립적 테스트 기관(The Independent Test Agency)

앞서 이야기 한 내용 처럼 개발 조직은 자신이 개발한 프로그램을 직접 테스트하는것을 지양해야한다.

객관적으로 테스트하기 어렵기 때문.

회사에서 여건이 안된다면, 업체를 이용하는것이 좋다.

 

---

반응형

 

정리

고수준 테스팅은 프로젝트의 크기가 증가함에 따라 중요해지고 있다.

기능 테스팅은

설계오류, 즉 완성된 프로그램과 외부 명세의 차이를 밝히려고 하는 작업

이는 최종 사용자의 관점에서 프로그램의 수행을 정확하게 설명하려 하는 것

 

시스템 테스트는

소프트웨어와 원래 목표간의 관계를 테스트 한다.

외부 명세에 프로그램의 목표를 변환하는 과정에서 코드라인에 만들어진 오류를 발견하기 위해 설계 된다.

 

이러한 여건이 없다면 독립적인 테스트 기관을 활용하는것도 나쁘지 않다.