KR101667262B1

KR101667262B1 - 코드 커버리지 측정 방법 및 이를 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체

Info

Publication number: KR101667262B1
Application number: KR1020140107037A
Authority: KR
Inventors: 배현섭; 윤광식; 조민성; 박재현; 곽충석
Original assignee: 슈어소프트테크주식회사
Priority date: 2014-08-18
Filing date: 2014-08-18
Publication date: 2016-10-19
Also published as: KR20160021585A; WO2016027992A1

Abstract

본 발명의 실시 형태는 코드 커버리지 측정 방법에 관한 것이다.
실시 형태에 따른 코드 커버리지 측정 방법은, 상기 소스 코드에 탐침을 삽입하는 단계; 상기 탐침이 삽입된 소스 코드를 컴파일하여 실행 파일을 생성하는 단계; 및 상기 생성된 실행 파일을 이용하여 상기 코드 커버리지를 측정하는 단계;를 포함하고, 상기 소스 코드에 탐침을 삽입하는 단계는, 상기 소스 코드로부터 추상 구문 트리를 생성하는 단계; 상기 추상 구문 트리를 해석하여 제어 흐름 그래프를 생성하는 단계; 및 상기 추상 구문 트리와 상기 제어 흐름 그래프를 이용하여 상기 소스 코드에 상기 탐침을 삽입하는 단계;를 포함한다.

Description

코드 커버리지 측정 방법 및 이를 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체{METHOD FOR MEASURING CODE COVERAGE AND COMPUTER READABLE RECORDING MEDIUM HAVING PROGRAM THE SAME }

본 발명은 코드 커버리지 측정 방법 및 이를 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체에 관한 것이다.

코드 커버리지(Code Coverage)는, 소프트웨어 테스트(software test)의 품질을 측정하기 위해 사용되는 하나의 척도(measure)이다.

코드 커버리지는, 어느 하나의 프로그램(program)의 소스 코드(source code)가 테스트된 비율을 의미한다. 따라서, 코드 커버리지는 일반적으로 백분율로 표시된다.

코드 커버리지를 측정하기 위해서는, 소정의 코드 커버리지 측정 도구가 필요한데 대표적으로 LDRA과 VectorCAST가 있다.

본 발명은, 코드 커버리지를 측정하고자 하는 소스 코드에 탐침을 효율적으로 삽입할 수 있는 코드 커버리지 측정 방법과 이를 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체를 제공한다.

또한, 본 발명은, 커버리지 측정을 위해 소스 코드를 컴파일 한 후에, 전체 소스 코드들 중에서 변경이 없는 소스 코드에 대해서는 컴파일하여 실행 파일을 생성해야하는 반복적인 과정을 생략할 수 있는 코드 커버리지 측정 방법과 이를 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체를 제공한다.

또한, 본 발명은, 소스 코드의 코드 커버리지 측정한 후에, 소스 코드에 변경이 이루어질 때마다 전체 소스 코드의 코드 커버리지를 다시 측정하지 않을 수 있는 효과적인 코드 커버리지 측정 방법과 이를 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체를 제공한다.

또한, 본 발명은, 소정의 소스 코드가 하나의 장치가 아닌 복수의 장치들에서 코드 커버리지 테스트가 수행된 경우에, 복수의 장치들에서 수집된 코드 커버리지 테스트를 취합하여 소스 코드의 코드 커버리지를 신속하게 측정할 수 있는 코드 커버리지 측정 방법과 이를 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체를 제공한다.

본 발명의 해결하고자 하는 과제는 이상에서 언급된 것들에 한정되지 않으며, 언급되지 아니한 다른 해결하고자 하는 과제들은 아래의 기재로부터 당업자에게 명확하게 이해되어질 수 있을 것이다.

실시 형태에 따른 소스 코드의 코드 커버리지 측정 방법은, 소스 코드의 코드 커버리지를 측정하는 방법으로서, 탐침 삽입 장치가 상기 소스 코드에 탐침을 삽입하는 탐침 삽입 단계; 컴파일러가 상기 탐침이 삽입된 소스 코드를 컴파일하여 실행 파일을 생성하는 컴파일 단계; 및 코드 커버리지 측정 도구가 상기 생성된 실행 파일을 이용하여 상기 코드 커버리지를 측정하는 코드 커버리지 측정 단계;를 포함하고, 상기 탐침 삽입 단계는, 파서가 상기 소스 코드로부터 추상 구문 트리를 생성하는 추상 구문 트리 생성 단계; 제어 흐름 그래프 생성기가 상기 추상 구문 트리를 해석하여 제어 흐름 그래프를 생성하는 제어 흐름 그래프 생성 단계; 및 소스 코드 재기록기가 상기 추상 구문 트리와 상기 제어 흐름 그래프를 이용하여 상기 소스 코드에 상기 탐침을 삽입하는 재기록 단계;를 포함하고, 상기 재기록 단계는, 상기 제어 흐름 그래프에서 기저 경로들을 검색한 후, 각 기저 경로당 제1 탐침을 하나씩 삽입하는 제1 탐침 삽입 단계; 및 상기 추상 구문 트리 내의 분기문 중 상기 탐침의 삽입을 생략할 수 있는 분기문을 판별하고, 상기 판별된 분기문의 형태를 삼항 연산자 형태로 변경하여 제2 탐침을 삽입하는 제2 탐침 삽입 단계;를 포함한다.
실시 형태에 따른 소스 코드의 코드 커버리지 측정 방법은, 탐침 삽입 장치가 상기 소스 코드에 탐침을 삽입하는 탐침 삽입 단계; 컴파일러가 상기 탐침이 삽입된 소스 코드를 컴파일하여 실행 파일을 생성하는 컴파일 단계; 및 코드 커버리지 측정 도구가 상기 생성된 실행 파일을 이용하여 상기 코드 커버리지를 측정하는 코드 커버리지 측정 단계;를 포함하고, 상기 탐침 삽입 단계 이전에, 상기 소스 코드가 기존에 컴파일을 수행하였던 것인지 여부를 판별기에 의해 판별하는 판별 단계를 더 포함하고, 상기 판별 단계에서, 상기 소스 코드가 기존에 컴파일을 수행하였던 것으로 판별되면, 상기 탐침 삽입 단계와 상기 컴파일 단계는 생략되고, 상기 코드 커버리지 측정 단계는 기존 실행 파일을 재사용하여 상기 코드 커버리지를 측정한다.

실시 형태에 따른 소스 코드의 코드 커버리지 측정 방법은, 상기 소스 코드가 실질적으로 변경되었는지 여부를 판별기가 판별하는 판별 단계; 상기 소스 코드가 실질적으로 변경되었으면, 코드 커버리지 도구가 변경된 소스 코드의 코드 커버리지를 측정하는 측정 단계; 및 상기 소스 코트가 실질적으로 변경되지 않았으면, 상기 판별기가 저장소에 저장된 기존 코드 커버리지 값을 불러와 출력하는 출력 단계;를 포함한다.

