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

4.3.2 구조 기반 기법 structure-based technique

구조 기반(화이트박스) 테스팅은 소프트웨어나 시스템의 구조를 중심으로 테스팅하는 것이다.

컴포넌트 레벨의 구조는 구문(statement), 결정(decision), 분기문(branch) 등 코드 그 자체이다.

통합 레벨의 구조는 한 모듈이 다른 모듈을 호출하는 관계를 도식화한 콜 트리 등이다.

 

구문 커버리지 statement coverage 는 테스트 스위트에 의해 실행된 구문이 몇 퍼센트인지 측정하는 것으로 다른 커버리지에 비해 가장 약하다.

 

결정 커버리지(branch coverage, decision coverage) 는 테스트 스위트에 의해 실행된 결정 포인트 내의 전체조건식이 최소한 참이 한 번 그리고 거짓이 한 번 선택되었는지 측정하여 퍼센트로 표현하는 것이다. 

 

조건 커버리지는 전체조건식의 결과와 관계없이 각 개별 조건식이 참 한번, 거짓 한번 모두 갖도록 조합한다. 강력한 형태이다.

 

조건 결정 커버리지(condition/decision coverage)는 전체 조건식의 결과가 참 한 번, 거짓 한번 갖도록 개별조건식을 조합한다. 이 때 각 조건식도 참과 거짓 한번씩 모두 갖도록 조합하는 것으로 결정 커버리지와 조건 커버리지를 포함하는 커버리지이다.

 

다중 조건 커버리지(multiple condition coverage)

결정 포인트 내에 있는 모든 개별조건식의 모든 가능한 논리적인 조합을 고려하여 100% 커버리지를 보장한다.

 

관련 커버리지를 달성하는 테스트 기법에 대해서 알아보자~

 

4.3.2.1 구문 테스팅과 커버리지

테스트 스위트에 의해 실행된 구문이 몇 퍼센트인지를 측정하는 것이다. 구문 테스팅은 구문 커버리지를 늘리기 위해 특정 구문을 테스트하는 테스트 케이스를 도출하는 것이다. 

 

4.3.2.2 결정 테스팅과 커버리지(decision testing and coverage)

테스트 스위트에 의해 실행된 조건문 분기가 전체 가능한 분기의 몇 퍼센트인지를 측정하고 평가하는 것이다. 결정 커버리지는 결정 포인트 내의 전체 조건식이 참과 거짓의 모든 값을 갖게 되어 모든 분기로 흐르게 되면 달성한다.

 

결정 테스팅은 결정 포인트에 해당하는 제어 흐름을 다루므로 제어 흐름 테스팅이 한가지 형태이다. 

 

결정 포인트에 들어오는 흐름(inflow)와 나가는 흐름(outflow)의 조합을 표형태가 아닌 트리 형태로 표현할 수 있고, 트리를 사용한 흐름 체크(test depth level2) 할 수 있다.

=> 시각화하여 커버되지 않은 부분을 파악하기가 용이하다.

 

결정 포인트 중심의 흐름 체크 - 테스트 깊이 레벨 3(선택적)

 

4.3.2.3 조건 테스팅과 커버리지(codition testing and coverage)

조건 커버리지나 다중 조건 커버리지와 같이 결정 커버리지보다 강력한 레벨의 구조적 커버리지가 있다. 

 

조건 커버리지는 달성하지만 결정 커버리지는 달성하지 못하는 경우 있다.

x>-2, and y<4, (-3,2) 와 (0,6)인 경우를 생각하면, 각각 x, y 라면, 거짓과 참, 그리고 참과 거짓이므로 거짓의 값을 갖게 되

므로 결정 커버리지를 달성하지 못한다.

 

=> 조건 커버리지는 달성하지만 결정 커버리지는 달성하지 못하는 경우가 존재하므로 두 커버리지 간에 포함관계가 성립되지 않는다. 더 강력한 커버리지는 조건 커버리지를 달성하는 테스트가 결정 커버리지를 달성하는 테스트보다 더 견고한(rigorous) 테스트이다.

 

조건/결정 커버리지는 조건 커버리지와 결정 커버리지를 최소한의 조합으로 달성하는 경우를 의미한다. 

=> 항상 모든 개별조건식이 참이고 이에 따른 전체조건식이 참일 경우와, 모든 개별 조건식이 거짓이면서 이에 따른 전체 조건식이 거짓일 경우 의미하며 2개의 테스트로 달성 가능하다.

 

다중 조건 커버리지 - multiple condition coverage

결정 포인트 내의 개별조건식 결과에 대한 모든 가능한 논리적인 조합을 적어도 한 번 수행

 

변형 조건/결정 커버리지 - MC/DC

결정 포인트 내의 다른 개별 조건식의 결과와는 독립적으로 해당 개별조건 식이 전체조건식의 결과에 영향을 줌

 

