Тестирование терминальных приложений при помощи Rational Functional Tester. Часть 4

Источник: developerworks

Читать часть 3

Изучаем скрипт

Описание скрипта

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

Скрипт

Скрипт - это код, который отображается в центральной панели окна IBM Rational Functional Tester .

     

Если вы уже знакомы со скриптами Functional Tester для Web-, Java- или .NET-приложений, этот код покажется вам знакомым. Данный конкретный скрипт записан на языке Java. (Не забудьте, что точно так же можно использовать среду Microsoft Visual Studio .NET и записывать скрипты на Visual Basic .NET.) Это означает, что если вы немного знаете программирование, то можете делать со скриптом Functional Tester то же, что и с любой Java-программой. В код можно встроить артефакты, созданные вашими разработчиками, например, алгоритмы и классы, которые могут быть полезными для тестирования. Это также означает и то, что скриптовые языки, которые изучают ваши тестировщики, являются стандартизированными, а не принадлежат конкретной компании. Тестировщики, которые хотят научиться читать код, могут использовать множество книг и обучающих дистанционных курсов.

Даже не обучаясь на курсах Java, вы сможете легко прочитать скрипт и понять, что происходит в процессе его выполнения. Давайте подробно рассмотрим несколько выражений. Следующее выражение инструктирует Functional Tester о том, что нужно выполнить щелчок левой кнопкой мыши в текстовом поле в окне эмулятора:

hostText().click(atPoint(41,11));

Следующее выражение передает терминалу нажатия клавиш cicsa, а затем клавиши Enter:

tFrame().inputKeys("cicsa{ENTER}");

Следующее выражение выполняет проверку свойства точки верификации для поля сообщения о состоянии в окне real-time quote:

Field_22_2_standardVP().performTest();

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

// Company Selection Screen
tFrame(ANY,LOADED).inputKeys("1{ENTER}");

Можно порекомендовать частую вставку комментариев в ходе записи теста.

 

Карта объекта

Итак, если скрипт приказывает IBM Rational Functional Tester выполнить тест по отношению к определенному полю в окне, как Functional Tester сможет понять, какое поле необходимо проверить? Каждый объект, с которым мы сталкиваемся при записи, фиксируется в карте тестовых объектов Объекты, с которыми вы взаимодействовали, можно увидеть в представлении Script Explorer, расположенном справа от представления скрипта.

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

Карта объектов, кроме того, содержит некоторые фрагменты информации о полях нашего приложения. При воспроизведении скрипта Functional Tester сверится с картой объектов, чтобы определить, какой именно объект или какое поле необходимо использовать. В данном разделе мы рассмотрим этот момент более подробно.

Выполните двойной щелчок на элементе карты объектов field_16_63 в представлении Script Explorer. Откроется окно, отображающее карту тестовых объектов.

Многие инструменты автоматизированного тестирования для идентификации объектов в процессе воспроизведения используют только одно свойство. Но что происходит, если значение свойства изменяется? Это часто приводит к ошибке воспроизведения и необходимости изменения ожидаемого значения свойства для продолжения тестирования. Functional Tester использует другой механизм. В данном случае Functional Tester записал пять свойств и их значения. Допустим, в следующей сборке приложения значение в текстовом поле больше не равно 0100. Никаких проблем. В распоряжении Functional Tester есть еще четыре значения других свойств, которые можно использовать для идентификации данного объекта. Что произойдет в том случае, если разработчик в следующей сборке передвинет поле на одну строку ниже? Скорее всего, проблем тоже не возникнет. Functional Tester использует передовую систему распознавания объектов ScriptAssure, позволяющую проанализировать поля окна приложения и определить, какое из них с наибольшей вероятностью является правильным, даже если с момента записи скрипта изменилось несколько свойств объекта. При помощи свойств и их весовых коэффициентов мы можем контролировать, насколько толерантным или строгим будет поведение Functional Tester при распознавании объектов.

Выделите самый верхний элемент в карте объектов Object Map - Java: Frame: TFrame: com.ibm.terminal.tester.gui.panel.TFrame. Этот объект представляет фрейм эмулятора терминала. Обратите внимание, что свойства .captionText и accessibleContext.accessibleName содержат имя конфигурационного файла подключения, используемого для подключения к приложению. Functional Tester записывает имя конфигурационного файла подключения одновременно с записью окна эмулятора. Во многих случаях это достаточно удобно и означает, что можно открыть несколько окон эмулятора терминала и взаимодействовать с ними в рамках одного сеанса тестирования. Functional Tester сможет отличить одно окно от другого при помощи этих отличительных свойств.

В нашем случае нужно использовать два конфигурационных файла подключений - для версии 1 и для версии 2- попеременно. Чтобы изменить поведение Functional Tester по умолчанию, измените значения в столбце весовых коэффициентов для свойств .captionText и accessibleContext.accessibleName на ноль. Вы недвусмысленно проинформируете Functional Tester о том, что не нужно беспокоиться о записи свойств окна эмулятора.

На этом мы закончим краткое описание карты объектов. Закройте окно карты объектов. В окне с запросом на сохранение изменений нажмите кнопку Yes.

