Поэтому не нужно проверять все N путей попадания в конкретное меню из всех возможных других меню, т.к. баги зачастую возможны лишь на стыке перехода из одного меню в другое.

с помощью каких инструментов происходит тестирование?

 

у нас в проекте мы не можем проверять IVR звоня на номер, номер зарегестрирован не  у нас в стране и поэтому звонить на него дорого. выбрали тестирование через фиддлер. В будущем планирую написать скрипты для автоматической проверки на пайтоне. Но пока это только в планах.

 

Эх... К вашему сожалению, у меня такая возможность была. Звонил с телефона.

Обычно создаются наглядные воркфлоу бизнес аналитиками, по которым намного проще расписать все тест кейсы.

Если есть несколько вариантов как попасть в одно меню N, то для упрощения стоит выбирать самый короткий путь как прекондишен степс, и описывать все тест кейсы по нему. Из других, более длинных путей, стоит только убедиться, что ты можешь попасть в это самое N меню.

Предлагаю рассматривать каждое меню, как независимый модуль. Поэтому не нужно проверять все N путей попадания в конкретное меню из всех возможных других меню, т.к. баги зачастую возможны лишь на стыке перехода из одного меню в другое.

Вот еще статья на русском:
http://www.akhozya.c...blackberry.html

Если вам для конкретного приложения.. то поделюсь тем,что у меня получилось. Единственная проблема - логи не идеально чистые получаются (чтобы только по этому приложению были), но в целом достаточно компактные, чтобы найти то,что вам нужно.

У вас должен быть установлен Android SDK, моб. устройство подключено к компьютеру с включенной USB-отладкой (т.е. при выполнении adb devices в cmd вам возвращает непустой список девайсов).

Вытягивает ошибки приоритета выше Error

>adb -d logcat [имя пакета приложения]:E *:E > [полный путь к файлу, куда записывать результат собираетесь]

Например: >adb -d logcat test.app:E *:E > D:\test.txt

P.S. Источник: https://developer.an...ine/logcat.html