개발자도 알아야 할 소프트웨어 테스팅 실무 요약 4-3

3) 테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교

문서화 정도와 지적 능력의 활용 정도에 따라 테스트 케이스 기반 테스팅과 탐색적 테스팅을 비교할 수 있다. 

탐색적 테스팅은 지적 능력(Intelligence) 활용도가 높고, 테스트 케이스 기반 테스팅은 문서화(documentation) 활용도가 높다. 

 

표. 테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교

테스트 케이스 기반 테스팅	탐색적 테스팅
테스트가 먼저 설계되고 기록된다. 나중에 다른 테스터가 이를 준비한다.	테스트가 설계됨과 동시에 수행된다. 테스트가 반드시 기록되는 건 아니다.
it's like 준비도니 연설을 하는 것과 같다. 테스트는 미리 착안된 생각에 따라 수행된다.	대화를 하는 것과 같다.  테스트는 아이디어를 반영하고, 생각을 시키는 방향으로 수행된다.
테스트의 실행을 관리한다.(controlling test execution)	테스트 설계를 향상 시키는 것이다.(improving test design)
테스트 실행 전에 tc를 작성한다.	프로젝트 기간 내내 테스트 계획/설계와 실행을 반복
테스트 문서 작성, 검토에 많은 에너지를 소비해 효율성이 감소	테스트 문서 작성, 검토에 대한 필요성을 최소화하여 보다 많고 복잡한 테스트에 상대적으로 많은 노력 투자가 가능
테스터 간 (특성, 능력) 차이 제거하려는 노력	테스터 간의 (특성, 능력) 차이를 십분 활용 노력
(테스터가 아닐 수 있는)테스트 설계자가 테스트 설계,	테스트 설계자일 수 있는 테스터가 테스트를 설계
완벽하게 한번에 테스팅	점진적이고 주기적으로 테스팅 수행

 

4) 리스크 기반 테스팅과 연계한 탐색적 테스팅의 활용

완벽 테스팅 불가능하므로 탐색적 테스팅을 할 때도 리스크 기반 접근(risk based approach) 전략을 사용해야 한다.

예) 테스트 분석/설계 단계에서 리스크 분석결과가 가장 리스크가 높은 곳을 강력하게 테스팅 해주고 싶을 때, 탐색적 테스팅을 추가하여 테스트의 완성도를 보완할 수 있다.

 

제품의 리스크가 가장 높을 때 탐색적 테스팅을 한다. 테스트 경험이 많고 능력 있는 테스트 엔지니어가 탐색적 테스팅을 수행해야 하고 반대로 리스크가 낮은 곳에는 경험과 능력이 상대적으로 부족한 테스트 엔지니어가 수행해야 한다.

 

탐색적 테스팅의 장점

• 경험적 테스팅을 체계화 시킬 수 있다.
• tc 작성 시간을 줄여 보다 많은 테스트 실행
• 엔지니어의 역량을 향상시킬 수 있다.
• 명세가 거의 없고 시간이 부족 경우 테스트를 효율적 효과적 수행 

 

4.4 고급 설계 기법(advanced test design techniques)

4.4.1 명세 기반 기법(specification-based technique)

4.4.1.1 분류 트리 기법(Classification Tree Method - CTM)

분류 트리 기법은 SW 일부 또는 전체를 트리구조로 분석 및 표현하고 이를 바탕으로 TC를 도출하는 기법

 

분류 트리 기법의 장점

• 테스트 아이디어를 시각화하여 TC 설계, 의도한대로 TC 도출 가능
• 시각적으로 보면서 트리 구조 끝단 조합 통해 TC 작성, 일부분만 테스트 진행/중복 테스트 피할 수 있음
• 복잡 시스템 일부/전체 테스팅 적합
• 개발 설계를 체크하는 용도로 사용 가능, 조기 테스트 설계(early test design)에 활용
• tc 개수와 트리의 복잡도 근거로 테스트 비용 추정 가능

 

