[소프트웨어 테스팅] 4. Test-Case Design(Black Box Testing and White Box Testing)

2022.03.20 - [컴퓨터 공학/0 +소프트웨어 테스팅] - [소프트웨어 테스팅] 3. Program Inspections, Walkthroughs and Reviews

[소프트웨어 테스팅] 3. Program Inspections, Walkthroughs and Reviews

 

우리는 시간과 비용이 무한이 아니기 때문에 

가능한 모든 테스트 케이스를 진행 할 수 없다.

가능한 모든 테스트 사례중 오류를 가장 많이 탐지할 확률이 높은 테스트 케이스는 무엇일까...?

일반적으로 가장 효과적이지 않은 방법론으로는 랜덤 입력 테스트이다.

죽, 가능한 모든 입력 값의 일부분을 무작위로 선택하여 프로그램을 테스트하는 프로세스이다..

이 테스트는 최적의 테스트가 될수 없다....

사람들은 이러한 문제를 해결하기 위해 Test Case Design에 대해서 연구하였다...😎

---

 

black box, white box test 각각 뚜렷한 장점과 단점이 있기 때문에, 서로 적절히 조합하며 사용해야한다.

 

---

White box testing

화이트 박스 테스트는 테스트 케이스가 프로그램의 논리(소스 코드)를 어느정도 포함하는지와 관련이 있습니다.

궁극적인 화이트 박스 테스트의 목적은 프로그램 내의 모든 경로를 실행하는 것이지만...

이것은 현실적으로 불가능하다..!!!!

따라서 현실적인 목표를 세워서 실행해야 한다.

 

이제부터 아래와 같은 로직을 테스트 한다고 가정하고 테스트 케이스를 만드는 방법에 대해서 소개하려고 한다.

코드 커버리지(Code Coverage)란?

 

 

IT위키

---

Statement Coverage

예시 로직

프로그램 내의 코드 한줄이 한번 이상 실행된다면 충족한다.

구문 커버리지(%) = (수행된 구문의 수 / 전체 구문의 수) x 100

전체 코드를 실행하기 위해서는 1,2,3,4번 구문을 실행하는 test case를 작성하면 된다.

a = 2, b = 0, x = 3은 조건을 만족하여 1, 2, 3, 4번 구문을 모두 통과한다.

해당 케이스는 4/4 x 100 = 100 이므로 100%에 해당한다. 😲

하지만, 만약에 첫번째 조건이 or인데 실수로 and로 했을 경우 해당 테스트 케이스는 에러를 검출하지 못한다.

두번째 조건도 x>0으로 했을 경우에도 해당 에러를 검출 하지 못한다.

따라서 Statement Coverage라는 녀석은 너무 허점이 많다... ㅠ0ㅠ

그런데, 라인 커버리지를 사용하면(만족하면) 모든 시나리오를 테스트한다는 보장은 할 수 없지만, 어떤 코드가 실행되더라도 해당 코드는 문제가 없다는 보장은 할 수 있다.

이러한 이유로 Statment Coverage를 많이 사용한다.(덤으로 비용도 저렴하다. 😀)

 

 

Decision coverage(Branch coverage)

조건의 전체적인 결과가 참/거짓 이면 충족한다.

결정 커버리지(%) = (수행된 분기 수 / 전체 분기 수) x 100

다시 말하면, 결정 커버리지를 100% 달성하려면 ture를 실행하는 테스트 데이터와 false를 실행하는 테스트 데이터가 모두 필요함.

Statement Coverage를 만족하지 못하는 경우 발생

 

Condition Coverage

각 모든 개별 조건식이 참/거짓을 가지게 되면 된다.

조건 커버리지(%) = (수행된 조건의 수 / 전체 조건의 수) x 100

 

 

Decision/Condition Coverage

Decision Coverage를 고려하지 않은 Condition Coverage를 개선한 것으로 실행된 개별 조건식의 true, false와 분기 모두를 측정한 값

쉽게 설명하면, Decision과 Condition Coverage를 모두 만족하는 값

