Как тестировать IVR приложения?
Конерктнее тестирование телефонных систем IVR, а так же тестирование ASR.

Интересует:
Как тестировать?
Как составлять тесты?
Возможно ли автоматическое тестирование?

Здравствуйте, tripolox, Вы писали:

T>Как тестировать IVR приложения?
T>Конерктнее тестирование телефонных систем IVR, а так же тестирование ASR.

T>Интересует:
T>Как тестировать?
T>Как составлять тесты?
T>Возможно ли автоматическое тестирование?

Знамо как — по частям. Я это делаю так. Бизнес-логика (в стейт-машины) отдельно, реал-тайм (ввод-вывод голоса, часы, таймеры и т.д.) отдельно. Друг с другом связаны через интерфейс так, что рейл-тайм часть может подменяться отладочной "заглушкой", позволяющей имитировать события (окончание проигрывания файла, изменение времени, приход dtmf...) с консоли или юнит-тестом. Таким образом, с тестированием бизнес-логики проблем нет.

С реал-тайм частью сложнее, но она получается довольно тонкой.

Здравствуйте, mihoshi, Вы писали:

M>Знамо как — по частям. Я это делаю так. Бизнес-логика (в стейт-машины) отдельно, реал-тайм (ввод-вывод голоса, часы, таймеры и т.д.) отдельно. Друг с другом связаны через интерфейс так, что рейл-тайм часть может подменяться отладочной "заглушкой", позволяющей имитировать события (окончание проигрывания файла, изменение времени, приход dtmf...) с консоли или юнит-тестом. Таким образом, с тестированием бизнес-логики проблем нет.

Я немного не понял...
У Бизнес-логики просто интерфейс, через который вызываються действия по событиям телефонного сервера?
Или всётаки бизнес-часть знает про телефонный сервер и обрабатывает его события, которые можно имитировать "заглушкой"?

Т.е. мне не совсем понятен принцип построения интерфейса для связи бизнес-логики и реал-тайм связи.

M>С реал-тайм частью сложнее, но она получается довольно тонкой.

Я видимо должен объяснить почиму у меня возник такой вопрос:
реализация такая:
есть VUI (Voice User Interface) — это весь кусок реал-тайма

ввод — dtmf, ASR

вывод — голос системы (записанные файлы или TTS)
соостветственно в VUI описаны обработки всех необходимых событий телефонного сервера ввод, вывод, таймеры, проигрываение файлов, события ASR и т.д.

А бизнес-логика, в моём понимании это все функции системы необходимые для предоставления пользователю запрошенной информации, которая будет ему озвучена через VUI, реализована отдельным куском, и отвечает только за обработку переданных пользователем через VUI запросов на получение той или иной информации, и сообщение VUI какую информацию озвучивать. Т.е. при таком подходи бизнес логика отвечает только за информацию, а на VUI ложиться вся нагрузка по общению с пользователем, соответственно тестирование этой части затруднено, т.к. она полностью завязана на событиях телефонного сервра, которые достаточно сложно имитировать.

Соответственно вижу, что мой подход неудобен для тестирования, поэтому и прошу Вас поделиться соображениями по архитектуре приложения, чтобы упростить процесс тестирование, повысить его эффективность и уменьшить время, которое тратиться на тестирование.

С уважением, Михаил.

Здравствуйте, tripolox, Вы писали:

T>Я немного не понял...
T>У Бизнес-логики просто интерфейс, через который вызываються действия по событиям телефонного сервера?
T>Или всётаки бизнес-часть знает про телефонный сервер и обрабатывает его события, которые можно имитировать "заглушкой"?

T>Т.е. мне не совсем понятен принцип построения интерфейса для связи бизнес-логики и реал-тайм связи.

Проще просто привести листинг интерфейса.

        class channel
    {
    public:
        virtual void playFile (string uri) =0;
        virtual void sayText (string text) =0;
        virtual void stopPlayback() =0;        
        virtual date currentTime () =0;
    };

    class channelController
    {
    public:
        virtual void playbackCompleted () =0;
        virtual void dtmf (string text) =0;
        virtual void utterance (string text) =0;
        virtual bool iterate() =0;
        virtual date timeout() =0;
    protected:
    };

    class channelControllerBroker
    {
    public:
        virtual channelController* fetchChannelController (string uri, channel* employer) =0;
        virtual void releaseChannelController(channelController* cc) =0;
    };

Тут еще будут добавлены методы для организации трансфера и ASR...

channel — рейлтайм-часть, channelController — бизнес-логика. При установлении соединения делается релизатор интерфейса channel, для него через channelControllerBroker делается channelController.

timeout() возвращает время, когда можно будет вызывать iterate(). Это или "прямо щас" или время, когда надо будет кричать посетителю "так нажмите уже наконец что-нибудь". Если iterate() возвращает false, то значит, что уже все сказано и соединение можно закрывать.

Текущее время controller узнает строго через currentTime() у channel.

Здравствуйте, mihoshi, Вы писали:
<!-- SKIPPED -->
M>channel — рейлтайм-часть, channelController — бизнес-логика. При установлении соединения делается релизатор интерфейса channel, для него через channelControllerBroker делается channelController.

M>timeout() возвращает время, когда можно будет вызывать iterate(). Это или "прямо щас" или время, когда надо будет кричать посетителю "так нажмите уже наконец что-нибудь". Если iterate() возвращает false, то значит, что уже все сказано и соединение можно закрывать.

M>Текущее время controller узнает строго через currentTime() у channel.

Получается, что на каждый узел меню, создаеться класс, реализующий интерфейс channelController, а при тестировании channel подменяеться на эмулятор. а channelControllerBroker необходим только для связи текущего channelController'а с channel'ом?

Таким образом всю логику голосового меню можно проверить тестом, подменив channel.

Значит останеться только проверить channel ?

Надеюсь я правильно во всём разобрался. Спасибо за советы.
Попробую такой подход на следующем приложении.

Здравствуйте, tripolox, Вы писали:

T>Получается, что на каждый узел меню, создаеться класс, реализующий интерфейс channelController, а при тестировании channel подменяеться на эмулятор. а channelControllerBroker необходим только для связи текущего channelController'а с channel'ом?

Не на каждый узел, а на каждое соединение. Одино-соединение — один channel — один channelController.

Здравствуйте, mihoshi, Вы писали:

M>Здравствуйте, tripolox, Вы писали:

T>>Получается, что на каждый узел меню, создаеться класс, реализующий интерфейс channelController, а при тестировании channel подменяеться на эмулятор. а channelControllerBroker необходим только для связи текущего channelController'а с channel'ом?

M>Не на каждый узел, а на каждое соединение. Одино-соединение — один channel — один channelController.
О! Теперь всё окончательно встало на свои места, еще раз спасибо за советы.