분류 트리 기법을 적용할 때 트리를 그려주는 도구(classification tree editor)의 지원 받을 수 있음

이 도구 tc 자동 수행은 x, 테스트할 조합(tc) 선택을 용이 지원

 

적용 사례

• 모바일 뱅킹에서의 계좌 이체 화면을 분류 트리 기법으로 테스트를 설계하고 테스트 케이스 도출 사례

 

tc 생성 방법, 절차

1. 계좌 이체 화면을 트리 형태로 구성하기 위해 비밀 번호, 입금 계좌 번호, 입금 은행, 이체 금액, 의뢰인을 조합의 파라미터로 결정

2. 파라미터의 세부 트리를 해당 값으로 간주하고 트리를 구성한다.

3. 각 파라미터별 하나씩의 값을 선택한 후 해당 지점을 점으로 표시하고 id를 부여한다.

4. id가 부여된 트리 우측에 기대결과를 기술하여 tc를 생성한다. 

 

파라미터와 값을 알 수 있는 경우에는 페어와이즈 또는 직교 배열 조합 테스팅 기법을 적용할 수 있다. 

 

4.4.1.2 페어와이즈 조합 테스팅(pairwise testing)

페어와이즈 조합 테스팅은 커버해야 할 기능적 범위에 비해 상대적으로 적은 량의 테스트 세트를 구성하여 소프트웨어의 결함을 찾고 테스트에 대한 자신감(confidence)을 얻을 수 있는 방법 중 한가지이다. 

관찰 결과 대부분의 결함이 2개 요소의 상호작용에 기인한다는 것에 착안하여 2개 요소의 모든 조합을 다룬다. 

 

=> 테스트를 하는데 필요한 각 값들이 다른 파라미터의 값과 최소한 한번씩은 조합을 이루게 된다. 

 

조합 테스팅에서 파라미터는 조합할 값을 대표하는 요소로서 소프트웨어의 다양한 기능, 사용자 또는 하드웨어 설정, 속성, 선택옵션 등의 종류를 파악함으로써 알 수 있다.

 

페어와이즈 조합을 생성하는 자동화 도구를 사용한다.

ex. 올페어즈(Allpairs)라는 도구를 사용하여 특정 폴더에 저장하고 페어와이즈 조합을 원하는 파라미터와 값을 엑셀에서 만든 후 이를 노트패드에 붙여 놓은 후 파일명을 정한다. ~~ 과정 생략.

 

4.4.1.3 직교 배열 테스팅(orthogonal array testing)

직교 배열은 현재 6시그마를 포함하는 산업 공학 분야의 실험 계획 및 분석 도구로서 널리 사용되고 있다. 이 원리를 sw 테스트 설계에 적용하여 조합의 수를 줄임으로써 tc 수를 합리적으로 할 수 있다. 

 

페어와이즈 조합 테스팅과 유사하며, 차이점은 직교 배열의 각 행과 열이 페어와이즈 하다는 것이다.

 

각 행과 열이 페어와이즈 하다는 것은 각 행 및 열에 선택 가능한 입력값들이 반드시 한 번 이상 들어가게 되어있다.

=>어느 행의 조합도 서로 다른 행의 조합과 서로 다르고, 어느 열의 조합도 서로 다른 열의 조합과 서로 다르다는 것을 의미한다.

 

3개의 파라미터와 직교 배열 테이블이 존재하며 이를 이용하여 테스트의 조합을 생성할 수 있다.

	P1	P2	P3
L1	1	1	1
L2	1	2	2
L3	2	1	1
L4	2	2	1

이를 기호로 표기하면 L4(2)3이 되고 4는 조합수(라인수)가 4개라는 것을 의미한다. 

 

4.4.2 구조 기반 기법 (Structure-based technique)

4.4.2.1 분할(splitting) 방법으로 접근한 조건/결정 커비리지

