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>

Вышеуказанный XML-документ основан на схеме, описанной на шаге 1.

• <testCaseData> является корневым элементом документа.
• <ServerType> содержит имя сервера LUWV97, на котором будут выполняться контрольные тесты.
• <Procedures> содержит создаваемые хранимые процедуры <sp>. В приведенном выше примере есть только одна <sp>.
• <sp> содержит имя vsai_fvt0001, детали параметров в теге <param>, а в <expectedResult> - путь к файлу ожидаемых результатов для хранимой процедуры. Пример процедуры имеет один входной параметр с именем ZIPCODE, типом INTEGER и значением 95054.

Шаг 4. Выполнение сценариев автоматизации тестирования

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

Рисунок 2. Конструктор хранимых процедур в Visual Studio

Теперь посмотрите на журналы, чтобы определить результат теста.

Рисунок 3. Log-файл результата

Если тест не прошел, можно посмотреть сгенерированный файл журнала трассировки, чтобы устранить проблему. Пример файла трассировки приведен ниже.

Рисунок 4. Файл журнала трассировки

Реализация инфраструктуры автоматизации

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

Создание Java-классов контрольного теста с использованием JAXB

Приведенная ниже команда связывания берет файл testCaseData.xsd, описанный на шаге 1, и генерирует пакет jaxb.testData, который будет содержать все производные классы, основанные на схеме.

Связывание:

Xjc -p jaxb.testData testCaseData.xsd -d autoClasses

Опция -p определяет пакет для созданных классов, а опция -d - целевой каталог. Таким образом, данная команда упаковывает классы в пакет jaxb.testData в каталоге autoClasses.

Компилятор связывания создает набор классов, которые представляют элементы в схеме.

Компиляция:

javac jaxb/testData/*.java

Данная команда компилирует все выходные Java-файлы, созданные процессом связывания, и создает файлы классов.

Сценарий автоматизации должен импортировать пакет, созданный процессом связывания, и может получить доступ к данным в файле testCaseData.xml, используя демаршализованный API JAXB, как показано ниже в листинге 4.

Листинг 4. Использование демаршализованного API JAXB для доступа к данным контрольного теста

private TestCaseData GetTestCaseData() {
TestCaseData tcData = null;
try {
	JAXBContext jc = JAXBContext. newInstance ("jaxb.testData");
	Unmarshaller u = jc.createUnmarshaller();
	// Проверка схемы с помощью XML-файла
	u.setEventHandler(new javax.xml.bind.helpers.DefaultValidationEventHandler());
	tcData = (TestCaseData) u.unmarshal(new FileInputStream(
					"TestCaseData.xml"));
			return (tcData);
} catch (JAXBException je) {
	je.printStackTrace();
} catch (IOException ioe) {
	ioe.printStackTrace();
}
	return (null);
}

Как только XML-файл демаршализован, данные XML-файла могут быть использованы в качестве объектов (см. листинг 5).

Листинг 5. Использование объектов данных контрольного теста

// Получить xml-файл testCaseData в качестве объекта
TestCaseData tcData = GetTestCaseData();

// Получить все серверы, ожидаемые для теста
List serverList = tcData.getServers().getServerType();
List spList = tcData.getProcedures().getSp();

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

Выполнение контрольных тестов

Инфраструктура автоматизации выполняет для каждого контрольного теста следующие шаги:

• Открывает тестируемое приложение.
• Запускает трассировку.
• Читает файл данных контрольного теста.
• Обходит все серверы и добавляет подключение к серверу базы данных в IBM Database Add-Ins, основываясь на данных файла данных контрольного теста.
• Для каждого типа сервера, упомянутого в файле данных контрольного теста, перебирает все данные хранимой процедуры и создает хранимую процедуру.
• Выполняет хранимую процедуру и записывает результат в файл журнала результатов.
• Добавляет запись в файл журнала трассировки в начале и в конце каждого вызываемого метода, а также при возникновении исключительной ситуации.
• Сравнивает результат теста с ожидаемым результатом и обновляет файл журнала результатов.

Расширяемость

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

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

Резюме

Развернув шаблон теста с помощью описанных выше действий, вы получаете в свое распоряжение инфраструктуру автоматизации тестирования, которая позволяет осуществлять автоматизированное тестирование IBM Database Add-Ins for Visual Studio. В настоящее время реализуется инфраструктура для автоматизированного тестирования хранимых процедур. Дальнейшая работа будет направлена на расширение инфраструктуры с целью автоматизации тестирования других элементов, таких как таблицы, функции и представления.