조건/결정 커버리지(%) = [(수행된 분기 + 조건의 수) / (전체 분기 + 조건의 수)] x 100

 

 

Modified Condition/Decision Coverage(MC/DC)

각 개별조건식이 다른 개별조건식에 무관하게 전체 조건식의 결과에 독립적으로 영향을 주도록 하는 방식

MC/DC(%)  = (만족한 MC/DC 조건 / 전체 조건) x 100

 

 

Multiple-Condition Coverage

결정 포인트 내에 있는 모든 개별조건식의 모든 가능한 논리적인 조합을 고려한다.

다중 조건 커버리지(%)  = (수행된 조건식 조합의 수 / 전체 조건식 조합의 수) x 100

 

 

정리하면 다음과 같다.

• 구문 커버리지(Statement Coverage)
  • 실행 된 구문이 전체 구문에 얼만큼 차지 했는지 측정
  • 다른 커버리지에 비해 제일 취약, 하지만 제일 많이 사용함.
• 결정 커버리지(Decision Coverage)
  • Branch Coverage라고도 불린다.
  • 전체 조건식의 결과가 최소한 참 한번 거짓 한번을 갖는지 측정
  • 조건/결정 커버리지에 비해 취약
• 조건 커버리지(Condition Coverage)
  • 전체 조건식의 결과와 관계없이 조건식의 조건이 참 한번, 거짓 한번을 모두 갖도록 조합하는 것
  • 결정 커버리지보다 강력함.
• 조건/결정 커버리지(Condition/Decsion Coverage)
  • 전체 조건식의 결과가 참 한번, 거짓 한번을 갖도록 각 개별 조건식을 조합하고, 이때 조건식의 조건이 참 한번 거짓 한번 갖도록 조합하는 방법.
• 변경 조건/결정 커버리지(Modify Condition Coverage)
  • 조건식의 조건이 다른 조건식의 조건에 무관하게 전체 조건식의 결과에 독립적으로 영향을 주도록 함
• 다중 조건 커버리지(Multiple Condition Coverage)
  • 결정 지점에 있는 조건식의 조건의 모든 가능한 논리적 조합을 고려

---

 

Balck Box Testing

블랙박스 테스트의 목적은 명세에 따라 동작하지 않는 영역을 찾는 것이다.

따라서 대표적인 명세기반 테스트 기법이다.

 

Equivalence Partitioning(동치 분할)

프로그램의 입력값과 출력값이 특정 그룹으로 분류되고, 분류된 그룹내의 값들이 시스템에 의해 동일하게 취급된다는 특성을 이용한 테스트 방법

여러가지 입력값 중 그 결과로 나오는 출력값이 동일한 경우는 하나의 그룹으로 간주한다.

그리고 이러한 그룹내의 입력값은 내부적으로 같은 방식으로 처리됨을 가정한다.

이러한 원리를 이용하여 입/출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대푯값 하나를 선택하여 테스트 케이스를 선정하는 방식이다.

따라서, 테스트 개수를 줄여준다.

 

예시)

구간	등급(결과)	입력 데이터
80 <= 구간 <= 100	1	85
60 <= 구간 < 80	2	66
0 <= 구간 < 60	과락	30

 

성적이 나올 수 있는 구간이 0 ~ 100이면  입력 데이터는 101가지 이다.

하지만 동등분할 기법을 사용하면 구간별로 그룹을 설정하고 입력 데이터를 선정하여 해당 입력데이터가 각 그룹별 대푯값으로 설정된다. 따라서 101가지에서 3가지로 테스트 케이스 수가 줄어든다.

 

---

 

Boundary Value Analysis(경계값 분석)

입출력 도메인을 동치 분할 클래스로 분류 했을 때, 각 입력값의 경계값에서 결함이 많이 발생하는 사례를 착안하여 테스트 케이스를 설계하는 기법. (동치 분할의 경계 부분에 해당되는 입력값에서 결함이 발결될 확률이 높다는 특성)

동치 분할 기법과 차이점은 2가지가 존재한다.