여러 개별조건식으로 구성된 복합 결정 포인트(complex determinant)가 포함된 결정 테이블을 테스팅하고자 할 경우, 두 가지 방법으로 선택한 커버리지에 따라 작성된 논리적 테스트 컬럼을 논리적 tc로 변경할 수 있다.

 

분할(splitting) : 논리적 테스트 컬럼의 각각을 선택한 커버리지로 생성한 모든 논리적 조합으로 분할하여 tc를 작성 방식

 

포함(including) : 논리적 테스트 컬럼의 각각을 선택한 커버리지로 생성한 조합 중에서 단 하나만 선택하여 하나의 논리적 tc로 작성하는 1:1 전환 방식

 

결정 테이블이 있을 때 조건/결정 커버리지를 선택하여 논리적인 테스트 케이스로 전환하는 방법을 보자.

 

표. 결정 테이블

결정포인트	논리적 테스트 컬럼	1	2	3	4	5
	이벤트	1	1	1	1	1
1	A>0	1	0	0	0	1
2	B=6	0	1	0	0	1
3	C=2 AND D=4 AND E=5	0	0	1	0	1
4	F<0 OR G>0	0	0	0	1	1
	RESULT1	*				*
	RESULT2		*	*	*	*Q

 

번호	C=2	D=4	E=5	결과값
1(C,D,E가 결정)	1	1	1	1
2(E가 결정)	1	1	0	0
3(D가 결정)	1	0	1	0

논리적인 TC를 작성하는 경우 두 개 이상의 개별 연산자를 포함한 결정 포인트가 많은 결정 테이블에 활용하게 되면 대량 TC 생성되므로 매우 중요하거나 리스크가 높은 부분에 대해서만 활용할 것을 추천한다. 

 

4.4.3 경험 기반 기법(Experience-based technique)

4.4.3.1 오류 추정(error guessing)

대체로 테스터는 경험에 기반하여 결함을 예측한다.

테스트의 마지막 단계에서 사용하는 것이 적절하다.

테스터가 대상을 완전히 이해하고 있ㄴ다는 전제로 식별된 취약점에 기반한 테스트

 

가능한 오류를 모두 나열하고 결함 또는 오류를 공격할 수 있도록 테스트를 설계해야 한다.

체계적인 접근법을 결점 공격(fault attack)이라 한다.

 

 

오류 추정 기법의 장점

테스트에 참고할 명세가 거의 없거나 불충분한 경우 시간적인 압박이 심한 경우 유용하다.

다른 기법이나 공식적인 테스트를 보완할 때 유용하게 사용할 수 있다.

가장 심각한 결함을 찾았다는 확신이 필요한 경우 사용해 테스트 프로세스 및 완성도를 확인하는 기준을 제공할 수 있다.

 

4.4.3.2 체크리스트(checklists)

테스트하거나 평가해야 할 내용과 경험을 나열해 놓은 것을 의미

여러 형태와 종류가 있다.

 

일반 체크리스트

기능(블랙박스) 체크리스트

전체 시스템의 최상위 기능 체크

개별적이 컴포넌트(단위)기능

서로 다른 레벨(컴포넌트, 통합, 시스템 레벨) 의 기능과 그룹핑

 

시스템 요소 체크리스트

상위레벨 서브-시스템이나 모듈

개별 구문이나 데이터 아이템

서로 다른 레벨의 시스템 요소와 그룹핑

 

체크리스트와 tc 비교

체크리스트는 경험과 노하우의 반영물이므로 테스트를 효율적으로 진행할 수 있지만 효과성을 보장하지 못한다.

tc 기법을 적용하여 도출되는 경우 대부분이므로 보장 범위 내에서 효과성을 보장해 준다.

 

기대결과 항목을 추가하면 tc와 형식적 측면에서 다르지 않다. 

=> '보장성'을 기준으로 구분하는 것이 타당하다.

 