Пул данных

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

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

  1. Нажмите правой кнопкой мыши на элементе Test Datapool в панели Script Explorer и выберите команду Associate with datapool..
  2. Выберите из списка пула данных в текущем проекте Private Test Datapool. Частный тестовый пул данных видим только для данного скрипта. В реальной среде вы, скорее всего, захотите создать общий тестовый пул данных, который будет видимым из любого количества тестовых скриптов. Это позволит эффективно использовать наборы данных в нескольких тестах и несколькими тестировщиками. Нажмите кнопку OK.
  3. Скрипты для терминалов часто содержат большое количество литеральных текстовых строк, а эти данные не всегда могут быть представлены в нужном формате. Например, найдите в нашем скрипте следующие строки: 
    tFrame().inputKeys("jan{TAB}");
tFrame().inputKeys("janpwd{ENTER}");

    Первая строка вводит имя пользователя jan и нажатие клавиши Tab для перехода в поле password. Вторая строка вводит janpwd в поле password и нажатие клавиши Enter. Нам нужно извлечь текст имени пользователя и пароля в пул данных, но сохранить в скрипте команды Tab и Enter. Замените эти две команды следующими четырьмя строками: 

    tFrame().inputKeys("jan");
tFrame().inputKeys("{TAB}");
tFrame().inputKeys("janpwd");
tFrame().inputKeys("{ENTER}");

  4. Просмотрите скрипт и найдите литеральные значения, которые можно заменить ссылками на пул данных. Чтобы помочь вам в этом, в Functional Tester имеется специальный мастер. Чтобы указать мастеру строки, которые мы рассматривали выше, установите указатель мыши в начало первой из четырех только что введенных нами строк, а затем нажмите и отпустите левую кнопку мыши.
  5. При помощи команд меню Script > Find Literals and Replace with Datapool References вызовите мастер. Если вы все сделали правильно, то мастер сразу же найдет литеральную строку jan. Теперь мы можем указать имя для переменной пула данных или столбец, который нужно ассоциировать с этими данными. Введите username в поле Datapool Variable. Установите флажок Add Literal to Datapool. Нажмите кнопку Replace для выполнения подстановки.
  6. Как только вы нажмете кнопку на предыдущем шаге, мастер найдет следующую литеральную строку в скрипте, а именно {TAB}. Мы не хотим делать подстановку для этого значения, поэтому просто нажмите кнопку Find, чтобы перейти к следующей литеральной строке.
  7. На этот раз мастер обнаружил значение janpwd. Мы хотим выполнить подстановку для этого значения, но с помощью новой переменной пула данных. Введите в поле Datapool Variable значение password, чтобы заменить значение по умолчанию, username. Нажмите кнопку Replace, чтобы выполнить подстановку.
  8. Это последнее значение, необходимое для подключения к пулу данных, поэтому нажмите кнопку Close.

Обратите внимание на представление Test Datapool в нижней части окна - это таблица, содержащая данные, которые можно использовать в скрипте. В эту таблицу уже внесены данные, извлеченные из скрипта мастером. Вы можете записать в эту таблицу дополнительные строки данных при помощи контекстного меню или импорта данных из CSV-файла. К сожалению, эмулированное серверное приложение состоит из простых, статичных окон и не даст отклика на измененные данные, поэтому при воспроизведении данного скрипта мы не сможем продемонстрировать эффективное изменение имен пользователей и паролей. Если вам интересно изучить более подробный пример использования пула данных, просмотрите упоминавшееся ранее учебное руководство "Automate regression tests: IBM Rational Functional Tester makes regression testing a snap" . В этом учебном руководстве рассматривается процесс создания и настройки управляемого данными теста для Java-приложения.

Анализ проделанной работы

В этом разделе мы изучили довольно много материала, поэтому стоит потратить несколько минут на анализ сделанного.

  • Мы рассмотрели три компонента теста: скрипт, карту объектов и пул данных.
  • Скрипт содержит запись процедуры теста на Java или Visual Basic .NET - одном из эффективных стандартизированных скриптовых языков.
  • Карта объекта содержит запись характеристик объектов и полей, использовавшихся в процессе записи. Современный механизм воспроизведения скриптов ScriptAssure использует эту карту для того, чтобы гарантировать устойчивость скрипта к изменениям пользовательского интерфейса в тестируемом приложении.
  • Мы создали пул данных и использовали специальный мастер для того, чтобы извлечь литеральные данные из скрипта в пул данных. Тем самым мы отделили процедуру теста от тестовых данных и получили возможность многократно использовать данный скрипт для выполнения множества аналогичных скриптов с уникальными наборами данных.

Вероятно, вас интересует, как будет воспроизводиться скрипт в IBM Rational Functional Tester . В конце концов, ради этого мы и проделали всю работу, правда? В следующем разделе мы подробно рассмотрим процесс воспроизведения теста и анализа результатов.

Читать часть 5


Страница сайта http://www.interface.ru
Оригинал находится по адресу http://www.interface.ru/home.asp?artId=23795