• 동치 분할 기법에서 구간에서 임의의 데이터를 선정하는 방법과 달리, 구간의 경계값의 데이터를 입력값으로 이용한다.
• 입력값에만 주의를 하는 것이 아니라 출력값을  고려하여 테스트 케이스를 설계한다.

구간	등급(결과)	입력 데이터	기대 결과
80 <= 구간 <= 100	1	valid: 80, 100 invalid: 79, 101	valid: 1등급 invalid:2, error
60 <= 구간 < 80	2	valid: 60, 79 invalid: 59, 80	valid: 2등급 invalid: 과락, 1등급
0 <= 구간 < 60	과락	valid: 0, 59 invalid: -1, 61	valid: 1 invalid: error, 2등급

기대결과와 실제결과를 비교하여 테스트를 한다.

edge를 중심으로 위, 아래값을 입력값으로 사용하고 output을 고려해서 test case를 설계한다.

 

동치 분할기법은 테스터가 선택하는 값이 시험하는 사람에 따라 달라질 수도 있지만,
경계값 분석에 입력 데이터는 누가 테스트해도 같은 입력값으로 테스트 하게 된다.

 

---

 

Cause-Effect Graphing

원인-결과 그래프(Cause-Effect Graph) 테스팅

 

원인 결과 그래프를 통해 요구사항 명세를 입력 조건과 출력 조건간의 논리적 관계로 표현(그래프를 그려서 table을 만듦)하고, 이를 기반으로 테스트 케이스를 만든다.

명세의 불완전성과 모호성을 지적하는 데 유용하다.

Cause는 입력 조건을 의미하고, Effects는 입력조건에 따른 결과를 의미한다.

원인과 결과간의 논리적 관계를 AND, OR, NOT 같은 Boolean연산자를 사용하여 표현.

테스트 출력이 여러 테스트 입력의 조합에 의존하는 시나리오에서 사용하기 적절.

기원은 단순화된 디지털 논리 회로 그래프(simplified digital-logic circuit graph)이며, 이를 소프트웨어 공학에 맞게 적용함.

 

이제 그래프 표기법에 대해서 알아보자...!!😼

여기서 a는 원인 b는 결과이다.

 

indentitiy

원인이 참이면 결과도 참, 원인이 거짓이면 결과도 거짓

NOT

원인이 참이면 결과는 거짓, 원인이 거짓이면 결과는 참

OR

하나이상의 원인이 참이면 결과는 참이고, 모든 원인이 거짓이면 결과는 거짓이다.

AND

하나 이상의 원인이 거짓이면 결과는 거짓, 모든 원인이 참이면 결과는 참

E제약

동시에 모든 원인이 참이 될수 없다.

I제약

동시에 모든 원인이 거짓이 될수 없다.

O제약

원인 중 오로지 하나만 참이다.

R제약

원인a가 참이면 원인b도 참이다.

M(Mask)

원인a가 참이면 원인b는 거짓이다.

 

테스팅 절차는 다음과 같다.

1. 명세를 분석한뒤, 원인과 결과를 식별하고 각각 고유 번호를 부여
2. 원인과 결과를 연결하는 boolean그래프 작성
3. 불가능한 원인 조합 또는 결과 조합을 나타내는 제약을 그래프에 표시
4. 원인-결과 그래프를 decision table(의사결정표)로 변환
5. 의사결정표의 각 컬럼을 테스트 케이스로 변환

 

e.g)

명세서(조건)

1. 첫번째 문자는 반드시 A, 또는 B이다.
2. 두번째 문자는 반드시 0~9까지의 숫자이다.
3. 첫번째 문자가 A또는 B이고 두번째 문자가 0~9의 숫자이면 파일 업데이트
4. 첫번째 문자에 에러가 있으면 메시지 X가 출력
5. 두번째 문자에 에러가 있으면 메시지 Y가 출력

 

원인(cause) 식별

C1: 첫번째 문자가 A

C2: 첫번째 문자가 B

C3: 두번째 문자가 숫자

 

결과(effect)식별

E1: 파일 업데이트 수행

E2: 메시지 X가 출력됨

E3: 메시지 Y출력됨

 

원인-결과 그래프 작성

