테스트는 테스터, 범위, 잠재적 문제, 행위, 평가에 중점을 두는 기법들로 구분할 수 있다.
● 테스트 : 테스트를 수행하는 사람. 예를 들어 사용자 테스트는 판매 대상으로 삼고 있는 사람들과 일반적으로 제품을
사용할 사람들에 의해 수행되는 테스트를 의미한다.
● 범위 : 무엇을 테스트하는가? 예를 들어 함수 테스트에서는 모든 함수를 테스트한다.
● 잠재적 문제 : 왜 테스트를 수행하는가? (어떤 위험요소를 테스트하는가?) 예를 들어 극한값 오류 테스트 등이 있다.
● 행위 : 어떻게 테스트하는가? 예를 들어 탐색적 테스트가 있다.
● 평가 : 테스트를 통과했는지, 실패했는지를 어떻게 이야기할 수 있는가? 예를 들어 이미 알고 있는 좋은 결과와
비교하는 방식이 있다.
▶ 누가 테스트를 수행하는가에 중점을 둔 사람 중심 기법
◎ 사용자 테스트
- 제품을 일반적으로 사용하게 될 사람들에 의한 테스트. 사용자 테스트는 개발 과정동안 당신이나 사용자가 언제든지 지시된 연습 과정에 따라 주의 깊게 수행되거나, 사용자가 임의로 수행하는 방식으로 테스트가 이루어질 수 있다.
◎ 알파 테스트
- 테스트 팀원에 의해 수행되는 내부 테스트(다양한 관심을 가진, 친한 내부 인사에 의해 수행될 수도 있다.)
◎ 베타 테스트
- 당신이 속한 조직의 일부가 아닌, 테스트와 제품의 대상 시장에 속한 사람들에 의해 수행되는 사용자 테스트의 한 형식. 테스트되는 제품은 일반적으로 완성 단계에 거의 근접해 있다. 많은 기업들이 선행 배포 코드를 고객에게 출시하는 것을 베타 테스트로 생각한다. 하지만 실제로 베타 테스트에는 매우 다양한 형식이 존재한다. 사용자(특히 특정 분야 전문가)에게 디자인이 적절한지를 물어보는 디자인 베타 테스트는 결과를 적용할 시간적 여유을 얻기 위하여 가능한 한 빨리 수행되어야 한다. 이 제품을 구입한 대규모 고객들을 설득시키기 위한 마케팅 베타 테스트는 제품이 매우 안정적으로 동작할 수 있도록 매우 늦게 진행되어야 한다. 호환성 베타 테스트는 쉽게 테스트할 수 없는 하드웨어와 소프트웨어의 플랫폼에서 제품을 실행해본다. 이 테스트 역시 호환성 문제를 해결하는데 너무 늦지 않도록 진행되어야 한다. 모든 베타 테스트는 목표를 결정한 다음, 그에 대한 일정과 실행 방법을 결정해야 한다.
◎ 버그 파티
- 간사, 프로그래머, 마케팅 담당자, 그리고 가능한 모든 사람이 동원되는 내부 테스트. 일반적으로 버그 파티는 반나절 정도 진행되며, 제품 출시 준비가 거의 완료되었을 때 수행된다.
◎ 특정 분야-중요도 전문가 테스트
- 소프트웨어가 처리하는 문제 영역에 해당하는 전문가에게 제품을 제공하고, 피드백(버그, 비평, 찬사)을 요청한다. 이때 전문가는 제품을 사용할 것으로 예상되는 사람일 수도 있고, 아닐 수도 있다. 전문가의 가치는 시장성이 아니라 그가 가진 지식으로부터 나오는 것이다.
◎ 짝 테스트
- 두 명의 테스터가 함께 버그를 발견한다. 일반적으로 컴퓨터 한 대를 같이 사용하며, 컴퓨터에 대한 제어권을 주고 받으면서 테스트를 진행한다.
◎ 스스로 사용해보라
- 소프트웨어가 판매되기 전, 실제로 사용자에게 충분한 신뢰성을 갖출 때까지 자사 소프트웨어의 선행 배포 버전을 직접 사용해보라.
▶ 무엇을 테스트하는가에 중점을 두는 범위 기반 기법
무엇을 염두에 두고 테스트를 하는가에 따라 다양한 기법을 구분할 수 있다. 예를 들어 어떤 함수를 다른 함수들과 조합하여 사용할 때 모든 함수가 제대로 동작하는지를 확인한다면 기능 통합 테스트는 범위 기반 테스트이다. 함수들이 상호 동작하는 과정에서의 오류에 대한 논리를 가지고 있고, 그것을 추적하고 싶다면 이는 문제 기반 테스트이다(예를 들어, 각 함수가 다른 함수로 데이터를 전달하는 방식에서 오류가 있는지를 살펴보고 싶다면 이는 문제 기반 테스트이다).
◎ 함수 테스트
- 모든 함수를 하나씩 테스트한다. 함수가 제대로 동작하고 있다고 확신할 수 있을 때까지 철저히 테스트한다. 화이트박스 함수 테스트는 일반적으로 유닛 테스트라고도 하며, 코드상의 함수에 중점을 둔다. 블랙박스 테스트는 명령어와 기능, 사용자가 실행 또는 선택할 수 있는 항목에 중점을 둔다. 함수 테스트를 수행한 다음 여러 함수와 관련이 있는 복합 테스트를 수행하는 것이 현명하다. 함수를 개별적으로 테스트하지 않고 복합 테스트에 의존하고 있다면 매우 늦은 시점에서 함 함수가 잘못되었다는 것을 알게 되고, 복합 테스트의 문제 해결에 많은 시간과 노력을 들인 뒤에서야 문제의 원인이 간단히 하나의 함수에 있었다는 사실을 알게 된다.
◎ 기능 또는 함수 통합 테스트
- 몇 가지 함수를 사용하면서 제대로 동작하는지를 살펴본다.
◎ 메뉴 살펴보기
- GUI 제품의 모든 메뉴와 대화상자를 따라가면서 가능한 모든 선택을 수행한다.
◎ 도메인 테스트
- 도메인이란 함수에 사용된 변수에서 사용할 수 있는 모든 값을 포함하는 (수학적) 집합이다. 도메인 테스트에서는 함수와 변수를 구분한다. 변수에는 입력 변수와 출력 변수가 있다(테스트 분석에는 입력 도메인과 출력 범위가 동일하기 때문에 입력 도메인과 출력 범위를 수학적으로 구분하는 것은 적절하지 않다). 각 변수에서 취할 수 있는 값의 집합을 구분하여 등가 클래스로 나눈 다음, 각 클래스의 대표 값 중 작은 값(일반적으로 경계 사례)을 선택한다. 이 방법에는 각 클래스에서 몇 안 되는 훌륭한 대표 값으로도 클래스의 모든 구성요소들에 대한 모든 혹은 거의 대부분의 버그를 발견할 수 있다는 가정이 숨어있다. 함수 테스트와 달리 함수가 아니라 변수에 관심을 두고 있음을 알아두자. 많은 변수들이 하나 이상의 함수에서 사용된다. 도메인 테스트는 변수를 분석한 다음, 그 분석 결과에 따라 이 변수를 사용하는 각 함수에 대해 입력과 출력으로 테스트를 실행한다.
◎ 등가 클래스 분석
- 등가 클래스는 변수에서 등가라고 생각되는 값들의 집합이다. 클래스에 속한 값들에 대해 (a) 모든 동일한 테스트를 수행하고 (b) 이 중 하나라도 버그가 발견되면 다른 값들에서도 버그가 발견될 것이며, (c) 이 값 중에서 버그를 찾아내지 못한다면 다른 값에서도 마찬가지로 버그를 찾이 못할 것이라고 확신할 수 있을때 이 테스트 클래스는 등가이다. 일단 등가 클래스를 구하고 나면, 각 클래스 구성요소 중 한두 개만 테스트 해본다.
◎ 경계 테스트
- 등가 클래스는 값들의 집합이다. 이를 하나의 수평선으로 옮길 때 클래스의 최소값과 최대값이 경계값이다. 경계 테스트에서는 이 값을 테스트한다. 그리고 테스트하고 있는 클래스의 최대값보다 큰 값이나, 클래스의 최소값보다 작은 값을 사용하여 클래스의 경계 인접값도 테스트해 볼 수 있다.
◎ 최상의 대표 테스트
- 등가 클래스에서 최상의 대표값은 소프트웨어 오류를 노출시키는 클래스 내의 임의의 값이다. 경계 테스트에서는 경계 사례가 거의 대부분 최상의 대표값이다. 그러나 등가 클래스를 수평선으로 옮길 수 없는 경우도 있다. 예를 들어 휴렛팩커드 PCL-5 호환인 프린터는 모두 동일한 방식으로 동작해야 하므로, 이를 등가 클래스라고 해보자. 이제 특정 작업에 대하여 프린터 중 하나가 다른 것보다 문제가 있는 경우를 생각해보자. 이 프린터가 그 클래스에 대한 최상의 대표값이 될 수 있다. 이 프린터가 오동작하지 않는다면 다른 프린터 역시 오동작하지 않을 것이라고 확신할 수 있다.
◎ 입력 필드 테스트 카달로그 또는 매트릭스
- 입력 필드의 각 형식에 대하여 테스트 사례에 대한 명료한 표준 집합을 만든 다음, 이를 해당 제품이나 향후 제품들의 유사 필드에서 사용할 수 있다.
◎ 필드를 수정하는 모든 방식을 테스트하기
- 종종 몇 가지 방식으로 필드의 값을 변경할 수 있다. 예를 들어 불러오기를 한 데이터를 계산한 다음 결과 값을 필드에 넣을 수도 있고, 계산 결과를 이 필드에 복사할 수도 있다. 이 필드에는 제약조건이 있다(취할 수 있는 값의 범위가 정해져 있다). 일부 제약조건은 항상 일정한 반면 어떤 제약조건은 다른 항목들의 값에 따라 달라질 수 있다. 예를 들어 J와 K는 부호가 없는 정수 값인데, 이 값은 0부터 MaxInt 사이의 값을 가져야 한다. 이것은 상수 제약조건이다. 그러나 N이 부호가 없는 정수형인데 N = J + K 이고, N = 5라고 생각해 보자. 이 경우 J = 5- K이므로 J는 5(N값)보다 큰 수가 될 수 없다. 이는 변수 제약조건으로, 가능한 값의 범위가 N 값에 의존한다. J가 허용 가능한 범위(5 - K) 내에 있는지 확인하기 위하여 J에 데이터를 입력하는 여러 방식을 통해 값을 변경시켜 보아야 한다.
◎ 논리 테스트
- 변수는 프로그램에서 연관선을 가진다. 예를 들어 나이가 50보다 많고, 흡연을 하면 보험 가입이 안 된다고 판단하는 결정 규칙을 가진 프로그램을 생각해 보자. 이때 결정 규칙은 논리적 관계로 표현된다. 논리적 테스트는 프로그램에서 모든 논리적 연관성을 확인한다. 원인-결과 그래프는 논리 기반 테스트의 확장된 집합을 설계하기 위한 한 가지 방법이다.
◎ 상태 기반 테스트
- 프로그램은 상태들을 변경한다. 주어진 상태에서 어떤 입력값은 유효하지만, 다른 값은 무시되거나 거부된다. 테스트되는 프로그램은 유효한 입력값이 주어질 때 프로그램이 그 작업을 수행하며, 유효하지 않다면 작업을 수행하지 않는다. 상태 기반 테스트에서는 상태 전이(상태 변화)에 대한 대형 집합을 훑어가면서 프로그램을 실행하여 결과를 매번 신중하게 확인한다.
◎ 경로 테스트
- 경로에는 현재 상태를 얻기 위하여 여러분이 취한 모든 단계나 프로그램이 거친 모든 구문들이 포함된다. 경로 테스트에서는 프로그램의 많은 경로들을 테스트한다. 그러나 프로그램의 사소한 경로를 모두 테스트할 수는 없다. 그러므로 몇몇 테스트들은 많은 부분 경로를 테스트하는 하위 경로 테스트를 수행한다. 또한 편향 경로 테스트에서는 이러한 하위 경로들을 모두 통과하면, 더 긴 경로에 대한 테스트에서는 하위 경로를 테스트할 때 놓친 버그를 발견하기가 어렵다는 가정 하에서, 특정 형식(기초 경로)에 대한 거의 모든 하위 경로를 테스트한다.
◎ 상태 및 분기 범위
- 프로그램에서 모든 구문(또는 코드 행)을 테스트한다면 100% 구문을 다루게 된다. 만약 한 구문에서 다른 구문으로의 모든 분기와 구문을 테스트해 보았다면 100% 구문 및 분기 범위를 다룬 것이다. 행 및 분기를 매우 많이 다루는 테스트 설계법을 종종 "범위 기반 테스트"라고 부른다(이 모든 것을 테스트한 다음 테스트를 중단하거나 별도 테스트를 설계하지 않는다). 우리는 이를 '상태 및 분기 범위'라고 부르며, 범위의 일부 다른 형식에 중점을 두는 테스트 형식과 다르게 구분한다. 구성 범위는 매우 많은 횟수 동안 동일한 구문을 수행하지만 잠재적으로 매우 다른 결과를 가질 수 있는 좋은 예이다. 구문 및 분기 범위 값을 수행하는데 중점을 두는 테스트는 그 특성상 코드에 빠져있거나, 경계값을 잘못 다루는 경우, 시간 조절 문제, 하드웨어/소프트웨어 구성에 관한 호환성 문제, 와일드 포인터나 메모리 누수, 스택 오버플로우를 야기할 수 있는 스택 파괴와 같은 지연된 문제점, 그리고 고객의 요구사항을 만족하는데 실패할 수 있는 기타 오류 등과 같은 다양한 형식의 버그를 놓칠 수 있다. 이 기법은 어느 정도의 테스트가 필요한지에 대하여 최소한의 기준이라기보다는 불완전한 테스트(어떤 코드가 아직 테스트되지 않았는지)를 식별하는데 더 중요한 가치가 있다. 실제로 테스터들이 X 퍼센트만큼 범위를 다루었다고 해서 테스트를 중단하는 것은 매우 위험하다.
◎ 구성 범위
- 100개의 프린터에 대해 호환성을 테스트해야 하는데 10개만 테스트하였다면 10% 프린터 범위를 테스트한 것이다. 더욱 일반적으로 말하자면 구성 범위는 실행하려고 계획한 총 구성 테스트 개수에 대하여 실행한(그리고 프로그램이 통과한) 구성 테스트의 기준 척도이다. 왜 이를 테스트 기법이라 부를까? 대개 테스트의 특정 형식에서 얼마나 테스트를 많이 했는가에 대한 단순한 기준을 고려할 수 있다. 그러나 몇몇 테스터들은 매우 많은 양의 구성 테스트를 더욱 빠르고 용이하게 수행하는 일련의 특별한 테스트를 만들었다. 그 방식에서 많은 범위를 수행하려는 시도에 대한 최적화는 테스트 기법이 될 수 있다.
◎ 규약 기반 테스트
- 제품에 대한 명세서상의 모든 요구 조건을 검증하는데 중점을 두는 테스트이다(요구조건은 참 또는 거짓으로 보여질 수 있는 상태이다). 이는 종종 사용 설명서에 있는 요구사항, 마케팅 문서나 광고에 있는 요구사항, 고객에게 전송되는 기술 지원 문서에 있는 요구사항 등이 포함된다.
◎ 요구사항 기반 테스트
- 프로그램이 요구사항 문서의 모든 요구사항을 만족하는지 확인하는데 중점을 두는 테스트(또는 만족하지 못하는 요구사항들을 확인하는데 중점을 두는 테스트)
◎ 조합 테스트
- 두 개 이상의 변수를 다른 변수와 조합하여 테스트하는 방법. 조합 테스트는 중요하다. 그러나 많은 테스터들이 이에 대해 충분히 공부하지 않는다. 프로그램에서 제공되는 대부분의 이점은 많은 변수들의 상호동작으로 얻어진다. 테스트에서 이러한 변수들을 함께 변경시키지 않는다면 다양한 개별 값보다 다양한 조합에 의해 발생되는 오류를 놓칠 수 있다.
▶ 왜 테스트를 하는가(테스트에 대한 위험)에 중점을 둔 문제 중심 기법
위험 기반 테스트는 적어도 두 가지 큰 의미를 가지고 있다.
Amland(1999)는 위험 기반 테스트 관리를 잘 설명하고 있다. 이 관점에 따르면 위험 분석은 다음에 테스트할 것이 무엇인가를 결정하기 위하여 수행된다. 테스트는 프로그램의 어떤 기능이 제대로 동작하지 않을 것인가와 그 기능이 문제가 발생했을 경우 실패에 대한 예측 비용이 어느 정도인가라는 관점에서 우선 순위를 매기게 된다. 오류 비용이 많을 가능성이 클수록 초기에 테스트해야 하며 가능한 한 주의 깊게 기능을 테스트해야 하는 중요성도 커진다.
또 다른 의미로, 우리가 더 중점을 두는 의미는 오류를 찾기 위한 목적으로 위험을 분석한다는 것이다. 제품의 기능을 살펴볼 때 우리는 어떻게 오류가 발생하는지를 물어본다. 이 질문은 다음과 같은 추가 질문을 유발한다: 오류가 어떻죠? 왜 이 기능이 잘못되었을까요? - 어떤 위험요소가 이 기능에 영향을 미쳤을까?
James Bach의 "Risk-Based Testing"에서는 위험 기반 테스트에 관한 두 가지 접근 방식을 다루고 있다.
Whittaker와 Jorgensen은 제약조건 위반에 관련된 오류에 대하여 잘 설명하고 있으며, 광의의 클래스들에 대한 예를 보여준다.
◎ 입력 제약조건
- 프로그램이 다룰 수 있는 제약조건. 예컨대 프로그램이 32자리 이하의 수치만 다룰 수 있다고 하면 프로그래머는 32자리 제약조건을 넘는 입력을 감지하여 이를 거부하는 보호 루틴을 작성해야 한다. 이러한 보호 루틴이 없으면 처리할 수 없는 입력 데이터를 처리하라고 할 경우 프로그램에서 오류가 발생한다.
◎ 출력 제약조건
- 입력은 정상적이라도 프로그램이 처리할 수 없는 출력값이 발생할 수도 있다. 이 값을 화면에 표시하거나, 출력하거나, 저장하려고 하면 프로그램에서 오류가 발생한다.
◎ 연산 제약조건
- 입력과 출력은 괜찮더라도 값을 연산하는 과정(이 과정에서 출력값이 만들어질 수 있다)에서 프로그램이 잘못될 수 있다. 예를 들어 큰 값을 곱하는 과정에서 프로그램이 처리할 수 없을 정도로 큰 값이 발생할 수도 있다.
◎ 저장(데이터) 제약조건
- 입력, 출력, 연산은 정상적이더라도 조작이 잘못되어 메모리가 부족하거나, 처리할 수 없는 매우 큰 데이터 파일이 발생할 수 있다.
다음은 위험 기반 테스트에 대한 몇 가지 추가적인 팁이다.
★ 위험 기반 테스트를 수행하고 있다면 올바른 판단을 위하여 위험을 충분히 잘 알지 못하는 위험을 테스트하여, 비교할 수 있는 비 위험-기반 테스트도 수행해야 한다.
★ 타이밍 문제에 대하여 테스트하라. 몇몇 고전적인 타이밍 문제로는 경쟁조건과 시간상 발생하는 이벤트가 기대하지 않았던 순서로 발생하는 경우 등이 포함되어 있다.
★ 테스트를 작성할 때 데이터를 부적절하게 사용하였는지를 판단할 수 있도록 반드시 프로그램에서 입력한 테스트 데이터를 사용하도록 테스트 절차를 작성하라.
▶ 어떻게 테스트를 수행하는가에 중점을 둔 행위 기반 기법
◎ 회귀 테스트
- 회귀 테스트는 동일한 테스트를 재사용함으로써 변경사항이 발생한 이후에도 이 테스트를 통해 다시 테스트해 볼 수 있다. 크게 3가지 종류의 회귀 테스트가 있다. 버그 수정 회귀 테스트는 버그를 보고한 다음, 이를 수정하였는지를 확인한다. 이 테스트의 목적은 버그가 제대로 수정되었는지를 확인하는 것이다. 예전에 고쳐졌던 버그가 다시 고쳐지지 않은 상태로 되돌아가지 않도록 점검하는 것이 이전 버그 회귀 테스트이다. 안정성 회귀 테스트라고도 하는 부작용 회귀 테스트는 제품의 기초적인 부분을 다시 테스트하는 것이다. 이 테스트의 목적은 변경사항에 의해 그동안 동작하던 부분이 지금 잘못되지 않았는지 확인하는 것이다.
◎ 스크립트 기반 테스트
- 사용 설명서 테스트. 일반적으로 선임 테스터들이 작성한 단계별 절차에 후임 테스터들이 테스트를 수행한다.
◎ 스모크 테스트
- 일종의 부작용 회귀 테스트로써, 새로운 빌드가 테스트할 가치가 없음을 확인한다. 스모크 테스트는 어떤 빌드에서 다음 빌드로 넘어가는 과정을 자동화하고 표준화한다. 이 테스트에서는 동작할 것이라고 생각되는 기능을 테스트하며, 만약 제대로 동작하지 않는다면 프로그램이 잘못된 파일로 빌드되었는지, 혹은 어떤 기본 요소가 잘못되지는 않았는지를 의심해볼 수 있다.
◎ 답사 방식 테스트
- 테스터들은 프로젝트를 통해 제품, 제품의 시장, 위험요소, 이전 테스트에서 실패한 방식 등을 학습해 나간다. 그 과정에서 계속 새로운 테스트가 작성되어 사용된다. 새로운 테스트는 지속적으로 높아져 가는 테스터들의 지식을 기반으로 작성되기 때문에 이전 테스트보다 더 강력한 힘을 발휘할 것이다.
◎ 게릴라 테스트
- 프로그램에 대하여 신속하게 결함이 있는 부분을 공격한다. 일반적으로 경험이 풍부한 답사 방식 테스터들에 의해 미리 정해진 시간 동안 테스트를 수행하는 형식이다. 예를 들어 선임 테스터들은 하루동안 다른 사람이 무시하는 영역을 테스트한다. 그는 자신이 할 수 있는 가장 강력한 공격을 시도할 것이다. 그가 중요한 문제를 발견한다면 그 영역에 대한 예산을 다시 책정하고, 전체적인 테스트 계획을 변경한다. 중요한 문제를 발견하지 못한다면 그 아래에 해당 영역은 무시할만하다거나 가볍게 테스트되었다고 적어둔다.
◎ 시나리오 테스트
- 시나리오 테스트는 일반적으로 4가지 속성과 관련이 있다. (1) 테스트는 현실적이어야 한다. 고객이 실제로 수행하는 행위를 반복해야 한다. (2) 테스트는 프로그램이 수행해야 하는 방식처럼 여러 가지 기능과 복합적으로 관련이 있어야 한다. (3) 프로그램이 테스트를 통과하였는지 실패하였는지를 쉽고 빠르게 알 수 있어야 한다. (4) 이해 당사자들은 프로그램이 이 테스트를 통과하지 못했을 경우 프로그램을 수정해야 한다고 적극적으로 주장할 것이다. 이러한 네 가지 특성을 가진 테스트가 설득력을 가지게 되며, 프로그램이 실패했을 경우 버그가 수정될 것이다. 그러나 뛰어난 시나리오 테스트를 개발하기 위해서는 며칠 정도의 시간이 소요된다.
◎ 설치 테스트
- 소프트웨어가 설치될 수 있는 다양한 시스템에 다양한 방식으로 설치한다. 어떤 파일이 디스크에 추가되었는지, 변경되었는지를 확인한다. 설치된 소프트웨어가 동작하는가? 설치된 소프트웨어를 제거하면 어떻게 되는가?
◎ 부하 테스트
- 테스트중인 프로그램이나 시스템은 자원을 매우 많이 요청하는 공격을 받는다. 너무 많은 부하를 받게 되면 아마도 시스템에서 오류가 발생할 것이며, 오류가 발생하는 이벤트 패턴에서 테스트중인 소프트웨어나 시스템이 더욱 일반적인 상황에서 발생할 수 있는 취약점을 지적해줄 수 있을 것이다.
◎ 장시간 순차 테스트
- 이 테스트는 밤새도록 또는 며칠 간 내지 몇 주 동안 수행된다. 이 테스트의 목적은 단기간 순차 테스트에서 빠뜨릴 수 있는 오류를 발견하는 것이다. 이러한 테스트를 통해 자주 발견되는 오류로는 와일드 포인터, 메모리 누수, 스택 오버플로우, 두 개 이상의 기능간의 잘못된 상호 동작 등이 있다(이는 종종 내성 테스트, 신뢰성 테스트 또는 내구성 테스트라고 불리기도 한다).
◎ 성능 테스트
- 이 테스트는 보통 프로그램이 최적화가 필요한지 여부를 판단하기 위하여 프로그램이 얼마나 빨리 해당 작업을 수행하는가를 판단한다. 그러나 다른 버그들도 많이 찾아낼 수 있다. 이전 패포판과 비교할 때 중요한 성능상의 변화가 있다면 코드 오류의 영향을받고 있음을 의미한다. 예를 들어 오늘 실행한 간단한 함수 테스트에 걸린시간과 내일 동일한 컴퓨터에서 테스트를 실행하는 데 걸린 시간을 비교함으로써 테스트가 3개 이상 빨라졌는지 혹은 느려졌는지를 프로그래머와 함께 확인하거나, 버그 보고서에 작성할 수 있다. 어떤 경우이든 간에 프로그램의 근본적인 부분인 변경되었으므로 의심의 여지가 있는 것이다.
▶ 테스트를 통과했는지의 여부를 어떻게 알 것인가에 중점을 두는 평가 기반 기법
평가 기반 기법은 프로그램이 테스트를 통과하였는지, 실패하였는지 여부를 판단하는 방법을 기술한다. 이 테스트에서는 테스트가 어떻게 수행되어야 한다든가, 데이터가 어떻게 수집될 것인가를 지정하지는 않는다. 다만 어떤 데이터를 수집하였을 때 이를 평가할 수 있는 방법을 알려준다.
◎ 자기-검증 데이터
- 테스트에서 사용하는 데이터 파일들과 함께 출력 데이터가 잘못되었는지를 판단할 수 있는 정보도 전달한다.
◎ 저장된 결과와의 비교
- 회귀 테스트(일반적으로 자동화되지만 항상 그런 것은 아니다)는 지난주 결과와 오늘 결과를 비교함으로써 테스트를 통과하였는지 실패하였는지를 판단한다. 지난주 결과가 옳았는데, 오늘 획득한 결과와 다르다고 한다면 이러한 차이점은 새로운 결함을 의미한다.
◎ 명세서 또는 다른 공인 문서와의 비교
- 명세서와의 불일치는 (아마도) 오류이다.
◎ 발견적 일관성
- 일관성은 프로그램을 평가하는 중요한 기준이다. 불일치성은 버그를 보고하는 원인이 되거나, 의도적인 설계상의 변경사항을 반영한다. 우리는 7가지 주요 일관성을 다룬다.
1) 역사적 일관성. 현재 함수의 동작은 이전 동작과 일관되게 동작해야 한다.
2) 관념에 의한 일관성. 조직이 프로젝트에 대해 원하는 관념에 일치하도록 동작해야 한다.
3) 비교 제품들에 대한 일관성. 비교 제품의 유사 기능의 동작과 일치하게 동작해야 한다.
4) 주장에 대한 일관성. 사람들이 그렇게 될 것이라고 추측하는 대로 동작해야 한다.
5) 사용자의 기대에 대한 일관성. 사용자가 이러한 기능을 원할 것이라고 생각하는 기대에 부응해야 한다.
6) 제품간 일관성. 제품에서 비교할 수 있는 함수의 동작이나 기능적 패턴과 일치해야 한다.
7) 목적에 의한 일관성. 함수의 동작은 분명한 목적에 일치되어야 한다.
◎ 오라클 기반 테스트
- 오라클은 프로그램이 테스트를 통과했는지의 여부를 알려주는 평가 도구이다. 대용량 자동화 테스트에서 오라클은 테스트의 결과에서 소프트웨어를 확인하거나 결과를 생성하는 또 다른 프로그램이다. 오라클은 일반적으로 테스트하는 소프트웨어보다 더 높은 신뢰도를 가지기 때문에 오라클에 의해 표시된 관심 항목은 시간을 가지고 확인해 볼만한 가치가 있다.
● 테스트 : 테스트를 수행하는 사람. 예를 들어 사용자 테스트는 판매 대상으로 삼고 있는 사람들과 일반적으로 제품을
사용할 사람들에 의해 수행되는 테스트를 의미한다.
● 범위 : 무엇을 테스트하는가? 예를 들어 함수 테스트에서는 모든 함수를 테스트한다.
● 잠재적 문제 : 왜 테스트를 수행하는가? (어떤 위험요소를 테스트하는가?) 예를 들어 극한값 오류 테스트 등이 있다.
● 행위 : 어떻게 테스트하는가? 예를 들어 탐색적 테스트가 있다.
● 평가 : 테스트를 통과했는지, 실패했는지를 어떻게 이야기할 수 있는가? 예를 들어 이미 알고 있는 좋은 결과와
비교하는 방식이 있다.
▶ 누가 테스트를 수행하는가에 중점을 둔 사람 중심 기법
◎ 사용자 테스트
- 제품을 일반적으로 사용하게 될 사람들에 의한 테스트. 사용자 테스트는 개발 과정동안 당신이나 사용자가 언제든지 지시된 연습 과정에 따라 주의 깊게 수행되거나, 사용자가 임의로 수행하는 방식으로 테스트가 이루어질 수 있다.
◎ 알파 테스트
- 테스트 팀원에 의해 수행되는 내부 테스트(다양한 관심을 가진, 친한 내부 인사에 의해 수행될 수도 있다.)
◎ 베타 테스트
- 당신이 속한 조직의 일부가 아닌, 테스트와 제품의 대상 시장에 속한 사람들에 의해 수행되는 사용자 테스트의 한 형식. 테스트되는 제품은 일반적으로 완성 단계에 거의 근접해 있다. 많은 기업들이 선행 배포 코드를 고객에게 출시하는 것을 베타 테스트로 생각한다. 하지만 실제로 베타 테스트에는 매우 다양한 형식이 존재한다. 사용자(특히 특정 분야 전문가)에게 디자인이 적절한지를 물어보는 디자인 베타 테스트는 결과를 적용할 시간적 여유을 얻기 위하여 가능한 한 빨리 수행되어야 한다. 이 제품을 구입한 대규모 고객들을 설득시키기 위한 마케팅 베타 테스트는 제품이 매우 안정적으로 동작할 수 있도록 매우 늦게 진행되어야 한다. 호환성 베타 테스트는 쉽게 테스트할 수 없는 하드웨어와 소프트웨어의 플랫폼에서 제품을 실행해본다. 이 테스트 역시 호환성 문제를 해결하는데 너무 늦지 않도록 진행되어야 한다. 모든 베타 테스트는 목표를 결정한 다음, 그에 대한 일정과 실행 방법을 결정해야 한다.
◎ 버그 파티
- 간사, 프로그래머, 마케팅 담당자, 그리고 가능한 모든 사람이 동원되는 내부 테스트. 일반적으로 버그 파티는 반나절 정도 진행되며, 제품 출시 준비가 거의 완료되었을 때 수행된다.
◎ 특정 분야-중요도 전문가 테스트
- 소프트웨어가 처리하는 문제 영역에 해당하는 전문가에게 제품을 제공하고, 피드백(버그, 비평, 찬사)을 요청한다. 이때 전문가는 제품을 사용할 것으로 예상되는 사람일 수도 있고, 아닐 수도 있다. 전문가의 가치는 시장성이 아니라 그가 가진 지식으로부터 나오는 것이다.
◎ 짝 테스트
- 두 명의 테스터가 함께 버그를 발견한다. 일반적으로 컴퓨터 한 대를 같이 사용하며, 컴퓨터에 대한 제어권을 주고 받으면서 테스트를 진행한다.
◎ 스스로 사용해보라
- 소프트웨어가 판매되기 전, 실제로 사용자에게 충분한 신뢰성을 갖출 때까지 자사 소프트웨어의 선행 배포 버전을 직접 사용해보라.
▶ 무엇을 테스트하는가에 중점을 두는 범위 기반 기법
무엇을 염두에 두고 테스트를 하는가에 따라 다양한 기법을 구분할 수 있다. 예를 들어 어떤 함수를 다른 함수들과 조합하여 사용할 때 모든 함수가 제대로 동작하는지를 확인한다면 기능 통합 테스트는 범위 기반 테스트이다. 함수들이 상호 동작하는 과정에서의 오류에 대한 논리를 가지고 있고, 그것을 추적하고 싶다면 이는 문제 기반 테스트이다(예를 들어, 각 함수가 다른 함수로 데이터를 전달하는 방식에서 오류가 있는지를 살펴보고 싶다면 이는 문제 기반 테스트이다).
◎ 함수 테스트
- 모든 함수를 하나씩 테스트한다. 함수가 제대로 동작하고 있다고 확신할 수 있을 때까지 철저히 테스트한다. 화이트박스 함수 테스트는 일반적으로 유닛 테스트라고도 하며, 코드상의 함수에 중점을 둔다. 블랙박스 테스트는 명령어와 기능, 사용자가 실행 또는 선택할 수 있는 항목에 중점을 둔다. 함수 테스트를 수행한 다음 여러 함수와 관련이 있는 복합 테스트를 수행하는 것이 현명하다. 함수를 개별적으로 테스트하지 않고 복합 테스트에 의존하고 있다면 매우 늦은 시점에서 함 함수가 잘못되었다는 것을 알게 되고, 복합 테스트의 문제 해결에 많은 시간과 노력을 들인 뒤에서야 문제의 원인이 간단히 하나의 함수에 있었다는 사실을 알게 된다.
◎ 기능 또는 함수 통합 테스트
- 몇 가지 함수를 사용하면서 제대로 동작하는지를 살펴본다.
◎ 메뉴 살펴보기
- GUI 제품의 모든 메뉴와 대화상자를 따라가면서 가능한 모든 선택을 수행한다.
◎ 도메인 테스트
- 도메인이란 함수에 사용된 변수에서 사용할 수 있는 모든 값을 포함하는 (수학적) 집합이다. 도메인 테스트에서는 함수와 변수를 구분한다. 변수에는 입력 변수와 출력 변수가 있다(테스트 분석에는 입력 도메인과 출력 범위가 동일하기 때문에 입력 도메인과 출력 범위를 수학적으로 구분하는 것은 적절하지 않다). 각 변수에서 취할 수 있는 값의 집합을 구분하여 등가 클래스로 나눈 다음, 각 클래스의 대표 값 중 작은 값(일반적으로 경계 사례)을 선택한다. 이 방법에는 각 클래스에서 몇 안 되는 훌륭한 대표 값으로도 클래스의 모든 구성요소들에 대한 모든 혹은 거의 대부분의 버그를 발견할 수 있다는 가정이 숨어있다. 함수 테스트와 달리 함수가 아니라 변수에 관심을 두고 있음을 알아두자. 많은 변수들이 하나 이상의 함수에서 사용된다. 도메인 테스트는 변수를 분석한 다음, 그 분석 결과에 따라 이 변수를 사용하는 각 함수에 대해 입력과 출력으로 테스트를 실행한다.
◎ 등가 클래스 분석
- 등가 클래스는 변수에서 등가라고 생각되는 값들의 집합이다. 클래스에 속한 값들에 대해 (a) 모든 동일한 테스트를 수행하고 (b) 이 중 하나라도 버그가 발견되면 다른 값들에서도 버그가 발견될 것이며, (c) 이 값 중에서 버그를 찾아내지 못한다면 다른 값에서도 마찬가지로 버그를 찾이 못할 것이라고 확신할 수 있을때 이 테스트 클래스는 등가이다. 일단 등가 클래스를 구하고 나면, 각 클래스 구성요소 중 한두 개만 테스트 해본다.
◎ 경계 테스트
- 등가 클래스는 값들의 집합이다. 이를 하나의 수평선으로 옮길 때 클래스의 최소값과 최대값이 경계값이다. 경계 테스트에서는 이 값을 테스트한다. 그리고 테스트하고 있는 클래스의 최대값보다 큰 값이나, 클래스의 최소값보다 작은 값을 사용하여 클래스의 경계 인접값도 테스트해 볼 수 있다.
◎ 최상의 대표 테스트
- 등가 클래스에서 최상의 대표값은 소프트웨어 오류를 노출시키는 클래스 내의 임의의 값이다. 경계 테스트에서는 경계 사례가 거의 대부분 최상의 대표값이다. 그러나 등가 클래스를 수평선으로 옮길 수 없는 경우도 있다. 예를 들어 휴렛팩커드 PCL-5 호환인 프린터는 모두 동일한 방식으로 동작해야 하므로, 이를 등가 클래스라고 해보자. 이제 특정 작업에 대하여 프린터 중 하나가 다른 것보다 문제가 있는 경우를 생각해보자. 이 프린터가 그 클래스에 대한 최상의 대표값이 될 수 있다. 이 프린터가 오동작하지 않는다면 다른 프린터 역시 오동작하지 않을 것이라고 확신할 수 있다.
◎ 입력 필드 테스트 카달로그 또는 매트릭스
- 입력 필드의 각 형식에 대하여 테스트 사례에 대한 명료한 표준 집합을 만든 다음, 이를 해당 제품이나 향후 제품들의 유사 필드에서 사용할 수 있다.
◎ 필드를 수정하는 모든 방식을 테스트하기
- 종종 몇 가지 방식으로 필드의 값을 변경할 수 있다. 예를 들어 불러오기를 한 데이터를 계산한 다음 결과 값을 필드에 넣을 수도 있고, 계산 결과를 이 필드에 복사할 수도 있다. 이 필드에는 제약조건이 있다(취할 수 있는 값의 범위가 정해져 있다). 일부 제약조건은 항상 일정한 반면 어떤 제약조건은 다른 항목들의 값에 따라 달라질 수 있다. 예를 들어 J와 K는 부호가 없는 정수 값인데, 이 값은 0부터 MaxInt 사이의 값을 가져야 한다. 이것은 상수 제약조건이다. 그러나 N이 부호가 없는 정수형인데 N = J + K 이고, N = 5라고 생각해 보자. 이 경우 J = 5- K이므로 J는 5(N값)보다 큰 수가 될 수 없다. 이는 변수 제약조건으로, 가능한 값의 범위가 N 값에 의존한다. J가 허용 가능한 범위(5 - K) 내에 있는지 확인하기 위하여 J에 데이터를 입력하는 여러 방식을 통해 값을 변경시켜 보아야 한다.
◎ 논리 테스트
- 변수는 프로그램에서 연관선을 가진다. 예를 들어 나이가 50보다 많고, 흡연을 하면 보험 가입이 안 된다고 판단하는 결정 규칙을 가진 프로그램을 생각해 보자. 이때 결정 규칙은 논리적 관계로 표현된다. 논리적 테스트는 프로그램에서 모든 논리적 연관성을 확인한다. 원인-결과 그래프는 논리 기반 테스트의 확장된 집합을 설계하기 위한 한 가지 방법이다.
◎ 상태 기반 테스트
- 프로그램은 상태들을 변경한다. 주어진 상태에서 어떤 입력값은 유효하지만, 다른 값은 무시되거나 거부된다. 테스트되는 프로그램은 유효한 입력값이 주어질 때 프로그램이 그 작업을 수행하며, 유효하지 않다면 작업을 수행하지 않는다. 상태 기반 테스트에서는 상태 전이(상태 변화)에 대한 대형 집합을 훑어가면서 프로그램을 실행하여 결과를 매번 신중하게 확인한다.
◎ 경로 테스트
- 경로에는 현재 상태를 얻기 위하여 여러분이 취한 모든 단계나 프로그램이 거친 모든 구문들이 포함된다. 경로 테스트에서는 프로그램의 많은 경로들을 테스트한다. 그러나 프로그램의 사소한 경로를 모두 테스트할 수는 없다. 그러므로 몇몇 테스트들은 많은 부분 경로를 테스트하는 하위 경로 테스트를 수행한다. 또한 편향 경로 테스트에서는 이러한 하위 경로들을 모두 통과하면, 더 긴 경로에 대한 테스트에서는 하위 경로를 테스트할 때 놓친 버그를 발견하기가 어렵다는 가정 하에서, 특정 형식(기초 경로)에 대한 거의 모든 하위 경로를 테스트한다.
◎ 상태 및 분기 범위
- 프로그램에서 모든 구문(또는 코드 행)을 테스트한다면 100% 구문을 다루게 된다. 만약 한 구문에서 다른 구문으로의 모든 분기와 구문을 테스트해 보았다면 100% 구문 및 분기 범위를 다룬 것이다. 행 및 분기를 매우 많이 다루는 테스트 설계법을 종종 "범위 기반 테스트"라고 부른다(이 모든 것을 테스트한 다음 테스트를 중단하거나 별도 테스트를 설계하지 않는다). 우리는 이를 '상태 및 분기 범위'라고 부르며, 범위의 일부 다른 형식에 중점을 두는 테스트 형식과 다르게 구분한다. 구성 범위는 매우 많은 횟수 동안 동일한 구문을 수행하지만 잠재적으로 매우 다른 결과를 가질 수 있는 좋은 예이다. 구문 및 분기 범위 값을 수행하는데 중점을 두는 테스트는 그 특성상 코드에 빠져있거나, 경계값을 잘못 다루는 경우, 시간 조절 문제, 하드웨어/소프트웨어 구성에 관한 호환성 문제, 와일드 포인터나 메모리 누수, 스택 오버플로우를 야기할 수 있는 스택 파괴와 같은 지연된 문제점, 그리고 고객의 요구사항을 만족하는데 실패할 수 있는 기타 오류 등과 같은 다양한 형식의 버그를 놓칠 수 있다. 이 기법은 어느 정도의 테스트가 필요한지에 대하여 최소한의 기준이라기보다는 불완전한 테스트(어떤 코드가 아직 테스트되지 않았는지)를 식별하는데 더 중요한 가치가 있다. 실제로 테스터들이 X 퍼센트만큼 범위를 다루었다고 해서 테스트를 중단하는 것은 매우 위험하다.
◎ 구성 범위
- 100개의 프린터에 대해 호환성을 테스트해야 하는데 10개만 테스트하였다면 10% 프린터 범위를 테스트한 것이다. 더욱 일반적으로 말하자면 구성 범위는 실행하려고 계획한 총 구성 테스트 개수에 대하여 실행한(그리고 프로그램이 통과한) 구성 테스트의 기준 척도이다. 왜 이를 테스트 기법이라 부를까? 대개 테스트의 특정 형식에서 얼마나 테스트를 많이 했는가에 대한 단순한 기준을 고려할 수 있다. 그러나 몇몇 테스터들은 매우 많은 양의 구성 테스트를 더욱 빠르고 용이하게 수행하는 일련의 특별한 테스트를 만들었다. 그 방식에서 많은 범위를 수행하려는 시도에 대한 최적화는 테스트 기법이 될 수 있다.
◎ 규약 기반 테스트
- 제품에 대한 명세서상의 모든 요구 조건을 검증하는데 중점을 두는 테스트이다(요구조건은 참 또는 거짓으로 보여질 수 있는 상태이다). 이는 종종 사용 설명서에 있는 요구사항, 마케팅 문서나 광고에 있는 요구사항, 고객에게 전송되는 기술 지원 문서에 있는 요구사항 등이 포함된다.
◎ 요구사항 기반 테스트
- 프로그램이 요구사항 문서의 모든 요구사항을 만족하는지 확인하는데 중점을 두는 테스트(또는 만족하지 못하는 요구사항들을 확인하는데 중점을 두는 테스트)
◎ 조합 테스트
- 두 개 이상의 변수를 다른 변수와 조합하여 테스트하는 방법. 조합 테스트는 중요하다. 그러나 많은 테스터들이 이에 대해 충분히 공부하지 않는다. 프로그램에서 제공되는 대부분의 이점은 많은 변수들의 상호동작으로 얻어진다. 테스트에서 이러한 변수들을 함께 변경시키지 않는다면 다양한 개별 값보다 다양한 조합에 의해 발생되는 오류를 놓칠 수 있다.
▶ 왜 테스트를 하는가(테스트에 대한 위험)에 중점을 둔 문제 중심 기법
위험 기반 테스트는 적어도 두 가지 큰 의미를 가지고 있다.
Amland(1999)는 위험 기반 테스트 관리를 잘 설명하고 있다. 이 관점에 따르면 위험 분석은 다음에 테스트할 것이 무엇인가를 결정하기 위하여 수행된다. 테스트는 프로그램의 어떤 기능이 제대로 동작하지 않을 것인가와 그 기능이 문제가 발생했을 경우 실패에 대한 예측 비용이 어느 정도인가라는 관점에서 우선 순위를 매기게 된다. 오류 비용이 많을 가능성이 클수록 초기에 테스트해야 하며 가능한 한 주의 깊게 기능을 테스트해야 하는 중요성도 커진다.
또 다른 의미로, 우리가 더 중점을 두는 의미는 오류를 찾기 위한 목적으로 위험을 분석한다는 것이다. 제품의 기능을 살펴볼 때 우리는 어떻게 오류가 발생하는지를 물어본다. 이 질문은 다음과 같은 추가 질문을 유발한다: 오류가 어떻죠? 왜 이 기능이 잘못되었을까요? - 어떤 위험요소가 이 기능에 영향을 미쳤을까?
James Bach의 "Risk-Based Testing"에서는 위험 기반 테스트에 관한 두 가지 접근 방식을 다루고 있다.
Whittaker와 Jorgensen은 제약조건 위반에 관련된 오류에 대하여 잘 설명하고 있으며, 광의의 클래스들에 대한 예를 보여준다.
◎ 입력 제약조건
- 프로그램이 다룰 수 있는 제약조건. 예컨대 프로그램이 32자리 이하의 수치만 다룰 수 있다고 하면 프로그래머는 32자리 제약조건을 넘는 입력을 감지하여 이를 거부하는 보호 루틴을 작성해야 한다. 이러한 보호 루틴이 없으면 처리할 수 없는 입력 데이터를 처리하라고 할 경우 프로그램에서 오류가 발생한다.
◎ 출력 제약조건
- 입력은 정상적이라도 프로그램이 처리할 수 없는 출력값이 발생할 수도 있다. 이 값을 화면에 표시하거나, 출력하거나, 저장하려고 하면 프로그램에서 오류가 발생한다.
◎ 연산 제약조건
- 입력과 출력은 괜찮더라도 값을 연산하는 과정(이 과정에서 출력값이 만들어질 수 있다)에서 프로그램이 잘못될 수 있다. 예를 들어 큰 값을 곱하는 과정에서 프로그램이 처리할 수 없을 정도로 큰 값이 발생할 수도 있다.
◎ 저장(데이터) 제약조건
- 입력, 출력, 연산은 정상적이더라도 조작이 잘못되어 메모리가 부족하거나, 처리할 수 없는 매우 큰 데이터 파일이 발생할 수 있다.
다음은 위험 기반 테스트에 대한 몇 가지 추가적인 팁이다.
★ 위험 기반 테스트를 수행하고 있다면 올바른 판단을 위하여 위험을 충분히 잘 알지 못하는 위험을 테스트하여, 비교할 수 있는 비 위험-기반 테스트도 수행해야 한다.
★ 타이밍 문제에 대하여 테스트하라. 몇몇 고전적인 타이밍 문제로는 경쟁조건과 시간상 발생하는 이벤트가 기대하지 않았던 순서로 발생하는 경우 등이 포함되어 있다.
★ 테스트를 작성할 때 데이터를 부적절하게 사용하였는지를 판단할 수 있도록 반드시 프로그램에서 입력한 테스트 데이터를 사용하도록 테스트 절차를 작성하라.
▶ 어떻게 테스트를 수행하는가에 중점을 둔 행위 기반 기법
◎ 회귀 테스트
- 회귀 테스트는 동일한 테스트를 재사용함으로써 변경사항이 발생한 이후에도 이 테스트를 통해 다시 테스트해 볼 수 있다. 크게 3가지 종류의 회귀 테스트가 있다. 버그 수정 회귀 테스트는 버그를 보고한 다음, 이를 수정하였는지를 확인한다. 이 테스트의 목적은 버그가 제대로 수정되었는지를 확인하는 것이다. 예전에 고쳐졌던 버그가 다시 고쳐지지 않은 상태로 되돌아가지 않도록 점검하는 것이 이전 버그 회귀 테스트이다. 안정성 회귀 테스트라고도 하는 부작용 회귀 테스트는 제품의 기초적인 부분을 다시 테스트하는 것이다. 이 테스트의 목적은 변경사항에 의해 그동안 동작하던 부분이 지금 잘못되지 않았는지 확인하는 것이다.
◎ 스크립트 기반 테스트
- 사용 설명서 테스트. 일반적으로 선임 테스터들이 작성한 단계별 절차에 후임 테스터들이 테스트를 수행한다.
◎ 스모크 테스트
- 일종의 부작용 회귀 테스트로써, 새로운 빌드가 테스트할 가치가 없음을 확인한다. 스모크 테스트는 어떤 빌드에서 다음 빌드로 넘어가는 과정을 자동화하고 표준화한다. 이 테스트에서는 동작할 것이라고 생각되는 기능을 테스트하며, 만약 제대로 동작하지 않는다면 프로그램이 잘못된 파일로 빌드되었는지, 혹은 어떤 기본 요소가 잘못되지는 않았는지를 의심해볼 수 있다.
◎ 답사 방식 테스트
- 테스터들은 프로젝트를 통해 제품, 제품의 시장, 위험요소, 이전 테스트에서 실패한 방식 등을 학습해 나간다. 그 과정에서 계속 새로운 테스트가 작성되어 사용된다. 새로운 테스트는 지속적으로 높아져 가는 테스터들의 지식을 기반으로 작성되기 때문에 이전 테스트보다 더 강력한 힘을 발휘할 것이다.
◎ 게릴라 테스트
- 프로그램에 대하여 신속하게 결함이 있는 부분을 공격한다. 일반적으로 경험이 풍부한 답사 방식 테스터들에 의해 미리 정해진 시간 동안 테스트를 수행하는 형식이다. 예를 들어 선임 테스터들은 하루동안 다른 사람이 무시하는 영역을 테스트한다. 그는 자신이 할 수 있는 가장 강력한 공격을 시도할 것이다. 그가 중요한 문제를 발견한다면 그 영역에 대한 예산을 다시 책정하고, 전체적인 테스트 계획을 변경한다. 중요한 문제를 발견하지 못한다면 그 아래에 해당 영역은 무시할만하다거나 가볍게 테스트되었다고 적어둔다.
◎ 시나리오 테스트
- 시나리오 테스트는 일반적으로 4가지 속성과 관련이 있다. (1) 테스트는 현실적이어야 한다. 고객이 실제로 수행하는 행위를 반복해야 한다. (2) 테스트는 프로그램이 수행해야 하는 방식처럼 여러 가지 기능과 복합적으로 관련이 있어야 한다. (3) 프로그램이 테스트를 통과하였는지 실패하였는지를 쉽고 빠르게 알 수 있어야 한다. (4) 이해 당사자들은 프로그램이 이 테스트를 통과하지 못했을 경우 프로그램을 수정해야 한다고 적극적으로 주장할 것이다. 이러한 네 가지 특성을 가진 테스트가 설득력을 가지게 되며, 프로그램이 실패했을 경우 버그가 수정될 것이다. 그러나 뛰어난 시나리오 테스트를 개발하기 위해서는 며칠 정도의 시간이 소요된다.
◎ 설치 테스트
- 소프트웨어가 설치될 수 있는 다양한 시스템에 다양한 방식으로 설치한다. 어떤 파일이 디스크에 추가되었는지, 변경되었는지를 확인한다. 설치된 소프트웨어가 동작하는가? 설치된 소프트웨어를 제거하면 어떻게 되는가?
◎ 부하 테스트
- 테스트중인 프로그램이나 시스템은 자원을 매우 많이 요청하는 공격을 받는다. 너무 많은 부하를 받게 되면 아마도 시스템에서 오류가 발생할 것이며, 오류가 발생하는 이벤트 패턴에서 테스트중인 소프트웨어나 시스템이 더욱 일반적인 상황에서 발생할 수 있는 취약점을 지적해줄 수 있을 것이다.
◎ 장시간 순차 테스트
- 이 테스트는 밤새도록 또는 며칠 간 내지 몇 주 동안 수행된다. 이 테스트의 목적은 단기간 순차 테스트에서 빠뜨릴 수 있는 오류를 발견하는 것이다. 이러한 테스트를 통해 자주 발견되는 오류로는 와일드 포인터, 메모리 누수, 스택 오버플로우, 두 개 이상의 기능간의 잘못된 상호 동작 등이 있다(이는 종종 내성 테스트, 신뢰성 테스트 또는 내구성 테스트라고 불리기도 한다).
◎ 성능 테스트
- 이 테스트는 보통 프로그램이 최적화가 필요한지 여부를 판단하기 위하여 프로그램이 얼마나 빨리 해당 작업을 수행하는가를 판단한다. 그러나 다른 버그들도 많이 찾아낼 수 있다. 이전 패포판과 비교할 때 중요한 성능상의 변화가 있다면 코드 오류의 영향을받고 있음을 의미한다. 예를 들어 오늘 실행한 간단한 함수 테스트에 걸린시간과 내일 동일한 컴퓨터에서 테스트를 실행하는 데 걸린 시간을 비교함으로써 테스트가 3개 이상 빨라졌는지 혹은 느려졌는지를 프로그래머와 함께 확인하거나, 버그 보고서에 작성할 수 있다. 어떤 경우이든 간에 프로그램의 근본적인 부분인 변경되었으므로 의심의 여지가 있는 것이다.
▶ 테스트를 통과했는지의 여부를 어떻게 알 것인가에 중점을 두는 평가 기반 기법
평가 기반 기법은 프로그램이 테스트를 통과하였는지, 실패하였는지 여부를 판단하는 방법을 기술한다. 이 테스트에서는 테스트가 어떻게 수행되어야 한다든가, 데이터가 어떻게 수집될 것인가를 지정하지는 않는다. 다만 어떤 데이터를 수집하였을 때 이를 평가할 수 있는 방법을 알려준다.
◎ 자기-검증 데이터
- 테스트에서 사용하는 데이터 파일들과 함께 출력 데이터가 잘못되었는지를 판단할 수 있는 정보도 전달한다.
◎ 저장된 결과와의 비교
- 회귀 테스트(일반적으로 자동화되지만 항상 그런 것은 아니다)는 지난주 결과와 오늘 결과를 비교함으로써 테스트를 통과하였는지 실패하였는지를 판단한다. 지난주 결과가 옳았는데, 오늘 획득한 결과와 다르다고 한다면 이러한 차이점은 새로운 결함을 의미한다.
◎ 명세서 또는 다른 공인 문서와의 비교
- 명세서와의 불일치는 (아마도) 오류이다.
◎ 발견적 일관성
- 일관성은 프로그램을 평가하는 중요한 기준이다. 불일치성은 버그를 보고하는 원인이 되거나, 의도적인 설계상의 변경사항을 반영한다. 우리는 7가지 주요 일관성을 다룬다.
1) 역사적 일관성. 현재 함수의 동작은 이전 동작과 일관되게 동작해야 한다.
2) 관념에 의한 일관성. 조직이 프로젝트에 대해 원하는 관념에 일치하도록 동작해야 한다.
3) 비교 제품들에 대한 일관성. 비교 제품의 유사 기능의 동작과 일치하게 동작해야 한다.
4) 주장에 대한 일관성. 사람들이 그렇게 될 것이라고 추측하는 대로 동작해야 한다.
5) 사용자의 기대에 대한 일관성. 사용자가 이러한 기능을 원할 것이라고 생각하는 기대에 부응해야 한다.
6) 제품간 일관성. 제품에서 비교할 수 있는 함수의 동작이나 기능적 패턴과 일치해야 한다.
7) 목적에 의한 일관성. 함수의 동작은 분명한 목적에 일치되어야 한다.
◎ 오라클 기반 테스트
- 오라클은 프로그램이 테스트를 통과했는지의 여부를 알려주는 평가 도구이다. 대용량 자동화 테스트에서 오라클은 테스트의 결과에서 소프트웨어를 확인하거나 결과를 생성하는 또 다른 프로그램이다. 오라클은 일반적으로 테스트하는 소프트웨어보다 더 높은 신뢰도를 가지기 때문에 오라클에 의해 표시된 관심 항목은 시간을 가지고 확인해 볼만한 가치가 있다.
