본 논문에서는 소프트웨어 개발 과정에서 소프트웨어의 품질향상에 필요한 소스코드의 API를 기반으로 테스트 케이스를 자동으로 생성할 수 있는 기법을 제안한다. 제안된 기법은 Doxygen오픈소스 툴을 이용한 소스코드 분석 과정, 분석된 결과를 이용한 API 사양 정의 과정, 테스트 디자인 생성 과정, Pairwise Test 기법을 적용한 테스트 케이스 생성 과정 등의 4가지 과정으로 구성된다. Doxygen 오픈소스 툴을 이용한 소스코드 분석 과정은 소스코드의 API 정보인 API 명, 입력 파라미터, 리턴 파라미터 정보 등을 추출하는 단계이다. 분석된 결과를 이용한 API 사양 정의 과정은 추출한 API 정보를 바탕으로 SQLite 데이터베이스를 이용하여 테스트 케이스 생성에 필요한 API 정보들을 데이터베이스화하여 정의하는 단계이다. 테스트 디자인 생성 과정은 정의된 API를 기반으로 입력 파라미터, 리턴 파라미터의 임계치 설정, 제약사항 설정 등을 통해 시나리오를 디자인하여 데이터베이스로 구성하는 단계이다. Pairwise Test 기법을 적용한 테스트 케이스 생성 과정은 테스트 디자인 정보를 바탕으로 Pairwise 조합 기법을 적용하여 실제 테스트 케이스를 생성하여 데이터베이스로 구성하는 단계이다. 제안된 기법의 효율성을 평가하기 위하여 기존의 명세서 기반의 테스트 케이스 생성 방법과 비교한 결과 비슷한 시간 내에 훨씬 더 많은 테스트 케이스가 생성되며, 명세 기반 기법으로는 불가능한 소스코드에 대한 기능 검증도 가능하여 소스코드내 결함 위치도 확인할 수 있다. 따라서 사람의 인력을 통한 수작업에 의존적으로 진행하였던 소프트웨어 개발 품질 향상 과정을 소스코드의 API를 기반으로 자동으로 테스트 케이스를 생성함으로써, 노동력 절감 및 제품 개발 시간 등을 단축 할 수 있으리라 기대된다.
본 논문에서는 소프트웨어 개발 과정에서 소프트웨어의 품질향상에 필요한 소스코드의 API를 기반으로 테스트 케이스를 자동으로 생성할 수 있는 기법을 제안한다. 제안된 기법은 Doxygen 오픈소스 툴을 이용한 소스코드 분석 과정, 분석된 결과를 이용한 API 사양 정의 과정, 테스트 디자인 생성 과정, Pairwise Test 기법을 적용한 테스트 케이스 생성 과정 등의 4가지 과정으로 구성된다. Doxygen 오픈소스 툴을 이용한 소스코드 분석 과정은 소스코드의 API 정보인 API 명, 입력 파라미터, 리턴 파라미터 정보 등을 추출하는 단계이다. 분석된 결과를 이용한 API 사양 정의 과정은 추출한 API 정보를 바탕으로 SQLite 데이터베이스를 이용하여 테스트 케이스 생성에 필요한 API 정보들을 데이터베이스화하여 정의하는 단계이다. 테스트 디자인 생성 과정은 정의된 API를 기반으로 입력 파라미터, 리턴 파라미터의 임계치 설정, 제약사항 설정 등을 통해 시나리오를 디자인하여 데이터베이스로 구성하는 단계이다. Pairwise Test 기법을 적용한 테스트 케이스 생성 과정은 테스트 디자인 정보를 바탕으로 Pairwise 조합 기법을 적용하여 실제 테스트 케이스를 생성하여 데이터베이스로 구성하는 단계이다. 제안된 기법의 효율성을 평가하기 위하여 기존의 명세서 기반의 테스트 케이스 생성 방법과 비교한 결과 비슷한 시간 내에 훨씬 더 많은 테스트 케이스가 생성되며, 명세 기반 기법으로는 불가능한 소스코드에 대한 기능 검증도 가능하여 소스코드내 결함 위치도 확인할 수 있다. 따라서 사람의 인력을 통한 수작업에 의존적으로 진행하였던 소프트웨어 개발 품질 향상 과정을 소스코드의 API를 기반으로 자동으로 테스트 케이스를 생성함으로써, 노동력 절감 및 제품 개발 시간 등을 단축 할 수 있으리라 기대된다.
This paper proposes an automatic generation technology of test case based on API in source code for software's quality improvement. The proposed technology is comprised of four processes which are analyzing source code by using the Doxygen open source tool, defining API specification by using analyz...
This paper proposes an automatic generation technology of test case based on API in source code for software's quality improvement. The proposed technology is comprised of four processes which are analyzing source code by using the Doxygen open source tool, defining API specification by using analyzed results, creating test design, generating a test case by adapting Pairwise test technology. Analyzing source code by using the Doxygen open source tool is the phase in which API information in source code such as the API name, input parameter and return parameter are extracted. Defined API specification by using analyzed results is the phase where API informations, which is needed to generate test case, are defined as a form of database by SQLite database on the basis of extracted API information. Creating test design is the phase in which the scenario is designed in order to be composed as database by defining threshold of input and return parameters and setting limitations based on the defined API. Generating a test case by adapting Pairwise test technique is the phase where real test cases are created and changed into database by adapting Pairwise technique on the base of test design information. To evaluate the efficiency of proposed technology, the research was conducted by begin compared to specification based test case creation. The result shows wider test coverage which means the more cases were created in the similar duration of time. The reduction of manpower and time for developing products is expected by changing the process of quality improving in software developing from man-powered handwork system into automatic test case generation based on API of source code.
This paper proposes an automatic generation technology of test case based on API in source code for software's quality improvement. The proposed technology is comprised of four processes which are analyzing source code by using the Doxygen open source tool, defining API specification by using analyzed results, creating test design, generating a test case by adapting Pairwise test technology. Analyzing source code by using the Doxygen open source tool is the phase in which API information in source code such as the API name, input parameter and return parameter are extracted. Defined API specification by using analyzed results is the phase where API informations, which is needed to generate test case, are defined as a form of database by SQLite database on the basis of extracted API information. Creating test design is the phase in which the scenario is designed in order to be composed as database by defining threshold of input and return parameters and setting limitations based on the defined API. Generating a test case by adapting Pairwise test technique is the phase where real test cases are created and changed into database by adapting Pairwise technique on the base of test design information. To evaluate the efficiency of proposed technology, the research was conducted by begin compared to specification based test case creation. The result shows wider test coverage which means the more cases were created in the similar duration of time. The reduction of manpower and time for developing products is expected by changing the process of quality improving in software developing from man-powered handwork system into automatic test case generation based on API of source code.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
따라서 본 논문에서는 이러한 명세 기반 테스트 케이스 생성 방법의 단점인 노동력 및 많은 소요 시간을 해결할 수 있는 소스코드의 API를 기반으로 테스트 케이스를 자동으로 생성할 수 있는 기법을 제안한다.
본 논문에서는 소프트웨어 개발 과정에서 소프트웨어의 품질향상을 위한 소스코드의 API를 기반으로 테스트 케이스를 자동으로 생성할 수 있는 기법을 제안 하였다. 제안된 소스코드 기반의 테스트 케이스 자동생성 기법은 소스코드를 Doxygen 오픈소스 툴을 이용 하여 분석한 후, API 정보인 API 명, 입력 파라미터, 리턴 파라미터 정보 등을 추출하여 API 사양을 정의한 후 데이터베이스화 하였다.
제안 방법
제안된 소스코드 기반의 테스트 케이스 자동생성 기법은 소스코드를 Doxygen 오픈소스 툴을 이용 하여 분석한 후, API 정보인 API 명, 입력 파라미터, 리턴 파라미터 정보 등을 추출하여 API 사양을 정의한 후 데이터베이스화 하였다. 데이터베이스화 된 API 사양은 각각의 파라미터에 임계치 설정을 통해 테스트 디자인을 생성하여 데이터베이스화 한 후, 데이터베이스화 되어 있는 테스트 디자인 정보를 토대로 Pairwise Test 기법을 적용하여 각각의 API 별로 테스트 케이스를 생성하였다. 실험결과, 기능이 3개일 경우에는 명세 기반 기법을 통해 생성된 테스트 케이스 수는 12개인 반면에 제안된 기법을 통한 테스트 케이스 생성 수는 159개로 약 13배 이상 많은 테스트 케이스가 생성되었다.
본 논문에서 제안하는 방법은 Doxygen 오픈소스 툴을 이용한 소스코드 분석 과정, 분석된 결과를 이용한 API 사양 정의 과정, 테스트 디자인 생성 과정, Pairwise Test 기법을 적용한 테스트 케이스 생성 과정 등의 4가지의 과정으로 구성되어진다.
본 논문에서 테스트 케이스 생성 수를 측정하기 위하여 스마트 TV의 녹화 기능을 명세 기법을 통한 방법과 제안된 방법으로 테스트 케이스를 생성하여 비교 분석한다. 제안된 방법에 사용된 소스는 모사에서 개발한 스마트 TV의 소스 중 녹화 기능과 관련된 2000라인 이상의 소스코드 이용하였다.
API 사양 정의를 토대로 API에 대한 제약사항 설정, 임계치 설정, 필요한 또는 필요 없는 파라미터 쌍 설정 등을 통해 디자인이 가능하다. 실험에서는 숫자형 변수들만 존재하기 때문에 변수에 대한 임계치 설정만을 진행하였다. 그림 5는 파라미터의 임계치 설정 결과이다.
제안된 방법에 사용된 소스는 모사에서 개발한 스마트 TV의 소스 중 녹화 기능과 관련된 2000라인 이상의 소스코드 이용하였다. 이는 실제 스마트 TV의 녹화 기능에 사용되는 소스코드가 포함되며 녹화 관련하여 많은 API가 연계되어 동작되지만 실험을 위해 대표적인 API들을 이용해 실험을 진행 하였다. 스마트 TV의 녹화 기능은 사용자의 리모컨 조작 및 GUI 선택에 의한 방법으로 표 1과 같이 기능을 분류 하여 선택할 수 있다.
본 논문에서는 소프트웨어 개발 과정에서 소프트웨어의 품질향상을 위한 소스코드의 API를 기반으로 테스트 케이스를 자동으로 생성할 수 있는 기법을 제안 하였다. 제안된 소스코드 기반의 테스트 케이스 자동생성 기법은 소스코드를 Doxygen 오픈소스 툴을 이용 하여 분석한 후, API 정보인 API 명, 입력 파라미터, 리턴 파라미터 정보 등을 추출하여 API 사양을 정의한 후 데이터베이스화 하였다. 데이터베이스화 된 API 사양은 각각의 파라미터에 임계치 설정을 통해 테스트 디자인을 생성하여 데이터베이스화 한 후, 데이터베이스화 되어 있는 테스트 디자인 정보를 토대로 Pairwise Test 기법을 적용하여 각각의 API 별로 테스트 케이스를 생성하였다.
표 1은 스마트 TV의 녹화 기능이 3개인 경우를 나타낸 것이다. 화질은 일반 SD 화질과 HD 화질로 구분하고, 소리는 모노와 스테레오로 구분하고 저장매체는 내부 메모리와 외부 메모리로 구분하였으며 외부 메모리는 USB 메모리와 외장하드로 구분하였다.
대상 데이터
Pairwise Test[3-6] 기법을 적용한 테스트 케이스 생성은 그림 6에서 구성한 테스트 디자인과 Pairwise 테스트 기법을 이용하여 테스트 케이스를 생성하는 과정이다. 본 논문에서는 그림 6에서 생성한 2개의 파라미터의 테스트 디자인 정보를 이용하여 입력 값들을 Pairwise로 조합을 하면 그림 7과 같이 200개의 테스트 조합 결과가 생성된다. 입력 파라미터 i의 값이 1일 경우에 입력 파라미터 j의 값이 1부터 20까지 증가하며 20개의 테스트 케이스 조합이 생성되고, i의 값이 1씩 증가함에 따라 20개의 테스트 조합이 추가로 생성된다.
본 논문에서 테스트 케이스 생성 수를 측정하기 위하여 스마트 TV의 녹화 기능을 명세 기법을 통한 방법과 제안된 방법으로 테스트 케이스를 생성하여 비교 분석한다. 제안된 방법에 사용된 소스는 모사에서 개발한 스마트 TV의 소스 중 녹화 기능과 관련된 2000라인 이상의 소스코드 이용하였다. 이는 실제 스마트 TV의 녹화 기능에 사용되는 소스코드가 포함되며 녹화 관련하여 많은 API가 연계되어 동작되지만 실험을 위해 대표적인 API들을 이용해 실험을 진행 하였다.
표 3의 API 들이 각 파라미터를 표 4의 임계치를 적용하여 pairwise 테스트 기법을 적용하여 테스트 케이스를 생성하면, 표 5와 같이 Input_GUI_Record() 함수의 테스트 케이스 생성 수는 20개, deviceOpen() 함수의 테스트 케이스 생성 수는 3개, recording() 함수의 테스트 케이스 생성 수는 20개, memory_Location() 함수의 테스트 케이스 생성 수는 4개, external_Memory_Type() 함수의 테스트 케이스 생성 수는 56개, check_Memory_Space() 함수의 테스트 케이스 생성 수는 56개로 총 159개의 테스트 케이스가 생성되었다.
명세 기반 테스트 케이스 생성 실험과 제안된 기법으로 통한 테스트 케이스 생성 실험 결과는 표 6과 같다. 표 6에 나타난 바와 같이 명세 기반 테스트 케이스 생성 수는 12개인 반면에, 제안된 기법으로 테스트 케이스를 생성한 결과는 159개이다. 이 결과는 명세 기반 테스트 케이스 생성과 비교하여 13배 이상 많은 테스트 케이스가 생성됨이 확인되었다.
데이터처리
그림 2는 두수의 합을 구하는 샘플 프로그램이다. 이 프로그램을 사용하여 Doxygen을 통해 소스코드를 분석과정을 진행하였다. 그림 3은 추출한 결과를 사용자가 보기 쉽도록 html 파일 형태로 추출한 결과이다.
이론/모형
추출한 데이터는 XML 또는 CSV, 데이터베이스 형태의 Repository에 저장할 수 있다. 본 논문에서는 SQLite라는 오픈소스 툴을 사용하여 데이터베이스화 하였다. 파라미터 정보는 입력 파라미터, 출력 파라미터, 리턴 파라미터로 구분되며, 각각의 파라미터는 데이터타입(int, char, user defined)을 가지게 된다.
성능/효과
한편, 스마트폰, 태블릿PC, 클라우드 서비스, 빅데이터(Big Data), Social Computing, 사물 인터넷 등 전략 기술 분야에서도 SW 테스팅을 적용하여 사전에 결함을 발견하고 성능의 안정성을 확보하기 위해 많은 노력을 기울이고 있다.[1-2] NIST(National Institute of Standards and Technology)는 소프트웨어 결함이 미국 경제에 미치는 비용은 1년에 600억 달러에 달하며 이는 미국 GDP의 0.6%에 해당하는 엄청난 규모라는 분석 결과를 발표하였다. 그러나, 실제 비용 추정 모델에는 소프트웨어의 신뢰도 저하에 따른 부차적인 손실, 즉 브랜드 이미지 저하, 고객의 충성도 저하, 매출 및 시장점유율 하락 등은 고려대상이 아니기 때문에 실제 유형, 무형적 손실을 합하면 예상하기 힘든 경제적 손실이 발생하고 있음을 알 수 있다.
이 결과는 명세 기반 테스트 케이스 생성과 비교하여 13배 이상 많은 테스트 케이스가 생성됨이 확인되었다. 따라서 명세 기반의 경우는 소스코드 내부 결함에 대한 검증이 이루어지지 않는 반면에, 제안된 기법은 소스코드를 분석하고 소스코드의 API 별로 테스트 케이스가 생성되어 소스코드 내부에 잠재된 결함까지 검출 할 수가 있었다.
실험결과, 기능이 3개일 경우에는 명세 기반 기법을 통해 생성된 테스트 케이스 수는 12개인 반면에 제안된 기법을 통한 테스트 케이스 생성 수는 159개로 약 13배 이상 많은 테스트 케이스가 생성되었다. 또한 제안된 기법은 기존의 명세기반 기법으로는 불가능한 소스코드의 API 기반의 검증이 가능하기 때문에, 소스코드 내에 잠재되어 있는 결함도 확인할 수 있었다. 따라서 본 제안 기법은 기존의 명세 기반 기법을 사람의 인력을 통해 수작업에 의존적으로 진행하였던 소프트웨어 개발 품질 향상 과정을 소스코드의 API를 기반으로 자동으로 테스트 케이스를 생성함으로써, 노동력 절감 및 제품 개발 시간 등을 단축 할 수 있으리라 기대된다.
데이터베이스화 된 API 사양은 각각의 파라미터에 임계치 설정을 통해 테스트 디자인을 생성하여 데이터베이스화 한 후, 데이터베이스화 되어 있는 테스트 디자인 정보를 토대로 Pairwise Test 기법을 적용하여 각각의 API 별로 테스트 케이스를 생성하였다. 실험결과, 기능이 3개일 경우에는 명세 기반 기법을 통해 생성된 테스트 케이스 수는 12개인 반면에 제안된 기법을 통한 테스트 케이스 생성 수는 159개로 약 13배 이상 많은 테스트 케이스가 생성되었다. 또한 제안된 기법은 기존의 명세기반 기법으로는 불가능한 소스코드의 API 기반의 검증이 가능하기 때문에, 소스코드 내에 잠재되어 있는 결함도 확인할 수 있었다.
표 6에 나타난 바와 같이 명세 기반 테스트 케이스 생성 수는 12개인 반면에, 제안된 기법으로 테스트 케이스를 생성한 결과는 159개이다. 이 결과는 명세 기반 테스트 케이스 생성과 비교하여 13배 이상 많은 테스트 케이스가 생성됨이 확인되었다. 따라서 명세 기반의 경우는 소스코드 내부 결함에 대한 검증이 이루어지지 않는 반면에, 제안된 기법은 소스코드를 분석하고 소스코드의 API 별로 테스트 케이스가 생성되어 소스코드 내부에 잠재된 결함까지 검출 할 수가 있었다.
후속연구
또한 제안된 기법은 기존의 명세기반 기법으로는 불가능한 소스코드의 API 기반의 검증이 가능하기 때문에, 소스코드 내에 잠재되어 있는 결함도 확인할 수 있었다. 따라서 본 제안 기법은 기존의 명세 기반 기법을 사람의 인력을 통해 수작업에 의존적으로 진행하였던 소프트웨어 개발 품질 향상 과정을 소스코드의 API를 기반으로 자동으로 테스트 케이스를 생성함으로써, 노동력 절감 및 제품 개발 시간 등을 단축 할 수 있으리라 기대된다. 한편, 앞으로의 연구에서는 소스코드의 API를 기반으로 테스트 케이스 자동 생성뿐 아니라 생성된 테스트 케이스를 이용한 테스트 자동화 방안의 연구가 필요하다.
따라서 본 제안 기법은 기존의 명세 기반 기법을 사람의 인력을 통해 수작업에 의존적으로 진행하였던 소프트웨어 개발 품질 향상 과정을 소스코드의 API를 기반으로 자동으로 테스트 케이스를 생성함으로써, 노동력 절감 및 제품 개발 시간 등을 단축 할 수 있으리라 기대된다. 한편, 앞으로의 연구에서는 소스코드의 API를 기반으로 테스트 케이스 자동 생성뿐 아니라 생성된 테스트 케이스를 이용한 테스트 자동화 방안의 연구가 필요하다.
질의응답
핵심어
질문
논문에서 추출한 답변
소프트웨어 테스팅 기술은 어떤 목적으로 적용되는가?
현대의 소프트웨어 역할은 기존의 컴퓨팅 영역을 탈피해 가전, 무선 단말기, 산업 기기 등 전방위로 확산되면서 SW 개발 공정은 물론 개발이 끝난 제품의 SW 결함을 사전에 진단하고 정상 동작여부를 시험하는 SW 테스팅 역할의 중요성이 점차 부각되고 있다. 또한, 소프트웨어 테스팅 기술은 응용 프로그램 또는 시스템의 동작과 성능·안정성이 요구하는 수준을 충족시키는지 확인하기 위해 “개발 전 과정에 걸쳐” 결함을 발견하는 행위로 현재 그 중요성이 부각되어 IT(Information Technology) 산업 전반에 걸쳐 적용되고 있다. 한편, 스마트폰, 태블릿PC, 클라우드 서비스, 빅데이터(Big Data), Social Computing, 사물 인터넷 등 전략 기술 분야에서도 SW 테스팅을 적용하여 사전에 결함을 발견하고 성능의 안정성을 확보하기 위해 많은 노력을 기울이고 있다.
소프트웨어 결함이 끼치는 악영향은?
6%에 해당하는 엄청난 규모라는 분석 결과를 발표하였다. 그러나, 실제 비용 추정 모델에는 소프트웨어의 신뢰도 저하에 따른 부차적인 손실, 즉 브랜드 이미지 저하, 고객의 충성도 저하, 매출 및 시장점유율 하락 등은 고려대상이 아니기 때문에 실제 유형, 무형적 손실을 합하면 예상하기 힘든 경제적 손실이 발생하고 있음을 알 수 있다. 한편, 이 매몰 비용(sunk cost)중에서 220억 달러는 더 나은 소프트웨어 테스팅을 통해 줄일 수 있는 비용이라는 분석 결과도 포함하여 발표하였다.
NIST가 발표한 소프트웨어 결함이 미국 경제에 미치는 비용은?
한편, 스마트폰, 태블릿PC, 클라우드 서비스, 빅데이터(Big Data), Social Computing, 사물 인터넷 등 전략 기술 분야에서도 SW 테스팅을 적용하여 사전에 결함을 발견하고 성능의 안정성을 확보하기 위해 많은 노력을 기울이고 있다.[1-2] NIST(National Institute of Standards and Technology)는 소프트웨어 결함이 미국 경제에 미치는 비용은 1년에 600억 달러에 달하며 이는 미국 GDP의 0.6%에 해당하는 엄청난 규모라는 분석 결과를 발표하였다. 그러나, 실제 비용 추정 모델에는 소프트웨어의 신뢰도 저하에 따른 부차적인 손실, 즉 브랜드 이미지 저하, 고객의 충성도 저하, 매출 및 시장점유율 하락 등은 고려대상이 아니기 때문에 실제 유형, 무형적 손실을 합하면 예상하기 힘든 경제적 손실이 발생하고 있음을 알 수 있다.
참고문헌 (6)
Q. Xie and A.M. Memon, "Model-Based Testing of Community-Driven Open-Source GUI Applications," Software Maintenance, 2006. ICSM '06. 22nd IEEE International Conference on, pp. 145-154, Sep. 2006.
J. H. Kim, "Android and Android Market", Journal of Contents Association, Vol.7, No.2, pp.29-36, 2009.
Malte Lochau, Sebastian Oster, Ursula Goltz, Andy Schurr, "Model-based pairwise testing for feature interaction coverage in software product line engineering," Software Quality Journal Vol. 20, No. 3, pp.567-604, Sep. 2012.
Amitava Mukherjee, "A Near-Nonparametric Partially Sequential Test for Monitoring Phase II Location Under Pairwise Dependence Between Two Phases," Sequential Analysis Vol. 30, No.2, pp.208-228, Feb. 2011.
Luc Duchateau, Paul Janssen, "Pairwise nonparametric non inferiority tests in $3{\times}3$ cross-over trials: should we adjust for period," Statistics in Medicine Vol. 24, No.10, pp.1525-1536, May. 2005.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.