Разработка действия для действий на платформе Google часто включает в себя реализацию Dialogflow для понимания естественного языка (NLU) и выполнение Dialogflow , которое обрабатывает логику вашего действия. Наличие тестов в вашей кодовой базе помогает гарантировать, что ваше действие работает должным образом в рабочей среде.
При реализации модульных, интеграционных или сквозных тестов для вашего действия вам следует рассматривать агент Dialogflow и выполнение как отдельные компоненты.
Рисунок 1. Блок-схема, описывающая системы, которые следует рассмотреть для тестирования
Тестирование агента Dialogflow
Агент Dialogflow и выполнение тестируются как отдельные компоненты. В следующих подразделах описывается, как можно концептуализировать и протестировать агент Dialogflow для вашего действия.
Dialogflow как система ввода и вывода намерений
Ваш агент Dialogflow отвечает за принятие запроса пользователя, сопоставление его с намерением и извлечение любых предопределенных сущностей из запроса. Ваш агент взаимодействует с вашим выполнением, передавая сообщение, содержащее совпадающее намерение, его параметры и метаданные Actions on Google.
Как разработчик, вы контролируете конфигурацию агента Dialogflow, например структуру намерений и сущностей. Метаданные Actions on Google поступают из Actions on Google, и можно предположить, что они содержат правильные данные для тестирования.
При тестировании сосредоточьтесь на том, чтобы ваш агент мог правильно извлекать параметры намерения и сопоставлять запросы с намерениями. Этот подход обеспечивает количественную метрику для оценки производительности агента. Вы можете рассчитать эту метрику, подготовив и используя отдельные тестовые примеры или набор проверок.
Рисунок 2. Представление Dialogflow как системы ввода и вывода данных.
Модульные тесты
Для вашего агента Dialogflow вы можете написать тесты, в которых каждый случай ожидает текстовый запрос в качестве входных данных и создает метаданные намерения в качестве выходных данных. Эти метаданные должны (как минимум) содержать имя совпадающего намерения и список совпадающих параметров.
Конечная точка detectIntent API Dialogflow принимает текстовый запрос в качестве входных данных и создает структурированный вывод, содержащий имя решенного намерения и извлеченные параметры. Эти выходные данные полезны для оценки производительности агента по сопоставлению намерений. Полную информацию о других полезных полях см. в справочнике 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 . Полный рабочий пример модульного теста Dialogflow, написанного на Node.js, можно найти в разделе «Факты о Google» .
Ваши тестовые файлы можно запускать параллельно, поскольку API Dialogflow принимает sessionId в качестве аргумента. В результате вы можете иметь отдельную песочницу для каждого разговора при использовании одного клиента API Dialogflow.
Поскольку вы отправляете запросы к API Dialogflow, при достижении вашей квоты бесплатных вызовов может взиматься плата. Дополнительную информацию см. в разделе «Квоты и лимиты» .
Интеграционные тесты
Конечная точка detectIntent API Dialogflow также запускает стороннее выполнение. Таким образом, можно написать тестовые примеры, охватывающие интеграцию между агентом Dialogflow и выполнением Dialogflow.
Основное различие между написанием интеграционных и модульных тестов для Dialogflow заключается в том, что в интеграционном тесте вы можете утверждать ответы, поступающие от веб-перехватчика, а также намерение Dialogflow и извлечение сущностей.
Полный рабочий пример интеграционного теста, написанного на Node.js, см. в репозитории «Факты о Google» .
Тестирование веб-перехватчика выполнения Dialogflow
Агент Dialogflow и выполнение Dialogflow тестируются как отдельные компоненты. В следующих подразделах описывается, как вы можете концептуализировать и проверить выполнение вашего Действия.
Выполнение как система ввода и вывода JSON
Ваш код выполнения Dialogflow одновременно ожидает запросы и выдает ответы в формате JSON. В результате вы можете протестировать свой код выполнения, представляя его как систему ввода и вывода JSON. Запрос содержит метаданные как из Dialogflow, так и из Actions on Google, поэтому в нем есть все необходимое для запуска определенного обработчика намерений при выполнении.
Чтобы проверить срабатывание обработчика намерений, вы отправляете запрос JSON (вход) в свое действие. Этот запрос передается на ваше выполнение, которое доступно в Интернете. Затем в результате выполнения выдается ответ JSON (выходные данные), который можно оценить на предмет проверки.
Рисунок 3. Представление выполнения в виде системы JSON-in и JSON-out.
Модульные тесты
Думайте о коде веб-перехватчика выполнения как о системе, которая принимает входные данные JSON и создает выходные данные JSON. Затем процесс тестирования действия упрощается до предоставления запроса на выполнение и проверки полученного выходного JSON.
Это дает вам свободу размещать выполнение локально и отправлять HTTP-запросы локально для тестирования. Если вы используете клиентскую библиотеку Actions on Google Node.js, вы также можете отправлять запросы JSON непосредственно на уровень промежуточного программного обеспечения клиентской библиотеки.
Если вы протестируете код веб-перехватчика с входными данными JSON и получите ожидаемые выходные данные JSON, то вы можете с разумной уверенностью сказать, что части, которыми вы управляете, работают правильно. Вы можете предположить, что Dialogflow и Actions on Google работают правильно, поскольку они генерируют правильные полезные данные JSON. Эта изоляция обеспечивает упрощенную модель программирования для написания тестов.
Вот общая схема процесса тестирования:
- Используйте симулятор в консоли «Действия», чтобы получать запросы 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 . Полный рабочий пример, написанный на Node.js, см. в репозитории «Факты о Google» .
Проектирование модульно-тестируемого выполнения
Код веб-перехватчика часто содержит пользовательскую бизнес-логику, на которую опирается ваше приложение для удовлетворения своих потребностей. Кроме того, код веб-перехватчика также может содержать обработчики намерений.
Чтобы повысить степень детализации модульных тестов для кода выполнения, рекомендуется организовать код таким образом, чтобы бизнес-логика была отделена от процедур обработки намерений. Это означает наличие обработчиков намерений и бизнес-логики в отдельных модулях, чтобы каждую часть можно было тестировать независимо.
Для примера обратитесь к нашему примеру действия сиритори на GitHub . В этом примере functions/index.js и functions/shiritori/*.js по отдельности содержат обработчики намерений и бизнес-логику, что позволяет создавать более надежные наборы тестов.
Интеграционные тесты
Чтобы написать тестовые примеры, охватывающие интеграцию между Dialogflow и вашим кодом веб-перехватчика выполнения, прочтите раздел интеграционного тестирования для Dialogflow выше.
Нагрузочные тесты
Прежде чем развертывать действие в рабочей среде, мы также рекомендуем нагрузочное тестирование выполнения вашего веб-перехватчика, чтобы выявить проблемы с производительностью, которые приводят к ухудшению или прерыванию вашей службы выполнения.
Вот несколько примеров проблем с производительностью, которые можно обнаружить при нагрузочном тестировании:
- Ограниченные вычислительные возможности и память
- Ограничения квот от ваших провайдеров
- Медленное чтение и запись данных
- Проблемы параллелизма в коде
Сценарии нагрузочного тестирования зависят от ожидаемого или исторического шаблона использования вашего действия, но типичными сценариями тестирования являются внезапное увеличение нагрузки (скачок) и продолжительные нагрузки (понижение).
Определите сценарии, в которых ваш веб-перехватчик вызывается и выполняет ресурсоемкие операции. Типичные ресурсоемкие операции включают запрос к базе данных, вызов другого API, выполнение вычислений и операции с интенсивным использованием памяти, такие как рендеринг звукового файла.
В этих сценариях вы можете захватывать запросы, отправленные действиями на серверах Google к веб-перехватчику, из журналов веб-перехватчика или из журналов Stackdriver. Вы также можете захватывать запросы из симулятора консоли Actions .
Получив запросы, вы можете использовать инструмент нагрузочного тестирования, чтобы узнать, как ваш вебхук реагирует на различные сценарии нагрузочного тестирования. В следующих подразделах представлены некоторые примеры пикового тестирования и тестирования на выдержку с использованием ApacheBench .
Спайк-тестирование
Spike-тестирование требует, чтобы вы в течение некоторого времени отправляли постоянное количество запросов к вебхуку и внезапно увеличивали нагрузку. Например, вы можете настроить тест, который отправляет нагрузку 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 для отправки 1200 запросов, по 10 одновременных запросов в секунду:
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Предположим, что файл ActionRequest.json содержит захваченные полезные данные запроса, отправленные на ваш веб-перехватчик.
Анализ результатов нагрузочного тестирования
После запуска нагрузочных тестов проанализируйте результаты по времени ответа веб-перехватчика. Индикаторами проблем в реализации вашего веб-перехватчика обычно являются такие тенденции, как среднее время ответа, которое увеличивается с каждым запуском теста, или время ответа в худшем случае, неприемлемое для вашего действия.
Сквозное тестирование
Для комплексного тестирования перед отправкой действия на утверждение используется симулятор консоли Actions . Инструкции по комплексному тестированию с помощью симулятора консоли Actions можно найти в документации симулятора Actions. Выполнение этих тестов поможет вам устранить потенциальные неопределенности в компоненте инфраструктуры Actions on Google.