Autotest Assist: 클라우드 경제 환경에서 API 품질을 위한 랜덤 테스트 생성

목차

1. 서론

API 경제가 주도하는 디지털 전환은 하이브리드 클라우드 및 엣지 환경에 배포된 복잡한 마이크로서비스 아키텍처에 의존합니다. 이러한 서비스는 종종 여러 벤더로부터 제공되며, 비즈니스 가치를 제공하기 위해 조합됩니다. 예를 들어, 온라인 서점은 재고, 장바구니, 신용 확인, 배송 마이크로서비스를 통합할 수 있습니다. 이러한 조합은 기능적 정확성 이상의 중요한 품질 과제, 즉 통신 실패, 메시지 순서 문제, 서비스 배치, 서킷 브레이커 실패 등을 야기합니다.

가능한 호출 시퀀스와 매개변수 조합의 방대한 공간으로 인해 이러한 API를 테스트하는 것은 본질적으로 복잡하며, 완전한 테스트는 비현실적입니다. 기존의 지시적 테스트는 노동 집약적입니다. 본 논문은 API 명세서를 읽고 모델을 추론하여 테스트를 생성하면서 동시에 명세서의 함정을 드러내도록 설계된 랜덤 테스트 생성 도구인 Autotest Assist를 소개합니다.

2. 랜덤 API 테스트 생성의 핵심 과제

랜덤 테스트 생성 패러다임은 API 함수 $f()$와 그 합법적인 입력 매개변수 $p_1, ..., p_k$를 무작위로 선택하여 실행하고, 출력 및 부작용을 관찰하는 과정을 포함합니다. 이 과정은 몇 가지 중요한 과제에 직면합니다.

2.1 구문적 및 의미적 입력 유효성

구문적으로 올바른 입력을 생성하는 것 이상으로, 생성기는 호출이 성공하기 위해 매개변수가 API의 사전 조건을 준수하도록 보장해야 합니다. 예를 들어, "책 구매" API $g()$를 호출하려면 이전 "책 조회" API $f()$에서 얻은 유효한 책 참조가 필요합니다.

2.2 동작 검증과 오라클 문제

API 호출이 예상대로 동작했는지 판단하는 것(테스트 오라클 문제)은 랜덤 테스트에서 특히 상태를 유지하는 시스템의 경우 사소하지 않은 문제입니다.

2.3 디버깅 및 문제 격리

무작위로 생성된 테스트가 문제를 드러낼 때 시스템은 디버깅을 지원해야 하며, 테스트의 비결정적 특성으로 인해 어려울 수 있습니다.

2.4 지시적 회귀 테스트 스위트와의 통합

핵심 질문은 랜덤 생성을 통해 발견된(특히 버그를 드러낸) 가치 있는 테스트 케이스를 안정적인 지시적 회귀 테스트 스위트에 어떻게 통합할 것인가입니다.

2.5 커버리지 평가와 신뢰성

랜덤 생성으로 달성된 커버리지를 평가하고, 시스템을 회귀시키기 위해 그것만으로 신뢰할 수 있는지, 아니면 여전히 지시적 테스트 스위트가 필요한지 판단하는 것입니다.

3. Autotest Assist 접근법

Autotest Assist는 근본적으로 API 명세서에 의존함으로써 처음 두 가지 과제를 해결합니다.

3.1 기반으로서의 API 명세서

이 도구는 사전 조건과 사후 조건을 정의해야 하는 API 명세서를 읽습니다. 이 명세서는 유효한 테스트와 오라클을 생성하기 위한 단일 진실 공급원 역할을 합니다.

3.2 모델 추론 및 테스트 생성

명세서로부터 Autotest Assist는 API의 동작, 의존성 및 상태에 대한 모델을 추론합니다. 이 모델은 구문적 및 의미적으로 유효한 API 호출 시퀀스를 무작위로 생성하는 데 사용됩니다.

3.3 명세서 함정 발견

