Наверное, каждый из нас сталкивался с подобной ситуацией: при работе с программой в самый неожиданный момент появлялось непонятное сообщение, после чего приложение закрывалось.

Мы называем это “крэшем” приложения. Такие ошибки классифицируются как ошибки с самой высокой важностью. Сегодня мы рассмотрим, как идентифицировать такие ошибки и с помощью инструмента Quick Test Professional автоматизировать их поиск в приложении.

Quick Test Professional — это программный продукт от HP, который по праву лидирует на рынке приложений по автоматизации тестирования. Мы выбрали Quick Test Professional, потому что он распознает “контролы” (графические элементы приложения) лучше, чем аналоги.

В нашем случае тестируемое приложение использует .NET 4.0. Однако нам так и не удалось применить средства Microsoft Visual Studio для автоматизированного тестирования.

Конечно, у QTP есть и недостатки – затруднительные вопросы, возникающие в процессе работы с этим продуктом, решаются непросто. В большинстве случаев действия оказываются нетривиальными – от создания вручную ключей в реестре до ручной регистрации библиотек. Некоторые проблемы решаются путем установки патчей.

Какие инструменты QTP мы использовали

В QTP предлагается множество функциональных элементов для проверки и взаимодействия с тестируемым приложением:

• различные “чекпоинты” (checkpoints);
• ручные сообщения об ошибках;
• чтение/запись информации в параметры теста;
• средство описания контролов через descriptive programming;
• различные уровни ошибок (Done, Passed, Info, Warning, Error);
• подключение пользовательских функций из внешнего файла;
• Recovery Scenario.

Среди всех вышеперечисленных не нашлось применения только для Recovery Scenario.

Recovery Scenario — специальная функция, предназначенная для исправления непредвиденных событий.

На первый взгляд может показаться: это именно то, что нам нужно. Однако для решения проблемы необходимо скопировать из “крэш”-сообщения в журнале трассировки (trace log) событие, вызвавшее “крэш”, и сохранить его для отправки разработчику. После этого следует выполнить сценарий закрытия приложения после крэша и остановить выполнение теста.

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

Итак, поскольку предложенный функционал QTP нам не подходит, нужно найти другое решение. Прежде всего, следует определить: когда возникает крэш приложения? В нашем случае приложение клиент-сервисное, со встроенными валидациями на стороне клиента.

Обращение к сервису происходит только при необходимости получить или передать какие-либо данные. Кроме этого, сервис работает с базой данных и API стороннего приложения, в которых есть свои правила валидации данных. Если переданные данные не проходят валидацию здесь, клиенту возвращается необработанное исключение.

Для данного приложения необработанные исключения могут быть двух типов — нарушение совместимости или связи между клиентом и сервисом, а также ошибки, переданные от третьей стороны. В любом случае у обоих типов есть общая черта — они возникают только в процессе взаимодействия клиента с сервисом.

В следующем посте мы расскажем о практическом применении QTP.