KR101004615B1 - 소프트웨어 인증 장치 및 방법 - Google Patents

Abstract

본 발명은 소프트웨어 인증에 관한 것이다.

본 발명의 일 실시예에 따른 소프트웨어 인증 방법은, 소프트웨어를 테스트하고 상기 테스트 결과에 기초하여 상기 소프트웨어를 인증하는 방법으로서, 테스트 프로젝트 정보를 생성하는 단계; 상기 테스트 프로젝트 정보에 기초하여 고유코드를 생성하는 단계; 상기 소프트웨어의 테스트가 수행되는 단계; 상기 소프트웨어의 테스트 결과를 상기 고유코드와 함께 압축하는 단계;

상기 압축된 테스트 결과를 공개키를 이용하여 암호화하는 단계; 상기 암호화된 테스트 결과를 상기 공개키를 이용하여 해독하는 단계; 상기 압축된 테스트 결과를 압축 해제하는 단계; 상기 테스트 결과를 검증하는 단계; 상기 테스트 결과를 분석하여 인증 여부를 판정하는 단계; 및 상기 인증 여부 판정 결과에 기초하여 인증서를 생성하는 단계를 포함한다.

소프트웨어, 테스트, 인증

Description

소프트웨어 인증 장치 및 방법{APPARATUS AND METHOD FOR AUTHENTICATING A SOFTWARE}

본 발명은 소프트웨어 인증에 관한 것이다.

국내에서 소프트웨어 인증 제도로는 산업용 소프트웨어 국제표준 적합성 인증 제도가 있다. 이것은 국내에서 개발된 산업용 소프트웨어의 품질 수준을 국제적 수준으로 향상시키기 위하여 국제표준(ISO/IEC 12119, 9126-2)에서 요구하는 소프트웨어 평가기술을 국내기업에 보급 및 확산하여 제조 산업 경쟁력 강화를 위한 인증 제도이다. 국제표준에서 규정하는 품질 평가 기준에 따라 신청 소프트웨어의 적합성 시험평가를 실시하여 적합한 경우 ES(Excellent software) 마크를 부여한다.

산업용 소프트웨어 국제표준 적합성 인증 제도의 인증 대상은 국내에서 3년 이내에 자체적으로 개발한 산업용 소프트웨어이다. 산업용 소프트웨어란 제조업의 생산 공정을 감시 및 제어하는 소프트웨어, 디지털 전자 제품 및 산업용 기기에 내장되어 핵심 기능을 수행하는 임베디드(embedded) 소프트웨어 등을 포함한다.

소프트웨어의 평가 절차는 인증 신청, 사전조사, 1차 인증위원회 심의, 현장 실사, 제품 시험, 2차 인증위원회 심의, 인증서 발급의 단계를 포함한다. 여기서, 제품 시험은 전문 시험 평가 기관에서 실시한다. 제품 시험을 위해 개발 업체는 전문 시험 평과 기관에 개발한 소프트웨어를 제출하고, 평가 기관에서 해당 소프트웨어를 테스트한다. 평가 결과 등 기타 사항을 종합적으로 판단하여 인증이 적합한 제품에 대하여 인증서를 발급한다.

이와 같은 소프트웨어 인증 제도를 이용하기 위해서는 상당한 비용과 기간이 소요된다. 또한, 소프트웨어 국제표준 적합성 인증 제도는 특정 소프트웨어를 대상으로 하고 있으므로, 산업용 소프트웨어가 아닌 경우에 인증을 받을 수 없다.

또한, 소프트웨어 인증을 받기 위해서는 인증 기관에 소프트웨어 자체를 제공해야 하므로, 인증 기관을 통한 소프트웨어 유출의 위험성이 있다.

본 발명은 소프트웨어 인증을 위해, 소프트웨어를 인증 기관에 제출하는 것이 아니라, 소프트웨어 개발자가 직접 테스트를 수행하고 그 테스트 결과를 제출함으로써 인증을 받을 수 있는 인증 장치 및 방법을 제공하는 것을 목적으로 한다.

또한, 소프트웨어 개발자가 직접 수행한 소프트웨어 테스트의 신뢰성을 확보할 수 있는 인증 장치 및 방법을 제공하는 것을 목적으로 한다.

또한, 소프트웨어에 대한 인증서가 그 소프트웨어에 대한 진정한 인증서인지 여부를 확인할 수 있는 인증서 검증 장치 및 방법을 제공하는 것을 목적으로 한다.

본 발명의 일 실시예에 따른 소프트웨어 인증 방법은, 소프트웨어를 테스트하고 상기 테스트 결과에 기초하여 상기 소프트웨어를 인증하는 방법으로서, 테스트 프로젝트 정보를 생성하는 단계; 상기 테스트 프로젝트 정보에 기초하여 고유코드를 생성하는 단계; 상기 소프트웨어의 테스트가 수행되는 단계; 상기 소프트웨어의 테스트 결과를 상기 고유코드와 함께 압축하는 단계;

상기 압축된 테스트 결과를 공개키를 이용하여 암호화하는 단계; 상기 암호화된 테스트 결과를 상기 공개키를 이용하여 해독하는 단계; 상기 압축된 테스트 결과를 압축 해제하는 단계; 상기 테스트 결과를 검증하는 단계; 상기 테스트 결과를 분석하여 인증 여부를 판정하는 단계; 및 상기 인증 여부 판정 결과에 기초하여 인증서를 생성하는 단계를 포함한다.

본 발명의 다른 일 실시예에 따른 소프트웨어 테스트 시스템은, 테스트할 소프트웨어의 테스트 프로젝트 정보를 생성하는 테스트 프로젝트 정보 생성 모듈; 상기 소프트웨어가 소정의 규칙을 만족하는지 여부를 판정하고, 테스트 커버리지를 측정하는 테스트 수행 모듈; 상기 테스트 결과를 미리 설정된 고유코드를 포함하여 압축하는 압축 모듈; 상기 압축된 테스트 결과를 미리 설정된 공개키에 기초하여 암호화하는 암호화 모듈; 및 상기 압축 및 암호화된 테스트 결과를 전송하는 송수신 모듈을 포함한다.

본 발명의 또 다른 일 실시예에 따른 소프트웨어 인증 시스템은, 테스트할 소프트웨어의 테스트 프로젝트 정보에 기초한 고유코드 및 공개키를 생성하는 고유코드 및 공개키 생성 모듈; 상기 공개키에 기초하여 암호화된 상기 소프트웨어의 테스트 결과를 상기 공개키를 이용하여 해독하는 해독 모듈; 상기 해독된 테스트 결과를 압축 해제하는 압축 해제 모듈; 상기 압축 해제된 테스트 결과를 상기 고유코드를 이용하여 검증하는 테스트 결과 검증 모듈; 상기 압축 해제된 테스트 결과가 소정의 기준을 만족하는지 여부를 판정하는 테스트 결과 분석 모듈; 상기 테스트 결과 분석에 기초하여 상기 소프트웨어에 대한 인증을 생성하는 인증 생성 모듈; 상기 고유코드 및 공개키, 상기 테스트 결과, 상기 인증을 송수신하기 위한 송수신 모듈; 및 상기 고유코드 및 공개키를 저장하는 데이터베이스를 포함한다.

본 발명의 또 다른 일 실시예에 따른 소프트웨어 인증서 검증 방법은, 소프트웨어 테스트 시스템에 의해 테스트된 소프트웨어를 수신하는 소프트웨어 수신 단계; 소프트웨어 인증서를 수신하는 인증서 수신 단계; 상기 소프트웨어에 대해 인 증한 인증 시스템으로부터 상기 소프트웨어에 대한 정보를 수신하는 단계; 및 상기 인증 시스템으로부터 수신한 상기 정보에 기초하여, 상기 수신된 인증서가 상기 테스트된 소프트웨어에 대한 진정한 인증서인지 여부를 검증하는 인증서 검증 단계를 포함한다.

여기서, 바람직하게는, 상기 인증 시스템으로부터 수신하는 상기 정보는, 상기 소프트웨어의 테스트 프로젝트 정보 및 상기 소프트웨어의 인증 정보를 포함한다.

여기서, 바람직하게는, 상기 인증서 검증 단계는, 상기 수신한 소프트웨어로부터 소프트웨어 정보를 추출하는 단계; 상기 인증 시스템으로부터 수신한 상기 테스트 프로젝트 정보와 상기 소프트웨어 정보를 비교하는 단계; 및 상기 인증 시스템으로부터 수신한 상기 인증 정보에 기초하여 상기 수신된 인증서가 유효한 인증서인지 여부를 확인하는 단계를 포함한다.

본 발명의 또 다른 일 실시예에 따른 소프트웨어 인증서 검증 시스템은, 소프트웨어 개발자로부터 소프트웨어 및 인증서를 수신하고, 인증 시스템으로부터 소프트웨어 정보 및 인증 정보를 수신하는 송수신 모듈; 상기 소프트웨어 개발자로부터 수신된 소프트웨어로부터 소프트웨어 정보를 추출하는 소프트웨어 정보 추출 모듈; 상기 인증 시스템으로부터 수신된 소프트웨어 정보와 상기 소프트웨어 정보 추출 모듈에 의해 추출된 소프트웨어 정보를 비교하는 소프트웨어 정보 비교 모듈; 및 상기 수신된 인증서가 상기 인증 시스템에 등록되어 있는 유효한 인증서인지 여부를 확인하는, 인증서 확인 모듈을 포함한다.

본 발명에 의하면, 소프트웨어 자체를 인증 기관에 제출하지 않고 인증을 받을 수 있으므로, 소프트웨어의 보안성을 향상시킬 수 있다. 또한, 인증 기관이 직접 소프트웨어 테스트를 수행하는 것이 아니라 소프트웨어 개발자가 직접 테스트를 수행할 수 있기 때문에, 인증 기관의 업무 적체를 해소할 수 있어 인증에 소요되는 기간 및 비용을 크게 절감할 수 있다.

또한, 본 발명에 의하면, 소프트웨어 개발자가 직접 소프트웨어 테스트를 수행하더라도 충분한 테스트를 보장할 수 있으므로, 인증의 신뢰성을 향상시킬 수 있다.

또한, 본 발명에 의하면, 소프트웨어에 대한 인증서가 그 소프트웨어에 대한 진정한 인증서인지 여부를 확인할 수 있으므로, 인증의 신뢰성을 향상시킬 수 있다.

도 1은 본 발명에서 이용하는 소프트웨어 인증의 개념을 설명하기 위한 개념도이다. 소프트웨어 개발사(10)에서 소프트웨어를 개발하면, 인증 업체(20)로부터 소프트웨어에 대해 인증을 받는다. 이때, 인증 업체(20)는 소프트웨어 구매사(30)가 미리 지정한 것일 수도 있다. 소프트웨어 구매사(30)는 인증 업체(20)로부터 인증을 받은 소프트웨어를 신뢰하고 구매한다.

소프트웨어 구매사(30)는 소프트웨어 구매 이전에 인증 업체(20)를 통해 소프트웨어의 충분한 테스트를 보장받을 수 있으므로 소프트웨어 구매 이후에 소프트 웨어의 오류로 인한 손실을 방지할 수 있다. 또한 소프트웨어 구매사(30)는 직접 구매한 소프트웨어의 테스트를 수행할 필요가 없으므로 구매한 소프트웨어를 바로 사용할 수 있어 시간 및 비용을 절감할 수 있다.

소프트웨어 개발사(10)는, 소프트웨어 구매사(30)에 소프트웨어를 판매하기 이전에 인증 업체(20)에 소프트웨어를 제공하는 경우 소프트웨어가 공중에 노출될 수도 있기 때문에, 인증 업체(20)에 대해 소프트웨어 자체를 제공하는 것을 꺼릴 수 있다. 따라서, 본 발명에서는, 인증 업체(20)가 소프트웨어 개발사(10)에 테스트 툴(test tool), 예를 들어, 테스트 툴을 제공하고, 소프트웨어 개발사(10)가 직접 테스트를 수행한다. 소프트웨어 개발사(10)가 직접 소프트웨어를 테스트하기 때문에, 인증 업체(20)로서도 소프트웨어 테스트에 필요한 비용을 대폭 절감할 수 있다.