이 접근법의 중요한 부수적 이점은 명세서를 읽고 모델링하는 과정 자체가 명세서의 모호성, 불일치 또는 누락된 제약 조건(통합 오류로 이어질 수 있는 함정)을 드러낼 수 있다는 점입니다.

4. 핵심 통찰 및 분석가 관점

5. 기술적 세부사항 및 수학적 프레임워크

Autotest Assist의 핵심은 명세서로부터의 모델 추론을 포함합니다. 우리는 API $f$를 사전 조건 $Pre_f$와 사후 조건 $Post_f$를 가진 함수로 개념화할 수 있습니다. 시스템의 상태 $S$는 API 호출에 의해 수정됩니다.

생성 알고리즘은 다음과 같이 추상화될 수 있습니다:

1. 모델: 각 API $f_i$에 대해 $Pre_{f_i}(S, \vec{p})$와 $Post_{f_i}(S, S', \vec{p}, \vec{r})$를 추출합니다. 여기서 $S$는 사전 상태, $S'$는 사후 상태, $\vec{p}$는 매개변수, $\vec{r}$은 결과입니다.
2. 선택: $Pre_{f_i}(S_{current}, \vec{p})$를 만족시킬 수 있는 API $f_i$를 무작위로 선택합니다. 이는 $S_{current}$가 주어졌을 때 $\vec{p}$를 해결하는 것을 요구합니다.
3. 생성: $Pre_{f_i}$를 만족시키는 $\vec{p}$에 대한 구체적인 값을 생성합니다.
4. 실행 및 검증: $f_i(\vec{p})$를 실행하고, 새로운 상태 $S'_{observed}$와 결과 $\vec{r}_{observed}$를 관찰합니다. $Post_{f_i}(S_{current}, S'_{observed}, \vec{p}, \vec{r}_{observed})$가 성립하는지 확인합니다.
5. 상태 업데이트: 유효하다면, $S_{current} = S'_{observed}$로 업데이트합니다.

과제는 2단계와 3단계의 제약 조건을 효율적으로 해결하는 것이며, 이는 만족도 모듈로 이론 문제와 관련이 있습니다.

6. 실험 결과 및 성능

제공된 PDF 발췌문에 구체적인 정량적 결과가 포함되어 있지 않지만, 논문은 평가에 중요한 성능 지표를 암시합니다:

• 버그 탐지율: 단위 테스트 시간당 드러난 결함(구현 및 명세서에서)의 수와 심각도. 지시적 테스트와 비교.
• 시퀀스 유효성 비율: 의미적으로 유효한(즉, 모든 사전 조건을 만족하는) 무작위 생성 API 호출 시퀀스의 백분율. 모델의 효과성을 입증합니다.
• 상태 공간 커버리지: 다양한 시스템 상태 및 매개변수 값 경계의 커버리지 지표. 코드 커버리지 도구나 사용자 정의 상태 프로브를 사용하여 측정될 가능성이 높습니다.
• 명세서 함정 발견: 모델링 단계에서 API 명세서에서 발견된 모호성 또는 오류 유형에 대한 정성적 분석.

가상의 결과 차트는 랜덤 테스트로 버그 발견의 초기 급격한 곡선을 보여주다가 결국 정체기에 이르는 반면, 지시적 테스트는 일관적이지만 낮은 비율의 발견을 제공할 것입니다. 결합된 접근법은 가장 높은 누적 결함 발견률을 산출합니다.

7. 분석 프레임워크: 비코드 예시

두 가지 작업을 가진 단순화된 "서점 API"를 고려해 보십시오:

1. GET /book/{id}: 책 세부 정보를 반환합니다. 사전 조건: `{id}`를 가진 책이 재고에 존재해야 합니다.
2. POST /cart/{bookId}: 책을 장바구니에 추가합니다. 사전 조건: `{bookId}`를 가진 책이 이용 가능해야 합니다(존재하고 재고가 있어야 함).

Autotest Assist 워크플로우:

