Практическое применение IBM Rational Functional Tester

Например, предположим, что вы тестируете распознавание  ручного ввода в эмуляторе  VTech Helio Emulator, который показан на рисунке 2.

 
Рисунок 2: Эмулятор VTech Helio Emulator  

Традиционные  сценарии Rational Functional Tester в приложениях, подобных Helio Emulator, малоэффективны. Фактически, как я писал в предыдущей статье о применении низкоуровневых сценариев в IBM® Rational® Robot (см. раздел Ресурсы), почти единственным выбором для таких приложений остается низкоуровневая запись. Перейдя на низкий уровень, вы сможете воспроизвести отдельные компоненты щелчка мышью.

Класс RootTestObject содержит два низкоуровневых метода:

• emitLowLevelEvent(LowLevelEvent)
• emitLowEvent(LowLevelEvent[])

Ниже  приводится список методов для конструирования  низкоуровневых событий LowLevelEvents в фабрике SubitemFactory:

• delay(int) Примечание: в миллисекундах
• keyDown(string)
• keyUp(string)
• mouseMove(point)
• mouseWheel(int)
• leftMouseButtonDown()
• leftMouseButtonUp()
• rightMouseButtonDown()
• rightMouseButtonUp()
• middleMouseButtonDown()
• middleMouseButtonUp()

Код сценария, представленный в листинге 7, рисует на блокноте распознавания  ручного ввода для Helio в Microsoft® Paint®.

 
Листинг 7. Использование  низкоуровневых сценариев в Rational Functional Tester

afx10000008window().click(atPoint(100,100));   LowLevelEvent llEvents[] = new LowLevelEvent[7];   llEvents[0] = mouseMove(atPoint(100,100));   llEvents[1] = leftMouseButtonDown();   llEvents[2] = delay(250);   llEvents[3] = mouseMove(atPoint(105,120));   llEvents[4] = delay(250);   llEvents[5] = mouseMove(atPoint(110,100));   llEvents[6] = leftMouseButtonUp();   getRootTestObject().emitLowLevelEvent(llEvents);

 

Код, представленный в листинге 7, генерирует в окне документа программы букву V как показано на рисунке 3.

 
Рисунок 3: Рисование  при помощи Microsoft Paint в эмуляторе Helio 

Есть  ли недостатки у этой грандиозно эффективной  функции? Насколько я знаю, в отличие  от Rational Robot, весь этот код вам придется писать вручную. Мне не известен способ переключения на низкоуровневую запись в Rational Functional Tester. Но и описанного вполне достаточно. Если вы действительно тестируете программу типа Helio, вам все равно придется создать методы многократного использования для написания букв. Поэтому, вероятнее всего, вам нужно будет разобраться со всеми буквами всего один раз.

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

Улучшение сценариев  при помощи вспомогательного суперкласса

Если  вы не читали статью Денниса Шульца (Dennis Schultz) "Creating a super helper class in IBM Rational Functional Tester," (Создание вспомогательных суперклассов в IBM Rational Functional Tester), перейдите к разделу Ресурсы и прочтите ее сейчас. Эта статья - самый лучший ресурс для изучения того, как работает суперкласс, из всех, которые мне приходилось видеть. Вспомогательные классы помогают добавить функциональности вашим сценариям тестирования.

По  умолчанию, все сценарии Rational Functional Tester представляют собой расширения класса RationalTestScript и поэтому наследуют ряд методов (таких как callScript). Более опытные тестировщики могут предпочесть создание собственных вспомогательных суперклассов, чтобы расширить класс RationalTestScript, добавив в RationalTestScript собственные методы или заменив существующие.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

IBM Rational Functional Tester: Упрощение автоматизации тестирования графического пользовательского интерфейса

Узнайте, как можно использовать шаблон проекта, который помогает автоматически  тестировать графические пользовательские интерфейсы (GUI) с помощью среды IBM Rational Functional Tester в сочетании с инфраструктурой автоматизации тестирования IBM Corporation. Это решение обеспечивает простую архитектуру и предоставляет полный набор функциональных тестов для любого GUI-продукта независимо от его платформы. Шаблон использует предопределенные входные XML-файлы, описывающие последовательность выполнения контрольного теста и ожидаемые окончательные результаты на выходе. Тесты можно разворачивать на различных платформах, генерируя в процессе тестирования детальную трассировку и журналы. В качестве практической демонстрации в статье даются примеры применения шаблона проекта автоматизации тестирования при работе с IBM Database Add-Ins for the Microsoft Visual Studio.