실시 형태에 따른 소스 코드의 코드 커버리지 측정 방법은, 서버가 복수의 장치들에서 수집된 코드 커버리지 로그들을 수신하여 코드 커버리지를 측정하는 방법으로서, 상기 복수의 장치들로부터 수신되는 코드 커버리지 로그들을 수신되는 시간 순서대로 대기열에 저장하는 단계; 및 상기 대기열에 저장된 코드 커버리지 로그들을 이용하여 상기 코드 커버리지를 측정하는 단계;를 포함한다.

본 발명에 따른 코드 커버리지 측정 방법과 이를 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체를 사용하면, 코드 커버리지를 측정하고자 하는 소스 코드에 탐침을 효율적으로 삽입할 수 있다. 따라서, 탐침이 삽입된 소스 코드의 바이너리(binary) 크기를 줄일 수 있어 소스 코드의 코드 커버리지 값을 측정할 때 따르는 성능 부작용을 최소화할 수 있는 이점이 있다.

또한, 소스 코드를 컴파일 한 후에, 소스 코드에 변경이 이루어질 때마다 전체 소스 코드에 대해서 커버리지 측정용 실행 파일을 생성해야하는 반복적인 과정을 생략할 수 있다. 따라서, 변경되지 않은 소스 코드에 대해서는 커버리지 측정 준비 과정이 생략될 수 있으므로, 소스 코드의 코드 커버리지 측정 준비 시간을 줄일 수 있는 이점이 있다.

또한, 소스 코드의 코드 커버리지 측정한 후에, 소스 코드에 변경이 이루어지더라도 변경되지 않은 소스 코드 부분의 커버리지 값은 그대로 유지하여 전체 소스 코드의 코드 커버리지를 다시 측정하지 않을 수 있다. 따라서, 코드 커버리지 테스트가 된 부분을 다시 테스트하지 않아도 되기 때문에, 특정 커버리지 기준값을 달성하는데 들어가는 시간을 줄일 수 있는 이점이 있다.

또한, 소정의 소스 코드가 하나의 장치가 아닌 복수의 장치들에서 코드 커버리지 테스트가 수행된 경우에, 복수의 장치들에서 수집된 코드 커버리지 테스트를 자동으로 취합하여 소스 코드의 코드 커버리지를 신속하게 측정할 수 있다.

도 1은 본 발명의 제1 실시 형태에 따른 코드 커버리지 측정 방법을 나타내는 순서도.
도 2는 도 1에 도시된 소스 코드에 탐침을 삽입하는 단계를 구체화한 순서도.
도 3은 탐침의 삽입 위치를 결정하는 방법을 설명하기 위한 제어 흐름 그래프의 일 예.
도 4는 도 2에 도시된 소스 코드에 탐침을 삽입하는 방법을 구현할 수 있는 탐침 삽입 장치의 블록도.
도 5는 본 발명의 제2 실시 형태에 따른 코드 커버리지 측정 방법을 나타내는 순서도.
도 6은 도 5에 도시된 해당 소스 코드가 기존에 컴파일 수행했던 소스 코드이지 여부를 판별하는 단계(10)를 구체화한 순서도.
도 7은 본 발명의 제3 실시 형태에 따른 코드 커버리지 측정 방법을 나타내는 순서도.
도 8은 도 7에 도시된 변경된 소스 코드가 실질적으로 변경되었는지 여부를 판별하는 단계(20)를 구체화한 순서도.
도 9는 제4 실시 형태에 따른 코드 커버리지 측정 방법을 설명하기 위한 시스템도.
도 10은 제4 실시 형태에 따른 코드 커버리지를 측정하는 방법을 설명하기 위한 순서도.
도 11은 도 10에 도시된 코드 커버리지 측정 방법의 첫 번째 예를 설명하기 위한 도면.
도 12은 도 10에 도시된 코드 커버리지 측정 방법의 두 번째 예를 설명하기 위한 도면.

이하, 본 발명의 바람직한 실시예의 상세한 설명이 첨부된 도면들을 참조하여 설명된다. 도면들 중 인용부호들 및 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 인용부호들로 표시됨을 유의해야 한다. 참고로 본 발명을 설명함에 있어서 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 이하 첨부된 도면을 참조하여 본 발명의 실시 형태에 따른 코드 커버리지 측정 방법을 설명한다.

도 1은 본 발명의 제1 실시 형태에 따른 코드 커버리지 측정 방법을 나타내는 순서도이다.

도 1을 참조하면, 제1 실시 형태에 따른 코드 커버리지 측정 방법은, 소스 코드에 탐침(probe)을 삽입하는 단계(100), 실행 파일을 생성하는 단계(300) 및 코드 커버리지를 측정하는 단계(500)를 포함할 수 있다.

소스 코드에 탐침을 삽입하는 단계(100)는 코드 커버리지를 측정하기 위한 탐침을 소스 코드에 삽입하는 단계이다. 이 단계는, 도 2를 참조하여 구체적으로 후술하도록 한다.

실행 파일을 생성하는 단계(300)는, 탐침이 삽입된 소스 코드를 컴파일하여 실행 파일을 생성하는 단계이다.

코드 커버리지를 측정하는 단계(500)는 생성된 실행 파일을 이용하여 코드 커버리지를 측정하는 단계이다.

도 2는 도 1에 도시된 소스 코드에 탐침을 삽입하는 단계를 구체화한 순서도이다.

소스 코드에 탐침을 삽입하는 단계는, 추상 구문 트리(abstract syntax tree, AST)를 생성하는 단계(110), 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하는 단계(120) 및 탐침을 삽입하는 단계(130)를 포함할 수 있다.

추상 구문 트리를 생성하는 단계(110)는, 소스 코드로부터 추상 구문 트리를 생성할 수 있다. 추상 구문 트리는, 파서(parser)를 이용하여 생성할 수 있다. 여기서, 파서는 예를 들어 C/C++ 파서일 수 있다. 소스 코드를 C/C++ 파서로 입력시키면 C/C++ 파서는 추상 구문 트리를 생성할 수 있다.

제어 흐름 그래프를 생성하는 단계(120)는 앞서 생성된 추상 구문 트리를 해석하여 제어 흐름 그래프를 생성한다.

탐침을 삽입하는 단계(130)는, 앞서 생성된 추상 구문 트리와 제어 흐름 그래프를 이용하여 탐침을 삽입하는 단계이다. 구체적인 탐침 삽입 방법을 이하에서 구체적으로 설명하도록 한다.

탐침은 추상 구문 트리와 제어 흐름 그래프를 이용하여 삽입한다. 구체적으로, 제어 흐름 그래프를 참조하여 탐침을 삽입하고, 추상 구문 트리 내의 분기문의 조건의 개수를 판별하여 탐침을 삽입할 수 있다.