인증 업체(20)는 인증에 필요한 기준을 미리 정한다. 이때 인증 기준은 소프트웨어 구매사(30)가 정한 것일 수도 있고, 인증 업체(20)와 소프트웨어 구매사(30)가 협의하여 정한 것일 수도 있다. 인증 업체(20)는 네트워크(40)를 통해 소프트웨어 테스트에 필요한 테스트 툴을 소프트웨어 개발사(10)로 전송한다. 소프트웨어 개발사(10)는 그 테스트 툴을 이용하여 개발한 소프트웨어를 테스트한다. 소프트웨어 테스트가 완료되면 소프트웨어 개발사(10)는 그 결과를 네트워크(40)를 통해 인증 업체(20)로 전송한다. 인증 업체(20)는 테스트 결과를 이용하여 인증 여부를 결정한다. 인증을 부여하기로 결정한 경우, 인증 업체(20)는 네트워크(40)를 통해 소프트웨어 개발사(10)에 인증서를 전송한다.

소프트웨어 개발사(10)는 개발한 소프트웨어를 인증서와 함께 소프트웨어 구매사(30)에 제공한다. 소프트웨어 구매사(30)는 인증서가 유효하고 진정한 인증서인지 여부를 인증 업체(20)에 확인할 수 있다.

여기서, 네트워크(40)는 인터넷, 인트라넷, 무선 통신망 중 어느 하나일 수 있다. 소프트웨어 개발사(10), 인증 업체(20), 소프트웨어 구매사(30) 사이의 정보, 데이터, 소프트웨어 등의 전송은 네트워크(40)를 통해 이루어질 수 있으므로 소프트웨어 인증에 필요한 시간을 대폭 절감할 수 있다.

[본 발명에 따른 소프트웨어 인증 방법]

도 2를 참조하여 본 발명의 일 실시예에 따른 소프트웨어 인증 방법을 상세히 설명한다. 도 2는 본 발명에 따른 소프트웨어 인증 방법을 모식적으로 나타낸 도면이다.

본 발명에 따른 소프트웨어 인증 방법은 테스트 시스템(210) 및 인증 시스템(310)에 의해 수행된다. 테스트 시스템(210) 및 인증 시스템(310)에 관하여는 후술하도록 한다. 도 2를 참조하면, 우선, 테스트 시스템(210)에 의해 테스트가 수행되고 (S10), 이 테스트 결과가 인증 시스템(310)으로 전송되고 (S12), 인증 시스템(310)에서 테스트 결과가 분석되고 (S14), 인증 시스템(310)에서 소프트웨어에 대한 인증이 부여된다 (S16).

본 발명의 일 실시예에 따른 소프트웨어 인증 방법은, 소프트웨어 테스트를 수행하는 동안 소프트웨어가 실행된 커버리지를 구하는 단계, 소프트웨어가 미리 정해진 테스트 규칙을 모두 만족하는지 여부를 판정하는 단계, 커버리지 및 규칙 만족 여부에 기초하여 소프트웨어에 인증을 부여하는 단계를 포함한다.

테스트가 수행되는 동안 (S10), 소프트웨어가 실행된 커버리지가 측정되고, 또한, 테스트에 의해 소프트웨어가 미리 정해진 테스트 규칙을 모두 만족하는지 여부가 판정된다. 즉, 테스트 수행 단계 (S10)는 소프트웨어 테스트를 수행하는 동안 소프트웨어가 실행된 커버리지를 구하는 단계 및 소프트웨어가 미리 정해진 테스트 규칙을 모두 만족하는지 여부를 판정하는 단계를 포함한다. 그 후, 테스트 결과, 즉, 측정된 테스트 커버리지 및 테스트 규칙 만족 여부를 분석하여 (S14) 소정의 기준에 부합하는 경우 소프트웨어에 대해 인증이 부여된다 (S16).

도 1에 나타낸 바와 같이, 테스트 수행 주체와 테스트 결과 분석 주체가 다른 경우에는, 테스트 수행(S10)과 테스트 결과 분석(S14) 사이에, 테스트 결과 전송 단계 (S12)가 포함될 수도 있다.

<커버리지>

본 발명에 따른 소프트웨어 인증 방법에서 측정하는 커버리지에 관하여 상세히 설명하도록 한다. 테스트 커버리지란 소프트웨어가 테스트되고 난 후, 전체 소프트웨어 코드 내에서 테스트된 부분의 비율을 나타내는 값이다. 소프트웨어 테스트 결과의 신뢰성을 확보하기 위해서는, 소프트웨어에 포함된 모든 문장들(statement), 소프트웨어에 포함된 모든 함수들(function)이 실행되는 것이 바람직하고, 또한, 소프트웨어가 수행될 때 가능한 모든 분기문, 조건문 등이 완벽하게 테스트 되는 것이 바람직하다. 하지만, 현실적으로 이러한 것들 전부가 모두 완벽하게 테스트되는 것은 시간적, 비용적인 한계가 있으므로, 일정 비율 이상의 테스트 커버리지가 달성되면 테스트 결과를 신뢰할 수 있다고 본다.

테스트 커버리지의 종류로는, 1) 문장 커버리지 (statement coverage), 2) 조건 커버리지 (condition coverage), 3) 함수 커버리지(function coverage) 등이 있다.

문장 커버리지란 소프트웨어 소스코드(source code)의 전체 문장 중에서 테스트 동안 실행된 문장의 비율을 나타내는 값이다. 조건 커버리지란 소프트웨어에서 가능한 모든 조건문 중 테스트 동안 수행된 조건문의 비율을 나타내는 값이다. 함수 커버리지란 소프트웨어에 포함된 전체 함수 중 테스트 동안 실행된 함수의 비율을 나타내는 값이다. 그 밖에도, 분기 커버리지, 경로 커버리지 등이 있다. 분기 커버리지란 소프트웨어에서 가능한 모든 분기 중 테스트 동안 수행된 분기의 비율을 나타내는 값이다. 경로 커버리지란 분기, 조건 등을 포함하여 소프트웨어에서 가능한 모든 경로 중 테스트 동안 수행된 경로의 비율을 나타내는 값이다.

본 발명의 일 실시예에 따른 소프트웨어 인증 방법에서는, 이들 커버리지의 임의의 조합 중 어느 하나가 미리 설정된 값 이상인 경우에만 소프트웨어에 인증을 부여한다. 예를 들어, 사용자에 의해, 문장 커버리지가 80% 이상인 경우에만 인증을 부여하는 것으로 설정된 경우, 소프트웨어의 테스트 동안 소프트웨어의 전체 문장 중 실행된 문장의 비율이 80% 이상인 경우에만 인증을 부여한다. 혹은, 문장 커버리지가 80% 이상, 함수 커버리지가 90% 이상인 경우에만 인증을 부여하는 것으로 설정된 경우, 소프트웨어의 테스트 동안 소프트웨어의 전체 문장 중 실행된 문장의 비율이 80% 이상이고, 소프트웨어에 테스트 동안 소프트웨어의 전체 함수 중 실행된 함수의 비율이 90% 이상인 경우에만 인증을 부여한다. 인증을 위해 필요한 커버리지의 종류 및 특정 커버리지가 몇 퍼센트 이상인 경우에 인증을 부여할지는, 인증을 부여하는 인증 시스템의 사용자에 의해 임의로 설정될 수 있다.

문장 커버리지 측정 방법은, 소프트웨어의 테스트가 개시되면 소프트웨어의 소스코드의 문장마다 프로브(probe)를 삽입하고, 소프트웨어 테스트 동안 특정 문장이 수행될 때 마다, 그 문장에 삽입된 프로브의 정보를 파악한다. 그리고, 소프트웨어 테스트가 종료되면 소프트웨어에 삽입된 전체 프로브 중에서 실행된 문장의 프로브의 비율을 파악하여 문장 커버리지를 측정한다.

마찬가지로, 조건 커버리지 측정 방법은, 소프트웨어의 테스트가 개시되면 소프트웨어의 소스코드의 조건문마다 프로브를 삽입하고, 소프트웨어 테스트 동안 특정 조건문이 수행될 때 마다, 그 조건문에 삽입된 프로브의 정보를 파악한다. 그리고, 소프트웨어 테스트가 종료되면 소프트웨어의 조건문마다 삽입된 전체 프로브 중에서 실행된 조건문의 프로브의 비율을 파악하여 조건 커버리지를 측정한다.

마찬가지로, 함수 커버리지는 소프트웨어의 테스트가 개시되면 소프트웨어의 함수마다 프로브를 삽입하고, 소프트웨어 테스트 동안 특정 함수가 수행될 때마다 그 함수에 삽입된 프로브의 정보를 파악한다. 그리고, 소프트웨어 테스트가 종료되면 소프트웨어의 함수마다 삽입된 프로브 중에서 실행된 함수의 프로브의 비율을 파악하여 함수 커버리지를 측정한다.

본 발명에서와 같이, 소프트웨어의 인증 기준으로써, 테스트 규칙을 만족하는지 여부를 확인할 뿐만 아니라, 테스트 동안 소프트웨어가 실행된 커버리지를 구하고, 그 커버리지에 기초하여 소프트웨어에 인증을 부여함으로써, 소프트웨어 인증의 신뢰성을 더욱 향상시킬 수 있다. 또한, 테스트 커버리지를 인증 기준에 포함시킴으로써, 인증을 부여하는 인증 시스템과 소프트웨어 테스트를 수행하는 테스트 시스템을 별개로 두는 것이 가능하다.

예를 들어, 소프트웨어 개발자(10)가 직접 소프트웨어 테스트를 수행하고, 테스트 결과를 인증 업체(20)에 전송하고, 그 테스트 결과에 기초하여 인증을 부여한 경우에, 소프트웨어 개발자(10)는 소프트웨어 중 일부만을 실행하여 양호한 테스트 결과를 얻은 경우에 그 결과에 기초하여 인증을 받고자 하려고 할 수 있다. 따라서, 테스트 커버리지가 일정 수준 이상인 경우에만 인증을 부여함으로써 소프트웨어 개발자(10)가 소프트웨어 테스트를 직접 수행하더라도 충분한 테스트를 수행하게 함으로써, 테스트 결과 및 그에 기초한 인증의 신뢰성을 향상시킬 수 있다.

테스트 커버리지를 측정하는 방법 중 한가지 방법으로서, 소프트웨어가 프로세서에 의해 실행되는 동안 소프트웨어에 프로브를 삽입하는 단계, 소프트웨어의 테스트 종료 후, 소프트웨어에 삽입된 프로브에 기초하여 소프트웨어가 실행된 커버리지를 판단하는 단계를 포함하는 방법을 이용할 수 있다.

<테스트 규칙>

본 발명에 따른 인증 방법에 따라, 개발된 소프트웨어가 테스트 규칙을 만족하는지 여부를 판정하여 인증을 부여함으로써, 다양한 개발자에 의해 개발된 소프트웨어를 신뢰할 수 있는 기준을 마련할 수 있다. 즉, 이와 같이 인증을 부여받은 소프트웨어는 미리 정해진 테스트 규칙을 모두 만족하는 것으로 신뢰할 수 있으므로, 소프트웨어 구매사(30)는 인증을 받은 소프트웨어를 신뢰하고 구입, 이용할 수 있다.

이하, 본 발명에 따른 인증 방법의 테스트 규칙과, 소프트웨어가 이러한 테스트 규격에 부합하는지 여부를 판정하는 방법 및 그 판정 장치에 관하여 상세히 설명한다.

본 발명의 일 실시예 따라 소프트웨어에 대해 인증을 부여하기 위한 코딩 규칙을 규격을 도 3에 나타내었다. 도 3에 나타낸 규칙은 WIPI(Wireless Internet Platform for Interoperability) 표준규격을 만족하기 위한 규칙 중 일부를 나타낸 것이다. WIPI는 한국무선인터넷 표준화 포럼(KWISF; Korea Wireless Internet Standardization Forum)의 모바일 플랫폼(mobile platform) 특별 분과에서 만든 모바일 플랫폼 표준규격으로서 무선 인터넷을 통해 다운로드 된 응용소프트웨어를 이동통신 단말기에 탑재시켜 실행 시키기 위한 환경을 제공하는데 필요한 표준규격이다.