Требования  заказчиков к сокращению времени  разработки и улучшению качества программного обеспечения заставляют организации искать способы автоматизации  и оптимизации своих процессов, чтобы оставаться конкурентоспособными. В этой статье описывается шаблон проекта автоматизации тестирования, который может быть использован  для автоматизации тестирования инструментальных средств, основанных на графическом пользовательском интерфейсе (graphical user interface - GUI), с целью существенного сокращения времени, необходимого для выполнения тестирования при контроле качества (QA). Кроме того, шаблон проекта направлен на смягчение этих проблем и помогает создать идеальную среду с учетом требований автоматизации тестирования. Он предлагает следующие возможности:

• Независимость от платформы. Автоматизация тестирования возможна для множества платформ и вариантов соединений с серверами.
• Расширяемость. Возможность непрерывного добавления новых тестов без изменения существующих тестов и артефактов.
• Отчетность и регрессионное сравнение. Прозрачная автоматическая отчетность со сравнением ожидаемых и фактических результатах теста.
• Простата отладки. Простота создания журналов и трассировки в целях отладки.

Среда IBM Database Add-Ins for Microsoft Visual Studio предоставляет разработчикам интуитивно понятные средства взаимодействия и интеграции компонентов базы данных для приложений в стадии разработки. Этот инструмент, использующий мощные графические конструкторы, мастера и меню, предлагает интегрированную среду разработки для жизненного цикла и обслуживания объектов баз данных IBM (включая таблицы, представления, хранимые процедуры, функции и т.д.). Программа поддерживает все типы серверов IBM DB2 и IDS.

Системные требования

Чтобы работать с предлагаемым шаблоном проекта, необходимы следующие технологии и  артефакты среды разработки:

• Среда поддержки сценариев IBM Rational Functional Tester Java, версия 8.1. Если у вас не установлена лицензионная копия, загрузите пробную версию Rational Functional Tester.

Шаблон проекта автоматизации тестирования

Шаблон  проекта, рассматриваемый в настоящем  документе, изображен ниже в виде архитектурной схемы.

Рисунок 1. Архитектурная схема

Объяснение компонентов архитектуры

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

Test Case Schema (схема контрольного теста)

Этот файл определяет XML-схему  и метаданные для выражения данных теста.

Test Case XML (XML контрольного теста)

Этот файл, основанный на Test Case Schema, содержит фактические данные теста, которые сценарии автоматизации тестирования будут читать при выполнении тестов.

Binding Compiler & Schema Derived Classes & Interfaces (компилятор связывания + производные классы схемы + интерфейсы)

Компилятор связывания JAXB автоматически генерирует необходимые  пакеты для интеграции со сценариями автоматизации тестирования.

Automation Framework and JAXB API (инфраструктура автоматизации и JAXB API)

Сценарий инфраструктуры автоматизации импортирует пакет(ы), сгенерированные компилятором связывания. Для чтения XML-данных контрольного теста используются API JAXB.

Test Application (тестируемое приложение)

Это базовое приложение, которое будет тестироваться.

Trace Log and Result Log (журнал трассировки и журнал результата)

Выходные данные инфраструктуры автоматизации теста представляют собой набор представленных в  понятном формате журналов трассировки  и результатов. В журналах отражаются поток управления и трассировки  стека при сбоях теста.

Сценарий

В этом разделе показано, как наш шаблон проекта используется при разработке механизма автоматизации тестирования для IBM Visual Studio Add-ins.

Шаг 1. Создание XML-схемы для данных контрольного теста

Начнем  с создания схемы для данных контрольного теста. Схема, приведенная ниже, предназначена  для хранения данных, необходимых  для хранимых процедур теста при  работе с IBM Visual Studio Add-In.

• Корневым элементом является testCaseData.
• Элемент servers содержит serverType, хранящий различные типы серверов, которые должны быть протестированы. Типов серверов может быть несколько.
• Procedures - это элемент, который содержит все данные, относящиеся к созданию хранимой процедуры, такие как имя, параметры и их свойства, а также тело хранимой процедуры и ожидаемый результат.

 
Листинг 1. XML-схема для данных контрольного теста

