Actions on Google 플랫폼에서 작업을 개발하는 데에는 자연어 이해를 위해 Dialogflow 구현 (NLU), 그리고 작업의 로직을 처리하는 Dialogflow fulfillment를 포함합니다. 코드베이스에 테스트가 있으면 작업이 예상대로 작동하는지 확인하는 데 도움이 됩니다. 살펴보겠습니다
작업의 단위 테스트, 통합 테스트, 엔드 투 엔드 테스트를 구현할 때는 Dialogflow 에이전트와 fulfillment를 별도의 구성요소로 간주해야 합니다.
그림 1. 테스트에 고려해야 할 시스템을 설명하는 플로우 차트
Dialogflow 에이전트 테스트
Dialogflow 에이전트와 fulfillment는 별도의 구성요소로 테스트됩니다. 이 다음 하위 섹션에서는 Dialogflow API를 개념화하고 테스트하는 방법을 설명합니다. 사용할 수 있습니다.
쿼리-인 및 인텐트-아웃 시스템으로서의 Dialogflow
Dialogflow 에이전트는 사용자의 쿼리를 받아 인텐트, 쿼리에서 사전 정의된 항목을 추출합니다. 에이전트 일치하는 URL이 포함된 메시지를 전달하여 주문 처리와 상호작용합니다. 인텐트, 그 매개변수, Actions on Google 메타데이터를 다룹니다.
개발자는 다음과 같이 Dialogflow 에이전트의 구성을 제어합니다. 인텐트와 엔터티의 구조입니다 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를 사용합니다. 전체 보기 Node.js로 작성된 Dialogflow 단위 테스트 실습 예: Google에 관한 사실.
Dialogflow API는
sessionId를 인수로 사용해야 합니다. 결과적으로
각 대화를 분리하는 데 사용됩니다
Dialogflow API에 대해 요청하기 때문에 요금이 부과될 수 있습니다. 발생할 수 있습니다. 할당량 및 한도 보기 를 참조하세요.
통합 테스트
또한 Dialogflow API의 detectIntent 엔드포인트는
서드 파티 처리를 트리거합니다. 따라서 테스트 사례를 작성하여
Dialogflow 에이전트와 Dialogflow 간의 통합을 다루는
합니다.
Dialogflow의 통합 테스트와 단위 테스트 작성의 주요 차이점은 통합 테스트에서 웹훅으로부터 들어오는 응답을 어설션할 수 있습니다. Dialogflow 인텐트 및 항목 추출도 지원합니다
Node.js로 작성된 통합 테스트에 대해 완벽히 작동하는 예시를 보려면 Google에 관한 사실 저장소
Dialogflow fulfillment 웹훅 테스트
Dialogflow 에이전트와 Dialogflow fulfillment는 별도로 테스트됨 구성할 수 있습니다. 다음 하위 섹션에서는 Google Cloud 콘솔의 fulfillment를 테스트합니다.
JSON-in 및 JSON-out 시스템으로서의 처리
Dialogflow fulfillment 코드는 요청을 예상하고 응답을 생성합니다. JSON 형식입니다. 따라서 다음과 같은 방법으로 처리 코드를 테스트할 수 있습니다. JSON-in 및 JSON-out 시스템으로 작동합니다 요청에는 모든 것을 갖추어 가상 머신을 실행하는 특정 인텐트 핸들러를 만들어야 합니다.
인텐트 핸들러의 트리거를 테스트하려면 있습니다. 이 요청은 다음에서 액세스할 수 있는 처리로 전달됩니다. 있습니다. 그러면 fulfillment가 JSON 응답 (출력)을 생성하며, 이 응답은 평가되어야 합니다
그림 3. 처리를 JSON-in 및 JSON-out 시스템으로 표현
단위 테스트
처리 웹훅 코드를 JSON 입력을 수락하고 JSON 출력을 생성합니다. 그러면 작업 테스트 프로세스가 처리에 요청을 제공하고 결과 출력 JSON을 확인합니다.
이렇게 하면 자유롭게 fulfillment를 로컬에서 호스팅하고 HTTP를 전송할 수 있습니다. 테스트용으로 로컬에서 요청을 실행할 수 있습니다 Actions on Google Node.js를 사용 중인 경우 클라이언트 라이브러리를 사용하여 JSON 요청을 클라이언트 라이브러리에 직접 보낼 수도 있습니다. 살펴보겠습니다
JSON 입력으로 웹훅 코드를 테스트하고 예상 JSON을 수신하는 경우 확신을 갖고 통제하는 부품이 잘 작동합니다. Dialogflow와 Actions on Google이 올바른 JSON 페이로드가 생성되기 때문입니다. 이러한 격리는 테스트 작성을 위한 단순화된 프로그래밍 모델을 제공합니다.
다음은 테스트 프로세스의 일반적인 개요입니다.
- Actions 콘솔에서 시뮬레이터를 사용하여 사용 사례의 각 단계를 설명합니다 JSON 파일로 저장합니다. 또는 다음 작업을 수행할 수 있습니다. Google 게시자 계정의 정보를 사용하여 webhook 참조 문서
- 이러한 페이로드로 웹훅을 호출하는 테스트를 작성합니다.
- 각 테스트에서 응답 JSON에 예상 항목이 포함되어 있는지 확인합니다.
또한 이 모델을 사용하면 단일 콘솔에서 Dialogflow fulfillment를 지속적 통합 설정을 사용하는 것이 좋습니다 Dialogflow API에는 세션이라는 개념이 내장되어 있습니다.
테스트 예는 다음과 같습니다.
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와 Google Cloud 콘솔 간의 통합을 다루는 테스트 사례 작성 fulfillment 웹훅 코드에 대한 자세한 내용은 Dialogflow 통합 테스트 섹션을 참조하세요. 참조하세요.
부하 테스트
작업을 프로덕션에 배포하기 전에 웹훅 처리를 사용하여 성능 저하 또는 성능 문제를 일으키는 주문 처리 서비스가 중단될 수 있습니다
다음은 부하 테스트에서 포착할 수 있는 성능 문제의 몇 가지 예입니다.
- 제한된 컴퓨팅 및 메모리
- 제공업체의 할당량 제한
- 데이터 읽기 및 쓰기 속도가 느림
- 코드의 동시성 문제
부하 테스트 시나리오는 예상 또는 과거 사용 패턴에 따라 일반적으로 테스트해야 할 시나리오는 갑작스러운 부하 증가 (급증)입니다. 지속적인 부하 (흡수)를 사용합니다
웹훅이 호출되고 이를 수행하는 시나리오를 식별합니다. 리소스를 많이 사용하는 작업을 예로 들 수 있습니다 일반적으로 리소스 집약적인 작업에는 다음이 포함됩니다. 데이터베이스 쿼리, 다른 API 호출, 컴퓨팅 및 메모리 수행 매우 저렴하고 내구성이 뛰어납니다.
이러한 시나리오의 경우 Actions on Google 서버에서 보낸 요청을 캡처할 수 있습니다. 웹훅 로그 또는 Stackdriver 로그에서 웹훅으로 변경할 수 있습니다. 그 외에 Actions 콘솔 시뮬레이터에서 요청을 캡처합니다.
요청이 있으면 부하 테스트 도구를 사용하여 웹훅을 설정할 수 있습니다 다음 하위 섹션에서는 ApacheBench
급증 테스트
급증 테스트를 수행하려면 웹훅에 일정한 수의 요청을 전송해야 함 갑자기 부하를 증가시키는 것입니다 예를 들어 10 QPS (초 당 쿼리 수)의 로드로 60 QPS가 약간 급증하는 것을 보여줍니다.
다음 ApacheBench 명령어를 실행하여 60개의 동시 요청을 보낼 수 있습니다. 웹훅에 추가하면 됩니다.
ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
ActionRequest.json 파일에 전송된 캡처된 요청 페이로드가 포함되어 있다고 가정합니다.
웹훅에 추가하면 됩니다
적응 테스트
적응성 테스트를 사용하려면 웹훅에 일정한 수의 요청을 보내야 합니다. 응답을 관찰합니다. 예를 들어, 몇 분 동안 10-20 QPS의 지속적인 로드를 제공하여 응답 시간이 증가할 수도 있습니다
다음 ApacheBench 명령어를 실행하여 10개의 초당 동시 요청 수:
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
ActionRequest.json 파일에 전송된 캡처된 요청 페이로드가 포함되어 있다고 가정합니다.
웹훅에 추가하면 됩니다
부하 테스트 결과 분석
로드 테스트를 실행한 후 웹훅 응답 시간 결과를 분석합니다. 웹훅 구현의 문제 지표는 일반적으로 다음과 같은 추세입니다. 테스트를 실행할 때마다 증가하는 응답 시간 중앙값 또는 최악의 경우 응답 시간을 지정할 수 있습니다.
엔드 투 엔드 테스트
승인을 위해 작업을 제출하기 전 엔드 투 엔드 테스트는 다음을 사용합니다. Actions 콘솔 시뮬레이터 엔드 투 엔드 단계를 위한 작업 시뮬레이터에서 Actions 콘솔 시뮬레이터를 통해 테스트하기 문서를 참조하세요. 이러한 테스트를 수행하면 잠재적 불확실성을 제거할 수 있습니다. 컨테이너 이미지를 가져올 수 있습니다