도 3에 나타낸 규칙은 프로그래밍 언어가 C 언어인 경우의 규칙이지만 본 발명이 특정 언어에 한정되는 것은 아니므로, 도 3에 나타낸 규칙은 예시적인 본 발명의 일 실시예임을 당업자는 명확히 이해할 수 있을 것이다. 또한, 도 3에 나타낸 규칙들의 임의의 조합이 소프트웨어 인증에 이용될 수 있다. 또한, 본 발명의 사상의 범위 내에서 소프트웨어 인증을 위해 추가적인 규격이 이용될 수도 있다. 이하, 도 3에 나타낸 규칙을 설명함과 동시에 이러한 규칙을 만족하는지 여부를 판정하는 방법에 관하여 상세히 설명한다.

<필수 C API 함수 구현>

WIPI-C는 필수 함수를 구현할 것을 정하고 있다. 따라서, 본 발명에 따른 소프트웨어 검사기는 이하의 함수들이 테스트되는 소프트웨어에 구현되어 있는지 여부를 검사한다.

void handleCletEvent(int type, int param1, int param2)

void startClet(int argc, char *argv[])

void pauseClet()

void resumeClet()

void destroyClet()

void paintClet(int x, int y, int w, int h)

예를 들어, handleCletEvent 함수가 구현되어 있는지 여부를 확인하기 위해, 소프트웨어 소스코드를 스캔하면서 handleCletEvent 라는 문자열이 포함되어 있는지 여부를 확인하고, 그러한 문자열이 소스코드에 포함되어 있지 않는 경우, 해당 소프트웨어가 WIPI 규격을 만족하지 않는 것으로 판단하고, 소스코드에 포함되어 있지 않는 함수를 로그에 기록한다. 나머지 함수들에 대해서도 마찬가지의 작업을 수행한다.

후술하는 소프트웨어 인증 장치(200)에서, 이와 같이 테스트 대상 소프트웨어에 필수 함수가 구현되어 있는지 여부의 확인은 필수 함수 검사기(232)에 의해 수행된다.

<커널 함수>

WIPI에서는, 메모리의 효율적인 관리를 위하여 메모리의 고정(static)할당과, 동적(dynamic)할당을 지원한다. 또한 동적으로 할당된 메모리는 컴팩션(compaction)을 지원할 수 있다. 고정 할당되는 메모리는 소프트웨어 로딩 시 메모리에 할당되며, 소프트웨어 수행 중에는 해제될 수 없고, 소프트웨어 종료 시에 자동으로 해제된다. 동적 할당되는 메모리는 소프트웨어 수행 중에 MC_knlAlloc() 또는 MC_knlCalloc() API에 의해 할당되며, 수행 중에 MC_knlFree() API를 통해 해제할 수 있다.

따라서, MC_knlAlloc() 또는 MC_knlCalloc() API에 의해 메모리가 할당된 경우, 소프트웨어 오류를 방지하기 위해 반드시 MC_knlFree() 함수에 의해 메모리가 해제되어야 한다. 본 발명에 따른 소프트웨어 검사기는 소프트웨어 소스코드에서 MC_knlAlloc()와 MC_knlFree()가 쌍을 이루어 존재하고, MC_knlCalloc()와 MC_knlFree()가 쌍을 이루어 존재하는지 여부를 확인한다. 즉, 한 함수가 소스코드 내에 존재하는 경우 다른 함수도 소스코드 내에 반드시 존재해야 한다. 그렇지 않은 경우, WIPI 규격을 만족하지 않는 것으로 판단하고, 해당 내용을 로그에 기록한다.

두 함수가 쌍을 이루어 존재하는지 여부를 판단하는 방법으로는, 예를 들어, 쌍을 이루어야 하는 함수의 개수를 확인하여 그 수가 서로 같은지 여부를 확인하는 방법을 이용할 수 있다. 또는, 하나의 함수가 나올 때 마다 그 함수와 쌍을 이루어야 하는 함수가 있는지 여부를 확인할 수도 있다. 이하, 본 명세서에서 두 함수가 쌍을 이루는지 여부를 확인하는 것을 ‘콜 페어(Call pair) 검사’라고 한다. 또한, 후술하는 내용 중에서 콜 페어 검사가 필요한 경우 이상 설명한 방법을 이용하여 콜 페어 검사를 수행할 수 있다.

후술하는 소프트웨어 인증 장치(200)에서, 이와 같이 두 함수의 콜 페어 검사는 콜 페어 검사기(236)에 의해 수행된다.

다음으로, 본 발명에 따른 소프트웨어 인증 방법에서는, 커널 함수 중 malloc, calloc() 함수의 사용을 금지한다. 소프트웨어 소스코드에서 malloc(), calloc() 함수가 존재하는지 여부를 확인하고, 만일 존재하는 경우 소프트웨어는 규격을 만족하지 않는 것으로 판단하고 해당 내용을 로그에 기록한다.

이와 같이, 금지된 함수가 존재하는지 여부를 검사하는 것을 ‘금지 함수 검사’라고 하고, 후술하는 소프트웨어 인증 장치(200)에서, 금지 함수 검사는 금지 함수 검사기(234)에 의해 수행된다.

<그래픽 함수>

그래픽 함수는 화면이나 오프 스크린 프레임 버퍼(Off Screen Frame Buffer)에 다양한 그리기를 할 수 있는 API를 의미한다. 화면(screen) 프레임 버퍼(frame buffer)나 오프 스크린(off screen) 프레임 버퍼는 데이터의 포인터(pointer)와 데이터의 한 라인당 바이트 수(Byte Per Line)로 기술된다. 프레임 버퍼는 MC_grpCreateOffScreenFrameBuffer 함수로 생성되는데, 생성된 프레임 버퍼는 MC_grpDestoryScreenFrameBuffer 함수로 삭제 해주어야 한다. 따라서, 본 발명에 따른 소프트웨어 검사기는 MC_grpCreateOffScreenFrameBuffer 함수와 MC_grpDestoryScreenFrameBuffer 함수의 콜 페어를 검사한다.

마찬가지로, 이미지를 생성하는 함수인 MC_grpCreateImage 함수에 대해 MC_grpDestroyImage 함수와 콜 페어를 검사한다.

<파일 함수>

MC_MAX_FILENAME_LENGTH 함수는 파일 이름의 최대 길이를 정의하는 함수이다. 소프트웨어 소스코드 내에 이 함수가 포함되어 있는지 여부를 확인한다. 만약 이 함수가 포함되어 있지 않은 경우, WIPI 규격을 만족하지 않는 것으로 판단하고 로그에 기록한다.

MC_fsRemove 함수는 파일을 삭제하는 함수이다. 파일을 삭제하는 경우, 이미 열려 있는 파일은 지울 수 없음이 WIPI 규격에 의해 정의되어 있다. 따라서, 본 발 명에 따른 소프트웨어 검사기에서는 MC_fsRemove 함수가 존재하는 경우, 그 함수에 의제 삭제될 파일이 닫혀 있는지 여부를 확인한다. 파일이 닫혀 있는지 여부를 확인하기 위해, MC_fsRemove 함수가 존재하는 경우, 소스코드를 역으로 거슬러 올라가 MC_fsClose 함수가 존재하는지 여부를 확인한다. 여기서, 소스코드를 역으로 거슬러 올라가 특정 함수 존재 여부를 확인하는 것은, 소스코드 구문에서 단순히 선행하여 기록되어 있는 것을 의미하는 것이 아니라, 소프트웨어 실행을 고려할 때 분기문, 조건문 등을 고려한 소프트웨어 실행 순서상 선행하여 기록되어 있는 것을 의미한다. 이하, 한 함수에 대해 소스코드를 역으로 거슬러 올라가 다른 함수가 존재하는지 여부를 판단하는 것을 ‘선행함수 검사’라고 한다.

후술하는 소프트웨어 인증 장치(200)에서, 이와 같은 선행함수 검사는 선행함수 검사기(238)에 의해 수행된다.

MC_fsRename 함수는 파일이름을 변경하는 함수이다. 이 함수가 존재하는 경우, MC_fsRemove 함수와 마찬가지로, 파일 이름 변경을 위해 우선 그 파일이 닫혀 있어야 하므로, MC_fsClose 함수에 대해 선행함수 검사를 수행한다.

<데이터 베이스 함수>

MC_dbDeleteDataBase 함수는 데이터베이스를 삭제하는 함수이다. 데이터베이스를 삭제하기 위해서는 그 데이터베이스가 닫혀 있을 것을 WIPI 규격에서 요구하고 있으므로, MC_dbCloseDataBase 함수에 대해 선행함수 검사를 수행한다.

<네트워크 함수>

WIPI에서는 TCP/IC 인터넷 통신에 관련된 모듈에 관해 정의하고 있다. MC_netConnect() 함수는 어플리케이션이 인터넷 접근을 위해 호출하는 함수이며, 인터넷 접근을 종료하기 위해서는 MC_netClose() 함수를 호출한다. 따라서, 본 발명에 따른 소프트웨어 검사기는 이들 두 함수, MC_netConnect(), MC_netClose()에 대해 콜 페어 검사를 수행한다.

MC_netSocket 함수는 TCP 혹은 UDP 통신을 위한 소켓을 생성하는 함수이다. 이 함수가 호출되기 전에 MC_netConnect() 함수로 인터넷 접근에 성공해야 한다. 따라서, 본 발명에 따른 소프트웨어 검사기는, MC_netSocket 함수가 존재하는 경우, MC_netConnect() 함수에 대해 선행함수 검사를 수행한다.

MC_netHttpConnect 함수는 서버와 HTTP 연결을 시도하기 위한 함수이고, MC_netHttpClose 함수는 HTTP 연결 식별자 사용을 종료하기 위한 함수이다. 본 발명에 따른 소프트웨어 검사기는 이 두 함수에 대해 콜 페어 검사를 수행한다.

<시리얼 통신>

MC_srlOpen 함수는 시리얼을 열기 위한 함수이고, MC_srlClose 함수는 시리얼 포트 사용을 종료하기 위한 함수이다. 본 발명에 따른 소프트웨어 검사기는 이 두 함수에 대해 콜 페어 검사를 수행한다.

<사용자 인터페이스 컴포넌트>

사용자 인터페이스 컴포넌트로 텍스트 박스, 날짜/시간 컴포넌트, 메뉴 컴포넌트, 라벨 컴포넌트, 리스트 컴포넌트가 있다. 컴포넌트를 생성하기 위해서는 컴포넌트 클래스 구조체가 있어야 한다. 컴포넌트 클래스 구조체는 미리 정의되어 값들이 결정된 구조체로 MC_uicGetClass함수를 통하여 정의된 구조체를 가져올 수 있다. 컴포넌트 클래스 구조체는 각 컴포넌트 별로 다르며, 이 컴포넌트 클래스 구조체를 매개 변수로 하여 MC_uicCreate 함수를 호출하면, 컴포넌트 클래스 구조체를 생성할 수 있다. 생성된 컴포넌트는 MC_uicDestroy로 파괴된다.

본 발명에 따른 소프트웨어 검사기는, MC_uicCreate 함수와 MC_uicDestroy 함수에 대해 콜 페어 검사를 수행한다.

<Generic I/O>

WIPI 규격은 단말기에 장착되는 일반적인 장치를 다루기 위한 API를 제공한다. MC_ioDevOpen 함수는 장치를 열고 초기화하는 함수이고, MC_ioDevClose 함수는 장치의 사용을 종료하는 함수이다. 본 발명에 따른 소프트웨어 검사는, 두 함수에 대해 콜 페어 검사를 수행한다.

<단말 리소스>

단말 리소스는 이미지, 사운드, 주소록 등 특정 데이터 포맷을 가지면서 단말 영역에 저장된 데이터들을 통칭하여 의미한다.

MC_termResSetGroupLockState 함수는 지정한 리소스 그룹의 록(Lock) 상태를 설정하고, MC_termResCheckPassword 함수는 지정한 비밀번호가 단말에 설정된 비밀번호와 일치하는지 확인한다. MC_termResCheckPassword를 이용해 비밀번호를 확인한 후 록 상태를 확인해야 하므로, 본 발명에 따른 소프트웨어 검사기는 MC_termResSetGroupLockState 함수가 존재하는 경우, MC_termResCheckPassword 함수에 대해 선행함수 검사를 수행한다.

MC_termResSetLockState 함수는 지정한 리소스의 록 상태를 설정하는 함수이다. 이 함수가 존재하는 경우에도, MC_termResCheckPassword 함수에 대해 선행함수 검사를 수행한다.

