1. 코드 커버리지

 

(1) 개요 : 코드 커버리지는 소프트웨어 테스팅에 대한 단계를 측정할 때 사용되는 도구이다. test에 대해 조사를 하면 어떠한 코드가 실행되었는지 또는 실행되지 않았는지에 대한 자료를 보여준다. 커버리지는 단위 테스트에 대해 보조적인 역할을 한다. 단위 테스트가 코드가 예상한대로 동작하는 것을 알려준다면 코드 커버리지는 무엇이 테스트 되야 할 필요가 있는지 알려준다.

 

100퍼센트의 커버리지는 훌륭한 목표이나 100퍼센트의 커버리지를 달성해도 버그가 발견되지 않을 수 있는 위험을 지니고 있다. 일반적으로 소프트웨어 개발 과정에서 line 이나 branch coverage를 측정하나 100퍼센트의 커버리지 수치가 나와도 치명적 버그를 내포할 수 있다. line coverage, branch coverage는 어떠한 코드가 실행되었는지 알려주지 않기 때문에 decision 에서 버그를 놓칠 수 있다. 반면에 path coverage는 결함을 조기에 발견하는데 도움을 줄 수 있다.

 


[그림1]  7개의 statement로 구성되어있고 input output이 같아야 되는 코드 예제

 

 



2. Line coverage

전체 라인에 대하여 얼마나 많은 코드가 수행되었는지 비율을 나타내준다.

[그림1] 에서의 line coverage를 측정하면 100퍼센트가 나온다. 그러나 returnInput() 메소드에는 버그가 있다. 첫번째(5번째 라인) 혹은 두번째(9번째 라인) decision true이고 다른 decision(13번째 라인) false라면 return값이 input과 같지 않게 된다. 이와 같이 100퍼센트의 line coverage가 측정되나 버그가 잠재된 채로 지나치기 쉽다.

 


[수식 1] Line coverage를 구하기 위한 수식

3. Branch coverage

분기문을 테스트 해준다. 메소드안의 분기문 수를 세주는 것은 쉽다. Boolean 분기문의 경우 두 가지의 결과만 나오나 switch문은 각 case마다 고려해야 한다. 심지어 죽 이어진 메소드도 하나의 분기로 가정한다. Boolean decision 10개만 있어도 1024개의 path가 생긴다. 그래서 100퍼센트의 branch coverage를 갖는 것이 적절하지 않을 수 있다.

 

[수식 2] Branch coverage를 구하기 위한 수식

 

[그림 2] TRUE-TRUE-TRUE의 경우와 FALSE-FALSE-FALSE의 경우

 

[그림1] 에서의 코드는 7개의 branch를 갖는다. 이때 [그림2]의 테스트로 TRUE-TRUE-TRUE의 경우와 FALSE-FALSE-FALSE의 경우를 테스트 가능하다. 그러나 TRUE-FALSE-TRUE 혹은 FALSE-TRUE-TRUE path가 누락되었음에도 마찬가지로 100퍼센트의 커버리지를 갖는다.



 

4. Path coverage

메소드의 실행 흐름의 시작부터 메소드의 종료 때까지의 실행가능한 path를 보여준다.  메소드가 N개의 decision이 있다면 2^N개의 path를 갖는다. 메소드에 반복문이 포함되어있으면 무한대 개수의 path를 갖는다


[수식 3] Path coverage를 구하기 위한 수식

 

(1) Cyclomatic complexity   

프로그램의 논리적 복잡성을 수량적으로 측정케 하기 위해 McCabe가 제안한 소프트웨어 척도이다. 복잡도의 계산 방법은 제어 흐름을 나타내는 그래프에서 V 정점과E 엣지가 있을 때 E-V+2 를 만족한다. Cyclomatic complexity를 이용하여 테스트해야 할 path를 줄일 수 있다. 모든 decision 결과에 대해서 테스트를 하는 것은 같으나 각각의 결과들에 대해 독립성을 보장한다. 각각 새 path에 전 실행 decision에서 한 결과만 뒤집는다. 이러한 요소로 한 개의 decision이 바뀌었을 때 메소드의 행동이 어떻게 바뀌는지 보여준다.

 



[그림 3] Control flow graph

 

위의 그림에서는 edge가 총 9, Node 8개 이기 때문에 공식을 대입해보면 Cyclomatic Complexity 9 – 8 + 2 = 3 란 값이 나온다.

 

 

 

(2) 예시