체크리스트는 테스트 베이시스(개발 산출물)의 결함을 발견하는데 주로 사용되므로 정적 테스트 기법의 주요 도구가 되는 반면 tc는 동적 테스팅의 주요 도구가 된다.(기능 체크리스트는 동적 테스팅에도 활용된다.)

 

공식적인 테스팅을 보완하는 용도로 사용하는 것이 바람직하고 체크리스트에 녹아있는 경험과 노하우를 tc에 반영하는 게 좋다.

이 때, 체크리스트를 유지하면서 공식적인 테스팅으로 이를 보완하는 것도 좋은 방법이다.

 

4.5 테스트 기법의 선택

테스트 기법을 사용할지 결정하는데 고려해야 할 사항

세스템 유형 및 특징

강제적 표준 또는 법적 기준 적용 여부

고객 또는 계약상의 요구사항

리스크 수준(level of risk)

리스크 유형(type of risk)

테스트 목표

문서(테스트 베이시스)의 존재 유무

지식 수준

시간과 예산

테스트 레벨

개발 수명 주기

유즈케이스, 상태 다이어그램 등 개발 설계 모델 존재 유무

발견된 결함 유형 등 이전의 경험

 

4.6 소프트웨어 특성에 따른 테스팅

국제 표준인 ISO/IEC 9126 품질모델(Quality model)에서 제시하는 품질 특성을 기준으로 tc를 도출하는 것도 유용하게 테스트를 설계할 수 있는 방법 중 하나이다.

 

특성 테스팅은 테스트 접근법 중 방법론적 접근법(methodological approach)에 속하며, 품질 특성을 tc 도출 기준으로 사용한다.

 

특성 테스팅으로 tc 도출하는 방법

1. 각 품질 특성을 평가항목으로 보고 테스트 대상에 대한 평가항목의 비율을 선정

2. 각 품질 특성별로 테스트 대상의 특징 및 경험을 고려하여 tc를 도출

 

 

특징을 반영하여 각 품질 특성별 테스트 수행시 집중해야 하는 정보(가중치)를 표시한다.

 

특성 테스팅은 기능 테스팅도 포함하지만 기능 이외 비기능 테스팅(non functional testing)도 포함한다. ISO/IEC 9126에서 기능성 이외의 품질 특성인 신뢰성, 사용성, 효율성, 유지보수성, 이식성 등은 비기능성이다.

 

각 품질 부특성(Quality sub-characteristics)을 참고하면 tc  도출이 용이해지고 일명 메트릭(metrics)으로 불리는 측정 요소들로 구성되어 있는데 메트릭을 활용해 tc 도출에 도움을 받을 수 있다. 그리고 메트릭을 이용해 테스트 결과를 수치화할 수 있다. 

 

신뢰성에 해당하는 품질 부특성

성숙성 : 사용자의 오류를 피하는 능력

오류 허용성 : 내재된 결함으로부터 성능 유지하는 능력

회복성 : 장애발생시 기능 및 데이터 복구 능력

준수성 : 신뢰성 관련 표준, 규정 관례 따르는 능력

 

신뢰성에 대한 테스트 조건의 일반적인 사례

1. 사용자가 암호 입력란에 20자 이상 입력하면 더 이상 입력되지 않으며 소리로 경고음을 출력한다.

2. 화상 대화 기능이 동작하지 않아도 대화 기능 외 다른 모든 기능 또는 시스템에 영향을 주지 않아야 한다.

3. 클라이언트/서버 제품인 경우, 네트워크를 차단했거나 시스템 전원이 단절되었을 때, 해당 상황을 감지하고 실행주이던 메신저가 자동 로그아웃되어야 한다.

 

사용성은 사용자가 이해하고 배우기 쉬운 정보를 의미하며, ui나 어떤 기능을 실행하기 위한 순서, 내용 및 처리 메시지가 적절한지 등을 확인하기 위한 tc를 작성한다. 스토리보드나 UI 설계 문서 등을 참조하여 TC를 작성하고, UI 마감(freeze) 단계에서 최종 마무리할 수 있다. 

 