제어 흐름 그래프를 참조하여 탐침을 삽입하는 방법과 추상 구문 트리 내의 분기문의 조건의 개수를 판별하여 탐침을 삽입하는 방법은 각자 병렬적으로 수행될 수 있다. 이하에서 각각 나눠서 설명하도록 한다.

제어 흐름 그래프를 참조하여 탐침을 삽입하는 방법은, 제어 흐름 그래프에서 탐침의 삽입 위치를 결정한 후, 탐침을 삽입할 수 있다.

제어 흐름 그래프에서 탐침의 삽입 위치를 결정하는 방법은, 제어 흐름 그래프에서 기저 경로(basis path)들을 검색한 후, 각 기저 경로당 하나의 탐침을 삽입하는 것으로 결정될 수 있다.

여기서, 기저 경로란, 분기문의 한 가지(brench)에서 다음 분기문을 만나기 전까지의 경로를 의미하는데, 기저 경로는 더 이상 나눌 수 없는 최소의 수행 흐름이다. 도 3을 참조하여 제어 흐름 그래프에서 탐침의 삽입 위치를 결정하는 방법의 일 예를 설명하도록 한다.

도 3은 탐침의 삽입 위치를 결정하는 방법을 설명하기 위한 제어 흐름 그래프의 일 예이다.

도 3에 도시된 제어 흐름 그래프에서 기저 경로를 검색한다. 기저 경로는 앞에서 설명한 바와 같이 분기문(if)의 한 가지에서 다음 분기문(if)을 만나기 전까지의 경로이므로, 도 3에 도시된 제어 흐름 그래프에서의 기저 경로는 5개(path 1, path 2, path 3, path 4, path 5)이다.

5개의 기저 경로들(path 1, path 2, path 3, path 4, path 5) 각각에 하나의 탐침(P1, P2, P3, P4, P5)을 삽입한다.

다시, 도 2를 참조하여, 추상 구문 트리 내의 분기문의 조건의 개수를 판별하여 탐침을 삽입하는 방법을 설명한다.

추상 구문 트리 내의 분기문의 조건의 개수를 판별하여 탐침을 삽입하는 방법은, 추상 구문 트리에서 조건의 개수가 2개 이상인 분기문을 검색하고, 검색된 분기문의 형태를 변경한 후, 탐침을 삽입하는 것일 수 있다.

여기서, 분기문은 실행 흐름을 결정하는 문으로서, for문, if문 및 while문을 포함할 수 있다. 그리고, 분기문의 형태를 변경한다는 의미는 검색된 분기문의 실질적인 의미는 변경하지 않고, 탐침을 삽입할 수 있도록 형식을 변경하는 것을 의미한다.

이하에서는, 조건이 2개인 분기문(if문)의 형태를 변경하는 하나의 방법을 예를 들어 설명하도록 한다.

[분기문 예]

If (A && B)

상기 [분기문 예]는 if문이고, 조건이 2개(A, B)이며, 2개의 조건(A, B)은 1개의 논리 연산자(&&)로 결합되어 있다. 상기 [분기문의 예]의 진리표는 아래의 <표 1>과 같다.

A	B	Decision
1 (true)	1 (true)	1 (true)
1 (true)	0 (false)	0 (false)
0 (false)	Don’t care	0 (false)

상기 [분기문 예]는 형식적으로 탐침을 삽입할 수 없는 형태를 갖고 있다. 따라서, 상기 [분기문 예]는 탐침을 삽입할 수 있는 형태로 변경해야 한다. 상기 [분기문 예]의 실질적인 의미는 변경하지 않으면서 탐침을 삽입할 수 있는 형태로 변경한 후 탐침을 삽입하면, 아래의 [분기문 변형 예1]과 같을 수 있다.

[분기문 변형 예1]

If ( ( A ? probe (m), 1 : probe (n), 0 ) && ( B ? probe(o), 1 : probe (p), 0 ) )

상기 [분기문 변형 예1]은 논리 연산자(&&)는 그대로 존재하고, 탐침을 삽입하기 위해 각 조건을 삼항 연산자로 변경하였다. 이렇게 변경하여도 상기 [분기문 예]와의 실질적인 의미는 동일하다. 이러한 상기 [분기문 변형 예1]는 내부에 분기점이 3개(?, &&, ?)가 존재하고, 총 4개의 탐침(m, n, o, p)이 존재한다.

상기 [분기문 예]의 다른 변형 예는 아래의 [분기문 변형 예2]와 같을 수 있다.

[분기문 변형 예2]

If ( A ? ( B ? probe (a), 1 : probe (b), 0 ) : probe (c), 0 )

상기 [분기문 변형 예2]는 논리 연산자(&&)를 삼항 연산자로 변경하였다. 이렇게 변경하여도 상기 [분기문 예]와의 실질적인 의미는 동일하다. 이러한 상기 [분기문 변형 예2]는 내부에 분기점이 2개(?, ?)이 존재하고, 총 3개의 탐침(a, b, c)이 존재한다.

상기 [분기문 변형 예2]는, 상기 [분기문 변형 예1]과 대비하였을 때, 조건을 삼항 연산자로 변경하는 것이 아니라, 논리 연산자를 삼항 연산자로 변경함으로써 분기점의 개수와 탐침의 개수를 각각 1개씩 더 줄일 수 있다. 분기점의 개수와 탐침의 개수는 코드 커버리지 측정을 위한 성능 부하를 결정하는 결정적인 요소이므로, 상기 [분기문 예]를 [분기문 변형 예1]이 아닌, [분기문 변형 예2]로 변경함으로써, 코드 커버리지 측정 성능을 향상시킬 수 있다.

도 4는 도 2에 도시된 소스 코드에 탐침을 삽입하는 방법을 구현할 수 있는 탐침 삽입 장치의 블록도이다.

도 4를 참조하면, 탐침 삽입 장치(400)는, 파서(410), 제어 흐름 그래프 생성기(430) 및 소스 코드 재기록기(450)를 포함할 수 있다.

파서(410)는 입력되는 소스 코드를 파싱하여 추상 구문 트리를 생성한다. 여기서, 파서(410)는 C/C++ 파서일 수 있다.

제어 흐름 그래프 생성기(430)는 파서(410)에서 출력된 추상 구문 트리를 입력으로 하여 이를 해석하여 제어 흐름 그래프(430)를 생성한다.

소스 코드 재기록기(450)는 제어 흐름 그래프 생성기(430)에서 출력된 제어 흐름 그래프와 파서(410)에서 출력된 추상 구문 트리를 이용하여 탐침이 삽입된 소스 코드를 출력한다. 제어 흐름 그래프와 추상 구문 트리를 이용하여 탐침을 삽입하는 방법은 도 2 내지 도 3에서 상세히 설명하였으므로, 이에 대한 설명은 생략하기로 한다.

도 5는 본 발명의 제2 실시 형태에 따른 코드 커버리지 측정 방법을 나타내는 순서도이다.

