Использование IBM Rational Functional Tester для автоматизированного тестирования глобализованных приложений

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

Предварительные требования

• Установленная программа IBM Rational Functional Tester Version 6 или 7 вместе с необходимыми языковыми пакетами (language packs).

• Установленные языковые пакеты операционной системы для всех необходимых месторасположений в зависимости от требований (например, японский, китайский и французский).

Обзор автоматизации тестирования

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

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

При использовании IBM Rational Functional Tester в качестве инструментария процесс автоматизации тестирования делится на три этапа:

1. Запись. Сценарий тестирования записывается "на лету" по мере работы пользователя с приложением. Можно также вставить точки верификации (verification points) для проверки ответа системы и сделать сценарии тестирования зависящими от данных, чтобы выполнять один и тот же сценарий с различными наборами входных данных.

2. Улучшение. Добавление кода, выполняющего разнообразные функции. Типичные изменения сценариев тестирования - условное ветвление, рефакторинг и обработка исключительных ситуаций.

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

Типичные проблемы глобализованной автоматизации тестирования

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

Глобализованными называются приложения, в которых все данные (например, сообщения, метки и текст) локализованы , то есть переведены на язык локали, в которой приложения выполняются или из которой запускаются. Например, если приложение запущено в японской локали или операционной системе, вся информация отображается на японском языке. Аналогично, если приложение запущенно во французской локали или операционной системе, вся информация отображается на французском языке и т.д. Термин "глобализованные" относится также к приложениям, которые позволяют вводить и выводить информацию с использованием кодировки символов, отличной от английской.

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

• Автоматизированные сценарии, записанные в одной локали, не воспроизводятся в другой. Это происходит из-за того, что определение объекта, используемое для воспроизведения автоматизированного сценария (например, метка кнопки, с которой должен работать сценарий автоматизации), может быть разным для английской и японской локалей (см. рисунок 1).

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

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

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

Рисунок 1. Сценарий, записанный в одной локали и воспроизводимый в другой, не работает

Проблема: модель запись/воспроизведение не работает.
Причина: тестируемое приложение является глобализованным

• Записано в локали 1 (например, English).
• Воспроизведено в локали 2 (например, Japanese).
• Результат: сценарий не работает.
• Причина: определение объекта, используемое для воспроизведения сценария автоматизации, отличается для различных локалей.

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

Как работает автоматизированное тестирование глобализованных приложений

Глобализованное приложение использует локальный файл ресурсов для отображения сообщений, меток и текста в одном и том же приложении, которое будет запускаться в различных локалях. Рассматриваемый в данной статье подход, основанный на программе IBM Rational Functional Tester, использует локальные файлы ресурсов, которые поставляются вместе с глобализованным приложением. Локальный файл ресурсов один в один отображает значение свойства объекта на переменную, соответствующую этому значению. Это помогает извлечь эквивалентное текстовое значение из файла ресурсов в зависимости от локали, в которой было запущено приложение при воспроизведении.

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

Рисунок 2. Графическое представление отображения объектов

Рисунок 3. Базовая утилита, предоставляющая возможность автоматизированного тестирования глобализованных приложений

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

Этапы автоматизации тестирования глобализованных приложений

Реализацию данного подхода начнем с примера глобализованного приложения JFC-кнопки (Java™ foundation class). Свойства accessibleName и name этой JFC-кнопки локализованы. Это означает, что значение, соответствующее этим свойствам, будет зависеть от локали, в которой запускается приложение.

На рисунке 4 показано, как скомпоновано и спакетировано глобализованное приложение. В данном случае приложение JFC-кнопки представляет собой исполняемый JAR-файл (Java™ Archive). Это исходный код в виде Java-классов в комбинации с различными локальными файлами ресурсов, которые делают возможным перевод текстов приложения. Таким образом, когда приложение запускается в различных локалях, появляющийся в пользовательском интерфейсе текст читается из соответствующего файла ресурсов для данной локали. Это и делает приложение глобализованным.

Рисунок 4. Структура глобализованного приложения JFC-кнопки

Запись

Чтобы автоматизировать любое глобализованное приложение, которое записывается только в одной локали и воспроизводится в других (например, Japanese, Chinese или French), выполните следующие действия:

1. Установите переменную Enable Localization в значение True (rational.test.ft.services.enable_localization=true) в файле ivory.properties, который находится в каталоге установки Rational Functional Tester (см. код в листинге 1).

Листинг 1. Фрагмент из файла ivory.properties, в котором переменная Enable Localization устанавливается в значение True

                
###
### Внутренние свойства: не предназначены для изменений клиентом
###
# Номер версии, применяемый для плагина enabler.wsw при включении командной
# оболочки eclipse
rational.test.ft.enabler.plugin.version=7.0.0
# параметры запуска JVM клиента rationsl 
#rational.test.ft.client.jvm_options=-xj9
# Разрешение данного параметра позволяет установить каталог install для локального 
# TestContext отличным от глобальной настройки
# (каталог install первого создаваемого TestContext)
rational.test.ft.install_dir.ignore_mismatch=true
# Разрешение данного параметра позволяет запись/воспроизведение для собственного
# UI продукта 
rational.test.ft.testability.allow_testing=true
# Разрешение этого свойства позволяет искать строку в локализованной 
# таблице строк (если она доступна) 
rational.test.ft.services.enable_localization=true
# Внутреннее. Позволяет подключаться к проекту .NET для тестирования
# интегрированной среды выполнения
#rational.test.ft.testability.allow_vbnet_remote=true