사용성에 해당하는 품질 부특성

이해성 : 사용자가 운용 방법이나 조건 등을 쉽게 파악하게 하는 능력

학습성 : sw 운용법을 쉽게 배울 수 있게 하는 능력

운용성 : sw를 쉽게 운영하고 제어할 수 있게 하는 능력

친밀성 : 사용자에게 호감을 주는 능력

준수성 : 사용자 관련 표준, 규정, 관례 등을 따르는 능력

 

사용성에 기존 테스팅 결험과 제품 특성을 고려하여 도출한 테스트 조건 사례

MS 윈도우 용으로 작성된 제품, 글꼴이 기본 글꼴 굴림9가 기본 설정으로 되어 있어야  한다.

대중화된 다른 메신저와 대화창의 구조가 비슷해야 하며, 사용자가 적응하기 어려운 구조를 피해야 한다.

광고를 제외한 전체 윈도우 창은 원색 피하고 전체 색감을 통일해야 한다.

 

효율성

자원의 적절한 사용 및 적정한 반응시간 정도로 정의

어떤 기능을 수행하거나 정보를 출력할 때 처리 시간과 자원 사용량이 적절한지를 확인하는 내용은 TC로 작성한다.

 

시간 효율성 : 응답시간, 처리시간, 처리율을 제공하는 능력

자원 효율성 : 기능 수행시 적절히 자원을 사용하는 능력

준수성 : 효율성 관련 표준, 규정, 관례 등을 따르는 능력

 

효율성에 대해 도출 가능한 테스트 조건 사례

각 사용자가 설정한 대화 상대자가 저장된 대량의 DB에서 해당 목록을 검색하여 3초 이내 창에 표시해야 한다.

메신저에 접속하는 동시 사용자 1만명 처리할 수 있어야 한다.

 

유지보수성

SW 수정 및 변경의 용이성으로 정의, SW상에서 변경이 발생하거나 기존의 시스템을 다른 시스템으로 교체하는 경우 작업 절차가 용이한지에 대해 확인하는 과정을 TC로 작성한다.

 

분석성 : 장애 원인을 진단할 수 있게 하는 능력(로그 생성 및 확인)

변경성 : 변경 요청 사항을 쉽게 구현할 수 있게 하는 능력

안정성 : 변경에 따른 예상 밖의 결과를 최소화하는 능력

시험성 : 변경된 결과를 검증할 수 있게 하는 능력

준수성 : 유지보수성 ㅗ간련 표준, 규정, 관례 등을 따르는 능력

 

유지보수성에 대해 도출가능한 테스트 조건 사례

제품이 패치될 경우 또는 버전 업 되었을 때 사용자 개입 없이 자동으로 업데이트 되어야 한다.

메신저 서버 장애시 알람 기능 동작하고 문제 발생 상황이 로그 파일에 기록되어야 한다.

메신저 서버에서 실행중인 시스템이 교체되거나 증설되어 시스템의 이름 또는 IP가 변경되거나 추가되었을 때 제품이 정상 동작하는지 확인한다. 이러한 변경이 가해진 후 사용자가 추가적인 작업 어디까지 해야 하는지에 대한 기준 있어야 한다. 

 

이식성

적응성 : 최소한의 조치만으로 이식될 수 있는 능력

설치성 : 사용자가 지정한 환경으로 설치될 수 있는 능력

대체성 : 공동 운영환경에서 다른 SW를 대체할 수 있는 능력

공존성 : 동일 환경에서 다른 SW와 충돌없이 구동할 수 있는 능력

준수성 : 이식성 관련 표준, 규정, 관례 등을 따르는 능력

 

이식성에 대해 도출 가능한 테스트 조건 사례

메신저는 윈도우 95 이상에서 설치되어 작동한다.

네이트온 및 다른 메신저 프로그램ㄷ과 충돌 없이 실행되어야 한다.

영문 윈도우에서 영문 버전이 설치되어 정상적으로 실행되어야 한다.