1. 모델 추론: 도구는 명세서를 읽고 의존성을 학습합니다: `POST /cart`는 먼저 성공적인 `GET /book` 호출을 요구합니다(존재/가용성을 확인하기 위해).
2. 테스트 생성: `POST /cart/{bookId}`를 테스트하기로 무작위로 결정합니다.
3. 매개변수 해결: 사전 조건을 만족시키기 위해 먼저 유효한 `bookId`를 생성해야 합니다. 다음 중 하나를 수행할 수 있습니다:
   a) 무작위 ID로 `GET /book`을 호출하여 성공할 때까지 시도합니다(탐색).
   b) 이전 테스트 실행 또는 시드 데이터에서 알려진 ID 목록을 사용합니다.
   그런 다음 이 유효한 `bookId`를 `POST /cart` 호출에 사용합니다.
4. 함정 발견: `POST /cart`에 대한 명세서가 "책이 존재해야 함"만 언급하고 구현에서 재고 수준도 확인한다면, 랜덤 테스트가 실패할 수 있습니다. Autotest Assist는 이를 명세서 함정으로 표시합니다: 명세서의 사전 조건이 불완전합니다.
5. 회귀 통합: 장바구니에 항목을 성공적으로 추가한 시퀀스 `[GET /book/valid_id, POST /cart/valid_id]`는 지시적 회귀 스위트 후보로 저장됩니다.

8. 미래 적용 및 연구 방향

• AI 강화 명세서 추론: 자연어 또는 불완전한 명세서를 해석하고 형식적인 사전/사후 조건을 제안하기 위해 LLM을 통합하여 완벽한 명세서를 사전에 생성하는 부담을 줄입니다.
• 적응형 및 피드백 기반 생성: 순수 무작위성을 넘어 강화 학습을 사용합니다. 생성기는 새로운 버그를 찾거나 커버되지 않은 상태 공간을 탐색할 가능성이 더 높은 API 시퀀스와 매개변수 값을 학습하게 됩니다. 적응형 퍼징의 기술과 유사합니다.
• 교차 서비스 및 통합 테스트: 모델을 확장하여 서로 다른 벤더의 마이크로서비스 간 의존성과 계약을 이해하고, 복잡한 다중 서비스 워크플로우 및 실패 시나리오(예: 서킷 브레이커 패턴)에 대한 테스트를 생성합니다.
• 준수 및 보안 테스트: 보안 정책(예: OAuth 범위, 데이터 개인정보 보호 규칙)을 모델에 통합하여 기능적 및 비기능적 준수 요구 사항을 모두 검증하는 테스트를 자동으로 생성합니다.
• 실시간 API 모니터링 및 테스트: 동일한 모델을 사용하여 프로덕션 또는 스테이징 환경에 대해 실행되는 저부하의 지속적인 테스트 스위트를 생성하여 실시간으로 회귀 또는 명세서 드리프트를 감지합니다.

9. 참고문헌

1. Farchi, E., Prakash, K., & Sokhin, V. (2022). Random Test Generation of Application Programming Interfaces. arXiv preprint arXiv:2207.13143v2.
2. Myers, G. J., Sandler, C., & Badgett, T. (2011). The Art of Software Testing. John Wiley & Sons. (기초 테스트 원칙).
3. Osterweil, L., et al. (2020). Shifting Left: The Economic Impacts of Early Defect Detection. Carnegie Mellon University, Software Engineering Institute. (초기 테스트의 비용 편익 분석).
4. Google Testing Blog. (2019). Fuzzing at Scale. Retrieved from https://testing.googleblog.com/. (대규모 랜덤 테스트에 대한 실용적 통찰).
5. de Moura, L., & Bjørner, N. (2008). Z3: An Efficient SMT Solver. Tools and Algorithms for the Construction and Analysis of Systems. (테스트 생성에 사용되는 제약 조건 해결의 기술적 기초).
6. OpenAPI Initiative. (2023). OpenAPI Specification v3.1.0. https://spec.openapis.org/oas/v3.1.0. (기계 가독 가능한 API 명세서의 표준).