도 5에 도시된 제2 실시 형태에 따른 코드 커버리지 측정 방법은, 적어도 1회 이상 컴파일이 수행되었던 소스 코드(이하, ‘이전 소스 코드’)의 내용이 개발자나 기타 프로그램에 의해 변경된 경우에 있어서, 변경된 소스 코드의 코드 커버리지를 측정하는 방법에 관한 것이다.

도 5를 참조하면, 제2 실시 형태에 따른 코드 커버리지 측정 방법은, 기존에 컴파일을 수행하였던 소스 코드인지 여부를 판별하는 단계(10), 소스 코드에 탐침을 삽입하는 단계(100), 실행 파일을 생성하는 단계(300) 및 코드 커버리지를 측정하는 단계(500)를 포함할 수 있다.

여기서, 기존에 컴파일을 수행하였던 소스 코드인지 여부를 판별하는 단계(10)를 제외하고, 소스 코드에 탐침을 삽입하는 단계(100), 실행 파일을 생성하는 단계(300) 및 코드 커버리지를 측정하는 단계(500)는 도 1에 도시된 소스 코드에 탐침을 삽입하는 단계(100), 실행 파일을 생성하는 단계(300) 및 코드 커버리지를 측정하는 단계(500)와 동일하므로, 이하에서는 기존에 컴파일을 수행하였던 소스 코드인지 여부를 판별하는 단계(10)를 구체적으로 설명하도록 한다.

기존에 컴파일을 수행했던 소스 코드인지 여부를 판별하는 단계(10)는, 소스 코드에 탐침을 삽입(100)하기 전에, 해당 소스 코드가 기존에 컴파일 수행하여 실행 파일을 생성했던 것인지 여부를 판별하는 단계이다.

판별 결과, 해당 소스 코드가 기존에 컴파일을 수행하지 않았던 것이라면 기존 것과 다른 소스 코드로 인식하고 소스 코드에 탐침을 삽입(100)하고, 탐침이 삽입된 소스 코드를 컴파일하여 새로운 실행 파일을 생성(300)한다. 그리고, 새로운 실행 파일을 저장(400)한 후, 새로운 실행 파일의 코드 커버리지를 측정(500)한다.

한편, 판별 결과, 해당 소스 코드가 기존에 컴파일을 수행했던 것이라면, 기존에 컴파일을 수행하여 미리 저장된 실행 파일을 불러와 코드 커버리지를 측정하는 단계(500)로 이동한다. 그러면, 이하에서는, 변경된 소스 코드가 기존에 컴파일 수행했던 것인지를 어떻게 판별하는지를 도 6을 참조하여 설명하도록 한다.

도 6은 도 5에 도시된 해당 소스 코드가 기존에 컴파일 수행했던 소스 코드이지 여부를 판별하는 단계(10)를 구체화한 순서도이다.

도 6을 참조하면, 변경된 소스 코드가 기존에 컴파일 수행했던 소스 코드이지 여부를 판별하는 단계(10)는, 전처리된 소스 코드를 생성하는 단계(11), 노이즈를 제거하는 단계(12), 고유값을 생성하는 단계(13), 생성된 고유값이 이전 고유값과 동일한지 여부를 판별하는 단계(14) 및 미리 저장된 실행 파일을 출력하는 단계(15)를 포함할 수 있다. 여기서, 노이즈를 제거하는 단계(12)는 생략될 수도 있다.

전처리된 소스 코드를 생성하는 단계(11)는, 변경된 소스 코드를 전처리(preprocessing)하여 전처리된 소스 코드를 생성하는 단계이다.

여기서, 전처리된 소스 코드는 탐침을 삽입할 수 있는 또는 컴파일을 수행할 수 있는 형상이 고정된 소스 코드이다.

여기서, 전처리는, 변경된 소스 코드를 해석하여 포함 관계 및 매크로 정의를 반영한 컴파일용 소스 코드를 생성하는 과정을 의미한다. 포함 관계를 반영한다는 것은, 전처리의 대상인 변경된 소스 코드 내에 시스템 헤더(system header)나 사용자 헤더(user header)가 포함(include)된 경우, 변경된 소스 코드에 상기 시스템 헤더나 사용자 헤더를 삽입하는 것을 의미한다. 그리고, 매크로 정의를 반영한다는 것은, 변경된 소스 코드 내에 정의된 매크로를 매크로 정의를 따르는 확장 문자열로 치환하는 것을 의미한다.

노이즈를 제거하는 단계(12)는, 전처리된 소스 코드의 노이즈를 제거하는 단계이다. 여기서, 노이즈란, 전처리 시점에 의존하는 요소들을 의미한다. 전처리 시점에 의존하는 요소는, 예를 들면, 전처리가 수행된 시간에 관한 정보 및 날짜에 관한 정보일 수 있다. 이러한 노이즈는, 정규 표현식(regular expression)을 사용하여 제거할 수 있다. 여기서, 정규 표현식은 특정한 규칙을 가진 문자열의 집합을 표현하는데 사용하는 형식 언어를 의미한다.

고유값을 생성하는 단계(13)는, 노이즈가 제거된 전처리된 소스 코드에 대해 정규화를 수행하여 형상 식별이 가능한 고유값을 생성하는 단계이다. 정규화를 수행한다는 것은 해쉬 알고리즘(hash algorithm)을 사용하여 전처리된 소스 코드 전체의 고유값을 생성하는 것을 의미한다. 여기서, 해쉬 알고리즘은 MD5(Message-Digest algorithm 5) 함수를 이용할 수 있다. 소스 코드에 주석을 삽입한다거나 띄어쓰기를 하는 등의 실질적인 의미를 변경하는 것이 아닌 것에 의해서는 소스 코드 전체의 고유값은 변경되지 않는다.

생성된 고유값이 이전 고유값과 동일한지 여부를 판별하는 단계(14)는, 생성된 고유값이 소정의 저장소에 미리 저장된 이전 고유값과 동일한지 여부를 판별하는 단계이다. 여기서, 상기 소정의 저장소에는 소정의 고유값들과 그 고유값들 각각에 대응하는 실행 파일들이 저장되어 있다.

만약, 생성된 고유값이 이전 고유값과 동일하면, 상기 소정의 저장소에 저장된 실행 파일을 불러온다(15). 그리고, 불려온 실행 파일의 코드 커버리지를 측정(500)한다.

한편, 생성된 고유값이 이전 고유값과 다르면, 전처리된 소스 코드에 탐침을 삽입(100)한다. 그리고, 도 5에 도시된 바와 같이, 실행 파일을 생성(300)하고, 추후에 다시 이용할 수 있도록 생성된 실행 파일을 생성된 고유값과 함께 상기 소정의 저장소에 저장한다(400). 마지막으로, 생성된 실행 파일의 코드 커버리지를 측정(500)한다.

