소프트웨어 테스트 방법 및 설계 기법
- 블랙박스 테스트: 테스트하고자 하는 소프트웨어의 내부는 고려하지 않고 주어진 입력에 요구되는 결과가 나오는가를 테스트
- 화이트박스 테스트: 프로그램의 내부 구조를 참조하여 테스트
난이도
블랙박스 < 화이트박스
블랙박스 테스트
프로그램 외부와의 인터페이스에 대해서 테스팅
프로그램의 기능에 대한 초점, 주어진 입력 값들의 조합에 의해 요구되는 결과가 나오는가를 점검하는 것
-
프로그램의 내부는 참조하지 않고 설계 명세서 또는 요구사항 명세서를 참조한다.
-
테스트 케이스 도출 기법
-
동등분할 : 대상의 입출력 값을 클래스로 분할, 각 클래스의 대표 값을 추출하여 테스트 케이스 생성, 테스트 데이터의 범주를 식별하는 기법
-
경계값 분석 : 동등 분할 기법을 확장시킨 것, 클래스 경계에 대한 값들까지 검사하는 기법
-
페어와이즈 조합
-
상태 전이
-
인과 그래프
-
결정 테이블
동등 분할
오류 종류에 따라 프로그램의 입력 데이터를 분류하여 시험 사례를 설계
입력 조건이 값의 범위를 지정하면 한 유효 등가 클래스와 두 무효 등가 클래스를 정의한다.
입력 조건이 특정치를 요구하면 한 유효 등가 클래스와 두 무효 등가 클래스를 정의한다.
입력 조건이 집합의 구성 원소들을 지정하거나 Boolean이면 유효 클래스와 무효 클래스는 각각 하나이다.
경계값 분석
프로그램 설계 및 개발에서 경계값 처리에 대해 실수할 가능성이 높고 경계값 주위의 입력값을 시험 데이터로 하면 오류를 발견할 가능성이 높아진다.
등가 분할 방법을 보충할 수 있는 시험 사례 기법이다.
화이트박스 테스트
내부(코드)의 구성을 시험하는 것
프로그램을 참조하여 이루여지며 구조 또는 코드에 기초한 테스트라고도 한다.
각 모듈 안의 동작을 자세히 관찰하는 시험 방법
많은 오류를 제거시켜 주나 모든 가능한 시험 사례의 생성은 불가능하다.
-> 적정한 개수의 테스트 케이스를 찾는 것이 중요하다.
화이트박스 테스트 검증 기준
-
모든 실행문 커버리지
-
분기/결정 커버리지 - 조건문(if문 같은)
-
조건 커버리지 - 조건식(a > 0 같은), 고려해야 할 것이 분기/결정 커버리지 보다 더 많다.
-
변경 조건/결정 검증기준
-
다중 조건 - 모든 조건문의 조합을 고려해야 한다.
-
기본 경로 테스트
-
자료 흐름 테스트
1 -> 7로 갈 수록 테스트 케이스의 개수가 증가하고 복잡해진다.
화이트박스 테스트가 필요한 이유
-
블랙박스 테스트로만은 프로그램의 모든 변수와 상수, 서브루틴의 실행을 포함한 모든 실행문이 실제로 실행되는지 알 수 없다.
-
블랙박스 테스트로만은 부작용을 예측하기 어렵다.
-
프로그램 내 불필요한 기능이 있는 경우를 찾을 수 있다.
-
오타를 찾을 수 있다.
문장 검증 기분(실행문 커버리지)
수행 가능한 모든 문장들이 단 한 번이라도 실행되도록 시험 사례를 만들고, 요구되는 결과가 나오는지 검증해 보는 것
단점: 조건문에 대한 검사는 매우 미약
조건 커버리지
충분한 테스트 케이스를 설계하여 조건문의 모든 조건식을 만족하는 경우와 만족하지 않는 경우를 테스트
조건 검증기준은 조건문의 조건식을 구체적으로 세분화 하여 테스트를 수행
- 조건식에 각각 한 번씩 참 or 거짓이 되는 경우를 찾아야 한다.
변경 조건/ 결정 검증 기준
각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 함으로써 조건/결정 기준을 향상시킨 것
다중 조건 커버리지보다 범위가 좁지만 효과가 좋음.
다중 조건 커버리지
결정 포인트 내에 있는 모든 개별 조건식의 모든 가능한 논리적인 조합을 고려한 가장 가엵한 검증 기준
단점: 테스트 케이스 양이 매우 방대해져 테스트가 힘들다.
테스트 완료 기준 관점
- 테스트 기간에 따른 기준 ex)베타테스트
- 테스트 작업량에 의한 기준 ex) 500시간동안 테스트
- 발견되는 오류가 감소하는데 따른 기준 ex) 발견되는 오류의 기준을 정하고 오류를 줄어나감
- 테스트 케이스의 수에 의한 기준
- 테스트 커버리지에 의한 기준