방법: 결과부터 시작해서 원인으로 탐색해 나간다. 즉, E1부터 시작하여 E2, E3의 각 결과가 참이려면 어떤 원인들이 참이어야 하는지를 따져가면서 그래프를 작성한다.

여기서 C1과 C2를 O제약으로 생각할 수 있는데,
O제약은 정확하게 1개의 원인이 참이어야 하고 E제약은 0개 또는 1개의 원인이 참일 수 있다.

 

의사결정표(Decision Table) 작성

그래프 작성과 마찬가지로 결과부터 시작해서 작성하면 좋다.

 

테스트 케이스 작성

ID	테스트 케이스 명	단계	예상 결과
1	파일 업데이트 시나리오1	1. 첫번째 문자를 A입력 2. 두번째 문자를 0~9사이 입력	파일 업데이트
2	파일 업데이트 시나리오2	1. 첫번째 문자를 B입력 2. 두번째 문자를 0~9사이 입력	파일 업데이트

 

---

에러 추측 기법

Error Guessing

에러 추측 기법은 경험 또는 결함 기반의 테스트 기법이다.

숙련된 테스터들은 다양한 테스팅 경험을 통해 특정 타입의 애플리케이션에서 어떤 문제가 흔히 발생하는지에 대해서 인지하고 있음을 이용한다.(특히, 어떤 부분에서 에러가 자주 일어나고, 개발자들이 어떤 실수를 많이 하는지 알고 있음)

테스터의 기술, 직감, 경험을 기반으로 흔히 나타나는 에러를 추측하고 테스트 케이스를 생성하는 테스팅 기법을 지칭한다.(Experience-based Techniques)

정형적인 테스팅 기법으로 찾기 힘든 결함을 식별하기 위해 다른 체계적인 테스팅 기법들을 보완하는 역할로 사용된다.

특정한 규칙없이 진행하기 때문에 테스터의 개인 역량에 따라 테스트 결과(성과)가 천차만별이다. 즉, 하나의 기법이라기 보다는 스킬로서 보는 편이 더 적절하다.

 

전형적인 에러

• 경계값
• 0으로 나누기
• 텍스트 필드를 빈 칸으로 두고 엔터
• 유효하지 않은 값 입력
• 값을 입력하지 않고 submit
• 최대 한계치를 넘는 파일 업로드
• 널 포인터
• 유효하지 않은 파라미터
• 특정 언어 또는 특수 문자
• 너무 많은 입력

 

에러를 추측하는데 활용될 수 있는 요소

• 과거 릴리즈에서 얻은 교훈
• 테스터의 직감
• 앞선 테스트 결과
• 기존 결함 로그
• 테스팅을 위해 사용된 데이터
• 대상 프로그램에 대한 지식

 

---

 

테스트 케이스 설계 방법에 대한 전략

1. 명세에 입력 조건의 조합이 포함되어 있는 경우 원인-결과 그래프부터 시작한다.
2. 어떠한 경우에도 경계값 분석기법을 사용한다.
3. 동치 분할 기법을 사용하여 테스트 케이스를 보완한다.
4. 에러 추측 기법을 사용하여 테스트 케이스를 보완한다.
5. 구문 커버리지, 조건 커버리지, 결정/조건 커버리지, 다중 조건 커버리지를 사용하여 테스트 케이스를 추가한다.

 

---

정리

• Logic Coverage
  • 모든 의사결정 포인트 결과를 한번 이상 실행 또는 모든 구문이 한번 이상 실행
• Equivalence partitioning
  • 유한한 수의 테스트를 가능하게 만들어주는 테스트 기법
• Boundary value analysis
  • 동치 분할 테스트 기법의 엣지 조건을 테스트함
• Cause-Effect Graphing
  • 효과적이고 완전한 테스트 케이스를 선택하는데 도움이 되는 잠재적인 테스트 케이스 결과를 보여줌.
• Error Guessing
  • 잠재적인 소프트웨어의 오류를 정의하기 위해 직관적이고 전문적인 지식과 경험을 바탕으로 테스트 케이스 작성