<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">   <xsd:element name="testCaseData">     <xsd:complexType>       <xsd:sequence>         <xsd:element name="servers">           <xsd:complexType>             <xsd:sequence>               <xsd:element maxOccurs="unbounded" name="serverType" type="xsd:string" />             </xsd:sequence>           </xsd:complexType>         </xsd:element>         <xsd:element name="procedures">           <xsd:complexType>             <xsd:sequence>               <xsd:element maxOccurs="unbounded" name="sp">                 <xsd:complexType>                   <xsd:sequence>                     <xsd:element name="name" type="xsd:string" />                     <xsd:element name="description" type="xsd:string" />                     <xsd:element maxOccurs="unbounded" name="param">                       <xsd:complexType>                         <xsd:sequence>                           <xsd:element name="name" type="xsd:string" />                           <xsd:element name="mode" type="xsd:string" />                           <xsd:element name="type" type="xsd:string" />                           <xsd:element name="value" type="xsd:string" />                         </xsd:sequence>                       </xsd:complexType>                     </xsd:element>                     <xsd:element name="body" type="xsd:string" />                     <xsd:element name="expectedResult" type="xsd:string" />                   </xsd:sequence>                 </xsd:complexType>               </xsd:element>             </xsd:sequence>           </xsd:complexType>         </xsd:element>       </xsd:sequence>     </xsd:complexType>   </xsd:element> </xsd:schema>

Теперь  запустим компилятор связывания JAXB для создания Java-пакета, который содержит все Java-классы, основанные на схеме контрольного теста.

После завершения скомпилируем Java-пакет, чтобы сгенерировать файлы классов и импортировать созданные классы в сценарий автоматизации тестирования.

Эти шаги описаны (с примером) в следующем  разделе статьи.

Шаг 2. Создание файла спецификации сервера

Задайте данные сервера в файле спецификации сервера. Этот файл специфичен для тестируемого приложения. Данные о сервере не включаются в XML-файл контрольного теста, потому что они не меняются так  часто, как данные файла контрольного теста. Файл спецификации сервера является общим для всех контрольных тестов, и информация в этом файле изменяется только тогда, когда происходят какие-либо изменения в параметрах подключения к серверу. На эту информацию ссылается элемент serverType схемы, рассмотренной на шаге 1.

 
Листинг 2. Файл спецификации сервера

#yes/no для теста LUW97 gsTestLUW97=yes #URL теста LUW97Server gsTestLUW97URL=server1.test.ibm.com:50000 #ID теста LUW97user gsTestLUW97UserID=UserName #Пароль теста LUW97user gsTestLUW97Password=password #Тест LUW97dbname gsTestLUW97DBName=SAMPLE #Информация о версии теста LUW97dbname gsTestLUW97DBVersion=[DB2/NT 09.07.0001]   #yes/no для теста LUW95 gsTestLUW95=yes #URL теста LUW95Server gsTestLUW95URL=server2.test.ibm.com:50000 #ID теста LUW95user gsTestLUW95UserID=UserName #Пароль теста LUW95user gsTestLUW95Password=password #Тест LUW95dbname gsTestLUW95DBName=SAMPLE #Информация о версии теста LUW97dbname gsTestLUW97DBVersion=[DB2/NT 09.05.0005]

В приведенном  выше файле свойств все выражения, начинающиеся с #, являются комментариями.

• gsTestLUW97URL содержит URL сервера для подключения LUW v97.
• gsTestLUW97UserID и gsTestLUW97Password содержат идентификатор пользователя и пароль для подключения к данному серверу.

Аналогичным образом в этом файле задается другая информация, необходимая для  установления соединения с сервером.

Шаг 3. Создание примера XML-файла контрольного теста

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

 
Листинг 3. Пример XML-файла контрольного теста

<?xml version="1.0"?> <testCaseData>   <servers>     <serverType>LUWV97</serverType>   </servers>   <procedures>     <sp>       <name>vsai_fvt0001</name>       <description>Stored Procedure with 1 INTEGER IN parameters</description>       <param>         <name>Zipcode</name>         <mode>IN</mode>         <type>INTEGER</type>         <value>95054</value>       </param>       <body></body>       <expectedResult>\expectedResult\SP\vsai_fvt0001.xml</expectedResult>     </sp>   </procedures> </testCaseData>