MC_termResRead 함수는 지정한 리소스의 데이터를 반환하는 함수이다. MC_termResRead 함수의 매개변수인 bufsize를 알기 위해서는 먼저 MC_termResGetSize 함수를 실행하여 그 반환값으로 설정한다. 따라서, 본 발명에 따른 소프트웨어 검사기는 MC_termResRead 함수가 존재하는 경우, MC_termResGetSize 함수에 대해 선행함수 검사를 수행한다.

< SMS >

MC_smsGetMaxMsgLength

MC_phnSmsGetMaxMsgLength

MC_phnSmsSend(M_Byte *telIDString, M_Char *telnum, M_Byte *buf, M_Int32 len)

들은 전송가능한 메시지의 최대길이 제한에 관련된 함수로서, 이러한 함수들이 존재하는 경우, 최대 길이를 넘는지 여부를 확인한다.

<보안통신>

MC_secSSLNew 함수는 SSL 핸들을 생성하고 값을 초기화 하고, MC_secSSLFree는 SSL 핸들을 제거하는 함수이다. 본 발명에 따른 소프트웨어 검사기는 두 함수에 대해 콜 페어 검사를 수행한다.

[본 발명에 따른 소프트웨어 인증 장치]

도 4는 본 발명에 따른 소프트웨어 인증 장치(200)를 나타낸 도면이다. 본 발명에 따른 소프트웨어 인증 장치(200)는 테스트 시스템(210)과 인증 시스템(310)으로 이루어진다. 테스트 시스템(210)은 프록그램 테스트를 수행하는 동안 소프트웨어가 실행된 커버리지를 측정하는 커버리지 측정 모듈(220) 및 소프트웨어가 미리 정해진 테스트 규칙을 모두 만족하는지 여부를 판정하는 테스트 규칙 판정 모듈(230)을 포함한다.

본 명세서에서 모듈이라 함은, 해당 작업을 수행하기 위해 컴퓨팅 디바이스에 의해 로딩되는 함수(function), 컴퓨터 소프트웨어, 컴퓨팅 디바이스 및 해당 작업을 수행하는 서버 중 어느 하나를 의미한다. 또한, 각각의 모듈은 본 명세서 정하고 있는 작업 이외의 작업을 수행하는 경우에도 본 발명의 범위에 포함되는 것으로 간주된다. 예를 들어, 커버리지 측정 모듈(220)은 커버리지 측정 이외의 작업을 수행하여도 무방하다.

인증 시스템(310)은 커버리지 및 테스트 규칙 만족 여부에 기초하여 소프트웨어에 인증을 부여한다. 인증 시스템(310)은 커버리지 측정 모듈(220)에 의해 측정된 커버리지가 소정의 임계값 이상인지 여부를 판정하는 커버리지 기준 판정 모듈(320) 및 소프트웨어에 대한 인증을 생성하는 인증 생성 모듈(330)을 포함한다.

여기서, 테스트 규칙 판정 모듈(230)은 앞서 설명한 테스트 규칙을 판정하기 위하여, 필수 함수 검사기(232), 금지 함수 검사기(234), 콜 페어 검사기(236) 및 선행 함수 검사기(238)를 포함한다. 필수 함수 검사기(232), 금지 함수 검사기(234), 콜 페어 검사기(236) 및 선행 함수 검사기(238)의 기능은 앞서 이미 설명하였다.

또한, 테스트 시스템(210)은 측정된 커버리지 및 테스트 규칙 판정 결과를 인증 시스템(310)으로 전송하는 테스트 결과 송신 모듈(240)을 더 포함하고, 인증 시스템(310)은 테스트 결과 송신 모듈(240)로부터 송신된 데이터를 수신하기 위한 테스트 결과 수신 모듈(340)을 더 포함하는 것이 바람직하다.

또한, 인증 시스템(310)은 인증 생성 모듈(330)에서 생성된 소프트웨어에 대 한 인증을 테스트 시스템(210)으로 송신하는 인증 송신 모듈(350)을 더 포함하고, 테스트 시스템(210)은 인증 시스템(310)으로부터 소프트웨어에 대한 인증을 수신하는 인증 수신 모듈(250)을 더 포함하는 것이 바람직하다.

[소프트웨어 인증 장치의 구현]

전술한 소프트웨어 인증 장치(200)는 하나의 통상적인 컴퓨팅 디바이스로 구현될 수 있다. 컴퓨팅 디바이스는 전형적으로 적어도 하나의 프로세싱부(processing unit) 및 시스템 메모리(system memory)를 포함한다. 프로세싱부는 물리적 프로세서(physical processors), 필요에 따라 물리적 프로세서와 함께 동작하는 다중 프로세서(multiple processors), 가상 프로세서(virtual processor) 및 바이너리 실행가능 지시(binary executable instructions)을 해석할 수 있는 여타 디바이스 또는 소프트웨어 소프트웨어를 포함하는 것이다. 또한, 시스템 메모리는 RAM, ROM, 플래시 메모리, 또는 이들의 소정의 조합을 포함할 수 있다. 전형적으로, 시스템 메모리는 운영 체제 및 하나 이상의 소프트웨어 모듈을 포함하며, 소프트웨어 데이터를 포함할 수도 있다. 또한, 컴퓨팅 디바이스는 부가적인 특징 또는 기능을 구비할 수 있다. 예를 들어, 컴퓨팅 디바이스는, 가령 마기 디스크, 광 디스크 또는 테이프와 같이 부가적인 (분리형 및/또는 비분리형) 데이터 스토리지 디바이스를 포함할 수 있다. 컴퓨터 스토리지 매체는 컴퓨터 판독가능 지시(instruction), 데이터 구조(data structure), 소프트웨어 모듈(program module) 또는 다른 데이터와 같은 소정의 정보에 대한 저장 방법 또는 기술로 구현되는 휘 발성 및 비휘발성, 분리형 및 비분리형 매체를 포함한다. 컴퓨터 스토리지 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술이거나, CD-ROM, DVD(digital versatile disks) 또는 다른 광 스토리지이거나, 자기 카세트, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스이거나, 또는 원하는 정보를 저장하는데 사용되며 컴퓨팅 디바이스에 의해 액세스될 수 있는 소정의 다른 매체를 포함하며, 이에 한정되지 않는다. 그러한 소정의 컴퓨터 스토리지 매체는 컴퓨팅 디바이스의 일부일 수 있다. 또한, 컴퓨팅 디바이스는 키보드, 마우스, 펜, 스타일러스(stylus), 음성 입력 디바이스, 터치 입력 디바이스 등과 같은 입력 디바이스도 구비할 수 있다. 또한, 디스플레이, 스피커, 프린터 등과 같은 출력 디바이스도 포함될 수 있다. 이러한 모든 디바이스들은 본 기술 분야에서 공지되어 있으므로 여기서는 더 이상 상세히 설명하지 않기로 한다. 또한, 컴퓨팅 디바이스는, 디바이스가 가령, 네트워크를 통해, 다른 컴퓨팅 디바이스와 통신할 수 있도록 하는 통신 접속(communications connection) 수단을 포함할 수 있다.

이와 다르게는, 소프트웨어 인증 장치(200)의 테스트 시스템(210)과 인증 시스템(310)이 개별적인 통상적인 컴퓨팅 디바이스로 구현되고, 테스트 시스템(210)과 인증 시스템(310)을 구현하는 컴퓨팅 디바이스들은 통신 접속 수단에 의하여 네트워크를 통하여 접속될 수 있다. 예를 들어, 테스트 시스템(210)과 인증 시스템(310)은 인터넷을 통해 접속된 서버와 클라이언트를 구성하는 개별적인 컴퓨팅 디바이스일 수 있다. 이 경우, 각 시스템(210, 310)에 포함되는 각 모듈은 개별적 인 소프트웨어거나 하나의 소프트웨어에 포함된 개별적인 기능 함수일 수 있다.

이와 다르게는, 테스트 시스템(210)과 인증 시스템(300)이 각각 독립적인 서버이고, 각 시스템(210, 310)에 포함되는 각 모듈을 개별적인 컴퓨팅 디바이스로 구현할 수도 있다. 또는, 각 시스템(210, 310)에 포함되는 각 모듈을 개별적인 서버로 구현하는 것도 가능하다.

이상, 본 발명에 따른 소프트웨어 인증 방법 및 장치를 첨부된 도면을 참조하여 상세히 설명하였다. 지금까지 설명한 소프트웨어 인증 방법 및 장치는 예시적인 것이지 본 발명을 한정하기 위한 것은 아니다. 본 발명의 범위는 이하의 특허청구범위에 의해 결정되어야 하며, 전술한 실시예뿐만 아니라 당업자가 전술한 실시예를 참조하여 변형 가능한 변형예 등도 본 발명의 권리 범위에 포함되는 것으로 해석되어야 한다.

[소프트웨어 인증 방법]

다음으로, 도 5를 참조하여 본 발명의 또 다른 일 실시예에 따른 소프트웨어 인증 방법을 상세히 설명한다. 도 5는 본 발명의 또 다른 일 실시예에 따른 소프트웨어 인증 방법을 모식적으로 나타낸 도면이다.

본 발명에 따른 소프트웨어 인증 방법은 테스트 시스템(210), 인증 시스템(310)에 의해 수행된다. 테스트 시스템(210) 및 인증 시스템(310)의 구성에 관해서는 이후에 상세히 설명하도록 하고, 먼저, 도 5를 참조하여, 소프트웨어 인증 방 법에 관하여 상세히 설명한다.

우선, 테스트 시스템(210)에서 테스트 프로젝트 정보가 생성된다 (S101). 테스트 프로젝트 정보는, 인증 시스템(310)에 의해 소프트웨어 인증을 받으려는 소프트웨어에 관한 정보를 의미한다. 테스트 프로젝트 정보는 1) 프로젝트 정보, 2) 소스 코드 정보, 3) 오브젝트(object) 정보를 포함한다. 프로젝트 정보는 소프트웨어 개발에 관련된 프로젝트 정보로서, 프로젝트 명칭, 프로젝트 생성 일자, 최종 수정 일자를 포함한다. 소스 코드 정보는 프로젝트에 포함된 소프트웨어 소스 코드에 관한 정보로서, 파일 개수, 각 소스 코드의 라인 수, 소스 코드에 포함된 함수(function) 개수, 각 소스 코드의 수정 일자 등을 포함한다. 오브젝트 정보는 소프트웨어 소스코드를 컴파일(compile)한 결과인 오브젝트 파일에 관한 정보이다. 오브젝트 정보는 오브젝트 파일의 특정 위치의 바이너리 정보를 포함한다. 예를 들어, 오브젝트 파일의 11킬로바이트에서부터 14킬로바이트 위치에 포함된 바이너리 값이 오브젝트 정보로서 이용된다.

생성된 테스트 프로젝트 정보는 인증 시스템(310)으로 전송된다 (S102). 테스트 시스템(210)과 인증 시스템(310)이 동일한 물리적 디바이스에 구현되는 경우, 테스트 프로젝트 정보의 전송은 생략될 수 있다. 인증 시스템(310)은 생성된 테스트 프로젝트 정보에 기초하여 고유코드를 생성한다 (S103). 이때, 고유코드는 각각 미리 정해진 크기를 가진다. 고유코드는 바이너리 코드, 파일, 쿠키 등 통상적으로 사용되는 임의의 형태를 가질 수 있다. 고유코드를 테스트 프로젝트 정보에 기초하여 생성한다는 것은 테스트 프로젝트 정보에 포함되는 정보 중 어느 하나가 다르면 다른 고유코드가 생성되도록 고유코드를 생성한다는 의미이다. 또한, 고유코드를 생성할 때 난수를 이용하며, 이때 이용한 난수는 데이터베이스에 기록한다. 예를 들어, 난수를 생성하기 위해, 고유코드가 생성되는 시간을 변수로 이용할 수 있다. 이 경우, 동일한 테스트 프로젝트 정보에 기초하여 고유코드를 생성하더라도 생성 시간에 따라 다른 고유코드가 생성될 수 있다.

또한, 인증 시스템(310)은 공개키를 생성한다. 공개키는 바이너리 코드, 파일, 쿠기 등 통상적으로 사용되는 임의의 형태를 가질 수 있다. 공개키는 고유코드와 같이, 테스트 프로젝트 정보에 기초하여 생성할 수도 있고, 혹은 테스트 프로젝트 정보와 무관하게 미리 정해진 통상적인 방식으로 생성할 수도 있다.