이와 같이, 도 5에 도시된 코드 커버리지 측정 방법은, 적어도 1회 이상 컴파일이 수행되었던 소스 코드가 개발자나 프로그램 등에 의해 변경된 경우에, 그 변경된 내용이 소스 코드의 실질적인 변경인지 아니면 실질적이지 않은 변경인지를 판별한 후, 그 변경된 내용이 실질적이지 않은 변경인 경우에는 기존에 컴파일이 수행되었던 실행 파일을 불러오고, 불려온 실행 파일의 코드 커버리지를 측정한다. 따라서, 적어도 1회 이상 컴파일 수행되었던 소스 코드에 주석이나 띄어쓰기 등과 같은 실질적인 변경이 이뤄진 경우에는, 변경된 소스 코드에 다시 탐침을 삽입한다거나 다시 실행 파일을 생성하는 과정을 다시 반복할 필요가 없다. 따라서, 적어도 1회 이상 컴파일 수행했던 소스 코드에 대해서는 코드 커버리지를 측정하기 위한 준비 시간을 단축할 수 있는 이점이 있다.

도 7은 본 발명의 제3 실시 형태에 따른 코드 커버리지 측정 방법을 나타내는 순서도이다.

도 7에 도시된 제3 실시 형태에 따른 코드 커버리지 측정 방법은, 적어도 1회 이상 코드 커버리지가 측정되었던 소스 코드(이하, ‘이전 소스 코드’)의 내용이 개발자나 기타 프로그램에 의해 변경된 경우에 있어서, 변경된 소스 코드의 코드 커버리지를 측정하는 방법에 관한 것이다.

도 7을 참조하면, 제3 실시 형태에 따른 코드 커버리지 측정 방법은, 변경된 소스 코드가 실질적으로 변경되었는지 여부를 판별하는 단계(20), 기존 코드 커버리지 값을 출력하는 단계(30), 코드 커버리지를 측정하는 단계(40) 및 변경된 함수의 고유값과 함수 커버리지 값을 저장하는 단계(50)를 포함할 수 있다.

변경된 소스 코드가 실질적으로 변경되었는지 여부를 판별하는 단계(20)는, 적어도 1회 이상 코드 커버리지를 측정했던 이전 소스 코드가 형식적인 변경이 아닌, 실질적으로 변경되었는지를 판별하는 단계이다.

판별 결과, 만약 변경된 소스 코드가 실질적으로 변경된 것이 아닌 경우에는, 변경된 소스 코드의 코드 커버리지 측정하지 않고, 기존에 측정했던 코드 커버리지 값을 불러와 출력한다(30).

한편, 변경된 소스 코드가 실질적으로 변경된 것이라면, 변경된 소스 코드의 코드 커버리지를 측정하고(40), 소스 코드 내에서 변경된 함수의 고유값과 함수 커버리지 값을 저장한다(50). 여기서, 변경된 함수의 고유값과 함수 커버리지 값은 추후에 다시 이용될 수 있도록 소정의 저장소에 저장될 수 있다.

이하에서는 도 8을 참조하여 변경된 소스 코드가 실질적으로 변경되었는지 여부를 어떻게 판별하는지를 구체적으로 설명하도록 한다.

도 8은 도 7에 도시된 변경된 소스 코드가 실질적으로 변경되었는지 여부를 판별하는 단계(20)를 구체화한 순서도이다.

도 8을 참조하면, 변경된 소스 코드가 기존에 코드 커버리지를 측정했던 것인지 여부를 판별하는 단계(20)는, 전처리된 소스 코드를 생성하는 단계(21), 노이즈를 제거하는 단계(22), 함수별 고유값을 생성하는 단계(23), 적어도 하나 이상의 변경된 함수가 존재하는지를 판별하는 단계(24) 및 변경된 함수와 변경되지 않은 함수를 분류하는 단계(25)를 포함할 수 있다. 여기서, 노이즈를 제거하는 단계(22)는 생략될 수도 있다.

전처리된 소스 코드를 생성하는 단계(21)와 노이즈를 제거하는 단계(22)는, 도 6에 도시된 전처리된 소스 코드를 생성하는 단계(11)와 노이즈를 제거하는 단계(12)와 동일하므로, 그 설명은 전술한 것으로 대체한다.

함수별 고유값을 생성하는 단계(23)는, 전처리된 소스 코드 내에 존재하는 복수의 함수들 별로 정규화를 수행하여 형상 식별이 가능한 함수별 고유값을 생성하는 단계이다. 따라서, 생성되는 함수별 고유값의 개수는 함수의 개수에 따라 결정된다. 여기서, 정규화를 수행한다는 것은 해쉬 알고리즘(hash algorithm)을 사용하여 전처리된 소스 코드 내의 복수의 함수들 별로 각각의 고유값을 생성하는 것을 의미한다. 특정 함수에 주석을 삽입한다거나 띄어쓰기를 하는 등의 실질적인 의미를 변경하는 것이 아닌 형식적인 변경에 의해서는 해당 함수의 고유값은 변경되지 않는다.

전처리된 소스 코드 내의 복수의 함수들 별로 고유값을 생성한 후, 복수의 함수들 중에서 적어도 하나 이상의 변경된 함수가 존재하는지 여부를 판별한다(24). 여기서, 변경된 함수가 존재하는지 여부는, 소정의 저장소에 미리 저장된 이전 소스 코드의 함수별 고유값들과 생성된 변경된 소스 코드의 함수별 고유값들을 일대일로 비교하여 판별할 수 있다.

판별 결과, 만약 변경된 소스 코드의 함수별 고유값들이 이전 소스 코드의 함수별 고유값들과 모두 동일하면, 기존 코드 커버리지 값을 출력한다(30).

한편, 변경된 소스 코드의 함수별 고유값들 중 적어도 하나 이상이 이전 소스 코드의 함수별 고유값들과 일치하지 않으면, 복수의 함수들을 변경된 함수와 변경되지 않은 함수를 분류하고(25), 코드 커버리지를 측정한다(40). 여기서, 코드 커버리지를 측정하는 단계(40)는, 변경되지 않은 함수의 함수 커버리지 값을 상기 소정의 저장소에서 불러와 변경된 소스 코드의 코드 커버리지를 계산한다.

제3 실시 형태에 따른 코드 커버리지 측정 방법을 종래의 코드 커버리지 측정 방법과 비교하면, 예를 들어, 이전 소스 코드는 100개의 함수를 포함하고, 상기 이전 소스 코드의 코드 커버리지 값은 100(%)이였는데, 상기 이전 소스 코드의 100개의 함수들 중 1개의 함수가 실질적으로 변경된 경우, 종래의 코드 커버리지 측정 방법에 의하면 코드 커버리지 값은 0(%) (왜냐하면, 종래의 코드 커버리지 측정 방법은 소스 코드가 실질적 또는 형식적으로 변경되면 새로운 소스 코드로 인식하기 때문에)이 되지만, 제3 실시 형태에 따른 코드 커버리지 측정 방법에 의하면 코드 커버리지 값은 0이 아닌 99가 출력된다. 따라서, 변경되지 않은 함수의 함수 커버리지는 그대로 유지되기 때문에, 추후에 변경되지 않은 함수를 다시 테스트하지 않아도 되는 이점이 있다.