На шаге 2 используются возможности интегрированной среды IBM® (ранее известной под названием ITCL) для разработки сценариев тестирования в Rational Functional Tester. Использование этой интегрированной среды обеспечивает структурный подход к разработке сценариев тестирования, а также дает другие преимущества: уровень абстракции для сценариев автоматизации тестирования путем оформления их в AppObjects, задания (tasks) и уровни контрольных примеров (test case layers); минимальная сложность, повторно используемые обобщенные сценарии тестирования; базовый набор библиотечных файлов, предоставляющих общую функциональность для разработки и распространения сценариев тестирования.

2. С помощью интегрированной среды IBM организуйте сценарии Rational Functional Tester, разработанных для глобализованного приложения JFC-кнопки, в три уровня (показанные на рисунке 5):
   • Уровень appObjects: создает класс appJbutton, сохраняющий объекты, с которыми будет взаимодействовать сценарий тестирования.
   • Уровень tasks: создает класс taskJbutton, в котором записана реальная логика в виде различных заданий , также называемых функциями .
   • Уровень testCases: создает класс testCaseJbutton, в котором различные задания уровня tasks используются для формирования полного сценария тестирования.

Рисунок 5. Использование интегрированной среды IBM для организации сценариев Rational Functional Tester

3. Запишите сценарий в любой локали (например, English), используя Rational Functional Tester.
   1. Определите все свойства объектов со значениями, различными для различных локалей.
   2. Теперь откройте файл определения объектов, известный как карта объектов, в Rational Functional Tester.
   3. Выберите свойство объекта, разное для разных локалей. В данном примере приложения отличаются свойства accessibleName и name объекта javax.swing.Jbutton (см. рисунок 6).

Рисунок 6. Карта объектов глобализованного приложения, выбрано свойство объекта с меняющимся значением

4. Найдите значение свойства объекта в файле ресурсов приложения JFC-кнопки. В данном случае меняющимся значением свойства объекта является текст Remove. Это значение в локали English, а вот эквивалентный текст в других локалях (см. листинги 2 и 3).

Листинг 2. Фрагмент из файла ресурсов локали English с парой ключ-значение (значение переменная-свойство)

                
# NLS_MESSAGEFORMAT_VAR
sampleapp.remove = Remove

Листинг 3. Фрагмент из файла ресурсов локали Japanese с парой ключ-значение (значение переменная-свойство)

                
# NLS_MESSAGEFORMAT_VAR
sampleapp.remove = \u9664\u53bb(E)

Улучшение

5. Замените значение в карте объектов Rational Functional Tester соответствующим названием переменной, найденной в файле ресурсов. В данном случае значением свойств accessibleName и name объекта javax.swing.Jbutton был текст Remove. Он заменяется именем переменной sampleapp.remove, поскольку это ключ, соответствующий значению Remove (рисунок 7).

Рисунок 7. Карта объектов до (со значением свойства) и после (со значением свойства, замененным переменной из файла ресурсов)

6. Поместите копии всех файлов ресурсов локализованного приложения в каталог resources проекта.
   1. Измените имена всех файлов ресурсов так, чтобы они начинались с имени проекта Rational Functional Tester и содержали названия локалей. В данном примере файлы ресурсов переименованы таким образом, чтобы они начинались с BeyondlocaleBarrier (поскольку это имя проекта) и продолжались названиями соответствующих локалей (см. рисунок 8).
   2. Таким образом, в нашем примере имя файла для локали Japanese выглядит как BeyondLocaleBarrier_ja.properties. Это гарантирует, что значение, соответствующее переменной, назначенной свойству объекта (см. шаг 5), извлекается сценариями Rational Functional Tester для корректного распознавания объектов во время воспроизведения.

Рисунок 8. Файлы ресурсов локализованного приложения, помещенные в папку ресурсов проекта

7. Напишите вспомогательную программу National Language Support (NLS) (как показано на рисунке 9), которая:
   • Принимает переменную, соответствующую значению свойства объекта.
   • Определяет текущую локаль (например, Japanese).
   • Ищет файл ресурсов для текущей локали.
   • Ищет переменную в файле ресурсов.
   • Возвращает локализованное значение:
     • Установите его как значение свойства объекта для корректного распознавания с использованием setProperty() API.
     • Используйте его для необходимых условных проверок или точек верификации (рисунок 10).

Рисунок 9. NLS-программа, написанная для тестирования глобализованного приложения JFC-кнопки

Рисунок 10. Использование возможностей NLS-программы для реализации условных проверок или точек верификации, гарантирующих соответствие названия кнопки фактической локали

Воспроизведение

8. Воспроизведите сценарий для различных локалей, например, Japanese, Chinese и French. Сценарий тестирования выполнятся успешно, поскольку он теперь не зависит от локали (см. рисунки 11 и 12).

Рисунок 11. Rational Functional Tester воспроизводит сценарий тестирования для приложения, запущенного в локали Japanese, которая отличается от локали, использованной при записи сценария

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

Рисунок 12. Журнал регистрации событий при воспроизведении сценария Rational

Преимущества подхода

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

• Регрессионное тестирование глобализации
  • Группы аавтоматизированного тестирования могут использовать преимущества данного подхода для создания инструментов автоматизированного регрессионного тестирования для тестирования глобализованных приложений в пошаговом режиме "сборка за сборкой".
• Записанное один раз работает везде
  • Сценарии автоматизации можно разрабатывать в локали English и выполнять в других локалях (Japanese, Chinese, French и т.д.) без каких-либо изменений.
• Разумное использование времени
  • Если время работы одного тестировщика по автоматизации тестирования составляло, скажем, X дней, то для девяти локалей оно составит 9*X дней.
  • Автоматизация тестирования глобализованных приложений с использованием IBM Rational Functional Tester займет максимум 2*X дней.
• Простота обслуживания
  • При изменении текста или метки в тестируемом приложении меняется только один файл ресурсов, а не сценарии автоматизации. Это позволяет обновлять объекты и соответствующие их свойства в одном месте.