생성된 고유코드 및 공개키는 테스트 시스템(210)으로 전송된다 (S104). 테스트 시스템(210)으로 고유코드 및 공개키가 전송되고 난 후, 테스트 시스템(210)에서 해당 프로젝트의 소프트웨어의 테스트가 수행된다. 소프트웨어 테스트 과정에서는, 소프트웨어 개발자 또는 테스트 툴에 의해, 개발된 소프트웨어가 다양한 상황에서 실행된다. 예를 들어, 소프트웨어 개발자는 테스트 대상 프로그램을 다양한 상황에서 실행시킨다. 테스트 시스템(210)은 테스트 대상 프로그램의 실행 결과를 감시한다. 이 감시 결과에 기초하여, 테스트 시스템(210)은 소프트웨어의 전체 소스 코드 중 테스트된 소스 코드의 비율, 즉, 테스트 커버리지를 측정한다. 이 테스트 커버리지는 소프트웨어 인증 여부에 이용될 수 있으며, 이에 관한 상세한 설명은 후술하기로 한다. 또한, 테스트 시스템(210)은 테스트 대상 소프트웨어가 미리 정해진 코딩 규칙을 만족하는지 여부를 판정한다. 이 판정 결과는 소프트웨어 인증 여부에 이용될 수 있으며, 이에 관한 상세한 설명은 후술하기로 한다. 판정의 대상이 되는 코딩 규칙의 예로서는, 소프트웨어가 WIPI 기준을 만족하는지 여부를 들 수 있다. 이 경우, 소프트웨어가 WIPI 기준을 만족하는지 여부의 판정 결과가 후술하는 소프트웨어 인증 여부에 이용된다.

테스트 시스템(210)이 테스트 커버리지를 측정한 경우에는 테스트 결과는 측정된 테스트 커버리지이다. 테스트 시스템(210)이 테스트 대상 소프트웨어의 코딩 규칙 만족 여부를 판정한 경우에는, 테스트 결과는 이 판정 결과이다. 테스트 결과는 테스트 커버리지와 코딩 규칙 만족 여부 판정 결과를 모두 포함할 수도 있다. 또한, 테스트 결과는 소프트웨어의 오류 정보, 테스트 로그 등을 포함할 수도 있다.

테스트 시스템(210)은 테스트 종료 후 테스트 대상 소프트웨어로부터 프로젝트 정보를 생성한다. 이렇게 생성된 프로젝트 정보를 테스트 후 프로젝트 정보라고 한다. 테스트 후 프로젝트 정보는, 테스트 개시 이전에 고유코드 공개키 생성을 위해 생성된 테스트 프로젝트 정보와는 별도로 생성된 것이다. 테스트 결과는 테스트 후 프로젝트 정보를 더 포함한다.

테스트 시스템(210)은 테스트 결과를 압축한다 (S106). 테스트 결과를 압축할 때, 테스트 결과 파일의 특정 위치에, 인증 시스템(310)으로부터 수신된 고유코드를 삽입한다. 예를 들어, 테스트 결과 파일 전체 용량이 n 바이트인 경우, 테스트 결과 파일을 m개의 조각으로 분리하고(즉, 각 조각이 n/m 바이트가 되도록), 다음으로, 수신된 고유코드를 그 조각 사이마다 삽입하고, 테스트 결과 파일과 고유 코드를 함께 압축할 수 있다. 또는, 수신된 고유코드도 m개의 조각으로 분리하고, m개의 조각으로 분리된 테스트 결과 파일의 각 조각마다 m개의 조각으로 분리된 고유코드를 순서대로 결합한 후, 결합된 결과 파일과 고유코드를 압축할 수 있다. 테스트 결과 파일에 고유코드를 삽입하는 방식 및 삽입하는 위치는 인증 시스템(310)에 의해 임의로 결정될 수 있다. 예를 들어, 고유코드가 생성될 때 고유코드가 삽입되는 방식도 임의로 결정되고, 고유코드 삽입 방식에 관한 정보가 테스트 시스템(210)으로 전송될 수도 있다. 이와 같이, 테스트 결과를 고유코드와 함께 압축하는 이유는, 소프트웨어 개발자가 테스트 결과를 임의로 변조하는 것을 방지하기 위함이다. 테스트 결과는 생성되는 즉시 고유코드와 함께 압축되므로, 테스트 결과를 변조하기 위해서는 압축을 해제해야 한다. 그러나 압축을 해제하고 테스트 결과를 변조한 후, 다시 테스트 결과를 압축하면, 고유코드의 변질이 발생하므로, 테스트 결과가 변조된 것을 인증 시스템(310)에서 용이하게 발견할 수 있다.

다음으로, 압축된 테스트 결과를 공개키를 이용하여 암호화한다 (S107). 암호화를 하는 이유는, 테스트 결과를 제3자가 보지 못하도록 하기 위한 것이다.

다음으로, 암호화까지 완료된 테스트 결과가 인증 시스템(310)으로 전송된다 (S108). 인증 시스템(310)에서는, 수신된 테스트 결과를 공개키를 이용하여 암호화를 해독하고 (S109), 압축을 해제한다 (S110).

다음으로, 수신된 테스트 결과에 포함된 고유코드가, 앞서 인증 시스템(310)에서 테스트 프로젝트 정보에 기초하여 생성한 고유코드와 동일한지 여부를 판정한다 (S111). 그것들이 동일하지 않은 것으로 판정될 경우, 테스트 결과에 조작이 있 었던 것으로 판정한다. 그것들이 동일한 경우에는 테스트 결과가 진정한 것으로 판정하고, 테스트 결과를 분석한다 (S112).

테스트 결과 분석(S112)을 통해, 소프트웨어에 대한 인증 여부를 결정한다. 앞서 설명한 바와 같이, 테스트 결과에는 테스트 커버리지, 코딩 규칙 만족 여부 등이 포함될 수 있으며, 테스트 커버리지가 소정의 임계값 이상인지 여부, 코딩 규칙 만족 여부 등에 기초하여 소프트웨어에 대한 인증 여부를 결정한다.

소프트웨어에 대해 인증을 하는 것으로 결정된 경우, 인증 시스템(310)은 인증서를 생성한다 (S113). 인증 시스템(310)은 생성된 인증서를 테스트 시스템(210)으로 전송할 수도 있고 (S114), 필요에 따라 해당 소프트웨어에 대한 인증을 요구하는 곳으로 직접 인증서를 전송할 수도 있다.

[소프트웨어 인증 장치]

이하, 도 6을 참조하여 본 발명의 또 다른 일 실시예에 따른 소프트웨어 인증 장치를 상세히 설명한다. 도 6은 본 발명에 따른 소프트웨어 인증 장치를 나타낸 블록도이다.

<소프트웨어 인증 장치(200)>

본 발명에 따른 소프트웨어 인증 장치(200)는 테스트 시스템(210) 및 인증 시스템(310)을 포함한다. 테스트 시스템(210)은 소프트웨어를 테스트하기 위한 환경을 제공한다. 테스트 시스템(210)은 소프트웨어 개발자 측에 위치할 수도 있으며, 혹은 소프트웨어를 인증하는 인증 업체 측에 위치할 수도 있다. 이하의 설명은 예를 들어, 테스트 시스템(210)이 소프트웨어 개발자 측에 위치하는 경우에 관한 것이다.

<테스트 시스템(210)>

테스트 시스템(210)은 소프트웨어 개발자 측에 위치하는 시스템으로서, 개발한 소프트웨어를 테스트하기 위한 시스템이다. 테스트 시스템(210)은 통상적인 컴퓨팅 디바이스, 서버 등, 프로세서(processor)를 포함하는 임의의 장치일 수 있으며, 그 구성에 관해서는 후술하도록 한다. 테스트 프로젝트 정보를 생성하기 위해, 테스트 시스템(210)에는 테스트 프로젝트 정보 생성을 위한 모듈이 포함되어 있다. 본 명세서에서 모듈이라 함은, 해당 작업을 수행하기 위해 컴퓨팅 디바이스에 의해 로딩되는 함수(function), 컴퓨터 소프트웨어, 컴퓨팅 디바이스 및 해당 작업을 수행하는 서버 중 어느 하나를 의미한다. 또한, 각각의 모듈은 본 명세서 정하고 있는 작업 이외의 작업을 수행하는 경우에도 본 발명의 범위에 포함되는 것으로 간주된다. 예를 들어, 테스트 프로젝트 정보 생성이 특정 서버에 의해 수행되는 경우, 그 서버는 테스트 프로젝트 정보 생성 이외의 작업을 수행하여도 무방하다.

테스트 시스템(210)은 테스트 프로젝트 정보 생성 모듈(211), 테스트 수행 모듈(212), 압축 모듈(213), 암호화 모듈(214) 및 송수신 모듈(215)를 포함한다.

테스트 프로젝트 정보 생성 모듈(211)은 테스트할 소프트웨어의 테스트 프로젝트 정보를 생성한다. 테스트 프로젝트 정보에 관해서는 앞서 본 발명에 따른 소프트웨어 인증 방법에서 설명하였다. 앞으로도 소프트웨어 인증 장치에서 특별히 언급하지 않는 내용은 앞서 설명한 소프트웨어 인증 방법의 설명을 참조하여 명확 하게 이해할 수 있다. 그 역도 마찬가지이다.

테스트 수행 모듈(212)은 소프트웨어 테스트를 수행하면서 미리 정해진 테스트 규칙 만족 여부(예를 들어, WIPI 기준 만족 여부)를 판정하고, 소프트웨어 테스트의 커버리지를 측정한다. 또한, 테스트 수행 모듈(212)은 테스트 결과 규칙 만족 여부, 테스트 커버리지, 테스트가 수행된 소프트웨어의 프로젝트 정보를 포함하는 테스트 결과를 생성한다.

압축 모듈(213)은 테스트 결과를 고유코드를 포함하여 압축한다.

암호화 모듈(214)은 테스트 결과를 공개키를 이용하여 암호화한다.

송수신 모듈(215)은 테스트 프로젝트 정보를 인증 시스템(310)으로 송신하는 송신 모듈, 인증 시스템으로부터 고유코드를 수신하는 수신 모듈, 인증 시스템으로부터 공개키를 수신하는 수신 모듈, 테스트 결과를 인증 시스템으로 송신하는 송신 모듈을 포함한다. 또한, 송수신 모듈(215)은 인증 시스템(310)으로부터 인증서를 수신하는 수신 모듈을 포함할 수도 있다.

<인증 시스템(310)>

인증 시스템(310)은, 예를 들어, 인증을 제공하는 인증 업체 측에 위치한다. 인증 시스템(310)은 고유코드 및 공캐키 생성 모듈(311), 해독 모듈(312), 압축 해제 모듈(313), 테스트 결과 검증 모듈(314), 테스트 결과 분석 모듈(315), 인증 생성 모듈(316), 송수신 모듈(317), 데이터베이스(318)를 포함한다.

인증 시스템(310)은 테스트 시스템(210)으로부터 테스트 프로젝트 정보를 수신한다. 수신된 테스트 프젝트 정보는 데이터베이스(318)에 저장된다. 고유코드 및 공개키 생성 모듈(311)은 테스트 시스템(210)으로부터 수신된 테스트 프로젝트 정보에 기초하여, 고유코드를 생성하는 고유코드 생성 모듈을 포함한다.

또한, 고유코드 공개키 생성 모듈(311)은 공개키를 생성하는 공개키 생성 모듈을 포함한다.

생성된 고유코드 및 공개키는 데이터베이스(318)에 저장되고, 테스트 시스템(312)으로 전송된다.

해독 모듈(312)은, 테스트 시스템(210)에서 공개키에 기초하여 암호화된 소프트웨어 테스트 결과를, 공개키를 이용하여 해독한다.

압축 해제 모듈(313)은 해독 모듈(312)에 의해 해독된 테스트 결과를 압축 해제한다.

테스트 결과 검증 모듈(314)은 압축 해제된 테스트 결과를 고유코드를 이용하여 검증한다. 압축 해제된 테스트 결과에 포함된 고유코드가 데이터베이스(318)에 저장되어 있는 고유코드와 동일한지 여부를 판정한다. 만일 이것들이 동일하지 않은 경우, 테스트 결과가 조작된 것으로 판정한다.

