소프트웨어 테스팅
소프트웨어의 품질을 확보하고 결함을 찾아내기 위해 수행되는 일련의 작업
일반적인 소프트웨어 테스트 목적
오류검사, 요구사항 검증, 유지보수
- 소프트웨어 내에 존재하는 오류 발견 (검사)
- 소프트웨어 요구사항에 충족하는지 확인 (검증)
- 소프트웨어 명세(요구사항)에 충족하는지 확인 (검증)
- 소프트웨어 출시 이후 발생할 수 있는 결함을 예방 (유지보수)
테스트의 목적은 높은 확률로 오류를 찾아낼 수 있도록 좋은 시험 사례를 설계하는 것이다.
모든 오류를 찾는 것은 불가능하므로 가장 적은 양의 시험 데이터를 사용하여 가장 많이 프로그램 오류를 잡아내는 것이 테스트의 목적이다.
부가적인 목적
- 품질에 대한 자신감과 정보 확인
- 개발 프로세스(방법론) 점검 및 이슈(장단점에 대한 정보) 제공
테스트 작업은 단순한 코드상의 오류(검사)만을 찾는 작업이 아니라 요구분석에서의 오류, 설계 또는 모듈 인터페이스의 오류(검증) 등 개발 단계의 작업들에 대한 테스트를 포함한다.
V 모델은 폭포수 모델에 시스템 검증과 테스트 작업을 강조한 것이다.
-
요구사항 분석
인수 시험과 시스템의 목적에 부합되는가를 확인하는 시스템 시험 계획 -
기본 설계(아키텍처 설계)
시스템 아키텍처 구성과 메뉴 구조, 자료구조를 설계
모든 모듈 항목과 기능 정의, 모듈간 인터페이스, 관계, 의존성 기술, 필요한 DB 테이블, 아키텍처 다이어그램, 적용 기술 내역이 문서화된다. -
상세 설계(모듈 설계)
각 모듈에 대한 상세 알고리즘 작성, 인터페이스 상세사항 작성, DB의 테이블 구조와 요소별 타입, 크기 기술, 각 단위 모듈에 대한 단위테스트 케이스, 절차 설계
단위 테스트
프로그램의 기본 단위인 모듈에 대한 테스트
- 모듈의 중요한 경로(알고리즘의 수행 경로)와 경계 값(모듈의 인터페이스)을 테스트해야 한다.
- 코드의 효율성, 코딩 컨벤션을 준수하는지 검증한다.
- 모듈 내부 구조에 대한 조사를 수행하는 화이트박스 테스트이다.
특징:
1. 모듈은 독립적인 프로그램이 아니기 때문에 드라이버 모듈 또는 스터브 모듈 설계가 필요하다.
2. 모듈 설계에 비용이 많이 들어 중요한 모듈만 테스트하는 경우가 많다.
드라이버 모듈: 테스트하려는 모듈을 호출하는 모듈. 테스트 모듈에 데이터를 보내주고, 결과를 출력하는 역할을 수행하는 주 모듈 역할을 수행
한다.
스터브 모듈: 테스트하려는 모듈이 호출하는 가상 모듈. 적은 데이터 처리를 수행하거나 고정된 결과를 돌려준다. 드라이버 모듈 설계보다 어렵다.
-
설계 문서를 근거로 작성된 테스트 케이스를 이용하여 모듈이 제대로 구현돼 있는지 테스트한다.
-
모듈을 블랙박스로 놓고 외부 관점의 테스트를 수행한다.
-
각 모듈에 대해 인터페이스, 지역 자료 구조, 경계 조건, 제어 흐름 및 오류 처리 등 다양한 면을 확인한다.
인터페이스 점검 사항
- 변수의 개수, 타입, 단위, 순서를 확인한다.
- 모듈 간 전역 변수에 대해 정확히 사용하고 있는지 확인한다.
자료구조(변수) 점검 사항
- 변수의 초기화 값을 확인한다.
- 데이터 타입을 확인한다.
- 계산에서 언더플로우 혹은 오버플로우가 발생하지 않는지 확인한다.
오류처리 점검 사항
- 오류 처리 전 원하지 않는 시스템 개입을 야기시키지 않고, 오류 조건이 정상처리과정에 반영되는지 확인한다.
- 오류에 대한 서술이 오류 위치를 차즌데 필요한 정보를 충분히 제공하는지 확인한다.
통합 테스트
각각의 모듈들을 통합하여, 통합된 컴포넌트 간의 인터페이스와 상호작용 상의 오류를 발견하는 작업을 수행
- 블랙박스 테스트를 통해 확인.
- 기본 설계(아키텍처 설계) 단계에서 진행.
- 점진적 통합 테스트 실시. (드라이버, 스터브 모듈 필요)
점진적 통합 테스트에서는 하향식 통합 테스트나 상향식 통합 테스트 방법을 이용할 수 있다.
하향식 통합
깊이 우선, 넓이 우선 방식이 있다.
- 기본 절차
- 주 모듈을 드라이버 모듈로 하고 종속 모듈은 스터브 모듈로 한다.
- 하나의 하위 모듈을 선택하여 통합하고 테스트한다.
- 모든 모듈이 통합되어 테스트될 때까지 두 번재 단계를 반복한다.
넓이 우선 통합 방식 ↓
장점: 프로그램의 주요 제어 흐름을 테스트 단계 초기에 확인 가능하다.
단점: 스터브 모듈을 설계해야 하는 것이 어렵다. 스터브는 제한된 기능만을 수행하여 중요한 데이터를 넣어 실험하지 못하는 한계점을 가진다.
상향식 통합
- 기본 절차
- 드라이버 모듈을 설계하여 하위 모듈들과 결합시켜 테스트한다. 모듈들의 묶음은 클러스터(cluster)라고 한다.
- 드라이버 모듈을 실제 모듈로 대체하고 한 층 더 높은 드라이버 모듈을 설계하여 더 큰 클러스터로 통합하여 테스트한다.
- 전부 모듈이 통합되어 테스트될 때까지 두 번째 단계를 반복한다.
위 그림에서 4를 테스트 시 5, 2, 1에 대한 모듈이 필요하다.
3, 6 모델은 독립되어 있으므로 병렬적, 독립적으로 테스트 후 마지막에만 모이면 된다.
장점:
드라이버 모듈의 설계가 상대적으로 쉽고, 동시에 테스트를 진행할 수 있다.
중요한 모듈을 먼저 테스트 할 수 있다.
단점: 프로그램의 전체적 윤곽을 초기에 볼 수 없어 고객의 요구 사항과 위배되는 오류를 일찍 발견하기 어렵다.
고객은 main()의 결과를 보고 싶어함.
새로 추가된 모듈이 기존 모듈과 상호작용하며 서로 영향을 주고, 기존 테스트에서 발생하지 않았던 오류가 발생할 수 있어 기존 테스트를 다시 수행할 수 있다. -> 회귀 테스트
회귀 테스트 케이스 선정
- 소프트웨어의 전체 기능을 수행할 수 있는 대표적인 테스트 케이스를 재수행
- 새로운 모듈에 의해 영향을 받을 수 있는 기능에 대해 회귀 테스트 수행
- 변경된 소프트웨어 구성 요소에 대해 집중적으로 회귀 테스트 수행
시스템 테스트
실제 구현된 시스템과 계획된 사양을 서로 비교하는 작업
모듈이 통합된 후 시작
시스템의 기능을 시험 확인하고 성능이나 기능에 제한이 없는지 확인
시스템 테스트의 테스트 종류
- 복구 테스트 : 소프트웨어를 고장나게 해서 시스템의 복구 능력을 확인
- 보안 테스트 : 불법 침입자의 침입을 막을 수 있는지 확인
- 스트레스 테스트 : 비정상적인 상태에서 소프트웨어의 기능과 성능을 테스트
- 성능 테스트 : 시스템의 수행 성능에 대한 테스트
인수 테스트
개발된 소프트웨어가 고객의 요구사항을 만족하는지 조사하는 시험을 확인 테스트라고 하고 사용자가 수행하는 확인 테스트를 인수 테스트라고 한다.
- 개발된 소프트웨어가 사용자의 요구에 만족하는지 검증하는 목적으로 수행
- 요구사항 분석 단계에서 도출된 시스템의 사양이나 계약을 만족하는지 확인
α-테스트: 사용자가 개발환경에 와서 하는 테스트
적합한 환경(제한된 환경)
β-테스트: 개발자가 사용자에게 소프트웨어를 배포하고 사용자의 환경에서 수행하는 테스트
사용자의 환경(자유로운 환경)
