[논문 리뷰] On the Generation of Test Data for Prolog by Partial Evaluation

Miguel Gómez‐Zamalloa, Elvira Albert외 1명|ArXiv.org|2009. 03. 12.

Software Testing and Debugging Techniques참고 문헌 21인용 수 7

한 줄 요약

이 논문은 부분 평가(PE)를 사용하여 Prolog 프로그램의 테스트 데이터 생성(TDG)을 위한 새로운 접근법을 제안한다. 이는 논리 프로그래밍에서 흔한 실패하는 유도 경로를 다루는 데 어려움을 해결하기 위해 Prolog 코드를 실패를 명시적으로 표현하도록 변환함으로써, 실패하는 경로를 포함한 테스트 케이스를 생성할 수 있도록 한다. 이 방법은 두 단계의 PE를 통해 테스트 케이스와 테스트 케이스 생성기를 동시에 생성할 수 있으며, 첫 번째 단계에서는 실패 경로를 캡처하기 위해 Prolog 인터프리터를 특수화하고, 두 번째 단계에서는 제약 조건 해결을 통해 구체적인 테스트 입력을 도출한다. 이는 PE 기반 TDG의 이점을 디클래라티브 언어로 확장한다.

ABSTRACT

In recent work, we have proposed an approach to Test Data Generation (TDG) of imperative bytecode by partial evaluation (PE) of CLP which consists in two phases: (1) the bytecode program is first transformed into an equivalent CLP program by means of interpretive compilation by PE, (2) a second PE is performed in order to supervise the generation of test-cases by execution of the CLP decompiled program. The main advantages of TDG by PE include flexibility to handle new coverage criteria, the possibility to obtain test-case generators and its simplicity to be implemented. The approach in principle can be directly applied for TDG of any imperative language. However, when one tries to apply it to a declarative language like Prolog, we have found as a main difficulty the generation of test-cases which cover the more complex control flow of Prolog. Essentially, the problem is that an intrinsic feature of PE is that it only computes non-failing derivations while in TDG for Prolog it is essential to generate test-cases associated to failing computations. Basically, we propose to transform the original Prolog program into an equivalent Prolog program with explicit failure by partially evaluating a Prolog interpreter which captures failing derivations w.r.t. the input program. Another issue that we discuss in the paper is that, while in the case of bytecode the underlying constraint domain only manipulates integers, in Prolog it should properly handle the symbolic data manipulated by the program. The resulting scheme is of interest for bringing the advantages which are inherent in TDG by PE to the field of logic programming.

연구 동기 및 목표

• 표준 부분 평가에서 자연스럽게 생략되는 실패하는 유도 경로를 포함한 Prolog 테스트 케이스 생성의 과제를 해결하기 위해.
• 기존의 명령형 바이트코드를 대상으로 설계된 PE 기반 TDG 프레임워크를 디클래라티브 언어인 Prolog와 같은 언어로 확장하기 위해.
• Prolog 프로그램으로부터 CLP 형태의 테스트 케이스 생성기를 자동으로 합성함으로써 재사용성과 커버리지의灵活性를 향상시키기 위해.
• 특히 부정된 통합을 포함한 복잡한 통합과 상징적 데이터를 다루기 위해 제약 조건 처리 규칙(CHRs)과 다중 도메인 제약 조건 해결기들을 통합하여 Prolog 내에서 효과적으로 모델링하고 해결하기 위해.
• 정규화된 재귀 깊이를 가진 재귀적 술어 예를 포함한 초보적 실험을 통해 이 접근법의 타당성과 효율성을 평가하기 위해.

제안 방법

• 실패하는 경로를 추적하는 Prolog 인터프리터를 부분 평가하여 원본 Prolog 프로그램을 실패를 명시적으로 표현하는 등가 버전으로 변환하기.
• 두 단계의 부분 평가 프로세스를 사용하기: 첫 번째로 바이트코드 인터프리터를 특수화하여 Prolog를 CLP로 역분석하고, 두 번째로 CLP 프로그램의 PE를 통해 테스트 케이스 생성을 감시하기.
• 부정된 통합에서 발생하는 비등가 제약 조건을 관리하기 위해 제약 조건 처리 규칙(CHRs)을 통합하기.
• 불리언 및 숫자 등의 다중 도메인 제약 조건 해결기를 활용하여 부정 조건을 양성 제약 조건으로 변환하고, 타당성 검사를 가능하게 하기.
• 블록 수와 같은 커버리지 기준을 적용하여 경로 열거를 안내하고 특정 프로그램 경로를 타겟팅하는 테스트 케이스를 확보하기.
• PE 프레임워크 내에서 상징적 실행 원리를 활용하여 경로 조건을 누적하고, 제약 조건 해결을 통해 테스트 입력을 생성하기.

실험 결과

연구 질문

• RQ1 표준 부분 평가에서 일반적으로 무시되는 실패하는 유도 경로를 포함한 Prolog 프로그램에 대한 테스트 케이스 생성을 위해 부분 평가를 어떻게 적응시킬 수 있는가?
• RQ2 Prolog 내에서 부정된 통합과 상징적 데이터 구조를 PE 기반 TDG 프레임워크 내에서 효과적으로 모델링하고 해결하기 위해선 어떻게 해야 하는가?
• RQ3 기존의 바이트코드를 대상으로 한 PE 기반 TDG 접근법이 Prolog와 같은 디클래라티브 언어로 얼마나 일반화될 수 있는가?
• RQ4 결과적으로 생성된 테스트 케이스 생성기는 실행 가능하고 재사용 가능한 CLP 프로그램 형태로 표현될 수 있는가?
• RQ5 블록 수와 같은 커버리지 기준은 Prolog에서 다양한 경로를 커버하는 테스트 입력 생성을 안내하는 데 얼마나 효과적인가?

주요 결과

• 이 방법은 블록 수(2) 기준을 사용하여 최대 세 번의 재귀 호출을 포함한 모든 경로를 커버하는 Prolog 술어 `sorted/1`에 대해 테스트 케이스를 성공적으로 생성하였다.
• 성공 및 실패 경로를 포함한 총 일곱 개의 서로 다른 테스트 케이스가 생성되었으며, 예를 들어 비정렬 리스트에 대한 `[[0,1,2,0|_]],[],no/first-try`와 같은 사례가 포함되었다.
• 이 방법은 CLP 기반의 테스트 케이스 생성기를 자동으로 합성할 수 있게 하여, 전체 PE 파이프라인을 다시 실행하지 않고도 새로운 테스트 입력을 생성할 수 있도록 재사용 가능성을 보장한다.
• CHR 및 다중 도메인 제약 조건 해결기의 통합을 통해 `\+ L=[]` 및 `\+ A#>0`와 같은 부정된 통합을 양성 비등가 제약 조건으로 변환함으로써 효과적으로 처리할 수 있었다.
• 초기 실험 결과는 이 접근법이 재귀적 술어에 대해 타당하고 확장 가능한 것으로 확인되었지만, 더 큰 프로그램에 대한 추가 평가가 필요하다.
• 프레임워크는 컷/0 및 페일/0와 같은 고급 Prolog 기능을 지원하지만, 완전한 통합 및 기존 도구와의 실증적 비교는 아직 진행 중이다.