도 9는 제4 실시 형태에 따른 코드 커버리지 측정 방법을 설명하기 위한 시스템도이다.

도 9를 참조하면, 제4 실시 형태에 따른 코드 커버리지 측정 방법이 수행되는 시스템은 복수의 장치들(910, 930)과 서버(950)를 포함할 수 있다.

복수의 장치들(910, 930)은 서버(950)로부터 전송되거나 사용자에 의해 직접 업로드된 소스 코드의 코드 커버리지를 측정할 수 있다.

복수의 장치들(910, 930) 각각은 로그 수집 에이전트를 포함할 수 있다.

로그 수집 에이전트는, 복수의 장치들(910, 930) 각각의 코드 커버리지 측정을 제어할 수 있다. 구체적으로, 로그 수집 에이전트는, 복수의 장치들(910, 930) 각각의 코드 커버리지 측정의 시작과 종료를 제어할 수 있으며, 복수의 장치들(910, 930) 각각의 코드 커버리지 측정 수행 현황 정보를 파악할 수 있다.

로그 수집 에이전트는 수집된 코드 커버리지 로그를 서버(950)로 전송할 수 있다. 여기서, 로그 수집 에이전트는 수집된 코드 커버리지 로그를 서버(950)의 갱신 요청에 따라 전송할 수도 있고, 서버(950)의 요청없이 미리 설정된 임의의 시점에 수집된 코드 커버리지 로그를 서버(950)로 자동 전송할 수도 있다. 여기서, 임의의 시점은 코드 커버리지 측정이 종료되었을 때일 수도 있고, 서버(950)가 요청한 임의의 시점일 수도 있다.

로그 수집 에이전트는 수집된 코드 커버리지 로그를 서버(950)로 전송하기 전에, 수집된 코드 커버리지 로그에 대해서 정규화를 수행하여 수집된 코드 커버리지 로그의 고유값을 생성할 수 있다. 그리고, 수집된 코드 커버리지 로그를 서버(950)로 전송할 때, 생성된 고유값도 함께 전송할 수 있다. 여기서, 고유값은 수집된 코드 커버리지 로그를 해쉬 알고리즘을 사용하여 생성된 형상 식별이 가능한 문자열일 수 있다.

복수의 장치들(910, 930)은 스마트폰, 태블릿 PC, 랩탑, 데스트탑 등일 수 있으며, 유선 또는 무선으로 서버(950)와 데이터 통신을 수행할 수 있다.

서버(950)는 복수의 장치들(910, 930)과 데이터 통신을 수행할 수 있다.

서버(950)는 복수의 장치들(910, 930)로부터 코드 커버리지 로그를 수신하고, 수신된 코드 커버리지 로그들을 저장하며, 저장된 코드 커버리지 로그들을 소정의 방법으로 취합하여 코드 커버리지를 측정할 수 있다.

서버(950)는 복수의 장치들(910, 930)로 코드 커버리지 로그를 요청하는 갱신 요청을 할 수 있다.

도 10을 참조하여, 서버(950)가 복수의 장치들(910, 930)에서 수집된 코드 커버리지 로그를 취합하여 코드 커버리지를 측정하는 방법을 구체적으로 설명하도록 한다.

도 10은 제4 실시 형태에 따른 코드 커버리지를 측정하는 방법을 설명하기 위한 순서도이다.

도 10을 참조하면, 제4 실시 형태에 따른 코드 커버리지 측정 방법은, 서버(950)가 복수의 장치들(910, 930)로부터 코드 커버리지 로그를 수신하는 단계, 서버(950)가 수신된 코드 커버리지 로그들을 저장하는 단계(951) 및 서버(950)가 저장된 코드 커버리지 로그들을 이용하여 코드 커버리지를 측정하는 단계(952)를 포함할 수 있다.

여기서, 서버(950)가 복수의 장치들(910, 930)로부터 코드 커버리지 로그를 수신하기 전에, 서버(950)가 복수의 장치들(910, 930)에게 코드 커버리지 로그를 달라는 갱신 요청을 할 수도 있다. 갱신 요청은 이 요청을 받은 현재의 코드 커버리지 로그를 달라는 요청일 수도 있고, 미래의 임의의 시점(특정 시간 또는 특정 시간대)에 코드 커버리지 로그를 달라는 요청일 수도 있다.

서버(950)가 수신된 코드 커버리지 로그들을 저장하는 단계(951)는, 서버(950)가 복수의 장치들(910, 930)로부터 수신되는 코드 커버리지 로그들을 대기열(queue)에 저장하는 단계일 수 있다.

서버(950)가 코드 커버리지를 측정하는 단계(952)는, 대기열에 저장된 코드 커버리지 로그들을 소정의 방법으로 취합하여 측정 대상 소스 코드의 코드 커버리지를 측정하는 단계일 수 있다.

서버(950)가 수신된 코드 커버리지 로그들을 저장하고(951), 코드 커버리지를 측정하는(952) 구체적인 방법을 두 가지 예를 들어 설명하도록 한다.

첫 번째 예는, 측정 대상인 소스 코드 전체가 복수의 장치들(910, 930)에서 각각 개별적으로 코드 커버리지 테스트가 수행된 후, 서버(950)가 복수의 장치들(910, 930)로부터 코드 커버리지 로그들을 수신한 경우이다.

두 번째 예는, 측정 대상인 소스 코드가 복수개로 나눠져 복수의 장치들(910, 930)로 분배되어 복수의 장치들(910, 930)에서 코드 커버리지 테스트가 수행된 후, 서버(950)가 복수의 장치들(910, 930)로부터 코드 커버리지 로그들을 수신한 경우이다.

첫 번째 예와 두 번째 예의 근본적인 차이점은, 복수의 장치들(910, 930)에서 테스트된 소스 코드들이 서로 동일한지 아니면 서로 다른 것인지 여부이다. 첫 번째 예는 복수의 장치들(910, 930)에서 테스트된 소스 코드들이 서로 동일한 경우이고, 두 번째 예는 복수의 장치들(910, 930)에서 테스트된 소스 코드들이 서로 다른 경우이다. 먼저, 첫 번째 예에 따른 코드 커버리지 측정 방법을 도 11을 참조하여 이하에서 설명하도록 한다.

도 11은 도 10에 도시된 코드 커버리지 측정 방법의 첫 번째 예를 설명하기 위한 도면이다.

도 11에 도시된 첫 번째 예는, 도 11의 (a)에 도시된 표와 같이, 특정 시점들(9:00, 9:10, 9:20)에서 제1 장치(910)로부터 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)를 수신하고, 제2 장치(930)로부터 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)를 수신한 경우를 예정한 것이다. 도 11의 (a)의 코드 커버리지 로그들 각각은 복수의 부분들을 포함하는데, 도면에서는 복수의 부분들을 박스들로 표현하였고, 체크된 박스는 코드 커버리지 테스트가 수행된 부분이고, 체크되지 않은 박스는 코드 커버리지 테스트가 수행되지 않은 부분이다. 제1 코드 커버리지 로그와 제2 코드 커버리지 로그는 동일한 소스 코드를 대상으로 한 것이기 때문에, 각 로그의 데이터의 길이는 동일한 것으로 가정하였다.