또한, 테스트 결과 검증 모듈(314)은 고유코드 및 공개키 생성 이전에 테스트 시스템(210)으로부터 수신되어 데이터 베이스(318)에 저장된 프로젝트 정보와, 테스트 결과에 포함되어 수신된 프로젝트 정보가 동일한지 여부를 판정한다. 만약 이것들이 동일하지 않은 경우, 인증을 부여하지 않는다.

테스트 결과 분석 모듈(315)은 테스트 대상 소프트웨어가 미리 정해진 규칙을 만족하는지 여부, 소프트웨어 테스트 커버리지가 소정의 임계값 이상인지 여부 를 판정한다. 그 외에도 인증을 부여하기 위하여 미리 정해진 기준을 만족하는지 여부를 판정할 수 있다.

인증 생성 모듈(316)은 테스트 결과 분석 모듈(315)의 분석 결과에 기초하여 소프트웨어에 대한 인증을 생성한다.

송수신 모듈(317)은 테스트 시스템(210)으로부터 테스트 프로젝트 정보를 수신하는 수신 모듈, 고유코드를 테스트 시스템(210)으로 송신하는 송신 모듈, 공개키를 테스트 시스템(210)으로 송신하는 송심 모듈, 테스트 시스템(210)으로부터 테스트 결과를 수신하는 수신 모듈을 포함한다.

[소프트웨어 인증서 검증 방법]

앞서, 소프트웨어 개발자가 테스트를 수행하고, 그 테스트 결과를 기초로 인증 시스템(310)으로부터 인증을 받는 방법 및 장치를 설명하였다. 그 후, 소프트웨어 개발자가 소프트웨어를 구매자에게 납품하는 경우, 소프트웨어와 함께 인증서를 함께 제출한다 (도 5의 단계 S115 참조).

여기서, 인증서 검증이란, 특정 인증서가 특정 소프트웨어에 대한 테스트 결과 생성된 인증서인지 여부를 판정하는 것을 의미한다. 예를 들어, 소프트웨어 개발자가 소프트웨어 A를 개발하였으나 테스트를 통과하지 못하여 인증을 받지 못하자, 다른 소프트웨어 B를 이용하여 인증서를 발급받고, 소프트웨어 A와 함께 소프트웨어 B의 인증서를 구매자에게 제공한 경우, 위조된 인증서 임을 판별하는 것을 의미한다.

우선 도 7에 도시된 바와 같이, 소프트웨어 개발자(201) 측의 테스트 시스템(210)에 의해 테스트된 소프트웨어가 인증서 검증 시스템(410)으로 제공된다. 여기서, 소프트웨어는 소스 코드의 형태가 아니라 오브젝트 코드(object code) 형태로 제공된다. 소프트웨어의 제공은 소프트웨어 개발자(201)에 의해 수행될 수 있다. 또는, 소프트웨어의 제공은 테스트 시스템(210)에 의해 인증서 검증 시스템(410)으로 전송될 수 있다. 이때, 소프트웨어와 함께 그 소프트웨어에 대한 인증서도 인증서 검증 시스템(410)으로 제공된다. 소프트웨어의 수신, 인증서의 수신은 인증서 검증 시스템(410)의 송수신 모듈(420)에 의해 수행된다.

다음으로, 인증서 검증 시스템(410)은 인증 시스템(310)으로부터 소프트웨어에 대한 정보를 수신한다. 소프트웨어 정보의 수신은 송수신 모듈(420)에 의해 수행된다. 소프트웨어에 대한 정보는 앞서, 소프트웨어 인증 장치 및 방법에서 설명한 테스트 프로젝트 정보를 포함할 수 있다. 또한, 소프트웨어에 대한 정보는 소프트웨어 인증 정보일 수 있다.

다음으로, 인증 시스템(310)으로부터 수신한 정보에 기초하여, 소프트웨어 개발자(201)로부터 제공받은 인증서가 테스트된 소프트웨어에 대한 진정한 인증서인지 여부를 검증한다. 인증서의 검증은 소프트웨어 정보 비교 모듈(440)에 의해 수행된다. 소프트웨어 정보 비교 모듈(440)은 인증서에 포함된 인증 정보를 기초로 인증 시스템(310)의 데이터베이스(318)에 저장된 테스트 프로젝트 정보를 참조한다. 앞서 설명한 바와 같이, 테스트 프로젝트 정보는 오브젝트 정보를 포함하고, 오브젝트 정보는 오브젝트 파일의 특정 위치의 바이너리 정보를 포함한다. 소프트 웨어 정보 비교 모듈(440)은 소프트웨어 개발자(201)로부터 수신한 오브젝트 파일의 특정 위치의 바이너리 정보와 인증 시스템(310)의 데이터베이스(318)에 저장된 테스트 오브젝트 정보를 비교하여, 해당 인증서가 수신된 소프트웨어에 대한 진정한 인증서인지 여부를 판정한다.

또한, 인증서 확인 모듈(450)은 수신된 인증서가 인증 시스템(310)의 데이터베이스(318)에 등록되어 있는 유효한 인증서인지 여부를 확인한다.

[소프트웨어 인증서 검증 장치]

도 7은 본 발명의 또 다른 일 실시예에 따른 소프트웨어 인증서 검증 장치를 나타낸 블록도이다. 본 발명에 따른 인증서 검증 시스템(410)은 송수신 모듈(420), 소프트웨어 정보 추출 모듈(430), 소프트웨어 정보 비교 모듈(440) 및 인증서 확인 모듈(450)을 포함한다.

송수신 모듈(420)은 소프트웨어 개발자(201)로부터 소프트웨어 및 인증서를 수신하고, 인증 시스템(310)으로부터 소프트웨어 정보 및 인증 정보를 수신한다.

소프트웨어 정보 추출 모듈(430)은 소프트웨어 개발자(201)로부터 수신된 소프트웨어로부터 소프트웨어 정보를 추출한다.

소프트웨어 정보 비교 모듈(440)은 인증 시스템(310)으로부터 수신된 소프트웨어 정보와 소프트웨어 정보 추출 모듈(430)에 의해 추출된 소프트웨어 정보를 비교한다.

인증서 확인 모듈(450)은 수신된 인증서가 인증 시스템(310)에 등록되어 있 는 유효한 인증서인지 여부를 확인한다.

[인증 시스템, 테스트 시스템, 인증서 검증 시스템의 구현]

전술한 테스트 시스템(210) 및 인증 시스템(310), 인증서 검증 시스템(410)은 각각 통상적인 컴퓨팅 디바이스로 구현될 수 있다. 컴퓨팅 디바이스는 전형적으로 적어도 하나의 프로세싱부(processing unit) 및 시스템 메모리(system memory)를 포함한다. 프로세싱부는 물리적 프로세서(physical processors), 필요에 따라 물리적 프로세서와 함께 동작하는 다중 프로세서(multiple processors), 가상 프로세서(virtual processor) 및 바이너리 실행가능 지시(binary executable instructions)을 해석할 수 있는 여타 디바이스 또는 소프트웨어 소프트웨어를 포함하는 것이다. 또한, 시스템 메모리는 RAM, ROM, 플래시 메모리, 또는 이들의 소정의 조합을 포함할 수 있다. 전형적으로, 시스템 메모리는 운영 체제 및 하나 이상의 소프트웨어 모듈을 포함하며, 소프트웨어 데이터를 포함할 수도 있다. 또한, 컴퓨팅 디바이스는 부가적인 특징 또는 기능을 구비할 수 있다. 예를 들어, 컴퓨팅 디바이스는, 가령 마기 디스크, 광 디스크 또는 테이프와 같이 부가적인 (분리형 및/또는 비분리형) 데이터 스토리지 디바이스를 포함할 수 있다. 컴퓨터 스토리지 매체는 컴퓨터 판독가능 지시(instruction), 데이터 구조(data structure), 소프트웨어 모듈(program module) 또는 다른 데이터와 같은 소정의 정보에 대한 저장 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 포함한다. 컴퓨터 스토리지 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술이거나, CD-ROM, DVD(digital versatile disks) 또는 다른 광 스토리지이거나, 자기 카세트, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스이거나, 또는 원하는 정보를 저장하는데 사용되며 컴퓨팅 디바이스에 의해 액세스될 수 있는 소정의 다른 매체를 포함하며, 이에 한정되지 않는다. 그러한 소정의 컴퓨터 스토리지 매체는 컴퓨팅 디바이스의 일부일 수 있다. 또한, 컴퓨팅 디바이스는 키보드, 마우스, 펜, 스타일러스(stylus), 음성 입력 디바이스, 터치 입력 디바이스 등과 같은 입력 디바이스도 구비할 수 있다. 또한, 디스플레이, 스피커, 프린터 등과 같은 출력 디바이스도 포함될 수 있다. 이러한 모든 디바이스들은 본 기술 분야에서 공지되어 있으므로 여기서는 더 이상 상세히 설명하지 않기로 한다. 또한, 컴퓨팅 디바이스는, 디바이스가 가령, 네트워크를 통해, 다른 컴퓨팅 디바이스와 통신할 수 있도록 하는 통신 접속(communications connection) 수단을 포함할 수 있다.

테스트 시스템(210), 인증 시스템(310), 인증서 검증 시스템(410)이 각각 통상적인 컴퓨팅 디바이스로 구현되는 경우 각 컴퓨팅 디바이스들은 통신 접속 수단에 의하여 네트워크를 통하여 접속될 수 있다. 또한, 각 시스템(210, 310, 410)의 모듈은 해당 컴퓨팅 디바이스에 의해 실행되는 독립적인 소프트웨어, 또는 소프트웨어의 함수일 수 있다.

이와 다르게는, 테스트 시스템(210), 인증 시스템(310) 및 인증서 검증 시스템(410)이 각각 독립적인 서버이고, 각 시스템(210, 310, 410)에 포함되는 각 모듈 을 개별적인 컴퓨팅 디바이스로 구현할 수도 있다. 또는, 각 시스템(210, 310, 410)에 포함되는 각 모듈을 개별적인 서버로 구현하는 것도 가능하다.

이상, 본 발명에 따른 소프트웨어 인증 방법 및 시스템을 첨부된 도면을 참조하여 상세히 설명하였다. 지금까지 설명한 소프트웨어 인증 방법 및 시스템은 예시적인 것이지 본 발명을 한정하기 위한 것은 아니다. 본 발명의 범위는 이하의 특허청구범위에 의해 결정되어야 하며, 전술한 실시예뿐만 아니라 당업자가 전술한 실시예를 참조하여 변형 가능한 변형예 등도 본 발명의 권리 범위에 포함되는 것으로 해석되어야 한다.

[소프트웨어 인증 시스템]

이하, 도 8을 참조하여 본 발명의 또 다른 일 실시예에 따른 소프트웨어 인증 시스템을 설명한다. 도 8은 본 발명에 따른 소프트웨어 인증 시스템(100)과 테스트 시스템(210)을 나타낸 도면이다. 인증 시스템(100)은 도 1의 인증 업체(20)에 위치하는 시스템이고, 테스트 시스템(210)은 소프트웨어 개발사(10)에 위치하는 시스템이다.

본 발명에 따른 소프트웨어 인증 시스템(100)은, 소프트웨어를 테스트하기 위한 툴을 제공하는 테스트 툴 제공 모듈(110), 소프트웨어의 테스트 결과를 수신하기 위한 테스트 결과 수신 모듈(120), 테스트 결과를 분석하는 테스트 결과 분석 모듈(140), 테스트 결과 분석에 기초하여 소프트웨어에 대한 인증을 생성하는 인증 모듈(150), 인증에 대해 과금하는 과금 모듈(130)을 포함한다.

본 명세서에서 모듈이라 함은, 해당 작업을 수행하기 위해 컴퓨팅 디바이스에 의해 로딩되는 함수(function), 컴퓨터 소프트웨어, 컴퓨팅 디바이스 및 해당 작업을 수행하는 서버 중 어느 하나를 의미한다. 또한, 각각의 모듈은 본 명세서 정하고 있는 작업 이외의 작업을 수행하는 경우에도 본 발명의 범위에 포함되는 것으로 간주된다. 예를 들어, 테스트 툴을 제공하는 테스트 툴 제공 모듈(110)은 테스트 툴 제공 이외의 작업을 수행하여도 무방하다.