다중 조건 커버리지(multiple condition coverage)

모든 개별 조건식의 모든 조합의 경우의 수 고려한 방법

tc 양이 매우 방대, 출시 전에 반드시 100% 결함을 제거해야 하는 제품 테스트에서 주로 사용됨

 

사용자의 id는 10자 미만 문자와 숫자 사용할 수 있고, 반드시 첫 문자 문자 허용, 암호는 10자 미만 문자와 숫자 허용 

 

표 DPoint = A AND B 에 대한 다중 조건 커버리지의 결정 테이블

DPoint	A(userID)	B(userpassword)
1	1	1
0	1	0
0	0	1
0	0	0

tc 는 물리적인 tc로 만들기 위해 개별 조합 DPoint 에 대해 하나의 물리적인 tc로 전환시킨다.

=> 이 기법 블랙박스 테스트에서 이용한다면 입력 정보가 2개 이상일 때 검색을 위해 선택된 항목이 2개 이상인 경우 각 항목의 조합을 위와 같은 기법을 사용하여 tc 로 도출할 수 있다.

항목이 2개 이상인 경우 tc  기하급수적으로 많아져 신뢰성 확보하면서 tc 줄일 수 있는 방법은 결정,조건, 조건/결정, 변형 조건/결정 커버리지이다.

 

4.3.2.4 변형 조건/결정 커버리지 (modified condition/decision coverage)

각 개별조건식이 다른 개별조건식에 영향을 받지 않고 전체조건식의 결과에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 것으로 결정, 조건 커버리지보다 강력하다. 

 

MC/DC 결정 테이블을 만드는 방법

결정 포인트 내의 전체 조건식은 적어도 한 번 모든 가능한 결과값(참, 거짓)을 취한다.

프로그램에 있는 결정 포인트 내의 모든 개별조건식은 적어도 한 번 모든 가능한 결과값을 취한다. 

결과값에 독립적으로 영향을 준다.

 

표. Dpoint=A AND B 에 대한 MC/DC 결정 테이블 (3개의 테스트 케이스)

Dpoint(전체조건식)	A(개별조건식)	B(개별조건식)	설명
1	1	1	A가 B에 독립적, B가 A에 독립적으로 영향미침. 개별조건식 A,B 중 하나라도 0으로 변경하면 전체조건식이 변경되므로 A,B 모두 전체조건식에 독립적으로 영향을 준다.
0	1	0	B가 A에 독립적으로 영향 미침 B를 1로 바꾸면 전체조건식이 1로 변경되므로 영향줌
0	0	1	A가 B에 독립적으로 전체조건식에 영향 미침 A를 1로 변경하면 전체조건식1 되므로 전체조건식에 독립적으로 영향을 주는 것이다.
0	0	0	개별조건식 A,B 중 어느 한 개의 값을 1로 변경하더라도 결과인 전체조건식은 0 으로 변화 없어서 독립적으로 영향을 미치지 못한다. 그러므로 MC/DC 커버리지에서는 제외한다.

 

변형 조건/결정 커버리지 통해 개별조건식의 개수 N개 라면 결정 포인트의 최소한의 테스트 케이스 수(MC/DC 조합의 수)는 = N+1 ( N: 개별조건식 개수)

 

1) 대각선으로 1과 0을 지정

D1에 대한 조건/결정 커버리지를 만족시키는 조건

 

OR 이나 AND 로 연결된 전체 조건식이 참과 거짓 값을 가져야 한다. 참이 되기 위해서는 개별조건식 중 최소한 한가지는 참값을 가져야 하고, 거짓이 되기 위해서는 최소한 한 가지가 거짓이어야 하므로 

 

2) 개별조건식이 OR인 경우, AND  인 경우 1을 빈곳에 삽입

 

3) 테스트 상황 (test situation) 구성

변형 조건/결정 커버리지를 달성하도록 의도하는 과정을 통해 파악할 수 있다.

 

4) 논리적인 tc 도출

 

5) 물리적 tc 도출

테스트 데이터를 선택하는 과정에서 경계값 분석 기법을 적용하여 tc 개수를 늘려 보장성이 높은 테스트를 실행할 수 있다.

=> 최소 비교 테스트는 구조기반 테스트(화이트박스 테스팅) 기법이지만 블랙박스 테스팅에도 적용할 수 있으며, 배치나 온라인 환경에서의 어떤 정보를 처리하기 위해 입력 또는 선택할 항목이 있을 때 효율적이면서 효과적으로 tc를 작성할 수 있다.

 

 