도 10에 도시된 서버(950)가 도 11의 (a)에 도시된 표와 같은 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)과 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)를 수신하면, 서버(950)는 대기열에 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)과 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)을 도 11의 (b)에 도시된 바와 같이 저장한다. 구체적으로, 대기열에는 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)과 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)이 서버(950)에 수신된 순서대로 저장된다. 편의상 도면에서는 제1 코드 커버리지 로그가 제2 코드 커버리지 로그보다 먼저 서버(950)에 수신되는 것으로 가정한다.

서버(950)의 대기열에 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)과 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)이 저장되면, 서버(950)는 저장된 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)을 취합하여 측정 대상 소스 코드의 코드 커버리지를 측정한다.

여기서, 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)을 취합하여 측정 대상 소스 코드의 코드 커버리지를 측정하는 하나의 방법은, 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)이 대기열에 저장되는 순서대로 차례대로 누적하여 상기 코드 커버리지를 측정하는 방법이다. 구체적으로, 제일 먼저 수신된 제1 코드 커버리지 로그 1(log_1-1)의 코드 커버리지 값(40%)을 계산하고, 다음으로 제1 코드 커버리지 로그 1(log_1-1)과 제2 코드 커버리지 로그 1(log_2-1)을 누적하여 코드 커버리지 값(60%)을 계산한다. 이러한 방법으로 마지막으로 저장된 제2 코드 커버리지 로그 3(log_2-3)까지 누적하여 코드 커버리지 값(100%)을 계산한다.

그러나, 상기 방법은 코드 커버리지 로그의 데이터 크고 긴 경우에 효율적이지 못하며 계산 시간이 너무 오래 걸린다는 문제가 있다. 따라서, 다음과 같은 방법으로 코드 커버리지 값을 계산하면, 더 효율적이고 신속하게 코드 커버리지 값을 계산할 수 있다.

코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)을 취합하여 측정 대상 소스 코드의 코드 커버리지를 측정하는 다른 방법은, 대기열에 저장된 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)과 동일한 데이터 크기를 갖는 가상의 코드 커버리지 로그를 만들고, 생성된 가상의 코드 커버리지 로그를 구성하는 복수의 부분들 각각에 대해서 코드 커버리지 테스트 여부를 판별한다.

구체적으로, 생성된 가상의 코드 커버리지 로그를 구성하는 복수의 부분들 각각에 대해서 코드 커버리지 테스트 여부를 판별하는 방법은, 모든 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)에서, 가상의 코드 커버리지 로그의 제1 부분과 대응되는 제1 부분들(1100)을 검색하고, 제1 부분들(1100) 중에서 하나라도 코드 커버리지 테스트된 것(체크된 것)이 존재하면, 가상의 코드 커버리지의 제1 부분은 테스트된 것으로 판별한다. 같은 방법으로 가상의 코드 커버리지의 모든 부분들에 대해서 테스트 여부를 판별하여 코드 커버리지 값을 계산한다. 이러한 방법에 의하면, 도 11의 (b)의 경우, 생성된 가상의 코드 커버리지 로그의 모든 부분들은 체크된 것으로 될 것이므로, 코드 커버리지 값은 100(%)이 될 것이다.

도 12은 도 10에 도시된 코드 커버리지 측정 방법의 두 번째 예를 설명하기 위한 도면이다.

도 12에 도시된 첫 번째 예는, 도 12의 (a)에 도시된 표와 같이, 특정 시점들(9:00, 9:10, 9:20)에서 제1 장치(910)로부터 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)를 수신하고, 제2 장치(930)로부터 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)를 수신한 경우를 예정한 것이다. 도 12의 (a)의 코드 커버리지 로그들 각각은 복수의 부분들을 포함하는데, 도면에서는 복수의 부분들을 박스들로 표현하였고, 체크된 박스는 코드 커버리지 테스트가 수행된 부분이고, 체크되지 않은 박스는 코드 커버리지 테스트가 수행되지 않은 부분이다. 제1 코드 커버리지 로그와 제2 코드 커버리지 로그는 서로 다른 소스 코드를 대상으로 한 것이기 때문에, 각 로그의 데이터의 길이는 서로 다른 것으로 가정하였다.

도 10에 도시된 서버(950)가 도 12의 (a)에 도시된 표와 같은 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)과 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)를 수신하면, 서버(950)는 대기열에 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)과 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)을 도 12의 (b)에 도시된 바와 같이 저장한다. 구체적으로, 대기열에는 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)과 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)이 서버(950)에 수신된 순서대로 저장된다. 편의상 제1 코드 커버리지 로그가 제2 코드 커버리지 로그보다 먼저 서버(950)에 수신되는 것으로 가정한다.

여기서, 도 12에 도시된 두 번째 예는 도 11에 도시된 첫 번째 예와는 달리 제1 코드 커버리지 로그와 제2 코드 커버리지 로그가 서로 다른 소스 코드를 대상으로 한 것이기 때문에 서로 다른 로그이다. 따라서, 도 12에 도시된 두 번째 예는, 대기열에 저장된 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)을 서로 같은 소스 코드를 대상으로 한 것들끼리 분류하는 단계가 코드 커버리지를 측정하기 앞서 수행되어야 한다.

여기서, 대기열에 저장된 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)을 서로 같은 소스 코드를 대상으로 한 것들끼리 분류하는 방법은, 고유값을 기준으로 분류할 수 있다. 도 10에 도시된 복수의 장치들(910, 930)은 서버(950)로 코드 커버리지 로그를 전송할 때, 코드 커버리지 로그와 함께 해당 코드 커버리지 로그의 고유값을 함께 전송할 수 있다. 상기 해당 코드 커버리지 로그의 고유값은 해쉬 알고리즘을 이용하여 생성될 수 있다. 상기 해당 코드 커버리지 로그의 고유값은 해당 코드 커버리지 로그 내의 복수의 부분들 각각이 테스트되었는지 여부와 상관없는 변하지 않는 고유의 값이다. 따라서, 서버(950)는 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)과 그들 각각의 고유값을 이용하여 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)을 서로 같은 소스 코드를 대상으로 한 것들끼리 분류할 수 있다. 이러한 방법으로 대기열에 저장된 모든 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)을 분류하면, 제1 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3)은 서로 같은 고유값을 갖고, 제2 코드 커버리지 로그들(log_2-1, log_2-2, log_2-3)도 서로 같은 고유값을 갖기 때문에, 서로 분류될 수 있다.