[그림1] 에서의 path coverage 100퍼센트로 달성하기 위해선 기본 set을 정의해야 한다. 이 메소드의 cyclomatic complexity 4 이므로, 4개의 선형적 독립 path를 정의할 필요가 있다. 이를 위해 첫번째로 임의의 path를 기본으로 선택하는 것으로 시작한다. 그런 후 기본 set을 얻을 때까지 decision을 뒤집는다.

 

Path1 : 기본으로 아무 set이나 택한다. 예로 TTT의 경우를 택한다.

Path2 : 다음 기본 path를 찾기 위해 첫번째 decision을 뒤집는다. FTT decision결과를 얻게 된다.

Path3 : 마찬가지로 2번째 decision을 뒤집으면 TFT 3번째 path로 얻는다.

 Path4 :  마지막으로 3번째 decision을 뒤집으면 TTF path를 얻게 되는데, 이때, 4개의 기본 path TTT, FTT, TFT, TTF 이다.

 

testReturnInputIntTFT() testReturnInputIntFTT() 의 경우 line coverage branch coverage로 놓치는 버그가 있다. 또한 decision이 증가할 수록 path가 선형적으로 증가하게 된다. 또한 기본 path가 메소드에서의 branch line coverage cover하기 때문에, 효과적으로 branch line coverage를 내포할 수 있다.

path testing 하는 목적이 서로 독립적으로 모든 판정 결과를 테스트하는 것이므로, 만약  FFF 를 기본 path로 정하였다면 기본 pathFFF, TFF, FTF, FFT 일 것이다. 위의 예와 마찬가지로 유효한 결과이고 독립적인 decision 결과를 만족한다.



5. Requirement coverage

요구사항 coverage는 소프트웨어 라이프 사이클에 필수적인 요소이다. 디자인,코딩, 테스팅 단계를 거치는 동안 소프트웨어가 요구사항을 만족시키는지 보장해주는 것이다. 소프트웨어가 개발 반복 과정을 거치면서 버그가 수정된다. 이와 동시에 소프트웨어의 요구사항 coverage 또한 추출된다.

 



[수식 3] 요구사항 coverage를 구하기 위한 수식

요구사항 coverage를 만족하기 위해 몇 가지 방법이 있다. 어떠한 도구들은 프로젝트의 부산물들에 대해 traceability를 기재한 스프레드 시트를 작성한다. 프로젝트가 코딩 단계에 들어가면 요구사항 coverage를 관리하기가 더 어려워진다. 프로젝트 도입 초기에 관리를 하는 것이 중요하다

 

 

 

 

 

6. 커버리지 측정 툴



(1) 원리 : Code Coverage 도구의 주요 기능은 실행 중에 해당 Code 라인이 수행되었는지를 검증하는 것이다. 이를 위해서 Coverage 도구는 Class의 각 실행 라인에 Code coverage 도구로 기록하는 Logic을 추가하는 것이 기본 원리이다. 이를 ‘Instrument’ 라고 함



(2) 도구 개요 :

정적 기법 도구 : 프로그램이 수행되기 이전에 Source code Compile이 완료되어 있는 Class 파일을 Instrument하여 Instrumented class들을 만든 후, 그것을 수행하는 방식



동적 기법 도구 : 원본 클래스를 가지고 프로그램을 수행하여 런타임에 클래스가 로딩될 때 클래스에 Instrumentation을 하는 방식, 런타임에서 Code instrumentation을 하는 부하가 발생하게 된다.


(3) 사용법 – EMMA


[그림 4] 위의 예제에서 Line coverageBranch coverage100퍼센트를 도달

 

 

[그림 5] line에 대해 coverage를 표시해줌

 


[
그림 6] 각 요소들마다의 coverage를 표시해줌

 

 

7. 요약

Line coverage Branch coverage는 측정이 간단하나 치명적인 결함을 놓칠 수 있다. Path coverage는 테스트 set의 갯수를 기하급수적으로 요하지 않으면서 Line coverageBranch coverage가 놓친 결함을 찾는데 사용된다.

 

참조

http://www.cs.swan.ac.uk/~csmarkus/CS339/dissertations/GregoryL.pdf

http://www.swbank.kr/html/tools/toolsFile/EMMA_05_functionIntro.pdf

http://aeternum.egloos.com/1209470

'Software Engineering > Testing' 카테고리의 다른 글

테스트 커버리지  (0) 2014.07.22
테스트 개요  (0) 2014.07.22
코드 커버리지  (0) 2014.03.26
JUnit  (0) 2014.02.01
성능 테스트  (0) 2013.12.17
테스팅 개요  (0) 2013.12.17

WRITTEN BY
마경욱
C.S, Software, 기타 일상

받은 트랙백이 없고 , 댓글이 없습니다.
secret