테스트 툴 제공 모듈(110)은 소프트웨어 개발자(201)가 테스트 시스템(210)을 이용하여 소프트웨어를 테스트할 수 있는 테스트 툴을 제공한다. 테스트 툴은 소프트웨어 개발자(201)가 인증 시스템(100)으로부터 다운로드 받아 테스트 시스템(210)에서 실행시키거나, 스트리밍(straming) 형태로 제공받을 수 있다. 테스트 툴을 다운로드 받을 수 있게 하기 위해서 테스트 툴 제공 모듈(110)은 다운로드 서버(download server)를 포함한다. 또는, 테스트 툴을 스트리밍 형태로 제공하는 경우, 테스트 툴 제공 모듈(110)은 스트리밍 서버를 포함한다. 테스트 툴 제공 모듈(110)은 테스트 툴을 저장하기 위한 데이터베이스를 포함한다. 테스트 툴 제공 모듈(110)은 소프트웨어 개발자(201)로부터 요청이 있는 경우 데이터베이스에 저장된 테스트 툴을 테스트 시스템(210)으로 전송한다. 소프트웨어 개발자가 테스트 툴을 제공받기 위해서는 미리 인증 시스템(100)에 사용자 등록을 하고, 로그인(log-in)을 하게 할 수도 있다.

다운로드 또는 스트리밍의 형태로 테스트 시스템(210)으로 전송된 테스트 툴은 테스트 시스템(210)에 탑재되어 실행된다. 이하, 테스트 시스템(210)은 테스트 툴이 탑재된 것을 의미한다.

여기서, 인증 시스템(100)의 이해를 돕기 위해, 테스트 시스템(210)에서 수행되는 테스트에 관하여 설명하도록 한다. 소프트웨어 개발자(201)는 테스트 시스템(210)을 이용하여 개발한 소프트웨어를 테스트한다. 테스트 툴은 테스트 대상 소프트웨어가 미리 정해진 규칙을 만족하는지 여부를 판정한다. 여기서 미리 정해진 규칙이란, 소프트웨어를 인증하기 위해 미리 정해진 규칙으로서, 이 규칙을 만족하는 경우에만 소프트웨어에 대해 인증이 부여된다. 규칙의 일례로서, WIPI 표준을 들 수 있다.

또한, 테스트 툴은 테스트 커버리지를 측정한다. 테스트 커버리지란 소프트웨어가 테스트되고 난 후, 전체 소프트웨어 코드 내에서 테스트된 부분의 비율을 나타내는 값이다. 소프트웨어 테스트 결과의 신뢰성을 확보하기 위해서는, 소프트웨어에 포함된 모든 문장들(statement), 소프트웨어에 포함된 모든 함수들(function)이 실행되는 것이 바람직하고, 또한, 소프트웨어가 수행될 때 가능한 모든 분기문, 조건문 등이 완벽하게 테스트 되는 것이 바람직하다. 하지만, 현실적으로 이러한 것들 전부가 모두 완벽하게 테스트되는 것은 시간적, 비용적인 한계가 있으므로, 일정 비율 이상의 테스트 커버리지가 달성되면 테스트 결과를 신뢰할 수 있다고 보는 것이 통상적이다. 테스트 커버리지의 종류로는, 1) 문장 커버리지 (statement coverage), 2) 조건 커버리지 (condition coverage), 3) 함수 (function coverage) 등이 있다.

테스트 시스템(210)은 소프트웨어 테스트가 종료되면, 그 테스트 결과를 인증 시스템(100)으로 전송한다. 인증 시스템(100)의 테스트 결과 수신 모듈(120)은 테스트 시스템(210)으로부터 전송되는 테스트 결과를 수신한다.

테스트 결과 분석 모듈(140)은 수신된 테스트 결과를 분석한다. 즉, 테스트 결과 분석 모듈(140)은 테스트 결과로부터, 테스트 대상 소프트웨어가 미리 정해진 규칙(예를 들어, WIPI 표준)을 모두 만족하는지 여부, 테스트 커버리지가 소정의 임계값 이상인지 여부 등을 판정한다.

인증 모듈(150)은 테스트 결과 분석 모듈(140)의 분석 결과에 기초하여 테스트 대상 소프트웨어에 대한 인증을 생성한다.

과금 모듈(130)은 테스트 결과 분석 및/또는 인증서 생성 작업에 대해 수수료를 부과한다. 즉, 테스트 결과 분석 및/또는 인증서 생성 작업에 대해 대가를 결정하고, 그 대가를 통보하고, 그 대가를 수수한 경우에 서비스의 제공을 완료한다. 과금 모듈(130)은 과금 정보를 생성하여 소프트웨어 개발자(201)에게 전송하는 과금 정보 생성 모듈(132), 소프트웨어 개발자(201)로부터 결제 정보를 수신하는 결제 정보 수신 모듈(134) 및 과금 정보와 결제 정보가 일치하는지 여부를 판정하는 결제 모듈(136)을 포함한다.

수수료 부과를 위해, 과금 정보 생성 모듈(132)은 수신된 테스트 결과에 포함된 소프트웨어 정보에 기초하여 과금 정보를 생성한다. 과금 정보는 수수료의 금액, 납부 일자, 납부 방법 등의 정보를 포함한다. 테스트 결과에 포함되는 소프트 웨어 정보는 테스트 프로젝트 정보를 포함한다. 테스트 프로젝트 정보는, 인증 시스템(310)에 의해 소프트웨어 인증을 받으려는 소프트웨어에 관한 정보를 의미한다. 테스트 프로젝트 정보는 1) 프로젝트 정보, 2) 소스 코드 정보, 3) 오브젝트(object) 정보를 포함한다. 프로젝트 정보는 소프트웨어 개발에 관련된 프로젝트 정보로서, 프로젝트 명칭, 프로젝트 생성 일자, 최종 수정 일자를 포함한다. 소스 코드 정보는 프로젝트에 포함된 소프트웨어 소스 코드에 관한 정보로서, 파일 개수, 각 소스 코드의 라인 수, 소스 코드에 포함된 함수(function) 개수, 각 소스 코드의 수정 일자 등을 포함한다. 오브젝트 정보는 소프트웨어 소스코드를 컴파일(compile)한 결과인 오브젝트 파일에 관한 정보이다.

과금 정보 생성 모듈(132)은 테스트 프로젝트 정보에 포함된 소스 코드 개수, 소스 코드의 라인 수, 소스 코드에 포함된 함수 개수 등에 기초하여 수수료 금액을 포함하는 과금 정보를 생성한다.

과금 정보 생성 모듈(132)은 생성된 과금 정보를 소프트웨어 개발자(201), 보다 구체적으로는 테스트 시스템(210)으로 전송한다. 소프트웨어 개발자(201)는 이 과금 정보에 기초하여 수수료를 결제한다. 수수료 결제는 온라인 납부, 지로 납부, 전자 결제 등 통상적인 임의의 방식으로 가능하다. 수수료 결제 후, 테스트 시스템(210)을 통하여 결제 정보가 인증 시스템(100)으로 전송된다. 결제 정보 수신 모듈(134)은 결제 정보를 수신한다. 결제 모듈(136)은 수신된 결제 정보가 과금 정보와 부합하는지 여부를 판정한다. 결제 정보가 과금 정보와 부합하는 경우에는 다른 모듈의 동작이 가능하지만, 부합하지 않는 경우에는 다른 모듈의 동작이 중단되 고, 과금 정보 생성 모듈(132)이 다시 과금 정보를 생성하여 소프트웨어 개발자(201), 보다 구체적으로는 테스트 시스템(210)으로 전송한다.

여기서, 과금 모듈(130)은 테스트 툴의 제공에 대해서는 수수료를 부과하지 않는다. 따라서, 소프트웨어 개발자(201)는 테스트 툴을 무료로 제공받을 수 있고, 테스트 시스템(210)을 이용하여 개발한 소프트웨어를 무료로 테스트할 수 있다.

[소프트웨어 인증 시스템 및 테스트 시스템의 구현]

전술한 소프트웨어 인증 시스템(100) 및 테스트 시스템(210)은 각각 통상적인 컴퓨팅 디바이스로 구현될 수 있다. 컴퓨팅 디바이스는 전형적으로 적어도 하나의 프로세싱부(processing unit) 및 시스템 메모리(system memory)를 포함한다. 프로세싱부는 물리적 프로세서(physical processors), 필요에 따라 물리적 프로세서와 함께 동작하는 다중 프로세서(multiple processors), 가상 프로세서(virtual processor) 및 바이너리 실행가능 지시(binary executable instructions)을 해석할 수 있는 여타 디바이스 또는 소프트웨어 소프트웨어를 포함하는 것이다. 또한, 시스템 메모리는 RAM, ROM, 플래시 메모리, 또는 이들의 소정의 조합을 포함할 수 있다. 전형적으로, 시스템 메모리는 운영 체제 및 하나 이상의 소프트웨어 모듈을 포함하며, 소프트웨어 데이터를 포함할 수도 있다. 또한, 컴퓨팅 디바이스는 부가적인 특징 또는 기능을 구비할 수 있다. 예를 들어, 컴퓨팅 디바이스는, 가령 자기 디스크, 광 디스크 또는 테이프와 같이 부가적인 (분리형 및/또는 비분리형) 데이터 스토리지 디바이스를 포함할 수 있다. 컴퓨터 스토리지 매체는 컴퓨터 판독가능 지시(instruction), 데이터 구조(data structure), 소프트웨어 모듈(program module) 또는 다른 데이터와 같은 소정의 정보에 대한 저장 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 포함한다. 컴퓨터 스토리지 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술이거나, CD-ROM, DVD(digital versatile disks) 또는 다른 광 스토리지이거나, 자기 카세트, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스이거나, 또는 원하는 정보를 저장하는데 사용되며 컴퓨팅 디바이스에 의해 액세스될 수 있는 소정의 다른 매체를 포함하며, 이에 한정되지 않는다. 그러한 소정의 컴퓨터 스토리지 매체는 컴퓨팅 디바이스의 일부일 수 있다. 또한, 컴퓨팅 디바이스는 키보드, 마우스, 펜, 스타일러스(stylus), 음성 입력 디바이스, 터치 입력 디바이스 등과 같은 입력 디바이스도 구비할 수 있다. 또한, 디스플레이, 스피커, 프린터 등과 같은 출력 디바이스도 포함될 수 있다. 이러한 모든 디바이스들은 본 기술 분야에서 공지되어 있으므로 여기서는 더 이상 상세히 설명하지 않기로 한다. 또한, 컴퓨팅 디바이스는, 디바이스가 가령, 네트워크를 통해, 다른 컴퓨팅 디바이스와 통신할 수 있도록 하는 통신 접속(communications connection) 수단을 포함할 수 있다.

이와 같이, 소프트웨어 인증 시스템(100) 및 테스트 시스템(210)이 각각 통상적인 컴퓨팅 디바이스로 구현되는 경우, 각 시스템(100, 210)에 포함되는 각 모듈은 개별적인 소프트웨어거나 하나의 소프트웨어에 포함된 개별적인 기능 함수일 수 있다.

이와 다르게는, 소프트웨어 인증 시스템(100) 및 테스트 시스템(210)이 각각 독립적인 서버이고, 각 시스템(100, 210)에 포함되는 각 모듈을 개별적인 컴퓨팅 디바이스로 구현할 수도 있다. 또는, 각 시스템(100, 210)에 포함되는 각 모듈을 개별적인 서버로 구현하는 것도 가능하다.

소프트웨어 인증 시스템(100)과 테스트 시스템(210)은 네트워크, 예를 들어 인터넷을 통하여 서로 접속될 수 있다.

[소프트웨어 인증에 대한 과금 방법]

이하, 도 9를 참조하여 소프트웨어 인증에 대한 과금 방법을 설명한다. 도 9는 소프트웨어 인증에 대한 과금 방법을 모식적으로 나타낸 흐름도이다.