이렇게 대기열에 저장된 모든 코드 커버리지 로그들(log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3)은 고유값에 따라 분류된 후, 앞서 도 11에서 설명한 두 가지 방법으로 측정 대상 소스 코드의 코드 커버리지 값이 계산될 수 있다.

이상 설명된 실시 형태는 다양한 컴퓨터 구성요소를 통하여 실행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터로 판독가능한 기록매체에 기록될 수 있다. 상기 컴퓨터로 판독가능한 기록매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다.

상기 컴퓨터로 판독가능한 기록매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수도 있다.

컴퓨터로 판독가능한 기록매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM, DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 ROM, RAM, 플래시 메모리 등과 같은 프로그램 명령어를 저장하고 실행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 상기 하드웨어 장치는 본 발명에 따른 처리를 실행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.

이상 첨부된 도면을 참조하여 본 발명의 실시 형태를 설명하였으나 이는 단지 예시일 뿐 본 발명을 한정하는 것이 아니며, 본 발명이 속하는 분야의 통상의 지식을 가진 자라면 본 실시 형태의 본질적인 특성을 벗어나지 않는 범위에서 이상에 예시되지 않은 여러 가지의 변형과 응용이 가능함을 알 수 있을 것이다. 예를 들어, 실시 형태에 구체적으로 나타난 각 구성 요소는 변형하여 실시할 수 있는 것이다. 그리고 이러한 변형과 응용에 관계된 차이점들은 첨부된 청구범위에서 규정하는 본 발명의 범위에 포함되는 것으로 해석되어야 할 것이다.

Claims

소스 코드의 코드 커버리지를 측정하는 방법에 있어서,
탐침 삽입 장치가 상기 소스 코드에 탐침을 삽입하는 탐침 삽입 단계;
컴파일러가 상기 탐침이 삽입된 소스 코드를 컴파일하여 실행 파일을 생성하는 컴파일 단계; 및
코드 커버리지 측정 도구가 상기 생성된 실행 파일을 이용하여 상기 코드 커버리지를 측정하는 코드 커버리지 측정 단계;를 포함하고,
상기 탐침 삽입 단계는,
파서가 상기 소스 코드로부터 추상 구문 트리를 생성하는 추상 구문 트리 생성 단계;
제어 흐름 그래프 생성기가 상기 추상 구문 트리를 해석하여 제어 흐름 그래프를 생성하는 제어 흐름 그래프 생성 단계; 및
소스 코드 재기록기가 상기 추상 구문 트리와 상기 제어 흐름 그래프를 이용하여 상기 소스 코드에 상기 탐침을 삽입하는 재기록 단계;를 포함하고,
상기 재기록 단계는,
상기 제어 흐름 그래프에서 기저 경로들을 검색한 후, 각 기저 경로당 제1 탐침을 하나씩 삽입하는 제1 탐침 삽입 단계; 및
상기 추상 구문 트리 내의 분기문 중 상기 탐침의 삽입을 생략할 수 있는 분기문을 판별하고, 상기 판별된 분기문의 형태를 삼항 연산자 형태로 변경하여 제2 탐침을 삽입하는 제2 탐침 삽입 단계;
를 포함하는, 코드 커버리지 측정 방법.
삭제
제 1 항에 있어서,
상기 판별된 분기문은, 2개 이상의 조건이 논리 연산자로 결합된 것을 포함하고,
상기 제2 탐침 삽입 단계는, 상기 논리 연산자를 상기 삼항 연산자로 대체하는, 코드 커버리지 측정 방법.
소스 코드의 코드 커버리지를 측정하는 방법에 있어서,
탐침 삽입 장치가 상기 소스 코드에 탐침을 삽입하는 탐침 삽입 단계;
컴파일러가 상기 탐침이 삽입된 소스 코드를 컴파일하여 실행 파일을 생성하는 컴파일 단계; 및
코드 커버리지 측정 도구가 상기 생성된 실행 파일을 이용하여 상기 코드 커버리지를 측정하는 코드 커버리지 측정 단계;를 포함하고,
상기 탐침 삽입 단계 이전에, 상기 소스 코드가 기존에 컴파일을 수행하였던 것인지 여부를 판별기에 의해 판별하는 판별 단계를 더 포함하고,
상기 판별 단계에서, 상기 소스 코드가 기존에 컴파일을 수행하였던 것으로 판별되면, 상기 탐침 삽입 단계와 상기 컴파일 단계는 생략되고, 상기 코드 커버리지 측정 단계는 기존 실행 파일을 재사용하여 상기 코드 커버리지를 측정하는, 코드 커버리지 측정 방법.
제 4 항에 있어서,
상기 판별 단계는,
상기 소스 코드를 전처리하여 전처리된 소스 코드를 생성하는 단계;
상기 전처리된 소스 코드의 노이즈를 제거하는 단계;
상기 노이즈가 제거된 전처리된 소스 코드의 고유값을 생성하는 단계; 및
상기 생성된 고유값이 미리 저장된 이전 고유값과 동일한지 여부를 판별하는 단계;를 포함하고,
상기 생성된 고유값이 상기 이전 고유값과 동일하면, 상기 소스 코드가 기존에 컴파일을 수행하였던 것으로 판별하고,
상기 생성된 고유값이 상기 이전 고유값과 다르면, 상기 소스 코드가 기존에 컴파일을 수행하지 않았던 것으로 판별하는, 코드 커버리지 측정 방법.
소스 코드의 코드 커버리지를 측정하는 방법에 있어서,
상기 소스 코드가 실질적으로 변경되었는지 여부를 판별기가 판별하는 판별 단계;
상기 소스 코드가 실질적으로 변경되었으면, 코드 커버리지 도구가 변경된 소스 코드의 코드 커버리지를 측정하는 측정 단계; 및
상기 소스 코드가 실질적으로 변경되지 않았으면, 상기 판별기가 저장소에 저장된 기존 코드 커버리지 값을 불러와 출력하는 출력 단계;
를 포함하는, 코드 커버리지 측정 방법.
제 6 항에 있어서,
상기 판별 단계는,
상기 소스 코드를 전처리하여 전처리된 소스 코드를 생성하는 단계;
상기 전처리된 소스 코드 내의 함수별 고유값들을 생성하는 단계;
상기 생성된 함수별 고유값들을 미리 저장된 기존 함수별 고유값들과 비교하여 적어도 하나 이상의 변경된 함수가 존재하는지 여부를 판별하는 단계; 및
상기 생성된 함수별 고유값들 중 적어도 하나 이상이 변경되었으면, 변경된 함수와 변경되지 않은 함수를 분류하는 단계;를 포함하고,
상기 측정 단계는, 상기 변경되지 않은 함수의 함수 커버리지 값을 불러와 상기 변경된 소스 코드의 코드 커버리지를 계산하는, 코드 커버리지 측정 방법.
삭제
삭제
제 1 항 및 제 3 항 내지 제 7 항 중 어느 하나의 항에 따른 코드 커버리지 측정 방법을 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체.