Actions on Google 플랫폼용 작업을 개발할 때는 자연어 이해(NLU)를 위한 Dialogflow와 작업의 로직을 처리하는 Dialogflow 처리를 구현하는 것이 포함됩니다. 코드베이스에 테스트가 있으면 작업이 프로덕션에서 예상대로 실행되는지 확인할 수 있습니다.
작업에 단위, 통합 또는 엔드 투 엔드 테스트를 구현할 때 Dialogflow 에이전트와 처리를 별도의 구성요소로 고려해야 합니다.
그림 1. 테스트를 위해 고려할 시스템을 설명하는 플로우 차트
Dialogflow 에이전트 테스트
Dialogflow 에이전트와 처리는 별도의 구성요소로 테스트됩니다. 다음 하위 섹션에서는 작업에 대해 Dialogflow 에이전트를 개념화하고 테스트하는 방법을 설명합니다.
쿼리 입력 및 인텐트 출력 시스템인 Dialogflow
Dialogflow 에이전트는 사용자의 쿼리를 가져와 인텐트와 일치시키고 쿼리에서 사전 정의된 항목을 추출해야 합니다. 에이전트는 일치하는 인텐트, 매개변수, Actions on Google 메타데이터가 포함된 메시지를 전달하여 처리와 상호작용합니다.
개발자는 인텐트 및 항목의 구조와 같은 Dialogflow 에이전트의 구성을 제어합니다. Actions on Google 메타데이터는 Actions on Google에서 가져오며, 테스트를 위한 올바른 데이터를 포함한다고 가정할 수 있습니다.
테스트할 때는 에이전트가 인텐트 매개변수를 올바르게 추출하고 쿼리를 인텐트에 일치시킬 수 있도록 하는 데 집중하세요. 이 접근 방식은 에이전트의 성능을 평가하기 위한 정량화 가능한 측정항목을 제공합니다. 개별 테스트 사례 또는 검증 세트를 준비하고 사용하여 이 측정항목을 계산할 수 있습니다.
그림 2. Dialogflow를 쿼리인 및 인텐트아웃 시스템으로 표현
단위 테스트
Dialogflow 에이전트의 경우 각 사례가 텍스트 쿼리를 입력으로 예상하고 인텐트 메타데이터를 출력으로 생성하는 테스트를 작성할 수 있습니다. 이 메타데이터에는 최소한 일치된 인텐트의 이름 및 일치하는 매개변수 목록이 포함되어야 합니다.
Dialogflow API의 detectIntent 엔드포인트는 텍스트 쿼리를 입력으로 사용하여 확인된 인텐트의 이름과 추출된 매개변수가 포함된 구조화된 출력을 생성합니다. 이 출력은 에이전트의 인텐트 일치 성능을 평가하는 데 유용합니다. 다른 유용한 필드의 전체 참조는 QueryResult 참조를 확인하세요.
샘플 테스트는 다음과 같습니다.
it('choose_fact', async function() {
// The `dialogflow` variable is an abstraction around the API that creates
// and sends payloads to Dialogflow.
const resJson = await dialogflow.detectIntent(
'Tell me about the history of Google');
expect(resJson.queryResult).to.include.deep.keys('parameters');
// Check that Dialogflow extracted required entities from the query.
expect(resJson.queryResult.parameters).to.deep.equal({
'category': 'history',
// Put any other parameters you wish were extracted
});
expect(resJson.queryResult.intent.displayName).to.equal('choose_fact');
});
이 스니펫에서는 Mocha 및 Chai를 사용합니다. Google에 관한 정보에서 Node.js로 작성된 Dialogflow 단위 테스트의 전체 실제 예를 참조하세요.
Dialogflow API가 sessionId을 인수로 허용하므로 테스트 파일을 동시에 실행할 수 있습니다. 따라서 단일 Dialogflow API 클라이언트를 사용하는 동안 대화마다 별도의 샌드박스를 둘 수 있습니다.
Dialogflow API에 대해 요청하므로 무료 호출 할당량에 도달하면 요금이 부과될 수 있습니다. 자세한 내용은 할당량 및 한도를 참조하세요.
통합 테스트
Dialogflow API의 detectIntent 엔드포인트는 서드 파티 처리도 트리거합니다. 따라서 Dialogflow 에이전트와 Dialogflow fulfillment 간의 통합을 다루는 테스트 사례를 작성할 수 있습니다.
Dialogflow의 통합 테스트와 단위 테스트 작성의 주요 차이점은 통합 테스트에서 Dialogflow 인텐트 및 항목 추출뿐만 아니라 웹훅에서 들어오는 응답을 어설션할 수 있다는 것입니다.
Google 정보 저장소에서 Node.js로 작성된 통합 테스트의 전체 실제 예를 확인하세요.
Dialogflow fulfillment 웹훅 테스트
Dialogflow 에이전트와 Dialogflow 처리는 별도의 구성요소로 테스트됩니다. 다음 하위 섹션에서는 작업의 처리를 개념화하고 테스트하는 방법을 설명합니다.
JSON 입력 및 JSON 출력 시스템으로서의 처리
Dialogflow 처리 코드는 요청을 예상하고 JSON 형식으로 응답을 생성합니다. 따라서 처리 코드를 JSON 입력 및 JSON 출력 시스템으로 간주하여 테스트할 수 있습니다. 요청에는 Dialogflow 및 Actions on Google의 메타데이터가 모두 포함되어 있으므로 처리에서 특정 인텐트 핸들러를 트리거하는 데 필요한 모든 것이 들어 있습니다.
인텐트 핸들러의 트리거를 테스트하려면 작업에 JSON 요청 (입력)을 전송합니다. 이 요청은 인터넷에서 액세스할 수 있는 처리에 전달됩니다. 그런 다음 fulfillment는 유효성 검사를 위해 평가할 수 있는 JSON 응답 (출력)을 생성합니다.
그림 3. 처리를 JSON 입력 및 JSON 출력 시스템으로 표현
단위 테스트
처리 웹훅 코드를 JSON 입력을 받아 JSON 출력을 생성하는 시스템으로 생각하면 됩니다. 그러면 작업을 테스트하는 프로세스가 처리에 요청을 제공하고 결과 출력 JSON을 확인하는 것으로 단순화됩니다.
이렇게 하면 자유롭게 Fulfillment를 로컬에서 호스팅하고 HTTP 요청을 로컬로 전송하여 테스트할 수 있습니다. Actions on Google Node.js 클라이언트 라이브러리를 사용하는 경우 클라이언트 라이브러리 미들웨어 레이어로 JSON 요청을 직접 보낼 수도 있습니다.
JSON 입력으로 웹훅 코드를 테스트하고 예상 JSON 출력을 받으면 제어하는 부분이 제대로 작동한다고 합리적으로 확신할 수 있습니다. Dialogflow 및 Actions on Google이 올바른 JSON 페이로드를 생성하기 때문에 제대로 작동한다고 가정할 수 있습니다. 이러한 격리를 통해 테스트 작성을 위한 단순화된 프로그래밍 모델이 제공됩니다.
다음은 테스트 프로세스의 일반적인 개요입니다.
- Actions 콘솔의 시뮬레이터를 사용하여 사용 사례의 각 단계에 대한 JSON 요청을 가져옵니다. JSON 파일로 저장합니다. 또는 웹훅 참조 문서의 정보를 사용하여 이러한 요청을 직접 빌드할 수 있습니다.
- 이러한 페이로드로 웹훅을 호출하는 테스트를 작성합니다.
- 각 테스트에서 응답 JSON에 예상 항목이 포함되어 있는지 확인합니다.
또한 처리 엔드포인트는 로컬에서 실행될 수 있고 Dialogflow API에는 기본 제공 세션 개념이 있으므로 이 모델을 사용하면 지속적 통합 설정에서 Dialogflow 처리를 테스트할 수 있습니다.
테스트 예는 다음과 같습니다.
it('yes-history', function() {
expect(jsonRes.payload).to.have.deep.keys('google');
expect(jsonRes.payload.google.expectUserResponse).to.be.true;
expect(jsonRes.payload.google.richResponse.items).to.have.lengthOf(3);
expect(jsonRes.payload.google.richResponse.suggestions).to.have
.deep.members([
{'title': 'Sure'}, {'title': 'No thanks'},
]);
});
위의 스니펫에서는 Mocha 및 Chai를 사용합니다. Google에 대한 정보 저장소에서 Node.js로 작성된 전체 작업 예를 참고하세요.
단위 테스트 가능한 처리 설계
웹훅 코드에는 애플리케이션이 요구사항을 충족하기 위해 사용하는 커스텀 비즈니스 로직이 포함되는 경우가 많습니다. 또한 웹훅 코드에는 인텐트 핸들러도 포함될 수 있습니다.
처리 코드의 단위 테스트 세부사항을 개선하려면 비즈니스 로직이 인텐트 처리 루틴에서 분리되도록 코드를 구성하는 것이 좋습니다. 즉, 인텐트 핸들러와 비즈니스 로직을 별도의 모듈에 사용하므로 각 부분을 독립적으로 테스트할 수 있습니다.
예시는 GitHub의 shiritori 샘플 작업을 참고하세요.
이 샘플에서 functions/index.js와 functions/shiritori/*.js는 인텐트 핸들러와 비즈니스 로직을 별도로 포함하므로 테스트 모음을 더 강력하게 만들 수 있습니다.
통합 테스트
Dialogflow와 처리 웹훅 코드 간의 통합을 다루는 테스트 사례를 작성하려면 위의 Dialogflow의 통합 테스트 섹션을 읽어보세요.
부하 테스트
작업을 프로덕션에 배포하기 전에 웹훅 처리 부하 테스트를 수행하여 처리 서비스 성능 저하 또는 중단을 유발하는 성능 문제를 파악하는 것이 좋습니다.
다음은 부하 테스트에서 포착할 수 있는 성능 문제의 몇 가지 예입니다.
- 제한된 컴퓨팅 및 메모리
- 제공업체의 할당량 제한
- 느린 데이터 읽기 및 쓰기
- 코드의 동시 실행 문제
부하 테스트 시나리오는 작업의 예상 사용 패턴 또는 과거 사용 패턴에 따라 달라지지만, 일반적으로 테스트할 시나리오는 갑작스러운 부하 증가 (급증)와 지속적인 부하 (침수)입니다.
웹훅이 호출되고 리소스를 많이 사용하는 작업을 수행하는 시나리오를 확인합니다. 일반적인 리소스 집약적인 작업에는 데이터베이스 쿼리, 다른 API 호출, 컴퓨팅 수행, 사운드 파일 렌더링과 같은 메모리 집약적인 작업이 포함됩니다.
이러한 시나리오의 경우 Actions on Google 서버에서 웹훅으로 전송된 요청을 웹훅 로그 또는 Stackdriver 로그에서 캡처할 수 있습니다. Actions 콘솔 시뮬레이터에서 요청을 캡처할 수도 있습니다.
요청이 있으면 부하 테스트 도구를 사용하여 다양한 부하 테스트 시나리오에서 웹훅이 어떻게 응답하는지 확인할 수 있습니다. 다음 하위 섹션에서는 ApacheBench를 사용한 급증 테스트 및 흡수 테스트의 몇 가지 예를 제공합니다.
스파이크 테스트
급증 테스트를 하려면 일정 시간 동안 웹훅에 일정한 수의 요청을 보낸 다음 갑자기 부하를 늘려야 합니다. 예를 들어 60QPS의 급증과 함께 10QPS (초당 쿼리 수)의 로드를 전송하는 테스트를 설정할 수 있습니다.
다음 ApacheBench 명령어를 실행하여 웹훅에 60개의 동시 요청을 보낼 수 있습니다.
ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
ActionRequest.json 파일에 웹훅으로 전송된 캡처된 요청 페이로드가 포함되어 있다고 가정합니다.
흡수 테스트
흡수 테스트를 하려면 웹훅에 일정한 수의 요청을 보내고 응답을 관찰해야 합니다. 예를 들어 응답 시간이 증가하는지 확인하기 위해 몇 분 동안 10~20 QPS의 일정한 로드를 전송하는 테스트를 설정할 수 있습니다.
다음 ApacheBench 명령어를 실행하여 초당 10개의 동시 요청으로 1, 200개의 요청을 전송할 수 있습니다.
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
ActionRequest.json 파일에 웹훅으로 전송된 캡처된 요청 페이로드가 포함되어 있다고 가정합니다.
부하 테스트 결과 분석
부하 테스트를 실행한 후 웹훅 응답 시간 결과를 분석합니다. 웹훅 구현에서 발생한 문제의 지표는 일반적으로 테스트를 실행할 때마다 증가하는 중앙 응답 시간 또는 작업에 허용되지 않는 최악의 응답 시간과 같은 추세입니다.
엔드 투 엔드 테스트
승인을 위해 작업을 제출하기 전에 엔드 투 엔드 테스트를 하려면 Actions 콘솔 시뮬레이터를 사용합니다. 작업 시뮬레이터 문서에서 Actions 콘솔 시뮬레이터를 통한 엔드 투 엔드 테스트 단계를 확인할 수 있습니다. 이러한 테스트를 수행하면 Actions on Google 인프라 구성요소에서 잠재적인 불확실성을 제거할 수 있습니다.