본 발명에 따른 소프트웨어 인증에 대한 과금 방법은, 인증 시스템(100)이 테스트 시스템(210)으로 테스트 툴을 전송하는 단계 (S101), 테스트 시스템(210)이 테스트 툴을 실행하여 소프트웨어 테스트를 수행하는 단계 (S102), 테스트 시스템(210)이 소프트웨어 테스트 결과를 인증 시스템(100)으로 전송하는 단계 (S103), 인증 시스템(100)이 테스트 시스템(210)으로 과금 정보를 전송하는 단계 (S104), 테스트 시스템(210)이 인증 시스템(100)으로 결제 정보를 전송하는 단계 (S105), 인증 시스템(100)이 소프트웨어 테스트 결과를 분석하는 단계 (S106), 인증 시스템(100)이 테스트 결과 분석에 기초하여 인증서를 생성하는 단계 (S107)를 포함한다.

먼저, 인증 시스템(100)이 테스트 시스템(210)으로 테스트 툴을 전송한다. 테스트 툴은 테스트 시스템(210)에서 개발된 소프트웨어를 테스트할 수 있는 환경을 제공하는 소프트웨어이다. 테스트 툴은 데스트 시스템(210)으로 다운로드되거나, 스트리밍 형태로 제공될 수 있다.

테스트 시스템(210)은 테스트 툴을 실행하여 개발된 소프트웨어의 테스트를 수행한다. 테스트 시스템(210)은 테스트 대상 소프트웨어가 미리 정해진 규칙을 만족하는지 여부를 판정한다. 여기서 미리 정해진 규칙이란, 소프트웨어를 인증하기 위해 미리 정해진 규칙으로서, 이 규칙을 만족하는 경우에만 소프트웨어에 대해 인증이 부여된다. 규칙의 일례로서, WIPI 표준을 들 수 있다.

또한, 테스트 시스템(210)은 테스트 커버리지를 측정한다. 테스트 커버리지란 소프트웨어가 테스트되고 난 후, 전체 소프트웨어 코드 내에서 테스트된 부분의 비율을 나타내는 값이다. 소프트웨어 테스트 결과의 신뢰성을 확보하기 위해서는, 소프트웨어에 포함된 모든 문장들(statement), 소프트웨어에 포함된 모든 함수들(function)이 실행되는 것이 바람직하고, 또한, 소프트웨어가 수행될 때 가능한 모든 분기문, 조건문 등이 완벽하게 테스트 되는 것이 바람직하다. 하지만, 현실적으로 이러한 것들 전부가 모두 완벽하게 테스트되는 것은 시간적, 비용적인 한계가 있으므로, 일정 비율 이상의 테스트 커버리지가 달성되면 테스트 결과를 신뢰할 수 있다고 보는 것이 통상적이다. 테스트 커버리지의 종류로는, 1) 문장 커버리지 (statement coverage), 2) 조건 커버리지 (condition coverage), 3) 함수 (function coverage) 등이 있다.

다음으로, 테스트 시스템(210)이 인증 시스템(100)으로 테스트 결과를 전송 한다 (S103). 여기서 테스트 결과는 테스트 대상 소프트웨어가 미리 정해진 규칙을 만족하는지 여부, 테스트 커버리지, 테스트 대상 소프트웨어의 정보 등을 포함한다. 테스트 시스템(210)은 테스트 결과만을 전송하고, 테스트 대상 소프트웨어 자체는 전송하지 않는다. 따라서, 개발된 소프트웨어가 외부로 유출될 우려가 없다.

인증 시스템(100)은 테스트 결과를 수신하고, 수신된 테스트 결과에 포함된 테스트 대상 소프트웨어 정보에 기초하여 과금 정보를 생성하여 테스트 시스템(210)으로 전송한다 (S104). 이 과금 정보에 기초하여, 소프트웨어 개발자가 소프트웨어 인증에 대한 수수료를 결제하고, 그 결제 정보를 인증 시스템(100)으로 전송한다 (S105).

인증 시스템(100)은 결제 정보를 수신하여 과금 정보와 비교하고, 결제 정보가 과금 정보에 부합하는 경우, 테스트 결과를 분석한다 (S106). 즉, 인증 시스템은 결제 정보가 수신되었는지 여부를 판단하고, 수신된 결제 정보가 과금 정보와 일치하는지 여부를 판단하고, 결제 정보가 과금 정보와 일치하는 경우에만 테스트 결과에 대한 분석을 수행한다.

테스트 결과 분석을 위해, 인증 시스템(100)은 테스트 대상 소프트웨어가 미리 정해진 규칙을 모두 만족하는지 여부, 테스트 커버리지가 소정의 임계값 이상인지 여부 등을 판정한다. 인증 시스템(100)은 테스트 대상 소프트웨어가 미리 정해진 규칙을 모두 만족하고, 테스트 커버리지가 소정의 임계값 이상인 경우, 인증서를 생성한다 (S107). 인증 시스템(100)은 생성된 인증서를 테스트 시스템(210)으로 전송한다 (S108).

본 발명에 따르면, 테스트 툴이 무료로 제공되고, 또한, 소프트웨어 개발자가 소프트웨어를 테스트 하는데 대해서는 비용을 부과하지 않는다. 다만, 소프트웨어 개발자는 소프트웨어 테스트 결과를 인증 시스템(100)으로 전송하여 인증을 받기 위해서만 비용을 부담하면 된다. 따라서, 소프트웨어 개발자는 소프트웨어를 개발하면서, 다양하고 풍부한 테스트를 수행할 수 있다. 그러므로, 개발된 소프트웨어의 완성도가 향상된다.

이상, 본 발명에 따른 소프트웨어 인증 시스템 및 소프트웨어 인증에 대한 과금 방법을 첨부된 도면을 참조하여 상세히 설명하였다. 지금까지 설명한 소프트웨어 인증 시스템 및 소프트웨어 인증에 대한 과금 방법은 예시적인 것이지 본 발명을 한정하기 위한 것은 아니다. 본 발명의 범위는 이하의 특허청구범위에 의해 결정되어야 하며, 전술한 실시예뿐만 아니라 당업자가 전술한 실시예를 참조하여 변형 가능한 변형예 등도 본 발명의 권리 범위에 포함되는 것으로 해석되어야 한다.

도 1은 본 발명에서 이용하는 소프트웨어 인증의 개념을 설명하기 위한 개념도이다.

도 2는 본 발명에 따른 소프트웨어 인증 방법을 모식적으로 나타낸 도면이다.

도 3은 본 발명에 따라 소프트웨어에 대해 인증을 부여하기 위한 코딩 규칙을 나타낸 도면이다.

도 4는 본 발명에 따른 소프트웨어 인증 시스템을 나타낸 도면이다.

도 5는 본 발명에 따른 소프트웨어 인증 방법을 모식적으로 나타낸 도면이다.

도 6은 본 발명에 따른 소프트웨어 인증 장치를 나타낸 블록도이다.

도 7은 본 발명에 따른 소프트웨어 인증서 검증 장치를 나타낸 블록도이다.

도 8은 본 발명에 따른 소프트웨어 인증 시스템(100)과 테스트 시스템(210)을 나타낸 도면이다.

도 9는 소프트웨어 인증에 대한 과금 방법을 모식적으로 나타낸 흐름도이다.

Claims (7)

1. 소프트웨어를 테스트하고 상기 테스트 결과에 기초하여 상기 소프트웨어를 인증하는 방법에 있어서,

   테스트 프로젝트 정보를 생성하는 단계;

   상기 테스트 프로젝트 정보에 기초하여 고유코드를 생성하는 단계;

   상기 소프트웨어의 테스트가 수행되는 단계;

   상기 소프트웨어의 테스트 결과에 상기 고유코드를 포함시켜 상기 소프트웨어의 테스트 결과와 상기 고유코드를 함께 압축하는 단계;

   상기 압축된 테스트 결과를 공개키를 이용하여 암호화하는 단계;

   상기 암호화된 테스트 결과를 상기 공개키를 이용하여 해독하는 단계;

   상기 압축된 테스트 결과를 압축 해제하는 단계;

   상기 테스트 결과를 검증하는 단계;

   상기 테스트 결과를 분석하여 인증 여부를 판정하는 단계; 및

   상기 인증 여부 판정 결과에 기초하여 인증서를 생성하는 단계를 포함하는, 소프트웨어 인증 방법.
2. 테스트할 소프트웨어의 테스트 프로젝트 정보를 생성하는 테스트 프로젝트 정보 생성 모듈;

   상기 소프트웨어가 소정의 규칙을 만족하는지 여부를 판정하고, 테스트 커버리지를 측정하고, 상기 소프트웨어에 대한 규칙 만족 여부, 상기 테스트 커버리지, 및 상기 테스트 프로젝트 정보를 포함하는 테스트 결과를 생성하는 테스트 수행 모듈;

   상기 테스트 결과를 미리 설정된 고유코드를 포함하여 압축하는 압축 모듈;

   상기 압축된 테스트 결과를 미리 설정된 공개키에 기초하여 암호화하는 암호화 모듈; 및

   상기 압축 및 암호화된 테스트 결과를 전송하는 송수신 모듈을 포함하는, 소프트웨어 테스트 시스템.
3. 테스트할 소프트웨어의 테스트 프로젝트 정보에 기초한 고유코드 및 공개키를 생성하는 고유코드 및 공개키 생성 모듈;

   상기 공개키에 기초하여 암호화된 상기 소프트웨어의 테스트 결과를 상기 공개키를 이용하여 해독하는 해독 모듈;

   상기 해독된 테스트 결과를 압축 해제하는 압축 해제 모듈;

   상기 압축 해제된 테스트 결과를 상기 고유코드를 이용하여 검증하는 테스트 결과 검증 모듈;

   상기 압축 해제된 테스트 결과가 소정의 기준을 만족하는지 여부를 판정하는 테스트 결과 분석 모듈;

   상기 테스트 결과 분석에 기초하여 상기 소프트웨어에 대한 인증을 생성하는 인증 생성 모듈;

   상기 고유코드 및 공개키, 상기 테스트 결과, 상기 인증을 송수신하기 위한 송수신 모듈; 및

   상기 고유코드 및 공개키를 저장하는 데이터베이스를 포함하는, 소프트웨어 인증 시스템.
4. 제2항에 따른 소프트웨어 테스트 시스템을 이용하여 소프트웨어 인증서를 검증하는 방법으로서,

   상기 소프트웨어 테스트 시스템에 의해 테스트된 소프트웨어를 수신하는 소프트웨어 수신 단계;

   소프트웨어 인증서를 수신하는 인증서 수신 단계;

   상기 소프트웨어에 대해 인증한 인증 시스템으로부터 상기 소프트웨어에 대한 정보를 수신하는 단계; 및

   상기 인증 시스템으로부터 수신한 상기 정보에 기초하여, 상기 수신된 인증서가 상기 테스트된 소프트웨어에 대한 진정한 인증서인지 여부를 검증하는 인증서 검증 단계를 포함하는, 소프트웨어 인증서 검증 방법.
5. 제4항에 있어서,

   상기 인증 시스템으로부터 수신하는 상기 정보는, 상기 소프트웨어의 테스트 프로젝트 정보 및 상기 소프트웨어의 인증 정보를 포함하는, 소프트웨어 인증서 검증 방법.
6. 제5항에 있어서,

   상기 인증서 검증 단계는,

   상기 수신한 소프트웨어로부터 소프트웨어 정보를 추출하는 단계;

   상기 인증 시스템으로부터 수신한 상기 테스트 프로젝트 정보와 상기 소프트 웨어 정보를 비교하는 단계; 및

   상기 인증 시스템으로부터 수신한 상기 인증 정보에 기초하여 상기 수신된 인증서가 유효한 인증서인지 여부를 확인하는 단계를 포함하는, 소프트웨어 인증서 검증 방법.
7. 소프트웨어 개발자로부터 소프트웨어 및 인증서를 수신하고, 인증 시스템으로부터 소프트웨어 정보 및 인증 정보를 수신하는 송수신 모듈;

   상기 소프트웨어 개발자로부터 수신된 소프트웨어로부터 소프트웨어 정보를 추출하는 소프트웨어 정보 추출 모듈;

   상기 인증 시스템으로부터 수신된 소프트웨어 정보와 상기 소프트웨어 정보 추출 모듈에 의해 추출된 소프트웨어 정보를 비교하는 소프트웨어 정보 비교 모듈; 및

   상기 수신된 인증서가 상기 인증 시스템에 등록되어 있는 유효한 인증서인지 여부를 확인하는, 인증서 확인 모듈을 포함하는, 소프트웨어 인증서 검증 시스템.

Images