커버리지를 달성하는 테스팅 기법을 컴포넌트 테스트 이외의 다른 테스트 레벨에서도 활용가능하다. 통합 테스팅에서는 모듈, 컴포넌트, 클래스가 특정 조건에 따른 IF 를 가지고 있을 경우, 시스템/인수 테스팅에서는 기능 또는 비즈니스 로직이 특정 조건에 따라 동작할 때 동일한 기법을 응용하여 적용할 수 있다.

 

코드의 구조를 테스트할 때는 TC를 자동으로 생성하여 실행하는 도구나 코드 커버리지를 자동으로 산출하는 도구를 사용하는 것이 유용하다.

 

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

이전에 테스터가 다루었던 유사 어플리케이션이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 tc를 추출해낸다. 

효율성, 효과성의 정도가 매우 달라질 수 있다.

 

4.3.3.1 탐색적 테스팅 접근법(Exploatory testing approach)

1) 탐색적 테스팅의 개념

탐색적 테스팅을 주창한 제임스 바크의 주장은 tc 작성의 시간을 최소화하고 테스트 엔지니어의 발견적인 (huristic) 지적 능력을 최대한 활용하여 테스트를 수행하는 것이다.

 

애드혹(Ad hoc) 테스팅, 게릴라 테스팅, 직관적(instuitive) 테스팅과 유사한 개념이지만 정해진 임무와 목표(objectives), 결과물(deliverables)이 존재한다는 측면에서 다르다. 

 

테스트 설계, 수행, 계획, 기록 및 학습을 동시에 진행하는 휴리스틱한, 발견적인 테스팅 접근법이다.

tc를 먼저 작성하지 않고, 대상 제품을 실행하면서 익숙해짐과 동시에 테스트를 설계하고 테스트를 계획한다.

 

60~120분 정도 몰입해서 수행할 수 있을 정도의 테스트 차터(test charter) 를 기반으로 수행하는 것이 일반적이다.

제한된 시간내에 테스팅의 목적을 정한 후 몰입하여 최소한의 설명 가능한 기록(note)를 남기면서 테스트를 수행하고, 수행 후 요약보고(debriefing)를 한다. 

 

tc 기반 공식적 테스팅과 반대되는 개념의 테스팅 접근법이다.

테스트 엔지니어는 자신 또는 동료와의 도전적인 대화와 체계적인 사고(systematic thinking)를 통해 머릿속에서 테스트를 설계하면서 테스팅을 진행한다. 

 

탐색적 테스팅에서는 페어와이즈 기법, 등가분할, 경계값 분석, 결정 테이블 테스팅 등 알려진 대부분 테스트 설계 기법을 활용할 수 있으나 최소한의 기법만을 사용할 것을 권장한다.

 

 

애드 훅 테스팅과 완전히 다르다. 가장 큰 차이점은 탐색적 테스팅이 차터 기반으로 제한된 시간 내에 몰입해서 테스팅을 수행하고, 설명 가능한 기록을 남기고 요약보고(debriefing) 미팅을 갖는다. 

=> 체계적인 사고 분야 및 휴리스틱스에 이론적 근거 둔다. 

 

탐색적 테스팅이 포함하는 항목

• 제품 탐색(product exploration)
• 테스트 설계(test design)
• 테스트 실행(test execution)
• 직관(heuristics)
• 검토 가능한 결과물(reviewable results)

 

탐색적 테스팅이 제안하는 테스트 절차

• 제품의 목적 식별(identity the purpose of the product)
• 기능 식별(identity functions)
• 잠재적으로 불안정한 부분 식별(identity areas of potential instability(
•  각각의 기능 테스트 및 문제점 기록
• 일관성 검증 테스트 설계 및 기록
•  

2) 탐색적 테스팅의 구성 요소

테스트 차터와 시간 제한

 

테스터가 제한 시간 안에 수행해야 할 것

• 정확한 리포팅(accurate reporting)
• 유연성 있는 일정관리(flexible scheduling)
• 테스트 방향 정정(couse correction)
• 견고한 테스팅(solid testing done)
• 효율적인 요약 보고(efficient debriefings)

 

테스트 차터가 효율적으로 만들기 위해서는 무작정 수를 늘리기 보다 제품 리스크에 기반하여 만들어야 한다.

=> 리스크 분석 결과 제품의 리스크가 높은 기능에는 테스트 차터를 많이 생성해야 한다.(반대!)

=> 리스크 기반 차터 설계

 

테스트 노트와 요약 보고

탐색적 테스팅에서는 문서를 최소화해야 한다 주장하지만 테스트 산출물이 아예 없지 않다.

엔지니어는 테스트 실행과 동시에 머릿속으로 계획, 설계하고 tc를 작성하며 이러한 사고활동을 간단하게 노트에 기록한다.

 

 

테스트 노트에 포함되어야 할 내용

테스트한 제품에 대한 노트 및 기록

발견한 결함과 장애에 대한 노트 및 기록

어떻게 테스트하였는지를 기술하는 요약된 문서